第十软件测试自动化

第十软件测试自动化第一页，共四十三页，2022年，8月28日概况

到目前为止我们已经讨论了多种测试类型和如何开发测试用例，但是这些测试用例的运行和检查会花费我们大量的时间和精力。随着测试的覆盖率和质量的提高，以及缺陷的不断改正，测试用例的运行还需要额外的时间。要想解决这个问题就是自动运行大部分需要反复运行的测试用例。通过开发软件和使用工具来进行软件测试叫做软件测试自动化（TestAutomation），也可以称为软件自动化测试（或自动测试）。本章我们将谈论软件测试自动化的几个主要问题。

第二页，共四十三页，2022年，8月28日概况本章内容提要自动测试与手工测试的比较如何开展自动测试自动测试方案的选择第三页，共四十三页，2022年，8月28日10.1手工测试与自动测试

手工测试和自动测试相对，是指不使用工具进行软件测试。在很多公司存在这两种测试方法，也有不少小公司只有手工测试。手工测试和自动测试孰好孰坏，是否自动测试就比手工测试优越？在回答这些问题之前，首先要对手工测试和自动测试有个清晰的认识，知道它们各自的优点和缺点。第四页，共四十三页，2022年，8月28日10.1.2自动测试是否比手工测试优越

在大多数软件开发模式中，软件发布之前都要多次重复编码—测试—修复的过程。如果要测试软件的某项特征，也许需要不止一次执行测试。重复测试的过程也称为回归测试。如果一个小型软件项目有上千测试用例要执行，还要重复执行，手工测试会非常单调和枯燥。而利用工具进行自动测试就可以把人从这种枯燥单调的重复性劳动中解放出来。第五页，共四十三页，2022年，8月28日●提高了测试执行速度，节省了时间。因此自动测试和手工测试比较起来有以下几个优点第六页，共四十三页，2022年，8月28日●提高了测试效率。手工测试存在效率问题，这在软件产品的研发后期尤其明显，因为随着产品的日趋完善，功能日渐增多，需要测试和检查的内容越来越多，很容易遗漏。加之产品发布日期日益临近，人工重复进行回归测试的难度加大，很难在短时间内完成大面积的测试覆盖。第七页，共四十三页，2022年，8月28日●提高了准确度和精确度。测试员尝试了几百个测试用例以后，注意力可能会分散，并开始犯错误。而测试工具可以重复执行同样的测试，并毫无差错地检查测试结果。第八页，共四十三页，2022年，8月28日●更好地利用资源。手工测试需要测试人员在场，而自动测试可以一天24小时、一周7天地随时执行。还可使位于全球不同地方、不同时区的团队监视和控制测试，提供全球时区的覆盖。第九页，共四十三页，2022年，8月28日●模拟测试条件。有的测试用例的测试条件需要的人数或设备数目很大，现实无法实现，测试工具可以模拟真实的情况。第十页，共四十三页，2022年，8月28日

如上所述，既然自动测试有如此多的优点，那么它是否比手工测试优越，可以完全代劳手工测试的所有工作呢？答案是否定的，自动测试没有想象中那么优越。第十一页，共四十三页，2022年，8月28日手工测试有其不可替代的地方，因为人是具有很强智能判断能力的动物，而工具是相对机械、缺乏思维能力的东西。手工测试不可替代的地方至少包括以下几点。●测试用例的设计：测试人员的经验和对错误的猜测能力是工具不可替代的。●界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的。●正确性的检查：人们对是非的判断和逻辑推理能力是工具不具备的。因此，自动测试适宜用在需要重复执行机械化的界面操作、计算、数值比较、搜索等方面。我们应该充分利用自动测试工具的高效率来帮助测试人员完成一些基本的测试用例的执行，从而实现更加快速的回归测试，并且提高测试的覆盖率。第十二页，共四十三页，2022年，8月28日10.2自动测试的开展在进行自动测试之前，先要考虑以下5个方面，这5个方面是成功开展自动化测试需要考虑的因素，也可用于衡量目前的项目是否有足够的条件进行自动测试。第十三页，共四十三页，2022年，8月28日（1）测试自动化类似于软件开发过程录制/回放的脚本开发方式是不可能应付所有自动测试的需求的，因此，需要测试人员掌握必要的开发知识和编码技巧。（2）测试自动化是一个长期的过程首先，不能期望自动测试在短期内找到很多缺陷，自动测试只有在长期的运行后才能体现出它的价值。其次，不要认为只要购买了工具，录制一些脚本，然后，就可以安枕无忧地看着自动测试实现想要的效果。需要考虑自动测试脚本的维护成本。随着测试应用程序功能的增加和修改，测试脚本的维护工作量会急剧增加。（3）确保测试自动化的资源，包括人员和技能最好有专门的自动测试工程师来保证测试自动化持续、顺利地进行下去，自动测试工程师需要对项目的测试自动化负责，设计测试框架和解决各种测试脚本结构，解决测试脚本的开发问题，确保自动测试得以计划、设计和有序地开发、维护。第十四页，共四十三页，2022年，8月28日（4）循序渐进地开展自动测试不要一开始就把自动测试设想得很大，这往往是不可实现的。应该从小开始，先熟悉工具和自动测试的基本技能，然后，整合资源，开始实现一些基本的自动测试用例，例如，冒烟测试类型的自动测试脚本。先实现那些容易实现且相对稳定的功能模块的自动测试，然后再考虑逐步扩展和补充其他相对难实现，或者是比较不稳定的功能模块。（5）确保测试过程的成熟度如果软件企业的测试过程和项目管理过程的能力成熟度比较低，则实现自动测试的成功率也比较低。在展开自动测试之前，先考察一下软件企业各方面的管理能力，例如，测试是否独立进行？有无配置管理？进度控制能力如何？如果各方面的能力成熟度都比较差的话，则不要盲目引入测试自动化。第十五页，共四十三页，2022年，8月28日10.2.1自动测试的周期

