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