自动化测试的好处

第1章

自动化测试的好处

1.回归测试，降低测试成本

对于产品型的软件或生命周期长的项目，经常会有新功能的开发或需求的变动，对于新发布的软件功能，大部分都和上一个版本相近或相同，这些功能如果在上一个版本之前已经实现了自动化测试，那么新发布的版本中，这部分功能就可以自动化测试实现，避免了重复测试的成本，也确保了软件的质量。

2.提高测试效率

一些测试用例手工测试是比较繁琐的，比如话单或协议字段的检查，如果是人工检查将是一件既繁琐又耗时还容易出错的工作，如果是自动化测试，测试就会变得轻松和容易很多。

对于检查点很多的测试用例，如果手工执行一步都需要停下来检查好几个复杂的检查点，测试的效率自然是非常低，使用自动化测试，设置好了输入条件和预期结果，只要点击按钮运行一下脚本就知道了复杂的测试结果。

3．易于发现软件的改动

自动化测试脚本可以重复执行，容易发现软件的任何变动。比如修复了一个TR 后，引起原功能的改动，执行相同的脚本，可以通过测试轻易发现问题。

4.充分利用资源

自动化测试可以不需要人在现场的情况下自动执行，发布了一个新版本的软件后，可以在白天的上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或周末执行，第二天上班就可以看到执行的结果。这样充分利用时间资源，提高测试的效率，也避免了开发和测试之间的等待。

5．性能测试

在一些压力大的性能测试中，人工是很难模拟的。在没有引入自动化测试工具之前，为了测试并发，研发中心再加上公司的其它部门上千号人在研发经理的口令“1－、2－、3！”的号召下，大家同时按下同一个按钮。这样的测试，虽然是模拟了并发，但需要消耗相当大的成本，想要测试一次也不容易。

在性能测试中使用自动化测试，可以轻易模拟并发，为性能压力测试提供了更好的方法。

6．将精力投入更有意义的测试

自动化测试减轻了很多重复的工作，我们有更多的时间去思考如何提高软件的质量，制定详细的测试计划，精心设计测试用例，构建更复杂的测试。对于我来说，这是自动化测试给我带来的最大的好处。

自动化测试的好处有很多，但并不意味着自动化测试可以取代手工测试，也不意味着任何的系统都适合自动化测试。自动化测试的意义并不是取代人在测试中的位置，而是将人从重复繁琐的工作中解放出来，做更有价值的测试工作。

第2章

自动化测试基本原则

2.1适合做自动化测试的软件

很多公司都知道自动化测试可以提高测试的效率，但在知道这个道理的公司中大部分的公司都是以手工测试为主的，原因可能有很多，但最大的影响因素就是自动化测试的成本。如果自动化测试的成本比手工测试的成本还大或者并没有比自动化测试占有太大的优势，公司自然不会选择自动化测试了。是否做自动化测试，主要看成本的投入和效果的产出是否值得。

1、不适合做自动化测试的系统

1）系统业务逻辑和交互过于复杂

如果系统业务逻辑和交互过于复杂，要实现自动化测试的成本非常高，工具开发和脚本编写的时间可能远远大于手工测试，这个系统就没有自动化测试的必要。

2）项目周期过短

如果系统的生命周期很短（半年内），即使很容易实现自动化测试，但自动化测试的使用率只有很短的时间或很有限的次数，这样的自动化测试也没有必要。因为前期脚本的编写和后期的维护都需要很多的时间，虽然自动化测试在功能测试的过程或回归测试的过程会节省一些时间，但如果自动化测试的脚本只是很短的生命周期，自动化测试的成本就非常的高了。

3）系统需求频繁变动

对于功能不稳定的系统，会由于这些不稳定因素导致自动化测试失败，自动化的测试结果也就变得不可信，这类型的系统也不适合使用自动化测试。

2、适合做测试化测试的系统

适合做自动化测试的系统，通常是一些生命周期比较长的项目或产品，且系统功能实现自动化测试也较为容易，这样的项目使用自动化测试必然可以节省很多的资源和成本。特别是一些在今后的几年间需要不断开发和维护的项目，需要重复的进行大量的回归测试，如果有完善的自动化测试脚本，回归测试就可以节省大量的时间和精力了。对于一些增量式的产品，白天手工测试新功能，晚上或周末利用自动化测试脚本回归测试，可以达到资源使用的最优化，用很少的时间和很少的资源做很多的事情。

简而言之，是否值得使用自动化测试，就要看它是否具有自动化测试的特点和高的投资回报率。

2.2开始自动化测试的时机

如果是新的自动化测试工具的开发或研究，最好预留一个比较充裕的时间，时间太赶很难设计出精品。如果想在功能测试阶段使用自动化测试，那么自动化测试架构的设计最好能够与代码实现同步，否则如果等代码实现提交测试之后再做自动化测试工具的开发或研究，在功能测试或回归测试的过程中就被动了很多。

关于在项目的什么阶段开始自动化测试，由项目决定，对于需求相对稳定并且是基于成熟的架构上开发的系统，自动化测试脚本最好在功能测试开始之前编写，在功能测试阶段就可以使用已经编写好的脚本做功能测试了。

但我们平时遇到的项目，有很多是需求变化比较大的，或者是一些不够成熟的系统，这样的系统如果在功能测试之前编写好的脚本，很有可能不能在系统上正确运行，大多还是需要手工执行才可以测试，甚至会在功能测试完后系统跟功能测试之前的系统会有非常大的区别。对于这样的项目，自动化测试开始得越早项目的成本就越大，最好在系统的架构或需求相对稳定后再做自动化测试。

对于一些需要录制GUI界面的功能的自动化测试，在页面的功能相对稳定之后再做自动化测试性价比会比较高，因为页面是最容易变动的部分，而且任何一个控件的修改都会导致自动化工具不能识别控件，导致很多自动化测试脚本会跟着做大量的修改，增加了维护的成本。当然，因为页面变化而引起的脚本的改动的大小，也跟自动化测试的架构和写脚本的功力有密切的关系。

对于一些协议或接口相关的功能测试（比如：XML或socket接口等），是较为容易实现自动化测试的，封装好底层的协议提供给自动化测试脚本调用，即使是协议会有变化，改动起来还是很简单的，维护的成本相对较低。

总的来说，在软件功能达到相对的稳定，没有严重错误和逻辑错误后开始自动化测试，性价比是比较高的。