章节（一）测试流程-测试用例

为了最有效和高效率，测试用例必须设计，not just slapped together。单词“设计”有以下定义：

1、为了在脑海中构想或形成；发明：设计一个好的理由去尝试STAR测试会议。为了明确地表达一项计划；设计：为新产品制定一个市场战略。

2、为了有系统地计划中，通常是以文档的形式：设计一个架构(building)，设计一个测试用例。

3、为了某个特有的目的或效果去创造或发明：设计一个能吸引所有年龄段的游戏。

4、作为一个目标或目的的；计划。

5、在艺术地或高度熟练的方式去创造或执行。

 

Key Point 为了最有效和高效，测试用例必须被设计，而不是(not just slapped together).

 

这些定义中的每一个都适用于好的测试用例的设计。关于测试用例的设计，Roger Pressman 写到：

“在软件及其他工程设计，产品测试，可作为产品本身的初步设计挑战。然而...软件工程师通常对待测试作为事后工作，开发测试用例是

‘感觉正确’但没有什么保证能被完全覆盖。回顾整个测试的目标，我们必须设计测试的目的是为了在最小的时间和精力的花费下找到尽可能多的错误。”

 

精心设计的测试用例包含以下三个部分：

输入

输出

执行的顺序

 

Key Point 测试用例由输入、输出和执行的顺序组成。

 

输入

输入通常认为是 在键盘 输入 数据 。 虽然这是一个系统输入的重要来源，数据可以来 来源于 其他-从系统的数据接口，从设备上的数据接口，读取文件或数据库，这种输入状况是系统在数据到达，并在其中的环境 中执行时。

 

输出

输出同样也有多种。通常输出被认为就是数据显示在电脑屏幕上。另外，数据能被发送到接口系统和外部设备。数据能被写到文件或数据库中。 通过系统的执行， 这种输出状况或环境也许会被改变。

 

所有这些有光的输入和输出时一个测试用例的重要组成部分。在测试用例的设计中，决定期待的输出是一个“oracle”的功能。

 

An oracle is any program, process, or data that provides the test designer with the expected result of a test.Beizer罗列了五种oracle类型：

• Kiddie Oracles----仅仅是运行该程序，并看看输出了什么。如果它看起来是正确，那么它就是正确的。
• Regression Test Suites----运行该程序并把输出和在先前版本的程序上用同样的测试得到的结果比较。
• Validated Date----运行该程序，并以一个标准为依据如表，规则，或有效的输出的其它可接受的定义比较这个结果。
• Purchased Test Suites---依据一个已经事先创建和验证的标准测试组件运行该程序。对程序像编译，浏览器，和SQL处理的测试，通常依据这样的组件。
• Existing Program----运行该程序，并输出和其它版本程序的输出相比较。

执行的顺序

关于测试执行的顺序，有两种测试用例设计的风格。

• 级联测试用例(Cascading test cases)----测试用例可以相互依存。例如，第一个测试用例演示了软件的一个特有的功能，然后离开了系统但留了一个能使第二个测试用例执行的状态。在测试数据数据库中考虑以下这些情况：

1. 创建一个记录
2. 读取这个记录
3. 更新这个记录
4. 读取这个记录
5. 删除这个记录
6. 读取这个删除的记录

上面的每个测试依存于上一个的测试。优点是每个测试用例明显地更小和更简单。缺点是如果一个测试失败了，后续的测试也许会无效。

• 独立的测试用例(Independent)----每个测试用例时完全自包含的。测试不依靠任何一个或需要其它测试已经成功地执行。优点是任何数量的测试以任何顺序都能执行。缺点是任何一个测试会变得更大和更复杂，因此会更难去设计，创建，和维护测试用例。