软件测试流程

软件测试流程如下：

1. 测试计划
2. 测试设计
3. 测试执行
   • 单元测试
   • 集成测试
   • 确认测试
   • 系统测试
   • 验收测试
   • 回归测试
4. 验证活动

测试计划

测试计划由测试负责人来编写，用于确定各个测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需的额时间和资源，进行活动的安排和资源分配。 测试依据主要是项目开发计划和测试需求分析结果而制定。

 

测试设计

根据测试计划设计测试方案，测试设计过程输出的是各测试阶段使用的测试用例，为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。

根据软件测试计划、软件需求、软件构架设计、软件详细设计等文档内容，设计测试用例具体如下：

1. 对每一个测试需求，确定其需要的测试用例。
2. 对每一个测试用例，确定其输入及预期结果。
3. 确定测试用例的测试环境配置、需要的驱动程序。
4. 编写测试用例文档
5. 对测试用例进行同行评审（peer review）

测试执行

 

如图所示，测试执行过程分为以下测试阶段：单元测试、集成测试、确认测试、系统测试、验收测试等。

单元测试

单元测试是在软件开发过程中进行的最低级别的测试活动，其测试的对象是软件设计的最小单位，单元测试又称为模块测试

很多人将单元的概念误解为一个具体函数或一个类的方法，这种理解并不准确。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。从某种意义上单元的概念已经扩展为组件（component）。

单元测试的环境：

由于每个模块在整个软件中并不是孤立的，在对 每个模块进行单元测试时，需要考虑它和周围模块的 相互联系。为模拟这一联系，在进行单元测试时，必 须设置若干个辅助测试模块。这些辅助模块分为两种：

• 驱动模块（driver）: 用以模拟被测模块上级模块，相当于被测模块的主程序。
• 桩模块（stub）: 用以模拟被测模块的下级模块，相当于被测模块调用的子模块。

单元测试完成方式

单元测试可以由两种方式完成：

 

单元测试的不足：

• 模块相互调用时引入了新的问题；
• 几个子功能组合起来不能实现主功能；
• 误差不断积累达到不可接受的程度；
• 全局数据结构出现错误等。

集成测试

确定测试

集成测试完成以后，分散开发的模块被联接起来，构成一个完整的程序。其中各模块之间接口存在的种种问题都已消除。于是进入了确认测试阶段。

确认测试，是对照软件需求规格说明书，对软件产品进行评估以确定其是否满足需求规格的过程。 它决定最后的软件产品是否正确无误。

确定测试的策略：

• 基于需求的测试：采用黑盒测试策略，在不知道详细设计规格说明或代码的情况下对用户需求进行测试。基于需求的测试根据功能设计规格说明设计测试用例。
• 基于功能的测试：采用黑盒策略，根据功能设计规格说明，采用等价类划分、边界值分析和故障猜测等方法设计测试用例。
• 基于内部的测试：只能采用白盒测试策略，但可采用功能设计规格说明制订测试计划。一但采用白盒测试，便可通过一系列的技术确保系统的内部各部分获得充分的测试并且达到足够的逻辑覆盖。

系统测试

系统测试实际上是针对系统中各个组成部进行的综合性检验，很接近我们的日常测试实践。 系统测试的目标不是要找出软件故障，而是要证明系统的性能。

注意：系统开发人员和组织不能负责系统测试，系统测试最好由独立的测试机构完成。

验收测试

验收测试是将最终产品与最终用户的当前需求进行比较的过程，是软件开发结束后，软件产品向用户交付之前进行的最后一次质量检验活动，回答开发的软件产品是否符合预期的各项要求，用户是否接受等问题。

验收测试不只检验软件某方面的质量，还要进行全面的质量检验并决定软件是否合格。因此验收测试是一项严格的正规的测试活动，并且应该在生产环境中而不是开发环境中进行。

回归测试

回归测试则是对程序进行测试以确定是否因故障修复而引入了新的故障。 回归测试不是一种新的测试活动，它是为检查是否因修复故障引入了新的故障而重新执行某些或所有测试用例的过程。

验证活动

验证活动存在测试生存周期中的每一个阶段，包括需求验证、功能设计验证、详细设计验证和代码验证。在每个验证活动中，测试的目的都是为了发现尽可能多的故障，测试人员应积极参与软件审查和走查工作，并开展验证工作。