大家好，又见面了，我是你们的朋友全栈君。
软件测试流程及规范
一、目标
制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。
二、测试流程说明
三、需求分析
需求分析由SA制定，要求细化每一个功能的细节，每一个按钮的位置以及边界范围，对于稍大或稍复杂需求要求建模。
（1）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据;
（2）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例;
（3）测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖.
四、需求评审（需求澄清）
参与人员，包括：SE、OM、PC、AD、TE以及QA。
SE提出需求。
开发人员（OM、PC、AD）考虑功能实现的方案与可行性。
TE主要是对需求的理解提出疑问，以便才能根据需求写用例。
QA人员是最终对软件质量进行验证的人，所以也需要了解需求
五、开发人员编写排期
开发人员需要根据需求功能点进行排期，然后将开发计划发送给参与项目的所有人员
六、测试计划排期
测试人员根据开发计划，安排测试的具体测试时间（包括SIT转测），然后将测试计划发送给参与项目的所有人员。
七、编写测试用例
根据详细的需求
文档，开始进行用例的编写。
文档，开始进行用例的编写。
八、用例评审
用例评审前，先将用例发送给相关人员，以便他们事先了解用例将对哪些功能进行验证以及验证的细节。
在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。
九、提交基线
开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试进行基线。
十、Showcase
开发人员自测完成后将实现的功能演示给测试人员。
测试人员可以提出疑问由开发人员解答或者后续提单解决。
十一、转测
转测试是开发把所有需求都开发完成，并所有需求都showcase完毕。
（即：开发转版本给测试组前进行的系统测试，目的是来评断这个版本功能是否可测。如果预测试不通过，打回，开发组返工，如果通过，测试组开始第一轮系统测试。）
迭代出口（转测之前是迭代出口，迭代出口前是迭代期）完成了，需要自己到测试环境进行验证。
转测时间根据版本制定。版本转测试以后，需要对本版本进行总结，版本制作人需要对合入版本期间的异常进行总结，对合入的事件做好记录，对版本延迟的原因要给出负责主题。
(1)第一轮系统转测试，测试组会执行所有测试用例，发现缺陷提交问题单，并每日汇报测试进展。第一轮测试结束后，测试组将所有的问题单跟踪提交给开发人员，由他们进行修改。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。
(2)在他们修复bug期间，测试组会对第一轮系统测试做一个测试评估，出一个测试报告。 还要根据实际情况，对测试组写的测试用例进行修改和增加，开发修改bug结束，提交一个新的版本给测试组。
首先是回归缺陷，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题继续提交缺陷问题单，直到缺陷率低于用户要求，测试组将进行最后一轮的大版本测试，结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。
十二、测试通过
经过两到三轮或四轮的测试后，直到没发现新的问题。或暂时无法解决，或不紧急的问题，通过上级确认，可以通过。
编写测试报告与验收方案（验收方案是交由QA进行验证的，测试人员重点关注的是功能是否可以正常运行，QA关注的是整个流程的质量以及最终用户的质量）。
十三、测试评估
执行阶段结束了进入测试评估阶段，测试组会出一个总的测试报告对测试组测试的这个过程和版本的质量做一个详细的评估
：
：
1) 需求需要评审那些？
2) 用例需要评审那些？
3) 计划应该评审那些？
4) 缺陷评审那些？
5) bug评估？
十四、测试总结文档报告输出
可以让具体的任务负责人对该本次测试中个人负责的模快进行评价，提出相关建议，给出总体的评估。
bug按照不同等级统计出来，用例数量、用例执行数量。
对项目中测试人力资源的统计。（单位：人/天）
项目中软硬件资源统计。
提出软件总体的评价。
十五、测试报告
测试报告包括对软件功能的结论，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
说明该项目软件的开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等。
记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。
十六、备注
| 测试团队职责： | 需求评审、测试计划、测试用例、测试用例评审、测试执行、缺陷报告、缺陷跟踪、测试报告 |
| 测试团队交付件： | 测试计划、测试用例、缺陷报告、测试报告 |
附加：敏捷测试流程
来源：http://www.testclass.net/software_test/
敏捷测试的一个核心是迭代
，在每个时间点上，所有项目人员都是有事可做的。
，在每个时间点上，所有项目人员都是有事可做的。
- 下面是我理解中的敏捷测试流程图：
第一阶段：
通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：
开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。
流程分析：
在这个流程中
弱化了文档，强调了各个人员的沟通
，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
弱化了文档，强调了各个人员的沟通
，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
但这种流程并非完美，
假如一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去
。
假如一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去
。
- 对测试问题的处理
上面的图更能清晰看出对问题的处理过程。
第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/136549.html原文链接：https://javaforall.net
