《软件测试》课件第9章

项目九对MercuryWebToursApplication网站的性能测试中 9.1问题情境9.2问题分析9.3任务的设计与实施9.4知识总结9.5应用实践

对LoadRunner安装时所带的示例程序MercuryWebToursApplication用LoadRunner进行简单的测试。9.1问题情境

MercuryWebToursApplication是惠普公司为LoadRunner测试工具编写的一个以机票预订为原型的示例程序，我们只对注册部分进行简单的测试。9.2问题分析

9.3.1录制脚本

启动LoadRunner，界面如图9-1所示。9.3任务的设计与实施图9-1LoadRunner启动界面在LoadRunner启动界面点击“Create/EditScripts”，进入如图9-2所示界面。图9-2脚本录制界面在脚本录制界面，点击“NewVuserScript”按钮，进入如图9-3所示界面。图9-3协议选择界面即将测试的应用程序是Web类型的，故采用HTTP协议。在协议选择界面，选择“Web(HTTP/HTML)”协议，点击“OK”按钮，进入如图9-4所示界面。图9-4任务向导图9-5开始录制图9-6设置录制参数在设置录制参数界面，由于即将要测试的应用程序是Web类型的，因此在“Applicationtype”项选择“InternetApplications”，在“Programtorecord”项选择机器上的“MicrosoftInternet”，在“URLAddress”项输入:1080/WebTours/，在“Workingdirectory”项选择“C:\ProgramFiles\InternetExplorer”。然后确保示例程序“MercuryWebToursApplication”能够正常打开。

其启动方式为：首先选择“开始—所有程序—MercuryLoadRunner—Samples—Web—StartWebServer”，其次选择“开始—所有程序—MercuryLoadRunner—Samples—Web—MercuryWebToursApplication”，看是否能够打开网页。在确定能够打开“MercuryWebToursApplication”后，点击“OK”按钮，LoadRunner开始录制脚本。打开IE浏览器，如图9-7所示。图9-7MercuryWebToursApplication的首界面图9-8MercuryWebToursApplication的注册界面图9-9MercuryWebToursApplication注册成功界面此时停止脚本录制。LoadRunner已经把之前操作过程中所录制的HTTP协议内容转换为脚本。可以在LoadRunner主界面上选择菜单“View—ScriptView”，则出现如图9-10所示界面。图9-10脚本界面至此即完成了最基本的脚本录制，LoadRunner会自动形成基本的测试脚本代码。但是这些测试脚本代码还不能马上用于测试，因为还需要对其进行参数化的设置，让其可以更好地模拟显示用户使用软件系统时的情形。9.3.2编辑脚本

1．编辑手动操作时对耽搁或是延误时间的处理

在脚本录制过程中，经常会有许多的停顿，LoadRunner默认地会把停顿时间录制下来加到脚本中，例如“lr_think_time(200)；”表示脚本在此时停顿了200秒的时间。很多时候这些值是不合理的，需要进行修改。根据实际情况在如图9-10所示脚本界面上进行相应的修改。本例中将两处的时间分别修改为25秒和35秒。

2．脚本参数化

在该任务中，我们注册的是账号，所以每次的用户名应该是不一样的，在此应该将用户名参数化。

在代码编辑区域中选中“chenwei”后，以右键选择“ReplacewithaParameter”，出现如图9-11所示界面。图9-11参数化名称和类型在参数化名称和类型界面中，点击“Properties…”按钮，可进行参数化属性的编辑，如图9-12所示。图9-12参数化属性设置在参数化属性设置界面，单击“CreateTable”按钮，可创建参数化表格并输入参数数据，如图9-13所示。图9-13创建的参数表格如图9-13所示，可将具体的参数逐个输入，也可以点击“EditwithNotepad”按钮，用记事本编辑器来编辑，如图9-14所示。图9-14记事本中的边界参数9.3.3可视化地添加事务

事务是用于模拟用户的一个完整业务操作的过程，LoadRunner提供了可视化添加事务的方式。

首先在任务向导界面的第三个步骤中点击“Transactions”按钮，则出现如图9-15所示界面。图9-15事务编辑界面在事务编辑界面中，LoadRunner把录制过程中发生的动作以截获的界面的方式列出来。点击右边的“NewTransaction”按钮，可以进行事务的添加和编辑。在此只做默认处理。9.3.4运行脚本

在完成了测试脚本后，就可以设计运行场景并运行了。

1．设计运行场景

单击任务向导界面中的“Finish”，出现如图9-16所示界面。图9-16完成界面图9-17创建场景在图9-17所示的创建场景界面中，可以选择场景的创建类型，指定虚拟用户的数量，确定压力产生的机器名等，具体设置如图9-17所示。然后点击“OK”按钮，LoadRunner就会调出“Controller”模块，如图9-18所示。图9-18场景设计界面在场景设计界面中，可以进行进一步的场景设计。在此只指定场景运行的持续时间。在“GlobalSchedule”界面的列表中，选择“Duration”并双击，出现如图9-19所示界面，在该界面中修改相应的时间。图9-19编辑场景持续运行的时间

2．运行场景

设定好时间后，就可以按运行按钮(快捷键F5)，开始按照设计的场景运行脚本，如图9-20所示。

可以通过选择“Monitors”菜单下的“AddMeasurements”来添加对各种性能参数的监控。图9-20运行场景9.3.5分析结果

LoadRunner提供了专门的性能测试报告和分析工具，用于对测试过程中收集到的数据进行整理分析，汇总成测试报告，并用各种图表展现出来。

