测试流程与规范

1、测试流程与规范 V1.0测试流程与规范1 测试流程1.1 版本的控制版本的发布要有一定的规律，建议以时间为参考，定期发布版本： 版本的发布沿用目前传至服务器63，告知相应路径和文件，并记录所该问题； 测试人员拿到当日的版本后，部署到服务器上，注意要将之前的版本备份，确认BVT测试通过后可将备份定期清除； 所测问题jira中需注明测试日期和测试版本；1.2 测试环境的搭建和维护 测试环境尽量接近客户的实际使用环境； 测试环境最好由测试人员维护，保留环境配置说明文档； 测试人员应备份一个净化版本，当测试人员在测试过程中制造的测试数据已对测试工作造成重大阻碍的时候，恢复数据；1.3 BUG的管理1.

2、3.1 BUG管理流程 一个完整的BUG需要注明:测试版本，测试时间，重现步骤，必要的截图，问题属性，严重程度，紧急程度，问题涉及的主要模块等； BUG的当前处理人处理当前的问题，处理完成后标明处理版本，如有特殊处理在备注中标明。 同一问题不能在同处理人处耗时过久，否则很容易被遗漏。 定期生成bug报告发送相关人员。1.3.2 缺陷属性缺陷涉及属性如下：属性名称描述填写人严重等级体现缺陷的严重性和重要程度，开发人员据此确定优先修改的缺陷；（ABC）测试人员录入BUG时填写解决方式缺陷的处理方式，开发人员根据缺陷实际处理情况进行选择；开发人员根据缺陷实际处理情况进行选择；缺陷状态缺陷在整个跟踪修

3、复过程中所处的状态；根据缺陷流转自动设置；1.3.3 优先级缺陷类型说明Blocker错误性质非常严重，影响系统无法运行，或影响测试的工作进行； Critical系统崩溃，丢失数据或内存溢出等严重错误；Major主要功能、重点功能错误或无效；Minor非主要功能、重点功能错误或无效，包括对现有系统的改进；Trivial界面错误，拼写错误，文本未对齐等；1.3.4 解决方式 严重程度说明FixedBUG已经解决；Wont FixBUG不解决，或不会被解决；Duplicate重复BUG；IncompleteBUG描述不准确、完全；Cannot ReproduceBUG不能重现，或者无足够的信息重现

4、问题；1.3.5 缺陷状态缺陷状态说明OpenBUG提交，待处理；In ProgressBUG处理中，未完成；ResolvedBUG已解决，待验证； ReopenBUG验证未通过，待开发处理； ClosedBUG验证通过，系统中不存在BUG描述问题； 1.3.6 管理BUG的经验合理安排测试时间和Bug验证时间；及时验证Bug；对于已改的Bug，要求在下个更新版本验证完毕；只要发现该问题仍然存在则应立即将该问题打回给开发人员，并标注：“该问题在新版本中依然存在。”出现争议时，尽量站在用户的角度去思考、沟通问题，如果发现自己不明确问题时，及时寻求同事和上级的帮助，协调尽快促成问题的定位和解决；及

5、时与开发人员沟通所发现的重大、紧急Bug，并合理确定Bug的优先级。有效的报告Bug，尽可能详细的描述Bug，并尽可能找出Bug出现的规律，以便开发人员能及时对Bug定位。经常跟踪一些处理时间比较长的Bug。复查Bug，对于程序员不处理的Bug，测试人员要认真核查，如果核实确定要处理，与程序员沟通并及时修正Bug。2 测试规范2.1 需求确定阶段在做市场调研后，确定了一定的用户需求。PM确定立项。设计需求文档的阶段主要任务： 需求设计完成后，要通知相关人员参加需求的评审讲解过程； Dev、Test 对业务以及逻辑可以提出质疑，及时得到处理和反馈；2.2 设计阶段 在需求确定以后，Dev需要依据

