目前，业务测试的同学普遍层级覆盖在P5、P6，是什么阻碍了业务测试的发展？在我看来，当业务测试的同学对如何在业务中进行测试这件事驾轻就熟的时候，就到了该考虑自身发展的时候。

　　所谓驾轻就熟，并不是作为业务测试的价值，这恰恰只能说明，你到了一个发展的起点，而非终点。驾轻就熟，从一定意义上来说，是在照搬别人的做法，达到了作为一名业务测试最基本的工作能力。如果用阿里的层级表示，那就是P5、P6的水平。

　　业务测试要做专，有两点必须把握：为产品质量负责的能力、为产品体验负责的能力。

　　对产品质量负责的能力：这是一项能够根据产品发展阶段、项目组成员能力结构来定制合适质量保证手段的能力。基本的测试流程、基本的测试方法可以照搬其他团队的经验，但如何确保测试工作真正有效，和产品所处的发展阶段、项目组成员的能力非常有关，一个刚起步的创业产品和一个已经处于稳定状态的维护产品，两者采取同样的项目流程、同样的测试方法，你能确保给予最好的质量保证结果吗？依据以往的经验，我的答复会是，有办法做到，但付出的代价很大。更重要的是，业务测试习惯性的照做思维，导致他们没有思考为什么要加班，为什么如此努力仍然要在上线时心惊胆战？

　　为产品体验负责的能力：这是一项作为业务测试最重要的能力。对业务精专，对产品的发展具有一定影响力，对产品的问题有自己独到的见解和解决能力，这是业务测试不同于其他转向测试的能力。为什么我们的业务测试总停滞在测试阶段？我们好像对产品很重要，但似乎又不那么重要？我们会对产品设计的体验问题提出自己的见解，但我们总不对体验问题负责。因为，看上去，体验与质量无关。但是否真的无关呢？如果你认可体验在产品生命中占用重要位置，那么作为业务测试，就应该对产品体验负责。

　　如果业务测试先改变自己，那么我们完全可以从三角的最低端资源密集型产业，变化为太极八卦图的特质八卦，即一套适合业务的测试架构，一套能提升产品质量和产品体验的测试体系。

　　三、业务测试与开发的黄金配比

　　在业务测试团队，我们常听到的测试效率，是用开发测试比来衡量。对这项简单的衡量标准，在产品发展的稳定阶段，非常适用，但不完全精确。举个简单的例子，当稳定团队的开发测试比达到10：1的时候，我们为这个测试团队的效率欢呼。但这10：1的背后，是真实的质量提升？还是测试工作的转移？当测试工作用开发自测来代替的时候，这10：1仅仅是人员机构的重组，而非业务测试效率的提升。当然，在良好的自测工具支持，完善的质量数据衡量前提下，开发自测效率更高，这是毋庸置疑的。只是，这个业绩的主角是开发，而非业务测试。

　　什么才是业务测试与开发的黄金配比呢？没有标准答案。我们对照产品生命周期来看测试：

　　以上针对产品生命周期和测试对比的分析，是我个人的观点，可能有不足，但从整体上，可以说明，一个产品在发展的不同阶段，测试的投入和重点是不同的，所对应的业务测试团队组成、测试工程师的技能需求也不相同，所以，每个业务团队要得到统一的测试开发黄金比，结果可能是牺牲团队效率，或者是个人成长空间。

　　综上所属，业务测试的精髓到底是什么？我的回答是，分析测试对象，用测试所具备的技能，寻找合适的质量保证方案，给予有效、实时的质量反馈。概念仍然没有变，业务测试要发展，最大的区别就是要做到经验的继承而不是复制，技术的精用而不是泛用，个性化的测试服务就是一个业务测试的发展之道。