在具备了可自动化测试的基本条件后，仍然需要默认自动化测试工作展开的难度之大！我们必须通过各种分析来确定是不是要继续将测试自动化做下去。根据作者在完成了多个自动化测试项目后总结出的经验（有成功的经验、同样也有失败的经验），我们在做测试自动化分析时最该做的就是以下3种。

　　（1）可行性分析。

　　在进行项目自动化测试之前，第一步就是要确认其可行性，是否可以实行测试自动化。作者认为，在常见的不可行因素下，如果出现其中任何一种，自动化测试工作都是不应该展开的，项目常见不可行因素如下。

　　● 项目时间紧迫。如果项目进度很紧迫，开发周期的时间表很紧，每次交付间隔时间很短，你就没有时间进行测试自动化，也就不要考虑自动化测试了。

● 项目需求变幻无常。测试负责人应该及时和PM或专门的需求人员沟通来获得最直接的项目方面、客户方面的现有情况以及未来情况，从而最终通过分析来确认是否要进行自动化测试。因为PM和需求人员往往是对项目现今和未来的发展或对客户的思想及个性最了解的人群。举一个例，作者曾经经历过一个项目，是属于比较大型的长期项目，但是最终这个项目并没有展开自动化测试。为什么？因为这个项目的需求由于总是要“赶时髦”，所以一直在不断变化，那么即使它再耗人力、物力，作者所在的测试团队也只能老老实实在每个版本下来后去进行大批量的手工回归测试。当然，现在看来作者非常庆幸，在这个项目中放弃了自动化测试的念头，因为刚上线那时，作者就和PM进行了沟通，得知了这个项目以后会是一个需求时常变化的项目。如果那时候引入测试自动化的话，作者相信基本现在已经属于一个烂尾楼工程了！

　　● 项目周期短。如果你觉得在写完所有自动化测试脚本后，这些脚本只能仅仅为你服务几个（6个或更少）版本，不用多考虑了，放弃自动化测试吧。

　　● 自动化测试工具对系统的有效性。如果上述的前3个和你所在的项目不沾边，那么请再看看这条因素。我们知道，想要开发自动化测试脚本，那么必须具备一款匹配的自动化测试工具，可以是开源的也可以是商业化的，甚至是自主研发一款。此时，就需要确切地了解这款测试工具能否应付项目中的需要。举个例，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些Java控件，但是测试工具自带的插件中又不包含Java控件的识别插件，那么此时就算拥有这款自动化测试工具，但由于无法有效地识别到项目中的控件，所以，对于项目来说是毫无作用的。

（2）抽样demo分析。

　　通过可行性分析后，接下来要做的就是一个做demo了，等待demo完成后，可以再次通过分析看看自动化测试工作能否顺利地展开下去，因为demo已经是一个实体案例，所以，可以完全通过透析demo来发现是否存在技术上的致命问题。通常在demo完成之后，有经验的自动化测试工程师或组长就能对这个项目的自动化测试工作有一个大体的把握了。换言之，可以把demo看成更深层次的可行性分析，一旦通过了抽样demo分析，自动化测试就可以展开了。关于demo的选取，一般直接选择冒烟测试用例（大冒烟）写成测试脚本后执行，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行到即可。

　　（3）测试需求分析。

　　到了测试需求分析这一步，分析的就不再是能否在项目中引入测试自动化了，而是在为下一阶段定制具体计划打下基础。测试需求其实就是测试目标，也可看做测试自动化的功能点，也就是自动化测试工程师想完成的任务。比如我们需要分析项目中具体哪些测试需求（功能点）准备进行自动化测试。一条测试需求可以包含多条自动化测试用例，通过测试需求分析来判定项目中测试自动化要做到什么程度。举个例子，在自动化测试用例的设计上，大体是以正向、反向（见小提示）划分的，一般在自动化测试中，优先考虑实现正向的测试用例后再去实现反向的测试用例，而且反向的测试用例大多都是需要进行分析然后筛选出来的，因为反向的测试用例实在太多了。我们知道，自动化测试是不需要也没有必要做到100%覆盖率的。所以，在测试需求分析这个阶段，确定测试覆盖率以及自动化测试粒度、测试用例上的筛选等都是重点工作。

转自精通QTP——自动化测试技术领航