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