研发测试的6层次

　　大概 6 年前曾和同事分享过测试的几个层次，今天的理解又有些许不同。试图用“三字经”体，描述如下。

　　层次 1 － 无测试

　　没有专职的测试人员。如果你在小企业，在初创企业，或者足够老，你就会经历过。

　　层次 2 － 有测试，无用例

　　领导实在觉得产品质量对实施和使用有了影响，又或者不知道怎么做，或者没有太多的银子可以投入，又或者觉得既需要测试又觉测试也解决不了大问题，于是就找壹两个做事认真做事的毕业生，听话切成本不高，当然也别指望毕业生听过测试用例等术语了

　　层次 3 － 有用例，无设计

　　这个层次在生长在本土企业，也生长在外企，它存在典型土壤就是瀑布式开发＋开发和测试团队分离管理。设计本是瀑布式开发的轴心，和开发团队与测 试团队的纽带。但由于（开发人员们）众所周知的原因，实在没时间花在设计文档上，赶进度时也实在没心情更新设计文档，更何况相对年轻的开发人员难有全面而 深入的设计，老板又认为这个技术又有什么难，即没必要请高大上人士加盟，又没必要做高端外包，永远经济的奢侈品才是老板的最爱。

　　层次 4 － 有设计，无敏捷

　　这个是目前业界最长见的情景剧。在互联网时代，不对应该已经是云时代了，瀑布式的开发远远赶不上需求的变化和尽快发布的渴望，于是在瀑布式的开 发过程中，被分成了多个阶段，每个阶段完成几个新特性。设计文档于是也分阶段唯特性而生。万幸中的不幸是，云时代的天总是阴晴不定，变化莫测。好好的设计 像女人的脸总是变来变去（是因为彩妆？是因为整容？）。

　　开发人员勉强支撑者，产品的质量已经无暇考虑，但凡能够写出或修改完代码就已经是阿弥陀佛。苦不堪言的测试人员在人员有限和越来越多有变化莫测的特性中焦头烂额，最后不得不制定一套在覆盖率和质量间平衡的测试理念，并说服老板们认同。

　　老板毕竟是老板，抛出自动化的概念，把球有传回了后卫们，后卫于是头硕大，他知道的是只有中后卫可以耍自动化这样的花活，他不知道的是中场是为 进球服务的，谁会给后卫提供便利呢？！于是测试团队在进球是死罪，不完成自动化是活罪，开发人员又忙于特性和变化，开发支撑测试是无稽之谈的状态下，辗转 腾挪，颇有些马戏团的猴戏的架势。

　　层次 5 － 有敏捷，无设计

　　终于敏捷开发替代了瀑布式开发，敏捷已经如 Transformer（电影变形金刚），深入人心。sprint 的周期已经从一个月降到了 2 周甚至 1 周。测试自动化也突飞猛进，达到了五成，八层，甚至 90%。研发和测试的沟通也亲密无间。在研发，测试，老板，产品经理看来，一切都很美。

　　然而在繁花簇锦氛围中，设计文档已悄悄的隐退了。一旦产品研发从A地迁移到B地，部分裁员，多产品架构重组，诸如此类，开发人员心里又恨又气， 把前任的亲戚和祖宗八代都在心中默数千百遍。测试人员看着海量的自动化代码，却显有一例和测试用例相符，于是沧海一声笑，跳进了大海。

　　怪谁呢？敏捷的提出者从未在理论中涉及设计文档（搜索并参见 Agile Scrum），读懂了敏捷的 Scrum Master 也未曾从老板哪里领到设计文档，测试用例的 KPI，快速＋变化＋自动化覆盖率＝敏捷目标。

　　怪谁呢？从没有哪本 Agile 的专著说“不”需要设计文档。佛法云：尽在其中。和尚说：不尽其然。是和尚读歪了经文，还是经文交错了和尚。看你的了。

　　层次 6 － 无测试

　　即 4 和 5 这对矛盾之后，6 与 1 也是一对。这就是对比和递归的组合。

　　随着迭代的速度越来越快，传统的手工测试已经在 5 和 6 中彻底沦为了外包工作，留下的精英也主要在跨产品（特别是和第三方）的 solution 高端测试上。传统的自动化开发人员，但凡除写代码外，对产品特性无体会，代码堆砌不精炼，或者测试用例设计无思路的，都不得不跳槽去了4，5 的企业。

　　在这里，开发人员和测试人员再次融合为一个角色。简练的设计，灵活的架构，多层次抽象，接口即是产品的一部分又是自动化测试的一部分，不断的原 型，不断的重构，核心设计文档快速的修订并辅以音视频，自动化代码不过是产品中与设计文档，产品源码，产品执行代码并列的有一个目录而已。每一次发布后都 会整理设计文档，对架构反思，对逻辑层次做再一次的优化，并把这些变化回归到设计文档本事。

　　抱歉的是我没有经历过层次 6 的产品开发，仅仅是从我 2 个人的小项目经历的推论。显然这样的研发各个是铁人 5 项选手，至少是 3 项的高手。精英团队的单人成本确实很大（如我：），沟通成本降低了超多，总人数大量的减少总体成本依然可以降低，而质量显著提高。其风险是某个人的长时间 病休或离职，会对产品有一定影响，可以使用一些弥补机制或预防机制。

　　亲，你的项目，产品，公司在哪层呢？

　　MK@我的阁楼  July 6，2014