土土松
级别: 论坛版主
精华:
7
发帖: 1689
基地声望: 246 点
基地币: 2765 Bug
基地贡献: 6 点
好评度: 48 点
在线时间:1031(小时)
注册时间:2005-10-30
最后登录:2007-10-29
|
我之前说的第一第二点，是为了第三点的测试用例组合作准备的。
我先来举例说明一下：
比如一个前台界面上有一个按钮“添加”，有一个输入框来输入内容，还有一个表格来显示所添加好的内容。
这3个控件构成了一个表面看似简单的界面。当用户输入内容并按下“添加”后，表格内要显示出添加好的内容。
实际上，在这个程序中，很可能，“添加”按钮执行时，其代码规定，先把输入框的内容加入后台数据库表中，表格控件随着“添加”按钮底层的代码去刷新读取数据库表中的内容并显示。如果这样的话，其实一个按钮执行了从前台到后台再到前台的复杂过程，所以一定要把它剥离开来讨论。
假设，我们输入 A + B 在这个输入框中，按添加之后要分别显示出这两个公式的计算结果。如果用户输入 2+2 那么应该在前台表格中显示一个 4。 但是程序设计时，后台数据库中的代码不是 A+B， 而错写成了A*B，但是结果也恰巧是4。 如果不剥离前台和后台，我们很可能认为测试是通过或者是不通过的。其实，仔细思考之后，我们可以发现，其前台功能是通过的。错的，是后台。因为前台既能执行“添加”的代码，又能从后台数据库中把数据读取出来，错的只是后台的程序。
实际上，数据库的计算比这种情况复杂的多。
那么设计测试用例时，前台的界面，我们只要写 按“添加”按钮，预期结果“能在表格控件中读取**表的**字段中的内容”。
至于后台的，我们就要思考，**表中的**字段，是怎么计算出来的。我们可以使用数据库工具，或者设计其他测试数据，比如2+5 和2*5，一看就能知道是后台出现问题。
这样，我们把问题分离，就不会一棍子打死，解决问题也有针对性。
再看看：
1，前台界面
自己画一张图，把模块细分成流。比如添加就是添加，删除就是删除，编辑就是编辑。然后指向某个后台的表的字段，如货物ID。
2，后台数据库
最好能问开发人员要来数据库字典或者E-R关系图，以及特殊字段的计算公式。自己制造数据完全摆脱前台界面的干扰，进行数据库验证。比如 1+2=3，就是1+2=3，不要从前台的输入和显示去辨别。
能知道我的意思不？？
至于后台的测试用例，可以写成：
INPUT 2和5， 预期OUTPUT 为 7 ，（不是10。。）
当然，实际上的情况，要你自己去设计了，我只是告诉你怎么去剥离他们。
当前台和后台都通过了这样简单模块的测试之后，我们需要组合测试用例。因为加上业务逻辑，很多模块都有相关性，这个我想你知道。
问题又回到了上面，测试要从简单的出发，堆积成复杂的集成测试。
于是这个例子中，集成测试的测试用例可以组合成类似：
在输入框中输入《数据》，按“添加”， 显示《结果》
预期结果：每次都能从后台**表中的**字段中刷新读取《结果》（结果=A+B），并正确显示在表控件中。
注意：我的例子极不规范，只是例子和思路！！嘿嘿  不要模仿哦。
祝你顺利。
|
MSN:ss2maomao@hotmail.com
我的博客已经升级:
http://hi.baidu.com/lidanny
欢迎莅临~~！！~~
|
|
[6 楼]
|
Posted: 2007-02-28 14:07 |
| |
软件测试基地论坛 -> 新手园地 -> 请教如何组织测试用例
