《一章系统测试》由会员分享，可在线阅读，更多相关《一章系统测试（98页珍藏版）》请在金锄头文库上搜索。
1、第6章 系统测试主要内容：n性能测试n压力测试n容量测试n健壮性测试n安全性测试n可靠性测试n可用性测试n验收测试的内容、策略和方法n系统测试工具及其应用6.1 性能测试6.1.1 性能测试的基本概念n性能测试主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。性能测试包括以下几个方面 ：n评估系统的能力。测试中得到的负荷和响应时间等数据可以被用于验证所计划的模型的能力，并帮助做出决策。 n识别系统中的弱点。受控的负荷可以被增加到一个极端的水平并突破它，从而修复系统的瓶颈或薄弱的地方。n系统调优。重复运行测试，验证调整系统的活动得到了预期的结果，从而改进
2、性能，检测软件中的问题。6.1.2 性能测试方法n基准法性能测试的基准大体有以下几方面：n响应时间响应时间 从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。合理的响应时间取决于实际的用户需求。n并发用户数并发用户数n常见的错误理解：n使用系统的全部用户数量n使用系统的全部在线用户数量n正确理解：n与服务器进行交互的在线用户数量n吞吐量吞吐量n单位时间在网络上传输的数据量n这个是衡量网络性能的主要指标n注：由S-Cn性能计数器 描述服务器或操作系统性能的一些数据指标，比如Windows系统资源管理器。6.1.2 性能测试方法n性能测试的其他常见用语：nTPSn每秒钟系统能
3、够处理事务的数量 n点击率n每秒发送的HTTP请求的数量n点击率越大对SERVER的压力也就越大n请求响应时间n从Client端发出请求到得到响应的整个时间。n一般包括网络响应时间+server的响应时间n事务响应时间n完成这个事务所用的时间n这个是性能测试中重点关注的指标6.1.2 性能测试执行分为三个阶段：n1计划阶段n2测试阶段n3分析阶段6.2 压力测试（负载测试、并发测试）6.2.1 压力测试的基本概念n压力测试（Stress Testing）是指模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。n压力测试是通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载
4、条件下系统性能处于失效状态，以此来获得系统性能提供的最大服务级别的测试。n在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能找出性能瓶颈瓶颈。从本质上来说，测试者是想要破坏程序。压力测试方法具有如下特点：n（1）压力测试是检查系统处于压力情况下的能力表现。n比如，通过增加并发用户的数量，检测系统的服务能力和水平；n通过增加文件记录数来检测数据处理的能力和水平等等。n（2）压力测试一般通过模拟方法进行。n通常在系统对内存和CPU利用率上进行模拟，以获得测量结果。如将压力的基准设定为：内存使用率达到75%以上、CPU使用率达到7
5、5%以上，并在此观测系统响应时间、系统有无错误产生。n除了对内存和CPU的使用率进行设定外，数据库的连接数量、数据库服务器的CPU利用率等等也都可以作为压力测试的依据。n（3）压力测试一般用于测试系统的稳定性。n如果一个系统能够在压力环境下稳定运行一段时间，那么该系统在普遍的运行环境下就应该可以达到令人满意的稳定程度。在压力测试中，通常会考察系统在压力下是否会出现错误等方面的问题。压力测试与性能测试的联系与区别：n压力测试是用来保证产品发布后系统能否满足用户需求，关注的重点是系统整体；n性能测试可以发生在各个测试阶段，即使是在单元层，一个单独模块的性能也可以进行评估。n压力测试是通过确定一个系
6、统的瓶颈，来获得系统能提供的最大服务级别的测试。n性能测试是检测系统在一定负荷下的表现，是正常能力的表现；而压力测试是极端情况下的系统能力的表现。n例如对一个网站进行测试，模拟10到50个用户同时在线并观测系统表现，就是在进行常规性能测试；当用户增加到系统出项瓶颈时，如1000乃至上万个用户时，就变成了压力测试。压力测试和负载测试（Load Test）：n负载测试是通过逐步增加系统工作量，测试系统能力的变化，并最终确定在满足功能指标的情况下，系统所能承受的最大工作量的测试。n压力测试实质上就是一种特定类型的负载测试。压力测试和并发性测试：n并发性测试是一种测试手段，在压力测试中可以利用并发测试
7、来进行压力测试。6.2.2 压力测试方法n压力测试应该尽可能逼真的模拟系统环境。n对于实时系统，测试者应该以正常和超常的速度输入要处理的事务从而进行压力测试。n批处理的压力测试可以利用大批量的批事务进行，被测事务中应该包括错误条件。压力测试中使用事务获得途径n测试数据生成器；n由测试小组创建的测试事务；n原来在系统环境中处理过的事务。n压力测试中应该模拟真实的运行环境。n测试者应该使用标准文档，输入事务的人员或者系统使用人员应该和系统产品化之后的参与人员一样。n实时系统应该测试其扩展的时间段，批处理系统应该使用多于一个事务的批量进行测试。有效的压力测试将可采用以下测试手段：n（1）重复（Rep
8、etition）测试：n重复测试就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。n确定在极端情况下一个操作能否正常执行，并且能否持续不断地在每次执行时都正常。n（2）并发（Concurrency）测试：n并发是同时执行多个操作的行为，即在同一时间执行多个测试线程。n例如，在同一个服务器上同时调用许多Web服务。并发测试原则上不一定适用于所有产品（比如无状态服务），但多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码测试用例才能得到测试结果。n（3）量级（Magnitude）增加：n压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。n量级的确定
9、总是与应用系统有关，可以通过查找产品的可配置参数来确定量级。n（4）随机变化： 该手段是指对上述测试手段进行随机组合，以便获得最佳的测试效果。6.2.3 压力测试执行n可以设计压力测试用例来测试应用系统的整体或部分能力。压力测试用例选取可以从以下几个方面考虑：n输入待处理事务来检查是否有足够的磁盘空间；n创造极端的网络负载；n制造系统溢出条件；n当应用系统所能正常处理的工作量并不确定时需要使用压力测试。压力测试意图通过对系统施加超负载事务量来达到破坏系统的目的。n压力测试的弱点在于准备测试的时间与在测试的实际执行过程中所消耗的资源数量都非常庞大。n通常在应用程序投入使用之前这种消耗的衡量是无法
10、进行的。【例例6.4】某个电话通信系统的测试n测试采用压力测试方法。在正常情况下，每天的电话数目大约2000个，一天24小时服从正态分布。在系统第1年使用时，系统的平均无故障时间大约1个月左右。分析表明，系统的出错原因主要来源于单位时间内电话数量比较大的情况下，为此，对系统采用压力测试，测试时将每天电话的数目增加10倍，即20000个左右，分布采用均匀和正态两种分布，测试大约进行了4个月，共发现了314个错误，修复这些错误大约花费了6个月的时间，修复后的系统运行了近2年，尚未出现问题。6.3 容量测试6.3.1 容量测试基本概念n所谓的容量测试（Volume Testing）是指，采用特定的手
11、段测试系统能够承载处理任务的极限值所从事的测试工作。n这里的特定手段是指，测试人员根据实际运行中可能出现极限，制造相对应的任务组合，来激发系统出现极限的情况。n容量测试的目的n容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理，通过测试，预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），确定系统在其极限值状态下是否还能保持主要功能正常运行。n容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。n对软件容量的测试，能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如电子商务网站所能承受的、同时进行交易或结算的在线用户数
12、。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。容量测试与压力测试的区别n与容量测试十分相近的概念是压力测试。二者都是检测系统在特定情况下，能够承担的极限值。n然而两者的侧重点有所不同，压力测试主要是使系统承受速度方面的超额负载，例如一个短时间之内的吞吐量。n容量测试关注的是数据方面的承受能力，并且它的目的是显示系统可以处理的数据容量。n容量测试往往应用于数据库方面的测试n数据库容量测试使测试对象处理大量的数据，以确定是否达
13、到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。压力测试、容量测试和性能测试的区别n更确切的说，压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段，不是直接的测试目标。n压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷，而容量测试和性能测试是系统测试的主要目标内容，也就是确定软件产品或系统的非功能性方面的质量特征，包括具体的特征值。n容量测试和性能测试更着力于提供性能与容量方面的数据，为软件系统部署、维护、质量改进服务，并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。n压力测试、容量测试和性能测试的测试方法相通，在实际
14、测试工作中，往往结合起来进行以提高测试效率。一般会设置专门的性能测试实验室完成这些工作，即使用虚拟的手段模拟实际操作，所需要的客户端有时还是很大，所以性能测试实验室的投资较大。对于许多中小型软件公司，可以委托第三方完成性能测试，可以在很大程度上降低成本。6.4 健壮性测试6.4.1 健壮性测试基本概念健壮性测试（Robustness Testing）主要用于测试系统抵御错误的能力。这里的错误通常指的是由于设计缺陷而带来的系统错误。测试的重点为当出现故障时，是否能够自动恢复或忽略故障继续运行。健壮性的两层含义：n一是高可靠性，二是从错误中恢复的能力。前者体现了软件系统的质量；后者体现了软件系统的
15、适应性。二者也给测试工作提出了不同的测试要求，前者需要根据符合规格说明的数据选择测试用例，用于检测在正常情况下系统输出的正确性；后者需要在异常数据中选择测试用例，检测非正常情况下的系统行为。6.4.2 健壮性测试方法健壮性测试可以根据以下方面评价系统的健壮性：n通过：系统调用运行输入的参数产生预期的正常结果。n灾难性失效：这是系统健壮性测试中最严重的失效，这种失效只有通过系统重新引导才能得到解决。n重启失效：一个系统函数的调用没有返回，使得调用它的程序挂起或停止。n夭折失效：程序执行时由于异常输入，系统发出错误提示使程序中止。n沉寂失效：异常输入时，系统应当发出错误提示，但是测试结果却没有发生
16、异常。n干扰失效：指系统异常时返回了错误的提示，但是该错误提示不是期望中的错误。自动化实现上述测试内容是需要把握以下原则：n可移植性：健壮性测试基准程序是用来比较不同系统的健壮性，因此移植性是测试基准程序的基本要求。n覆盖率：理想的基准程序能够覆盖所有的系统模块，然而这种开销是巨大的。因此一般选取使用频度最高的模块进行测试。n可扩展性：可扩展性体现在当需要扩展测试集时能够前后一致。这种可扩展性不仅指为已有模块增加测试集，还包括为新增加的模块增加测试集。n测试结果的记录：健壮性测试的目的是找出系统的不健壮性因素，因此应详细的记录测试结果。设计健壮性测试的策略n基于错误的策略：确认所有可能的错误源
17、，为每一类错误开发错误注入技术；n基于覆盖率的策略：接口覆盖的数量，故障位置覆盖的数量，例外覆盖的数量；n基于失效的策略：用例设计故障是否被处理了，例外是否被处理了，一个组件中的失效是否影响另一个组件；健壮性测试用例设计方法n在进行健壮性测试时，常用的用例设计方法主要有三种：故障插入测试，变异测试和错误猜测法。健壮性测试方法通常需要构造一些不合理的输入来引诱软件出错，如输入错误的数据类型，输入定义域之外的数值等。6.4.3 一个健壮性测试案例分析n【例66】为了更清楚的让读者了解什么是健壮性测试，在这里举个简单的例子。假如定义了两个变量X1和X2，两个变量都有自己的取值范围，则写成如下这种形式
18、：aX1b；cX2d；用坐标的形式表示，如图6.7所示。图6.7 两变量函数的健壮性测试用例n在图中，灰色区域外的4个点就是健壮性测试要重点考虑的情况。一般情况下，边界值分析的大部分讨论都直接适用于健壮性测试。健壮性测试最需要关注的部分不是输入，而是预期的输出。当物理量超过其最大值时，会出现什么情况。如果是飞机机翼的迎角，则飞机可能失速，健壮性测试的主要价值是观察例外处理情况。6.5安全性测试6.5.1安全性测试基本概念n安全性测试是检查系统对非法侵入的防范能力，其目的是为了发现软件系统中是否存在安全漏洞。软件安全性是指在非正常条件下不发生安全事故的能力。n安全性一般分为两个层次，即应用程序级
19、的安全性和系统级别的安全性 6.5.2安全性测试方法n（1）功能验证n功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如用户管理模块、权限管理模块、加密系统、认证系统等进行测试，主要是验证上述功能是否有效。 n（2）漏洞扫描 n安全漏洞扫描通常都是借助于特定的漏洞扫描器完成。漏洞扫描器是一种能自动检测远程或本地主机安全性弱点的程序，通过使用漏洞扫描器，系统管理员能够发现所维护信息系统存在的安全漏洞，从而在信息系统网络安全防护过程中做到有的放矢，及时修补漏洞。n模拟攻击试验 n对于安全测试来说，模拟攻击试验是一组特殊的黑盒测试案例，通常以模拟攻击来验证软件或信息系统的安全防护能力
20、。6.6 可靠性测试6.6.1 可靠性测试的基本概念可靠性测试的基本概念n1软件可靠性测试过程软件可靠性测试过程n2描述软件可靠性的基本参数描述软件可靠性的基本参数n假设系统假设系统S投入测试或运行后，工作一段时投入测试或运行后，工作一段时间间t1后，软件出现错误，系统被停止并进行后，软件出现错误，系统被停止并进行修复，经过修复，经过T1时间后，故障被排除，又投入时间后，故障被排除，又投入测试或运行。假设测试或运行。假设t1，t2，tn是系统正是系统正常的工作时间，常的工作时间，T1，T2，Tn是维护时是维护时间，如图间，如图6.11所示。所示。n（1）故障率（风险函数）： 的单位是FIT，1
21、FIT=10-9/小时。n(2) 维修率：(3) 平均无故障时间： n(4) 平均维护时间：n(5) 有效度 n (6) 可靠性：n美国国家标准ANSI/AIAA R-013-1992要求最合理的故障率大约在10-4/小时左右，对于安全用计算机，推荐的MTBF大约为100010000小时。n【例例6.8】 某个系统的使用情况如图6.12所示。nn根据题义，n=6,t=186天=1488小时（每天8小时），T=15小时，则：nMTBF=248小时n=0.004/小时nMTTR=2.5小时n=0.4nA=0.99.n3测试剖面和使用剖面之间的关系测试剖面和使用剖面之间的关系n(1) 计算准确的软件
22、运行剖面，只有得到真实的软件运行剖计算准确的软件运行剖面，只有得到真实的软件运行剖面，软件可靠性计算的结果才是真实的，否则，就会存在误面，软件可靠性计算的结果才是真实的，否则，就会存在误差。假设差。假设Test(D)是测试时的运行剖面，是测试时的运行剖面，User(D)是用户使是用户使用时的运行剖面。用时的运行剖面。n(2) 计算测试强度计算测试强度C，也称为压缩因子。，也称为压缩因子。C被定义为：被定义为：n n定理6.1：设x1，x2，xn是测试期间的n个无故障时间间隔，测试剖面等于使用剖面，即Test (D)= User (D)，则：n定理6.2：假设软件有n功能或模块，实际使用时每个模
23、块被执行的概率分别为p1，p2，pn，均匀分布测试M小时，相当于按使用剖面测试了小时。n定理6.3：假设软件有n功能，实际使用时每个功能被执行的概率分别为p1，p2，pn，测试期间假设的每个功能被执行的概率分别为：p1，p2，pn，令： 则x越大，测试时估计的可靠性就越不准确。反之，亦然。6.6.2 软件的运行剖面软件的运行剖面n1运行剖面的概念及意义运行剖面的概念及意义n定义6.1：软件的运行剖面：设D是软件S的定义域，D=d1，d2，dn，P(di)是di的发生的概率，则运行剖面被定义为： (d1 ,P(d1), (d2 ,P(d2), (dn ,P(dn)。n软件测试与软件可靠性的评估离
24、不开软件的运行剖面。软件S的运行剖面是指软件输入空间D以及D中的点取值的分布，也就是说，D中每个点取值的概率（一般，将D及D的分布称为运行剖面）。显然，如果dD，若S（d ）是正确的，则S的正确运行的概率为1，即P（S）=1。假设D=D1D2，D1是S正确运行的概率，D2是S产生错误的概率。在均匀分布假设下，S正确运行的概率为： 6.7 可用性测试6.7.1 可用性测试的概念n可用性测试 (Usability Testing) 是对于用户友好性的测试，是指在设计过程中被用来改善易用性的一系列方法。n测试人员为用户提供一系列操作场景和任务让他们去完成，这些场景和任务与产品或服务密切相关，通过观察
25、来发现完成过程中出现了什么问题、用户喜欢或不喜欢哪些功能和操作方式，原因是什么，针对问题所在提出改进的建议。可用性与实用性的区别n可用性是指产品在特定使用环境下为特定用户用于特定用途时所具有的有效性、效率和用户主观满意度。有效性是用户完成特定任务时所具有的正确和完整程度；效率是用户完成任务的正确完整程度与所用资源（如时间）之间的比率；满意度是用户在使用产品过程中具有的主观满意和接受程度。n可用性体现的是用户在使用过程中所实际感受到的产品质量，即使用质量；而实用性体现的是产品功能，即产品本身所具有的功能模块。n与实用性相比，可用性重视了人的因素，重视了产品是被要最终用户使用的。典型可用性测试包含
26、以下维度:n任务操作的成功率；n任务操作效率；n任务操作前的用户期待；n任务操作后的用户评价；n用户满意度；n各任务出错率；n二次操作成功率；n二次识别率用户操作过程中各认知纬度（视产品情况而定）。可用性测试的文档n日程安排文档n用户背景资料文档n用户协议n测试脚本 n测试前问卷 n测试后问卷n任务卡片 n测试过程检查文档 n过程记录文档 n测试报告 n影音资料6.7.2 可用性测试方法n（1）一对一用户测试：n一个可用性测试部分包括测试人员（主持人/助理）和一个目标用户，这个目标用户会在测试人员的陪同下完成一系列的典型任务。征得参与者的同意后测试过程将被摄像，测试人员将持续观察、了解用户的操
27、作过程、思维过程以及相关各项指标（包括用户出错次数、完成任务的时间等），记录用户遇到的可用性问题并分析。n（2）启发式评估：n邀请58名用户作为评估人员来评价产品使用中的人机交互状况，发现问题，并根据可用性设计原则提出改进方案。n启发式评估法是一种用来发现用户界面设计中的可用性问题从而使这些问题作为再设计过程中的一部分被重视的内容可用性检查方法。启发式评估法旨在利用已确立的可用性原则来解释每个发现的可用性问题，所以要根据由已经被违背的、好的交互系统需具备的原则所规定的设计准则来制定一个修正的设计方案是相当容易的。n据研究发现，一般情况下，5个评估人员能够发现75的可用性问题，从可用性问题产出的
28、市场价值与评估费用的比率来看，是较为理想的数字。 n（3）焦点小组：n是在可用性工程中使用的比较多的一种方法，通常用于产品功能的界定、工作流程的模拟、用户需求的发现、用户界面的结构设计和交互设计、产品的原型的接受度测试、用户模型的建立等。可用性问题包括以下方面:n过分复杂的功能或者指令；n困难的安装过程；n错误信息过于简单，例如“系统错误”；n语法难于理解和使用；n非标准的GUI接口；n用户被迫去记住太多的信息；n难以登录；n帮助文本上下文不敏感或者不够详细；n和其他系统之间的连接太弱；n默认不够清晰；n接口太简单或者太复杂；n语法、格式和定义不一致；n没有给用户提供所有输入的清晰的认识。6.
29、8 验收测试6.8.1 验收测试的概念n验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。实施验收测试的常用策略主要有三种，分别是正式验收测试、非正式验收测试和Beta测试。策略的选择通常建立在合同需求、公司标准以及应用领域的基础上 1正式验收测试 n 正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应当是系统测试中所执行测试用例的子集，并且不应当偏离所选择的测试用例方向。在很多项目中，正式验收测试是通过自动化测试工具执行的。 n优点包括：n要
30、测试的功能和特性都是已知的n测试的细节是已知的并且可以对其进行评测n这种测试可以自动执行，支持回归测试n可以对测试过程进行评测和监测n可接受性标准是已知的 n缺点包括：n要求大量的资源和计划n这些测试可能是系统测试的再次实施n可能无法发现软件中由于主观原因造成的缺陷2非正式验收测试n在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格，那样组织有序，而且更为主观。非正式验收测试确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例，测试内容由各测试人员决定。多数情况下，非正式验收测试是由内部测试人员组织执行的。n优点包括：n要测试的功能和特性都是已知的n可以对测试过程进行评
31、测和监测n可接受性标准是已知的n与正式验收测试相比，可以发现更多由于主观原因造成的缺陷n缺点包括：n要求资源和计划n无法控制所使用的测试用例n最终用户可能沿用系统工作的方式，并且可能无法发现缺陷n最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷n用于验收测试的资源不受项目的控制，并且可能受到压缩3Beta测试n在以上三种验收测试策略中，Beta测试需要的控制是最少的。在Beta测试中，采用的数据和方法完全由各测试人员决定。各测试人员负责创建自己的环境，选择数据，并决定要研究的功能、特性和任务。各测试人员负责确定自己对于系统当前状态的接受标准。nBeta测试由最终用户实施，通常开发组
32、织对最终用户的管理很少或不进行管理。Beta测试是所有验收测试策略中最主观的。 n优点包括：n测试由最终用户实施n大量的潜在测试资源n提高客户对参与人员的满意程度n与正式或非正式验收测试相比，可以发现更多由于主观原因造成的缺陷n缺点包括：n未对所有功能或特性进行测试n测试流程难以评测n最终用户可能沿用系统工作的方式，并可能没有发现或没有报告缺陷n最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷n用于验收测试的资源不受项目的控制，并且可能受到压缩n可接受性标准是未知的n需要更多辅助性资源来管理Beta测试人员6.8.2 验收测试方法n1验收测试的过程n2验收测试用例的设计要点验收测试
33、的过程 n(1) 软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。n(2) 编制验收测试计划和项目验收准则：根据软件需求和验收要求编制测试计划，制定所需测试的测试项，制定测试策略及验收通过准则，并由客户参与计划评审。n(3) 测试设计和测试用例设计：根据验收测试计划和项目验收准则编写测试用例，并经过评审。n(4) 测试环境搭建：建立测试的硬件环境、软件环境等。n(5) 测试实施：测试并记录测试结果。n(6) 测试结果分析：根据验收通过准则分析测试结果，给出验收是否通过和测试评价。n(7) 测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客
34、户。验收测试用例的设计要点 n(1) 验收测试的目的主要是验证软件功能的正确性和需求的符合性。软件研发阶段的单元测试、集成测试、系统测试的目的是发现软件错误，将软件缺陷排除在交付给客户之前，而验收测试是与客户共同参与的，旨在确认软件符合需求规格的验证活动。这是组织和编写验收测试用例的出发点。n(2) 验收测试用例所覆盖的范围应该只是软件功能的子集，而不是软件的所有功能。在V字模型中验收测试与需求分析阶段是相对应的，因此，验收测试用例与软件需求规格说明书之间具有可追溯性。一个软件产品可能使用在多个项目中，因而可能具有复杂多样的功能，验收测试不可能也没有必要把研发阶段所有的测试用例都重新执行一遍。
35、n(3) 验收测试用例应当是粗粒度的、结构简单的、条理清晰的，而不应当过多地描述软件内部实现的细节。验收测试预期结果的描述，要从用户可以直观感知的方面体现，而不是针对内部数据结构的展示。因此，需要用黑盒测试的方法，尽量屏蔽软件的内部结构。n(4) 验收测试用例的组织应当面向客户，从客户使用和业务场景的角度出发，而不是从开发者实现的角度出发。使用客户习惯的业务语言来描述业务逻辑，根据业务场景来组织测试用例和流程，适当迎合客户的思维方式和使用习惯，便于客户的理解和认同。n(5) 设计验收测试用例应当充分把握客户的关注点。在保证系统完整性的基础上，把客户关心的主要功能点和性能点作为测试的重点，其它的
36、功能点可以忽略，避免画蛇添足。n(6) 验收测试用例可以适当地展示软件的某些独有特性，引导和激发客户的兴趣，达到超出客户预期效果的目的。适当展示软件在某些方面的独特功能，能够为软件增色，特别是在针对招标入围、设备选型、系统演示等目的的测试活动中，可以弥补软件在其它方面的不足，赢得加分的效果。6.9系统测试工具及其应用 n LoadRunner nTTworkbench nQACenter nDataFactory LoadRunner概述nMercury LoadRunner是一种预测系统行为和性能的负载测试工具。n通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用
37、系统的发布周期 LoadRunner测试原理n用多线程或多进程的方式向服务器端发送大量的数据包，同时接收服务器的返回结果。 测试实例分析n被测系统:Tomcat自带的的猜数游戏。n测试目的：测试该应用中的Jsp提交表单的性能。n测试步骤：n(1) 录制脚本 n选择Visual User Generator，在协议选择框中选择Web(HTTP/HTML)协议 n(2) 生成测试场景n选择Tools菜单中的Create Controller Scenario选项，弹出Create Scenario对话框 n运行测试n点击Start Scenario按钮，开始执行测试场景，执行过程中，左上方的运行状态表格会实时显示当前执行中的虚拟用户的情况，等到所有虚拟用户都执行完毕以后，左下方的四个曲线窗口和底部的数据窗口会显示出测试结果。n查看测试结果n有四个曲线窗口，主要的结果信息集中反映在上面两个界面上，点击各个窗口，可以对应的看到底部的数据窗口会显示响应数据。
