系统测试——软件测试的艺术

系统测试有着特定的目的：将系统或程序与其初始目标进行比较，给定目标后有两含义：

1. 系统测试不局限于系统，若产品是一个程序：系统测试就是试图说明程序作为一个整体是如何不满足其目标的过程
2. 根据定义，若产品没有一组书面的、可度量的目标，系统测试就无法进行

在寻找程序与其目标之间的不一致的过程中，应重点注意那些在设计外部规格说明的过程中所犯的转换错误。系统测试因而成为一种关键的测试类型，因为就软件产品本身、所犯错误的数量及其严重性而言，开发周期的这个阶段是最易出错的

这也暗示与功能测试的情况不同，外部规格说明不能作为获得系统测试用例的基础，否则就破坏了系统测试的目标。然而另一方面，也不能利用目标文档本身来表示测试用例，因为根据定义，这些文档并不包含对程序外部接口的准确描述

克服两难局面的方法是利用程序的用户文档或书面材料：通过分析目标文档来设计系统测试，分析用户文档来阐明测试用例。该方法能够产生两方面的作用：

• 将程序与其目标和用户文档相比较
• 将用户文档与程序目标相比较
  
  将程序与程序目标进行比较【系统测试的核心目的】，却不说明用什么测试用例设计方法。因为目标文档阐述了程序该做什么、做到什么程度，却不说明程序功能如何体现
  如何编写测试用例，以试图证明程序与目标文档中每条语句都存在着不一致性。因此，系统测试采取了一种不同的测试用例设计方法:不是描述一项技术，我们讨论的是不同类型的系统测试用例。由于没有一个方法，系统测试需要大量的创造性

15种测试用例（并非适合所有程序，为避免遗漏而提出

• 能力测试
  最明显的系统测试类型是判断目标文档提及的每一项能力(避免与功能测试发生混滑而不使用“功能”一词)是否都确实已经实现
  能力测试的过程是逐条语句地检查目标文档，当某条语句定义了一个“要做什么”(例如， “语法应该- …“用户应当可以指定一个空间范围…等)，就判断程序是否满足。此种类型的测试常常可以在不使用计算机的情况下进行，有时人工对目标和用户文档进行比较就足够了。尽管如此，利用问题检查单将有助于在下一次进行测试时，确保人工检查的目标是相同的。
• 容量测试
  使程序经受大容量数据的检验。举例来说，编译器可能要编译规模非常庞大的源程序，连接编辑器可能需要处理一个包含上千模块的程序，电子电路模拟器可能要输入一个包含上T部件的电路，而操作系统的作业队列可能已经达到饱和的容量。如果程序需要处理跨越不同卷的文件，则应产生足够的数据使程序从一个卷转换到另一个中。换言之，容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量
  由于容量测试显然需要大量的资源，鉴干对机器和工时的考虑，不可进行过多的容量测试【每个程序应该至少进行几次容量测试】
• 强度测试
  强度测试使程序承受高负载或强度的检验。这不应和容量测试发生混淆:所谓高强度是指在很短的时间间隔内达到的数据或操作数的最峰值。
  如测试一名打字员。容量测试是判断打字员能否处理大篇幅的稿子，强度测试则是判断打字员能否达到每分钟50个单词的速度
  由于强度测试涉及时间因素，因此， 它不适用于很多程序，如编详器或批处理工资程序。然而，强度测试适用于在可变负载下运行的程序，以及交互式程序、实时程序和过程控制程序。假如某个空中交通控制系统要求在其区域内最多可跟踪200架飞机，则可以通过模拟200架飞机存在的情况来对其进行强度测试。由于在客观上无法避免第201架飞机进入该区域，因此需要进一步的强度测试，考察系统的反应
  常用于基于web的应用程序
