在测试用例设计之前，我们可以先研读相关规格文档，记录不明白的地方、不严谨的地方，然后简单画出总体流程图。()

A.TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码

B.TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程

C.TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求

D.TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证

A.setUp()，在每一个测试用例执行之前，会先执行此方法。一般用于业务逻辑。

B.tearDown()，在每一个测试用例执行之后，会执行此方法。一般用于释放资源。

C.setUpClass()，在类中的所有测试用例执行之后，会先执行此方法。

D.tearDownClass()，在类中的所有测试用例执行之前，会执行此方法。

A) 测试输入数据和与之对应的输出结果

B) 测试输入数据和软件产生的效果

C) 软件的执行流程和执行结果

D) 软件的执行结果和结果分析

A.等价类

B.边界值

C.因果图

D.错误推测法

A.利益相关方需求和系统需求

B.系统需求和系统架构设计的要素

C.系统架构设计要素与系统集成测试规范中的测试用例

D.系统需求与系统合格性测试规范中的测试用例

场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。表6-5是一种通用格式，表中各行代表各个测试用例，而各列代表测试用例的信息。本例中的测试用例包含测试用例ID号、场景(或说明/条件)、测试用例中涉及的所有数据元素(作为输人或已经存在于数据库中)以及预期结果等项目。

测试用例的设计步骤通常是：首先确定执行用例场景所需的数据元素(本例中包括账号、是否黑名单卡、输入油量、账面金额以及加油机油量)，然后构建矩阵，最后确定包含执行场景所需的适当条件的测试用例。在表6-6的测试矩阵中，V表示有效数据元素，I表示无效数据元素，n/a表示不适用，例如CW01表示“成功加油”基本流。请按上述规定为其他应用场景设计测试用例矩阵。

场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。表7-17是一种通用格式，表中各行代表各个测试用例，而各列代表测试用例的信息。本例中的测试用例包含测试用例ID号、场景(或说明/条件)、测试用例中涉及的所有数据元素(作为输入。或已经存在于数据库中)，以及预期结果等项目。

测试用例的设计步骤通常是，首先确定执行用例场景所需的数据元素(本例中包括账号、是否黑名单卡、输入油量、账面金额和加油机油量)，然后构建矩阵，最后确定包含执行场景所需的适当条件的测试用例。在表7-17的测试矩阵中，V表示有效数据元素，I表示无效数据元素，n/a表示不适用，例如CW01表示“成功加油”基本流。请按上述规定为其他地应用场景设计测试用例矩阵。