软件测试实例课件.ppt

1、本章介绍的被测试软件项目是医院本章介绍的被测试软件项目是医院信信 息息 管管 理理 系系 统统（HIS，HospitalInformation System）。）。HIS是一个集成是一个集成度很高的项目，因为行业的关系其中有度很高的项目，因为行业的关系其中有一些词汇可能不被大家所了解，但这并一些词汇可能不被大家所了解，但这并不妨碍说清楚它的测试过程。不妨碍说清楚它的测试过程。本章要重点描述的测试过程是本章要重点描述的测试过程是 HIS的集的集成测试，该阶段的测试重点在功能测试上，成测试，该阶段的测试重点在功能测试上，也有必要的性能测试。后面依次给出了也有必要的性能测试。后面依次给出了HIS集成

2、测试阶段的测试计划、测试用例、集成测试阶段的测试计划、测试用例、缺陷（错误）报告、测试结果总结与分析缺陷（错误）报告、测试结果总结与分析等内容。测试用例将针对等内容。测试用例将针对 HIS的一个子系的一个子系统统门诊挂号管理子系统来设计。该子门诊挂号管理子系统来设计。该子系统不但包含了对数据库的应用，对系统系统不但包含了对数据库的应用，对系统的并发性、安全性、准确性、高效性都有的并发性、安全性、准确性、高效性都有很高的要求，可谓麻雀虽小，五脏俱全，很高的要求，可谓麻雀虽小，五脏俱全，适合将其进行剖析。适合将其进行剖析。8.1 被测试软件项目介绍8.1.1 软件背景医院信息管理系统（医院信息管理

3、系统（HIS）包含门诊挂号、）包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管理医药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程。各子系统所处理的业院日常运作的整个过程。各子系统所处理的业务前后衔接，数据共享。务前后衔接，数据共享。医院信息管理系统的系统结构如图医院信息管理系统的系统结构如图8-1所示。所示。图8-1 HIS1.0系统结构图8.2 HIS测试过程概述HIS的测试按照一般测试过程，将其分的测试按照一般测试过程，将其分为单元测试、集成测试、系统测试和验收为单元测试、集成测试、系统测试和验

4、收测试测试4个阶段。个阶段。8.2.1单元测试单元测试单元测试常常是动态测试和静态测试两种单元测试常常是动态测试和静态测试两种方式并举的。动态测试可由开发人员去运行局方式并举的。动态测试可由开发人员去运行局部功能或模块以发现系统潜藏的错误，也可以部功能或模块以发现系统潜藏的错误，也可以借助测试工具去测试。静态测试即是代码审查。借助测试工具去测试。静态测试即是代码审查。审查的内容包括代码规则和风格，程序设计和审查的内容包括代码规则和风格，程序设计和结构，业务逻辑等。结构，业务逻辑等。HIS系统中涉及到许多的费用计算问题，系统中涉及到许多的费用计算问题，逻辑性很强，需要程序结构也很复杂。面逻辑性很

5、强，需要程序结构也很复杂。面对复杂的业务流程，面对管理各异的用户对复杂的业务流程，面对管理各异的用户需求，没有白盒测试是不可想像的。最简需求，没有白盒测试是不可想像的。最简单的例子：单的例子：HIS中要处理很多类的患者，中要处理很多类的患者，普通患者、医保患者、内部职工、公费患普通患者、医保患者、内部职工、公费患者等，每类患者的费用处理流程和计算方者等，每类患者的费用处理流程和计算方法都不相同，开发人员就要严格地依照系法都不相同，开发人员就要严格地依照系统设计去检查代码的逻辑结构，选取有代统设计去检查代码的逻辑结构，选取有代表性的测试用例去测试相关的模块。表性的测试用例去测试相关的模块。又如医

6、嘱分解，药房摆药等，必须知道又如医嘱分解，药房摆药等，必须知道系统的详细设计和程序的逻辑结构才能设系统的详细设计和程序的逻辑结构才能设计好测试用例。计好测试用例。8.2.2集成测试集成测试集成测试（有时被分为集成测试和确认集成测试（有时被分为集成测试和确认测试两个阶段）是指将各模块组装起来进测试两个阶段）是指将各模块组装起来进行测试，以检查与设计相关的软件体系结行测试，以检查与设计相关的软件体系结构的有关问题，并确认软件是否满足需求构的有关问题，并确认软件是否满足需求规格说明书中确定的各种需求。规格说明书中确定的各种需求。HIS系统的集成测试是指开发人员完系统的集成测试是指开发人员完成了所有系

