第六章 软件测试自动化 HLJU Software Testing

[本章要点] 1.自动化测试应考虑的各种因素； 2.自动化测试和手工测试中涉及的问题以及二者的 优缺点； 3.应用自动化测试工具的目的； 4.自动化测试工具的分类和选择方法； 5.自动化测试过程实例及自动化测试经验。 HLJU Software Testing

[本章目标] 2.掌握自动化测试和手工测试的优缺点，知道如何正确选择两种软件测试策略。 1.了解自动化测试应考虑的各种因素以及如何衡量自动化测试成本。 2.掌握自动化测试和手工测试的优缺点，知道如何正确选择两种软件测试策略。 3.了解测试工具的分类、使用目的及其选择，了解几种常用的测试工具。 4.了解自动化测试的过程。 HLJU Software Testing

当对产品的一些特征来设计一系列测试时，对每一个测试都需要决定是否对其进行自动化测试。 1.进行自动化测试的适当时机 如何做出一个合理的决定，假设如下： 1．拥有稳定的自动化测试技术支持。 2．两种极端的可能性：一种就是无需人工干预的完全自动化测试，另一种就是只运行一次就废弃的人工测试。 3．自动化测试和手工测试都可行（但事实并非如此）。 4．测试是通过外部接口来完成的（黑盒测试）。 5．不要求必须进行自动化测试。 6．测试已经设计好之后，再决定是否进行自动化测试。 7．有一定的时间用于完成测试，并且在这段时间里完全有可能把测试做好。 一律用自动化测试就好? 要考虑经济性、有效性，适当的进行自动化测试。 当对产品的一些特征来设计一系列测试时，对每一个测试都需要决定是否对其进行自动化测试。 HLJU Software Testing

经济学角度成本 1.进行自动化测试的适当时机 在决定是否要进行自动化测试之前，通常需要考虑如下几个主要问题： 同手工测试相比，只运行一次的自动化测试要多付出多少代价？ 自动化测试的生命周期是有限的。那么，这类测试是否迟早要终止？什么事件将会导致测试中止？ 在整个生命周期内，这次测试能捕获到新bug的可能性会有多大？这些难以预计的收益能够使自动化测试的成本得到补偿吗？ 经济学角度成本 HLJU Software Testing

2. 自动化测试的成本 创建一次自动化的测试所花费的时间要比一次手工测试所花费的时间多得多。 测试成本因产品的架构以及自动化测试的方式不同而异。介绍如下几种(费用由高至低)： <1> 通过图形用户界面来测试产品； <2> 使用GUI捕捉/回放工具来跟踪测试与产品之间的交互，同时建立脚本； <3> 测试的是一个编译器； 测试成本还要考虑测试时间、Bug的多少等问题。 HLJU Software Testing

3.自动化测试的生命周期 测试的生命周期如下图7-1所示： HLJU Software Testing

回归测试包括几部分？？？ 回归测试？？？ 两部分 函数本身的测试、其他代码的测试。 是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 两部分 函数本身的测试、其他代码的测试。 自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 一、对被修改的函数重新测试。 如果函数的设计功能没有变化，直接运行函数测试就可以了。 如果修改了设计功能，则要根据增减的功能点，增加或删除测试用例。另外，还要完成白盒覆盖。 二、函数代码的修改 可能导致调用该函数的代码产生错误，所以需要测试其他代码。如果函数是私有函数并且未涉及到全局变量，应运行类测试，否则应运行工程测试。在函数列表中选择类测试或工程测试，编译运行测试工程，即可执行对其他代码的回归测试。 HLJU Software Testing

3.自动化测试的生命周期 在决定是否进行自动化测试之前，必须首先估计一下，产品的代码变动在什么范围内，测试仍能存活。如果要求代码不能有太多变动，要做的测试最好是非常善于捕获bug的测试；而且要求估计生命周期。 HLJU Software Testing

中介代码 3.自动化测试的生命周期 （intervening code） 一、中介代码的变动对测试周期的影响 介于需要被测试的代码和测试之间的代码称作中介代码 一、中介代码的变动对测试周期的影响 中介代码是使测试中止的一个主要原因。 例如，用户界面以前要求输入电话号码，现在变为提供一个可视的电话键盘，使用鼠标点击数字来模拟使用真实的电话。虽然通过两种界面向被测试的代码传递的都是相同的数据，但是因为没有了提供输入电话号码的地方，自动化测试可能就会中止。 HLJU Software Testing