自动测试什么时候启动、什么时候结束并没有硬性规则。自动测试工作可以与产品开发同时进行，并且可以与产品的多个发布版本重叠。与多产品发布一样，自动测试也有多个发布版本。对自动测试的一个整体需求就是，自动测试的交付应该在测试执行阶段之前，以便自动测试可交付产品能够在测试被测产品的当前发布版本时使用。自动测试的需求跨多个发布版本的多个阶段，这与产品需求一样。测试执行可以在发布产品后不久结束，但是自动测试工作却在产品发布后仍然持续。第十六页，共四十三页，2022年，8月28日由于产品开发和自动测试开发具有以上的相似性，因此，自动测试遵循的过程和生存周期模型与产品开发的也非常类似。在绝大多数情况下，自动测试也遵循产品的软件开发生存周期（SDLC）模型。本节集中介绍V字模型及其扩展，以介绍测试自动测试的过程。首先研究产品开发所包含的阶段和自动测试阶段如图10-1所示，并理解两者之间的相似性。第十七页，共四十三页，2022年，8月28日6.6单元测试环境桩模块3﹨﹨﹨﹨﹨﹨产品需求产品策划产品设计产品编辑自动测试需求自动测试策划自动测试设计自动测试编码图10-1产品开发与自动测试间的相似性第十八页，共四十三页，2022年，8月28日本章已经介绍过，自动测试生存周期活动与产品开发活动有很强的相似性。就像产品需要采集产品需求一样，自动测试也需要采集自动测试需求。类似地，就像产品策划、设计和编码一样，在测试自动测试过程中也有自动测试策划、设计和编码。在测试产品时检验测试包很重要。测试包是被自动化的一组测试用例和与这些用例相关联的场景（Scenario）。如果测试包中有缺陷，就要花很大的精力搞清楚缺陷是来自产品还是来自测试包。自动测试包在用于测试产品之前，首先要进行测试。如果测试包报告了错误的缺陷，就会严重影响测试自动测试的信誉，影响下一步的自动测试工作。因此，自动测试包必须具有值得信任的质量。为了创建具有值得信任的质量的测试包，与产品开发一样，一些测试阶段也是很重要的。图10-2扩展了图10-1，引入了产品和自动测试包的测试阶段。第十九页，共四十三页，2022年，8月28日6.6单元测试环境桩模块3﹨﹨﹨﹨﹨﹨产品需求产品策划产品设计自动测试需求自动测试策划自动测试编码图10-2W字模型—自动测试周期包含的阶段测试设计测试包的测试设计自动测试设计测试策划测试需求测试包测试需求测试包测试计划产品编码产品测试就绪测试包就绪测试包的测试产品测试执行﹨﹨﹨∕∕∕∕∕∕￣￣－－∕∣第二十页，共四十三页，2022年，8月28日产品和自动测试开发的每个阶段可以执行一组活动，具体包括四项。产品在需求阶段采集开发需求时，同时完成针对测试产品的测试需求、针对自动测试开发的需求和针对自动测试的需求。类似地，在策划和设计阶段也可以执行一组活动，具体也包括四项。针对产品和自动测试的编码构成这种W字模型的编码阶段，这个阶段要交付产品和测试包。产品和自动测试就像铁路的两条钢轨，沿同一方向并行铺开，并具有类似的预期。测试包构成自动测试的一种可交付产品。此外，测试框架也可看作自动测试的一种可交付产品，上一段讨论的测试阶段只针对测试包，因为测试包需要彻底测试，以便用于产品测试。在产品和自动测试中引入测试活动后，生命周期模型图中就包含了并行的两组开发活动和并行的两组测试活动。把这些活动合在一起就构成W字模型。因此，对于包含自动测试的产品开发，遵循W字模型，既保证产品的质量，又保证所开发的测试包达到预期的质量要求，是一种很好的选择。第二十一页，共四十三页，2022年，8月28日 在讨论W字模型时，不能将其解释为出现在特定阶段内的所有活动都应该同时开始和结束。例如，图10-2中的“设计”、“测试设计”、“自动测试设计”和“针对测试包的测试设计都出现在同一个阶段(在图中并排给出)。针对产品和自动测试的这些活动可以在不同时间开始和结束。W字模型只是保证活动的流程，并没有限定起止时间。产品开发和自动测试可以有独立的进度计划，并作为两个不同的项目进行处理。 不需要同时开始和结束的另一个理由是，在很多公司中，要由同一个测试团队测试产品和开发测试包。在这种情况下，显然进度是不同的，活动的起止时间取决于由可用的资源和其他依赖关系决定的项目进度。 对于公司内有专门的自动测试团队的情况，自动测试进度可以独立于产品的发布。每次产品发布对应一些(经过测试的)可交付产品。这样，可以使用最新开发的测试包测试产品的当前发布版本。第二十二页，共四十三页，2022年，8月28日10.2.2自动测试的成本