1．初步的结果分析

场景运行完毕后，LoadRunner会自动收集运行过程中的所有监控数据，并用图表的方式展现出来，如图9-21和图9-22所示。图9-21运行的虚拟用户数和状态统计表图9-22事务相应时间及统计表如图9-21所示，虚拟用户在运行1分钟后达到了峰值，也就是设定的10个虚拟用户同时在运行中。除了状态图外，还给出了统计表。在图9-22中展示了事务响应时间的状态变化图及事务响应时间统计表。

2．产生测试分析报告

如果想要查看更加详细的分析图表并产生测试报告，可选择“Results”菜单下的“AnalyzeResult”，则LoadRunner会调出“Analysis”模块，如图9-23所示。图9-23测试报告在这个界面中，包括了概要测试报告以及各种图表报告。测试人员可按需要将其整合成一份完整的测试报告。

9.4.1LoadRunner的介绍

LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。9.4知识总结LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快地查找和发现问题。此外，LoadRunner能支持广泛的协议和技术，为用户的特殊环境提供特殊的解决方案。LoadRunner的主要功能有下面6种。

1．轻松创建虚拟用户

使用LoadRunner的VirtualUserGenerator，用户能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程，然后将其转化为测试脚本。利用虚拟用户，可以在Windows、UNIX或Linux机器上同时产生成千上万个用户访问。所以LoadRunner能极大地减少负载测试所需的硬件和人力资源。

2．创建真实的负载

VirtualUsers建立起来后，用户需要设定自己的负载方案、业务流程组合和虚拟用户数量。利用LoadRunner的Controller，用户能很快地组织起多用户的测试方案。Controller的Rendezvous功能提供一个互动的环境，在其中用户既能建立起持续且循环的负载，又能管理和驱动负载测试方案。而且，用户可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，用户就能将测试过程自动化。同样用户还可以用Controller来限定用户的负载方案，在这个方案中所有的用户同时执行一个动作，例如登录到一个库存应用程序来模拟峰值负载的情况。另外，用户还能监测系统架构中各个组件的性能，包括服务器、数据库、网络设备等来帮助客户决定系统的配置。

3．定位性能问题

LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，用户都可以观察到应用系统的运行性能。这些性能监测器为用户实时显示交易性能数据(如响应时间)和其他系统组件，包括ApplicationServer、WebServer、网络设备和数据库等的实时性能。这样，用户就可以在测试过程中从客户和服务器这两方面来评估这些系统组件的运行性能，从而更快地发现问题。利用LoadRunner的ContentCheck，用户可以判断负载下的应用程序功能正常与否。ContentCheck在VirtualUsers运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助用户从终端用户角度观察程序的性能状况。

4．分析结果以精确定位问题所在

一旦测试完毕，LoadRunner即收集汇总所有的测试数据，并提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。通过使用LoadRunner的Web交易细节监测器，用户可以了解到将所有的图像、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据组件而使应用系统运行的速度减慢。另外，Web交易细节监测器可分解用于客户端、网络和服务器上端到端的反应时间，以便于确认问题，定位查找真正出错的组件。例如，用户可以将网络延时进行分解，以判断DNS解析时间和连接服务器或SSL认证所花费的时间。通过使用LoadRunner的分析工具，用户能很快地查找到出错的位置和原因并做出相应的调整。

5．重复测试保证系统发布的高性能

负载测试是一个重复过程。每次处理完一个出错情况，用户都需要在相同的方案下对自己的应用程序再进行一次负载测试，以此检验自己所做的修正是否改善了运行性能。

6．其他功能

利用LoadRunner，用户可以很方便地了解系统的性能。它的Controller允许用户重复执行与出错修改前相同的测试方案。它的基于HTML的报告可为用户提供一个比较性能结果所需的基准，以此衡量在一段时间内，有多大程度的改进并确保应用成功。由于这些报告是基于HTML文本的，因此用户可以将其公布于用户公司的内部网上，便于随时查阅。9.4.2LoadRunner的安装

双击setup启动安装，如图9-24所示。图9-24提取文件过程图9-25检测机器上有没有安装必备程序图9-26LoadRunner安装向导欢迎界面图9-27协议声明图9-28设置用户信息界面图9-29安装类型界面图9-30安装目录界面图9-31安装确认界面图9-32安装进行中界面图9-33安装完成界面9.4.3LoadRunner的测试步骤

(1)用户确定需要进行性能测试的业务或交易，通过用户操作和VuserGenerator的录制功能来记录并生成虚拟用户脚本。

(2)手工修改虚拟用户脚本，确定脚本能够回放成功。

(3)在Controller中对场景进行设置后，就可以启动测试了。在测试过程中，Controller控制LoadGenerator对被测系统的加压方式和行为。

(4)

Controller同时负责搜集被测系统各个环节的性能数据。各个LoadGenerator会记录最终用户响应时间和脚本执行的日志。

(5)压力运行结束以后，LoadGenerator将数据传到Controller中，由Controller对测试结果进行汇总。

(6)测试人员借助数据分析工具Analysis对性能测试数据进行分析，进而确定瓶颈和调优方法。

(7)针对性地对系统进行调优，重复进行压力测试，确定性能是否有所提高。9.4.4Web网站的测试

随着Internet和Intranet/Extranet应用的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行已无所不在，这是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。早在1998年就有了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统。目前，对于Web工程的研究主要在国外开展，国内才刚刚起步。在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。而且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。一般软件的发布周期以月或以年计算，而Web应用的发布周期以天甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。一个网站基本完工后，需要通过下面三步测试才可以交付使用：

