测试原理1

测试阶段分类：

1. 单元测试（Unit Testing）又称模块测试（Module Testing），是指对软件中的最小可测试单元进行测试，目的是检查每个单元是否能够正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种缺陷。

2. 集成测试（Integration Testing）又称组装测试，是在单元测试的基础上，按照设计要求，将通过单元测试的单元组装成系统或子系统而进行的有序的测试，目的是检验不同程序单元或部件之间的接口关系是否符合概要设计的要求，能否正常运行。

3. 确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试检测与证实软件是否满足软件需求说明书中规定的要求。

4. 系统测试（System Testing）是为了验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试，是在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

系统测试主要由黑盒测试工程师在整个系统集成好之后进行。前期主要看系统功能是否满足需求，这被称为功能测试。后期主要测试系统运行是否满足要求，以及系统在不同硬件和软件环境中的兼容性等，这被分别称为性能测试、兼容性测试、用户界面测试等。有人也喜欢将功能测试从系统测试中单独提出来，作为集成测试和系统测试之间的一个测试环节。
系统测试的主要依据是软件的需求规格说明文档。

5.验收测试（Acceptance Testing）又称接受测试，是一种正式的测试，是在系统测试后期，以用户测试为主，或有测试人员等质量保证人员共同参与的测试，是一般由用户或其他权威机构来决定是否可以接受一个产品（系统或组件）的验证性测试。验收测试是软件正式交付给用户使用的最后一个测试环节，并决定用户是否最终验收签字和结清所有应付款。
主要依据 软件需求规格说明文档和验收标准。
测试用例 可以直接采用内部测试组所设计的系统测试用例的子集，也可以由验收人员自行设计。

• α测试(开发方测试):开发方通过检测和提供客观证据，证明软件运行是否满足用户规定的需求。
• β测试是内部测试之后的外部公开测试，是将软件完全交给用户，让用户在实际使用环境下进行的对产品预发布版本的测试。

软件测试的分类

静态测试

又称静态分析（Static Analysis），是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。

主要包括对源代码、程序界面和各类文档及中间产品（如产品规格说明书、技术设计文档等）所做的测试。

（1）对于源代码
静态测试主要是看代码是否符合相应的标准和规范，如可读性、可维护性等，其工作过程类似一个编译器，随着语法分析的进行做特定工作，如分析模块调用图、程序的控制流图等图表，度量软件的代码质量等。
（2）对于程序界面
静态测试主要是查看软件的实际操作和运行界面是否符合需求中的相关说明。
（3）对于文档

1. 静态测试主要是检查用户手册与需求说明是否真正符合用户的实际要求。

2. 静态测试是采用走查、同行评审、会审等方法来查找错误或收集所需度量数据的。其不需要运行程序，所以相对动态测试，可以更早地进行。

3. 静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中的问题（也只能通过静态测试发现），通过文档中的问题或其他软件评审发现来找出需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范，包括代码风格、变量/对象/类的命名、注释行等。

4. 静态测试已被当做一种主要的自动化代码校验方法。

动态测试（Dynamic Testing）

又称动态分析（Dynamic Analysis），是指需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例（对应的输入、输出关系）来分析被测程序的运行情况或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的地方。

动态测试的局限性:
●往往需要借助测试用例来完成。即通过执行测试用例、分析测试用例来对被测软件重点考查，以期发现缺陷。相比静态测试，动态测试增加了测试用例的设计、执行和分析，以及由测试用例所带来的用例组织与管理等一系列活动。
●需要搭建软件特定的运行环境，增加了有关测试环境的配置、维护和管理的工作量。
●不能发现文档问题，必须等程序代码完成后进行，发现问题相对迟得多。

静态测试与动态测试比较:
（1）协同性
静态测试是保守和健壮的，其测试结果离我们的期望值可能还有距离，但它保证了将来的执行。
动态测试是有效和精确的，它不需要花费大量的分析过程，尽管它确实需要测试用例的设计、执行和结果分析。动态测试给出了高度精确的结果。
（2）独立性
静态测试需要建立程序的状态模型（如函数调用图、控制流图等），在此基础上确定程序对该状态的反映（如通过各种图表分析，找出多入口多出口的模块、高层控制模块等）。因系统可能执行的状态有很多，测试必须跟踪多个不同的状态，通常经过大量细致的分析后也不一定能考虑到所有的系统状态。因此，静态分析通常采用程序状态的抽象模型，并需要较长时间的等待。
动态测试过程中不存在近似和抽象的概念，它直接执行程序段，检查实时的行为，在控制流程路径中，几乎不存在不确定因素。

按是否需要查看代码分类

黑盒测试

又称功能性测试（Functional Testing）或数据驱动测试（Data-driven Testing）。但是，功能性测试不等于功能测试。黑盒测试是从功能的角度检查软件是否满足需求规格说明的要求，但并不仅限于功能测试。

只考虑系统的输入和输出，完全不考虑程序内部逻辑结构和处理过程。黑盒测试的依据是各阶段的需求规格说明（如需求分析阶段是产品的需求规格说明书，单元测试阶段是函数的详细设计说明）。

• 优点
  ●黑盒测试用例与程序如何实现无关。
  ●测试用例的设计与程序的开发可以并行进行。
  ●没有编程经验的人也可以设计黑盒测试用例（这也是造成当前测试人员的素质偏低的主要原因之一）。当然，一般情况下，具备一定的编程经验最好。

• 局限性
  ●不可能做到穷举测试。由于输入控件太大，包括输入条件太多、输入数据量太大、输入条件的组合太复杂等因素，导致黑盒测试不可能做到穷举测试。
  ●因不可能做到输入的穷举，只能从中选择部分输入构成测试用例，因此黑盒测试是很有可能存在漏洞的。(测试可能不全面)

白盒测试

又称结构性测试（Structural Testing）或逻辑驱动测试（Logic-driven Testing）。值得注意的是，白盒测试并非仅限于对程序源代码的测试。对于高层的测试，仍然可以采用某些白盒测试的方法。

白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构。白盒测试的依据是程序代码。

特殊的应用领域：
●程序代码往往具有多个分支。白盒测试可以利用不同的覆盖准则来测试这些分支，黑盒测试则无法做到这一点。
●白盒测试的覆盖指标可以充当黑盒测试的检查手段。例如，若采用黑盒方法设计的测试用例（如边界值测试）没有满足某些白盒测试覆盖指标（如判定覆盖）的要求，则证明该测试用例集合必然存在漏洞。
●代码中常存在内存泄露的问题，尤其是C/C++程序，白盒测试可以方便地发现内存泄露的问题，且是直接定位缺陷，而黑盒测试只能通过长时间运行程序，并仔细地检查用例执行结果，才能发现这类问题。
●有时只有在某种极端的条件下才会出现的情况，是难以直接进行功能测试的，如卫星在太空中收到电磁辐射。这时，缺陷预防是测试的主要目的，白盒测试通过对源代码的静态分析可以发现该类问题。

灰盒测试