测试框架结构体系

1.0 项目启动

1.1.1 项目情况

    公司产品部下达项目开发任务，确定项目情况（输出项目计划书）

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

1.1.2测试职责

    弄清楚项目背景，确定项目要素

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

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

    项目启动后，确定测试资源是否能否满足测试需求，如不满足，多长时间能到位，在会议上应多和项目负责人做充分的交流

2.0 测试计划

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

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

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

3.0 产品需求分析

   根据产品原型，对项目的需求进行了解，以保障在测试业务的过程中不会有漏洞和瑕疵，以基础知识为内力，以测试方法和测试理论为核心，以业务知识为动力，从而出色的完成项目整体的测试过程

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

4.0 测试设计

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

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

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

补充：测试设计过程中，可能有需求的变动或功能的增删，作为测试人员应该及时和开发人员（产品）将变更或增加的地方更新到设计文档中，并按新的设计文档来编写测试文档。

5.0 测试执行

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

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

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

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

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

6.0 测试记录

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

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

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

7.0缺陷跟踪

测试

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

8.0测试结束

    测试结束后，首先需要将最后测试的版本发送到FTP服务器上，同时告诉项目经理，将版本控制工具上的版本流做lock操作，将版本流冻结，禁止操作人员随意提交代码到项目上。

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

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

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

9.0 项目总结

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

    总结过程中，可以适当邀请项目负责人和开发人员代表，听听他们对我们测试的一些建议和看法，这样也有利于以后更好的配合工作，测试其实就是一种服务，测试应该怀着这样的心态去测试。

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