两个熟悉的场景：

　　·生产环境出现问题，解决问题，原因复盘、责任分配到人；

　　· 无休止的测试-回归-再测试-再回归测试，已经投入了很大精力，但仍对项目质量不信心；

　　如果自己所负责或参与的项目经常遇到上面的两种情况，不妨从项目测试流程角度，去思考原因以及破开瓶颈的方法。

　　测试流程拆解

　　需求评审

　　通过参与技术设计评审，可以为测试方案提供依据。例如：核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等，都可以在这个阶段进行思考和产出。

　　另外，可以有效的评估需求影响范围和风险点，避免遗漏。

　　此阶段是质量的基石，通过测试左移，尽早发现需求设计缺陷、技术方案风险、关联方依赖影响等方面，了解测试关注点，需求可测试性以及预留排期等问题。

　　举例：

　　接口测试：权益核销&&退款，接口都需要对前端传入的参数进行校验。

　　新老数据兼容，比如说小程序的发版，一般会滞后于接口发布，一定要测试旧版本的兼容性。

　　测试方案设计

　　测试用例设计：需要从整体入手，而不仅仅局限于待测功能本身的业务逻辑。好的测试用例，是质量保证的核心。

　　测试用例评审：避免三方需求不一致，减少测试执行阶段做无效工作，如执行无效用例、提交无效BUG等。

　　测试数据准备。

　　此阶段是质量的骨架，通过测试设计，覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备，为质量保驾护航，为测试赢得更多宝贵的时间。

　　测试用例这一步不能忽略，即使改动很小，排期很紧，也建议要画出思维导图；要想提高测试用例设计能力，就需要平时就要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地总结、归纳，才能逐渐形成体系化的用例设计思维。

　　同时，对于高质量的测试活动，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求。

　　好的测试用例是如何定义的？

　　不应该从是否能发现BUG的维度去定义，而是应该从集合的完备性角度去思考，也就是测试用例是否能够覆盖所有等价类以及各种边界值为维度去衡量。

　　如果把被测系统看作一个池塘，BUG是池塘中的鱼，设计测试用例集的过程就像是在编织一张捕渔网。好的用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。渔网眼就是测试用例的粒度，粒度越大，意味着网眼越大，这就只能捕捞大鱼，一些小鱼就会漏网。这也是一些项目通用的现状，测试活动由于受限于时间成本和经济成本，只能采用基于风险驱动的模式，选择合适的测试粒度，即有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

　　整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求；

　　等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，同子集下其他输入也一定测试通过；

　　等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。

　　线下测试（含灰度）

　　横向覆盖：对于一个场景，从开始到结束涉及到的关键节点，都要进行检查点覆盖，包括功能实现、数据读取、数据计算、数据写入等的正确性；

　　纵向覆盖：正常场景、异常场景、补偿场景都要覆盖；

　　探索性测试：凭个人经验进行探索性测试；

　　回归测试：拉取回归测试集，手动测试和自动化测试相结合，在测试环境验证新功能对原有功能是否产生影响；

　　此阶段是质量的成型，通过测试设计的充分准备、线下测试的严格、立体的执行，发现和解决绝大部分问题。

　　探索性测试

　　根据需求描述来设计最初的测试用例，然后执行测试；在执行过程中，如果得到的输出和预期输出不完全一致，于是会猜测这种不一致是否可能是软件的缺陷造成的；为了验证想法，你会根据错误输出，设计新的测试用例，然后采用不同的输入再次检查软输出。经过几轮这样的猜测和验证，进行反复“探索”，最终确定了一个软件的缺陷。

　　而识别缺陷的思路和测试用例的设计，并没有出现在最初的测试设计和测试用例文档中。探索性测试是一种测试风格，并且强调依据当前项目上下文选择最适合的测试技术。同样的测试风格，由不同的人来具体执行，得到的结果可能会差别巨大，一直强调测试分析能力是最重要的技能。

　　线上测试

　　回归测试：拉取线上回归测试集，并结合自动化测试，保证核心流程测试通过；

　　新功能测试：拉取新功能快速验证测试集，并确保覆盖新功能核心测试点；

　　此阶段是版本质量终态，线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。

　　测试复盘

　　在发布上线后，对测试过程进行复盘，总结遇到的问题，对当时的解决方案进行探讨。通过复盘，从而达到指导后续工作，减少重复踩坑。并在可以在个人复盘完成后，在部门内进行信息共享。每个人负责的项目虽然不同，但是测试思想确有共通之处。通过复盘分享，可以有效提升团队整体测试经验。

　　此阶段是测试经验累积阶段，也是容易被忽略的阶段。通过信息共享，大大降低重复踩坑的概率。

　　线上监控

　　通过选取业务流程中优先级高的测试用例，作为心跳测试用例定时运行，并持续进行补充完善。

　　接口测试用例的开发进度落后于新功能的发布节点。自动化不是跟着新需求走，而是测变化的东西对不变东西的影响。

　　此阶段是测试活动右移，质量补偿，快速响应和解决，降低生产事故造成的损失。

　　总结

　　通过规范测试流程，全覆盖产品生命周期，量化测试产出，在有限测试资源下的提升产出；

　　推动力是衡量测试角色能力的重要指标，特别是一些需求不明确的项目，在各个阶段都要保证信息在团队成员间的一致性。

　　目前的不足之处：

　　测试用例评审流程：邮件or会议， 需要产研给出积极响应；

　　测试各阶段的准入准出条件模糊：进入测试、进入开发，要有基本的要求，一环连着一环，在某些阶段确实可以加入一些提交基线，比如进入测试阶段，之前增加提测基线（类似冒烟）。

　　技术沉淀不足，异常场景模拟依赖开发人员。

作者：Rethink    

来源：http://www.51testing.com/html/35/n-5099535.html