软件测试实用教程-方法与实践（第2版）课件ch11测试应用案例实践

第11章测试应用案例实践高等学校计算机类系列教材软件测试实用教程——方法与实践01保险金案例实践自动化测试设计1.脚本设计原则对于某个函数的测试实施来说，主要需考虑的问题是：(1)该函数是否存在上下级调用关系，若被上层函数所调用，或调用其他下层函数，则需为存在直接调用关系的那些函数另外开发驱动函数或桩函数，以实现对本函数的测试；(2)是否需以自动化方式来测试该函数，若需要，则应进一步考虑自动化测试覆盖的范围、支持自动化测试脚本的开发工具、测试脚本的存储等问题。同为函数的自动化测试，保险金问题的测试需求与1.5节捉虫实践4中提到的测试需求完全一致，不再赘述。所不同的是，本节使用Java语言开发，且基于Eclipse和Ant工具来完成保险金问题的自动化测试。自动化测试设计2.测试代码说明测试代码主要包括两个文件，其中InsuranceCalculatorTestjava用于定义测试驱动类，而XMLToXLSjava用于定义XML文件向Excel文件输出报告的过程。该测试脚本的基本思想是从一个名为“测试报告模板.xls”的Excel文件中读取全部测试用例数据，测试执行后将结果保存在report目录下形如“测试报告-20120604-211255.xls”的Excel文件中。受篇幅所限，详细代码见教学资源包。测试报告结果文件包括4个工作薄，其中，第一个工作薄为“概要”，说明测试的统计信息(如图11.1所示)，测试人、测试时间等这些具体的测试统计信息在测试执行之前为空。自动化测试设计第二个工作薄为“边界值”，用于提供基于边界的测试用例的测试结果，部分内容如图11.2所示，分别将通过和失败的部分测试用例显示在图11.2(a)、(b)中，图中测试结果、出错信息和测试用时在测试执行后才由系统自动填入对应数据。自动化测试设计

第3个工作薄为“决策表”，提供基于决策表的测试用例的测试结果，内容见图11.3。自动化测试设计