3.自动化测试的生命周期 二、被测试代码的改变对测试周期的影响 为了使测试免受中介代码变化的影响，应该从以下几个方面考虑： 1、评估一下中介代码的改变会不会影响测试。如果绝不会影响到测试，使用自动测试就能节省大量的时间。 2、如果中介代码的变化会影响到测试，就必须考虑一下使用测试库函数能够使测试不受影响的可能性会有多大。 3、假如没有测试函数库——如果是在捕捉/回放的模式下使用GUI测试自动化工具——不要指望测试会不受影响。 二、被测试代码的改变对测试周期的影响 需要判断一下被测试的代码的稳定性。 首先，需要重点考虑代码的行为。 其次，考虑功能的增加会不会影响测试。 HLJU Software Testing

4.自动化测试的价值 考虑哪些问题： 2.测试通常是用来测试功能代码。支撑代码对于测试者来说通常是不可见的。 1.测试代码的结构要清晰。 2.测试通常是用来测试功能代码。支撑代码对于测试者来说通常是不可见的。 3.但功能代码的改变通常会改变代码的行为。因此，极有可能会使测试中止，而不是报告bug。 4.测试的价值主要在于支撑代码改变以后仍能捕获bug的能力。 5.如果我们一点也不了解支撑代码，无法知道测试是否能捕获bug?如何估计测试是否有助于我们捕获bug? 6.可以认为与被测试的代码进行交互的其他代码大多数是支撑代码，支撑代码的变化也会产生自动测试所能捕获的bug。 进行自动化测试要解决的问题就是： 自动化测试的价值必须要超过所有因此而放弃的手工测试的价值。 HLJU Software Testing

4.自动化测试的价值 注意： 高价值的测试不可能是特征驱动测试而是任务驱动测试。 HLJU Software Testing

例子：被测试的是一段处理从银行账户里提款的代码。 把被测试的代码分成两部分： 一、分析被测试代码的结构 例子：被测试的是一段处理从银行账户里提款的代码。 把被测试的代码分成两部分： ①功能代码（feature code），它直接实现被测试代码所完成的功能。测试会专门对其进行调用。功能代码（support code）可以完成用户所进行的操作（通过使用用户界面的关联代码）。 ②支撑代码(support code)，它起到支持功能代码 （support code）的作用。测试代码会对其进行调用，但并没有针对这些代码的特殊测试。 HLJU Software Testing

在这里，支撑代码位于水平线以下。功能代码位于水平线以上，共有五种不同的功能，我们只针对其中的两个功能进行测试。 图1 功能代码和支撑代码示意图 在这里，支撑代码位于水平线以下。功能代码位于水平线以上，共有五种不同的功能，我们只针对其中的两个功能进行测试。 HLJU Software Testing

1．就给定的结构而言，代码的变化将会产生什么样的影响？ 2．什么样的变化具有测试价值？ 假设一些功能代码发生了变化，如图2中灰色图形所示： 二、被测试代码的变化所带来的影响 主要考虑这样一些问题： 1．就给定的结构而言，代码的变化将会产生什么样的影响？ 2．什么样的变化具有测试价值？ 假设一些功能代码发生了变化，如图2中灰色图形所示： 这种变化极有可能会导致调用功能代码的测试中止。因此，如果希望使用自动化测试的方法在发生变化的功能代码（feature code）中找到bug，就必须终止原有测试。如果测试的成本很高，这样做是很不经济的。 HLJU Software Testing

为了使原有的测试行为仍然能够保留，通常采用的做法是更改支撑代码（support code）以便能够支持其他功能代码的变动。请看图3： 图2 图3 HLJU Software Testing

例子 三、支撑代码的变化对测试的影响 主要从以下两方面来考虑这个问题： 代码的变化有多少？这些变化会引入多少bug? 假设我正在测试一个产品，测试已经完成一半。产品已经实现了主要的功能，但是还需要增加一些辅助功能。现在我要对这些主要的功能进行测试。 测试过程中，在同如下人员进行交流的过程中提出的问题如下： HLJU Software Testing