7、统模块的开发并通过了单元测成了所有系统模块的开发并通过了单元测试后，将编译好的软件交付给测试部门进试后，将编译好的软件交付给测试部门进行测试的过程。行测试的过程。这个阶段的测试需要一个完备的测试管这个阶段的测试需要一个完备的测试管理过程。集成测试过程可以分为测试准备、理过程。集成测试过程可以分为测试准备、测试计划、测试设计、测试执行和测试总测试计划、测试设计、测试执行和测试总结结5个阶段。个阶段。测试准备阶段是指测试人员准备测试资测试准备阶段是指测试人员准备测试资源，熟悉系统的过程。源，熟悉系统的过程。测试计划阶段包含制定测试策略、资源测试计划阶段包含制定测试策略、资源分配、风险预警和进度安排

8、等内容，此项分配、风险预警和进度安排等内容，此项工作由测试负责人来做。工作由测试负责人来做。8.3节中给出了节中给出了HIS集成测试的测试计划。测试计划的模集成测试的测试计划。测试计划的模板各不相同，这个取决于软件的特殊性和板各不相同，这个取决于软件的特殊性和管理的规范性。管理的规范性。测试设计阶段包括设计测试用例及相关测试设计阶段包括设计测试用例及相关管理工具的设计。管理工具的设计。8.4节将给出节将给出HIS集成测集成测试过程中挂号管理子系统部分的主要测试试过程中挂号管理子系统部分的主要测试用例，侧重于系统的功能和性能测试。测用例，侧重于系统的功能和性能测试。测试用例设计之前一般要有一个测

9、试用例的试用例设计之前一般要有一个测试用例的设计大纲。设计大纲。完成测试设计工作后，就开始执行实际完成测试设计工作后，就开始执行实际的测试工作了。的测试工作了。测试时另外一项非常重要的工作就是做测试时另外一项非常重要的工作就是做好系统缺陷记录。本章好系统缺陷记录。本章8.5节将给出系统生节将给出系统生成缺陷报告的注意事项以及缺陷报告的实成缺陷报告的注意事项以及缺陷报告的实例，另外还设计了一个问题记录数据库表。例，另外还设计了一个问题记录数据库表。用数据库记录缺陷的好处是测试人员和开用数据库记录缺陷的好处是测试人员和开发人员能够通过动态的信息发布和获取进发人员能够通过动态的信息发布和获取进行更好

10、的交互，提高测试和修改的工作效行更好的交互，提高测试和修改的工作效率。率。经过修改后的系统再次经过测试即是经过修改后的系统再次经过测试即是回归测试。回归测试。测试结束后要及时总结分析测试结果。测试结束后要及时总结分析测试结果。测试结果的总结与分析一方面是提供一个测试结果的总结与分析一方面是提供一个系统功能、性能和稳定性等方面的完整的系统功能、性能和稳定性等方面的完整的分析和结论，另外要对测试过程本身做出分析和结论，另外要对测试过程本身做出总结，总结成功的经验和失败的教训，以总结，总结成功的经验和失败的教训，以使日后的工作开展得更顺利。具体的测试使日后的工作开展得更顺利。具体的测试总结详见总结详

11、见8.6节。节。8.2.3系统测试系统测试系统测试是在真实或模拟系统运行的环境系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。确配置、连接，并满足用户需求。系统测试也应该经过测试准备、测试计系统测试也应该经过测试准备、测试计划、测试设计、测试执行和测试总结划、测试设计、测试执行和测试总结5个阶个阶段，每个阶段所做工作内容与集成测试很段，每个阶段所做工作内容与集成测试很相似，只是关注点有所不同。相似，只是关注点有所不同。

12、在在HIS系统的系统测试中，要搭建更真系统的系统测试中，要搭建更真实的运行环境，另外还要在不同的操作系实的运行环境，另外还要在不同的操作系统下进行测试，如数据库服务器分别搭建统下进行测试，如数据库服务器分别搭建在在UNIX环境和环境和WINNT环境下长时间多客环境下长时间多客户端并发运行系统的各项功能，并观测服户端并发运行系统的各项功能，并观测服务器的承受能力（系统的反应时间，服务务器的承受能力（系统的反应时间，服务器的资源占用情况等）。器的资源占用情况等）。8.2.4验收测试验收测试验收测试是指在用户对软件系统验收之验收测试是指在用户对软件系统验收之前组织的系统测试。测试人员都是真正的前组织

13、的系统测试。测试人员都是真正的用户，在尽可能真实的环境下进行操作，用户，在尽可能真实的环境下进行操作，并将测试结果进行汇总，由相关管理人员并将测试结果进行汇总，由相关管理人员对软件做出评价以及是否验收的决定。对软件做出评价以及是否验收的决定。HIS系统一般在用户验收之前都需要对系统一般在用户验收之前都需要对系统进行一段时间的试运行，因此可以说系统进行一段时间的试运行，因此可以说HIS的验收测试就是实际的使用（但用户的验收测试就是实际的使用（但用户一般要参与软件的系统测试，即所谓的一般要参与软件的系统测试，即所谓的?测试，不然用户是不会放心让系统试运行测试，不然用户是不会放心让系统试运行的）。的