第4个工作薄为“无效等价类”，存储针对无效等价类的用例测试结果，部分内容见图11.4。JUnit概述1.JUnit自动化测试框架JUnit采用Composite设计模式构建自动化测试框架，如图11.5所示。该模式下，TestSuite(测试包类)可以容纳任何派生自Test(测试类)的对象，当调用TestSuite对象的run()方法时，将遍历自己所容纳的所有对象，分别调用它们的run方法，并分析返回的结果。JUnit概述2.JUnit主要的包和类的说明JUnit共有7个包，核心包是JUnit.framework和JUnitrunner，分别负责整个测试对象的构建和测试驱动。JUnit框架的骨干可表示为：TestCase+TestSuite+BaseTestRunner=TestResult。JUnit包含7个核心类，简要说明如下：(1)Test(测试)类是一个接口类，用来测试和收集测试结果，通过Test接口建立TestCase与TestSuite之间的关联。(2)TestCase(测试用例)类是Test接口的抽象实现，通过对该类继承来开发自己的测试驱动。一般地，一个TestCase的派生类实现对一个类的测试，可包含若干测试用例。也可以根据本项目和团队需要来开发自己的TestCase测试驱动基类，以便于代码重用。JUnit概述(3)TestSuite(测试包)类用于聚合多个测试用例。(4)TestRunner(测试运行)类是用于启动测试的用户界面，从而执行测试。(5)TestResult(测试结果)类用于收集TestCase的执行结果，将结果分为Failure和Errors两种异常，并转发给TestListener处理，其中由Assert触发的Failures是由测试用例抛出的可预测异常，当用例执行结果不同于期望值时抛出，表示用例失败；Errors是因测试驱动程序本身存在语法等缺陷而抛出的不可预测异常，与测试用例无关。我们可开发自己的TestResult类。(6)Assert(断言)类用于比较实际值与预期值，判断二者是否一致，进而确定用例是否通过。Assert类可对普通数据类型、字符串等多种情况实现自动检验。(7)TestListener(测试监听)类用于处理测试结果和提取测试驱动过程的工作特征，当测试中产生事件(开始、结束、错误、失败)时，会通知TestListener。JUnit概述3.JUnit3与JUnit4的区别目前JUnit已经发展到JUnit4.9版本，JUnit4是配合JDK1.5版本的，因此，JUnit4以上版本较JUni3.x改动较大。JUnit3强制继承TestCase类，以函数命名规则(规定函数名应形如“testXX”)来判断是否是测试方法；而JUnit4使用元数据。JUnit3和JUnit4的简单对比如下：(1)定位测试JUnit3使用命名约定和反射来定位测试。JUnit4中的测试是由@Test注释来识别的。(2)SetUp和TearDown方法JUnit3在运行(testrunner)每个测试之前自动调用setUp()方法，完成初始化字段、打开日志记录、重置环境变量等任务：JUnit4中不需强制使用setUp()方法，只需用@Before注释指示即可，甚至可用其注释多个方法，使之均在每个测试之前运行。类似地，tearDown方法替换为用@After注释指示即可。JUnit4不需要在超类中显式调用初始化和清除方法，只要它们不被覆盖即可，测试运行程序根据需要自动调用这些方法，其中，超类中的@Before方法在子类中的@Before方法之前被调用，而@After方法则以反方向执行。JUnit概述4.基于JUnit4的测试程序编写采用JUnit4编写测试程序的基本步骤如下：(1)添加测试初始化和环境清理方法，完成初始化和清理资源工作在每个测试之前/之后执行的方法：@Before和@After;在整套测试之前/之后执行的方法：@BeforeClass和@AfterClass;测试时跳过该方法：@Ignore.(2)编写测试类通过添加@Test注释，将类的方法标记为一个单元测试方法，方法名可自定义。(3)使用assertEquals()方法进行比较判断。(4)使用测试集来构建测试包，并将测试用例加入测试包。(5)使用参数化测试通过@Parameters注释的方法返回包含一组参数的集合，JUnit4自动将每组参数传入测试方法进行测试。基于Eclipse的JUnit4测试开发作为Java单元测试的事实标准，JUnit得到了各种开发工具广泛的支持，如Eclipse中集成了JUni3和JUnit4，NetBeans中可使用JUnit。下面简要说明如何在Eclipse中使用JUnit4。(1)新建Java项目时，添加testsrc源文件夹，以存放测试类的源文件，如图11.6所示。基于Eclipse的JUnit4测试开发(2)添加JUnit库并选择JUnit4版本，在Java设置中选择“库”页签并单击“添加库”按钮，在弹出的对话框中选择“JUnit”，如图11.7所示。基于Eclipse的JUnit4测试开发(3)将其他可能用到的库放入项目的lib文件夹，在此分别添加poi库用来读写Excel文件，dom4j库用来读取XML文件，jaxen库用于在dom4j中使用Xpath查询语句，如图11.8所示。基于Eclipse的JUnit4测试开发(4)在src目录下写好被测试的类后，在testsrc下创建一个同名的包，并新建JUnit测试用例，如图11.9所示。基于Eclipse的JUnit4测试开发在弹出的新建JUnit测试用例对话框(见图11.10)中应注意，填写的包名应与被测试的类保持一致。当勾选方法存根中的方法后，系统将自动生成对应的由@BeforeClass、@AfterClass、@Before、@After注释的方法。(5)写好测试驱动类后，运行结果如图11.11所示，图中的进度条表示存在测试失败的情况，且目前选择了“只显示失败”的显示模式。1.Ant的安装配置Ant安装配置的步骤如下：(1)下载安装包并解压。从下载安装包apache-ant-1.8.4-binzip，解压到计算机上的某个适当的目录，如C:Nava，解压缩时会自动在该目录下创建所下载的Ant分发包的子目录结构，如C:Nava\apache-ant-1.8.4。(2)配置环境变量。在桌面用鼠标右击“我的电脑”，选择“属性”，在打开的系统属性对话框中选择“高级”页签，并单击“环境变量”按钮，可设置JAVAHOME、ANTHOME和PATH，如图11.12所示。Ant概述2.Ant的构建文件编写要定义某个项目中Ant要执行的目标，需编写基于XML的配置文件，通常为build.xml，用于描述想应用在项目中的每个任务(Task)，通过调用目标树就可执行各种任务。配置文件可包含若干目标，或称进入点(Entrypoint)，目标的depends属性定义目标间的依赖关系，即某目标完成后才执行此目标。每个目标下包含若干任务，每个任务由实现了特定接口的对象来运行。Ant概述Ant内置了很多任务，包括与JUnit相关的两个任务junit和junitreport，分别用于执行JUnit单元测试和生成测试结果报告。Ant还支持一些可选任务，但一般需要额外的库才能工作，且可选任务与内置任务是分开单独打包的。基于Eclipse的Ant使用在Eclipse平台下要使用Ant，可遵循如下的步骤：(1)在项目根目录下新建XML文件，并以Ant编辑器的方式打开，如图11.13所示。(2)编写好build.xml文件后，选择“窗口”→“显示视图”→“Ant”菜单项，添加构建文件buildxml，查看各个目标，并选择执行某个目标，如图11.14所示。基于Eclipse的Ant使用(3)为执行Ant的JUnittask，需将junitjar和orghamcrestcore.jar也添加到lib文件夹下，以方便在Ant的执行中去引用。完整的目录结构如图11.15所示，其中class、testclass和report文件夹是由于build.xml中有相关任务，运行一次后会自动生成。(4)选择buildxml运行默认目标，或在Ant视图中选择运行特定目标，在控制台显示运行结果，如图11.16所示。测试小结保险金问题是一个函数级别的测试问题，即使如此，设计的测试用例也可能非常多。当在Eclipse平台下基于Java进行开发时，应基于JUnit提供的测试框架，编写测试脚本，自动完成测试用例的执行，以提高效率。当然，如果对JUnit不熟悉，则可能需要花费巨大的精力来编写测试脚本，且得到的测试脚本可能质量也不高，这是需要在制订测试计划时就注意到的。02信息采集系统案例实践信息采集系统的主要功能是对给定的信息文件和照片文件进行格式及内容的校验，并在信息文件和照片文件正确的情况下对多个文件进行统一汇总导出，其测试重点在于如何考虑到尽可能多的格式及内容无效的情况。自动化测试设计对应地，其测试用例的设计就是设计典型缺陷表的过程，通过构建一批典型数据文件，将多种缺陷植入这些数据文件(含信息文件和照片文件)，判断系统能否发现这些数据文件中植入已知的缺陷。因此，不需要额外开发自动化测试脚本，而仅需构建测试数据，测试用例执行的过程实际上就是导入包含典型缺陷的数据文件并运行系统来对这些数据文件进行校验的过程。表11.1给出了一个典型的包含多种缺陷的信息文件数据表。其中，身份证号省略了。备注列是为了说明设计该数据的原因，在实际的信息文件中不包含备注列。自动化测试设计部分缺陷分析尽量信息采集系统功能不多，但要考虑的无效情况太多，所以经测试后还是发现了一些缺陷，部分缺陷如表11.2所示。信息采集系统是一个系统级别的案例，但由于该系统的主要功能是对文件进行查错，因此，其测试脚本的开发主要在于测试数据文件的设计，而测试数据文件对于该系统而言，其实就是被校验的数据对象，所以该系统的测试不需要额外开发自动化测试脚本。测试小结03网络教学平台案例实践网络教学平台案例来源于课程教学建设的需要，服务于某课程教学。该网络教学平台是一个课程网站，主要功能：通过网络教学平台主要为教师和学生用户提供服务，教师通过教学平台提供课程相关资源、作业的布置及相关自测题。案例说明学生通过该平台可随时访问课堂内外与课程相关的教案、课件、案例、实验、软件、阅读材料等资源，可方便地提交课程作业，随时就课程内容进行自测自评，并可在课后与教师就课程相关专题和疑问等展开交流。该网络教学平台的最终目标是使之成为师生之间资源共享、提供实践和增进交流的平台。该网络教学平台以VisualStudio2005为开发平台，采用ASPNET和C#语言为开发语言，后台数据库采用SQLServer2005开发实现。1.系统用户及用例系统用户主要分为如下4类：(1)管理员：负责管理用户和设置用户使用期限。对应系统后台功能。(2)匿名用户：所有访问网站的未登录的用户都是匿名用户。对应系统前台功能。(3)教师用户：本课程的任课教师。对应系统前台功能。(4)学生用户：当前学期学习该门课程的学生。对应系统前台功能。案例说明案例说明受篇幅所限，在此仅分析管理员用户的用例，如图11.17所示。案例说明2.软件需求跟踪矩阵根据管理员用户的用例，可以得到其对应软件需求跟踪矩阵如表11.3所示。该表仅列出需求标题和功能简述，其他有关需求状态、变更等内容不再给出。案例说明3.系统需求规格说明受篇幅所限，仅列出添加用户和删除用户的功能需求说明，分别如表11.4和表11.5所示。案例说明测试需求分析对应上述功能需求，得到测试项如表11.6所示：添加用户的测试需求如表11.7所示：测试需求分析删除用户的测试需求如表11.8所示：1.添加用户的部分测试用例对添加用户功能，仅针对测试需求A1.1.1、A1.1.2给出部分测试用例，见表11.9、表11.10。测试用例设计2.删除用户的部分测试用例对删除用户功能，仅针对测试需求A1.2.1、A1.2.4给出测试用例，见表11.11、表11.12。测试用例设计自动化测试设计使用QTP进行功能测试时，应时刻注意，使用工具的最终目的不是为了给领导展示实施自动化测试的过程，而是为了切实提高测试效率，因此，关键仍然在于测试的设计。1.测试设计原则该教学平台已进行过较为详细的手动测试，为了提高后续版本的回归测试效率，将部分功能的测试改为自动化方式执行。基本原则如下：(1)针对大量的重复性手动测试，尽量改为自动化方式，即只要能够通过系统自动读入的方式执行的测试，均改为自动化方式进行，且注意每个测试脚本包含的流程不要太复杂。(2)对于某些无法用自动化方式实现的测试，仍采用手动测试。(3)对于交叉功能的测试，仍采用手动方式执行，例如涉及多类用户频繁登录和退出系统的流程，自动化测试脚本的开发和维护将十分繁琐和困难。自动化测试设计2.测试重点对于管理员用户的功能测试，最重要的功能模块是添加用户，即测试的重点。对各用户之间的交叉功能测试，重点应放在用户超过使用期限后无法登录、用户被删除后无法登录等内容。3.测试难点基于QTP进行自动化功能测试的难点在于：(1)预置条件的设置。例如，测试添加教师用户时，如何设置预置条件以保证每次添加用户时，系统环境一致。(2)参数的设置。例如，设计3组输入数据，如何将这3组数据写入测试脚本。(3)检查点的插入。例如，添加用户后，如何添加检查点来验证添加的用户是否成功，以及如何验证添加的用户是否按顺序添加。QTP概述QTP(QuickTestProfessional)采用关键词驱动测试的理念执行测试，用于执行重复的手动测试，简化测试创建和维护工作，主要用在回归测试中，或测试同一软件的新版本。(1)QTP测试的3个阶段使用QTP测试包括3个阶段：创建测试或组件、运行测试或组件以及分析结果。(2)QTP测试的注意事项①使用QTP进行测试时，应了解QTP的加载项。②了解QTP对浏览器的要求。③QTP的3种录制模式。QTP有3种录制模式：正常录制模式，模拟录制模式和低级录制模式。QTP概述④QTP的对象库。脚本中用到的对象都必须存在对象库中，若在脚本中使用了某个对象而对象库中并不存在，运行脚本时就会出现找不到相应对象的错误。⑤设置Action的执行次数。若执行数据列表中的多组测试数据，应设置Action的执行次数，在QTP的“当前Action”→“ActionCallProperties”中勾选“Runonallrows”，或勾选“Runfromrow()torow()”，仅选择其中指定的几行参数来执行。⑥预置条件的设置。QTP脚本在运行前均有预置条件。QTP概述(3)QTP的合理应用QTP测试的重点不是实现测试的自动化，而是提高测试效率。在实际的测试过程中，如何合理地应用QTP是使用QTP的难点所在。软件系统开发的初期是不适合用QTP进行测试的，此时，待测系统还不稳定，如果这时就采用QTP进行测试，将需要投入大量的成本，且一旦被测系统发生重大改变，将影响很多的自动化测试和组件。总的来说，QTP主要是用于回归测试，它最大的好处是可以重用，在被测系统改动不大的情况下，由QTP将之前的用例全部执行一次，使用回归的次数越多，使用率越高，就越能体现使用QTP的优势。基于QTP的功能测试1.测试环境该网络教学平台的测试环境如表11.13所示。基于QTP的功能测试2.测试脚本开发(1)测试脚本编写的一般步骤测试脚本，也就是测试用例的实现过程，一般步骤为：①录制，将用例中需要测试的具体步骤用QTP录制下来；②脚本增强，修改脚本以满足测试的需要，如添加检查点等；③测试数据添加，如果脚本中进行了参数化，将需要测试的数据添加到数据列表中；④对象库管理，如果修改脚本时用到了新的对象，则将该对象添加到对象库中便于识别。基于QTP的功能测试(2)测试脚本开发(以成功添加教师用户为例)以添加教师用户的测试为例，针对有效用户的测试见表11.9中测试需求A1.1.1对应的测试用例。(3)测试脚本开发(以添加教师用户的有效性校验为例)仍以添加教师用户为例，当输入数据无效时对应的部分测试用例见表11.10，完整的用例应为8个，此时，所有执行步骤完全相同，可直接通过参数化输入测试数据。基于QTP的功能测试3.测试执行脚本编写完成后，即可执行测试脚本。表11.10中测试用例脚本的执行过程部分截图如图11.21-图11.23所示。可以看到，当用户名末4位与身份证号不相同时，系统告警。基于QTP的功能测试在实际执行过程中可能会碰到这样的情况，运行测试脚本时，一些随机生成的验证码无法用脚本来输入，这时需要在脚本运行的过程中手动添加这些内容，且手动添加内容时，时间不能过长，否则脚本执行将中断，如图11.24所示。基于QTP的功能测试4.测试结果分析测试脚本执行完成后，QTP自动生成测试报告，列表如图11.25所示。图中打勾的表示测试通过，未发现缺陷。测试结果中身份证验证的结果如图11.26所示。基于QTP的功能测试验证输入无效数据时系统是否告警的结果如图11.27所示。当测试脚本执行后测试不通过，则将在测试报告相应项的前面显示叉号，图11.28给出了测试脚本A1.1.4的执行结果。基于QTP的功能测试从图11.28可以看出，用户名重复时存在Bug，详细内容见图11.29，测试报告中指出错误原因为“用户名重复系统没有告警，出现功能错误”，对应的缺陷写入缺陷报告，不再给出示例。实际上，在详细的手动测试之后，基于QTP对该网络教学平台进行自动化测试后又发现了20个缺陷。测试小结网络教学平台是一个典型的Web应用系统，包含多类用户、多个子系统、提供较多功能，在功能测试的层面上，当流程、界面稳定时，可采用QTP工具进行自动化功能测试。良好的测试效果关键取决于测试用例的设计，以及如何根据测试用例的要求来构建测试脚本，通过原始的录制、回放方式得到的脚本肯定是不满足要求的，而设计得过于复杂，包含太多流程、操作和校验点的脚本也是不适用的。04分布式搜索系统案例实践案例说明分布式搜索系统是一个基于B/S模式的图书馆馆藏文献查找系统，系统核心功能是提供智能搜索服务，即授权用户登录系统后，通过输入一些描述信息，如文献题目、作者、书评、目录、内容简介等内容，这些内容可能是完整的，或者仅给出部分词汇，也可能只是与文献相关描述有一定关联而已，系统需通过自动对用户输入进行理解，并在资料库中进行搜索匹配，然后将与用户输入最匹配的馆藏文献以一定的排序方式呈现给用户，用户通过浏览文献来查阅各馆藏文献的具体描述信息，并判断该文献是否是自己所需要借阅的文献。案例说明该系统的核心特点是：(1)海量数据的分布式存储。由于文献数量众多，每个馆藏文献不仅包含标题、作者、出版社等基本信息，还可能包含多种格式的附件，且文献数量将随着时间的推移呈逐步上升趋势。面对TB级的文献存储量，必须采用分布式存储方式对其进行存储。(2)分布式搜索方式。系统用户数量众多，且分散在多个地点，用户数也呈稳步上升趋势，为保证为用户提供快速的搜索响应，必须采用分布式搜索方式。(3)高稳定、可靠的系统部署。对于一个庞大的系统而言，必须保证整个系统部署的稳定、可靠，一旦系统停止服务，即使极短时间，也很可能导致投诉电话被打爆。(4)智能化的搜索。用户在搜索文献时并不知道系统中有哪些文献，其输入可能很不专业，系统需自动对用户输入进行词法、语法甚至语义分析，然后基于专业特性计算文献匹配度，同时为用户推荐更多相关文献。自动化测试设计分布式搜索系统的本质是基于分布式存储和分布式搜索提供一个稳定、可靠的T级海量数据智能搜索服务，其中，智能搜索的效果主要通过查全率、查准率、用户反馈等指标加以衡量，不再详述。在此主要考虑的是作为一个应用系统而应满足的核心功能的性能要求，即面对T级海量数据，面对大量用户的并发搜索请求，系统性能如何。然而，在系统上线之前，用户不可能提供实际的数据，且一旦上线，不能允许系统频繁出错，这样的性能测试难点在于：(1)如何通过性能测试证明当前方案的可行性；(2)如何通过性能测试预测实际上线后的性能；(3)如何通过性能测试来寻找系统进一步优化的方向。LoadRunner概述LoadRunner是惠普公司开发的一款性能测试工具，主要用于C/S和B/S结构的软件系统测试。该产品通过模拟虚拟的并发用户数来对系统进行测试。与WinRunner不同，LoadRunner(简称LR)可以跨平台使用，适用于Windows、Linux等多种操作系统下。LoadRunner是最好的企业级软件性能测试工具之一。LR的运行机制是通过用一台或几台计算机产生成千上万虚拟用户，模拟实际用户行为，虚拟用户(Vuser)通过执行典型业务流程模拟设计用户的操作，对于Vuser执行的每个操作，LR向服务器或类似的企业系统提交输入信息，增加Vuser的数量可以增大系统上的负载。若要模拟较多用户负载的情况，可通过Controller设定虚拟用户数执行一系列任务的Vuser，如观察1000个Vuser同时登录系统并进行搜索时服务器的行为。通过使用LR将客户端/服务器的性能测试需求划分为多个场景，通过场景定义每个测试会话中发生的事件。LoadRunner概述LR提供多种Vuser类型，适于各种特定负载测试环境。Vuser使用Vuser脚本进行描述，脚本中包含在方案中独立并录制服务器性能的函数。LR由如下3部分构成：(1)VuGen:脚本生成器，是LR用于开发Vuser脚本的主要工具，可用于录制和运行脚本。(2)Controller:控制器，通过手动和基于目标的两种方法来设计场景，并通过设置场景模拟用户行为，在场景运行期间自动收集应用服务器软、硬件相关数据，存放到小型数据库文件中，从而独立监控和分析系统性能和功能。(3)Analysis:分析器，当运行完成，数据收集工作完成后，通过该分析器对测试结果数据进行分析，包括各种图表，并可根据需要进行合并，还可以比较两次运行结果之间的差异，利于系统的性能调优，最终的输出结果也可通过该分析器以Word或HTML格式输出。基于LoadRunner的性能测试1.测试环境(1)硬件环境2台主服务器，配置分别为：①AMDAthlon(tm)ⅡX4635Processor2.90GHz，内存4.00GB②Intel(R)Core(TM)2DuoCPUT83002.40GHz，内存2.00GB2台从服务器，配置均为：AMDAthlon(tm)ⅡX2240Processor2.81GHz，内存2.00GB1台测试客户端，配置为：CPU:Intel(R)Core(TM)i5-2410MCPU2.30GHz，内存2.00GB(2)软件环境操作系统：Ubuntu10.04，WindowsXP软件配置：Jdk1.6.029，Tomcat6.0.35，Apache2.22，Solr3.5.0基于LoadRunner的性能测试(3)系统部署系统部署如图11.30所示。基于LoadRunner的性能测试(4)网络环境网络环境如图11.31所示。基于LoadRunner的性能测试2.测试数据测试所用原始数据见表11.14(在此仅截取2012年3月23日到3月26日之间的数据):基于LoadRunner的性能测试生成的索引数据见表11.15。搜索主要是针对索引数据展开，而非针对原始数据进行搜索，因此，需要重点关注的不是原始数据的规模，而是生成的索引数据的规模，以及原始数据与索引数据在规模上的关系。从数据对比看出，索引数据相比原始数据的规模级别相差较大，其存储要求不高，且数据核心在数据库数据而非附件文档，为此，构造原始数据时重点并非附件文档，主要利用数据库数据增大索引数据规模，这样也可节省硬盘空间，便于展开有限条件下的性能测试。基于LoadRunner的性能测试3.测试需求测试主要针对搜索模块。性能要求：分别在250、500、1000、1500、2000的并发用户数条件下，要求系统的平均响应时间不大于3秒。4.测试风险本性能测试并非在实际用户使用环境中进行测试(即模拟的测试环境和客户实际使用环境配置差别较大)，因此，测试结果与实际使用环境中的结果可能存在一定的出入。另外，测试环境中的数据量相比实际使用环境中数据量少得多，且系统上线后很长时间内必然无法达到T级数据量的测试要求，系统目前的性能不能精确地代表数据量增长后的性能，但具有较大的借鉴意义。基于LoadRunner的性能测试预估系统将有上万用户同时在线使用，因暂无法获取实际业务数据，按经验性原则，取10%(即1000人左右)作为并发用户数，进行压力测试。正常情况下，基于相同的数据源，对关键字搜索操作进行并发的压力测试，采用直接并发(所有并发用户同时加压，无任何缓冲时间)和阶梯逐渐加压(在一定时间内每隔一段时间增加多个用户)两种方式，分别使用并发用户250、500、1000、1500、2000个进行测试。搜索的关键字为“411”，搜索后一共返回68条结果。针对直接并发方式和逐渐加压方式，以250个最大并发用户数为例，参数设置分别如图11.32和图11.33所示，其他并发用户情况下仅需对应修改最大并发数，其余设置不变。基于LoadRunner的性能测试无论是哪种加压方式，测试时都忽略脚本的思考时间，即用户实际操作中的思考和停顿时间，这样对系统产生的压力更大。具体设置如图11.34所示。基于LoadRunner的性能测试6.场景模型及测试结果针对该测试共设计10个场景，其中场景1～5采用直接并发的测试方式，场景6～10采用逐渐加压的测试方式。受篇幅所限，在此仅给出两个场景的测试结果。(1)场景2的测试结果场景2的设置如表11.16所示。基于LoadRunner的性能测试场景2的平均事务响应时间结果如图11.36所示，图中的绿线代表运行的虚拟用户数，紫线代表平均事务响应时间。该图反映了整个测试过程中不同时刻运行的虚拟用户数和当时的平均事务响应时间之间的关系。基于LoadRunner的性能测试平均事务响应时间百分比结果如图11.37所示。该图显示的是多少百分比的搜索事务在对应的响应时间内完成。该图表示86%的搜索事务都是在2.927秒内完成的。基于LoadRunner的性能测试服务器(IP为02)的资源情