小弟做黑盒测试及测试用例的一点心得，写出来原和大家一起分享。

lz6988 · 发表于 2006-4-11 23:30:59

黑盒测试是不是就是写写测试用例记录测试过程啊，黑盒测试是不是要通过什么软件工具来测呢

bluemay217 · 发表于 2006-4-12 12:23:23

我们的测试用例一般是根据需求说明书和概要说明书来写的
感觉个人有点定向思维了，写的测试用例覆盖率好像不够
不知道有没有什么好的方式？

bluemay217 · 发表于 2006-4-12 12:24:23

还有一点需要大家讨论一下：
测试用例是用Excel还是Word形式管理起来方便些？

bluemay217 · 发表于 2006-4-12 12:25:13

btw，我们的测试用例是用Excel形式来写的，感觉总是写得不全，思路好像没有拓宽

11034 · 发表于 2006-4-15 20:16:38

提个意见:含有非正常数据的用例:应该是一个用例只覆盖一项非正常数据,这样有利于定位错误
其实就是:等价类划分中必须遵守:一个用例只覆盖一个无效等价类.

wyc51007 · 发表于 2006-4-19 14:53:47

尚无测试经历，谢谢大家的共享，学习中……

test454 · 发表于 2006-4-21 21:28:29

ding

wangziyang · 发表于 2006-4-26 07:51:30

楼主的用例不怎么多啊，就这么简单啊，不过偶没写过....

steven.chen · 发表于 2006-4-28 12:04:59

帮助很大阿，不过根据测试书籍中的指导，在利用等价类测试时有两个原则，一是一个针对正确情况的test case要覆盖尽量多的正确等价类，同时一个针对错误等甲类的test case要分别针对一个错误的等甲类，搂主好像用了一个test case覆盖了很多错误等价类，这种i情况应该是归入强健壮等价类测试的吧。

liujkx1 · 发表于 2006-5-6 17:19:48

对于我这个菜鸟来说真是收获很大。

yuqing · 发表于 2006-5-12 11:17:09

我觉得你采购模块的内容不详细,还有采购模块用例很少的

davids · 发表于 2006-5-15 09:28:17

原帖由 billsong 于 2005-2-17 21:56 发表
还有刚才关于“按照Test Case执行测试，但是还是没发现问题”，
首先，一个再好的程序不可能没有Bug。
我觉得很有可能是Test Case设计的问题；不过在实际测试中，其实很大一部分Bug不是靠Test Case发现的。

是的，呵呵，我也有这样的感觉！
TC多少有点形式主义！

davids · 发表于 2006-5-15 09:32:29

原帖由 bluemay217 于 2006-4-12 12:25 发表
btw，我们的测试用例是用Excel形式来写的，感觉总是写得不全，思路好像没有拓宽

以前的公司是用的WORD，现在用的EXCEL，其实都差不多！
个人感觉WORD更清楚些！

rain0905 · 发表于 2006-5-16 16:42:27

恩!不错!我也是新手!今天去面试了!出了一道题目!让我自己设计测试用例!说是输入框可以输入8个数字字符!提交后,会变成yyyy--mm--dd的形式!是功能测试!写了一点,不知道对不!以前都没有写过!请高人指点!

CONNIE06 · 发表于 2006-5-18 11:20:32

楼主,写得很不错.
如果文档资料不够详细,如要写一份好的测试用例,自己对业务流程也要很清楚才可以.特别是项目急的时候.

鲁西西 · 发表于 2006-5-18 15:50:05

有一些想法想与各位XDJM交流一下:
不知对于多任务的操作系统的案例如何写作?欢迎大家多给意见!

flywithwind1226 · 发表于 2006-5-26 17:09:56

我觉得这是一个比较好的话题，第一次从头到尾地看完这么长的贴，感觉收获颇多。大家可以多多发表自己的看法，从别人的看法中，往往能激发很多灵感。我也是一个测试新手，看到大家的发言，我也有表达的冲动了，呵呵，抛砖引玉。

测试用例，在测试的过程中也可以不断地新增和更新。之前有人说，编写好的测试用例往往测不出什么问题，反而是在测试过程中灵机一动测出了更多的BUG。我觉得并不能因此而降低测试用例的重要性，而是恰恰说明了测试用例的不够完善。可以把那灵机一动产生的用例添加到你的用例中，这样也是经验积累的一种方法。

stone131 · 发表于 2006-6-6 23:57:14

软件质量稳定的21个因素???请问哪里有这方面的介绍，麻烦告诉一下，谢谢。

大家好不好 · 发表于 2006-6-7 09:38:39

我也是测试新人，而且更倒霉的测试部公司的新部门，所以所谓的测试牛人就是我一个sdlkfj9，有问题无人商量，好可怜！！！sdlkfj9
谈一谈我对测试工作中的问题的分析。
测试用例的编写的环境大致分为两种：1、有设计文档一应具全（较大的系统），编写详细测试用例比较简单。sdlkfj2 2、时间紧张，直接进入开发状态（小系统），根本无法编写测试用例sdlkfj8
对于情况二，要做的只能是一件事，通过系统流程编写页面数据的迁移，确保测试人员自身对系统的了解。以后的测试就把自己假设为一般的普通用户，先进行正常正确的测试，就是保证可以录入的一项不空全部录入，接着在就是查看数据是否显示正常（就是显示在该显示的的地方，不要在数据库中查看，没有用户会去看数据库），再接着检测最小输入（就是必填项）先保证基本功能实现先，这样程序员也好跟用户演示，你就赶紧趁这段时间完整你的测试用例（而且你对该系统也有了进一步的了解，可以开始构思如果在什么什么情况下会不会出错了sdlkfj2）。

tongsheng520 · 发表于 2006-6-7 11:09:27

新手，问候大家了，我刚准备入行了，学软件的以前

		自动登录	找回密码
密码			(注-册)加入51Testing

小弟做黑盒测试及测试用例的一点心得，写出来原和大家一起分享。

keyi

太经典了！

采购模块

我们的案例

加入头脑风暴

站长推荐 /1