让我们以最简单的例子为说明：
HELLO WORLD 登场！！（“HELLO WORLD”的出场费真高~~ >_<） 
看上图，这个程序够粗糙吧？——当然，难看死了，你一定会这样认为。对，因此程序的功能和最终的实现上，是存在误差的。我们知道，HELLO WORLD的最终功能，是实现在屏幕上显示“HELLO WORLD”的字样。然而，单单这样的定义，从客户的大脑里，直到开发编程上的实现，想象的空间非常大，大到这样的误差足够引起项目失败。因此，我们展开测试用例的撰写之前，先要看清楚需求。需求，是我们做事的标准和依据。 现在列出最简单的需求：1.
程序窗体在屏幕最中央出现。窗体大小为320*240；2.
窗体不允许最大化或者拉伸操作；3.
窗体标题为“HW”；4.
按钮标题为“PRESS”，位于左下角。默认焦点并可操作；5.
在窗体中央显示默认宋体字，8号的“HELLO WORLD”字样。 OK，至此，乍一看，需求定义的已经相对明确了。那么这样，我们该如何展开测试用例的设计呢？请看例子：
|
测试步骤
|
描述
|
预期结果
|
实际结果
|
是否通过
|
测试日期
|
测试人
|
1
|
运行“HELLO WORLD”
|
“HELLO WORLD”程序主界面被打开：
1.
程序窗体在屏幕最中央出现。
2.
窗体大小为320*240。
3.
没有最大化按钮，但有关闭按钮。
4.
窗体标题为“HW”。
5.
左下角有按钮“PRESS”，默认焦点，可操作。
|
|
|
|
|
2
|
拉伸主窗体
|
窗体属性为“FIXED”，不允许被拉伸。
|
|
|
|
|
3
|
点击“PRESS”按钮
|
在窗体中央显示默认宋体字，8号的“HELLO WORLD”字样。
|
|
|
|
|
OK，以上的测试用例100%覆盖了测试需求。然而实际上我们通常会在执行时发现，有些需求，并不会在一开始的定义阶段被罗列进去。这样便会产生麻烦或者新需求。比如：“HELLO WORLD”字样再显示之后，是否还需要变色，或者消失，再次按“PRESS”之后，是否会重新显示？键盘对“PRESS”按钮的操作是否需要测试？等等。如此一来，便需要和客户重新沟通，如果客户认可了某些新需求，那么TEST CASE自然需要跟随需求更新后也UPDATE。 总结：测试用例是用来描述测试动作的文本规范，设计时，需要首先从正常功能的路思考，尽可能多的覆盖需求。然后设计并想象一些异常情况，以测试程序能否在异常时保证功能的完整。 技巧：用词简练，步骤明确。尽可能写专业术语。要根据实际操作去设计“步骤前”，根据需求定义的可能性，去设计“步骤后”。（参照上面的例子，看预期结果和步骤之间的融合。） 责任意识：设计出来的测试用例，要让任何执行人员都能使用。 ————————————————————————————————————— 以下简单介绍一下如何写英语的测试用例：首先，要使用被动语态和简单句。其次，不能使用含糊的代词和人身代词。不要使用花哨的形容词去修饰。 将上面的例子转化成英语：
|
Test Steps:
|
Test Description
|
Expected Result
|
Actual Result
|
Status
|
Run Date
|
Tester
|
1
|
Launch ‘HELLO WORLD’
|
Main frame should be opened as:
1. The main form should be appeared in the middle of the screen.
2. Form size should be 320 * 240.
3. Main form should has [x] on the right of the top but without max button.
4. Title should be ‘HW’.
5. ‘Press’ button should be on the left down of the form, enabled, focus on as default.
|
|
|
|
|
2
|
Stretch on main form
|
Form should be fixed.
|
|
|
|
|
3
|
Click on ‘PRESS’ button
|
‘Hello World’ should be displayed on the middle of the form. Font 8, Style Song.
|
|
发表于 @ 2007年06月16日 16:20:00|评论(loading...)|编辑