(1)制作者测试：包括美工测试页面、程序员测试功能。在做完后第一时间内由制作者本人进行测试。测试包括以下两方面：

首页、二级页面、三级页面的页面在各种常用分辨率下有无错位，图片上有无错别字，各链接是否是死链接，各栏目图片与内容是否对应等。

功能达到客户要求，数据库链接正确，各个动态生成链接正确，传递参数格式、内容正确，试图填写测试内容没有报错，页面显示正确等。

(2)全面测试：根据交付标准和客户要求，由专人进行全面测试。它也包括页面和程序两方面，而且要结合起来测试，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识性错误。

(3)发布测试：网站发布到主服务器之后的测试，主要是防止因环境不同而导致的错误。

1．功能测试

对于网站的测试而言，每一个独立的功能模块需要设计单独的测试用例，主要依据为《需求规格说明书》及《详细设计说明书》。对于应用程序模块，需要设计者提供基本路径测试法的测试用例。

1)链接测试

链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：

(1)测试所有链接是否按指示的那样确实链接到了该链接的页面。

(2)测试所链接的页面是否存在。

(3)保证Web应用系统上没有孤立的页面。所谓孤立页面，是指没有链接指向该页面，只有知道正确的URL地址才能访问的页面。

链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。Xenu是一款主要测试链接正确性的工具，它只在对动态生成的页面的测试中会出现一些错误。

2)表单测试

当用户给Web应用系统提交信息时，就需要使用表单操作，例如用户注册、登录、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如，用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，也要进行测试。例如，只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。要测试这些程序，需要验证服务器能否正确保存这些数据，而且后台运行的程序能否正确解释和使用这些信息。

B/S结构实现的功能主要有提交数据、处理数据等。如果有固定的操作流程，可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，也可以在测试、回归测试时运行以便减轻测试人员的工作量。

对子系统各个功能模块中的各项功能进行逐一测试，主要测试方法为边界值测试、等价类测试以及异常类测试。测试中要保证每种类型都有两个以上的典型数值的输入，以确保测试输入的全面性。

3)

Cookies测试

Cookies通常用来存储用户信息和用户在某应用系统的操作。当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，可用来创建动态和自定义页面或者存储登录等信息。

如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且是否已经对这些信息进行了加密。测试的内容可包括Cookies是否起作用、是否按预定的时间进行保存、刷新对Cookies有什么影响等。

4)设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，对不同的脚本语言，例如Javascript、ActiveX、VBScript或Perl等也要进行验证。

5)数据库测试

在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，即数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的。针对这两种情况可分别进行测试。

2．性能测试

网站的性能测试对于网站的运行而言异常重要。但是，目前对于网站的性能测试做得不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。

网站的性能测试主要从三个方面进行：连接速度测试、负载测试(Load)和压力测试(Stress)。

连接速度测试指的是打开网页的响应速度测试。负载测试指的是进行一些边界数据的测试。压力测试更像是恶意测试，其倾向应该是使整个系统崩溃。

1)连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，它们或者是电话拨号，或者是宽带上网。当下载一个程序时，用户可以等待较长的时间，但如果仅仅访问一个页面，Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。

另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登录了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2)负载测试

负载测试测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上进行负载测试，其结果才是正确可信的。

3)压力测试

进行压力测试是指实际破坏一个Web应用系统，以测试系统的反应。压力测试主要测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。

压力测试的区域包括表单、登录和其他信息传输页面等。

3．接口测试

在很多情况下，Web站点不是孤立的。Web站点可能会与外部服务器通信，请求数据、验证数据或提交订单。

1)服务器接口

第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

2)外部接口

有些Web系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用Web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用Visa卡和Mastercard卡，则可以尝试使用Discover卡的数据(简单的客户端脚本能够在提交事务之前对代码进行识别，例如3表示AmericanExpress，4表示Visa，5表示Mastercard，6代表Discover)。通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

3)错误处理

最容易被测试人员忽略的地方是接口错误处理。通常测试人员试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况，订单是否完成，尝试中断用户到服务器的网络连接，尝试中断Web服务器到信用卡验证服务器的连接。在这些情况下，查看系统能否正确处理这些错误，是否已对信用卡进行收费。如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表通知用户进行订单确认。

4．可用性/易用性测试

在可用性/易用性方面，目前只能采用手工测试的方法进行评判，而且缺乏一个好的评判基准，此方面需要共同讨论。

1)导航测试

导航描述了用户在不同的链接页面之间的易操作性。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观，Web系统的主要部分是否可通过主页存取，Web系统是否需要站点地图、搜索引擎或其他的导航帮助等。在一个页面上放太多的信息往往会起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开，很少有用户愿意花时间去熟悉Web应用系统的结构。因此，Web应用系统导航帮助要尽可能地准确。

导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

2)图形测试

在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有以下四种：

(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面上。

(2)验证所有页面字体的风格是否一致。

(3)背景颜色应该与字体颜色和前景颜色相搭配。

(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩格式。

3)内容测试

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷。信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用MicrosoftWord的“拼写与语法检查”功能。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中所谓的“相关文章列表”。

4)整体界面测试

整体界面是指整个Web应用系统的页面结构设计要给用户一个整体感。例如，当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方，整个Web应用系统的设计风格是否一致。

对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

对所有的可用性测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

5．兼容性测试

