2013年，软件测试新思路
操作方法
- 01
以基于风险测试为指导，测试驱动开发为核心，加强测试基础建设，提升产品可测性可恢复性，提升软件测试工程师能力走专精路线，结合多样化的测试手段与持续集成开展全过程质量保障活动。
- 02
基于风险测试 概念不多说，简单讲分为高中低九个区块，所有研发任务会首先进行风险判别，属于高 危三区块的测试人员全程参与，属于中危三区块的测试人员提供测试设计支持不参与执行过程，属于低危三区块的开发人员自行完成。 从10年就开始说全民测试概念，直到12年实施土壤才逐渐形成，一专多能复合型人员是未来发展趋势，细节不多说，这里主要谈一个问题，工作量蒸发。
- 03
蒸发 以往常说能量守恒，总体工作量不会消失只会发生转移，从测试人身上转移到开发人或其他角色身上，很多开发人都会问按上面方式运作是否开发人工作量会增加？答案是在初期一定会，不过一旦进入良性循环就不会，因为它从根源上减少了以往运作方式中缺陷修复成本和沟通协作成本。大家都知道问题越晚修复风险越高成本越大，以往进入测试阶段缺陷修复所带来的成本有多高不多说。 举例，我们一般说股票买卖有人赚就有人亏，但实际上股票市值会蒸发，没人赚也没人亏但就是不见了。工作量也类似，从根本上减少，当然你也可以说它是扩散到不为人知的角落。注意，随意举例而已，请金融专家勿纠结。 那么如何从根源上减少成本？
- 04
测试驱动开发 是否所有团队都适合做TDD？答案是否定的，不过一开始就把事做对相信没人会反对。研发任务伊始构建测试框架（测试设计框架、测试代码框架），告诉开发人这样做才对，同时依据以往故障构建缺陷预防框架，告诉开发人这样做就错，一对一错互为补充。注意，开发人不要在任务后期引入单独测试阶段，要把传统的事后验证转变为事前预防。 TDD能有效降低缺陷修复成本，那么沟通协作成本如何降低？以往多个角色共同完成任务变为现在一个角色完成任务你说降低没？但这里有个衍生问题，是否需要引入检查机制？单由一人完成任务是否会有风险？交叉测试？结对编程？
- 05
快速测试 自动化测试和探索性测试。自动化测试不多说大家都明白什么意思，让机器去检查。探索性测试不等同于快速测试，但我们现在就把它当快速测试用，专业测试人使用ET能快速把产品过一遍，当然这对测试人员能力有较高要求，同时对传统测试知识沉淀方式上有较大冲击。顺带再次鄙视一下不懂业务的测试工程师，毫无存在价值，别跟我说你了解什么测试业务，你了解啥？
- 06
基建 测试自动化不是终点，往前一步是傻瓜化，再进一步是智能化。要让测试活动开展门槛越来越低，测试技术使用越来越简单，只有做到这一步全民测试才有基础，清洁阿姨才有参与测试活动的可能，多年来想做引导式的测试应用系统，看清楚绝非平台更不是框架，今年应该能腾出手来弄弄。 多样化的测试手段持续积累，什么好用我们用什么，技术无国界更无山头。持续集成常态化，绝不无谓追求脚本数量，覆盖率统计要合理，首先考虑分支覆盖率，辅以场景覆盖率。 从狭义上讲测试工作的核心价值永远是发现问题，如何发现更多更深入的问题，业务场景验证覆盖率设计的越高代表能力越强，换言之测试范围评估的越准越牛逼。 在测试设计尽善尽美的前提下我们再看需要何种测试技术支撑我们的测试思路，千万不要本末倒置，你说你有个多不得了的高精尖技术结果完全用不上高射炮打蚊子一个问题没发现，你不去死你还等什么？ 如何评估测试工具的ROI，如何评估狭义测试技术为业务产品带来的价值，这是个问题。 然后，尽量在taocode上开源哇哈哈哈哈哈。
- 07
可测性可恢复性 永远不要仅站在测试角度看问题，更不要整天绞尽脑汁想着如何单独凸显测试价值，把产品质量做好了就是测试人的价值。 产品可测性可恢复性的概念不多说，可测性的目标两个：第一能准确评估，第二能推动提升。可恢复性的目标三个：快速知晓、快速分析、快速解决。 如果到今天还有测试人对产品质量特性没概念，那实在不知说什么好了。
- 08
人员 专精化路线。去年初我们十来个人支撑两个业务，现在我们还是十几个人但要支撑六个业务，未来可能还会增加。早前提过业务测试架构师或业务测试专家的概念，希望人人都能成为“专家”。 开年以来我们有四位测试人员转岗开发，为今年角色融合打下了坚实基础，未来还会有更多，希望到财年末整个技术团队能真正成为人人都是开发，人人都是测试，人人都是前端。