在新版本中，新增的功能是一个十分重要的部分吗？如果是这样的话，由于市场竞争激烈，图形用户界面有可能改变吗？以前，用户界面改动有多大？ 程序员： 这些辅助的功能是否有可能需要改变产品的支撑代码？程序员有可能精心设计了支撑代码，并且考虑坚持使用可视化的用户界面来完善各种功能。如果是这样的话，那么自动化测试的价值就不大。 但是因为要急于完成测试，程序员也可能知道程序的支撑代码的结构不会一成不变的。由于大部分工作将会重复进行，所以可能会特别需要进行自动化测试。或者程序员也不知道支撑代码是否要改变。 项目经理： 在新版本中，新增的功能是一个十分重要的部分吗？如果是这样的话，由于市场竞争激烈，图形用户界面有可能改变吗？以前，用户界面改动有多大？ HLJU Software Testing

如何应对产品的变化？什么样的变化会使测试中止？对于新增加功能的测试，遇到这些情况的几率会有多大？ 为什么会希望今后的改动越少越好？这些变化是为了增加功能，还是用来代替现有的功能？我们需要切实的估计一下变动的可能性，因为任何变化都可能会提高自动化测试的成本，缩短测试的生命周期。 了解并熟悉测试工具的人员： 如何应对产品的变化？什么样的变化会使测试中止？对于新增加功能的测试，遇到这些情况的几率会有多大？ 一次自动化测试所花费的成本相当于几次手工测试，并且要特别重视测试价值的大小和生命周期的长短，这样做可能不对。但这都是为了避免犯下灾难性的错误，如果自动化测试的成本很高而生命周期很短，我们最好使用手工测试。 HLJU Software Testing

但是这并不意味着不能使用自动化测试，而是要判断与衡量。 在测试中，要不断跟踪bug报告并加以修改，保留所有和测试相关的文档。从这些资料当中，我们常常能够发现更为重要的信息。如： •什么样的因素与产生的bug无关？ •哪里存在bug？ •代码行为的稳定性如何？ 经过一段时间，要进行自动化测试还是手工测试的想法就会逐渐成熟，可能会形成一个更大的测试套。 HLJU Software Testing

5. 另外一些需要考虑的问题 1.手工测试有时候会发现一些自动化测试所不能发现的问题。 2.尽管人善于发现问题，但很容易疲劳。并且不能对结果做出精确的分析。 3.由于我们不能保证每次手工输入的数据完全相同。因此，重复的手工测试多少会有些不同，那么就有可能捕获支撑代码中的bug。 4.要求对配置测试进行更多的自动化测试。 5.如果在进行第一次测试的时候就捕获了bug。表明这部分程序代码将来有可能发生变化，要进行更多的自动化测试 。 HLJU Software Testing

7. 使用手工测试的时候捕获了bug, 但又不能再现bug时会使人很沮丧。 6. 如果自动化测试的技术支持足够强大，开发人员很容易就能做回归测试，自动化测试也需要比手工测试快得多，但是并不是所有的公司都具有这样的自动化测试技术支持水平。 7. 使用手工测试的时候捕获了bug, 但又不能再现bug时会使人很沮丧。 8. 程序更改之后，测试人员应该对其进行检查。 9. 因为进行自动化测试的创建要花费一些时间，因此把第一个bug提交给程序员所花费的时间要比手工测试花费的时间长。 10.把测试设计的有利于进行自动化测试，但不善于捕获bug。 11.如果产品的行为改变了，自动化测试就有可能会报告一些不真实的bug。 HLJU Software Testing

12. 如果自动化测试创建的十分好，能够有序的运行，并且可以改变测试运行的顺序。 13. 我们可以在产品需要测试之前先设计测试。 14. 也许自动化测试的价值直到下一个新版本发布之后才能体现出来。 HLJU Software Testing

与手工测试比较 自动化测试并不能完全取代手工测试，二者各有优缺点。 这个测试案例中包括1750个测试用例和700多个错误。 测试步骤 手工 通过使用工具改善测试的百分比 测试计划的开发 32 40 -25% 测试用例的开发 262 117 55% 测试执行 466 23 95% 测试结果分析 58 50% 错误状态/更正检测 80% 产生报告 96 16 83% 时间总和 1090 277 75% 这个测试案例中包括1750个测试用例和700多个错误。 HLJU Software Testing

