软件测试技术
按开发阶段划分
单元测试（模块测试）
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。
测试阶段：编码后或者编码前
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
1. 模块接口测试；
2. 模块局部数据结构测试；
3. 模块边界条件测试；
4. 模块中所有独立执行通路测试；
5. 模块的各条错误处理通路测试。
集成测试（联合测试、组装测试）
将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。
集成主要目的是检查软件单位之间的接口是否正确。
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
1. 把各个模块连接起来时，穿越模块接口的数据是否会丢失。
2. 各个子功能组合起来，能否达到预期的要求的父功能。
3. 一个模块的功能是否会对另一个模块的功能产生不利的影响。
4. 全局数据结构是否有问题，会不会被异常修改。
5. 单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。
时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
冒烟测试
对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。也可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
验收测试（交付测试）
验收测试是部署软件之前的最后一个测试操作。技术测试的最后一个阶段。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）
测试人员：主要是最终用户或者需求方
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能…各类文档等)
按测试实施组织
α 测试
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件，在正式发布前，通常需要执行α和β 测试。α测试不能由程序员或测试员完成。
β 测试
β 测试是一种验收测试。β 测试由软件的最终用户们在一个或多个场所进行。
α测试与β 测试的区别：
- 测试的场所不同：
α测试是指把用户请到开发方的场所来测试；
β 测试是指在一个或多个用户的场所进行的测试。 - α测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。
β 测试的环境是不受开发方控制的，用户数量相对比较多，时间不集中。 - α测试先于β 测试执行。通用的软件产品需要较大规模的β 测试，测试周期比较长。
第三方测试
介于开发方和用户方间的组织的测试
按测试执行方式
静态方式
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。
分析如下：
- 检查项：
代码风格和规则审核；
程序设计和结构的审核；
业务逻辑的审核；
走查、审查与技术复审手册。 - 静态质量：度量依据标准是ISO9126。该标准，软件的质量用以下几个方面来衡量，即功能性 (Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性（Maintainability）、可移植性(Portability)。
动态方式
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性 能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。
大多数软件测试工作都属于动态测试。
按是否查看代码
黑盒测试（功能测试）
测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。
白盒测试
白盒指的打开盒子，去研究里面的源代码和程序结果。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
按是否手工执行划分
手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
总结优缺点：
优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错。
自动化测试
在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。通常所说的自动化是指功能测试自动化。
自动化实施步骤：
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化
按测试对象划分
性能测试
检查系统是否满足需求规格说明书中规定的性能。
- 对资源利用进行的精确度量
- 对执行间隔
- 日志事件
- 响应时间
- 吞吐量
- 辅助存储区
- 处理精度等进行的监测
内存泄漏测试
从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。
造成内存泄露的原因：
分配完内存之后忘了回收
程序写法有问题，造成没办法回收
某些API函数的使用不正确，造成内存泄露
没有及时释放
内存泄漏的检测：
1、对于不同的程序可以使用不同的方法来进行内存泄露的检查，还可以用一些专门的工具来进行内存问题的检查。
2、通过代码扫描分析工具来检查
安全测试
检查系统对非法侵入的防范能力。安全测试期间。测试人员假扮非法入侵者，采用各种办法试图突破防线。系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。
兼容性测试
兼容性主要是指软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。
- 平台测试
- 浏览器测试
- 软件本身能否向前或者向后兼容
- 测试软件能否与其它相关的软件兼容
- 数据兼容性测试
文档测试
- 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
- 用户文件：用户手册、操作手册，
用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。 - 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
易用性测试（用户体验测试）
易用性是交互的适应性、功能性和有效性的集中体现。
业务测试
是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
查看邮件：
登录网站-输入用户名、密码登录-进入收件箱-查到邮件-点击打开-查阅-关闭邮件-退出邮件-关闭网站
界面测试（UI测试）
测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
安装测试
测试程序的安装、卸载
容错性测试
主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。容错测试首先要通过各种手段，让软件强制性地发生故障，然后验证系统是否能尽快恢复。对于自动恢复需验证熏新初始化、检查点、数据恢复和重新启动等机制的正确性。
容错性测试包括两个方面：
- 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
- 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；
对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
容错性好的软件能确保系统不发生无法意料的事故。当软件出现故障时如何进行故障的转移与恢复有用的数据是十分重要的。
容量测试
预先分析出反映软件系统应用特征的某项指标的极限值。知道系统的实际容量，如果不能满足要求，就应该寻求新的解决方案， 以提高系统的容量。
压力测试
压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。
压力测试的目的就是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，以提高软件系统的可靠性、稳定性，减少系统的宕机时间和因此带来的损失。