自动化测试本质上是一个开发项目，而不是一项测试活动。

　　因为：

　　1、自动化测试工作包括了可行性分析、需求收集分析直到运行维护的全流程活动，而不仅仅是检查系统是否满足需求；

　　2、自动化测试是在构建一个系统，而不是测试一个系统；

　　3、自动化测试的需求来源于测试人员。因此测试人员对自动化测试而言相当于“领域专家”。而通常情况下，领域专家并不是开发系统的佳人选。

　　既然自动化测试是一个开发项目，那么这个项目由测试人员来做可以吗？

　　答案是“可以，担不是很好”。

　　不可否认，测试人员也可以管理开发项目，也能够有需求分析、系统设计、代码设计乃至定位及解决问题的能力，因此他们也能够承担开发项目。

　　然而从专业性角度来说，测试人员的主要特长并不在这些领域。或者说在现实的团队中，在这些领域有突出表现的测试人员比较少。而这些本来是开发人员（包括系统设计SE）需要具备的能力，是他们的专长领域。在开发人员中找到这些方面的“佳人选”，比在测试人员中寻找要容易，而且一般而言，专业素养要高一些。

　　接下来自然会产生另一个问题：既然你说开发人员更适合做自动化测试工作，那么为什么很多情况下仍然是测试人员在做这个事情？

　　换句话说，为什么“适合的人”没有做，而一些并不太适合的人却在做这项工作呢？

　　原因可能有很多，比如：测试经理自己认为这是测试团队的事，从而也应该由测试人员来做；开发经理认为这是测试团队的事，我不负责；项目经理认为这确实是整个项目团队的事，而且开发团队做更好，但是开发团队“太忙，没有精力”，所以只能测试团队来做；测试经理与开发经理都同意由开发团队来做，但是开发人员没有热情，能拖拖......

　　在寻找这些问题的解决方案之前，需要先看看产生这些问题的根因何在。

　　[病况1] 测试经理认为测试人员做自动化更好，这是因为他还将这件事看作“测试”而不是“开发”。这是其个人对自动化测试的了解不足，或者经验不足所致。

　　药房1：测试经理加强学习，提高对自动化测试工作的认识；在执行过程中及时总结经验教训，从实践中总结出更好的解决方案。

　　[病况2] 开发经理认为这是测试团队的事，则一方面与第一个问题一样属于认识问题，可以服用相同药房，另一方面却需要从组织上解决。因为如果从组织定义上将自动化测试划归测试团队负责，那么开发团队多只能是“帮忙”性质，而不会主动负责。

　　药方2：要么在组织工作界定上将自动化测试工作完全或部分划归开发团队负责，要么在组织结构上定义一个专职的“自动化测试”支撑团队，当然该团队成员仍然以开发人员为主。

　　[病况3] 开发团队“太忙，没有精力”，一方面是项目进度过紧，不科学；另一方面也可能是由于项目团队乃至整个公司对“进度”的敏感度远高于“质量”。因为项目进度稍有偏差，所有的人都会被惊动，而且会有问责机制；但是因为没搞自动化测试而导致质量上有所降低，很多项目团队是没有感觉的，哪怕因此发生了一些低级问题，通常也不会惊动什么“大人物”，而是静悄悄地解决了。

　　药方3：将自动化测试工作纳入项目计划，使其成为“正式的工作”，而不是“额外的负担”。同时提高质量敏感度，对不应发生的低级问题追究到底，建立“没有做好等于没做”的团队质量观念。

　　[病况4] 开发人员没有热情......你什么时候会对一件事毫无兴趣呢？第一是这件事看来对你没有任何好处，第二是这件事没有任何挑战，只是机械重复。

　　开发人员为什么会认为自动化测试对他没有任何好处？

　　因为：1、没人告诉他；2、投入很多，也没有提高他的绩效，还导致特性开发延迟被批评；3、这个技术掌握了也没什么用，应聘时从来没人问开发人员是否掌握自动化测试技术。

　　开发人员为什么会认为自动化测试没有挑战，只是机械重复？

　　因为：1、自动化测试框架太强大，真的把自动化测试工作变成了翻译——从测试用例逐字逐句翻译成逻辑脚本；

　　2、自动化测试规划太烂，没有分层要求也没有平台设计，基本上到处都是拷贝+粘贴+少量修改。