随着软件开发过程的进展，测试工作越来越繁重，如果使用手工测试的方法，将很难保证测试工作的进度和质量。 短测试周期中手工测试面临的挑战 迭代式的开发过程已逐渐取代传统的瀑布式开发，成为了目前最流行的软件开发过程。在迭代开发中强调在较短的时间间隔中产生多个可执行、可测试的软件版本，这就意味着测试人员也必须为每次迭代产生的软件系统进行测试。 随着软件开发过程的进展，测试工作越来越繁重，如果使用手工测试的方法，将很难保证测试工作的进度和质量。 HLJU Software Testing

手工测试的问题 手工测试的方法是根本不可能符合软件快速开发的要求的。大公司用自动化测试因为它适合自动化测试的特点和有较高的投资回报率。 哪些情况要用到自动化测试 1、针对产品型项目的测试 2、针对增量式开发、持续集成项目的测试 3、针对能够自动编译、自动发布的系统的测试 4、回归测试 5、需要多次重复、机械性动作的测试 6、需要频繁运行的测试 7、将烦琐的任务转化为自动化测试 HLJU Software Testing

自动化测试的问题 不 能 是否可以完全取代手工测试 哪些情况下不适合使用自动化测试 例如：在下面几种情况下就不适合使用自动化测试。 不 能 例如：在下面几种情况下就不适合使用自动化测试。 <1> 定制型项目（一次性的） <2> 项目周期很短的项目 <3> 涉及业务规则复杂的对象 <4> 关于美观、声音、易用性的测试 <5> 很少运行的测试，如：一个月只运行一次的测试。 <6> 测试的软件不稳定 <7> 涉及物理交互的测试 HLJU Software Testing

自动化测试的优点 1、对程序的新版本运行己有的测试，即回归测试。 2、可以运行更多更频繁的测试。 3、可以进行一些手工测试难以完成或不可能完成的测试。 4、充分地利用资源。 5、测试具有一致性和可重复性。 6、测试具有复用性。 7、缩短软件发布的时间。 8、增强软件的可靠性。 HLJU Software Testing

自动化测试的缺点 2、新缺陷越多，自动化测试失败的几率就越大。 3、工具本身不具有想象力 4、技术问题、组织问题、脚本维护 1、自动化测试不能取代手工测试， 测试主要还是要靠人工的。 2、新缺陷越多，自动化测试失败的几率就越大。 3、工具本身不具有想象力 4、技术问题、组织问题、脚本维护 5、测试工具与其他软件的互操作性 HLJU Software Testing

自动化测试工具的选择和使用 提高测试质量； 减少测试过程中重复的手工劳动，提高测试效率； 实现测试自动化，充分利用测试资源。 1、 应用自动化测试工具的目的 提高测试质量； 减少测试过程中重复的手工劳动，提高测试效率； 实现测试自动化，充分利用测试资源。 HLJU Software Testing

自动化测试工具的选择和使用 2、自动化测试工具的概要介绍 根据软件生命周期中的定义，可以把自动化测试工具分为三大类： 白盒测试工具 黑盒测试工具 测试管理工具这些工具和软件开发过程中相关活动的关系如图4所示： HLJU Software Testing

图4 测试工具与开发过程关系图 HLJU Software Testing

自动化测试工具的选择和使用 一、白盒测试工具 白盒测试工具一般是针对代码进行测试的工具，测试中发现的缺陷可以定位到代码级，根据测试原理的不同，又可以分为静态测试工具和动态测试工具。 1、 静态测试工具 就是不运行测试而直接对代码进行分析的测试。 静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。 HLJU Software Testing

自动化测试工具的选择和使用 2、 动态测试工具 主要采用“插桩”的方式，即向代码生成的可执行文件中插入一些监测代码，运行框架程序，统计程序运行时的数据，可以针对所有类的成员函数进行测试，也可以只针对类的公共接口函数进行测试。 （1）商业性的白盒测试工具，比较有代表性的如：compuware公司的Numega系列工具和ParaSoft的JavaSolution以及C/C++ Solution系列。 （2）非商业性的白盒测试工具，主要以Xunit系列为代表的测试框架工具。 HLJU Software Testing

自动化测试工具的选择和使用 二、黑盒测试工具 黑盒测试工具包括： 功能测试工具 性能测试工具。 黑盒测试工具的代表有 Rational公司的TeamTest、Robot Compuware公司的QACenter， 另外，专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。 HLJU Software Testing