6、需求文档以及从PM在需求评审时获得的对新功能的UI、使用逻辑等做出详细的设计文档。主要任务： 设计文档设计完成后，也要通知本次参与该项目的相关人员组织评审大会； 设计评审中各个人要根据自己掌握的业务知识以及开发经验对设计进行完善，尽量减少遗漏。 设计评审完成后，Dev根据自己的设计以及会议中的补充和更改给出开发时间；注意事项：需求、设计文档都评审完毕，在Dev进入新功能开发阶段，test依据现有资料，设计case，并进行case评审。Case评审完成后给出测试时间。测试人员在case评审 完成后，要摘出来主流程的case信息，命名为准入case提供给Dev。为Dev开发完成后完成自测提供依据。

7、所有资料准备齐全。测试根据对本次要测试的功能的了解，提前准备测试需要数据以及环境等所需内容。以便在功能进入测试阶段时不至于手忙脚乱。2.3 新功能的开发阶段。2.4 提测验证阶段1. 代码正确性的验证 验证release包中的信息是否完整，有没有多余的代码内容；验证不通过找相关Dev负责人处理。 将正确的代码发布到测试环境，正确的完成环境部署。2. 功能正确性的验证 验证本次需求中需要新增或变更你的功能是否全部完成； 验证准入case是否全部通过，如未通过，该版本驳回，不进入测试阶段。本次CC为失败。 验证通过，进入下一阶段：测试阶段PS：准入case验证是否通过，都需要给出回应，让相关人员知

8、晓。2.5 测试阶段 执行所有case； Case中无法实现的测试场景也要测试到。尽量将测试点覆盖全面。 将测试阶段发现的bug提交到jira上做记录。最好在提bug时标注清楚bug严重程度等相关信息。注意事项： 测试阶段，需要Dev积极的配合，及时修复发现的bug； 该版本确认测试完成可以发版时，jira上关于本次功能的所有bug原则上必须全部处于close状态； 如有本次不修复且可以发版的bug一定要在发版前得到相关负责人的认可。 在测试、开发时间都比较紧张的情况下需要汇总bug信息按严重程序来决定先修复哪些bug。关于测试遗漏bug的说明：1、 测试人员最终来说不是业务人员，没有真正的使

9、用本产品的经验，测试的依据只是相关文档资料。以及经验中了解的业务知识。所以遗漏bug在所难免；2、 线上是允许发现bug的。在运行环境和场景不同的情况的有bug是正常情况。3、 如果发版后，有明显的功能无法正常使用，此时测试人员就该自我检讨了！4、 产品以及Dev可以将测试认为是对产品一无所知，一定要保证给出的测试依据的正确性。2.6 发版1. 场景一：产品发版准备前置条件：产品根据设计已完成一定功能，或者规定时间内发布的版本。所发版本经测试无问题，或现存问题已由相关负责人确认暂不处理。版本中应包含：新版本部署文件，变更数据库脚本，发版说明。2. 场景二：客户定制产品发版准备根据与客户商定的修

10、改内容，发版时间完成发版。版本中应包含：新版本部署文件，变更数据库脚本，发版说明。3. 发版及线上验证 发版包准备就绪，通知相关人员进行发版； 客户定制产品发版需行现场验证，并给出验证结果的答复。 正常发布通过后，版本归档。 如未能正常发版，则撤销发版。注意事项：如果发版失败后，需要版本回滚，要及时做验证。3 附录3.1 测试时间的预估测试人员要根据自己设计的case以及一些无法用case体现出来的测试场景出发计算测试时间，对自己的工作时间的评估要负责、谨慎。选择权利的同时也赋予了自己责任。3.2 测试点的遗漏 测试case没有覆盖到的主流程以及功能的遗漏点； 测试人员业务知识不够丰富，导致的遗漏； Case覆盖到了，在测试执行时没有严格按照case执行测试的遗漏； 产品没有经过联调，环境没有跑通情况下发版，测试人员没有评估到风险的；PS：基于如上几点的测试点遗漏，测试人员需要负全责。 测试阶段case执行，且通过了，发版后又出现的bug； 发版后用户在使用过程中发现的不符合业务逻辑，以及业务