软件测试规范.docx

软件集成项目测试规范

XXXXX公司

软件集成项目测试规范

2023年6月

目录

TOC\o1-3\h\z\u目录 2

1.目的 3

2.测试流程说明 3

2.1需求分析 4

2.2需求评审 4

2.3编写开发计划 5

2.4编写测试计划 5

2.5编写测试用例 5

2.6研发自测 5

2.7版本转测 6

2.8公司质检测试 7

2.9试运行测试 7

目的

本文档主要制订完整且具体的软件测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。

测试流程说明

需求分析

需求文档由售前部门经过与客户进行多轮沟通交流后统一整理汇总后提供给交付部门，需求细节由项目研发负责人进行细化明确，要求细化到每一个功能的细节，每一个按钮的位置以及边界范围。

（1）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据；

（2）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例；

（3）测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖。

需求评审

需求评审环节参与人员包括但不限于需求负责人、项目经理、研发负责人、研发人员、UI工程师、测试负责人、测试工程师、运维工程师。

由需求负责人对需求进行整体业务与流程进行讲解，与会人员提出存在争议和疑惑的部分，需求负责人进行解答与说明。

对于有改动的部分，由需求负责人对需求文档进行调整完善，并将更新后的需求以邮件形式通知项目的所有人员。

编写开发计划

研发负责人需根据项目需求的功能点进行开发计划排期，然后将开发计划发送给参与项目的所有人员。

编写测试计划

测试负责人根据项目需求的功能点及开发计划，结合测试人力及测试资源编写测试计划，安排测试的具体时间，然后将测试计划发送给项目的所有人员。

编写测试用例

根据项目详细的需求规格说明书或其他格式的需求文档，由测试组开始进行系统的测试用例编写工作。

研发自测

在系统集成前，开发人员在完成单个功能后都需要对其进行自测，以确保最小单元功能正确、正常。

在集成阶段，同样需要对结成后的功能进行自测，以便提前将比较明显的问题规避掉，到转测时测试人员能将精力放在更重要的功能、业务流程、数据验证以及发掘隐藏Bug等方面。

版本转测

研发小组按照版本规划开发完成某个版本后提交版本转测。将版本转至测试组，并描述当前版本的基本情况、功能列表、覆盖的需求以及已修复的Bug清单。测试组对其功能进行一个预测试（冒烟测试），目的是来评断这个版本功能是否可测。如果预测试不通过，测试组将版本打回，开发组返工；如果通过，测试组开始第一轮版本测试。

（1）第一轮转测试，测试组会执行所有测试用例，发现缺陷提交问题单，并每日汇报测试进展。第一轮测试结束后，由研发人员进行Bug修复，并提交下一个版本。测试人员进行第二轮测试，第二轮会对第一轮中发现的问题进行重点回归。

（2）在研发人员修复Bug期间，测试组会对第一轮系统测试做一个测试评估，根据实际情况，对测试用例进行相应的修改和增加，待Bug修改结束，提交一个新的版本给测试组。首先回归缺陷，然后会在测试用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷问题单，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。

公司质检测试

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决或不紧急的问题，通过组内和部门评估确认后，可将系统整体交给公司进行质检测试，通过后软件测试工作结束，测试负责人编写测试报告。系统进入试运行阶段。

试运行测试

待系统初验完成进入试运行阶段后，由运维人员对系统功能进行每日巡检、使用跟踪、功能监测、用户问题收集等事项。