搜索
本章介绍的被测试软件项目是医院信息管理系统（HIS，HospitalInformationSystem）。HIS是一个集成度很高的项目，因为行业的关系其中有一些词汇可能不被大家所了解，但这并不妨碍说清楚它的测试过程。本章要重点描述的测试过程是HIS的集成测试，该阶段的测试重点在功能测试上，也有必要的性能测试。后面依次给出了HIS集成测试阶段的测试计划、测试用例、缺陷（错误）报告、测试结果总结与分析等内容。测试用例将针对HIS的一个子系统——门诊挂号管理子系统来设计。该子系统不但包含了对数据库的应用，对系统的并发性、安全性、准确性、高效性都有很高的要求，可谓麻雀虽小，五脏俱全，适合将其进行剖析。8.1被测试软件项目介绍8.1.1软件背景医院信息管理系统（HIS）包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程。各子系统所处理的业务前后衔接，数据共享。医院信息管理系统的系统结构如图8-1所示。图8-1HIS1.0系统结构图8.2HIS测试过程概述HIS的测试按照一般测试过程，将其分为单元测试、集成测试、系统测试和验收测试4个阶段。8.2.1单元测试单元测试常常是动态测试和静态测试两种方式并举的。动态测试可由开发人员去运行局部功能或模块以发现系统潜藏的错误，也可以借助测试工具去测试。静态测试即是代码审查。审查的内容包括代码规则和风格，程序设计和结构，业务逻辑等。HIS系统中涉及到许多的费用计算问题，逻辑性很强，需要程序结构也很复杂。面对复杂的业务流程，面对管理各异的用户需求，没有白盒测试是不可想像的。最简单的例子：HIS中要处理很多类的患者，普通患者、医保患者、内部职工、公费患者等，每类患者的费用处理流程和计算方法都不相同，开发人员就要严格地依照系统设计去检查代码的逻辑结构，选取有代表性的测试用例去测试相关的模块。又如医嘱分解，药房摆药等，必须知道系统的详细设计和程序的逻辑结构才能设计好测试用例。8.2.2集成测试集成测试（有时被分为集成测试和确认测试两个阶段）是指将各模块组装起来进行测试，以检查与设计相关的软件体系结构的有关问题，并确认软件是否满足需求规格说明书中确定的各种需求。HIS系统的集成测试是指开发人员完成了所有系统模块的开发并通过了单元测试后，将编译好的软件交付给测试部门进行测试的过程。这个阶段的测试需要一个完备的测试管理过程。集成测试过程可以分为测试准备、测试计划、测试设计、测试执行和测试总结5个阶段。测试准备阶段是指测试人员准备测试资源，熟悉系统的过程。测试计划阶段包含制定测试策略、资源分配、风险预警和进度安排等内容，此项工作由测试负责人来做。8.3节中给出了HIS集成测试的测试计划。测试计划的模板各不相同，这个取决于软件的特殊性和管理的规范性。测试设计阶段包括设计测试用例及相关管理工具的设计。8.4节将给出HIS集成测试过程中挂号管理子系统部分的主要测试用例，侧重于系统的功能和性能测试。测试用例设计之前一般要有一个测试用例的设计大纲。完成测试设计工作后，就开始执行实际的测试工作了。测试时另外一项非常重要的工作就是做好系统缺陷记录。本章8.5节将给出系统生成缺陷报告的注意事项以及缺陷报告的实例，另外还设计了一个问题记录数据库表。用数据库记录缺陷的好处是测试人员和开发人员能够通过动态的信息发布和获取进行更好的交互，提高测试和修改的工作效率。经过修改后的系统再次经过测试即是回归测试。测试结束后要及时总结分析测试结果。测试结果的总结与分析一方面是提供一个系统功能、性能和稳定性等方面的完整的分析和结论，另外要对测试过程本身做出总结，总结成功的经验和失败的教训，以使日后的工作开展得更顺利。具体的测试总结详见8.6节。8.2.3系统测试系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。系统测试也应该经过测试准备、测试计划、测试设计、测试执行和测试总结5个阶段，每个阶段所做工作内容与集成测试很相似，只是关注点有所不同。在HIS系统的系统测试中，要搭建更真实的运行环境，另外还要在不同的操作系统下进行测试，如数据库服务器分别搭建在UNIX环境和WINNT环境下长时间多客户端并发运行系统的各项功能，并观测服务器的承受能力（系统的反应时间，服务器的资源占用情况等）。8.2.4验收测试验收测试是指在用户对软件系统验收之前组织的系统测试。测试人员都是真正的用户，在尽可能真实的环境下进行操作，并将测试结果进行汇总，由相关管理人员对软件做出评价以及是否验收的决定。HIS系统一般在用户验收之前都需要对系统进行一段时间的试运行，因此可以说HIS的验收测试就是实际的使用（但用户一般要参与软件的系统测试，即所谓的测试，不然用户是不会放心让系统试运行的）。因为验收测试由用户完成，不同软件实际应用的差异性又很大，这里就不对其详加论述了。8.3测试计划测试计划工作的提交成果是一份完整的测试计划报告。下面给出医院信息管理系统1.0版集成测试的测试计划报告。8.3.1概述本测试项目拟对医院信息管理系统（HIS）1.0进行测试。医院信息管理系统包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程，各子系统所处理的业务前后衔接，数据共享。测试的目标是要找出影响医院信息管理系统正常运行的错误，分别在功能、性能、安全性等方面检验系统是否达到相关要求。本次集成测试采用黑盒和白盒测试技术（重点在黑盒测试）。测试手段为手工与自动测试相结合（主要依靠手工进行功能测试，依靠自动测试工具进行性能测试）。本测试计划面向相关项目管理人员、测试人员和开发人员。8.3.2定义质量风险：被测试系统不能实现描述的产品需求或系统不能达到用户的期望的行为，即系统可能存在的错误。测试用例：为了查找被测试软件中的错误而设计的一系列的操作数据和执行步骤，即一系列测试条件的组合。测试工具：应用于测试用例的硬件/软件系统，用于安装或撤销测试环境、创造测试条件，执行测试，或者度量测试结果等工作。测试工具独立于测试用例本身。进入标准：一套决策的指导方针，用于决定项目是否准备好进入特定的测试阶段。在集成测试和系统测试阶段，进入标准会很苛刻。退出标准：一套标准，用于决定项目是否可以退出当前的测试阶段，或者进入下一个测试阶段或者结束项目。同进入标准，测试过程的后几个阶段退出标准一般很苛刻。功能测试：集中于功能正确性方面的测试。功能测试必须和其他测试方法一起处理潜在的重要的质量风险，比如性能、负荷、容积和容量等。8.3.3质量风险摘要危险性：表示故障对系统影响的大小。5—致命；4—严重；3—一般；2—轻微；1—无。影响：5—一定影响所有用户；4—可能影响一些用户；3—对有些用户可能的影响；2—对少数用户有限的影响；1—在实际使用中难以觉察的影响。优先级：表示风险可以被接受的程度。5—很紧急，必须马上纠正；4—不影响进一步测试，但必须修复；3—系统发布前必须修复；2—如果时间允许应该修复；1—最好修复。8.3.4测试进度计划8.3.5进入标准（1）“测试小组”配置好软硬件环境，并且可以正确访问这些环境。（2）“开发小组”已完成所有特性和错误修复并完成修复后的单元测试。（3）“测试小组”完成“冒烟测试”，程序包能打开，随机的测试操作正确完成。8.3.6退出标准（1）“开发小组”完成了所有必须修复的错误。（2）“测试小组”完成了所有计划的测试。没有优先级为3以上的错误。优先级为2以下的错误少于5个。（3）“项目管理小组”认为产品实现稳定性和可靠性。8.3.7测试配置和环境服务器1台：HPPentiumⅢ550，1GB内存，8.4GB硬盘；软件环境：WindowsNT，Oracle。客户机10台：PentiumMMX166，1.2GB硬盘，32MB内存；软件环境：Oracle客户端。打印机1台：PanasonicKX-P1131。地点：58号楼101室。8.3.8测试开发设计测试用例以进行手工测试。准备使用MILoadRunner，以检测系统对并发性的控制和系统的强壮性。设计开发问题记录及交互工具，包括问题存取控制系统及所对应的数据库，以对测试结果做很好的记录并提供相关测试和开发人员的交互平台。8.3.9关键参与者测试经理：宋欣欣（制定测试计划及部署、监督相关工作）。测试人员：蔡亮，邱实，崔进，赫北松，洪怡，武刚，沙盼盼，王军妹（负责相关子系统测试）。开发人员：王铁全，李云帆，夏淼，张铁（及时解决影响测试进行的系统问题）。项目管理人员：王斌（跟踪项目进展）。8.3.10预算8.3.11参考文档8.4测试用例测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设计是测试系统开发中一项非常重要的内容。集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员充分交互。另外有一些内容由测试人员的相关背景知识、经验、直觉等产生。测试用例的设计需要考虑很周全。在测试系统功能的同时，还要检查系统对输入数据（合法值、非法值和边界值）的反应，要检查合法的操作和非法的操作，检查系统对条件组合的反应等。好的测试用例让其他人能够很好地执行测试，能够快速地遍历所测试的功能，能够发现至今没有发现的错误。所以测试用例应该由经验丰富的系统测试人员来编写，对于新手来说，应该多阅读一些好的测试用例，并且在测试实践中用心去体会。在编写测试用例之前，应该给出测试大纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是顾此失彼。测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。本节给出“医院信息管理系统1.0”的“门诊挂号管理子系统”的测试大纲和测试用例的主体部分。8.4.1挂号管理子系统测试大纲8.4.2其他可用性测试检查标准软件产品的可用性是指软件产品能否让用户更快更容易地完成工作，即软件是否易学、易用，并使用户感到满意。软件产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现，提高用户工作效率，增加用户满意度。对于开发商而言可以缩减服务和培训费用，提高用户满意度。软件可用性已经越来越引起用户和开发商的关注。可用性测试对所有功能模块来说，检测标准是相同的，而这些检测在功能测试的同时即可检验，所以不再设计单独的测试用例。8.4.3功能测试用例1．普通挂号，要病历本的测试用例2．预约挂号，老患者，不要病历本的测试用例3．预约挂号，不要病历本，无挂号费有诊察费的测试用例4．有挂号费无诊察费，要病历本的测试用例5．退号，不退病历本的测试用例6．退号测试用例，包括病历本的测试用例7．挂号员结算的测试用例8．挂号员结算补打的测试用例8.4.4性能测试用例8.5缺陷报告这里给出一个利用数据作缺陷记录报告的实例。错误跟踪数据库可以自己开发，也可以购买现成的产品。8.5.1建立缺陷报告数据库缺陷报告数据库应该在测试工作的准备配置阶段就建立起来，测试执行阶段，测试人员、开发人员和项目管理评估人员可以采用各种方式通过缺陷报告数据库进行交互，而可以自行开发一个小系统，使得数据库能够记录下人们访问数据库的一切活动。先设计一个缺陷记录的数据表结构。8.5.2编写缺陷报告关于测试人员、系统开发人员和相关问题评审人员打开、读取和写入缺陷报告数据库，以何种形式并不重要，重要的是对于问题的描述应该是完整的、严谨的、简洁的、清晰的和准确的。下面列出编写好的错误报告的几个要点（也是测试执行应该遵循的一些原则）。（1）再现：尽量三次再现故障。如果问题是间断的，那要报告问题发生频率。（2）隔离：确定可能影响再现的变量，例如配置变化、工作流、数据集，这些都可能改变错误的特征。（3）推广：确定系统其他部分是否可能出现这种错误，特别是那些可能存在更加严重特征的部分。（4）压缩：精简任何不必要的信息，特别是冗余的测试步骤。（5）去除歧义：使用清晰的语言，尤其要避