决定自动化测试成功的关键是什么？是自动化测试的语言？是自动化测试的软件工具平台？是可支持高自动化测试率的工具？大家都有自己的认识和结论。但我今天提一种观点，欢迎大家讨论，思辨。
“决定自动化测试成功的关键是测试用例的质量。”
对自动化测试的认识，我也走过和大多数人一样的历程。从03年开始孤独地用Tcl编写自动化测试框架开始到07年为某公司做自动化测试咨询，我都一直认为自动化测试就是测试巅峰，对自动化测试认识都停留在如何在最短的时间内实现最高的自动化测试率和运行效率，一直认为决定自动化测试成功的就是自动化测试脚本的结构和运行自动化测试的平台。
但最近一年在主抓多个产品测试组测试质量的工作中，对测试活动的质量有了一些新的认识和反思。一切测试活动的质量最直接的影响因子就是测试用例和测试报告。无论是功能测试，性能测试，兼容性测试，可靠性测试，还是安全性测试。测试用例是输入，测试报告是输出，两者的质量决定了测试结果的质量。
我们可以很明白的就理解了：如果测试用例质量差，那么把它转化成自动化测试脚本，运行100遍也没有意义。就像我们本来要在沙漠中挖油田，可是却一直在钢板上打井，即使是自动化机器打井但也没有意义了。如果是我，宁可多花时间找油田，手工在油田上挖井，也不愿意让机器在一个打不出油的地方自动挖井。
自动化测试直接带来的效益是——提高了测试的效率，释放人出来思考更多更合理的测试用例，间接提高测试质量。如果国内目前只盲目追求自动化测试的开发，而忘了应该投入更多的时间和资源在直接提高测试质量的活动中，那就确实有些本末倒置了。
所以，我建议：“以退为进”。与其一开始就追求片面的自动化率，还不如先踏实把测试用例的质量抓好。特别是对于新产品在测试早期，还是多用心思考如何提高测试人员设计测试用例的质量，扩大测试用例的覆盖面，加强测试用例测试的强度。在准备写自动化测试脚本前，先反思是否我的测试用例质量和测试报告质量还有改进的空间，我的测试用例库是否有足够多系统的可靠性测试，性能测试，压力测试，安全性测试，兼容性测试，可用性测试等的testcase
