注：这不是一般的标准流程。 请作为参考。
目标制定完整具体的测试途径和流程，为快速、高效、高质量的软件测试提供基本的流程框架。 最终目标是实现软件测试的规范化、标准化。
工艺说明流程图
需求分析
需求分析由SA制定，要求细化各功能的详细情况、各按钮的位置、边界范围，需要对稍大或稍复杂的需求进行建模。
)1)测试要求是制定测试计划的基本依据，只有确定的测试要求才能为测试计划提供客观依据；
)测试要求是设计测试用例的指导，只有确定测量什么、测量什么，才能有针对性地设计测试用例。
(3)测试需求计算测试覆盖范围的分母，没有测试需求就不能有效地进行测试覆盖。
需求评审（需求澄清）
SE、OM、PC、AD、TE、QA等参与者。
SE提出需求。
开发者(OM、PC、AD )考虑功能实现的计划和可行性。
TE主要对需求的理解提出疑问，以便能够根据需求编写用例。
QQ员工是最终验证软件质量的人，因此也需要了解需求。
开发人员编写排期
开发人员的需求将根据需求的功能点进行安排，并将开发计划发送给所有参与项目的人。
测试计划排期
测试人员根据开发计划设置测试的具体测试时间(包括SIT迁移测试)，并将测试计划发送给参与项目的所有人员。
编写测试用例
根据详细的需求文档，开始创建用例。
用例评审
在审阅用例之前，将案例发送给相关人员，以便他们可以事先了解用例验证和验证哪些功能的详细信息。
在用例审阅中，参与者必须对用例中与实际功能不匹配的用例或格式不规范的用例提出修改建议。
提交基线
开发人员在完成所有功能后，对自己的功能进行自检。 自检完成后提交测试并基线化。
Showcase
开发者完成自检后，向测试者演示所实现的功能。 测试人员可以提出疑问由开发商解答，也可以由后续提单解决。
转测
迁移到测试是开发和完成所有需求，然后showcase完成所有需求。 (即开发移交测试组之前进行的系统测试，目的是评价该版本的功能是否可测量。 如果测试失败，则回调，开发组重试；如果测试失败，则测试组开始第一次系统测试。 (迭代出口)测试前为迭代出口，迭代出口前为迭代期间)完成，需要前往测试环境自行验证。
测量时间是基于版本创建的。 版本转移到测试后，需要总结本版本。 版本创建者必须总结合并版本期间的异常，记录合并的事件，并为版本延迟的原因提供责任主题。
)1)在第一次系统测试中，测试小组执行所有测试用例，发现缺陷并提交问题单，每日报告测试进展。 第一次测试结束后，测试组将所有调查表跟踪提交给开发者，由他们修改。 然后进行基线后的第二次测试，第二次重点回归第一次发现的问题。
)2)在他们修复bug期间，测试组对第一次系统测试进行测试评估，并提交测试报告。 另外，根据实际情况，修改并添加测试组编写的测试用例，在开发修改错误结束后，向测试组提交新版本。 首先是回归缺陷。 然后，在用例中选择优先级高的用例进行测试。 发现问题后，继续提交缺陷问题单，直到缺陷率低于用户要求。 测试组将进行最后一个较大版本的测试，然后结束系统测试。 具体的测试回合由版本质量和项目复杂性决定。
测试通过
经过两到四轮测试，直到没有发现新问题。 一时解决不了或者不紧急的问题，可以上级确认和通过。
编制测试报告和验收方案(验收方案由QA验证。 测试人员重点关注功能是否正常运行，QA关注整个过程的质量和最终用户的质量)。
测试评估
执行阶段结束后进入测试评估阶段，测试组提供综合测试报告，详细评估测试组测试的此流程和版本的质量。
1 )需求需要审查它们吗？
2 )用例需要评论它们吗？
3 )计划应该审查它们吗？
4 )缺陷评审它们？
5 )错误评估？
测试总结文档报告输出
可以让具体的任务负责人评价这次测试中个人负责的模快，提出相关建议，给予整体评价。
整体错误按级别统计，用例数、用例执行数。
项目中测试人力资源的统计。 (单位：人/日)
项目硬件和软件资源统计。
提出软件整体评价。
测试报告
测试报告包括软件功能的结论、旨在满足此功能的软件功能以及一个或多个测试中经过验证的功能。
说明这个项目软件
开发是否达到预定目标，是否可以交付使用。总结测试工作的资源消耗数据：如工作人员的水平级别数量、机时消耗等。记录测试结果与发现及本项目测试工作所得到的各项输出的承载体，根据输入与计划、要求的对比来总结此次项目所获得的经验。
备注
测试团队职责：需求评审、测试计划、测试用例、测试用例评审、测试执行、缺陷报告、缺陷跟踪、测试报告
测试团队交付件：测试计划、测试用例、缺陷报告、测试报告