兼容性测试需要验证应用程序是否可以在用户使用的机器上运行。如果用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和Modem速度。最后，还要尝试各种设置的组合。

1)平台测试

市场上有很多不同的操作系统类型，最常见的有Windows、UNIX、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

2)浏览器测试

浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java、

Javascript、ActiveX、plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为InternetExplorer而设计的，Javascript是Netscape的产品，Java是Sun的产品等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，有时甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

3)视频测试

视频测试是测试页面版式在640

×

400、600

×

800或1024

×

768等不同的分辨率模式

下是否显示正常，字体是否太小(或者是太大)以至于无法浏览，文本和图片是否对齐等问题。

4)

Modem连接速率测试

如果用户使用28.8KModem上网，而测试人员在测试的时候使用的是2M或更高的网速，则不会发现这样的缺陷。那么，用户在下载文章或演示的时候，可能就会等待比较长的时间，这个时候用户不会耐心等待操作的完成。这对于Web系统来说也是一个严重的缺陷，因此在设计Web系统时要考虑到不同网速的用户。

5)打印机测试

用户可能会将网页打印下来，因此网页在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面的打印是正常的。

6)组合测试

最后需要进行组合测试。600

×

800的分辨率在MAC机上可能不错，但是在IBM兼容机上却很难看。在IBM机器上使用Netscape能正常显示，但却无法使用Linux来浏览。

如果是内部使用的Web站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用T1专线，可能不需要测试下载施加。但需要注意的是，可能会有员工从家里拨号进入系统。有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持那些已设置的系统，但是理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

6．安全性测试

Web应用系统的安全性测试区域主要有以下几个方面。

1)目录设置

Web安全的第一步就是正确设置目录。每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。如果没有执行这条规则，那么选中一幅图片，单击鼠标右键，找到该图片所在的路径“…com/objects/images”，然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系，但是进入下一级目录“…com/objects”，在该目录下有很多资料，其中有些是已过期的页面。如果该公司每个月都要更改产品价格信息，并且保存过期页面，那么只要翻看一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

2)登录

现在的Web应用系统基本采用先注册后登录的方式。因此，必须测试有效和无效的用户名和密码，要注意是否对大小写敏感、可以试多少次的限制、是否可以不登录而直接浏览某个页面等。

3)Session

Web应用系统是否有超时的限制，也就是说，用户登录后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登录才能正常使用。

4)日志文件

为了保证Web应用系统的安全性，建立日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

5)加密

当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

6)安全漏洞

服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试未经过授权就不能在服务器端放置和编辑脚本的问题。

7．代码合法性测试

代码合法性测试主要包括以下两个部分：

(1)程序代码合法性检查。程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够由相应的工具进行测试。

(2)显示代码合法性检查。显示代码的合法性检查主要分为Html、Javascript、Css代码检查，目前采用HTML代码检查——采用CSEHTMLValidator进行测试，JavaScript、CSS也可以在网上下载相应的测试工具。

8．文档测试

1)产品说明书属性检查清单

(1)完整：是否有遗漏和丢失，是否完全，是否包含全部内容。

(2)准确：既定解决方案是否正确，目标是否明确，有没有错误。

(3)精确：不含糊，清晰，描述是否一清二楚，是否是自说自话，是否容易看懂和理解。

(4)一致：产品功能描述是否自相矛盾，与其他功能有没有冲突。

(5)贴切：描述功能的陈述是否必要，有没有多余信息，功能是否是客户原来的要求。

(6)合理：在特定的预算和进度下，以现有人力、物力和资源能否实现。

(7)代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计、架构和代码。

(8)可测试性：特性能否测试，测试员建立验证操作的测试程序能否提供足够的信息。

2)产品说明书用语检查清单

(1)说明：对问题的描述通常表现为粉饰没有仔细考虑的功能，这可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的，产品说明书可能会为其掩饰和开脱，也可能含糊其辞，无论是哪一种情况都可视为软件缺陷。

(2)总是、每一种、所有、没有、从不：如果看到此类绝对或肯定的、切实认定的叙述，软件测试员就可以着手设计针锋相对的案例。

(3)当然、因此、明显、显然、必然：这些词语意图诱使接受假定情况，不要中了圈套。

(4)某些、有时、常常、通常、惯常、经常、大多、几乎：这些词语太过模糊。“有时”发生作用的功能无法测试。

(5)等等、诸如此类、依此类推：以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。

(6)良好、迅速、廉价、高效、小、稳定：这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。

(7)已处理、已拒绝、已忽略、已消除：这些词汇可能会隐藏大量需要说明的功能。

(8)如果……那么……(没有否则)：找出有“如果……那么……”而缺少配套的“否则”结构的陈述，想一想“如果”没有发生会怎样。9.4.5软件测试质量保证

1．软件质量保证与软件测试

软件质量(SoftWareQuality)是贯穿软件生存期的一个极为重要的问题，是软件开发过程中所使用的各种开发技术和验证方法的最终体现。因此，在软件生存期中要特别重视质量的保证，以生成高质量的软件产品。

1)软件质量保证

软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。软件质量与传统意义上的质量概念并无本质差别，只是针对软件的某些特性进行了调整。

软件质量由三部分构成：

软件产品的质量，即满足使用要求的程度。

软件开发过程的质量，即能否满足开发所带来的成本、时间和风险等要求。

软件在其商业环境中所表现的质量。

总结起来，高品质软件应该是相对的无产品缺陷或只有极少量的缺陷，它能够准时递交给客户，所花费用都在预算内，并且满足客户需求，是可维护的。但是，有关质量好坏的最终评价依赖于用户的反馈。