自动化测试工具的选择和使用 三、测试管理工具 测试管理工具用于对测试进行管理。一般而言，测试管理工具主要对软件缺陷、测试计划、测试用例、测试实施进行管理。 *缺陷跟踪工具是管理工具使用最多的*。 测试管理工具的代表有Rational公司的Test Manager、 Compureware公司的TrackRecord等软件。 HLJU Software Testing

自动化测试工具的选择和使用 如何选择缺陷跟踪工具？ 三、测试管理工具 方法如下： 1.使用word、excel等类型的平面文档； 2.自行设计开发一套管理软件； 3.购买商业性的软件； 4.下载一套适合自己的开源软件，自行配置和维护。 HLJU Software Testing

自动化测试工具的选择和使用 四、 其他自动化测试工具 还有一些专用的自动化测试工具针对数据库测试的TestBytes，对应用性能进行优化的EcoScope等工具。 HLJU Software Testing

自动化测试工具的选择和使用 如何选择自动化测试工具？？？ 在考虑选用工具的时候，建议从以下几个方面来权衡和选择： 1、 功能 　1、 功能 　 **除了基本的功能之外，以下的功能需求也可以作为选择自动化测试工具的参考：　 1) 报表功能； 2) 自动化测试工具的集成能力； 3) 操作系统和开发工具的兼容性； 2、价格 3、对自动化测试工具进行评估。主要从以下几点来考虑： <1>在使用了多种工具后对今后要采用的工具进行期盼。 <2>自动化测试工具的实际性能是否和自动化测试工具文档中声明的一致。 〈3〉总结试用自动化测试工具的结果，得出评估报告。 HLJU Software Testing

7.3.4自动化测试工具在测试过程中的应用 4、引入自动化测试工具的目的是使测试自动化 很多引入测试软件的公司并没有能够让测试软件发挥应有的作用，其原因主要有三个方面： 1、没有考虑公司的实际情况，盲目引入自动化测试工具 2、没有形成一个良好的使用自动化测试工具的环境 3、没有进行有效的自动化测试工具的培训 HLJU Software Testing

性能测试实例 1、 LoadRunner 简介 本节列举了一个使用LoadRunner进行的性能测试实例。 LoadRunner® 是一种预测系统行为和性能的负载测试工具。通过模拟成千上万名用户和实施实时性能监测来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。其主要功能如下： 1、轻松创建虚拟用户 2、创建真实的负载 3、定位性能问题 4、分析结果精确定位问题所在 HLJU Software Testing

2、案例分析 该案例仍然是针对电厂两票管理系统的性能测试，电厂工作人员可以使用该管理系统开出工作票和操作票。假设开设100个账号和密码可供100个工作人员同时开出工作票或操作票。要求，每台机器只能由一个用户使用，每个用户只能使用各自不同的账号登录该管理系统，开票结束后，要求把工作票或操作票内容存档，若在规定的时间内没有存档，则系统强制存档。 HLJU Software Testing

现场测试环境： 硬件：100台PC机，一个Web服务器 操作系统：Windows 2000 Server 但是，一般测试部门不可能有100台机器同时进行测试的。所以，使用Loadrunner7.51模拟IP地址，修改脚本来协助测试。但是，为了保证测试结果，建议使用所有可用的机器进行复测，因为有时候测试工具是不可以完全信赖的。 现场测试环境： 硬件：100台PC机，一个Web服务器 操作系统：Windows 2000 Server 测试工具：Loadrunner 8.0 浏览器：IE5.0和IE6.0 测试人员：质控小组4人，执行现场测试 项目小组22人，提供现场环境 技术小组各1人，提供技术支持 HLJU Software Testing

测试要求： 100个用户拥有独立IP地址，不同的用户及密码登录，开票操作完成后各自同时把工作票或操作票内容存档。 测试内容： 100个用户以不同的用户名和密码登录该管理系统。开票完成后，把工作票或操作票内容存档。测试系统是否能正常开票以及正确存档。 测试方案： 1、 完全50台实际的PC机进行现场测试。 （1） 准备工作，并做计划。第一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用IE5.0，第二遍25台使用IE5.0，25台使用IE6.0，第三遍全部使用IE6.0 HLJU Software Testing

