【思考】：一个项目完全交由一个人来做自动化测试，可行吗？

      昨夜凌晨两点多，辗转反侧，夜不能寐。

      回想起在目前这家公司的三年，经历了大大小小几个项目，过后总结发现，其实或多或少，都存在一些人为因素及管理上的问题。而这些问题，是不在其位的我所改变不了的。（况且，我只是一个最强工具人角色，没有任何管理的实权，也没有较强的话语权）

      后面，思绪跳跃，联想到当时做的自动化测试，呕心沥血，历时半年多，最后却因为种种因素，无疾而终。想到，部门的几个项目自动化实现效果不好或者说部门推广自动化最后推不下去的场景，顿时发觉，归根到底不是这些项目不适合自动化，主要还是人的因素。

      回归正题，思考一下：如果一个项目自动化测试的实现，仅仅靠一个人，完全交给他全权负责，那最终可能出现哪几种情况？

      ①.交付的自动化脚本，纯属应付，偷工减料，质量差;

      ②.因对业务理解不深，自动化脚本场景单一，或者有bug;

      ③.因无法确切知道自动化要替代该业务哪部分场景，可能他会选择脚本设计覆盖该业务所有场景，但是结果导致自动化测试脚本维护成本高。（本来，当时是考虑等后续明确后，再进行脚本拆分。。。）

　　抛开上面的话题，我们看一下现在一个项目的成员构成及分工情况：一个项目至少要有3类人：需求人员 + 开发人员 + 测试人员，这三者是一个项目顺利开展下去必不可少的关键角色。

       而对于一个项目自动化测试的实现，其实仅仅靠一个人是不够的，是需要两个人，或者说两个角色：一个是自动化需求分析师，另一个是自动化测试编码者。

       因为需要有人熟悉整个项目的业务，能够挖掘出该项目当前阶段，哪些业务的哪些场景是可以通过自动化测试来替代手工测试进行回归的；需要有人能够实时收集测试人员反馈的情况，知道现阶段哪些重复性的测试工作（比如构造数据、准备数据等），是可以交给自动化来实现，进而辅助手工测试人员进行功能测试。

       而这个角色，只能是自动化测试的需求分析师或者说是自动化负责人。然后自动化测试需求分析师，将需要实现的细节及后续规划告知自动化测试编码人员，由自动化测试编码人员进行自动化脚本开发并测试通过。（当然如果测试负责人具备自动化测试的思维意识，这个角色完全可以由测试负责人担任，自动化测试人员，只需按要求编码就好了，最终交付的自动化脚本，质量也绝对会很高。）

       所以，综上所述，这不是一个人，能集需求 + 开发 + 测试工作于一身，就可以很好完成的，需要有一定的分工。自动化测试人员，可以担任开发+测试的角色，但还需要有个了解项目的资深人员出自动化的需求，规划设计好自动化交付件原型，制定自动化设计规范，并对最终交付的自动化脚本进行验收。