测试流程规范

测试流程主要分为五个阶段：

需求分析阶段：确定测试负责人和测试人员，还有参与需求评审，另外所有成员需理解需求、提炼测试范围和测试点，并且深入理解每个测试点的逻辑。 

测试计划阶段：编写测试方案、分解测试任务，最后制定详细的测试计划； 

测试准备阶段：编写测试用例、先小组内评审、后项目会议评审，测试环境、测试数据、测试工具等的准备。 

测试执行阶段：负责人对测试任务分工，按计划执行测试过程，提测后，先执行冒烟测试，然后进行系统测试，提交bug，跟踪bug，直到被测软件达到测试需求要求，测试结束； 

测试总结阶段：项目测试结束，负责人输出测试报告，对整个测试过程和版本质量做一个详细评估，确认是否可以上线。 

迭代启动

1.1.1 迭代情况 

    公司产品组下达产品开发需求，确定需求情况 

    需要明确迭代时间进度，并且标注里程碑，对迭代中的开发任务、测试任务对应所属负责人 

1.1.2测试职责 

    弄清楚需求背景，确定需求要素 

    深刻认知产品需求，弄清开发团队人员，以便后期沟通交流 

    分析测试工作量，在有效的时间内是否可以保证高质量发布 

    迭代启动后，确定测试资源（人员、工具、硬件）是否能否满足测试需求，如不满足，多长时间能到位，在会议上应多和产品经理做充分的交流 

测试需求分析（需求分析阶段）

   根据产品原型，对需求进行了解，以保障在测试业务的过程中不会有漏洞和瑕疵，细化测试点并确定测试方法。可以用MindManager列出个模块下的测试点，各模块或大的测试点需要写出对应的测试方法，或测试策略。 

   是否需要提前准备数据，或会遇到的测试难点，采取怎样的应对措施。另外确定哪些工作测试人员可以提前介入，规避后面测试的进度风险和质量风险 

   测试人员在进行需求分析后，一定要认真理解，一方面可以通过对原型的方式熟悉需求，同时也为后续测试的文档设计，测试的执行打好良好的基础。 

测试计划（测试计划阶段）

    根据产品原型、需求文档、开发计划制定测试计划，制定测试计划有利于测试范围、测试时间和测试资源的调用、充分利用 

    测试计划应明确迭代整体开发周期，确定测试任务的测试人员，在整个测试迭代启动后，除非特殊情况，一般规定的测试人员即为专职专用，保证测试的连贯性、高效性 

    测试计划中需要明确测试风险 并加以标注，如：人员的变动、测试人员对需求的熟悉程度，需求的频繁变动等等，不可控因素。 

    测试计划由测试经理编写，编写完成之后，必须组织相关人员（产品经理、技术经理）进行评审 

测试设计（测试准备阶段）

    测试设计阶段的主要任务是编写测试用例和用例评审。是测试人员展示自己所有能力，确保认真和高度重视，测试设计相当于承上启下的阶段，既是检验我们对整体迭代需求的熟悉程度，又是考验我们对整个测试的计划把握和测试方法应用的检验，所以，有必要投入100%的精力去对待。 

    测试用例设计是整个测试设计的重中之重，测试用例应该充分考虑需求的覆盖程度和用例的设计方法，采用多种设计方法、多种测试组合类型做到全覆盖迭代需求。 

    测试文档编写后，应该通知相关人员做评审，只有评审通过的测试文档才能作为测试执行的依据，评审文档应提前1~2天发送，给评审成员足够的时候阅读，并反馈提出的问题，在评审过程中，对问题做记录并更新测试文档 

补充：测试设计过程中，可能有需求的变动或功能的增删，作为测试人员应该及时和技术经理、产品经理同步信息，将变更或增加的地方更新到设计文档中，并按照新的设计文档来编写测试文档。 

测试执行（测试执行阶段）

    在测试的过程中，对测试出来的问题不太确定的情况下，作为测试人员 应进一步跟开发人员进行积极沟通和配合 

    测试人员在测试之前应该独立完成对测试环境的部署，部署可以根据文档来进行（环境部署文档） 

    测试过程中，对发现的bug应能复现，在提交bug时，在步骤中需要描述清楚，以便开发人员在解决问题的时候参考，对偶发的bug或者出现小概率的bug在提交的时候 附上图片等信息，便于开发人员更好的定位问题和解决问题 

    测试人员在测试完每一轮时，都应该对测试版本和环境做保存，在下一轮版本测试时在版本的配置文件，安装部署都应该是全新取到的，避免和禁止用上一个版本的测试环境仅替换和更新修改的包，这样从测试的意义来说，并不是一次全新意义的测试过程。 

    测试人员在测试过程中，应该积极、主动，在发现问题时，不但可以发现，还能深刻思考和学习问题出现的本质，学习开发人员解决问题的思路，想想，这个问题为啥会出现，到底问题由何引起的呢？这一些问题的思考，不但能协助开发人员快速解决问题提供帮助，同时对自己的技能提高有很大的帮助。 