（1） 准备工作，并做计划。第一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用IE5 （1） 准备工作，并做计划。第一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用IE5.0，第二遍25台使用IE5.0，25台使用IE6.0，第三遍全部使用IE6.0 （2） At 9：00 ，50个用户同时登录系统 （3） At 9：05 ，50个用户同时提交 （4） 分别记录第一轮测试（三遍）的结果 （5） 第二轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用IE5.0 （6） At 9：15 ，50个用户同时登录系统 （7） At 9：20 ，30个用户同时提交 （8） At 9：25 ，剩余20个用户同时提交 （9） 记录第二轮测试结果 （10） 第三轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用IE6.0 HLJU Software Testing

（11） At 9：15 ，50个用户同时登录系统 （12） At 9：20 ，30个用户同时提交 （13） At 9：25 ，剩余20个用户同时提交 （14） 记录第三轮测试结果 （15） 第四轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用IE5.0，延时提交用户使用IE6.0 （16） At 9：15 ，50个用户同时登录系统 （17） At 9：20 ，30个用户同时提交 （18） At 9：25 ，剩余20个用户同时提交 （19） 记录第四轮测试结果 （20） 第五轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用IE6.0，延时提交用户使用IE5.0 （21） At 9：15 ，50个用户同时登录系统 （22） At 9：20 ，30个用户同时提交 HLJU Software Testing

（23） At 9：25 ，剩余20个用户同时提交 （24） 记录第五轮测试结果 （25） 第六轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户其中20个使用IE5.0，10个使用IE6.0，延时提交用户使用IE5.0 （26） At 9：15 ，50个用户同时登录系统 （27） At 9：20 ，30个用户同时提交 （28） At 9：25 ，剩余20个用户同时提交 （29） 记录第六轮测试结果 （30） 第七轮测试准备工作，设定25个用户开出的工作票或操作票内容同时提交，另外25个用户分两次分别延时5、15分钟提交 （31） At 9：35 ，50个用户同时登录系统 HLJU Software Testing

（41） 第九轮测试准备工作，设定其中25个用户开出的工作票或操作票内容同时提交，15个用户延时5分钟提交，其余用户由系统强行提交 （32） At 9：40 ，25个用户同时提交 （33） At 9：45 ，剩余的其中15个用户同时提交 （34） At 9：55 ，其他10个用户同时提交 （35） 记录第七轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试 （36） 第八轮测试准备工作，设定其中25个用户开出的工作票或操作票内容不提交，由系统强行提交 （37） At 10：10 ，50个用户同时登录系统 （38） At 10：15 ，25个用户同时提交 （39） 其余用户的内容由系统强行提交 （40） 记录第八轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试 （41） 第九轮测试准备工作，设定其中25个用户开出的工作票或操作票内容同时提交，15个用户延时5分钟提交，其余用户由系统强行提交 HLJU Software Testing

2、模拟50个用户进行测试。其中，18台是PC机，另外32台机器的IP地址是Loadrunner模拟出来的。 （42） At 10：25 ，50个用户同时登录系统 （43） At 10：30 ，25个用户同时提交 （44） At 10：35 ，剩余的其中15个用户同时提交 （45） 剩余10个用户系统强制提交 （46） 记录第九轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试 2、模拟50个用户进行测试。其中，18台是PC机，另外32台机器的IP地址是Loadrunner模拟出来的。 （1） 在18台实际的PC机中抽取其中一台虚拟32个IP地址，包括自身的IP地址，这台机器上共33个IP地址，这33个IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余17台实际的PC机分别由17个人操作，另外一台机器由一位质控小组人员操作 HLJU Software Testing

（3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 3、模拟50个用户进行测试。其中，10台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。 （1） 在10台实际的PC机中抽取其中一台虚拟40个IP地址，包括自身的IP地址，该机器上共41个IP地址，这41个IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余9台实际的PC机分别由9个人操作，另外一台机器由一位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 4、模拟75个用户进行测试。其中，35台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。 HLJU Software Testing

