3.1测试用例综述

黑盒测试与测试用例设计测试用例综述3.2

等价类设计方法3.3

边界值设计方法3.4

因果图设计法目录CONTENTS3.5正交试验设计方法3.13.1测试用例综述测试用例现在没有标准的定义，比较常见的说法是：为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例将软件测试的行为活动做了一个科学化的组织归纳，以便能够把软件测试的行为转化为可管理的模式。同时，测试用例也是将测试具体量化的方法之一；对于不同类别的软件，测试用例也是不同的。对于一个测试过程来说，测试用例起到了很重要的作用，它构成了设计和制定测试过程的基础。而从某种角度来说，测试的“深度”与测试用例的数量成比例，判断测试是否完全的一个主要评测方法是基于需求的覆盖。测试用例设计的最基本要求是覆盖住所要测试的功能。然而这个要求并不像看上去那么简单。测试中要能够是测试用例达到切实覆盖全面的要求，需要对被测试产品功能全面了解、明确测试范围（特别是要明确哪些是不需要测试的）、具备基本的测试技术（如：等价类划分等）等。但是由于成本因素的介入，决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条，下面几条常见的测试用例设计原则。3.1.1测试用例设计原则1）测试用例最小化原则2）测试用例替代产品文档功能原则4）测试结果分析和调试最简单化原则3）单次投入成本和多次投入成本原则3.1.1测试用例设计原则0102使用一个覆盖三个子功能点的测试用例Test_F1_F2_F3。使用三个单独的测试用例，分别覆盖三个子功能，Test_F1，Test_F2，Test_F3。1）测试用例最小化原则这条原则是最重要的，同时也是最难达到、最易忽略的。它对其他几条原则都有着或多或少的影响。在测试过程中有一个功能FUNC需要被测试，它含有三个子功能：F1，F2与F3，以两种方法来设计测试用例：(b)测试结果对产品缺陷的指向性更强C）测试用例间的耦合度最低，因此彼此间的干扰也最低。(a)测试用例的覆盖边界更清晰1）测试用例最小化原则对于规模较小的工程来说，方法1更为适宜；但对于规模较大或者质量要求较高的项目，方法2显得更为合适，因为它具有以下的优点：对于测试用例来说，它忠实反映了产品功能，否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已，其实对测试用例的理解应该再上升到另一个高度，它应该是能够扮演产品描述文档的功能。这就要求编写的测试用例足够详细、测试用例的组织要有调理、分主次，单靠Word、Excel或者

OneNote这样通用的工具是远远无法完成的，需要更多专用的测试用例管理工具来辅助。此外，对于自动化测试用例而言，无论是API还是UI级别的，代码在编写上都应该有别于产品代码编写风格：可读性和描述性应该是重点考虑的内容。在测试代码中，当然可以引入面向对象、设计模式等优秀的设计思想，但是一定要适度使用，往往面向过程的编码方式更利于组织、阅读和描述。2）测试用例替代产品文档功能原则3）单次投入成本和多次投入成本原则例如，第一条原则：单个用例覆盖最小化原则，就是一个很好的例子，测试FUNC功能的3个功能点F1，F2和F3，从表面上看用Test_F1_F2_F3这一个用例在设计和自动化实现时最简单的，但它在反复执行阶段会带来很多的问题。这样的用例的失败分析相对复杂，对于测试人员需要确认到底是哪一个功能点造成了测试失败；首先步骤多的手工测试用例增加了手工执行的不确定性，步骤多的自动化用例增加了其自动执行的失败可能性，特别是那些基于UI自动化技术的用例；.再者自动化用例的调试更为复

杂，如果是F3功能点的问题，程序仍需要不断地走过F1和F2，然后才能到达F3，这增加了调试时间和复杂度；其次将不相关功能点耦合到一起，降低了尽早发现产品回归缺陷的可能性，这是测试工作的大忌。最后3）单次投入成本和多次投入成本原则成本永远是任何项目进行决策时所要考虑的首要因素，软件项目中的开发需要考虑成本，测试工作同样如此0