软件质量具有以下三个特性：

(1)可说明性：用户可以基于产品或服务的描述和定义加以使用。

(2)有效性：产品或服务对于客户的需求是否能保持有效，如具有99.99%有效性，就可以说达到质量要求。

(3)易用性：对于用户，产品或服务非常容易使用并且一定是非常有用的功能。

过程质量是探索复杂系统开发过程的秩序，按一定规程工作，可以较合理地达到目标。规程由一系列活动组成，形成方法体系，建立严格的工程控制方法，要求每一个人都要遵守工程规范。目前主要流行的过程改进模型有两种：软件能力成熟度模型(CMM)和国际标准过程模型。

软件质量保证(SQA)是指建立一套有计划、有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

软件的质量保证就是向用户及社会提供满意的高质量的产品，进一步来说，软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。

任何形式的产品都是多个过程得到的结果，因此对过程进行管理与控制是提高产品质量的一个重要途径。对于一个软件项目，质量保证活动是自始至终的，它的管理对象是软件过程，是对过程的管理。影响SQA活动效果的重要因素有以下几个：

(1)知识结构：SQA人员的职责是审查软件设计和开发人员的活动，验证他们是否将选定的标准、方法和规程应用到活动中去。因此，SQA工作的有效执行需要SQA人员掌握专业的技术。

(2)经验：SQA人员的经验对任务的实现同样重要。应当选择那些经验丰富的人来做SQA，同时为SQA人员进行专门的培训，以使他们能够胜任这项工作。

(3)依据：SQA人员的工作要有依据和判断的标准，如果没有这些标准，SQA人员就无法准确地判断开发活动中的问题，容易引发不必要的争论。因此公司应当建立开发标准和规程。

(4)全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。

(5)把握重点：SQA人员在工作过程中一定要抓住问题的重点和本质，尽可能避免陷入对细节的争论之中。

2)软件质量保证与软件测试的关系

软件质量保证与软件测试二者之间既存在包含又存有交叉的关系。软件测试能够找出软件缺陷，确保软件产品满足需求。但是测试不是质量保证，二者并不等同。测试可以查找错误并进行修改，从而提高软件产品的质量。软件质量保证则是避免错误以求高质量，并且还有其他方面的措施以保证质量问题。

从共同点的角度看，软件测试和软件质量保证的目的都是尽力确保软件产品满足需求，从而开发出高质量的软件产品，两个流程都是贯穿整个软件开发生命周期的。正规的软件测试系统主要包括制定测试计划、设计测试用例、实施测试、建立和更新测试文档。而软件质量保证的工作主要为制定软件质量要求、组织正式审查、管理软件测试、对软件的变更进行控制、对软件质量进行度量、对软件质量情况及时记录和报告。软件质量保证的职能是向管理层提供正确的可行信息，从而促进和辅助设计流程的改进。软件质量保证的职能还包括监督测试流程，这样测试工作就可以被客观地审查和评估，同时也有助于测试流程的改进。

二者的不同之处在于，软件质量保证工作侧重对软件开发流程中的各个过程进行管理与控制，杜绝软件缺陷的产生；而测试则是对已产生的软件缺陷进行修复。

2．软件测试管理和软件测试团队职责

随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。统计表明，开发较大规模的软件，有40%以上的精力是耗费在测试上的。即使是富有经验的程序员，也难免在编码中发生错误，何况有些错误在设计甚至分析阶段就已埋下“祸根”。无论是早期潜藏下来的错误还是编码中新引入的错误，若不及时排除，轻则降低软件的可靠性，重则导致整个系统的失败。为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。

1)软件测试的组织

(1)测试的过程及组织。根据软件测试计划，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整、合理的测试用例，以便系统实现后进行全面测试。当软件由开发人员完成并检验后，提交测试组，由测试负责人组织测试。测试一般可以以下列方式组织：

①编写测试大纲、测试用例。测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

②将测试过程分阶段。软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认(有效性)测试、系统测试和验收(用户)测试五个阶段。

(2)测试人员组织。人是测试工作中最有价值也是最重要的资源，没有一个合格的负责人、积极的测试小组，测试就不可能实现。为高质高效地完成测试任务，应该组织测试人员进行集体学习，做到如下几点：

测试项目的负责人必须做到：把要做的事情理清楚；把要达到的目的说清楚；把做事情的思路和方法理清楚；把合理的资源调配到合适的位置上，让兴趣和能力结合。从大的方面需要先将这些事情理清楚，才可能使得一个团队具有非常好的战斗力。组织测试人员定期培训，让团队的每个人具备应有的沟通能力、技术能力、自信心、怀疑精神、自我督促能力和洞察力。

组织测试人员进行工作总结，例如在什么地方容易犯错误，犯什么类型的错误，犯错误的原因是什么。还需要对各种错误进行统计，以找到问题的根本原因。就问题而讨论问题，提出问题的实质是什么，然后改进。

组织测试人员提出意见。因为如果一个团队要发展，是需要大家一起努力的，但是做起来却很难。避免一言堂，让大家充分参与到设计中，在其中找到自我的感觉，这样每一个人才能关心项目的每一个角落，工作才能更有效率。

(3)软件测试文件组织。软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计软件开发其他阶段的工作，对于保证软件的质量和它的运行有着重要意义，因此必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。测试文件不只在测试阶段才考虑，应在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍需用到测试文件。①测试文件的类型。根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果进行分析说明，即经过测试后，软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见。这些意见既是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，测试文件自然要在测试阶段内编写。②测试文件的重要性。测试文件的重要性表现在以下几个方面：

