软件测试第11章.pptVIP

11.3.4 验收测试 验收测试是指在用户对软件系统验收之前组织的系统测试。测试人员都是真正的用户，在尽可能真实的环境下进行操作，并将测试结果进行汇总，由相关管理人员对软件做出评价以及是否验收的决定。 HIS系统一般在用户验收之前都需要对系统进行一段时间的试运行，因此可以说HIS的验收测试就是实际的使用（但用户一般要参与软件的系统测试，即所谓的 ? 测试，不然用户是不会放心让系统试运行的）。 因为验收测试由用户完成，不同软件实际应用的差异性又很大，这里就不对其详加论述了。 11.4 测 试 用 例 设 计 测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设计是测试系统开发中一项非常重要的内容。集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员充分交互。另外有一些内容由测试人员的相关背景知识、经验、直觉等产生。 测试用例的设计需要考虑很周全。在测试系统功能的同时，还要检查系统对输入数据（合法值、非法值和边界值）的反应，要检查合法的操作和非法的操作，检查系统对条件组合的反应等。好的测试用例让其他人能够很好地执行测试，能够快速地遍历所测试的功能，能够发现至今没有发现的错误。所以测试用例应该由经验丰富的系统测试人员来编写，对于新手来说，应该多阅读一些好的测试用例，并且在测试实践中用心去体会。 在编写测试用例之前，应该给出测试大纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是顾此失彼。测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。 本节给出“医院信息管理系统1.0”的“门诊挂号管理子系统”的测试大纲和测试用例的主体部分。 11.4.1 挂号管理子系统测试大纲 11.4.2 其他可用性测试检查标准 软件产品的可用性是指软件产品能否让用户更快更容易地完成工作，即软件是否易学、易用，并使用户感到满意。软件产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现，提高用户工作效率，增加用户满意度。 对于开发商而言可以缩减服务和培训费用，提高用户满意度。软件可用性已经越来越引起用户和开发商的关注。可用性测试对所有功能模块来说，检测标准是相同的，而这些检测在功能测试的同时即可检验，所以不再设计单独的测试用例。 11.4.3 功能测试用例 1．普通挂号，要病历本的测试用例 2．预约挂号，老患者，不要病历本的测试用例 3．预约挂号，不要病历本，无挂号费有诊察费的测试用例 4．有挂号费无诊察费，要病历本的测试用例 5．退号，不退病历本的测试用例 6．退号测试用例，包括病历本的测试用例 7．挂号员结算的测试用例 8．挂号员结算补打的测试用例 11.4.4 性能测试用例 11.5 缺 陷 报 告 这里给出一个利用数据作缺陷记录报告的实例。错误跟踪数据库可以自己开发，也可以购买现成的产品。 11.5.1 建立缺陷报告数据库 缺陷报告数据库应该在测试工作的准备配置阶段就建立起来，测试执行阶段，测试人员、开发人员和项目管理评估人员可以采用各种方式通过缺陷报告数据库进行交互，而可以自行开发一个小系统，使得数据库能够记录下人们访问数据库的一切活动。 先设计一个缺陷记录的数据表结构。 11.5.2 编写缺陷报告 关于测试人员、系统开发人员和相关问题评审人员打开、读取和写入缺陷报告数据库，以何种形式并不重要，重要的是对于问题的描述应该是完整的、严谨的、简洁的、清晰的和准确的。 下面列出编写好的错误报告的几个要点（也是测试执行应该遵循的一些原则）。 （1）再现：尽量三次再现故障。如果问题是间断的，那要报告问题发生频率。 （2）隔离：确定可能影响再现的变量，例如配置变化、工作流、数据集，这些都可能改变错误的特征。 （3）推广：确定系统其他部分是否可能出现这种错误，特别是那些可能存在更加严重特征的部分。 （4）压缩：精简任何不必要的信息，特别是冗余的测试步骤。 （5）去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。 （6）中立：公正表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。 （7）评审：至少有一个同行，最好是一个有丰富经验的测试工程师或测试经理，在你递交错误报告之前先读一遍。 为了说明一个基本的测试缺陷报告应该具有的内容，截取了本章所介绍案例HIS1.0中挂号管理子系统集成测试缺陷报告中的一页