自动化测试个人已经投入两年多的研究和实践，我拿有3个典型的工作经历来配合学习自动化测试。

　　首先一点，自动化测试不能开始就对其投以发现更多问题的期望。我个人认为，自动化首先是让我们测试人员的工作智能化，能够节省时间和提高工作技能是首要需求。毕竟循环测试同样的东西是很多测试人员都碰过的经历，好处是你会积累很多业务经验，坏处是你会厌倦工作（尤其通宵赶版本），这时人之常情。所以首先定位为两点：做一些手工测试做不到的环境测试和减轻测试人员的工作量和枯燥感。好比我们之前学的测试计划方式，不同的阶段给予不同的定位。

　　在总结前，说一些概念：实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：

　　软件需求变动不频繁，项目周期足够长，自动化测试脚本可重复使用。

　　通常适合于软件测试自动化的场合：

　　回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；　　此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；

　　软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以及性能测试方面）。

　　这时我给出3个工作经历的场景，都是以嵌入式产品，无线通讯业务的项目：

　　A大企业，拥有很细的部门分工，很成熟的产品和足够的人力，拥有自己开发的一套自动化。

　　B产品很适合用于自动化，但组内没人有自动化经验，一直在自己弄自动化打”擦边球”

　　C同样的产品别的公司能够自动化，想找做过的人来搭建自动化环境。

　　自动化测试需求分析：

　　A：写需求分析前，首先在产品会议上有经验者分析哪些功能能够自动化，哪些功能不行。因为有自己的自动化工具，所以还需要分析本产品和我司的自动化工具的接口和插件需求。最后定论自动化哪些工作放在测试部，哪些工作放在开发部，哪些功能执行自动化，从而设计测试需求，内容包括测试用例等等

　　B：由于自身组内弄自动化，所以没有需求分析，只通过项目申请来获取收费的自动化工具，能就用收费的，不能就上网找免费。

　　C：需求由1~3个有自动化经历的工程师自己写，由于人力物力问题，基本和手工测试的需求一样

　　总结：第一个是正规的流程，实用且评估了风险的需求；第二个基本上就是性能测试”需求”；第三个是手工和自动化测试一致的需求。

　　自动化测试框架的搭建：

　　A：分工明确后，分出功能测试，性能测试，业务（场景）测试的几块自动化，按照不同的测试需求搭建测试框架，分析该产品的部门人力情况和产品的开发语言，选择出自动化开发语言，工具，调用的过程，以及文件结构如何划分。搭建一套兼容自动化测试平台且适合自己产品的环境。

　　B：基本的测试框架就是”外挂脚本”+免费性能工具（因为风险大没投入自动化培训和收费工具）。

　　C：有基本的产品测试框架，但是过程同样因为人力物力问题而导致搭建的问题和进度较慢。

　　从上面3个实例对比下，影响自动化测试的因素有：人力物力资源投入，产品评估，软件测试管理，工程师技能等。

　　之前自我培训的时候提出过自动化测试的时期在测试前期和后期是否是评估自动化测试的标准。现在我个人的总结看法是即使在实力强大的企业，自动化测试执行的阶段其实是在于你需要自动化测试做什么？做单元测试可以放在开发阶段，做功能测试放在前期，做性能测试放在后期。所以应该这个理解，好的自动化测试其中一个标准是执行了多少的自动化测试方式。

　　在3个工作场景中提的自动化问题单（以一个项目完结为准）：A150个，B20个，C5个。说下B和C，因为B没有一个需求规格，是测试人员以探索性测试和模糊的性能指标进行测试，20个自动化问题单某种程度是体现测试人员的经验和能力；C是由于没有足够的支撑，没有B产品那样合适做自动化，所以应对需求变更和风险评估缺陷，导致大部分时间投入在改脚本，问题单就非常少。

　　所以总结B的大致问题是缺乏自动化测试实施的经验，对自动化测试期望过高，C是自动化测试时间不充足，自动化测试工具（产品需求）更新过于频繁，自动化测试工具对软件测试本身没有起到帮助作用。

　　当我总结完毕后。再次面向一个自动化测试项目，我该怎么做？

　　项目周期长短来制定不同的自动化测试规模，判断软件需求变动；假设自动化必须执行且项目权利大时，根据项目周期长短来设定人力和物力的投入，需求中变动小的模块投入优先自动化设计，其他的以附属特性，通过开会裁决进行增加（条件允许的话给新员工练手）。

　　测试目的？单元测试？功能测试？性能测试，不同目的给出的方案不同。好比性能测试用lr，回归测试为主用QTP。

　　测试用例还是以手工用例为模板（不能因为区别而抛弃），时间充裕可以重新编写测试用例功能模块，同时分析哪些功能自动化，哪些不能。有开发支持则投入更多。同时测试用例基本上都是一个函数为一个测试用例的写法，给出AW和模板规范，给出命名规则等。

　　评估风险以及应对，例如项目突然忙起来的话怎么办。这是根据不同能力的工程师做出不同的选择。

　　选择尽可能少的自动化产品覆盖尽可能多的平台，测试流程管理自动化通常应该优先考虑，性能测试自动化产品将优先于功能测试自动化被考虑，尽量选择趋于主流的产品。最重要不是代码语法等，是时时刻刻都要有个架构和设计的思想。自动化测试不能抛弃手工测试的那些原则。

　　最后，不管测试做到什么程度，还是以人为本。不知正确与否，我还坚持一个原则，是我第一个带我做测试的经理说的：测试有着承上启下的作用。交流好了能够解决很多不必要的东西。同时对于产品是否适用于自动化这个问题，我的个人认为每个IT业的产品都能够做到自动化，但是重点在于什么时间或阶段和什么方式去实现。

版权声明：本文出自 acbennn 的51Testing软件测试博客：http://www.51testing.com/?299791

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。