测试记录（测试执行阶段）

    测试记录主要包括记录测试结果和测试过程，测试结果是指针对测试发现的bug能详细地记录在bug缺陷库中，并且对缺陷的描述能做到言语简单明了，包含必要复现信息 

    在测试过程中发现的bug复现概率很小，或者有的无法复现等信息都要有测试记录。另一个方面是在测试过程中可能发现测试用例有的地方写的不全或有的bug并不能通过测试用例来发现，需要进一步细化和完善测试用例，这也需要做记录，目的是在今后更好的把测试用例做到全覆盖 

    测试记录还应该记录在测试过程中，这些测试可能不作为版本发布的需要，比如测试人员的一些想法、测试过程中遇到的困惑、测试和开发之间对问题处理的想法、对迭代功能的体验想法等等，这些都可以作为一个自我心得体会记录下来，在测试完成后，作为一种共享，大家一起来分享和讨论，这样对自己是一种成长，推动组织在流程的建设中可以更好的完善。 

缺陷跟踪（测试执行阶段）

测试 

1.测试人员在提交bug后，应该对该bug全程跟踪，bug从提交到Closed整个生命周期的各个阶段,测试人员一定要实事求是、严谨细致的认真对待。 

2.测试人员在提交bug中，应该明确标明bug的严重级别程度、优先解决顺序、测试步骤、预期结果、实际结果、项目版本、bug出现的概率等重要属性，便于bug的解决优先级和迭代的总结统计。 

3.在验证bug时，发现bug已经解决，应该在bug中注明bug解决的当前版本，如果验证问题还存在，需要将bug状态重新置为reopen，并和解决bug的开发人员做主动积极沟通。 

4. 在测试中，可能会发现有些bug出现的概率很小，复现的机会也非常小，但又确实存在，对这类bug应该先记录整理下来，并告知项目负责人，申请做长时间观察测试时间，因为这类bug可以需要长时间的测试才能复现，一旦复现应该将测试数据、日志、抓图等信息都保存下来。 

开发 

1.bug的整个生命周期离不开开发人员的参于，当测试人员分配给属于自己的bug时，首先应该快速响应，并将bug状态置为Open，当发现分配的bug不属于自己来解决时，也不要有其它想法，直接将该问题Forward回去并注明原因即可，保持和测试人员口头沟通 

2.对bug 解决后，首先应该自己测试，保证测试没有问题后再提交到版本上，避免未经自测就直接提交，导致解决bug的时间周期延长。 

3.开发人员在解决bug的过程中，有可能出现按描述的步骤根本复现不了该bug，这种情况完全有可能，因为bug的出现不但是操作的问题，还涉及测试环境、输入数据、数据的累积等原因，所以，遇到不能复现的问题，应该和测试人员积极沟通，不要将bug直接就No bug 

测试结束（测试执行阶段）

    测试完成后，需要将测试的情况整理成报告，发送给参与项目的全部人员和相关领导，报告中应该重点体现测试的信息，比如测试轮数、发现的bug总数量、遗留bug的处理意见、性能指标等必要参考信息。 

    测试结束后，对测试文档也要做整理并归档提交到服务器做备份保存，比如在测试过程中发现测试用例的不完善，测试过程中需求的微调等都需要同步到测试文档中有体现。 

    测试结束是代表一个阶段的结束，应该给参与测试人员几天自由支配的时间，调节下状态，同时对项目做总结。 

迭代总结（测试总结阶段）

    一个迭代测试完成后，应该抽时间大家一起座下来做个测试总结，总结时间不能和迭代结束时间相差太久，因为刚测试完迭代大家一定有很多想法，时间一长，很可能就会遗忘，而且时间长了，大家可能又有新的测试任务，所以，测试总结应该尽快完成 

    总结过程中，可以适当邀请产品经理和技术经理，听听他们对我们测试的一些建议和看法，这样也有利于以后更好的配合工作，测试其实就是一种服务，测试应该怀着这样的心态去测试。 

    总结完成后，应该形成文档化并保存下来，作为测试体系改进和完善的重要内容，同时也可以为部门、公司的流程体系建设完善提供一些参考信息。