14、）。因为验收测试由用户完成，不同软件因为验收测试由用户完成，不同软件实际应用的差异性又很大，这里就不对其实际应用的差异性又很大，这里就不对其详加论述了。详加论述了。8.3 测 试 计 划测试计划工作的提交成果是一份完整测试计划工作的提交成果是一份完整的测试计划报告。的测试计划报告。下面给出医院信息管理系统下面给出医院信息管理系统1.0版集成版集成测试的测试计划报告。测试的测试计划报告。8.3.1概述概述本本测测试试项项目目拟拟对对医医院院信信息息管管理理系系统统（HIS）1.0进行测试。进行测试。医院信息管理系统包含门诊挂号、门诊医院信息管理系统包含门诊挂号、门诊收费、诊间医令、病房管理、病案

15、管理、收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程，各子系统所理医院日常运作的整个过程，各子系统所处理的业务前后衔接，数据共享。处理的业务前后衔接，数据共享。测试的目标是要找出影响医院信息管理测试的目标是要找出影响医院信息管理系统正常运行的错误，分别在功能、性能、系统正常运行的错误，分别在功能、性能、安全性等方面检验系统是否达到相关要求。安全性等方面检验系统是否达到相关要求。本次集成测试采用黑盒和白盒测试技术本次集成测试采用黑盒和白盒测试技术（重点在黑盒测试）。测试手段为手工与自（重点在黑盒测试）。测试手段

16、为手工与自动测试相结合（主要依靠手工进行功能测试，动测试相结合（主要依靠手工进行功能测试，依靠自动测试工具进行性能测试）。依靠自动测试工具进行性能测试）。本测试计划面向相关项目管理人员、测本测试计划面向相关项目管理人员、测试人员和开发人员。试人员和开发人员。8.3.2定义质量风险：被测试系统不能实现描述的质量风险：被测试系统不能实现描述的产品需求或系统不能达到用户的期望的行产品需求或系统不能达到用户的期望的行为，即系统可能存在的错误。为，即系统可能存在的错误。测试用例：为了查找被测试软件中的错测试用例：为了查找被测试软件中的错误而设计的一系列的操作数据和执行步骤，误而设计的一系列的操作数据和执

17、行步骤，即一系列测试条件的组合。即一系列测试条件的组合。测试工具：应用于测试用例的硬件测试工具：应用于测试用例的硬件/软软件系统，用于安装或撤销测试环境、创造件系统，用于安装或撤销测试环境、创造测试条件，执行测试，或者度量测试结果测试条件，执行测试，或者度量测试结果等工作。测试工具独立于测试用例本身。等工作。测试工具独立于测试用例本身。进入标准：一套决策的指导方针，用于进入标准：一套决策的指导方针，用于决定项目是否准备好进入特定的测试阶段。决定项目是否准备好进入特定的测试阶段。在集成测试和系统测试阶段，进入标准会在集成测试和系统测试阶段，进入标准会很苛刻。很苛刻。退出标准：一套标准，用于决定项

18、目是退出标准：一套标准，用于决定项目是否可以退出当前的测试阶段，或者进入下否可以退出当前的测试阶段，或者进入下一个测试阶段或者结束项目。同进入标准，一个测试阶段或者结束项目。同进入标准，测试过程的后几个阶段退出标准一般很苛测试过程的后几个阶段退出标准一般很苛刻。刻。功能测试：集中于功能正确性方面的测功能测试：集中于功能正确性方面的测试。功能测试必须和其他测试方法一起处试。功能测试必须和其他测试方法一起处理潜在的重要的质量风险，比如性能、负理潜在的重要的质量风险，比如性能、负荷、容积和容量等。荷、容积和容量等。8.3.3质量风险摘要质量风险摘要危险性：表示故障对系统影响的大小。危险性：表示故障对

19、系统影响的大小。5致命；致命；4严重；严重；3一般；一般；2轻微；轻微；1无。无。影响：影响：5一定影响所有用户；一定影响所有用户；4可能可能影响一些用户；影响一些用户；3对有些用户可能的影响；对有些用户可能的影响；2对少数用户有限的影响；对少数用户有限的影响；1在实际使在实际使用中难以觉察的影响。用中难以觉察的影响。优先级：表示风险可以被接受的程度。优先级：表示风险可以被接受的程度。5很紧急，必须马上纠正；很紧急，必须马上纠正；4不影响进不影响进一步测试，但必须修复；一步测试，但必须修复；3系统发布前必系统发布前必须修复；须修复；2如果时间允许应该修复；如果时间允许应该修复；1最好修复。最好

