软件工程自动化测试基础Word格式文档下载.docx

软件工程自动化测试基础Word格式文档下载.docx

《软件工程自动化测试基础Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件工程自动化测试基础Word格式文档下载.docx（11页珍藏版）》请在冰豆网上搜索。

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

　　4.充分利用资源

　　自动化测试可以不需要人在现场的情况下自动执行，发布了一个新版本的软件后，可以在白天的上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或周末执行，第二天上班就可以看到执行的结果。

这样充分利用时间资源，提高测试的效率，也避免了开发和测试之间的等待。

　　5．性能测试

　　在一些压力大的性能测试中，人工是很难模拟的。

在没有引入自动化测试工具之前，为了测试并发，研发中心再加上公司的其它部门上千号人在研发经理的口令“1－、2－、3！

”的号召下，大家同时按下同一个按钮。

这样的测试，虽然是模拟了并发，但需要消耗相当大的成本，想要测试一次也不容易。

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

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

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

对于我来说，这是自动化测试给我带来的最大的好处。

　　自动化测试的好处有很多，但并不意味着自动化测试可以取代手工测试，也不意味着任何的系统都适合自动化测试。

自动化测试的意义并不是取代人在测试中的位置，而是将人从重复繁琐的工作中解放出来，做更有价值的测试工作。

　　第2章自动化测试基本原则

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

　　很多公司都知道自动化测试可以提高测试的效率，但在知道这个道理的公司中大部分的公司都是以手工测试为主的，原因可能有很多，但最大的影响因素就是自动化测试的成本。

如果自动化测试的成本比手工测试的成本还大或者并没有比自动化测试占有太大的优势，公司自然不会选择自动化测试了。

是否做自动化测试，主要看成本的投入和效果的产出是否值得。

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

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

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

　　2）项目周期过短

　　如果系统的生命周期很短（半年内），即使很容易实现自动化测试，但自动化测试的使用率只有很短的时间或很有限的次数，这样的自动化测试也没有必要。

因为前期脚本的编写和后期的维护都需要很多的时间，虽然自动化测试在功能测试的过程或回归测试的过程会节省一些时间，但如果自动化测试的脚本只是很短的生命周期，自动化测试的成本就非常的高了。

　　3）系统需求频繁变动

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

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

　　适合做自动化测试的系统，通常是一些生命周期比较长的项目或产品，且系统功能实现自动化测试也较为容易，这样的项目使用自动化测试必然可以节省很多的资源和成本。

特别是一些在今后的几年间需要不断开发和维护的项目，需要重复的进行大量的回归测试，如果有完善的自动化测试脚本，回归测试就可以节省大量的时间和精力了。

对于一些增量式的产品，白天手工测试新功能，晚上或周末利用自动化测试脚本回归测试，可以达到资源使用的最优化，用很少的时间和很少的资源做很多的事情。

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

　　2.2开始自动化测试的时机

　　如果是新的自动化测试工具的开发或研究，最好预留一个比较充裕的时间，时间太赶很难设计出精品。

如果想在功能测试阶段使用自动化测试，那么自动化测试架构的设计最好能够与代码实现同步，否则如果等代码实现提交测试之后再做自动化测试工具的开发或研究，在功能测试或回归测试的过程中就被动了很多。

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

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

对于这样的项目，自动化测试开始得越早项目的成本就越大，最好在系统的架构或需求相对稳定后再做自动化测试。

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

当然，因为页面变化而引起的脚本的改动的大小，也跟自动化测试的架构和写脚本的功力有密切的关系。

　　对于一些协议或接口相关的功能测试（比如：

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

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

　　2.3自动化测试的覆盖率

　　自动化测试的覆盖率是很多管理层所关心的，很多项目或产品的自动化测试目标之一就是自动化测试的覆盖率。

从管理的角度来说，100%的自动化目标只是一个从理论上可能达到的，但是实际上达到100%的自动化的代价是十分昂贵的。

自动化测试覆盖率越高，测试脚本的维护成本也就越大。

由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。

　　自动化测试的覆盖率的大小与自动化测试的成本有着很大的联系。

自动化测试的覆盖率为多少比较恰当，也要看被测试系统的性质和测试的阶段。

　　在自动化测试设计的阶段，可以考虑先实现冒烟测试的测试用例自动化，冒烟测试的功能一般是系统的主要功能，是自动化测试设计必须首先实现的，而且通过实现这些功能，也可以检验自动化测试的架构是否合理。

　　在功能测试的前期，自动化测试脚本的覆盖率最好只是一些关键的并且是相对稳定的功能的测试自动化，用于冒烟测试或关键功能测试。

