流程分解

目的：本活动的意图

负责人：负责执行本活动的角色

参与人：配合执行本活动的角色

进入准则：能够开展本活动所须满足的因素或条件

输入：执行本活动需要使用的数据或文档

活动：将本活动的输入转化为输出的一系列行动

输出：本活动所产生的数据或文档

完成准则：标志本活动完成的因素或条件

1、设计用例

目的：确保为发现至今未发现的缺陷提供依据

负责人：用例设计师

参与人：主测人

进入准则：《详细设计》评审通过

输入：《需求规格说明书》《概要及详细设计》《业务逻辑流程图》《现场应用场景》

活动：

①依据输入文件运用设计方法设计用例；

②部门内对用例进行Review；

设计标准：

①可读性高

②覆盖全部需求点，考虑到各边界值、异常条件

输出：测试用例

完成准则：部门内Review通过

2、评审用例

目的：确保对需求规格场景覆盖率达到100%

负责人：用例设计师

参与人：主测人、开发代表、项目经理、应用工程师、测试经理

进入准则：部门内Review通过

输入：测试用例

活动：

①评审用例设计的结构是否清晰，是否有效对需求规格覆盖

②是否从用户角度来设计测试场景和使用流程的用例

③是否有效覆盖业务逻辑，对程序要求是否合理

输出：评审通过的用例

完成准则：对需求规格和业务逻辑流程的覆盖率达到100%

3、版本转测

目的：严把转测入口，控制版本转测质量

负责人：主测人

参与人：主测人、测试代表、测试配合人，项目经理

进入准则：部门内Review通过

输入：转测单据

活动：

①测试人员核对转测单据的版本号是否否和立项要求

②测试人员核对转测单据附件是否包含完整的《研发自测试报告》《转测说明》

③测试人员核对转测单据是否填写功能描述，缺陷修复情况

输出：转测单据

完成准则：转测单据审核通过，不通过打回，重新转测审核。

4、澄清范围

目的：确保覆盖修改点和风险点及影响范围

负责人：测试代表

责任人：主测人、开发代表、项目经理

进入准则：版本转测

输入：《需求规格说明书》《业务逻辑流程图》《修复缺陷清单及影响范围》

活动：

①基于需求规格及业务逻辑流程，分析新增需求及修复缺陷的影响范围；

② 依据可能影响的模块，划分版本测试范围，明确测试重点；

输出： 版本测试范围

完成准则：项目干系人对版本测试范围澄清一致

5、制定计划

目的：指导测试过程

责任人：测试代表

参与人：主测人、开发代表、项目经理

进入准则：测试范围澄清完毕

输入：项目里程碑计划

活动：

①明确范围

②规划时间

③设定策略

④关联用例

输出：测试计划

完成准则：项目组审核通过

6、评估版本

目的：确保版本具备可测试性

负责人：主测人

进入准则：版本转测

输入：转测版本、开发自测报告、转测说明文档

测试活动：

①核实输入文档是否完整和正确；

②抽检开发自测报告执行情况；

③对转测版本进行冒烟测试；

④冒烟测试包括自动化测试，手工重点功能测试

输出：转测版本是否具备可测试性

完成准则：冒烟测试通过

7、执行测试

目的：发现问题

负责人：主测人

参与人：其他测试人员

进入准则：转测版本具备可测试性

输入：转测版本、测试计划

活动：

①按计划执行测试提交缺陷；

②反馈版本测试进展和情况；

输出：缺陷列表、产品风险、测试情况

完成准则：用例执行率100%，且在测试最后一天主测全人力投入未发现严重及以上缺陷。

8、产品培训

目的：产品使用和推广

负责人：应用工程师

参与人：应用工程师，前端技术人员

进入准则：测试完成

输入：《硬件新品培训文档》、《操作软件类培训文档》、《硬件程序包培训文档》、《原理性培训文档》

活动：

①硬件新品技术参数，操作，功能培训；

②操作软件升级，操作，功能培训；

③硬件程序包升级使用说明；

④服务，软件实现原理说明。

输出：《培训总结》

完成准则：部门内Review通过

9、编写报告

目的：呈现测试过程

负责人：测试代表

参与人：主测人

进入准则：测试完成

输入：测试过程所有输入、输出文件和过程数据

活动：

①记录整个测试过程和结果；

②分析过程数据和产品质量；

③部门内对报告进行Review；

输出：《测试报告》

完成准则：部门内Review通过

10、发布评审

目的：评审是否达到发布状态

负责人：测试代表

参与人：项目组相关干系人

进入准则：《测试报告》部门内Review通过

输入：《测试报告》和《发布评审表》

活动：

①评审过程质量；

②评审遗留缺陷影响；

③评审产品风险项影响；

输出：《评审意见表》

完成准则：所有评审组成员签字确认可以结束测试

11、支持现场

目的：独立和协助解决现场问题