验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求是十分有益的。

检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。

明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜藏的问题事先作好思想上和物质上的准备。

生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例具有重要的意义。

评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

再测试：测试文件规定的和说明的内容对维护阶段要进行的再测试是非常有用的。

决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。

③测试文件的编制。在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。

确定进行各阶段测试所需要的标准和策略，掌握其相关文档。

确定监督、管理和控制各测试阶段的准则和方法。

确保可以获得必要的资源和信息，以支持测试流程的正常进行和监督工作的顺利开展。

为了提高测试质量，实行适当改进措施。

2)软件测试的管理

在前面介绍了软件测试是软件质量保证的关键步骤。为了真正做好软件测试工作，系统地建立一个软件测试管理体系是非常重要的，只有这样才能确保软件测试在软件质量保证中发挥应有的关键作用。

建立软件测试管理体系有以下几个方面：

确定软件测试的每个阶段，制定测试计划、设计测试用例、实施测试、建立和更新测试文档以及测试管理。

确定阶段间的相互关系。制定测试计划、设计测试用例、实施测试三个阶段是按顺序依次进行并且相互作用的，阶段间的衔接是规范化的，即每个阶段有开始标志和结束标志。测试管理对这三个阶段进行监督和管理。建立和更新测试文档则贯穿整个测试流程。软件测试管理的主要内容如下：

(1)软件产品的监督和测量。对软件产品的质量特性进行监督和测量，主要依据软件需求规格说明书，验证产品是否满足要求，所开发的软件产品是否可以交付。要预先设定质量度量指标并进行测试，只有符合预先设定的指标才可以交付。

(2)对不符合要求的产品的识别和控制。对于软件测试中发现的软件缺陷，要认真记录它们的属性和处理办法，并进行跟踪，直至最终被修复。在修复软件缺陷之后，要再次进行验证测试。

(3)软件过程的监督和测量。从软件测试中可以获取大量关于软件过程及其结果的数据和信息，利用它们可判断这些过程的有效性，为软件过程的正常运行和持续改进提供决策依据。

(4)产品设计和开发的验证。通过设计测试用例对需求分析、软件设计、程序代码进行验证，确保程序代码与软件设计说明书一致，软件设计说明书与需求规格说明书一致。对于验证中发现的不合格现象，同样要认真记录和处理，并跟踪解决。解决之后，也要再次进行验证。

3)测试团队总的职责

组织一支优秀的测试团队是做好软件测试工作的基本保障。良好的组织结构和人员划分会促进测试工作的顺利开展和实施，提高软件测试的效率和质量，从而大大提高软件产品的开发效率和产品质量。

在科学的管理体系下，软件测试团队各个成员要明确自身责任，既要完成本职工作又要相互协调好，为整个测试流程负责。软件测试团队人员的基本责任应该包括以下几点：

尽早发现软件产品中的所有问题；

督促软件开发人员及时解决测试中发现的缺陷；

帮助项目管理人员制定合理的产品开发计划；

对软件产品中的问题进行分析和跟踪调查，形成文档，以便让项目管理人员和相关产品开发人员对当前产品的质量情况有全面的了解；

协助完善软件开发流程，提高产品开发的效率。

4)软件开发和测试过程的组织结构与职责划分

图9-34表示的是软件开发和测试过程中的组织结构。参与整个软件生产流程的人员种类很多，结构图中列举了具有代表性的开发和测试人员。其中，产品经理和产品开发代表是核心领导。以软件开发经理为首的开发部门和以软件测试经理为首的测试部分既各有分工又需要相互合作，共同开发软件，确保软件质量符合设计标准。

图9-34软件开发和测试过程中的组织结构

(1)在需求分析阶段中，软件开发人员的职责如下：

①软件开发项目经理的职责是：

带领项目组分析审核工作任务书；

带领项目组与系统工程师进行需求交流并进行分析和文档化；

需求跟踪。

②软件开发工程师的职责是：

完成软件需求说明书(SRS)文档；

完成需求跟踪；

参加SRS审查；

根据SRS评审专家意见，修改SRS文档。

③开发代表的职责是：

与项目组一起审查项目任务书；

在评审结束后，批准SRS文档。

(2)在需求分析阶段中，软件测试人员的职责如下：

①质量保证/软件测试经理的职责是：

监督项目组遵循需求管理流程；

参加SRS审查；

保证相关组参加SRS审查。

②软件测试项目经理的职责是：

参与开发人员的软件需求分析，提出可测试性需求；

组织人员参与SRS的评审工作；

组织软件系统测试计划写作；

组织软件系统测试方案写作。

③软件测试工程师的职责是：

参与SRS评审工作；

协助软件测试项目经理完成软件系统测试计划的写作；

协助软件测试经理完成软件系统测试方案的写作。

(3)在软件设计阶段中，软件开发人员的职责如下：

①软件开发项目经理的职责是：

在项目计划中标识设计活动并确保有足够的资源；

从项目成员中标识出设计人员，负责设计工作；

确保设计人员按照本流程开发相应的设计说明书(HLD和LLD)；

确保按照审查规程进行设计的审查；

批准设计说明书(HLD和LLD)；

确保更新了需求跟踪矩阵；

确保设计文档按照配置管理流程来控制。

②软件开发工程师的职责是：

完成设计文档；

完成需求跟踪；