成功开展自动化测试必须考虑自动测试的成本问题。成本包括测试人员、测试设备、测试工具等。第二十三页，共四十三页，2022年，8月28日（1）应该能抽出专职的测试人员进行自动测试脚本的开发，并且抽调的测试人员不会对已有的手工测试人员造成影响，需要保证自动测试的开展不会影响到手工测试的正常进行。（2）自动测试可能需要额外的测试设备，例如，测试执行的机器、文件服务器、数据库等。应该能为自动测试准备专门的测试设备。第二十四页，共四十三页，2022年，8月28日（3）有引入测试工具或开发测试工具的成本预算。缺乏工具的自动测试是不可能实现的。在上马一个项目的自动测试之前应该进行测试工具的引入准备、开展测试工具的培训工作开展等。（4）某些项目选用了很多第三方控件或自定义的控件，而这些控件的可测试性非常差，那么对这个项目进行自动测试的成本会非常高，不适宜进行自动测试。第二十五页，共四十三页，2022年，8月28日10.2.3合理选择自动测试的导入时机

自动测试只有在多次运行后，才能体现出自动化的优势，只有不断地运行自动测试，才能有效预防缺陷，减轻测试人员手工的回归测试的工作量。如果一个项目是短期的，并且是一次性的项目，则不适合开展自动测试，因为这种项目得不到自动测试的应有效果和价值体现。另外，不宜在一个进度非常紧迫的项且中开展自动测试。有些项目经理期待在一个进度严重拖延的项目中引入自动测试来解决测试的效率问题，结果适得其反。这是因为，自动测试需要测试人员投入测试脚本的开发，同时，需要开发人员的配合，提供更好的可测试的程序，还有可能需要对被测试的软件进行改造，以适应自动测试的基本要求。如果在一个已经处于进度拖延状态的项目中开展自动测试，则很可能带来反效果。第二十六页，共四十三页，2022年，8月28日过早的自动化会带来维护成本的增加，因为早期的程序界面一般不够稳定，处于频繁更改的状态，这时候进行自动测试往往得不偿失，疲于应付“动荡”的界面。那么，什么时候开始自动测试项目呢？自动测试不应该在界面尚未稳定的时候开始，而是需要适当的计划和准备工作。在界面雏形时期，可以基于界面原型提供的控件来尝试自动测试工具的适用性，因为有些控件是自动测试工具不能识别和测试的。这时候，就要考虑工具的选择问题。在开发人员着手开发一些核心的代码时，可能会同时开发出一些核心可重用的控件，而且是那种自定义的个性化控件，那么就需要在这个阶段取到这些控件，并且尝试使用自动化工具来测试这些控件。如果发现有不适用的地方，则要考虑让开发人员重新设计控件，或者提供更多的测试接口。第二十七页，共四十三页，2022年，8月28日10.2.4自动测试的人员要求

