精准测试的个人理解

敏捷开发下测试的处境

从传统模式到敏捷开发，产品或项目的迭代增多，很有可能达到每两周就会有一个版本。虽然没有达到每天部署3~4个版本的devops开发模式，但这个时候测试的压力依然陡然增大，既没有那么多的时间写完善的用例，更做不到每个版本都进行完整的回归测试。以前的同事便是在敏捷开发环境下测试某电信运营商相关的金融类app。她经常会遇到即使上线，缺陷也不断的涌现。有些在测试时已经修复的问题，在生产环境又再次出现；或者之前修复的问题，下次测试又再次出现。测试到最后经常顾此失彼，疲于奔命。这时候，测试如果仅仅只是在部署后才参与到产品或项目中，就会越来越累。测试需要肩负起软件质量控制的重任。

测试遇到的问题

• 测试不参与产品或项目的需求评审，无法对产品或项目做测试计划
• 即使参与到需求评审，但是没有把控需求的可测试性
• 版本构建快，无法把控版本构建
• 测试不了解产品或项目内部流程，无法针对性的编写更有效、更精简的用例
• 测试人力不足，版本迭代快速，无法进行全面的回归测试

理论

测试左移、测试右移的概念可以参见项目实施DevOps时，我们是如何做测试的

Laurent提出一个测试左移和右移的概念:

测试左移，就是指在开发阶段之前定义测试。

测试右移，就是直接在生产环境中监控，并且实时获取用户反馈。

---

实现方法

需求到任务到用例的转化

用例的编写

敏捷开发，拥抱变化。需求的变化相较于传统模式越来越多，所以用例也需要跟着及时更新。为了提高编写用例的效率，使用一个好的用例管理平台比用Excel等工具要好。不管是给上级看到工作成果也好，还是方便其他测试接手也好，甚至评价分析测试用例覆盖率都是很有帮助的。

用例从概括到逐步细化

刚有需求但没有原型设计，或者需