参加设计文档审查；

根据评审专家意见，修改设计文档。

③相关评审专家的职责是：

针对设计文档，提交评审意见；

参加设计文档的评审会议；

确认修改后的意见。

(4)在软件设计阶段中，软件测试人员的职责如下：

①质量保证/软件测试经理的职责是：

监督项目组遵循软件设计流程；

参加设计审查；

保证相关组参加设计审查。

②软件测试项目经理的职责是：

组织所有的测试活动；

制定测试策略；

确保测试活动有合适的计划；

审核并批准单元测试和集成测试的测试计划；

确保所有分配需求被跟踪和验证；

确保测试策略在签发后基线化，单元测试计划(UTP)、集成测试计划(ITP)、系统测试计划(STP)在审查和批准后基线化。

需要说明的是，基线是指一个被正式评审和批准的规格和产品，它作为进一步开发的一个基础必须通过正式的变更流程来变更。

③软件测试工程师的职责是：

准备测试计划(STP/UTP/ITP)；

撰写单元测试(UT)/集成测试(IT)/系统测试(ST)测试用例；

完成需求跟踪。

(5)软件测试执行阶段，软件测试人员的职责如下：

①软件开发项目经理的职责是：

确保缺陷分发给相关软件工程师并及时得到解决；

参与需求变更评审。

②软件开发工程师的职责是：

修正缺陷；

验证相关的缺陷已经被修正。

③软件测试项目经理的职责是：

组织所有的测试活动；

确保选择适合的测试工具以及测试环境的建立；

确保测试活动的计划得到执行并获得资源；

确保缺陷分发给相关软件工程师并及时得到解决；

审核并批准测试报告；

审核并批准测试状态报告。

④软件测试工程师的职责是：

搭建测试环境；

执行测试用例；

将测试中发现的所有缺陷填写在缺陷报告中；

回归测试；

准备测试报告；

测试期间，每周准备测试状态报告。

3．ISO9000标准

近年来，国际上影响最为深远的质量管理标准当属国际标准化组织于1987年公布的ISO9000系列标准了。这一国际标准发源于欧洲经济共同体，但很快就被美国、日本等国所采用。到目前为止，已有70多个国家在它们的企业中采用和实施了这一系列标准。一套国际标准在如此短的时间内为这么多的国家采用，影响如此广泛，实属罕见。中国对此也十分重视，采取了积极态度，一方面确定对其等同采用，发布了与其相应的质量管理国家标准系列GB/T19000；同时积极组织实施和开展质量认证工作。计算机软件行业自然也和其他领域一样被席卷进去。

ISO9000有两个显著特点：

它的目标在于开发过程，而不是产品。它关心的是进行工作的组织方式而不是工作成果。

ISO9000只决定过程的要求是什么，而不管如何达到。

ISO9000标准中针对软件的部分是ISO9001和ISO9000-3。ISO9001负责设计、开发、生产、安装和服务产品方面的事务。ISO9000-3负责开发、供应、安装和维护计算机软件方面的事务。

ISO9000-3的核心内容包括：

合同评审；

需方需求规格说明；

开发计划；

设计和实现；

测试和确认；

验收；

复制、交付和安装；

维护。

1)合同评审

在投标、接受合同或订单之前，供方应对标书、合同或订单进行评审，以确保如下方面的实施：

各项要求都有明确规定并形成文件。在以口头方式接到订单而对要求没有书面说明的情况下，供方应确保订单的要求在其接受之前得到同意。

任何与投标不一致的合同或订单的要求已经得到解决。

供方具有满足合同或订单要求的能力。

2)需方需求规格说明

在某一具体项目进行开发前，应具有一套该项目的完整、精确、无歧义的功能需求，这些需求应包括需方的所有要求。该需求应足以成为产品验收确认时的依据。在制定需求规格说明时应注意以下几点：

双方指定专人负责。

需求认可和更改的批准。

防止误解，定义好术语，对需求的前景进行说明。

记录和评审双方讨论的结果，以备将来查询某些需求、确定原因时使用。3)开发计划

在项目进行前制定开发计划，作为总体的策划，指导整个项目有序的进行。开发计划要求包括以下方面：

项目定义。

项目资源组织管理。

开发阶段。

进度。

确定质量保证计划、测试计划、集成计划等。

4)设计和实现

设计和实现活动是将需求规格说明转化为软件产品的过程。为保证软件产品的质量，这些活动必须在严格规定的方法下进行，不能依赖于事后的审查监督。

(1)设计。设计阶段要满足各阶段的共同要求。此外，设计阶段还应考虑如下几方面：

选用适合所开发产品类型的设计方法；

总结、吸取以往项目的经验教训；

设计应考虑软件以后的测试、维护和使用。

(2)实现。规定编程规则、编程语言、命名约定、编码和注释规则等，要求在实现过程中严格遵守既定开发规则，选用合适的方法和工具实现产品。

(3)评审。为使需求规格说明得以满足，上述规则方法得以实施，必须以评审的方式加以保证。直到所有被发现的缺陷都被消除或确定缺陷的风险可被控制后，才能进入下一步的设计或实现工作。

5)测试和确认

要具有完整的测试计划，测试计划要经过评审，并以此为依据进行测试活动。

(1)测试计划包括以下几个方面：

包括单元测试计划、集成测试计划、系统测试计划、验收测试计划；

制定测试用例、测试数据和预期结果；

考虑要进行的测试类型；

描述测试环境、工具以及测试软件；

软件产品是否完成的判断准则；