（1） 在35台实际的PC机中抽取其中三台分别虚拟13、13、14个IP地址，这40个IP地址只能全部使用IE5. 0或者全部使用IE6 （1） 在35台实际的PC机中抽取其中三台分别虚拟13、13、14个IP地址，这40个IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余32台实际的PC机分别由32个人操作，另外三台机器由两位质控小组人员操作 （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 5、模拟100台用户进行测试。其中，40台是PC机，另外60台机器的IP地址是用分别用四台实际的PC机模拟出来的。记录测试结果。 （1） 在40台实际的PC机中抽取其中四台分别虚拟15个IP地址，这64个IP地址只能全部使用IE5.0或者全部使用IE6.0 （2） 其余36台实际的PC机分别由36个人操作，另外四台机器由四位质控小组人员操作 HLJU Software Testing

7、 为了保证结果的正确性，完全100台实际的PC机进行现场测试。过程参见1 测试过程： （3） 对于异常情况，延时提交和强制提交全部由实际的机器来模拟 （4） 其余过程参见1 6、 对5中所述情况重复测试两次。 7、 为了保证结果的正确性，完全100台实际的PC机进行现场测试。过程参见1 测试过程： 1、 一台PC机上创建15个虚拟的IP地址。首先，启动IP Wizard，如下：开始程序－>Loadrunner－>Tools－>IP Wizard 点击“Add”，添加你计划虚拟的IP地址。但是注意不能添加已经被占用的IP地址。 2、 启动Virtual User Generator，并录制脚本，由于100个用户的账号和密码各不相同，所以，要修改脚本，设置参数。 HLJU Software Testing

LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，都可以观察到应用系统的运行性能。 3、 启动Loadrunner Controller，先将刚才保存的脚本添加进来。然后点击“Scenario”菜单，激活其中的“Enable IP Spoofer”。 4、点击屏幕右方的“Generators”，添加已经建立的IP，然后connect建立连接。 5、对连接起来的不同用户（IP地址）分配不同的脚本，在Controller中的“design”中，点击“Load Generators”其中，每个脚本有一个用户执行。 6、 执行Scenario。 LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，都可以观察到应用系统的运行性能。 当测试运行结束后，LoadRunner 收集汇总所有的测试数据，提供高级分析和汇报数据，这样便能迅速查找到性能问题并追溯原由。 HLJU Software Testing

1.测试个案（test case ，或称为测试用例）的生成 经验总结 1.测试个案（test case ，或称为测试用例）的生成 2.科学合理的安排和控制测试的执行 3.测试结果与标准输出的对比 4.不吻合的测试结果的分析、分类、记录和通报 5.总体测试状况的统计、报表的产生 6.自动测试与开发中产品每日构建的配合 7.图形界面的测试 HLJU Software Testing

2．应该针对特殊的目的来设计测试，然后针对一个或多个功能的重要方面进行测试。 本章小结 1．由于进行自动化测试，我们要放弃一些手工测试，所以在衡量自动化测试的成本时要考虑到我们因此放弃多少手工测试，少捕获了多少bug。 2．应该针对特殊的目的来设计测试，然后针对一个或多个功能的重要方面进行测试。 3．要正确估量自动化测试脚本开发和维护工作量，将关键而有许多次执行的测试用例自动化。 4．一般来说，手工测试可以取代任何类型、功能的自动测试，但在多用户并发等情况下，手工测试是很难实现的，这时自动测试就发挥作用了。另外，使用自动测试工具可以减少很多重复的手工劳动，精确复制缺陷，提高测试覆盖率，从而提高产品质量。 HLJU Software Testing

5．应该根据企业的特点来选择测试工具。首先，对商业化的测试工具进行评估；然后，在公司的实际项目中试用，通过这种方法来检验工具在特定的环境下是否具有供应商所宣传的特性，同时考察代理商的技术支持水准，这对将来工具的大规模应用非常重要。 6．虽然测试工具的应用可以提高测试的质量、测试的效率，但要成功实施自动化测试，测试工作就必须遵从系统的、结构化的和循序渐进的观念来进行。 HLJU Software Testing

习 题 1、自动化软件测试应该考虑哪些因素？ 2、简述自动化测试和手工测试的优缺点。 习 题 1、自动化软件测试应该考虑哪些因素？ 2、简述自动化测试和手工测试的优缺点。 3、自动化测试工具大致可以分为几类，并举例说明几种与之相应的测试工具？ 4、简述应用自动化测试工具的目的？ 5、选择测试工具时主要应该从哪几个方面进行考虑？ 6、使用LoadRunner对本校网站进行压力测试，判断此网站能否在同一时间相应大量用户，得出测试结果。 HLJU Software Testing