一．测试计划
测试计划，描述了要进行的测试活动的范围、方法、资源和进度，确定出测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
通常测试计划的范围包括以下几点：
2.简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
3.如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
4.列出可能会影响测试设计、开发或实施的所有风险或意外事件。
5.列出可能会影响测试设计、开发或实施的所有约束。
6.规划测试进度，分配测试任务至个人
需要借助自动化进行测试时，计划好自动化参与的时间，如何部署自动化测试环境以及具体的执行步骤等。
二．测试设计
测试计划制定完成后，即开始进行测试设计，内容包括：
1.测试场景设计，针对不同的模块、不同功能、各业务流程和逻辑分支，分别进行测试场景设计。相同的功能在不同的模块，可以参考已有的测试场景进行设计。
2.测试用例设计。新模块测试用例按照测试用例模板进行编写；已有模块更新或优化需要更新原有case。
3.用例评审。
完在测试用例设计之后为了保证测试用例的覆盖率，需要对测试用例进行评审，评审可以是交叉review或开会讨论的形式，主要从以下几方面进行评审。
a)测试用例是否覆盖了所有需求；
b)测试用例内容是否正确，是否与需求目标一致；
c)测试用例内容是否完整，是否清楚包含输入和预期输出结果；
d)测试用例是否具有指导性，是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维；
e)找出哪些需求不可测：无法准备环境、可测试性达不到等等原因；
f)对具体需求的实现结果的确认（设计人员、开发人员、测试人员的认识是否一致，如果不一致，谁说了算）；
g)测试用例本身的描述是否清晰，是否存在二义性；
h)是否考虑到测试用例的执行效率。往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下。
充分利用已有资源，比如公共测试用例，简化测试工作，提高效率。
三．Bug提交和缺陷跟踪
1.确认该bug是否复现以及复现的步骤。
2.Bug库中是否已存在同一问题描述的bug。
3.确认该问题是否为真正的bug，比如不满足产品需求、影响产品使用等等。
4.思考该问题是否还在其他场景下复现。
提交bug时，各个参数根据bug规范进行填写，summary要简单明了，复现步骤要清晰直接，另外，必要时提供相关测试数据和文字说明，上传图片或附件，以便更加直观的说明问题。发现产品缺陷时，测试人员要对软件缺陷进行分类，以简明扼要的方式指出其影响，以及修改的优先次序~
四．回归测试的测试范围
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。通常有下列几种方法来确定回归测试范围：
1.测试全部用例。这种方法比较安全，但往往带来很大的工作量。
2.基于风险选择测试，先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试，测试过程从主要特征到次要特征。
3.基于操作剖面选择测试，可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
再测试修改的部分。测试者可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上，使回归测试尽可能覆盖受到影响的部分。
五．内部沟通
测试人员除了需要注重与产品人员和开发直接的沟通，团队各成员之间沟通也应高效及时，避免测试人员之间测试结果互相影响、重复测试、重复与开发沟通确认浪费开发时间等，从而提高测试工作的效率。因此，要求测试人员做到以下几点：
1.测试前期，沟通结果实时共享。
2.测试过程中，以更高的实时性进行沟通，特别是和产品和开发沟通结果会对其他测试人员工作产生影响的情况，有助于团队其他人员的工作，提高团队协作能力。
和产品和开发沟通的结果，及时以文档形式记录下来并进行内部沟通。
其实一份测试规范的内容很多，将目录结构列出后，只是一个指引，其中列出了几项需要关注的点，具体的规范，不一定都要依据如此，但是如果能对你有所启发，那就是晴天~一份好的规范，会让你省去很多不必要的麻烦，希望可以规范的实践起来，以此达到更高效的工作与配合。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