20、修复。8.3.4测试进度计划测试进度计划8.3.5进入标准（1）“测试小组测试小组”配置好软硬件环境，配置好软硬件环境，并且可以正确访问这些环境。并且可以正确访问这些环境。（2）“开发小组开发小组”已完成所有特性和已完成所有特性和错误修复并完成修复后的单元测试。错误修复并完成修复后的单元测试。（3）“测试小组测试小组”完成完成“冒烟测试冒烟测试”，程序包能打开，随机的测试操作正确完成。程序包能打开，随机的测试操作正确完成。8.3.6退出标准退出标准（1）“开发小组开发小组”完成了所有必须修完成了所有必须修复的错误。复的错误。（2）“测试小组测试小组”完成了所有计划的完成了所有计划的测试。没有优

21、先级为测试。没有优先级为3以上的错误。优先级以上的错误。优先级为为2以下的错误少于以下的错误少于5个。个。（3）“项目管理小组项目管理小组”认为产品实现认为产品实现稳定性和可靠性。稳定性和可靠性。8.3.7测试配置和环境测试配置和环境服务器服务器1台：台：HP Pentium 550，1GB内存，内存，8.4GB硬盘；软件环境：硬盘；软件环境：WindowsNT，Oracle。客户机客户机10台：台：PentiumMMX166，1.2GB硬盘，硬盘，32MB内存；软件环境：内存；软件环境：Oracle客户端。客户端。打印机打印机1台：台：Panasonic KX-P1131。地点：地点：58号

22、楼号楼101室。室。8.3.8测试开发测试开发设计测试用例以进行手工测试。设计测试用例以进行手工测试。准备使用准备使用MI LoadRunner，以检测系统，以检测系统对并发性的控制和系统的强壮性。对并发性的控制和系统的强壮性。设计开发问题记录及交互工具，包括问设计开发问题记录及交互工具，包括问题存取控制系统及所对应的数据库，以对题存取控制系统及所对应的数据库，以对测试结果做很好的记录并提供相关测试和测试结果做很好的记录并提供相关测试和开发人员的交互平台。开发人员的交互平台。8.3.9关键参与者测试经理：宋欣欣（制定测试计划及部署、测试经理：宋欣欣（制定测试计划及部署、监督相关工作）。监督相关

23、工作）。测试人员：蔡亮，邱实，崔进，赫北松，测试人员：蔡亮，邱实，崔进，赫北松，洪怡，武刚，沙盼盼，王军妹（负责相关子系洪怡，武刚，沙盼盼，王军妹（负责相关子系统测试）。统测试）。开发人员：王铁全，李云帆，夏淼，张铁开发人员：王铁全，李云帆，夏淼，张铁（及时解决影响测试进行的系统问题）。（及时解决影响测试进行的系统问题）。项目管理人员：王斌（跟踪项目进展）。项目管理人员：王斌（跟踪项目进展）。8.3.10预算预算8.3.11参考文档参考文档8.4 测 试 用 例测试用例应由测试人员在充分了解系统测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设的基础上在测试之前设计好，测

24、试用例的设计是测试系统开发中一项非常重要的内容。计是测试系统开发中一项非常重要的内容。集成测试阶段测试用例的设计依据为系统需集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员关资料的内容，而且测试人员要与开发人员充分交互。另外有一些内容由测试人员的相充分交互。另外有一些内容由测试人员的相关背景知识、经验、直觉等产生。关背景知识、经验、直觉等产生。测试用例的设计需要考虑很周全。在测测试用例的设计需要考虑很周全。在测试系统功能的同时，还要检查系统对输入试系统功能的同时，还要检查系统对输入数据（合法

25、值、非法值和边界值）的反应，数据（合法值、非法值和边界值）的反应，要检查合法的操作和非法的操作，检查系要检查合法的操作和非法的操作，检查系统对条件组合的反应等。好的测试用例让统对条件组合的反应等。好的测试用例让其他人能够很好地执行测试，能够快速地其他人能够很好地执行测试，能够快速地遍历所测试的功能，能够发现至今没有发遍历所测试的功能，能够发现至今没有发现的错误。所以测试用例应该由经验丰富现的错误。所以测试用例应该由经验丰富的系统测试人员来编写，对于新手来说，的系统测试人员来编写，对于新手来说，应该多阅读一些好的测试用例，并且在测应该多阅读一些好的测试用例，并且在测试实践中用心去体会。试实践中用

