备考第12天——测试用例的编写

Posted 2021-03-06 archer-xin

测试设计说明

        为了更好地进行测试，我们需要为单个软件特性定义具体的测试方法，这就是测试设计说明。ANSSI/IEEE 829中对测试设计说明的解释是：测试设计说明就是在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断特性通过/失败的规则。

        测试设计说明的目的是组织和描述针对具体特性需要进行的测试。然而，它并不给出具体的测试用例或者执行测试的步骤。以下内容来自于ANSSI/IEEE 829标准，应该作为测试设计说明的部分内容。

• 标识符：用于引用和定位测试设计说明的唯一标识符。
• 要测试的特性：对测试设计说明所包含的软件特性的描述。例如“计算器程序的加法功能”。该部分还将明确指出要间接测试的特性，它通常作为主特性的辅助特性。例如，文件打开对话框的用户界面虽然不在测试设计说明中重点指出，但是测试读写功能的过程中要间接测试。
• 方法：描述测试的通用方法。如果方法在测试计划中列出，就应该在此详细描述要使用的技术，并给出如何验证测试结果的方法。例如，我们这样描述一种方法，开发一种测试工具，顺序读写不同大小的数据文件，数据文件的数目和大小及包含的内容由程序员提供的示例来确定。用文件比较工具比较输出的文件和源文件，如果相同，则认为通过；如果不同，则认为失败。
• 测试用例信息：用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用信息以及用于执行测试用例的测试程序说明。例如：“检查最大值  测试用例ID#15326”，在这部分不定义实际测试用例。
• 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。这种描述有可能非常简单和明确，例如“通过是指当执行全部测试用例时没有发现软件缺陷”。也有可能不是非常明确，例如“失败是指10%以上的测试用例没有通过”。

测试用例说明

        如何记录和记载创建的测试用例？如果你已经开始进行一些软件测试了，就可能采用过一些用例描述格式。ANSSI/IEEE 829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，同时还明确指出，使用具体测试用例产生的测试程序的限制。一个测试用例的编写可参考下表：

        测试用例应该解释要向软件发送什么值或者条件，以及预期结果。一个测试用例说明可以由多个测试用例说明来引用，也可以引用多个测试程序。ANSSI/IEEE 829标准还列出了一些应该包含在内的重要信息，如下：

• 标识符：由测试设计过程说明和测试程序说明引用的唯一标识符。
• 测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。如果测试设计说明提到“计算器程序的加法功能”，那么测试用例说明就会相应地提到“加法运算的上限溢出处理”。它还要指出引用的产品说明书或者测试用例所依据的其他设计文档。
• 输入说明：该说明列举执行测试用例的所有输入内容或者条件。如果测试计算器程序，输入说明可能简单到“1+1”。如果测试蜂窝电话交换软件，输入说明可能是成百上千种输入条件。如果测试基于文件的产品，输入说明可能是文件名和内容的描述。
• 输出说明：描述进行测试用例预期的结果。例如，1+1等于2吗？在蜂窝软件中上千的输出变量设置正确吗？读取文件的全部内容和预想的一样吗？
• 环境要求：是指执行测试用例必要的特殊要求。测试写字板程序也许不需要任何特殊条件，但是测试一些特殊的软件（如核电站软件）就有特殊要求。
• 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。

        如果按照这里推荐的文档格式，对于每一个测试用例至少都要写上一页的描述文字，数千个测试用例可能要形成千页文档。所以我们经常把ANSSI/IEEE 829标准当作规范而不是标准使用（除非必须这样做，许多政府项目和某些行业要求按照此规格编写测试用例，但是在大多数情况下可以采用简便方法）。

        采用简便方法并不是说放弃或者忽视重要的信息，而是意在找出一个更有效的方法对这些信息进行精简，例如，没有必要刻意要求不能用书面段落形式表述测试用例。如表5-15给出了一个打印机兼容性简单列表的例子。

        表中的每一行是一个测试用例，有自己的标识符。伴随测试用例的所有其他信息，例如测试项、输入说明、输出说明、环境要求、特殊要求和依赖性等对所有这些用例都必须有，可以一并编写，附加到表格中。审查测试用例的人可以快速看完测试用例信息，然后审查表格，检查其范围。

测试程序说明

        编写完测试设计和测试用例之后，就要说明执行测试用例的程序。什么是测试程序呢？ANSSI/IEEE 829标准把测试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。

        测试程序，有时也叫“测试脚本说明”，详细定义了执行测试用例的每一步操作。以下是需要定义的内容。

• 标识符：用来把测试程序与相关测试用例和测试设计相联系的唯一标识。
• 目的：本程序描述的目的以及将要执行的测试用例的引用信息。
• 特殊要求：执行测试所需的其他程序、特殊测试技术或特殊设备。
• 程序步骤：执行测试用例的详细描述。它包含以下内容。

    ①日志：指出用什么方法记录测试结果和想象。

    ②设置：说明如何准备测试。

    ③启动：说明启动测试的步骤。

    ④程序：描述运行测试的步骤。

    ⑤衡量标准：描述如何判断结果。

    ⑥关闭：描述因意外原因而推迟测试的步骤。

    ⑦终止：描述正常停止测试的步骤。

    ⑧重置：说明如何把环境恢复到测试前的状态。

    ⑨偶然事件：说明如何处理计划之外的情况。

        如果我们把测试程序只理解成“尝试执行所有的测试用例并报告发现的问题”是不够的。这虽然简单、容易，但是无法告诉新加入的测试员如何进行测试，不能重复而且无法证明哪些步骤执行了。使用详细的程序说明，则把要测试什么、如果测试等问题都表述得一目了然。如图5-12所示是“windows计算器”的测试程序说明的例子片断。

测试用例细节探讨

        俗话说“做什么都要适可而止”，测试用例计划也一样。测试用例计划包含四个目标，即组织性、重复性、跟踪和测试证实。开发测试用例的软件测试工程师要力争实现这些目标，但是其实现程度取决于行业、公司、项目和测试组的具体情况，通常也不太可能按照最细致的程度去编写测试用例。

        我们设计的测试用例计划要力求达到最佳的详细程度，比如，在一个测试程序中要求在PC机上安装windows2000来执行测试，测试程序在其部分声明需要windows2000，但是为声明windows2000的那个版本。那么一两年内出现新版本会怎么样？测试程序需要升级来反映这个变化吗？为了避免这个问题，可以省略具体的版本，而用“可用的最新版本”这样的说明来代替。

        无比详细的测试用例说明减少了测试的随机性，使测试可以很好地重复，使得无经验的测试人员按照测试用例说明也能执行测试。但是编写如此细致的测试用例说明要花费相当多的时间和精力，并且由于细节繁多，也会阻滞测试工作，造成测试执行时间变长。

        开始编写测试用例时，最好是采用当前项目的标准，同时需要根据ANSSI/IEEE 829标准定义的格式，看什么符合项目要求，并可以做适当的调整。不同的测试工程师设计的测试用例也会有所不同。通常有经验的测试工程师设计出的测试用例，在深度及广度上会比经验少的测试工程师要完整，这也是所谓的测试经验值。举例来讲，客户反映前一版V1.3的软件在windows98的环境下运行时，在屏幕保护程序激活后会产生问题，开发工程师将这问题解决并且已提交修改正版本供客户网络下载，并且目前开发工程师所开发的软件最新版本为V1.5版，软件测试工程师就必须在V1.5版的测试用例内，加入屏幕保护程序激活测试用例，甚至将这个用例增加至其他的测试平台。