一、熟悉的场景
生产环境出现问题-定位问题-解决问题-原因复盘-问题定级-划分责任人（每次都希望不会是自己的问题）
无休止的测试-回归-再测试-再回归测试-已经投入了很大精力，但仍对项目质量不信心（每次都在祈祷上线顺利）
我相信很多人都会遇到上面两种情况吧，如果自己所负责或参与的项目经常遇到上面的两种情况，不妨从项目测试流程角度，去思考原因以及破开瓶颈的方法，从根本上去解决问题，或者减伤出现问题的频率。
二、测试流程拆解分析
1、需求评审
需求评审流程：
需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义
人人都是产品经理，需求评审对于测试来说就是项目最初的“产品测试”，在理解的基础上发现产品设计缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的bug，减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环，甚至可以说是没有这个环节，追其原因无非因为项目时间紧迫或者觉得没有必要，其实这是本末倒置和得不偿失的。
产品需求作为程序的源头，只有控制好最开始部分，才不会到最后去亡羊补牢。我有过很多血的教训，所以才深深的体会到需求评审的重要性。举个栗子
记得有一次由于项目时间比较紧迫，没有对需求进行评审，当开始测试的时候发现需求的优惠券计算逻辑有一个重大的错误，经过和产品经理讨论后发现是需求设计有缺陷，需要重新设计一套优惠券计算逻辑。于是改完需求后反馈到开发这里的时候，开发原来的代码不能处理这种逻辑，只能把代码逻辑重新写一遍，最后又花了好几天重构代码，项目就延迟了一周上线。
后来回头想想如果当时在需求评审的时候把这个问题抛出来，开发就不需要编写错误的代码，测试也不需要再多测试一遍，项目也不会延迟那么久才能上线。类似的教训还有很多，都是由于不重视需求评审造成的，虽然大多数问题还是可以通过后期的测试来弥补的，但这样反正折腾真的是累人累己，如果可以有好的方法来优化，为什么不用呢？
说了需求评审的重要性，接着就来谈谈如何进行需求评审，总的来说分3步走：
第一步就是要完全读懂产品需求，这个过程只需要理解而不是去挑刺，因为要明白这个需求的目的是什么，为什么这样做，怎么做等等，只有在理解的基础上才能去发现问题，而不是一知半解的去挑毛病，有些需求设计的是不合理，但也许有其特殊的用意，或者只是没有更好的方案，不能为了挑毛病而去挑刺。
第二步就是分析和找问题，这就有点类似写测试用例的时候设计测试方案了，把逻辑梳理出来，看看有没有不对或者遗漏的点，整理出来反馈给产品经理。除了考虑有问题的地方，没问题的地方也是需要分析的，比如有些设计非常合理，但会增加代码的复杂度或者不利于后续的扩展和修改，同时也可能会给测试带来成倍的工作量，这些也是需要指出的，因为测试要考虑的东西一定要比产品经理多，用户使用习惯，程序复杂度，与线上系统的兼容性等等，不然直接让产品经理做测试不就好了吗？
第三步就是细节问题的纠正，可以是界面，可以是文字，开发一般都是复制黏贴或者照着样子画葫芦，这些小问题后期其实也可以测试出来的，但其锅不在于开发，早点发现问题早点解决也是好事一件，至少不用提bug走一套bug处理流程了，也算给大家省点工作量，积少成多也是极好的。
当然需求评审能解决的问题也是有限的，一方面计划往往赶不上变化，中间会有部分需求的改动，另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的，大家一定要积极的参与进去，而不是像听故事一样啥问题都没有，如果能重视起来不仅仅对项目的效率提高不少，而且也能让后期测试压力减小，何乐而不为呢？
2、技术设计评审
通过参与技术设计评审，可以为测试方案提供依据。**例如：核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等，都可以在这个阶段进行思考和产出。另外，可以有效的评估需求影响范围和风险点，避免遗漏。
此阶段是质量的基石，通过测试左移，尽早发现需求设计缺陷、技术方案风险、关联方依赖影响等方面，了解测试关注点，需求可测试性以及预留排期等问题。
例如：
接口测试：会员权益核销&&优惠券核销&&退款，接口都需要对前端传入的参数进行校验
新老数据兼容，比如说小程序的发版，一般会滞后于接口发布，一定要测试旧版本的兼容性
3、测试方案设计
测试用例设计
需要从整体入手，而不仅仅局限于待测功能本身的业务逻辑。 好的测试用例，是质量保证的核心
测试用例评审
避免三方需求不一致，减少测试执行阶段做无效工作，如执行无效用例、提交无效BUG等
测试数据准备
此阶段是质量的骨架，通过测试设计，覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备，为质量保驾护航，为测试赢得更多宝贵的时间。
测试用例这一步不能忽略，即使改动很小，排期很紧，也建议要画出思维导图；要想提高测试用例设计能力，就需要平时就要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地总结、归纳，才能逐渐形成体系化的用例设计思维。
同时，对于高质量的测试活动，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求。
那好的测试用例是如何定义的呢？我在这里说说个人的见解：
不应该从是否能发现BUG的维度去定义，而是应该从集合的完备性角度去思考，也就是测试用例是否能够覆盖所有等价类以及各种边界值为维度去衡量。
如果把被测系统看作一个池塘，BUG是池塘中的鱼，设计测试用例集的过程就像是在编织一张捕渔网。好的用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。渔网眼就是测试用例的粒度，粒度越大，意味着网眼越大，这就只能捕捞大鱼，一些小鱼就会漏网。这也是一些项目通用的现状，测试活动由于受限于时间成本和经济成本，只能采用基于风险驱动的模式，选择合适的测试粒度，即有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
我个人从下面3个维度出发：
整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求
等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，同子集下其他输入也一定测试通过
等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖
4、线下测试（含灰度）
横向覆盖：
对于一个场景，从开始到结束涉及到的关键节点，都要进行检查点覆盖，包括功能实现、数据读取、数据计算、数据写入等的正确性
纵向覆盖：
正常场景、异常场景、补偿场景都要覆盖
探索性测试：
凭个人经验进行探索性测试
回归测试：拉取回归测试集，手动测试和自动化测试相结合，在测试环境验证新功能对原有功能是否产生影响；
此阶段是质量的成型，通过测试设计的充分准备、线下测试的严格、立体的执行，发现和解决绝大部分问题。
在这里我把探索性测试单独拉出来讲一讲：
根据需求描述来设计最初的测试用例，然后执行测试；在执行过程中，如果得到的输出和预期输出不完全一致，于是会猜测这种不一致是否可能是软件的缺陷造成的；为了验证想法，你会根据错误输出，设计新的测试用例，然后采用不同的输入再次检查软输出。经过几轮这样的猜测和验证，进行反复“探索”，最终确定了一个软件的缺陷。
但是识别缺陷的思路和测试用例的设计，并没有出现在最初的测试设计和测试用例文档中。探索性测试是一种测试风格，并且强调依据当前项目上下文选择最适合的测试技术。同样的测试风格，由不同的人来具体执行，得到的结果可能会差别巨大，一直强调测试分析能力是最重要的技能。
5、线上测试
回归测试：
拉取线上回归测试集，并结合自动化测试，保证核心流程测试通过
新功能测试：
拉取新功能快速验证测试集，并确保覆盖新功能核心测试点
此阶段是版本质量终态，线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。
6、测试复盘
在发布上线后，对测试过程进行复盘，总结遇到的问题，对当时的解决方案进行探讨。通过复盘，从而达到指导后续工作，减少重复踩坑。并在可以在个人复盘完成后，在部门内进行信息共享。每个人负责的项目虽然不同，但是测试思想确有共通之处。通过复盘分享，可以有效提升团队整体测试经验。
此阶段是测试经验累积阶段，也是容易被忽略的阶段。通过信息共享，大大降低重复踩坑的概率。
7、线上监控
通过选取业务流程中优先级高的测试用例，作为心跳测试用例定时运行，并持续进行补充完善。
接口测试用例的开发进度落后于新功能的发布节点。自动化不是跟着新需求走，而是测变化的东西对不变东西的影响。
此阶段是测试活动右移，质量补偿，快速响应和解决，降低生产事故造成的损失。
三、总结
通过规范测试流程，全覆盖产品生命周期，量化测试产出，在有限测试资源下的提升产出
推动力是衡量测试角色能力的重要指标，特别是一些需求不明确的项目，在各个阶段都要保证信息在团队成员间的一致性
目前的不足之处：
测试用例评审流程：邮件or会议， 需要产研给出积极响应；
测试各阶段的准入准出条件模糊：进入开发、进入测试，要有基本的要求，一环连着一环，在某些阶段确实可以加入一些提交基线，比如进入测试阶段之前增加提测基线（类似冒烟）
技术沉淀不足，异常场景模拟依赖开发人员
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