26、心去体会。在编写测试用例之前，应该给出测试大在编写测试用例之前，应该给出测试大纲，大纲基本上是测试思路的整理，以保纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是证测试用例的设计能够清晰、完整而不是顾此失彼。测试大纲可以按照模块、功能顾此失彼。测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。点、菜单和业务流程这样的思路来策划。本节给出本节给出“医院信息管理系统医院信息管理系统1.0”的的“门门诊挂号管理子系统诊挂号管理子系统”的测试大纲和测试用例的测试大纲和测试用例的主体部分。的主体部分。8.4.1挂号管理子系统测试大纲挂号管理子系统测试大纲8.4.2其他

27、可用性测试检查标准其他可用性测试检查标准软件产品的可用性是指软件产品能否软件产品的可用性是指软件产品能否让用户更快更容易地完成工作，即软件是让用户更快更容易地完成工作，即软件是否易学、易用，并使用户感到满意。软件否易学、易用，并使用户感到满意。软件产品的可用性主要反映在软件产品的用户产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现，提高用界面及操作过程上减少错误出现，提高用户工作效率，增加用户满意度。户工作效率，增加用户满意度。对于开发商而言可以缩减服务和培训对于开发商而言可以缩减服务和培训费用，提高用户满意度。软件可用性已经费用，提高用户满意度。软件可用性已经越来越引起用户和

28、开发商的关注。可用性越来越引起用户和开发商的关注。可用性测试对所有功能模块来说，检测标准是相测试对所有功能模块来说，检测标准是相同的，而这些检测在功能测试的同时即可同的，而这些检测在功能测试的同时即可检验，所以不再设计单独的测试用例。检验，所以不再设计单独的测试用例。8.4.3功能测试用例1普通挂号，要病历本的测试用例2预约挂号，老患者，不要病历本的测试用例3预约挂号，不要病历本，无挂号费有诊察费的测试用例4有挂号费无诊察费，要病历本的测试用例5退号，不退病历本的测试用例6退号测试用例，包括病历本的测试用例7挂号员结算的测试用例8挂号员结算补打的测试用例挂号员结算补打的测试用例8.4.4性能测

29、试用例性能测试用例8.5 缺 陷 报 告这里给出一个利用数据作缺陷记录报这里给出一个利用数据作缺陷记录报告的实例。错误跟踪数据库可以自己开发，告的实例。错误跟踪数据库可以自己开发，也可以购买现成的产品。也可以购买现成的产品。8.5.1建立缺陷报告数据库缺陷报告数据库应该在测试工作的准缺陷报告数据库应该在测试工作的准备配置阶段就建立起来，测试执行阶段，备配置阶段就建立起来，测试执行阶段，测试人员、开发人员和项目管理评估人测试人员、开发人员和项目管理评估人员可以采用各种方式通过缺陷报告数据员可以采用各种方式通过缺陷报告数据库进行交互，而可以自行开发一个小系库进行交互，而可以自行开发一个小系统，使得

30、数据库能够记录下人们访问数统，使得数据库能够记录下人们访问数据库的一切活动。据库的一切活动。先设计一个缺陷记录的数据表结构。先设计一个缺陷记录的数据表结构。8.5.2编写缺陷报告关于测试人员、系统开发人员和相关问关于测试人员、系统开发人员和相关问题评审人员打开、读取和写入缺陷报告数题评审人员打开、读取和写入缺陷报告数据库，以何种形式并不重要，重要的是对据库，以何种形式并不重要，重要的是对于问题的描述应该是完整的、严谨的、简于问题的描述应该是完整的、严谨的、简洁的、清晰的和准确的。洁的、清晰的和准确的。下面列出编写好的错误报告的几个要点下面列出编写好的错误报告的几个要点（也是测试执行应该遵循的一

31、些原则）。（也是测试执行应该遵循的一些原则）。（1）再现：尽量三次再现故障。如果）再现：尽量三次再现故障。如果问题是间断的，那要报告问题发生频率。问题是间断的，那要报告问题发生频率。（2）隔离：确定可能影响再现的变量，）隔离：确定可能影响再现的变量，例如配置变化、工作流、数据集，这些都例如配置变化、工作流、数据集，这些都可能改变错误的特征。可能改变错误的特征。（3）推广：确定系统其他部分是否可）推广：确定系统其他部分是否可能出现这种错误，特别是那些可能存在更能出现这种错误，特别是那些可能存在更加严重特征的部分。加严重特征的部分。（4）压缩：精简任何不必要的信息，）压缩：精简任何不必要的信息，特