。3）单次投入成本和多次投入成本原则综上所述，Test_F1_F2_F3这样的设计，减少地仅是一次性设计和自动化的投入，增加地却是需要多次投入的测试执行的负担和风险，所以需要决策时（事实上这种决策是经常发生的，尤其是在设计测试用例时）选择Test_F1_F2_F3还是Test_F1、Test_F2和Test_F3，务必要考虑投入的代价。4）测试结果分析和调试最简单化原则这条原则是实际上是第三条原则的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调更简单，包括：用例日志、调试辅助信息输出等。往往在测试项目中，测试用例的编写人和最终的执行者是不同的团队的成员，甚至有些测试的执行工作被采用外包的方式交给第三的团队去进行。因为测试用例的执行属于多次投入，测试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。而这时，测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。例如，Coded

UI

Test就提供了类似的API，来辅助基于Coded

UI框架实现的自动化测试用例，使它有更好的调试体验。测试理论为日常的测试工作指明了前进的方向，但在实际工程中还需要我们不断地“活化”这些理论，使理论和实践更好地契合在一起。测试用例更新完善测试用例评审测试用例设计业务流程分析测试需求分析.3.1.2测试用例设计步骤一个完整的软件测试流程包括许多内容，该部分从测试用例的编写开始，介绍测试用例编写的一般步骤，以使编写的测试用例最大程度上满足需求，又不产生重复而冗余的负担。首先我们从理论上来了解测试用例编写的一般步骤：0102030405end01测试需求分析这一步需要测试人员从软件需求文档中，找出测试软件、测试模块的需求，并进行分析后整合出测试需求，清楚被测对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。在软件需求的基础上，测试需求应该进行进一步的归纳和分类，以便设计出合理的测试用例。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个的测试用例集对应一个测试需求。主流程是什么条件备选流程是什么数据流向是什么关键的判断条件是什么.02业务流程分析软件测试不仅要从功能的角度进行测试，也要从软件的内部结构入手进行逻辑测试。为了完整地进行测试活动，需要对软件产品的业务流程有较高的熟悉度。因此在设计一些复杂的测试用例之前，可以先整理出软件的业务流程，它可以帮助理解软件的逻辑处理和数据流向，从而指导测试用例的设计。从业务流程上，应得到这些信息。（1）确定测试套件（2）对每一个测试套件，确定一个或多个基本流程和可选流程测试套件是功能上的划分，是相似测试场景的组合，而非技术划（3）针对每一个测试场景，确定一到多个测试用例（4）增加测试数据，完成测试用例分。如果技术设计中各模块耦合度较高，可能功能上不相干的模块由于代码重用的原因会在修复缺陷时互相引致错误；而实际上回归测试的出现即是为了避免这种情况。但是做功能测试划分模块时，还是要从用户的角度出发，按照用户场景划分测试的“模块”。（1）（2）（3）测试数据是测试用例中很重要的内容，一个用例可能对应多套测试数据，测试工程师根据某种测试技术，将尽可能的设计较少的测试数据完成“足够”的测试。（4）03测试用例设计设计测试用例的关键点：可以借助Scenario

Matrix来清晰地对可能出现的场景进行排

列组合。值得注意的是，一方面Use

Case或PRD文档中的描述

很有可能并没有完整的写尽所有的场景，测试人员尽可能地挖

掘测试场景，既有可能是出于测试本身的需要，也可能是基于

开发团队的工作；另一方面，在复杂系统中，测试场景不可能

覆盖所有可能的场景，这便需要测试人员采用一定的测试策略，对系统进行“足够（adequate）”的测试，而不是完全的测试。这仍然可以借助Matrix来清晰地规划测试用例，每一个测试用例都有其对应的预置条件、输入和期望结果。测试用例分为PositiveTestCase和NegativeTestCase两种，分别用来测试产品是否完成应当完成的工作和不执行不应当完成的操作。04测试用例评审测试用例设计完成后，为了确保测试过程和方法的正确性，以及是否有遗漏的测试点，需要进行测试用例的评审。评审活动一般由测试主管来主导，参与的人员有测试用例设计者、测试主管、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。05测试用例更新完善测试用例完成后并不是这一阶段的终止，而