测试人员在实际工作中根据不同覆盖要求设计面向代码的单元测试用例，运行测试用例后至少应实现如下覆盖需求：
- 对程序模块的所有独立的执行路径至少覆盖一次;
- 对所有的逻辑判定，真假两种情况至少覆盖一次;
- 在循环的边界和运行界限内执行循环体;
- 测试内部数据结构的有效性等。
至少应设计覆盖如下需求的基于功能的单元测试用例：
- 测试程序单元的功能是否实现；
- 测试程序单元性能是否满足要求（可选）；
- 是否有可选的其它测试特性，如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。
无论白盒、黑盒测试，每个测试用例都应包含4个关键元素：
- 被测单元模块初始状态声明，即测试用例的开始状态(仅适用于被测单元维持了调用中间状态的情况)；
- 被测单元的输入，包含由被测单元读入任何外部数据值；
- 该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试；
- 测试用例期望的输出结果(在测试进行前测试说明中定义)。
测试用例设计步骤
步骤1：首先运行被测单元
在单元测试中应该把通过简单的方法能够执行被测单元的测试用例作为第一个测试用例，因为当这个测试用例运行成功时可以增强人的自信心。如果运行失败，最好选择一个更简单的输入对被测单元进行测试/调试。
步骤2：正面测试(Positive Testing)
验证被测单元能够执行应该完成的工作。测试设计者应该查阅相关设计说明，每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。
步骤3：负面测试(Negative Testing)
负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。
步骤4：模块设计需求中其它测试特性用例设计
如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。在有安全保密需求的情况下，重视安全保密分析和验证是方便的。针对安全保密问题的测试用例应该在测试说明中进行标注。同时应该加入更多的测试用例测试所有的保密和安全问题。
步骤5：覆盖率测试用例设计
应该增加更多的测试用例到单元测试说明中以达到特定的测试覆盖率目标。覆盖率测试一般要求语句覆盖率和判断覆盖率。
步骤6：测试执行
使用上述5个步骤设计的测试说明在大多数情况下可以实现一个比较完整的单元测试。到这一步可以使用测试说明构造和执行测试过程。测试过程可能是特定测试工具的一个测试脚本。
测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。在测试过程中的动态分析可以产生代码覆盖率测量值，以指示是否已经达到了覆盖目标。
因此需要在测试设计说明中增加完善代码覆盖率的步骤。
步骤7：完善代码覆盖
由于模块单元设计文档规范不一，测试设计中可能引入人为的错误，测试执行后，复杂的决策条件、循环和分支的覆盖率目标可能并没有达到，这时需要进行分析找出原因，导致一些重要执行路径没有被覆盖的可能原因有：
①不可行路径或条件：应该标注测试说明证明该路径或条件没有测试的原因。
②不可到达或冗余代码：正确处理方法是删除这种代码。
③测试用例不足：应该重新提炼测试用例，设计更多的测试用例添加到测试说明中以覆盖没有执行过的路径。
理想情况下，覆盖完善阶段应该在不阅读实际代码的情况下进行。然而，实际上为达到覆盖率目标，阅读实际代码也是需要的。
面向对象应用程序的单元测试用例设计
对面向对象软件的类测试相当于传统软件的单元测试。但与传统软件的单元测试不同，它往往关注模块的算法细节和模块接口间流动的数据，面向对象软件的类测试是由封装在类中的操作和类的状态行为所驱动的。
因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的。封装使得我们难以获得对象的状态，继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试。多重继承更增加了需要测试的语境的数量，使测试进一步复杂化。
在类的生命周期中，类测试只是一个初始的测试阶段。类作为独立的成分可以多次在不同的应用系统中重复使用，这些成分的用户可要求每个类是可靠的，无须了解实现细节。
类的测试用例可以先根据其方法设计，然后扩展到方法间的调用关系。如果类中的方法都已定义了前置／后置条件，则可参考这些条件设计对各方法进行测试所需的测试用例。
类测试也采用功能性测试和结构性测试，即黑盒测试和白盒测试。功能性测试以类的规格说明为基础，它主要检查类是否符合规格说明的要求。
测试用例设计实例
例：ATM取款这个组件的功能点有：
(1)正常取款
(2)输入取款金额是否合法
(3)检查是否超出当天最大取款（假设2000RMB）
(4)余额不足（假设余额为1500RMB）
(5)打印收据功能至少一次
测试前提是银行卡和密码都有效，最多允许密码输错5次。功能覆盖测试用例如下所示：
单元最小功能点覆盖实例
| 用例编号 | 输入 | 预期输出 | 覆盖功能说明 | ||
| 银行卡号 | 卡密码 | 取款金额 | |||
| 001 | 111-8888 | 654321 | 500 | 正常取款，打印收据 | （1）（5） |
| 002 | 111-8888 | 654321 | 005 | 取款金额不合法 | （2） |
| 003 | 111-8888 | 654321 | 2500 | 超出当天最大取款 | （3） |
| 004 | 111-8888 | 654321 | 1800 | 账户余额不足 | （4） |
单元测试的非功能性测试一般是通过黑盒测试实现特定的功能来达到测试的目的。边界值分析是黑盒测试的经典方法，一般的用例设计都会采用，边界值用例如下图所示：
边界值法设计用例列举
| 用例编号 | 输入 | 预期输出 | 覆盖功能说明 | ||
| 银行卡号 | 卡密码 | 取款金额 | |||
| 001 | 111-8888 | 654321 | 0 | 取款金额不能为0 | 测试零边界 |
| 002 | 111-8888 | 123456 (错2次) | 200 | 正常取款 | 密码错误次数没超边界 |
| 003 | 111-8888 | 123456 (错5次) | 1000 | 正常取款 | 密码错误次数没超边界 |
| 004 | 111-8888 | 123456
(错6次) | 1000 | 吞卡 | 密码错误次数超出边界 |
也可以根据单元测试中提及的“强制一些错误情况发生”通过黑盒测试来设计测试用例。如ATM系统中主动造成磁盘空间不足，内存空间不足等。如下图所示：
强制错误用例列举
| 用例编号 | 输入 | 预期输出 | 说明 | ||
| 支局号 | 报表类型 | 报表日期跨度 | |||
| 001 | 000234 | 交易明细 | 7天 | 交易明细保存失败 | 报表产生后放于本地系统中，假设本地系统只有500M可用空间，而7天的交易明细有700M |
总之，在使用黑盒测试技术设计测试用例时应多方面考虑，至少应该考虑以下几方面：
(1)测试程序单元的所有最小功能点是否覆盖。
(2)测试程序单元非功能性是否满足要求(安全性、可靠性等)。
(3)考虑可选的其他测试特性(接口，人机交互界面等)。
125jz网原创文章。发布者：江山如画，转载请注明出处：http://www.125jz.com/1707.html
微信扫一扫 
支付宝扫一扫 