32、别是冗余的测试步骤。特别是冗余的测试步骤。（5）去除歧义：使用清晰的语言，尤）去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义其要避免使用那些有多个不同或相反含义的词汇。的词汇。（6）中立：公正表达自己的意思，对）中立：公正表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。幽默或讽刺。（7）评审：至少有一个同行，最好是）评审：至少有一个同行，最好是一个有丰富经验的测试工程师或测试经理，一个有丰富经验的测试工程师或测试经理，在你递交错误报告之前先读一遍。在你递交错误报告之前先读一遍。为了说明一个基本的测试缺陷报告应为了说明一

33、个基本的测试缺陷报告应该具有的内容，截取了本章所介绍案例该具有的内容，截取了本章所介绍案例HIS1.0中挂号管理子系统集成测试缺陷报中挂号管理子系统集成测试缺陷报告中的一页，如图告中的一页，如图8-5所示。所示。8-5 图测试缺陷报告示例8.6 测试结果总结分析8.6.1测试总结报告图图8-6所示的是测试总结报告的一个模所示的是测试总结报告的一个模板，各行业、各阶段的软件测试会有具体板，各行业、各阶段的软件测试会有具体不同的总结报告，但基本上应该有本模板不同的总结报告，但基本上应该有本模板所展示的项目。所展示的项目。*测试报告 项目编号：项目名称：项目软件经理：测试负责人：测试时间：测试目的与

34、范围：测试环境 名称 软件版本 服务器操作系统 数据库 应用服务器 测试软件 测试机操作系统 测试数据说明：总体分析：典型性具体测试结果：8-6 图测试总结报告的一个模板8.6.2测试用例分析对工作的及时总结，会及时调整方向，对工作的及时总结，会及时调整方向，大大提高工作效率。测试工作的效果要直大大提高工作效率。测试工作的效果要直接依赖测试用例的编写和执行状况，所以接依赖测试用例的编写和执行状况，所以在测试过程中和测试结束后都要对关于测在测试过程中和测试结束后都要对关于测试用例的一些重要值进行度量。试用例的一些重要值进行度量。关于测试用例的分析，通常包括以下的关于测试用例的分析，通常包括以下的

35、内容：内容：计划了多少个测试用例，实际运行了多计划了多少个测试用例，实际运行了多少？少？有多少测试用例失败了？有多少测试用例失败了？在这些失败的测试用例中，有多少个在在这些失败的测试用例中，有多少个在错误得到修改后最终运行成功了？错误得到修改后最终运行成功了？这些测试平均占用的运行时间比预期的这些测试平均占用的运行时间比预期的长还是短？长还是短？有没有跳过一些测试？如果有，为什么？有没有跳过一些测试？如果有，为什么？测试覆盖了所有影响系统性能的重要事测试覆盖了所有影响系统性能的重要事件吗？等等。件吗？等等。这些问题都可以从相关的测试用例的设这些问题都可以从相关的测试用例的设计和测试问题记录中找

36、到相应的答案。当然，计和测试问题记录中找到相应的答案。当然，如果使用了数据库，这些问题就更能轻松地如果使用了数据库，这些问题就更能轻松地被解答了。测试用例的分析报告可以以多种被解答了。测试用例的分析报告可以以多种形式体现出来：文字描述、表、图等。形式体现出来：文字描述、表、图等。8.6.3软件测试结果统计分析软件测试结果统计分析软件问题统计与分析，在对软件产品测试过程软件问题统计与分析，在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基础中发现的问题进行充分分析、归纳和总结的基础上，由全体参与测试的人员完成上，由全体参与测试的人员完成“软件问题倾向软件问题倾向分析表分析表”，对该软件

37、或该类型系统软件产品在模，对该软件或该类型系统软件产品在模块、功能及操作等方面出错倾向及其主要原因进块、功能及操作等方面出错倾向及其主要原因进行分析。软件问题倾向分析表将为以后开发工作行分析。软件问题倾向分析表将为以后开发工作提供一个参考，使开发人员根据软件问题倾向分提供一个参考，使开发人员根据软件问题倾向分析表明确在开发过程中应注意和回避的问题。该析表明确在开发过程中应注意和回避的问题。该表也可为以后的测试工作明确测试重点提供依据。表也可为以后的测试工作明确测试重点提供依据。图图8-7表达的是软件的不同版本在测试表达的是软件的不同版本在测试时检测出的缺陷时检测出的缺陷(Bug)数的对应关系。

38、这里数的对应关系。这里的版本指的是同一软件经过不同的测试阶的版本指的是同一软件经过不同的测试阶段并修复段并修复 Bug及作必要的调整后所产生的及作必要的调整后所产生的软件产品。显然，该图所表达的测试结果软件产品。显然，该图所表达的测试结果的变化是非常理想的。的变化是非常理想的。120 100 80 60 40 20 0 1 按版本统计结果 Bug数 2 3 版本 4 5 图8-7 按版本统计结果示例图图8-8表达的是在一个测试阶段所发现的表达的是在一个测试阶段所发现的缺陷数与测试日期之间的对应关系。测试过缺陷数与测试日期之间的对应关系。测试过程中所发现的缺陷是随着时间的推移而增多程中所发现的缺

