自动化测试【转载内容】

0、序

      测试是个大学问。在测试人力不足、项目迭代快速的时候，时常想起自动化测试。到底能否帮到我，我们那一个一个快速迭代的版本？

      有Web、有Win客户端、有Android和iOS手机客户端，合理的考虑、适当地行走，自动化测试，不是那么简单。天、时、地利、人和，我占哪样？得好好琢磨和尝试实践一番……

p.s.:

1、2 from: http://www.51testing.com/html/21/n-225721.html，鸣谢

3       from: http://blog.sina.com.cn/s/blog_632292990100xcxz.html，再次鸣谢

 

1、自动化测试适用的测试阶段

　　软件产品的开发和测试一般分为两大阶段，一是项目执行阶段，二是项目维护阶段。

　　软件开发过程中的第一阶段就是软件产品的开发编码及需求的实现阶段，第二阶段就是软件产品的功能维护阶段，查看软件是否有需要改进的方面。

　　与开发相对应，测试也分为两个阶段，因为软件的测试和开发是相辅相成的。测试的第一阶段为同软件开发同时进行的单元测试、功能测试、性能测试等基于软件功能实现的一些测试，第二阶段为对软件产品的集成测试、系统测试、配置测试及验收测试等。

　　建议在软件测试的第一阶段可以大量采用自动化测试。在单元测试、功能测试及性能测试中使用自动化测试能够降低测试人员的大量重复劳动操作，减少测试的工作量，能够节省大笔产品测试的时间和成本的开支。虽然自动化测试中建立和维护测试代码需要花费大量的时间，但是随着产品新版本的不断发布，自动化测试代码和测试用例在产品测试过程中的是可以重复使用的，这对保障产品基本功能的正常运行有很大的帮助。

　　特别是在性能测试中，自动化测试工具能够完成人力所不能完成的测试任务，如Web网站系统的并发性测试，在实际测试中我们不可能让成千上万个用户来进行登录、与服务器交互等操作，但是如果采用测试工具我们就可以轻松实现此类操作。性能测试工具中，LoadRunner 就是一款相当好用的测试工具。

　　而在第二阶段的操作属于产品的后期操作，其主要工作是进行产品功能的维护和改进，其主要功能不会产生巨大的变化，所以此阶段不建议采用自动化测试。

　　以上是针对各个测试阶段是否适合采用自动化测试的讨论，下面我们再根据项目自身的原因来讨论是否适合使用自动化测试。

　　如果是基于某一个系统二次开发的、开发周期较长、开发完成之后需要长期维护和修改的项目，建议选择自动化测试。

　　在前面已经提到了，对于有后续版本的软件项目，各种测试用例及测试脚本的可重用性是非常高的。

　　自动化测试多用于发现原来出现过的Bug。在项目开发过程中的后期阶段，新需求开发工作很少，更多的工作是修改程序及程序重新发布，这时会需要频繁验证已实现的功能是否能正确地工作，因为每重新发布一次就会有未知的隐患存在。那么在这个阶段自动化工具的作用就体现出来了，执行自动化测试可以确保主要功能点是正确无误的。

　　大型项目的回归测试是一项重复率高、工作量大、工作枯燥无味的工作，使用人工测试会严重浪费人力资源及财力资源，也无法保证进度的执行。所以一般大型项目如果既适合采用自动化测试，又有能力采用自动化测试，那么建议使用自动化工具来控制整个测试项目。

　　对于一些相对独立并且开发周期较短的项目，由于项目收入及资金来源不是很充足，不值得花费大量精力去实施自动化测试。

　　对于需求变更相对频繁的项目，需要花费较高的成本来维护和修改测试脚本，也不适合采用自动化测试。

　　对于一些经费不太充足的测试项目，采用人工测试能够节省开支。

　　以上讨论了自动化测试适用的阶段，你可以根据项目的实际情况来选择是否使用自动化测试。

 

2、自动化测试执行的先决条件

　　执行自动化测试需要满足如下条件：

　　1）软件需求变动不频繁。

　　进行测试时能发现Bug可以提高测试人员的自信心。在自动化测试的执行过程中，如果被测软件不稳定，可能会导致自动化测试失败，出现崩溃性错误，这会极大地打击自动化测试执行人员的自信心。

　　2）项目周期足够长。

　　这一点我们在前面已经讨论过了，此处不再赘述。

　　3）产品结构相对复杂。

　　对于产品结构相对复杂的软件建议采用自动化测试。

　　4）资源投入相对充裕。

　　对于人力及财力资源相对充足的项目使用自动化测试。

　　5）测试时间相对长，且存在大量需要执行回归测试的软件项目。

　　对于整个项目周期较短的测试，使用自动化测试会入不敷出。

　　6）待测软件系统界面基本稳定，没有较大的功能上的更改。

　　一定要等到待测软件系统界面基本稳定时，才能使用自动化测试工具进行功能、性能等测试。

 

3、自动化测试的过程

       自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

1) 自动化测试需求分析。

当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

2) 自动化测试框架的搭建。

所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。

而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：

a. 公用的对象。

       不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。

b. 公用的环境。

       各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。

c. 公用的方法。

       当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。

d. 测试数据。

       也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。

在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

3) 自动化测试脚本的编写

       该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为，以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

4) 脚本的测试与试运行

       事实上，当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

因此，脚本的测试与试运行极为重要，它需要祥查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。