● 项目需求变幻无常。测试负责人应该及时和PM或专门的需求人员沟通来获得最直接的项目方面、客户方面的现有情况以及未来情况，从而最终通过分析来确认是否要进行自动化测试。因为PM和需求人员往往是对项目现今和未来的发展或对客户的思想及个性最了解的人群。举一个例，作者曾经经历过一个项目，是属于比较大型的长期项目，但是最终这个项目并没有展开自动化测试。为什么？因为这个项目的需求由于总是要“赶时髦”，所以一直在不断变化，那么即使它再耗人力、物力，作者所在的测试团队也只能老老实实在每个版本下来后去进行大批量的手工回归测试。当然，现在看来作者非常庆幸，在这个项目中放弃了自动化测试的念头，因为刚上线那时，作者就和PM进行了沟通，得知了这个项目以后会是一个需求时常变化的项目。如果那时候引入测试自动化的话，作者相信基本现在已经属于一个烂尾楼工程了！
● 项目周期短。如果你觉得在写完所有自动化测试脚本后，这些脚本只能仅仅为你服务几个（6个或更少）版本，不用多考虑了，放弃自动化测试吧。
● 自动化测试工具对系统的有效性。如果上述的前3个和你所在的项目不沾边，那么请再看看这条因素。我们知道，想要开发自动化测试脚本，那么必须具备一款匹配的自动化测试工具，可以是开源的也可以是商业化的，甚至是自主研发一款。此时，就需要确切地了解这款测试工具能否应付项目中的需要。举个例，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些Java控件，但是测试工具自带的插件中又不包含Java控件的识别插件，那么此时就算拥有这款自动化测试工具，但由于无法有效地识别到项目中的控件，所以，对于项目来说是毫无作用的。
（2）抽样demo分析。
通过可行性分析后，接下来要做的就是一个做demo了，等待demo完成后，可以再次通过分析看看自动化测试工作能否顺利地展开下去，因为demo已经是一个实体案例，所以，可以完全通过透析demo来发现是否存在技术上的致命问题。通常在demo完成之后，有经验的自动化测试工程师或组长就能对这个项目的自动化测试工作有一个大体的把握了。换言之，可以把demo看成更深层次的可行性分析，一旦通过了抽样demo分析，自动化测试就可以展开了。关于demo的选取，一般直接选择冒烟测试用例（大冒烟）写成测试脚本后执行，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行到即可。
（3）测试需求分析。
到了测试需求分析这一步，分析的就不再是能否在项目中引入测试自动化了，而是在为下一阶段定制具体计划打下基础。测试需求其实就是测试目标，也可看做测试自动化的功能点，也就是自动化测试工程师想完成的任务。比如我们需要分析项目中具体哪些测试需求（功能点）准备进行自动化测试。一条测试需求可以包含多条自动化测试用例，通过测试需求分析来判定项目中测试自动化要做到什么程度。举个例子，在自动化测试用例的设计上，大体是以正向、反向（见小提示）划分的，一般在自动化测试中，优先考虑实现正向的测试用例后再去实现反向的测试用例，而且反向的测试用例大多都是需要进行分析然后筛选出来的，因为反向的测试用例实在太多了。我们知道，自动化测试是不需要也没有必要做到100%覆盖率的。所以，在测试需求分析这个阶段，确定测试覆盖率以及自动化测试粒度、测试用例上的筛选等都是重点工作。
|
小提示： 自动化测试用例设计中的“正向”和“反向”指什么？通俗点讲，“正向”测试用例就是正常的业务操作流，几乎没有什么非正常情况操作融入在其中。反之，“反向”测试用例就是异常的业务操作流。我们可以想象一下，做出来的软件是给谁用的？当然是给用户使用的，一般情况下，用户在基本使用上不会像测试工程师那样去“破坏”，他们只关注软件的功能是否好用、是否有异常、是否有差错。所以，“正向”的测试用例就是只针对正常的操作，不会去考虑异常情况，当然，也必须是自动化测试脚本优先要写出来的。待把这些正常的业务操作的测试脚本全部完成后，才去考虑加入部分最重要且优先级最高的“反向”测试用例进去，比如一个注册页面中某表单的填写，用户一样比较关心系统对错误的处理情况，这时候，就需要把自动化测试用例设计成“反向”的，然后加入到回归测试中。不过，“反向”测试用例实在太多，如果全部都写成脚本，是没必要也不符合自动化测试的特性。所以，才需要分析、筛选、决策。 |
3．测试计划定制
在经过了测试需求分析阶段后，项目PM和自动化测试组长就该正式起草正式方案了。写一个优秀、完善、精致的测试计划是必须的工作。当然，这里不会讲述测试计划是如何写的。只是要告诉读者，测试计划的质量和以后的工作顺利进展有着密切的联系，能越早地把各种情况都考虑在计划中对以后自动化测试项目的展开都是很有利的，想要使得自动化测试最终成功，也必须踏踏实实抓住每一个环节，测试计划定制阶段如果能做好，则可以看作是一个良好的开始。而且，通过作者的经验发现，自动化项目的测试计划越全面，后期越能够循规蹈矩的去实施，自动化测试的成功率就越高；如果自动化测试计划设计不周全，靠后期去完善、补充，基本上这个自动化测试项目就成了一个实验项目。
4．自动化测试设计阶段
在这个阶段，把它分为两个核心部分。第一个部分就是自动化测试框架，第二部分就是自动化测试用例。
（1）自动化测试框架设计、开发与搭建。
自动化测试框架的好与坏直接影响以后项目的实施。作一个恰当的比喻，一个软件项目如果没有一个好的架构，那这个项目也不会好到哪里去，自动化测试框架对于整个自动化测试项目来说就相当于一个架构，这个架构越好、功能越强大和实用，那就可以给今后整个自动化测试项目的工作过程带来更多的好处。不过，国内目前很多自动化测试框架都过于浮夸，很多工程师为了把自动化测试框架设计得更加强大，开发了一个又一个的“强大”功能，其实到头来只是“花拳绣腿”，根本和自动化测试项目无法兼容！他们也忘了做自动化测试的基本目的是“测试”两个字，把自动化测试框架搞成了一个新项目来开发，真是得不偿失！自动化测试框架其实不止是一种程序，它也应该是、一种思想、一个规范。测试框架的好坏判定应该以实用、适用、扩展性强、使用范围广、稳定、思想先进为先，绝对不能以“强大”却又背道而驰的可用功能为主！在本书的自动化测试框架章节中，作者会把自己原创的自动化测试框架完全奉献给每一位读者。