39、陷是随着时间的推移而增多的，但一段时间后，测试所发现的缺陷增加的，但一段时间后，测试所发现的缺陷增加会渐缓，甚至没有增加，如果测试还在进行，会渐缓，甚至没有增加，如果测试还在进行，那么表明，在现有测试用例、软硬件环境及那么表明，在现有测试用例、软硬件环境及相关条件下已经很难再发现新的缺陷了（虽相关条件下已经很难再发现新的缺陷了（虽然可以肯定系统中仍然存在缺陷），那么这然可以肯定系统中仍然存在缺陷），那么这个测试阶段应该考虑停止了。个测试阶段应该考虑停止了。按日期统计结果 200 180 160 140 120 100 80 60 40 20 0 Bug数 1 2 3 4 5 6 7 8 9 1

40、0 11 12 13 14 15 16 17 18 19 20 日期 图8-8 按日期统计结果示例图图8-9表达的是测试中所发现的不同等表达的是测试中所发现的不同等级的缺陷的数目。关于级的缺陷的数目。关于 A、B、C、D等级等级（或者还有（或者还有E、F、G、）所表达的不同）所表达的不同含义由相关测试和开发人员来制定，而这含义由相关测试和开发人员来制定，而这种按等级的统计结果可以清楚地反映开发种按等级的统计结果可以清楚地反映开发工作中的薄弱之处。工作中的薄弱之处。按等级统计果 结140 120 100 80 60 40 20 0 A B C D 等级 图8-9 按等级统计结果示例Bug 数 B

41、ug数 图图8-10表达的是测试所发现的缺陷数表达的是测试所发现的缺陷数目与究其原因缺陷所属的软件工程的不同目与究其原因缺陷所属的软件工程的不同阶段之间的关系。这个图表会又一次验证阶段之间的关系。这个图表会又一次验证软件工程的任何阶段都会有导致程序中产软件工程的任何阶段都会有导致程序中产生错误的因素，只是程度和数目不同而已。生错误的因素，只是程度和数目不同而已。通过该图表的分析，可以清楚地看到，软通过该图表的分析，可以清楚地看到，软件工程中的哪个阶段更应该加强控制。件工程中的哪个阶段更应该加强控制。200 按原因统结果 计Bug数 150 100 50 0 需求 设计 原因 编码 测试 图8-

42、10 按原因统计结果示例图图8-11表达的是程序的不同模块与在表达的是程序的不同模块与在其中所发现的缺陷数目之间的关系。缺陷其中所发现的缺陷数目之间的关系。缺陷的产生有多方面的原因，但也可以从该图的产生有多方面的原因，但也可以从该图中反映出哪些程序员所开发的模块中中反映出哪些程序员所开发的模块中Bug很多，而另一些程序员的则很少，那么在很多，而另一些程序员的则很少，那么在相同的系统设计和工作条件下，这也反映相同的系统设计和工作条件下，这也反映了程序员的工作能力或者责任感的不同。了程序员的工作能力或者责任感的不同。50 40 按模块计 统Bug数 30 20 10 0 M1 M2 M3 M4 M

43、5 M6 M7 M8 模块 图8-11 按模块统计结果示例图图8-12表达的是在测试过程中每日发现表达的是在测试过程中每日发现的错误报告公开、关闭的对应关系图。公的错误报告公开、关闭的对应关系图。公开是指错误被发现并被公告，关闭则指错开是指错误被发现并被公告，关闭则指错误已被处理完毕的状况。图中中间两条粗误已被处理完毕的状况。图中中间两条粗线反映的是错误累计公开和累计关闭的实线反映的是错误累计公开和累计关闭的实际状况。随着时间的推移，累计公开和累际状况。随着时间的推移，累计公开和累计关闭的错误数目都是渐增的，但到某个计关闭的错误数目都是渐增的，但到某个时间点，两条曲线会会合，即累计公开的时间点

44、，两条曲线会会合，即累计公开的数目等于累计关闭的数目，那就是说所有数目等于累计关闭的数目，那就是说所有发现的错误都得到了处理。发现的错误都得到了处理。图8-12 按公开/关闭日期统计图表图图8-13表达的是错误原因分析，其中纵轴表达的是错误原因分析，其中纵轴表达的是每类测试发现错误占所有错误的百表达的是每类测试发现错误占所有错误的百分比。可以看出，只有每个错误都被明确细分比。可以看出，只有每个错误都被明确细致地归类后才能得到这样的分析图表，也才致地归类后才能得到这样的分析图表，也才能知道该从哪里去控制以减少错误的产生。能知道该从哪里去控制以减少错误的产生。图8-13 错误原因分析图图8-14表