• 易用性测试
  发现人为因素或易用性的问题：
  1.每个用户界面是否都根据最终用户的智力、教育背景和环境要求而进行了调整?
  2.程序的输出是否有意义、不模糊且没有计算机的杂乱信息?
  3.错误诊断{如错误信息)是否直接，用户是否需要有计算机学科的博七学位才能理解？
  4.整体的用户界面是否在语法、惯例、语义、格式、风格和缩写方面展现出了相当程度的概念完整性、基本的一致性和统一性?
  5.在准确性极为重要的环境里，如网上银行系统,输人中是否有足够的冗余信息?eg:该系统可能会要求输人帐号、用户名和PIN (个人识别号)来验证访问帐户信息的是合法用户
  6.系统是否包含过多或不太可能用到的选项?现代软件的一个趋势是，仅向用户提供那些基于软件测试和设计考虑而确定出的最有可能使用的菜单选项。一个设计良好的软件可以向用户学习，并开始向不同的用户展示其经常访问的菜单项。即使已经有了这样智能化的菜单系统，仍需要设计成功的软件，使得对不同选项的访问合乎逻辑、符合直觉。
  7.对于所有的输入，系统是否返回了某些类型的即时确认信息?举例来说，在点击鼠标进行输入的环境里，被选项可以变换颜色，或者某个按钮对象可以显示凹进或凸起的状态。如果要让用户从列表中选择，那么当用户作出选择后被选序号应显示在屏幕上。还有，如果被选的操作需要一些运行时间(如果软件正在访问一个远程的系统)，那么应显示一条信息通知用户当前正在做什么
  8.程序是否易于使用?eg：如果输入是区分大小字符的，这一点对用户来说是否清楚?如果程序要求浏览一系列的菜单或操作，那么返回到主菜单的方法是否清楚?用户是否可以很容易浏览到上一层或下一层?
• 安全性测试
  社会对个人隐私的日益关注，许多软件都有特别的安全性目标。安全性测试是设计测试用例来突破程序安全检查的过程。举例来说，设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制
  设计此种测试用例的方法之一是研究类似系统中已知的安全问题，然后生成测试用例，尽量暴露被测系统存在相似问题。例如，在杂志.聊天室和新闻组中发布的资料，经常包含有操作系统或其他软件系统的已知错误。通过在与被测软件提供相似服务的现有系统中搜寻安全漏洞，可以设计测试用例来判断软件是否受到类似问题的困扰
  基于Web的应用程序常常比绝大多数程序所需的安全测试级别更高。对于电子商务网站尤其如此。尽管已经有了足够多的技术(例如密码学)允许客户在因特网上安全地完成交易，但不能单纯依赖技术的应用来确保安全。除此之外，我们必须向客户群证明软件是安全的，否则就会有失去客户的风险
• 性能测试
  很多软件都有特定的性能/效率目标，这些特性描述为在特定负载和配置环境下程序的响应时间和吞吐率
• 存储测试
  软件偶尔会有存储目标，举例来说，可能描述了程序使用的内存和辅存的容量,以及临时文件或溢出文件的大小，应设计测试用例来证明这些存储目标没有得到满足
• 配置测试
  诸如操作系统.数据库管理系统和信息交换系统等软件都支持多种硬件配置，包括不同类型和数量的I/O设备和通信线路，或不同的存储容量。通常可能的配置数量非常之大,以致于测试无法面面俱到，但是至少应该使用每一种类型的设备，以最大和最小的配置来测试程序。如果软件本身的配置可忽略掉某些程序组件，或可运行在不同的计算机上,那么该软件所有可能的配置都应测试到
  如今的很多软件都设计成可运行在多种操作系统下，因此如果测试此类程序，应该在该程序面向的所有操作系统环境中对其进行测试。对设计在Web浏览器里运行的程序，需要特别的注意，因为Web浏览器的种类繁多，并不是所有浏览器都按同样方式运行，即使是同一种Web浏览器，在不同的操作系统之下，运行方式也会不同
• 兼容性/配置/转换测试
  大多数开发的软件都并不是全新的，常常是为了替换某些不完善的系统。这样的软件往往有着特定的目标，涉及与现有系统的兼容以及从现有系统的转换过程。再次强调，在针对这些目标测试程序时，测试用例的目的是证明兼容性目标标未被满足，转换过程并未生效。在将数据从一个系统转移到另一个系统时，应尽力发现错误。升级数据库管理系统就是一个例子。需要确定现有的数据安置到了新的系统中。有很多不同的方法测试这个过程;但这些方法都高度依赖于所使用的数据库系统