测试所需人员及其要求。

(2)测试活动应包括以下几个方面：

记录发现的问题，指出可能受影响的其他部分软件，通知相关负责人员；

确定受影响的其他部分软件，并对其进行重新测试；

评价测试是否适度和适当；

在验收和交付产品前，必须尽可能在类似使用环境中进行确认测试。

6)验收

当软件产品已经完成，经过内部确认测试准备好交付后，应要求需方根据合同中的规定原则判断是否可以进行验收。对于验收中发现问题的处理办法由双方商定并纳入文档。具备验收条件后，应制定验收计划并逐步实施。验收计划应包括：时间进度、评估规程、软件/硬件环境、验收准则。

7)复制、交付和安装并制定安装分发计划

(1)复制。制作好安装程序，复制好必要的副本，准备好该交付的操作手册、用户指南等文档。

(2)交付。交付前应对所交付产品的正确性及完整性进行检验。

(3)安装。就以下方面双方应明确商定各自的作用、责任和义务：

时间进度及安排，包括非工作时间及假日的工作人员安排及工作责任；

提供出入便利条件；

指定熟练人员的密切配合；

提供必要的系统及设备；

对每次安装的确认条件需明确规定；

对每次安装认可的正式规程。

8)维护

对于软件产品在初次交付及安装后必须提供的维护，应在合同中明确规定。合同中应明确以下各项的维护期：程序、数据、规格说明。维护工作一般包括问题的解决、接口的调整、功能扩充和性能改进。

4．能力成熟度模型(CapabilityMaturityModel，CMM)

CMM即软件能力成熟度模型。设计并实施CMM是为了指导软件组织达到以下要求：

(1)确定当前过程的成熟度等级，识别出对软件质量和过程改进至关重要的问题，选择其过程改进策略。

(2)通过关注一组有限的活动，并为实现它们而积极工作，组织能稳步地改善其软件过程，使其软件过程能力持续不断地增长。

1)软件机构的成熟性

多年来软件开发项目不能如期交付，软件产品的质量不能令客户满意，软件开发的开销超出项目开始时所做的预算，这些都是许多软件开发机构遇到的难题。近20年中，不少人力图采用新的软件开发技术来解决软件生产率和软件质量存在的问题，但结果却不能令人满意。这一现象促使人们进一步考察软件过程，从而发现，关键问题在于软件开发过程的管理很不完善。事实表明，在无规则和混乱的管理条件下，先进的技术和工具并不能发挥应有的作用。人们认识到改进软件过程的管理是解决上述难题的突破口。有时，个别项目完成得比较好是因为有个别优秀的软件人员参与工作，并不是因为遵循了成熟的软件过程。要想使多个项目都能很好地完成，不出现上述问题，除非让这几个优秀的软件人员承担所有的项目，但这毕竟是不可能的。稳定、持续地保证软件高质量的完成，只能依靠建立反映有效软件工程实践和管理实践的过程基础设施才能达到。

对于不同的软件开发机构，在组织人员完成软件项目时所依据的管理策略有很大差别，因而软件项目所遵循的软件过程也有很大差别。在此，可用软件机构的成熟度加以区别。

2)能力成熟度模型(CMM)

CMM是一个行业标准模型，用于定义和评价软件公司开发过程的成熟度，一般将软件过程能力成熟度分为以下五个等级：

(1)初始级(等级1)：软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力。

(2)可重复级(等级2)：已建立基本的项目管理过程用于跟踪成本、进度和功能性。必要的过程记录已经就位，使具有类似应用的项目能重复以前的成功。

(3)已定义级(等级3)：管理活动和工程活动两方面的软件过程均已文档化、标准化、并集成到组织的标准软件过程中。全部项目均采用供开发和维护软件的组织标准软件过程中一个经批准的剪裁本。

(4)已管理级(等级4)：已采集详细的有关软件过程和产品质量的度量。无论软件过程还是产品均得到定量了解和控制。

(5)优化级(等级5)：利用来自过程和来自新思想、新技术先导性试验的定量反馈信息，使持续过程改进成为可能。

3)利用CMM对软件机构进行成熟度评估

评估过程有以下几步：

(1)建立评估组。评估组成员应对软件过程、软件技术和应用领域很熟悉，有实践经验，能够提出见解。

(2)评估组准备具体审定评估问题，决定对每一个问题要求展示哪些材料和工具。

(3)项目准备。评估组与被评估机构领导商定选择哪些处在不同开发阶段的项目和典型的标准实施作为评估对象，并将评估时间安排通知被评估项目负责人。

(4)进行评估。对被评估机构的管理人员和项目负责人说明评估过程。评估组与项目负责人一起就所列出的问题逐一对照审查，保证对问题的回答有一致的解释，从而取得一组初始答案。

(5)初评。对每个项目和整个机构做出成熟度等级初评。

(6)讨论初评结果。使用备用资料及工具演示，可进一步证实某些问题的答案，从而决定可能的成熟度等级。

(7)给出最后的结论。由评估组综合问题的答案以及背景证据，作出最终评估结论。9.4.6软件测试经验与原则

测试是一个极其广泛的领域，需要花费大量的时间和精力去研究和实践。正如其他知识领域一样，不可能在完全掌握了所有知识之后才开始应用。测试的知识是在不断的实践中积累并发展的。

下面介绍一下软件测试人员在工作中进行测试的一些经验和原则：

(1)测试的GoodEnough原则。GoodEnough原则是一种权衡投入/产出比的原则：不充分