45、达的是对系统性能测试所产生表达的是对系统性能测试所产生的分析数据、图和简单的结论。这种分析的分析数据、图和简单的结论。这种分析是在系统经过性能测试后所必不可少的。是在系统经过性能测试后所必不可少的。性能测试的分析一般从并发用户数、系统性能测试的分析一般从并发用户数、系统响应时间以及响应时间以及CPU的利用率几方面来表述。的利用率几方面来表述。0 响应时间（秒）1 CPU 利用率（%）响应时间（秒）CPU 利用率（%）20 1.8 32%2.3 45%10 万 2 37%4.9 38%20 万 2.7 40%9.2 42%30 万 3 39%9.7 56%40 万 5.1 41%16.5 49%

46、10 Testcase1:材料收报查询 响应时间 15 10 5 0 0 10 万 20 万 已注册药品数 30 万 40 万 单用户 并发 10 人 结果分析：通过数据显示在 30 万的基础数据量下，并发 10 人查询的响应时间为 9.7 秒，可以接受；但在 40 万数据量下并发 10 人达到了 16.5 秒，变化较大。图8-14 系统响应时间与用户数对比分析（性能测试结果分析）8.7 应 用 测 试 工 具实际测试需要投入大量的时间和精力，实际测试需要投入大量的时间和精力，测试工作同样也可以采用其他领域和行业测试工作同样也可以采用其他领域和行业中运用多年的办法中运用多年的办法开发和使用工具

47、，开发和使用工具，即自动化测试使工作更加轻松和高效。采即自动化测试使工作更加轻松和高效。采用测试工具不但能提高效率，节约成本，用测试工具不但能提高效率，节约成本，还可以模拟许多手工无法模拟的真实场景。还可以模拟许多手工无法模拟的真实场景。当建立一个新的测试项目时，测试工具当建立一个新的测试项目时，测试工具会自动生成测试代码，用户可以根据需要会自动生成测试代码，用户可以根据需要进行修改，自动测试工具再执行这些代码。进行修改，自动测试工具再执行这些代码。图图8-15显示的是测试工具在建立一个新的显示的是测试工具在建立一个新的测试项目时产生的原始代码和测试执行记测试项目时产生的原始代码和测试执行记录

48、，只是截取了其中的片断。这些代码很录，只是截取了其中的片断。这些代码很冗长，可不用担心，一切都是自动测试工冗长，可不用担心，一切都是自动测试工具为你生成的。具为你生成的。图自动测试工具所生成的代码8-15 为了测试挂号管理子系统的并发性控制，为了测试挂号管理子系统的并发性控制，按照前面的测试用例，选择按照前面的测试用例，选择 10用户并发执用户并发执行，每用户连续执行行，每用户连续执行200次停止。如图次停止。如图8-16所示的是增加用户进程控制界面。所示的是增加用户进程控制界面。10用户用户可以一起加入，而模拟可以一起加入，而模拟 3000用户时，可以用户时，可以批量加入用户，如每批量加入用

49、户，如每 5分钟加入分钟加入600用户，用户，这样可能更接近于实际场景。这样可能更接近于实际场景。图图8-16 增加用户进程的界面增加用户进程的界面脚本开始运行后，脚本开始运行后，Load Runner会跟踪会跟踪被测试系统的运行状况以及监控被测试设被测试系统的运行状况以及监控被测试设备的资源使用情况，如图备的资源使用情况，如图8-17所示。所示。图图8-17 自动测试监控场景自动测试监控场景8.8 文 档 测 试广义地说，文档测试也是软件测试的一广义地说，文档测试也是软件测试的一项内容。文档测试包括对系统需求分析说明项内容。文档测试包括对系统需求分析说明书、系统设计报告、用户手册以及与系统相

50、书、系统设计报告、用户手册以及与系统相关的一切文档、管理文件的审阅、评测。关的一切文档、管理文件的审阅、评测。系统需求分析和系统设计说明书中的系统需求分析和系统设计说明书中的错误将直接带来程序的错误；而用户手册错误将直接带来程序的错误；而用户手册将随着软件产品交付用户使用，是产品的将随着软件产品交付用户使用，是产品的一部分，也将直接影响用户对系统的使用一部分，也将直接影响用户对系统的使用效果，所以任何文档的表述都应该清楚、效果，所以任何文档的表述都应该清楚、准确，含糊不得。准确，含糊不得。文档测试时应该慢慢仔细阅读文字。特文档测试时应该慢慢仔细阅读文字。特别是用户手册，应完全根据提示操作，将别