负责人：应用工程师

参与人：研发同事、前端同事

进入准则：前端反馈现场问题

输入：现场问题基本信息

活动：

①通过信息分析和独立解决问题；

②复现现场协助开发解决问题；

输出：《现场问题解决办法和规避措施》

完成准则：问题闭环

注意：流程是按照工作积累，非通用的测试标准流程，仅可参考即可。

---

测试相关流程图

测试开始前期需要知道的流程内容（参考）：

测试主要流程顺序图（参考）：

测试缺陷BUG流程图：（参考）

测试日报的主要内容（参考）：邮件的方式通知

测试相关流程说明

需求分析

需求分析由CR制定，要求细化每一个功能的细节，每一个按钮的位置以及边界范围，对于稍大或稍复杂需求要求建模。

（1）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据;
（2）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例;

需求评审参与

 1. 参与人员：SE、OM、PC、AD、TE以及QA。 
 2. SE提出需求。 
 3. 开发人员（OM、PC、AD）考虑功能实现的方案与可行性。
 4. TE主要是对需求的理解提出疑问，以便才能根据需求写用例。 
 5. QA人员是最终对软件质量进行验证的人，所以也需要了解需求。

开发人员编写排期

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

测试计划排期

测试人员根据开发计划，安排测试的具体测试时间（包括SIT转测），然后将测试计划以及测试中日报发送给参与项目的所有人员。

编写测试用例

根据详细的需求文档，开始进行用例的编写。

用例评审（有的不需要评审，但是需要用例发给相关人员）

 1. 用例评审前，先将用例发送给相关人员，以便他们事先了解用例将对哪些功能进行验证以及验证的细节。
 2. 在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。

介入测试前期

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试进行提测。
开发人员自测完成后将实现的功能演示给测试人员。测试人员可以提出疑问由开发人员解答或者后续提单解决。

提测冒烟

1. 提测是开发把所有需求都开发完成，并所有需求都showcase完毕。
   （即：开发转版本给测试组前进行的系统测试，目的是来评断这个版本功能是否可测。如果预测试不通过，打回，开发组返工，如果通过，测试组开始第一轮系统测试。）

2. 提测时间根据版本制定。版本提测以后，需要对本版本进行总结，版本制作人需要对合入版本期间的异常进行总结，对合入的事件做好记录，对版本延迟的原因要给出负责主题。

1)第一轮系统转测试，测试组会执行所有测试用例，发现缺陷提交问题单，并每日汇报测试进展。
2）第一轮测试结束后，测试组将所有的问题单跟踪提交给开发人员，由他们进行修改。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
3) 在他们修复bug期间，测试组会对第一轮系统测试做一个测试评估，出一个测试报告。 还要根据实际情况，对测试组写的测试用例进行修改和增加，
4）开发修改bug结束，提交一个新的版本给测试组。
    首先是回归缺陷，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷问题单，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。

测试通过

 1. 经过三四轮的测试后，直到没发现新的问题。或暂时无法解决，或不紧急的问题，通过上级确认，可以通过。
 2. 编写测试报告与验收方案（验收方案是交由QA进行验证的，测试人员重点关注的是功能是否可以正常运行，QA关注的是整个流程的质量以及最终用户的质量）。

测试评估

执行阶段结束了进入测试评估阶段，测试组会出一个总的测试报告对测试组测试的这个过程和版本的质量做一个详细的评估 ：

1) 需求需要评审那些？
2) 用例需要评审那些？
3) 计划应该评审那些？
4) 缺陷评审那些？
5) bug评估？

测试总结文档报告输出

可以让具体的任务负责人对该本次测试中个人负责的模快进行评价，提出相关建议，给出总体的评估。
整体上的bug按照不同等级统计出来，用例数量、用例执行数量。
对项目中测试人力资源的统计。（单位：人/天）
项目中软硬件资源统计。
提出软件总体的评价。

测试报告

测试报告包括对软件功能的结论，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
说明该项目软件的开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等。
记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。

版本上线相关文档交付关闭

测试报告、测试复盘、测试禅道需求相关的内容关闭，做好下个迭代版本的测试计划以及安排好测试内容

---

备注：以上是按照工作积累经验以及参考大佬，编写整理，仅供参考

0.研发中的测试

软件测试和软件开发一样，都遵循软件工程的原理；测试和开发是密切相关的；测试活动是贯穿于软件项目开发的全过程的，和开发活动交互开展。

软件需求完成后，需要进行需求的评审，此时测试人员可以参与需求的评审，当需求确定后，测试人员可以开始进行系统测试方案以及计划的制订。

软件项目总体设计方案完成后，测试人员可以开始进行集成测试方案以及计划的制订。

详细设计完成后，测试方可以开始进行模块测试方案以及计划的制订。

单元测试和编码一般是同步的，由开发人员自己完成的。