　　系统稳定后，如果系统是一个生命周期很长的系统，且测试的功能很容易实现自动化测试，这样的系统的自动化测试覆盖率可以考虑在80％以上。

　　但如果是一些时间很赶的项目，或者是一些比较难实现自动化测试的功能，也就没有追求高的自动化测试的覆盖率的必要。

随着测试案例的增加，维护的成本也会相应增加，特别是一些GUI的测试，自动化比率越高，维护脚本的成本也就越高。

　　不要追求在很短的时间实现自动化测试，也不要追求100％的自动化测试覆盖率，积累经验循序渐进的自动化测试，效果会更好。

　　第3章自动化测试实现基本策略

　　自动化测试与软件开发本质上是一样的，利用自动化测试工具，经过测试需求分析，设计出自动化测试用例，从而搭建自动化测试的框架，设计与编写自动化脚本，验证测试脚本的正确性，最终完成自动化测试测试脚本（即主要功能为测试的应用软件）。

　　3.1测试系统需求分析

　　任何测试的基础都是被测系统的功能，不管是手工的功能测试还是自动化测试或者是性能测试，都是基于系统的功能展开的。

当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。

此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

　　很多公司都是将自动化测试和功能测试划分成两个不同的team，自动化测试team的同事实现自动化测试工具的开发，功能测试team的同事向自动化测试team的同事提需求，自动化测试team的同事编写代码实现自动化测试工具的功能后提交给功能测试team的同事使用，这是当前非常常见的自动化测试的模式，毕竟每个人都有自己擅长的技能，某个人也不可能面面俱到，通过这样的一种方式可能使自动化测试的门槛变得更低一些。

自动化测试工具的开发和自动化测试的使用的确是可以由不同的角色去承担，不过作为自动化架构设计的人员，应该是对系统的功能或需求非常熟悉，同时具有良好的设计和开发能力，才可以设计出适合测试系统的自动化测试架构，否则开发出来的自动化测试工具就只是简单的一个工具，某种程度上会增加维护的成本。

　　漂亮的自动化测试架构的设计是一个渐进的过程，但这个渐进是基于对功能熟悉的基础上，全盘考虑之后一点一点的搭建起来的。

　　3.2自动化测试工具的选择

　　很多测试的同行或以前的老同事都会问，你们用什么自动化测试工具？

几年前入门测试时跟着老前辈写自动化测试工具，后来因为兴趣偶尔玩一下当时流行的自动化测试工具，再到现在毫无选择工具的余地设计自动化测试架构，越来越发觉自动化测试工具真的没有那么的重要。

工具始终是工具，思想和架构才是自动化测试的核心，同样的工具不同的人使用会出现完全不一样的结果，而且，不管是什么样的自动化测试工具，原理都有异曲同工之处。

所以，不需要把工具看得那么重要，而是把怎样使用工具，怎样利用工具为你服务放在首位。

也就是你的思想位于工具之上。

　　但是，是不是这就意味着测试工具一点也不重要呢？

当然不是，遇上不稳定或不友好的测试工具，可能会浪费大量的时间在调试工具上，也可能会出现因为工具不稳定导致测试结果的不可信任，那么自动化测试不是提高测试效率反而是阻碍了测试的进度了。

　　关于工具的选择或开发，基本的原则为：

1）首先，能够满足项目的需求，容易扩展，可以满足系统任何重要功能的自动化测试；

2）其次，友好易用，容易上手，为测试人员提供较为低的门槛；

3）当然最重要的是它的稳定性，是否不需要人工干预就能稳定地批量运行所有的自动化测试脚本，并且能够产出准确的测试报告；

4）最后，还有一点就是它的性价比是否值得，免费的软件对公司来说当然是最好：

）

　　市场上有很多测试工具，在这些测试工具中，puretest是一个性价比很高的自动化测试工具。

它容易入门，易于扩展，使用简单，运行稳定，基本上可以满足任何包括GUI、协议和业务逻辑的测试。

　　3.3自动化测试架构设计

　　自动化测试架构的设计是整个自动化测试的灵魂核心，它的好坏关系到自动化测试的成败。

从系统的基本功能入手，设计自动测试架构，这是软件测试的关键一步。

架构的好与坏很重要，它影响到系统的扩展、维护和使用，如果想要系统容易扩展和维护，一定要多花心思在设计上。

很多同行问我使用什么测试工具，我会告诉他们，用什么测试工具其实并不那么重要，不同的人使用同样的测试工具，会做出效果完全不一样的自动化测试，那是因为他们的架构不同，设计比工具重要得多。

　　怎样的自动化测试