• 安装测试
  有些类型的软件系统安装过程非常复杂。测试安装过程是系统测试中的一个重要部分。 对包含在软件包中的自动安装系统而言，尤其重要
  安装程序如果出现故障，会影响用户对软件的成功体验。用户的第一次体验来自干安装软件的过程。如果这个过程进行得很糟糕，用户或顾客就要么寻找其他的产品，要么对软件的有效性不抱太大信心
• 可靠性测试
  虽然所有类型的测试都是为了提高软件的可靠性，但是如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。测试可靠性目标可能很困难------->引一个归纳断言
• 可恢复性测试
  如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统测试的一个目标是证明这些恢复机制不能够正确发挥作用。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复
  如内存校验错误或I/O设备错误等硬件错误也可以进行模拟、通信线路中的噪音或数据库中的无效指针等数据错误可以故意生成或模拟出来，以分析系统的反应。这些系统的设计目标之一是使平均恢复时间(MTTR)最小。系统宕机往往会减少公司的收入。我们的一个测试目标是证明系统不能满足MTTR的服务合同
  MTTR往往有上界和下界，所以测试用例应反映出这些界限
• 适用性测试
  软件还可能有适用性或可维护性的目标。所有的此类目标都必须测试到。这些目标可能定义了系统提供的服务辅助功能，包括存储转存程序或诊断程序、调试明显问题的平均时间、维护过程以及内部业务文档的质量等
• 文档测试
  系统测试需要检查用户文档的正确性。完成此任务的主要方法是根据文档来确定系统测试用例的形式。也就是说，一旦设计完成某个具体的测试情况，应该使用文档来作为编写实际测试用例的指南。同时，用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，井提交给程序
• 过程测试
  很多软件都是较大系统的组成部分，这些系统并不完全是自动化的，包含了很多人员操作过程。在系统测试中，必须对所有已规定的人工过程(如系统操作员、数据库管理员或最终用户)的操作过程进行测试
  举例来说，数据库管理员必须记录备份和恢复数据库系统的操作过程。在可能的情况下,应由与数据库管理不相关的人来测试这些过程。然而，公司必须为充分测试这些过程而提供所需的资源，这些资源通常包括硬件和额外的软件许可证
• 系统测试的执行
  (1)不能由程序员来进行系统测试
  (2) 在所有的测试阶段之中，这是惟一一个明确地不能由负责该程序开发的机构来执行的测试
  第一点基于的事实是：执行系统测试的人思考问题的方式必须与最终用户相同，这意味着必须充分了解最终用户的态度和应用环境，以及程序的使用方式。那么显然的是，如果可行的话，一位或多位最终用户是很好的执行测试的候选人。但是，由于一般的最终用户都不具备执行很多前面所描述的测试类型的能力或专业技术，因此，理想的系统测试小组应由几位专业的系统测试专家(以执行系统测试作为职业)、一位或两位最终用户的代表一位人类工程学工程师以及该程序主要的分析人或设计者所组成。将原先的设计者包括进来并不违反测试原则【不提倡测试由自己编写的程序】因为程序自构思以来已经历经人手，所以原先的设计者不会再受到心理束缚的影响，对程序的测试不会再触及该原则
  第二点基于的事实是：系统测试是一项“随心所欲，百无禁忌”的活动，而软件开发机构会受到心理束缚，有悖于此项活动。而且大多数的开发机构最为关心的是让系统测试进行得尽可能顺利并按时完成，而不会尽力证明程序不能满足其目标。系统侧试至少应由很少(如果有的话)受开发机构左右的独立人群来执行。也许最经济的执行系统测试的方式(所谓经济，是指花一定的成本发现最多的错误，或利用更少的费用发现相同数量的错误)是将测试分包给一个独立的公司来完成