功能测试用例设计

 

功能测试用例

从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终都会涉及到，而且功能测试几乎是系统测试的核心内容，因此功能测试用例编写的是否成功，决定着最后测试结果的成败。

功能测试关注的是系统功能是否正确实现，其主要依据文档是需求分析文档，集成测试中相关的功能测试会涉及概要设计和详细设计文档。

在目前的大多数测试工作中，测试人员的分工还不像开发人员分工那样明确，经常是测试经理不但要编写测试计划和设计测试，还要执行具体的测试工作，尤其在功能测试过程中，编写测试用例和执行测试用例的经常是一个人。因此针对功能测试，本着提高效率的宗旨，提出下面的编写原则：

1、  用例应该编写的少而精：建议越少越好，但是功能用例的覆盖面应该是全部的功能需求，这是针对目前大多数企业提供的测试资源较少提出的一个原则，目前的大多数公司没有能力给测试用例足够的编写时间，是少的用例节省时间便于执行和维护，随着企业软件开发过程的规范化，测试人员分工会更加明确，这个时候需要编写较为全面的功能测试用例，由专门的测试员执行；

2、  尽量包括更多的测试内容：比如一些易用性测试、健壮性、界面测试，都可以包含在功能测试中，这用做不但可以减少测试次数，更能提高测试效率，同时把相关联的测试用例一起执行，会发现更多的缺陷。

本小节主要介绍功能测试用例的基本编写方法和一些功能测试用例的编写实例。

10.2.1 .1功能测试用例设计基本方法

功能测试的用例设计方法常见的有等价类划分、边界值分析、因果图、比较法和错误推测法，这些方法在测试书籍、网上文章中都可以找到，在这里就不重复了。本节给大家介绍一种比较新的用例设计方法：使用用例场景来设计测试用例。

用例场景来设计法的重要概念是测试点：在系统的用例模型描述中应明确指出每个用例模型的优先级和用例工作流程，每个用例模型为一个测试点，用例模型中每个测试需求至少应编写两个测试用例。这个概念经常被误解和误用，请大家注意。

用例场景的定义：用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

为什么引入用例场景？

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。

用例场景示例：

下图中经过用例的每条不同路径都反映了基本流和备选流，备选流用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景1	基本流
场景2	基本流	备选流1
场景3	基本流	备选流1	备选流2
场景4	基本流	备选流3
场景5	基本流	备选流3	备选流1
场景6	基本流	备选流3	备选流1	备选流2
场景7	基本流	备选流4
场景8	基本流	备选流3	备选流4

注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。

测试用例：

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

测试用例例子：

假定上图描述的用例对备选流3规定如下：

“如果在上述步骤2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2‘输入提款金额’，此时银行客户可以输入新的提款金额。”

据此，可以开始确定需要用来执行备选流3的测试用例：

测试用例ID	场景	条件	预期结果
TCx	场景4	步骤2-提款金额>帐户余额	在步骤2处重新加入基本流
TCy	场景4	步骤2-提款金额<帐户余额	不执行备选流3，执行基本流
TCz	场景4	步骤2-提款金额=帐户余额	不执行备选流3，执行基本流

注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。

10.2.1 .2功能用例编写策略

    功能用例的编写策略一般是这样的：

    1)首先确定测试点和其自有工作流程。

    2)按业务（系统测试）或功能（单元和集成测试）将测试点进行编号和排序。

    3)使用用例场景方法确定测试用例。

    要点：使用场景，类似于白盒测试的基本路径法。能清晰的描述出系统的功能或业务流程，将测试用例的实际测试效果提升到最大。又因描述出各测试点之间的关系从而降低测试用例的设计难度和复杂度。 10.2.1 .3功能用例编写例子

下面是一个由用例生成测试用例的更符合实际情况的例子。

 

一台ATM机器的主角和用例。下表包含了上图中提款用例的基本流和某些备用流：

