标签：用例 wiki 高效 计划 标准化 框架 docx nbsp 细节
制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。
流程图
需求分析
需求分析由产品经理制定，要求细化每一个功能的细节，每一个按钮的位置以及边界范围，对于稍大或稍复杂需求要求建模。
（ 1 ）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据 ;
（ 2 ）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例 ;
（ 3 ）测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖 .
需求评审（需求澄清）
参与人员，包括：产品，开发和测试。
产品提出需求。
开发人员考虑功能实现的方案与可行性。
测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。
开发人员编写排期
开发人员需求根据需求功能点进行排期，然后将开发计划发送给参与项目的所有人员。
测试计划排期
测试人员根据开发计划，安排测试的具体测试时间，然后将测试计划发送给参与项目的所有人员。
注：排期小技巧，根据需求先去预估大概需要多少测试用例来覆盖，用例数目预估出来之后，根据自己编写的速度和执行测试的速度，时间这样就出来了。
编写测试用例
根据详细的需求文档，开始进行用例的编写。
编写测试用例的准则： 1 ，覆盖所有的需求； 2 ，每个需求分支必须至少包含正常和异常两种场景； 3 ，测试用例的版本号必须与需求的版本号保持一致；
例如以禅道为例如下：
整体用例完成之后，如下：
用例评审
用例评审前，先将用例发送给相关人员，以便他们事先了解用例将对哪些功能进行验证以及验证的细节。
在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。
提交基线
开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试进行基线。
自测用例输出不少于整个迭代测试用例的 30% ，自测用例主要由自测用例由开发人员执行
Showcase
开发人员自测完成后将实现的功能演示给测试人员。测试人员可以提出疑问由开发人员解答或者后续提单解决。
转测
转测试是开发把所有需求都开发完成，并所有需求都 showcase 完毕。（即：开发转版本给测试组前进行的系统测试，目的是来评断这个版本功能是否可测。如果预测试不通过，打回，开发组返工，如果通过，测试组开始第一轮系统测试。）迭代出口（转测之前是迭代出口，迭代出口前是迭代期）完成了，需要自己到测试环境进行验证。
转测时间根据版本制定。版本转测试以后，需要对本版本进行总结，版本制作人需要对合入版本期间的异常进行总结，对合入的事件做好记录，对版本延迟的原因要给出负责主题。
(1) 第一轮系统转测试，测试组会执行所有测试用例，发现缺陷提交问题单。第一轮测试结束后，测试组将所有的问题单跟踪提交给开发人员，由他们进行修改。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
(2) 在他们修复 bug 期间，测试组会对第一轮系统测试做一个测试评估，出一个测试报告。 还要根据实际情况，对测试组写的测试用例进行修改和增加，开发修改 bug 结束，提交一个新的版本给测试组。首先是回归缺陷，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷问题单，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。
转测试之前，需要规划执行哪些用例，用例的规划结合禅道如下：
测试通过
经过两到三轮或四轮的测试后，直到没发现新的问题。或暂时无法解决，或不紧急的问题，通过上级确认，可以通过。
编写测试报告与验收方案，测试报告和验收方案由测试人员编写，测试报告。
测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少 BUG 、遗留多少 BUG 、解决多少 BUG 、追后对这个模块总结一下）
BUG 的统计，根据时间轴来统计 BUG 的数量，例如： XXXX 年 X 月 X 日，发现 BUG 多少，关闭 BUG 多少，剩余 BUG 多少，高级的 BUG 有多少，中级的 BUG 有多少，低级和建议的 BUG 有多少，一直罗列到项目完结
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
测试评估
执行阶段结束了进入测试评估阶段，测试组会出一个总的测试报告对测试组测试的这个过程和版本的质量做一个详细的评估 ：
1) 需求需要评审那些？
2) 用例需要评审那些？
3) 计划应该评审那些？
4) 缺陷评审那些？
5) bug 评估？
测试总结文档报告输出
可以让具体的任务负责人对该本次测试中个人负责的模快进行评价，提出相关建议，给出总体的评估。
整体上的 bug 按照不同等级统计出来，用例数量、用例执行数量。
对项目中测试人力资源的统计。（单位：人 / 天）
项目中软硬件资源统计。
提出软件总体的评价。
测试报告
测试报告包括对软件功能的结论，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
说明该项目软件的开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等。
记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。
备注
测试团队职责：需求评审、测试计划、测试用例、测试用例评审、测试执行、缺陷报告、缺陷跟踪、测试报告
测试团队交付件：测试计划、测试用例、缺陷报告、测试报告
标签：用例 wiki 高效 计划 标准化 框架 docx nbsp 细节
原文地址：https://www.cnblogs.com/softtester/p/11586081.html