另外，自动测试工程师与手工测试的工程师一样，需要具备设计测试用例的基本方法和能力，具备软件涉及的基本业务的理解能力。而且，应该有把测试用例转换成自动测试用例的能力。了解各种编程语言、编程工具以及各种标准控件、第三方控件，则会对自动测试脚本的编写大有裨益。自动测试工程师应该具备一定的自动测试基础，包括自动测试工具的基础、自动测试脚本的开发基础知识等；还需要了解各种测试脚本的编写和设计方法，知道在什么时候选取怎样的测试脚本开发方式，知道如何维护测试脚本；需要具备一定的编程技巧，熟悉某些测试脚本语言的基本语法和使用方法。第二十八页，共四十三页，2022年，8月28日10.3自动测试的方案选择

在选择自动测试方案之前我们先要确定自动化的对象和范围，然后决定采用什么样的自动测试方案，采用什么样的指导测试脚本开发方法。第二十九页，共四十三页，2022年，8月28日

10.3.1确定自动化的对象和范围

在产品开发过程中，需求的变更是很常见的。对于这种情况，要自动化的对象是很容易确定的。自动化应该考虑需求不变或没有变更的部分。需求变更一般会影响场景和新特性，不会影响产品的基本功能。在自动化时，要首先考虑产品的这类基本功能，以便用做“回归测试”和“冒烟测试”的基础

。第三十页，共四十三页，2022年，8月28日

有些类型的测试本身自动进行自动化。例如：压力、可靠性、可伸缩性和性能测试这些类型的测试要求在大量不同的计算机上以一定的持续时间运行测试用例，比如48小时等。让数百个用户天天使用产品简直就是不可能的，他们既不愿意承担重复性工作，也不可能找到那么多有所需技能的人群。属于这些类型测试的测试用例是自动化的第一候选者。回归测试是重复性的。这些测试用例在产品开发各个阶段要执行多次。由于这些测试用例具有重复性，因此自动化从长远看会显著节省时间和工作量。此外，正如本章已经提到过的，所节省的时间可以有效地用于即兴测试和其他更具创造性的测试。功能测试这类测试可能需要复杂的设置，因此可能需要当前还没有普遍具备的特殊技能。利用专家的技能一次性自动化这些测试用例，使技能不那么高的员工也可以马上运行这些测试用例。第三十一页，共四十三页，2022年，8月28日在产品开发场景中，很多测试需要重复，如果考虑了定期增强和维护发布版本，好的产品会有很长的生命期。这就提供了自动化测试用例在发布周期内多次执行的机会。根据一般经验，如果测试用例在不久的将来，比方说一年内需要执行至少10次，如果自动化工作量不超过执行这些测试用例的10倍，那么就可以考虑自动化这些测试用例。当然，这只是根据经验，具体选择哪些测试用例还有很多因素需要考虑，例如是否具备所需的技能、在强大的发布日期压力下是否有设计自动化测试脚本的时间、工具的成本、是否有所需的支持等。第三十二页，共四十三页，2022年，8月28日作为自动化范围的总结，就是要选择自动化那些能够以最少的时间延迟换得最大投回人报的工作。在开始自动化前，需要花很大的精力取得管理层的承诺。自动化一般要耗费大量工作量，也并非一次性活动。自动化的测试用例还需要维护，直到产品退出市场。由于开发和维护自动化工具需要大量的工作量，因此取得管理层的承诺是一项很重要的活动。由于自动化在很长时间内都需要投入，因此管理层的批准是按阶段按部分进行的。所以，自动化工作应该集中于已经存在管理层承诺的区域。投入回报也是需要认真考虑的一个方面。自动化工作量估计要向管理层提供预期投入回报的明确结论。在启动自动化时，关注点应该放在好的排列组合区域上。这使自动化能够用较少的代码覆盖较多的测试用例。另外，自动化应该首先考虑需要较短时间，易于自动化的测试用例。有些测试用例没有能够预先确定的预期结果，这类测试用例需要很长时间自动化，应该放在自动化的后期阶段。这可以满足管理层寻求自动化快速投入回报的要求。

第三十三页，共四十三页，2022年，8月28日

为了符合“重要事情优先做”的原则，重要的是要首先自动化产品的关键和基本功能。为此，所有测试用例都要根据客户预期分为高、中、低优先级，自动化要从高优先级的测试用例入手，然后覆盖中、低优先级需求的测试用例。第三十四页，共四十三页，2022年，8月28日10.3.2选择自动测试的方案和脚本编写方法