基本流	本用例的开端是ATM处于准备就绪状态。 准备提款－客户将银行卡插入ATM机的读卡机。 验证银行卡－ATM机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。 输入PIN－ATM要求客户输入PIN码（4位） 验证帐户代码和PIN－验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。对于此事件流，帐户是有效的而且PIN对此帐户来说正确无误。 ATM选项－ATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。 输入金额－要从ATM中提取的金额。对于此事件流，客户需选择预设的金额（10美元、20美元、50美元或100美元）。 授权－ATM通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。 出钞－提供现金。 返回银行卡－银行卡被返还。 收据－打印收据并提供给客户。ATM还相应地更新内部记录。用例结束时ATM又回到准备就绪状态。
备选流1-银行卡无效	在基本流步骤2中－验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。
备选流2-ATM内没有现金	在基本流步骤5中－ATM选项，如果ATM内没有现金，则“提款”选项将无法使用。
备选流3-ATM内现金不足	在基本流步骤6中－输入金额，如果ATM机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤6－输入金额处重新加入基本流。
备选流4-PIN有误	在基本流步骤4中－验证帐户和PIN，客户有三次机会输入PIN。如果PIN输入有误，ATM将显示适当的消息；如果还存在输入机会，则此事件流在步骤3－输入PIN处重新加入基本流。如果最后一次尝试输入的PIN码仍然错误，则该卡将被ATM机保留，同时ATM返回到准备就绪状态，本用例终止。
备选流5-帐户不存在	在基本流步骤4中－验证帐户和PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则ATM显示适当的消息并且在步骤9－返回银行卡处重新加入基本流。
备选流6-帐面金额不足	在基本流步骤7－授权中，银行系统返回代码表明帐户余额少于在基本流步骤6－输入金额内输入的金额，则ATM显示适当的消息并且在步骤6－输入金额处重新加入基本流。
选流7-达到每日最大的提款	在基本流步骤7－授权中，银行系统返回的代码表明包括本提款请求在金额内，客户已经或将超过在24小时内允许提取的最多金额，则ATM显示适当的消息并在步骤6－输入金额上重新加入基本流。
选流x-记录错误	如果在基本流步骤10－收据中，记录无法更新，则ATM进入“安全模式”，在此模式下所有功能都将暂停使用。同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作。
选流y-退出	客户可随时决定终止交易（退出）。交易终止，银行卡随之退出。
选流z-“翘起”	ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。在任一时刻，如果某个传感器被激活，则警报信号将发送给警方而且ATM进入“安全模式”，在此模式下所有功能都暂停使用，直到采取适当的重启/重新初始化的措施。
第一次迭代中，根据迭代计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流： 基本流-提取预设金额（10美元、20美元、50美元、100美元） 备选流2-ATM内没有现金 备选流3-ATM内现金不足 备选流4-PIN有误 备选流5-帐户不存在/帐户类型有误 备选流6-帐面金额不足

以从这个用例生成下列场景

场景1－成功的提款	基本流
场景2－ATM内没有现金	基本流	备选流2
场景3－ATM内现金不足	基本流	备选流3
场景4－PIN有误（还有输入机会）	基本流	备选流4
场景5－PIN有误（不再有输入机会）	基本流	备选流4
场景6－账户不存在/账户类型有误	基本流	备选流5
场景7－账户余额不足	基本流	备选流6

注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。

对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

TC（测试用例）ID号	场景/条件	PIN	帐号	输入的金额（或选择的金额）	帐面金额	ATM内的金额	预期结果
CW1.	场景1-成功的提款	V	V	V	V	V	成功的提款。
CW2.	场景2-ATM内没有现金	V	V	V	V	I	提款选项不可用，用例结束
CW3.	场景3-ATM内现金不足	V	V	V	V	I	警告消息，返回基本流步骤6-输入金额
CW4.	场景4-PIN有误（还有不止一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤4，输入PIN
CW5.	场景4-PIN有误（还有一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤4，输入PIN
CW6.	场景4-PIN有误（不再有输入机会）	I	V	n/a	V	V	警告消息，卡予保留，用例结束

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2至6表示（阴影单元格表明这种条件下需要执行备选流）。虽然CW2至6对于基本流而言都是负面测试用例，但它们相对于备选流2至4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1-基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例（以激活场景4）：

输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤3-输入PIN。

输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

最后一次输入时输入了“正确”的PIN。备选流在步骤5-输入金额处重新加入基本流。注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看V和I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

TC（测试用例）ID号	场景/条件	PIN	帐号	输入的金额或选择的金额	帐面金额	ATM内的金额	预期结果
CW1.	场景1－成功的提款	4987	809－498	50.00	500.00	2,000	成功的提款。帐户余额被更新为450.00
CW2.	场景2－ATM内没有现金	4987	809－498	100.00	500.00	0.00	提款选项不可用，用例结束
CW3.	场景3－ATM内现金不足	4987	809－498	100.00	500.00	70.00	警告消息，返回基本流步骤6-输入金额
CW4.	场景4－PIN有误（还有不止一次输入机会）	4978	809－498	n/a	500.00	2,000	警告消息，返回基本流步骤4，输入PIN
CW5.	场景4－PIN有误（还有一次输入机会）	4978	809－498	n/a	500.00	2,000	警告消息，返回基本流步骤4，输入PIN
CW6.	场景4－PIN有误（不再有输入机会）	4978	809－498	n/a	500.00	2,000	警告消息，卡予保留，用例结束

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

场景6-帐户不存在/帐户类型有误：未找到帐户或帐户不可用

场景6-帐户不存在/帐户类型有误：禁止从该帐户中提款

场景7-帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）无法读卡（读卡机堵塞、脱机或出现故障）帐户已消户、冻结或由于其他方面原因而无法使用ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币值都不足）无法联系银行系统以获得认可银行网络离线或交易过程中断电。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1477743