整个模块开发完成后，测试人员开始进行模块测试，当然在这之前，所有的模块测试用例已经准备完毕。

模块测试后是集成测试和系统测试。

软件运行维护期间则要对运行期间发现的问题进行回归测试。

1.测试模型

这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。常见的软件测试模型有：V模型、W模型、H模型、X模型(不成熟)。

（0）V模型

发展自软件开发的瀑布模型，说明了基本的开发过程和测试行为；明确地标识了测试过程中存在的不同级别以及测试阶段和开发过程各阶段的关系；但其有局限性，包括测试对象只有程序代码以及测试作为编码后的活动，没有体现”尽早测试”的原则。

（1）W模型

 

其从V模型演化而来，在V模型中增加与软件各开发阶段同步进行的测试。其强调测试伴随着整个软件开发周期，测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。其局限性包括W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代以及变更调整。

（2）H模型

测试活动独立，贯穿于整个产品周期，与研发流程并发。循环：测试点准备就绪就可以开始执行测试。测试可以尽早进行，可以对被测对象分层次、反复测试。

模型要能指导实际工作，H模型本身并无太多的可执行的指导意义。

2.测试流程

测试过程定义了企业在产品开发过程中在设计、开发与实现、维护、退出等阶段与测试相关活动的内容、流程以及规范。

测试过程指导项目如何开展各项测试活动，以及各项活动的输入与输出；约定活动中所涉及的角色与职责，规范各个活动的内容和规程，以及所使用到的统一的模板、表单、指导书和检查单。

定义测试过程的目的是给本公司在产品开发过程中测试相关的活动提供指导，确保产品可以真正满足用户的要求。

软件项目中测试和开发是相互配合同步推进的，为软件项目的复杂性被测对象往往不断发生变化，实际项目中测试与开发的关系更加复杂，虽然复杂，测试工作的开展是有自己的过程要遵循的。

虽然在一个项目的研发过程中，有很多种不同的测试类型，不同的测试阶段，但是对单次测试来说，存在一个一般性的过程。

 1.需求分析阶段：收集相关资料，学习业务(测试对象)，分析测试需求点。

 2.测试计划阶段：测试主管组织编写《测试计划》，该文档指明测试范围、方法、资源以及相应测试活动人员时间进度安排。测试计划需要进行评审，测试计划一旦开始执行，就要定期监控计划的执行情况。

3.测试设计及开发：测试设计一般由对需求熟悉的资深的测试工程师设计，为每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。测试开发主要完成对测试用例编写、测试数据准备、测试环境准备。测试设计和测试用例完成后需要进行评审。

4.测试执行及报告：执行测试用例，及时提交有质量的Bug和测试阶段报告反馈测试情况。

5.软件评估报告及批准：根据测试结果给出对软件的整体评估，以及是否通过测试的建议。一般决策部门会根据这份评估报告决定产品是否可以发布。

6.测试总结及资产归档：结项阶段对整个过程进行回顾总结，将项目相关资源进行整理归档。

创建软件测试流程注意事项：从实际情况出发，优化流程，解决问题；重点考虑四个问题：哪些测试要做、谁做、什么时间做、如何做

对当前存在的问题进行收集、诊断分析；根据实际情况建立新的流程；流程发布和试运行；促进流程的执行，收集问题；流程更新和发布。

测试执行是按照测试计划去执行测试活动；测试过程执行是严格按照测试的过程去开展测试活动。需要注意的是，测试过程创建后并不是一成不变的，要根据实际实践情况不断改进和完善，进行修订后要及时进行过程发布。一般在测试过程执行中要设置一定的机制，去保证测试人员有按照测试过程开展测试活动，一般有两种方法：QA人员对项目的监督和指导与组织级审计。

测试流程在每一轮执行完毕之后，根据执行情况对流程进行更新和完善。用好的实践去更新完善流程。

3.涉及资产

测试过程中涉及的文档等资产包括：测试计划文档、测试方案文档、测试用例、测试报告、测试缺陷库以及其他包括：

新开发或引入的测试工具、测试工作会议记录测试计划、测试方案、测试用例的评审报告、测试总结、测试原始数据以及度量数据、测试日志：每天测试日程记录、周期性测试报告、任务报告：任务完成情况报告。

描述为完成软件特性的测试而采用的测试方法的细节。其主要内容：概述、被测对象、应测试的特性、不被测试的特性、测试模型、测试需求、测试设计。

测试用例表描述测试用例：测试项目、用例编号、用例级别：测试用例重要程度、用例可用性、输入值、预期输出、实测结果、特殊环境需求[可选]、特殊测试步骤[可选]。

描述测试结果的文档，其主要内容：概述、测试时间、地点、人员、测试环境、测试结果统计分析、测试评估、测试总结与改进、测试缺陷列表。

描述测试缺陷，其主要内容：缺陷简述、缺陷描述、缺陷级别、缺陷分析与对策。

4.企业案例