标准功能测试流程

1.  目的 

本文旨在制定完整且具体的测试流程和规范，为快速、高效和高质的软件测试工作提供基础流程框架，以提高软件测试组的整体工作效率，最终实现软件测试的规范化和标准化。 

 

2.  测试流程图 

 

 

1.  测试流程说明 

3.1.  测试准备阶段 

在项目立项后，项目经理会根据实际的情况，告知测试组长，需要相应的测试人员参与到项目中来。那么测试组长会根据项目的背景及部门人员技术情况及资源情况进行协调，指派测试人员。 

项目经理在获得明确的人员安排后，应将测试人员及组长填写到项目人员名单中，及各种虚拟的项目团队中（邮件组、Wiki空间组，Jira用户组等），以支持后续的沟通交流。 

3.2.  测试计划阶段 

3.2.1.  需求澄清 

测试组长将会安排小组成员阅读需求文档及其他项目文档，理解需求，理解业务。对不明确、含糊的，甚至有疑义的地方可以与项目经理、产品经理、开发部门多沟通交流。当出现大家都无法确定的问题时，项目经理或产品经理应该负责和客户沟通澄清，尽早地将问题解决。 

3.2.2.  需求评审 

产品组在需求全部确定后，申请召开需求评审会议，并应至少提前三天时间提交软件需求规格说明书给其他评审参与人员。产品组在需求评审时应说明之前发现的问题已被解决。测试组根据真实情况决定是否可以通过。如果有违背项，可以要求需求文档负责部门进行改正，直到达到标准为止。只有在需求通过评审之后，测试组才能开始测试需求提取工作。 

3.2.3.  测试计划 

测试组长根据软件需求规格说明书，项目总体计划制定测试计划，内容包括测试范围（来自需求文档），进度安排，测试所需资源（人力、设备等），整体测试策略的制定，风险评估与规避措施等。 

3.3.  测试设计阶段 

3.3.1.  测试需求提取 

测试工程师根据需求规格说明书等文档提取可测试的需求点，并记录在测试需求文档中。 

3.3.2.  测试用例编写 

测试组根据需求规格说明书，软件设计说明书（概要或详细设计文档）、页面原型等开始编写测试用例。测试用例一般需要指出（不少于）测试用例类型（功能、性能、安全性、兼容性等）、测试用例描述、用例优先级别、步骤、期望结果、数据等信息。 

测试用例必须覆盖到所有的需求，测试用例需经过测试组长审核通过。在项目进行过程中，如果需求发生了变更，也应对测试用例进行修改以反映最新的需求。 

3.4.  测试执行

3.4.1.  准备测试环境 

在测试之前，测试组长应和项目经理安排好测试环境，尽量能够和开发环境分开，且通过自动化持续集成/部署来更新测试环境。 

3.4.2.  执行冒烟测试 

开发组在完成编码后，应先通过单元测试或开发经理审查后，通知测试人员做冒烟测试后，才能进入正式的测试流程。 

此过程应考虑变成自动化持续集成/部署工作中的一个环节。 

3.4.3.  产品经理确认测试 

冒烟测试通过后，测试组应通知产品经理对提交测试的功能进行功能确认测试。产品经理确认完成后测试组才开始测试，否则必须进行修复直到产品经理确认完成为止。 

3.4.4.  执行测试 

产品经理完成确认测试之后，测试组按照测试用例进行测试，当测试用例全部执行后，应开展探索式测试，并不断完善测试用例。 

在测试最后一周时间，测试组应根据产品的质量情况，邀请项目组全体成员，甚至外部有关联或是有兴趣的同事对产品进行测试，以便可以发现更多的缺陷，并在交付给客户之前修复。 

3.4.5.  录入缺陷 

测试组在测试执行过程中将发现的问题录入到Jira中。 

3.4.5.  跟踪缺陷修复情况

测试组每天将发现的问题发送给研发团队，一周统计该产品/项目的缺陷情况，并要求开发组针对严重程度高的缺陷制定修复计划，开发经理和产品经理要确定要修复哪些问题。 

3.5.  报告总结 

当达到项目预定测试结束时间时，并且不存在严重程度高及以上的问题时，就可以结束测试执行了。 

执行结束后，测试人员需要按照产品或项目要求的测试报告格式（如没有模板，就采用内部模板）对测试工作进行测试总结，并且提交给项目经理，为产品后续的工作提供信息支持。 

3.6.  测试归档 

项目验收后项目经理应组织全体成员开展项目总结会议，测试组成员就情况进行总结陈述，会后将所有的测试文档整理、更新并分类归档入项目库存档。