公众号关注：测试充电宝，一起交流
测试人员的烦恼，测试是处于研发流程末端，因此前期的各种问题都会影响到测试。如何打破这种困境，已经成为测试人员迫在眉睫的问题。
作为测试应该有责任去监督开发，产品等各个环节，以免对测试端造成影响。建立测试左移的思想，从需求阶段开始思考，如何对整个流程质量的保障。
所谓测试左移，就是控制上游质量，提前规避风险。如何做好测试左移，可以从下面几个方向切入：
需求阶段
需求的频繁变动，我想研发和测试都是非常苦恼的一件事情，而且维护成本也是非常大，如何提高需求的质量已经刻不容缓！
- 多提问题
在需求评审前，产品一般都会提前给出本次评审内容，这个阶段可以要求测试和开发提前对需求有个了解和思考，并且针对一些不确定或者存在问题的地方做好记录，待正式评审的时候跟产品经理一一确认，保证需求的质量和稳定。
- 合理的奖励制度
针对提出的需求问题的价值，可以进行分级，一旦被产品采纳，则可以给与对应人一定奖励，提高大家对此环节的积极性。共同来保障需求的质量。
- 设立需求反讲环节
可以安排测试或者研发来进行需求讲解，同样提升大家对需求的理解，当然这可能会导致里程碑的延后，可根据情况进行选择。
研发阶段
如果测试人员有能力，可以参与研发的设计评审和数据库评审，因为测试是对业务最熟悉的，如果存在业务上的设计缺陷，能提前规避。
用例阶段
- 列重点、画流程图
在需求拆解过程中，可以先把业务流程图画下来，然后用思维导图列出本次迭代的测试点。虽然会带来额外的工作量，但是我觉得短期可能工作量有，但是后期的收益也是可以预见的。
- 业务流程图有助于对需求和业务进行深入思考；
- 测试重点和业务流程图作为知识文档沉淀，有助于新入职员工快速融入团队，开展工作；
- 流程图和列重点更直观，后期评审用例也有提效作用；
- 组织内部互审
用例写完后，可以先组织测试人员内部互查，达到查缺补漏的效果。
- 用例评审
产研测三方评审，同样可以设计用例反讲，但是也是根据团队情况而定，评审过程中挑重点，非重要的可以一带而过，提高评审效率，会议越拖收益越低。
提测阶段
对于开发提测，我们可以设立提测准入条件。
- 选取本次迭代重要的测试用例给开发自测；
- 分发给开发的用例必须自测通过；
- 提测后，测试冒烟通过；
满足以上条件后，才能进入系统测试。
上线阶段
首先我们要设立上线的质量标准，比如：
- 不能带着严重bug上线；
- 测试用例必须全部通过；
- 一些轻微bug经过商议允许上线，必须在下一迭代作为高优先级进行处理；
- 做好上线方案；
结束语
以上都是我在工作中的一些总结，大家不必完全一直按照文章所列点去做，我们要根据项目实际情况做出调整，毕竟全部落实需要投入更大的资源，因此我们可以不断试错，找出收益最大化的一个平衡点。
希望本篇文章能给处于困境中的你带来一些参考价值。
标签：需求,用例,左移,测试人员,评审,困境,测试,提测 来源： https://www.cnblogs.com/easy-test/p/14187252.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。