论文设计-基于LoadRunner的“在线交流系统”性能测试.doc

盐城师范学院毕业设计技术报告基于LoadRunner的“在线交流系统”性能测试摘 要在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在Web系统上。随着软件的复杂性的提高，用户对软件的质量、性能要求越来越高。本课题使用LoadRunner软件对“在线交流系统”进行初步的性能测试，通过设计测试计划，录制相关LoadRunner脚本，模拟多用户并发测试场景并进行调试，收集测试数据，对测试数据进行分析等手段，最终生成相关数据结果及最终测试报告，经实践证明测试具有可行性。关键词性能测试 LoadRunner 在线交流系统第一章 引言1.1 选题背景随着软件产业的发展，软件产品的质量控制与质量管理渐渐的成为企业发展的核心。软件规模的不断扩大，软件设计的复杂程度不断提高，软件开发中出现错误或缺陷的机会越来越多，同时，市场对软件质量重要性的认识逐渐增强，因此软件测试在项目实施过程中越来越重要1。软件测试的方式主要有手动测试和自动化测试。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。与手动测试它相比大大节省了人力、时间或硬件资源，提高了测试效率。自动化测试常用的性能测试工具就是LoadRunner，它是一种预测系统行为和性能的负载测试工具，通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner 能够对整个企业架构进行测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期2。随着Web技术的迅速发展，基于Web的网站服务越来越普遍，通常在设计开发Web应用系统的时候很难模拟出大量用户同时访问系统的实际情况，因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。对此情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试，来测试系统的响应时间为服务器的性能优化和调整提供数据依据。现在人们的生活越来越离不开网络，网络已经成为人们的一种生活方式。于是各种论坛、博客、日志空间在网络上随处可见，在线交流系统也变得普遍，而为了避免用户过多超过负载响应过慢、系统崩溃对该系统性能必要进行详细的测试。因此，本课题将基于Web的性能测试作为主要研究方向，并以“在线交流”系统作为对象，以LoadRunner软件为工具进行性能负载测试，对软件测试，尤其是性能测试进行系统的概括和实践。1.2 本文的目标和主要内容本文将通过基于LoadRunner的“在线交流系统”性能测试实例的设计与实现进行深入研究，并在此基础上对系统的性能测试流程做出整理和归纳，本课题的主要任务有：1. 以LoadRunner为工具对“在线交流系统”进行性能测试；2. 对性能测试的流程进行整理归纳；3. 通过对“在线交流”系统的性能测试，学习并掌握基于LoadRunner的测试技术；4. 分析所得测试数据并最终生成测试报告。第二章 性能测试2.1 自动化测试概述很多时候我们没有办法把每个案例都测试一遍，总有很多用例需要测试，或者需要在另一个平台或以其他配置再试一次，但是随着最终期限和产品交付日期的限制分配给每个测试周期的时间缩短了，如何实现低成本高效率的测试成了我们要考虑的问题。有合理的机制防止测试设计时场景遗漏，引入合适的自动化测试工具，自主开发针对性强的测试框架，能做到减少项目维护阶段的投入。 对于“什么是自动化测试”，人们往往理解得过于狭窄，只关心由工具或编程产生的测试脚本，但实际上自动化一词包含了更为广阔的含义。一个Quality Engineering团队在构建一套自动化测试准则时，对自动化测试是这样定义的：在我们的环境中，“自动化”指的是对策略、工具和工件的使用，它增加或减少了手工或人为参与或干预非技巧性、重复或冗长工作的需要。自动化测试，或者说自动化测试策略及工具的实现，是测试人员工具箱里的一件利器，测试工作自动执行并记录测试结果，可以把测试人员从枯燥的重复性工作中解脱出来，将更多精力和时间专注于需要智能判断的复杂工作和其他新的测试用例。这样，不但可以有效提高测试效率、缩短测试特别是回归测试所需时间。自动化测试主要用于下列情况：主要用于回归测试，减少工作量；重复执行一系列的测试用例可以节省时间；条件组合覆盖率要求高的时候；遇到死锁、资源冲突、多线程等问题时；性能测试大量并发用户的时候。2.2 性能测试在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在和Web系统上。随着软件的复杂性的提高，用户对软件的质量、性能要求越来越高，性能测试不但要求测试人员具备很强的技术能力，还要具备综合分析问题的能力。2.2.1 性能测试概念4性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况，而压力测试则是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。本文主要从广义和狭义两方面来讨论性能测试：狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用户使用场景来测试系统的性能是否满足生产性能的要求。广义的性能测试则是压力测试、负载测试、强度测试、并发测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。2.2.2 性能测试类型51）压力测试对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，系统的事务响应时间何时会变得不可接受或事务不能正常执行。2）负载测试对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。3） 容量测试（Volume Testing）：确定系统可处理同时在线的最大用户数。2.2.3 性能测试的目的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。包括以下几个方面：1评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策2识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方3系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能检测软件中的问题，长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突4验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。2.2.4 性能测试的工具随着软件测试的地步逐渐提高，测试的重要性逐步显现，测试工具已成了普遍的趋势。目前的测试工具主要分为白盒测试工具、黑盒测试工具、性能测工具等。性能测试的工具一般有：QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。QALoad是QACenter性能版的一部分，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。Webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试，webload通过模拟真实用户的操作，生成压力负载来测试web的性能。LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。第三章 LoadRunner简介随着测试越来越重要，其中的性能测试也受到越来越多的关注。比较常用的性能测试工具是LoadRunner。3.1 LoadRunner简介LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。在场景中，LoadRunner可以在物理计算机上用虚拟用户(即Vuser)代替真实用户。这些 Vuser 通过以可重复、可预测的方式模拟典型用户的操作，在系统上创建负载。3.2 LoadRunner测试步骤6步骤 1 创建脚本：捕获在您的应用程序中执行的典型最终用户业务流程。步骤 2 设计场景：通过定义测试会话期间发生的事件，设置负载测试环境。步骤 3 运行场景：运行、管理并监控负载测试。步骤 4 分析结果：分析负载测试期间 LoadRunner生成的性能数据。LoadRunner工具组件测试过程的每个步骤均由一个Mercury LoadRunner工具组件执行。这些组件如下：Mercury 虚拟用户生成器 (VuGen)创建脚本VuGen 通过录制应用程序中典型最终用户执行的操作来生成虚拟用户 (Vuser)，VuGen 将这些操作录制到自动虚拟用户脚本中，以便作为负载测试的基础。Mercury LoadRunnerController设计和运行场景Controller 是用来创建、管理和监控负载测试的中央控制台。使用 Controller 可以运行用来模拟真实用户执行的操作的脚本，并可以通过让多个Vuser (虚拟用户)同时执行这些操作来在系统中创建负载。 Mercury Analysis分析场景Mercury Analysis 提供包含深入的性能分析信息的图和报告。使用这些图和报告，可以标识和确定应用程序中的瓶颈，并确定需要对系统进行哪些更改来提高系统性能。第四章 系统分析和测试计划测试计划是在软件测试中最重要的步骤之一，在软件开发的前期对软件测试做出清晰，完整的计划，不仅对整个测试起到关键性的作用，而且开发的工作，整个项目的规划，项目审查都有辅助性作用。4.1 “在线交流”系统项目分析4.1.1 系统需求分析该系统是综合个人信息维护、通知公告、文章发布、留言管理、短信管理于一体的综合信息管理系统，对注册用户提供公告浏览、文章发布、短信收发、留言等服务，对游客提供公告浏览、文章阅读服务。系统主要有登录验证、个人信息管理、文章管理、留言管理、短信管理等模块组成。4.1.2 系统配置该系统的开发环境及工具如下：操作系统：Windows7开发环境：JDK1.6使用数据库：SQL SERVER 2005开发工具：Myeclipse 7.5、Tomcat 6.0 4.2 负载测试目标在开始测试之前，精确地定义想要实现的目标。如表1是LoadRunner测试的常规应用程序测试目标，如表1所示：表1 负载测试目标目标解决的问题度量最终用户响应时间完成一个业务流程需要的时间定义最优硬件配置哪一种配置可以提供最佳性能检查可靠性系统无错误、故障运行的时间长度查看硬件或软件升级升级对性能的影响度量系统容量在没有显著性能下降的前提下，系统能处理的负载程度确定瓶颈影响会延长响应时间的因素本次测试的主要目标为检验该系统在正常峰值下相应模块的响应速度、能承受的最大用户量。通过LoadRunner软件进行以对上述需求进行检测，并在此基础上进行延伸以对该系统负载容量，瓶颈进行评估。4.3 测试方案设计通过分析 “在线交流系统”的需求说明，本文主要研究“登陆模块”，因此本次测试将创建复数Vuser脚本以模拟典型最终用户的不同操作，结合测试目标需衡量的任务定义相应事务，并在此基础上，通过在脚本中使用集合点来模拟峰值期活动，即多个Vuser在同一时刻执行以搜集相关数据。根据目标测试项目的性能需求，本次测试将设计如下两个测试用例：测试用例1：用户进入“在线交流”系统，总共登陆50个用户，登陆模式为每5秒5个用户并发操作。测试用例2：用户进入“在线交流”系统，总共登陆300个用户，登陆模式为每5秒60个用户并发操作。第五章 负载测试与结果分析测试环境一切就绪，下一步的工作就是使用测试工具来模拟实际用户的活动。5.1 创建用户脚本LoadRunner使用用户脚本模拟实际用户来访问网站，该工具提供了录制方法来产生用户脚本，模拟多个用户点击与使用目标网站的各个页面和功能7。“在线交流系统”采用Browser/Server(浏览器/服务器)软件体系结构，主要测试目标为Web应用，因此在本次测试中脚本录制选择Web(HTTP/HTML)协议（图1）。图1 协议选择测试目标为网上系统，地址为：http:/localhost:8080/HPwww98/top.html（图2）。图2 目标地址因为系统是中文的，所以在录制之前需要注意的设置与中文兼容:Advanced Support charset UTF-8（图3）。图3 兼容性设置界面设置好相关参数，开始录制，VuGen将自动生成用户脚本。 图4 脚本部分代码在回放脚本之前需要跟录制时一样要注意的设置：对中文兼容性(图5)，并开始回放成功（如图5）。图5 兼容性设置界面图6 回放成功界面5.2 方案执行脚本制作完成，需要添加一个虚拟场景，在场景中模仿负载运行脚本，在LoadRunner中Controller完成这一功能。5.2.1 场景创建方案模式的选择有两种情况：一种是百分比方案模式，一种是面向目标的方案模式。在实际测试工作过程中根据这两个方案不同的特点来进行选择。百分比方案模式：在设计常规手动方案时，需要创建Vuser组，为它们分配脚本、负载生成器计算机以及Vuser。在百分比模式下，可以定义方案中要使用的Vuser总数，并为每个脚本分配负载生成器和占总数一定百分比的Vuser。面向目标的方案模式：在面向目标的方案中，用户可以定义自己希望实现的测试目标，LoadRunner 将根据定义的目标自动为用户创建一个方案。在一个面向目标的方案中，可以定义5种类型的目标：Vuser数、每秒点击次数（仅Web Vuser）、每秒事务数、每分钟页面数（仅Web Vuser）或方案的事务响应时间。测试用例1为模拟50个用户在线，并在一定时间内对服务器进行拟真的高强度访问，与此有关的设置中，首先将其负载数量设置为50。图7 负载设置5.2.2 负载设置计划生成器中包含“按方案”和“按组”两种计划模式，但两种计划都包含加压，持续时间，减压三项。加压是设置虚拟用户运行的次序和方式，持续时间是所有虚拟用户运行的次序和方式，一种方式为指定时间和数量，表示每隔指定时间，加载指定的虚拟用户数。减压是指虚拟用户运行结束退出运行的方式，指每隔多少时间停止多少用户。按照测试用例1的要求，加压情况为：该50个用户登陆模式为每5秒5个用户并发操作。而测试用例2的加压情况为：该300个用户登陆模式为每5秒60用户并发操作。其他的参数设置都一致。图8 加压方式Duration（持续时间）选项卡的设置如图9所示：图9 持续时间选项卡的设置当加压人数到达规定的并发最大人数时，开始执行场景，在此处设置运行场景的时间，如果在脚本中设置好迭代的次数，便可以选择第一项（Run until completion），运行直到任务结束才停止；如果规定在某段时间一直执行场景，便可以选择第二项（Run for），指定运行的时间。Stop Vusers（减压）选项卡的设置如图10所示：图10 减压选项卡设置当场景运行停止，在此处设置场景结束方式，默认为第一项（Stop all Vusers simultaneously），即为场景停止，所有的用户也同时停止操作。第二项（StopVusers every）设置在指定的时间内停止Vuser数目，可调整在两次停止之间填写间隔时间。如图9测试方案1所显示的，每30秒停止5个用户，直到全部用户都停止时场景结束。当测试场景在Controller创建的场景中运行时，测试人员可以添加相应的监视器，除事物响应时间的监视器以外，其余监视器均需要手动添加。场景配置完成则可以开始运行测试脚本了，Controller将按照已经定义好的场景配置运行脚本。5.3 测试分析LoadRunner 性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率等几个方面分析8。要查找系统瓶颈，就必须分析LoadRunner获取的性能指标数据。在LoadRunner场景运行的同时可以获取大量的数据，可以根据以下几种方式分析这些数据：查看Vuser Log文件，这些文件包括了场景运行过程中每个用户的跟踪数据，Vuser Log文件一般放在脚本目录中；在控制台的输出窗口查看场景的执行过程信息；使用Analysis模块分析获得的结果图；让LoadRunner自动生成HTML或Word格式的测试报告，通过报告进行分析。LoadRunner的Analysis模块是分析系统的性能指标的一个主要工具，它能够直接打开场景的执行结果文件，将场景数据信息生成相关的图表显示出来。Analysis集成了数据统计分析功能，允许测试员对图表进行比较和合并等多种操作，分析后的图表能够自动生成测试员需要的测试报告文档。在运行方案时，数据将存储在结果文件中，扩展名为.lrr。Analysis是处理收集的结果信息并生成图和报告的实用程序，他将活动图的显示信息和布局设置存储在扩展名为.lra的文件中。在运行方案时，默认情况下所有Vuser信息将存储在每个Vuser主机（每个运行场景的机器）中，方案执行之后，这些结果会自动进行整理或合并，即将所有主机的结果传输到结果目录中。通过在控制台窗口中选择ResultsAuto Collate Results（自动整理结果），并清除该选项旁边的复选标记，可以禁用自动整理。要手动整理结果，请选择ResultsCollate Results（整理结果），如果方案执行后这些结果还没有进行整理，在生成分析数据之前，Analysis将对其进行整理。场景运行完毕，在结果目录下会自动保存一个扩展名为.lrr的结果文件，Analysis能够打开这个结果文件，加载该文件时自动处理lrr文件内的结果信息，并自动生成相应的结果图表。5.3.1 摘要信息分析下面以测试用例获取的数据进行分析比较。LoadRunner 进行场景测试结果收集后，首先显示的该结果的一个摘要信息。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等，以简要的信息列出本次测试结果。该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图11所示，从该图我们得知，本次测试运行的最大并发数为50，总吞吐量为312,153,374字节，平均每秒的吞吐量为427,607字节，总的请求数为49,000，平均每秒的请求为67,123，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。图11 统计信息摘要图该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图所示，从该图我们得到每个Action的平均响应时间与业务成功率。图12 事务摘要图该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5- 6所示，从图中可以看到，在本次测试过程中LoadRunner共模拟发出了49,000次请求（与“统计信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是48,123次，而“HTTP 302”则有875，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分失败了，但未影响测试结果，“HTTP 200”表示请求被正确响应，而“HTTP 302”表示被请求资源暂时转移，然后给出一个转移的URL，浏览器在处理服务器返回的302错误时，会重新建立一个TCP连接，然后再取重新定向的URL页面，如果页面处于缓存，则不重新获取。Http返回状态说明：当用户或搜索引擎向网站服务器发出浏览请求时，服务器返回的http数据流中头信息(header)中的状态码1、Http/1.1 200 OK 表示成功访问,为网站可正常访问时的状态2、Http/1.1 301 Moved Permanently永久重定向，对搜索引擎相对友好的跳转方式，当网站更换域名时可将原域名作301永久重定向到新域名，原域名权重可传递到新域名， 也常有将不含www的域名301跳转到含www的，如通301跳转到 3、Http/1.1 302 Found为重定向，但易被搜索引擎判为作弊,一般为普通的js跳转或静态http跳转4、Http/1.1 404 Not Found表示请求页面不存在，设置404错误页时需确保返回值为404。5、Http/1.1 500 Internal Server Error表示服务器内部错误，出现这样的提示一般是程序页面中出现错误，如小的语法错误等 图13 HTTP响应摘要图5.3.2 事务响应分析由图14-1可见，测试用例1中，前60秒左右为事务登录的时间，因此随着用户数量的增加，登录这个事务的响应时间增长的最快，在后期趋于平衡，说明该系统比较稳定；而图14-2中，测试用例2中，不管是在事务登录时间还是后期都不平衡，说明此时系统已经不稳定。图14-1 平均事物响应时间图 图14-2 平均事物响应时间图5.3.3 运行并发数分析“Running Vusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用可以确定Vuser的数量对事务响应时间产生的影响。图15显示了在线交流系统在登录模块性能测试过程中Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景执行计划中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser出现运行错误，这样从另一个侧面说明我们的参数化设置是正确的，因为使用唯一数进行参数化设置，如果设置不正确，将会导致Vuser运行错误。由图15-1可见，50个用户是以每5秒5个用户的顺序开始运行，也就是说当测试场景运行至50秒的时候，所有用户的登录申请都将被提交，从图中可以看出当测试场景运行至大约2分20秒的时候，活动的Vusers数量达到最大值，所有的登录申请都被通过。300个用户是以每5秒60个用户的顺序开始运行，当测试场景运行至25分的时候，所有用户的登录申请都将被提交，从图中15-2可以看出当测试场景运行至大约20分的时候，活动的Vusers数量达到最大值，而此时的活动用户达到300个，全部可以登录申请通过。图15-1 并发数分析图 图15-2 并发数分析图5.3.4 每秒点击数与吞吐量数分析“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这两者结合起来分析。图17显示的是 “Average Throughput”的图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。而如下图16-1和图17-1所示，两种曲线基本走向一致，说明服务器能够及时接受客户端，并且返回正常结果；而图16-2和17-2真的两种曲线走向存在少许区别说明可能存在问题。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢；如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。图16-1 每秒点击数图 图16-2 每秒点击数图图17-1 每秒吞吐量图 图17-2 每秒吞吐量图5.3.5 业务成功率数分析“业务成功率”这个指标在很多系统中都提及到，比如电信的、金融的、企业资源管理的等等，具体的业务成功率是排除那些复杂的业务业务成功率就是事务成功率，用户一般把一个Aciton当做一笔业务，在LoadRunner场景执行中一笔交易称为一个事务，所以说业务成功率其实就是事务成功率、通过率的意思。在“Transaction Summary”中我们可以很明确的看到每个事务的执行状态，如图18-1所示，从图中可以看出，所有的Aciton都是绿色的，即表示为Passed；而图18-2所示部分Aciton是红色的表示没有Passed。图18-1 “业务成功率”图 图18-2 “业务成功率”图通过对两个测试用例获取的数据分析得知，该系统用户达到300时可以全部登录申请成功，但是系统此时已经不稳定，并且还有Action没有通过，则可以推测该系统能承受的用户在300左右。第六章 结束语这此我完成了对一个项目的测试。之前我并没有学过软件测试，刚开始接触的时候，总站在开发的角度去看问题，通过几个月在常熟IBM-ETP的培训，使我对软件测试这个行业有了一定的了解，并且也掌握了软件测试的基本知识和一些测试工具的使用，结合我的学习我完成了我的毕业论文。一门新技术的掌握，最重要的是实践和主动学习，只有这样才能尽快掌握它。在毕业论文过程中我完成了对一个系统的完整测试，从刚开始的制定测试计划，设计测试用例，实施测试，测试结果分析，到最后的测试总结，学到了不少知识