针对以上所述病况4，这些不同的根因，需要开出不同的药方：

　　药方1：告诉开发人员他能够从自动化测试获得的好处，好是他的直接主管告诉他，并提供参考资料给他学习。

　　药方2：参考药方3，同时将自动化测试作为绩效考察点，对自动化测试做得出色而且开发的特性质量高的人员予以嘉奖。

　　药方3：.......在面试开发人员时多问点关于测试的问题，对具备（自动化）测试能力的开发人员更重用。

　　药方4：既然自动化测试工作只是翻译，那么理论上可以由机器完成——翻译过程也自动化，引入MBT很可能可以解决此问题。

　　药方5：......所以说自动化测试是一个真正的开发项目，不能够没有架构、没有设计。缺什么补什么吧。前端工作没有做好，一个必然的结果是后期的自动化维护工作量剧增。

　　以上是将自动化测试落实到开发人员负责时可能遇到的问题（实际上大多数问题笔者都碰到过），以及从个人角度给出的一些解决建议。

　　三、自动化测试的价值在于发现缺陷？

　　这个问题与“人力解放”的神话一样，常常被不太了解测试的人提起。

　　笔者在公司内听到过从不同产品、不同项目的开发经理口中说出类似的话。他们认为，通过自动化测试运行，发现了若干的缺陷，这证明自动化测试发挥了作用，起到了“防护网”的作用。

　　开始笔者还尝试向他们解释这样的想法存在不足，不过经过一段时间以后，笔者不再解释了。因为他们这样的理解尽管不太对，却有助于他们重视自动化测试。对产品和项目有利的事情，也未必一定要争论个你对我错出来，对吧？

　　言归正传，自动化测试的价值是否在于发现缺陷？

　　我的回答是：是的。

　　当然，后面还有个“但是”：但是，不全是。

　　完整的回答是：自动化测试的价值不仅仅在于发现缺陷。

　　确实，自动化测试的运行确实可以发现这些用例应该发现的问题——需求不满足，运行出错，程序卡死、崩溃等。

　　但是，要说“自动化测试的价值在于发现缺陷”，其实言下之意是“发现不了缺陷的自动化测试是没有价值的”。

　　此言一出，天下大乱。

　　自动化测试发现不了缺陷，有可能是测试设计得不好，不能发现原本应该揭示的缺陷；也有可能是开发质量做得不错，确实在自动化所覆盖的部分表现所致。

　　因此，仅仅凭是否发现了缺陷这一条来评价自动化测试的价值，显然失之偏颇。

　　那么除了发现缺陷这一条外，自动化测试还有些什么价值呢？

　　首先从开发的角度来看，由“发现缺陷”其实很容易引伸出，自动化测试的真正价值应当是“预防缺陷”。

　　尽管我们常常将自动化测试比作项目的“防护网”，但它却并不完全像现实中的安全防护网那样工作。在工地上，当你不小心踏空坠下时，防护网能够兜住你，避免可能的伤害。但是在项目中，当开发人员犯了错误，自动化测试“防护网”却不会帮你自动纠正错误，避免由此带来的返工。

　　由这个完全不同的比喻，可以看出，根据自动化测试发现了多少缺陷来衡量自动化测试的价值，与使用“建设坠楼伤亡的次数”衡量安全防护网的价值并不相同。如果将自动化测试看做项目的“故障报警灯”，那么我们的期望应该是它亮起的次数越少越好。

　　自动化测试的作用可能更加类似于“故障报警灯”，当仪器设备发生故障时，会有显眼的报警灯亮起，有时还伴有刺耳的警示音。当项目中有人犯错，被自动化测试检查出来，它也会亮起刺眼的红灯，提示整个项目组、负责的开发人员去定位并修复错误。

　　开发人员都是一群自尊心很强的家伙。没有多少人愿意看到自己负责的代码“警钟长鸣”。当自动化测试在他面前亮起过一次后，他一定想法设法避免第二次“亮灯”。对个人而言，这是在自动化测试帮助下，逐渐养成重视质量的习惯、追求“一次做对”的过程。

　　除了可以帮助开发人员个体养成良好工作习惯外，自动化测试还能够帮助项目组和产品组建立起流程规范。

　　自动化测试用例像部署在项目组前进道路上的雷区一样，每次踩中地雷都会带来惨烈的后果。项目组安全前进的方法是找到一条不触雷而尽量快速的通道。

　　这个通道的建立当然不能是靠人把所有地雷都趟一遍，那样的“牺牲”实在是没什么意义。

　　这里我们建立起自动化测试的第二个比喻：雷区。

　　我们需要给整个项目组一份“雷区图”，告诉所有的人，什么样的做法会导致“踩雷”，做好哪些事情才能避开“地雷”保证安全。

　　这份“雷区图”是项目组的流程规范，它可以让项目走得更快、更安全。当然，除了“雷区图”，你还可以装备上“探雷器”——必要的辅助工具，有它的帮助，你的前进速度会更快。

　　以上两条对开发人员和项目组整体的好处，到底怎么衡量呢？建议可以通过“低级错误”的比例，以及缺陷密度的趋势来进行考察。