采用什么样的自动化测试方案，需要考虑以下几个方面的因素：●项目的影响：自动化测试能否对项目进度、覆盖率、风险有积极的作用，或者让开发更敏捷？●复杂度：自动化是否容易实现（包括数据和其他环境的影响）？●时间：自动化测试的实现需要多少时间？●早期需求和代码的稳定性：需求或早期的代码是否能证明是在一定范围内变化的？●维护工作量：代码是否能长期保持相对稳定？功能特性是否会进化？●覆盖率：自动化测试能否覆盖程序的关键特性和功能？●资源：测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动测试？●自动测试执行：负责执行自动测试的小组是否拥有足够的技能和时间去运行自动测试？第三十五页，共四十三页，2022年，8月28日自动测试项目也像普通的软件开发项目—样有编码阶段。自动测试的编码阶段主要是通过编写测试脚本实现所设计的自动测试用例。自动功能测试的脚本开发主要有以下几种方法:（1）录制与回放使用简单的录制回放的方法，测试工程师使用这种方法来自动地测试系统的流程或某些系统测试用例。它可能包含某些多余的，有时候并不需要的函数脚本，但录制与回放可避免重复执行测试用例。市场上几乎所有的测试工具都具有录制与回放特性。测试工程师录制键盘字符或鼠标点击的行动序列，并在以后按照录制的顺序回放这些所录制的脚本。由于所录制的脚本可以回放很多次，所以可以减少测试工作。除了可以避免重复工作，录制和保存脚本也很简单。但是这一代工具也有一些缺点。脚本中可能包含一些硬编码的取值，因此很难执行一般类型的测试。例如，如果报告必须使用当前的日期和时间，那么就很难使用已录制的脚本。错误条件的处理留给测试人员，这样回放脚本就可能需要很多人工介入来检测和更正错误条件。当应用程序变更后，所有脚本都必须重新录制，因此增加了测试维护的成本。所以，如果频繁出现变更，或没有多少机会重用或重新运行测试用例，那么这一代测试自动化工具的有效性就可能很低。6.8单元测试的过程第三十六页，共四十三页，2022年，8月28日（2）结构化结构化脚本编写方法在脚本中使用结构控制。结构控制让测试人员可以控制测试脚本，或测试用例的流程。在脚本中，典型的结构控制是使用“if-else”，“switch”，“for”，“while”等条件状态语句来帮助实现判定，实现某些循环任务，调用其他覆盖普遍功能的函数。下面是结构化脚本编写方法的特点:●测试用例在脚本中定义。●编程的成本要比录制回放编写方法略高一点。●需要测试员的调整编码技巧。●需要某种程度上的计划、设计。●测试数据也是在脚本中被硬编码。●因为相对稳定一点，所以需要相对少的脚本维护，维护成本比录制回放脚本编写方法的要相对低。●除了编程知识外，还需要一些脚本语言的知识。第三十七页，共四十三页，2022年，8月28日（3）数据驱动数据驱动脚本编写方法把数据从脚本分离出去，存储在外部的文件中。这样，脚本就只是包含编程代码了。这在测试运行时要改变数据的情况下是需要的。这样，脚本在测试数据改变时也不需要修改代码。有时候，测试的期待结果值也可以跟测试输入数据一起存储在数据文件中。下面是数据驱动脚本编写方法的特点:●脚本是以结构化的方式编程的。●测试用例由测试数据或脚本定义。●由于脚本参数化和编程成本，这种方法的开发成本跟结构化脚本编写方法比较要相对高。●需要测试员较高的代码调整方面的编程技巧。●需要更多的计划和设计。●数据独立存储在数据表或外部文件。●脚本维护成本较低。●推荐在需要测试正反数据的时候使用。第三十八页，共四十三页，2022年，8月28日（4）关键字驱动关键字驱动脚本编写方法把检查点和执行操作的控制都维护在外部数据文件。因此，测试数据和测试的操作序列控制都是在外部文件中设计好的，除了常规的脚本外，还需要额外的库来翻译数据。关键字驱动脚本编写方法是数据驱动测试方法的扩展，其特点如下:●综合了数据驱动脚本编写方法、结构化脚本编写方法。●测试用例由数据定义。●开发成本高，因为需要更多的测试计划和设计、开发方面的投入。●要求测试人员有很强的编程能力。●最初的计划和设计、管理成本会比较高。●数据在外部文件存储。●维