去年的四月份，技术部提出要提升研发效能，而ICBU质量保证部提出了要提升测试效能，当时并没有明确提出提高研发测试比，而随后的测试工具平台的建设和效率度量，以及测试工作方式方法的改变都是围绕着提升测试效能来做。事后的结果，测试效率上去了并且可度量了，研发测试比也确实提升了，但这是做出来的结果而不是依据。

　　先抛开开发测试比的问题，我们不妨问一下自己，测试同学对业务的贡献是什么，可能很多人会毫不犹豫地说——质量，那么保证质量之后呢？无疑是效率。在我看来，质量保证是测试的本份，而测试同学对业务的进一步贡献就是大幅提升测试效率，其中包括提升自身测试效率和提升开发测试效率。所以从更宏观的层面上来看，如果没有别的可统计的指标来衡量测试效率，那么开发测试比这种一眼就能看到的指标就自然而然的成了衡量效率的方式。

　　那么是不是提高开发测试比就是把测试的工作完全不变的转移给开发做呢？如果是这样，正象这位同学说的，的确是意义不大的，固然让开发提升了测试能力和质量意识，让问题发现的更早，但也伴随着不小的学习成本。这种方式下效率的提升会大打折扣，随之而来，更为重要的是在工作的转移过程中根本无法体现测试人员的价值，最后开发团队同时具备了开发和测试能力，测试人员left nothing，而开发团队依然头疼于低效的测试工作。所以提高效率才是我们要入手去做的事情，开发测试比是我们在提高效率之后自然产生的结果，而不是提高开发测试比来证明效率，如果真有团队纯粹用提高开发测试比来证明效率，开发也不见得会接受。

　　再回到如何提升测试效率上，提升测试效率对QA而言责无旁贷。但我们应该如何提升测试效率，如果纯粹靠人，显然是不现实的，技术改变工作，只有让测试最大程度的自动化起来才能解决测试效率，而要实现高度的自动化测试，我们就需要一套非常高效而流畅的测试工具平台。只有测试工具平台的高效，让我们在搭建环境、编写维护各层的测试代码、测试执行、排查问题、提交缺陷等各个环节都大幅提效才能让测试效率有质的提升。只有测试工具平台的易用，让我们在上述各个环节都能降低开发的测试门槛，让开发有更强的意愿参与到测试平台以及测试各个环节的使用上来。如此测试可以在项目小需求的生命周期的前期来做，提前发现更多的问题，又可以让更多的开发和测试同学在测试的各个环节的测试工作大幅提效。

　　谈到测试工具平台，很多同学都知道业内的诸多的测试工具平台，问题在于目前普遍的测试工具平台只能满足开发测试比在2:1到4:1之间的开发测试团队的测试工作。因为这样的开发测试配比的团队使用一般的测试工具平台也够用了，这个阶段的测试工具平台更多的是注重质量而不是效率，也正是因为这个原因，业内大多数工具平台都没有自身的效率度量系统来衡量测试活动的每一个环节的效率如何以及如何进一步提效。但是当测试效率提高到支持开发测试比超过5:1、7:1，甚至10:1以后，所需要支撑的测试工具平台就和支撑3:1的测试工具平台截然不同。所有的工具平台都会向一个目标前进：效率。

　　谈到测试工具平台对测试和开发的效率提升上，不得不说一句目前的测试工具平台的共建，笔者目前参加了很多的测试工具平台的共建会议，但是会议上谈得大多是不要重复造轮子，要测试工具平台的统一，对于怎么样使工具平台进一步创新和提效，乃至建立工具平台的自身效率度量系统谈论的很少。如果我们希望用测试工具平台去提升开发测试效率从而达到高的开发测试配比的结果为宗旨，那么我们就必须对现有的工具平台以提升效率为宗旨突破原有模式，使在工具平台支撑下的测试效率提升数倍甚至10倍，才有可能实现这个目标。要做到这一点绝非易事，不仅需要专业测试平台建设人员全力以赴，还需要各个BU广大测试人员、开发人员针对自身业务需要的有效测试工具的积极参与。如此工具平台才能快速落地，发挥提效的作用。目前的测试工具平台的正在经历历史性的突破，技术上我们已经看到了支撑极高的测试效率的希望。

　　毕竟是做工具平台的，免不了多说了几句，回到测试效率上来，工具平台固然是提升测试效率的必要条件，但光有工具平台而没有一系列的配套措施是绝对不行的。管理层从上到下的认识，测试同学的测试模式的转变，测试经验的系统性沉淀和输出，开发同学和测试同学的自身努力等等都是绕不开的问题。希望有时间和其他BU、公司的QA多交流，各自都会有一些适合自身的解决方案，也会碰到一些别的BU、公司碰不到的问题需要解决，但我们相信只要大的方向是对的，问题都是能解决的。