测试用例的关键的认知
无论缺陷预防工作贯彻落实地多好，软件组件总有缺陷。这很明显，因为开发商无法阻止/消除软件开发周期的所有缺陷。因此，软件必须进行彻底的测试，然后才交付给最终用户。测试人员的责任是：设计既可以（ⅰ）找软件缺陷，又能（ii ）评估该软件的性能，可用性和可靠性等方面的测试。现在，为了实现这些目标，测试人员必须（往往是从一个非常大的执行域中）选择和/或制定测试用例的有限数量。不幸的是，完整的测试通常不是在这个范围，预算和时间的约束内实现和/或执行的。重要的是，当测试开始失控且不按计划地运行时，由于预期无法实际，测试人员往往承受了来自管理层和利益相关者的巨大压力。
因此，测试人员必须有效地计划测试并制定正确的测试用例，选择并执行合适的用例，监控过程，以确保有效利用工作资源和时间。所以，要列出这些无疑是一项艰巨的任务；要有效地实施，测试人员需要受过适当的教育和培训并拥有赢得管理层支持的能力。
一般情况下，测试人员会用两种不同的测试方法，其中，使用常规方法，测试人员主要是尝试用所有可能的输入去测试一个模块或组件，用所有可能的软件结构去实践。尽管这种做法仍在使用，测试人员却在慢慢灌输推理软件的一切的价值，最终使他们能够检测出所有可能存在的缺陷。但见多识广且有学问的测试员们都明白，这在现实或经济上是不可行，不可实现的目标。
现在，另一种方法可能就是让测试员们随机选择测试输入，希望这些测试能将大的缺陷找出来。不过，测试专家认为，随机生成的测试输入在评估系统的质量属性方面表现纪录欠佳。所以，从测试的角度来看，这是一个无休止的争论和悬而未决的问题。尽管如此，我们还是认为，测试员的最终目标是了解测试的功能、输入/输出域和使用环境，等等。
同样，对于某些特定类型的测试，测试人员也需要详细地了解代码是如何构造的。此外，测试人员也需要利用关于常在软件开发或维护过程中生成的特定缺陷的知识。有了这些信息，测试者就必须明智地选择测试输入的子集，以及被认为最有可能找测试过程中条件和限制内的缺陷的测试输入组合。然而，这个过程需要时间和精力。所以，测试人员知道且赞同：只有开发出基于执行的测试的有效测试用例，才能最大化和/或优化对时间和资源的利用。
“有效测试用例”我们是指：“一个很可能找出缺陷的测试用例” 。因此，制定有效测试用例的能力对于一个组织迈向一个更高质量的测试过程来说是非常重要的；反过来， 一个组织迈向一个更高质量的测试过程对制定有效测试用例的能力也有许多积极影响。
例如，如果测试用例是有效的，那么：
检测缺陷的概率更大。
更有效地利用组织资源。
测试再用的可能性更高。
更符合测试、项目进度、预算，更重要地，提供更高质量的软件产品的可能性。
测试用例设计方法 - 概念化
上面介绍了有效测试用例的种种好处，但缜密考虑测试人员用来设计这些有效测试用例的方法也同样重要。为了回答这个问题，有必要把软件作为一个精心设计的产品来查看和/或检查。现在，有了这个观念，就有两个基本方法可以用来设计测试用例：
黑盒（有时也称为功能或规格）测试方法。
白盒（有时也称为clear或透明盒 ）测试方法。
使用黑盒测试方法，测试人员把SUT （测试中的软件）当作一个不知道其内部结构（即如何运作）的不透明盒子，测试人员只知道它的作用。使用这种方法的SUT的大小可以是一个简单的模块、成员函数、对象群、一个子系统、或一个完整的软件系统。此外， SUT的基础行为或功能的描述可以由正式规格，输入/处理/输出图（ IPO），或一套定义明确的先决、后置条件来提供；重要的是，另一个值得一提的信息来源是：需求规格说明文档，通常描述SUT的功能，输入及预期输出。现在，鉴于上述来源，测试员提供指定输入到SUT，进行测试运行，然后确定所产生的输出是否与说明文档中提供的一致。因为黑盒测试方法只考虑了软件的行为和功能，它通常被称为功能测试，或基于规范的测试。这种方法特别有用，极有助于找到要求和规格中的缺陷。
与此相反，白盒测试方法关注将被测试的软件的内部结构。因此，使用白盒测试方法来设计测试用例，测试人员应该先了解结构，且为了实现这一目标，必须可随时参考和理解代码或适当的类伪代码的要求。一旦对结构有了必要的了解，测试者就可以选择合适的测试用例去实践特定的内部结构要素，并确定它们是否正常工作。例如，测试用例通常被设计来实践所有语句或发生在一个模块或成员函数中的真/假分支。但是，由于白盒测试的设计，执行和结果分析非常耗时，这种方法被限制和/或通常只适用于软件的小部分，如模块或成员函数。然而，白盒测试方法对于找出设计和基于代码的控件的逻辑缺陷和顺序缺陷，初始化缺陷和数据流缺陷等特别有用。
然而，从测试员的角度来看，要实现向用户提供低缺陷高质量的软件的目标，必须把这两种方法都用来设计测试用例。另外，这两种方法都支持测试员选择有限数量的将被用于测试的测试用例。这两种方法可以相互补充，因为每个都或许有助于找到某些特定类型的缺陷。重要的是，有了使用这两种方法设计出的一组测试用例，测试员找到SUT中各种不同类型缺陷的机会就增加了。
测试员还有一套有效的可再用的用来进行回归测试（更改后的重新测试），以及软件测试的新版本。
上面是一份概要：使用任一设计方法制定测试用例的各种可用方法。
但是，在使用任一设计方法准备测试用例前有一些因素需要考虑清楚。它们分别是：
测试相关风险。
预期缺陷类型。
测试员的知识和经验。
测试水平和必须进行分组和管理的小组活动。
用于执行测试用例的工具。
应用程序，软件和问题域的类型。
客户要求，等等。
现在除了上述因素，以下几个要点和/或问题在选择正确的测试用例设计技术中发挥了至关重要的作用：
基于“经验”的测试用例设计
在基于经验的技术中，是人们的知识，技能和专业知识（关于域，技术等）构成了测试条件和测试用例的基础，且对制定测试条件和测试用例很重要。
在这儿，人们技术和业务两方面的经验都是绝对必需的，必要的，因为这给测试分析和设计过程提供了不同的角度。
重要的是，有了他们使用类似系统工作的丰富（前）的经验，他们或许对什么会出错，什么有助于测试有了想法和/或深入的理解。
因此，基于经验的技术与基于规范既与基于结构的技术偕行，又可用于没有规格，或者规格不足或过时的时候。
这可能是用于设计测试低风险系统的测试用例的唯一技术，但是这种方法可能在非常紧急的情况下特别有用，事实上，这是导致探索性测试的一个因素。
“随机”方式—考虑了吗？
通常，任何软件模块或系统都有输入域，从这个域里选择并使用测试输入数据建和/或执行测试用例。
现在，如果一个测试人员从必要输入域中随机选择输入，准备测试用例，并用它们来测试应用程序，这种方法被称为“随机测试”。
例如，如果一个模块的有效输入域是1到100之间所有的正整数，然后用这种方法测试人员会随机或胡乱地从该领域内选择值，如，选15 ， 27和33。
但是，使用这种方法，也有一些一直无解的问题：
值（上面的例子中三个值）足以表明，执行测试用或运行例测试时，模块符合其规格吗？
是否有其他输入值，比那些（在本例中）被选中的值，更能找缺陷？
抑或有效输入域外的任何值应该作为执行测试用例的测试输入？
这就是说，测试数据应包括大于100的浮点值，负值或整数值？
因此，上述问题可以立即通过更加结构化的黑盒测试设计方法解决，尽管使用随机测试输入可以节省一些时间和精力，其他测试输入选择方法要求。
但是，根据许多测试专家，随机选择测试输入会产生一个有效的用于执行测试用例的测试数据集的机会非常小，并且对于一个更结构化的方法，随机方法生成测试输入的相对有效性总成为自省和/或研究的课题。
测试用例必不可少的部分—概念化
首先，设计一个测试用例用来回答这个问题：“我要测试什么？ ” 。因此，对于测试人员来说，开发测试用例时周到地考虑很重要，这能够明确界定和/或提供需被验证以确保系统如期运行且能反映出它是用最高质量创建的信心的项目（模块，应用程序，子系统，或SUT ）的完整概述。
现在，无论开发测试用例时用了什么设计技术/战略，测试人员都必须确保基本涵盖以下主要内容：
摘要 -应该反映实际的主题，类别和功能特性，使测试人员可以轻易地组织测试用例成逻辑组，并相应地对它们进行分类。
这部分可能具有关于基于测试时间，工作单元，和优先级等的执行工作的细节。它经常被称为测试用例的权重。
测试用例设计 - 这部分反映了测试用例的整体设计，其中可能包括一些高层次的描述。
正式审查 - 包含了关于必须审查或批准测试用例、并定义审批流程的团队清单的详情。
这部分主要是用来建立一个正式的审查程序，以确保业务流程符合标准。
此外，它可能包括关于测试用例所有人，工作项目，通知和成果总结等的细节
要求 - 本部分旨在：当要求被添加到测试计划中时，联系要求与一个特定的测试用例。
因此，一旦需求和测试用例间的联系被建立，测试人员就可以继续创建覆盖报告来了解和确定被测试用例覆盖的要求的比例有多大。重要的是，通过保持这种关联，有助于设置和检查整个项目的可追溯性。
先决条件 - 描述了形成前提的或必须在测试人员可以真正开始运行/执行测试用例之前发生的事物。
后置条件 - 不像先决条件，后置条件说明了需在测试用例运行/执行完成之后发生的事物。通常是产生适当的确认，如发送电子邮件通知等。
预期结果 - 本部分详细介绍了必须在测试员认为测试运行已取得成功前获得的结果列表。它可能包含了结果代码的文件或图像。
测试脚本 - 本部分概述了与特定的测试用例相关的测试脚本。通常，测试脚本有几种类型，包括手动测试脚本，关键字启用测试脚本，及其中每个测试脚本都包含用来实现一个测试用例的指示的自动化功能测试脚本。
在执行过程中，不像使用工具自动运行的自动化测试脚本，手工测试脚本是用语句处理语句。
测试执行记录 - 通常测试执行记录包含测试用例的详细信息，及从测试用例执行产生的高层次结果的细节。
重要的是，它们提供测试执行所需的相关硬件和软件环境的细节。例如，如果当运行在两个不同的操作系统和两个不同的硬件平台上，且使用了不同的浏览器的测试用例通过了，那么测试员可以为这些组合中的每一个创建测试执行记录。
测试执行记录还包含与该测试用例运行，测试运行的详细记录，以及所有执行结果的详细历史相关的的整体结果。
附件 – 本部分通常包含了支持测试用例的所有文档和文件。
风险评估表 - 本部分意在列出与某个特定的测试用例相关的风险。
所以，当上述所有部分都与测试用例相关，且如果这样的测试例被执行，那么就是一个好的迹象：关于实现完整的测试覆盖率，效率等方面的标准已达到。 好长哇 shoucang 说实话，现在都很少写手工测试用例了，尤其是互联网产品，都走敏捷，没时间写。现在都是写user story，然后细分成scenario 最后在covert到自动化脚本的时候，才会写详细的步骤 看不完呀，好累！！ 确实有点长 看得瞌睡都来了:sleepy: 顶。特好 能结合实例讲讲怎么设计测试用例吗
页:
[1]
