软件测试过程|软件工程

软件测试并不是在产品开发过程结束后才开始进行的，前面谈过的单元测试就是在产品编码阶段需要进行的工作，一般情况下对于测试有以下原则：

·应及早进行测试并把测试贯穿于整个软件生命周期；

·软件测试应追溯需求；

·测试应由第三方承担（不一定指第三方机构）；

·穷举测试是不可能的；

·必须确定预期输出结果；

·必须彻底检查每个测试结果；

·充分注意测试中的群集现象。

一个简单的产品测试流程可以归结为四步：

第一步：制订测试计划。

需求分析阶段就需要根据产品规格说明书编制出测试计划。测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容。通过测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保证测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

制订测试计划的原则是：

·明确测试的目标，增强测试计划的实用性

测试计划中的测试范围必须高度覆盖功能需求；测试方法必须切实可行；测试工具具有较高的实用性，便于使用；生成的测试结果直观准确。

·坚持“5W2H”规则，明确内容与过程

“5W”规则指：What（测试的范围和内容），Why（测试目的），When（测试开始和结束日期），Where（测试文档和软件存放位置），Who（谁来做），How（测试的方法和工具），How much（测试所需的资源耗费），这个原则同样适合于软件项目管理。

测试计划的模板可以参考GB/T 8567—2006软件测试计划。

第二步：设计测试方案、测试用例。

在系统设计和编码阶段需要给出测试方案和测试用例，其中：

测试方案是根据测试计划制订的，是在对系统模块的功能进行分析后，设计测试点（正常、异常情况，要求达到对模块功能的全覆盖），指导测试用例的设计。在制订测试方案时，要求对模块功能实现逻辑进行全面的掌握，包括功能限定，异常情况处理、后台数据处理，涉及的数据表/字段等，同时需要与开发人员进行沟通，让开发人员对实现逻辑等进行全面说明，并做好记录。测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。测试方案是技术层面的文档，从技术的角度对一次测试活动进行规划。

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例的选取原则和方法可以参考上一节的相关内容，在进行测试用例设计时还需要注意以下问题：

·一种情况一个用例，用例设计尽可能细化；

·用例名称要求能简单明了地描述该用例的测试点；

·用例级别要明确，一般主功能正常用例的级别为1级，复杂及异常情况用例可为2、3级；

·预置条件要清楚，对该用例执行所需要满足的条件描述清楚，特别是异常情况用例时；(www.xing528.com)

·测试步骤尽量详细，要做到让用例设计者以外的人能根据测试步骤顺利执行用例；

·预期结果要明确，对于页面跳转，数据入库等结果要细化，异常操作要有相应提示等。

测试方案与测试用例在设计完成后需要进行相关的评审，只有评审通过后才能够开展下一步工作。

第三步：实施测试。

具体测试的实施是从单元测试开始的，开发人员每完成一个功能单元都应该按照测试方案要求，使用测试用例进行测试，单元测试的具体测试人员可以是开发人员也可以是专门的测试人员，一般情况下单元测试都是由开发人员完成的，但测试人员需要跟踪测试的结果。单元测试之后的集成测试、系统测试则基本上是由专门测试人员完成的。验收测试则是由专门测试人员与用户共同完成的。

在具体测试实施过程中，往往会遇到很多问题阻塞测试进度，或者问题迟迟得不到解决。此时要求测试人员能发现问题，尽量通过日志进行定位，如无法定位问题所在，应及时找相关开发人员进行问题定位及解决。

通过测试所发现的问题可以划分为以下级别：

·致命：系统的主要功能完全丧失，数据受到破坏，系统崩溃、死机等；

·严重：系统的主要功能部分丧失，数据不能保存，所提供的功能或服务受到明显影响；

·一般：系统次要功能没有完全实现，但不影响用户使用；

·建议：不影响功能，提示信息，易用性方面等。

不同级别的问题可以采用不同的处理策略，比如对于建议级的错误，如果产品开发进度很紧，那么可以采用暂时搁置的策略。搁置的问题并不代表不处理，而是暂缓处理，测试人员需要进行记录。

此外，对测试中发现并已经解决的问题需要进行回归测试，这样做是因为不断修改问题，会导致产品出现多个版本，如果最后签入的版本不是最后修改正确的版本，那么将会导致最终的系统出错，此时发现错误，定位的难度将成倍增加。

第四步：测试总结。

当全部测试完成后，需要提交测试总结报告。在之前每个阶段测试当中一般是提交测试报告，有些时候可以简化一些，采用问题清单的方式。问题清单需要明确故障的现象，采用的是哪个测试用例、出现故障的前置操作是哪些等。而测试总结报告要比问题清单复杂，需要对测试的全过程进行总结，包括测试进度、测试用例、测试环境、测试工具、测试方法、测试结论等。

以上是传统开发模型的软件测试过程，那么在敏捷开发中又是如何进行的？敏捷开发提倡以测试驱动开发，需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代，一个迭代可以看成是一个小的完整的版本周期，每个迭代包含多个故事，一个故事相当于一个功能点，一个小的需求，而一个大的、完整的发布版本一般由几个迭代版本组成。在敏捷开发中的测试是从故事开始的，因此没有测试计划。下面是敏捷测试的测试过程：

·召开故事澄清会议，参与人员包括开发人员、测试人员、用户等。通过会议让所有参与项目的人员更深入地了解需求。会议与测试相关的文档是：故事验收标准。

·测试人员根据会议时了解的需求点编写测试方案，输出用例。完成后需要对用例进行评审，测试人员再根据意见修改用例，直到大家认可后再导入用例管理工具。

·在故事测试之前，测试人员需要开发人员进行一部分基本功能的用例验证，用例通过后才可以转测试。

·故事测试，测试人员执行用例—提交bug—回归问题—故事评价—关闭故事。

·迭代结束召开回归会议，开发与测试人员一起进行此次迭代版本的优缺点分析等。

·问题单逆向分析，分析每个问题单产生的原因，是用例设计遗漏、老版本遗留的问题，还是修改引入的问题？

·撰写测试质量报告，从发现问题多少、严重性以及聚焦的功能点等考虑给出等级评价，并合理地给出建议。