[转载] 自动化测试及工具的一点理解

1 、回归测试：

由于回归测试的测试目标是已有的，稳定的功能，我们会下意识的以为是不会有问题的，并且往往只需要测试一次就行，在这中情况下，如果能有一个稳定的自动化测试脚本来代替手工的操作，将极大的提高工作效率，在关注新功能的同时不会忽略回归测试。而且随着产品版本不断的迭代，叠加的功能也会越来越多，我们会更关注新功能，没有更多的精力和意识去关注既有功能是否被破坏掉了，所以自动化是不二的选择。 

2 、手工测试和自动化的区别：

手工测试：测试人员能很好的把握测试用例之间执行的先后顺序，一个个有序的执行测试，后执行的测试可以利用前一个测试执行后所创建的数据记录 自动化测试：需要在程序中将脚本的执行顺序显示的用代码表示出来，并且清晰的告诉计算机如何判断结果的正确与否，测试用例之间的依赖关系很难在脚本中清晰的表达出来，运行脚本的人员并不知道用例之间的依赖性。 

3 、测试环境

我们知道，在测试之前对于测试环境的搭建是很重要的，保证测试环境的正确性、快速的搭建出测试环境，有利于之后测试的顺利进行。一般对于同一个需要测试的软件，系统的环境要求是一样的，要是在不同的机子上测试，每次都需要重新搭建一个环境，这样既耗时又耗费力气，如果能将环境的配置信息编写成脚本，每次只需要运行脚本就可以将环境搭建好，那么节省大量的人力物力。 

4 、不是所有都是自动化

软件产品开发的特点就是紧急，时间紧，如何在短时间内实现自动化，是否需要自动化都是需要考虑的。如果产品周期短，脚本的开发执行成本远远大于手工执行脚本，在根据之后对于该脚本的执行次数来看，就可以简单的判断是否可以自动化。自动化测试虽然好，但不能一味的将所有的都自动化，自动化投入的时间成本会比较高。自动化框架和脚本的开发是一个投入量很大的项目，而一个可读性不高，健壮性不强的脚本，往往会让测试人员耗费大量的精力去维护，其结果往往得不偿失。所以在脚本开发时要特别注意脚本的了可读性、独立运行性和可重复性，降低后续的维护成本。 

对于自动化测试工具：

1 、界面自动化测试工具，我们往往入门的时候都是用的商业或者开源的工具，例如： QTP 、 RFT 之类，这些都是界面级别的自动化测试，界面自动化测试的有一定开发难度，但是确有不少的开源库可以提供，完全可以基于以上库开发，或者有一些开源的工具很成熟了，你所做的就是基于以上进行一下更改。例如：测试 Java 界面的工具就有 aboot 、 swbot 、 mathron 等开源工具，测试 web 界面的有 Selenium 、 watin 等，测试移动端的有 robotium 、 monkey 等。要能二次开发这些工具，主要是需要理解抓取对象和回放的原理，然后是一些配置文件的处理，对象库里主要是 XML 的处理，一般录制功能我觉得可以忽略。

2 、白盒测试工具，一些代码级别的测试工具，例如：对代码覆盖率的分析、对代码质量的分析等，这方面涉及较浅，就不随便造次了。

3 、接口自动化测试工具，接口自动化测试工具在开发的时候，首先需要明确业务接口类型，然后掌握一定的接口工具的应用方式，一般的接口工具都是会解析某种接口定义文件，然后将接口文件以界面的形式展现出来，可以通过对界面接口的操作：对某个接口填写参数，然后发送到服务器端，查看响应，或者直接 get 接口返回值。例如： SoapUI 工具是针对 WebService 系统的测试，主要是解析 WSDL 接口定义文件。 JMeter 和 LR 也可以做接口测试工具，例如： java 接口和 HTTP 接口等。之前，开发过的接口工具包括： SNMP 接口和 corba 接口工具，其原理也是解析 mib 和 IOR 接口定义文件，然后可以对接口进行 set 与 get 操作。所以，开发这类的工具，一定要明确什么是软件接口、然后接口描述文件是什么，最后是如何去对接口进行操作，日志和结果的展现等，还有一些就是额外的功能了，例如：录制，将测试人员对接口的操作录制下来，成为工作流等。

4 、性能自动化测试工具，看到性能测试工具，大家很容易想到 LR 、 Jmeter 之类，这方面的工具，我用的较少，但是会基于自己公司内部的产品一些特殊性能场景方面的测试，会专门开发一些这样的工具，例如：开发一个发送 SNMP 网络报文的工具，模拟告警最大接收和并发性能，开发一个网元模拟器，能够模拟大量不同 IP 的网元，可以在公司网元管理器上测试同时管理的最大网元等。所以，性能测试首先要与业务场景相结合，然后掌握一定的性能基础和指标，分析好相关的接口协议和需要模拟的业务，就可以快速开发相应的工具了。

5 、系统应用级别的自动化测试工具，这种工具需要明确应用场景，即明确需求，例如：我之前开发一些部门内部工具集合，专门提供给测试人员进行脚本录制()、公司级别的有采集和巡检工具。(对外支持)，这部分工具带来的效益是很大的。所以说，千万不要将自动化测试局限在测试方面，其实提高测试与开发的人员的效率、以及对公司产品的质量保障方面的工具都是能给公司带来直接效益的。也许几行代码也是一个能提升效率的好的工具。

测试工具虽好但不能迷恋，不能期望测试工具可以取代手工测试。测试工具在测试工作中起的是辅助作用，一般用来提高测试效率。自动化测试弥补了手工测试的不足，减轻一定的工作量。实际上测试工具是无法替代大多数手工测试的，而一些诸如性能测试等自动化测试也是手工所不能完成的。

　　对于自动测试技术，应当依据软件的不同情况来分别对待，一般自动技术会应用在引起大量重复性工作的地方、系统的压力点、以及任何适合使用程序解决大批量输入数据的地方。然后再寻找合适的自动测试工具，或者自己开发测试程序。一定不要为了使用测试工具而使用。

我个人认为自动化测试，就是用技术和自动化去服务测试，保证质量，提高产品生产率（不是测试生产力）。无论如何这个行业需求是关键，脱离需求和具体环境，一切都是玩笑。

基于全球首创的对象识别技术， TestBird 可以为客户提供深入到移动 APP&游戏内部所有功能的深度解析能力。通过自助 App 功能测试、远程真机调试、真机兼容性测试、真人体验测试、 真人压力测试和崩溃分析等产品， TestBird 建立了云手机、云测试和云分析三大测试平台，为移动应用提供从研发到上线再到运营的一站式质量管理服务，帮助移动应用企业建立完善的质量管理体系和能力，全面提高移动应用的 DAU 、留存率以及付费情况。