同意你的说法
边界很容易被开发人员忽视,所以测试人员应该重视起来 Quote:Originally posted by wangying1982_0 at 2004-12-18 14:37:
我是新手，请多关照。以前我按别人写的测试用例测试，但基本上测不出什么问题，不知是我本身的原因还是.....？
一可能是测试用例的问题，二是否真正理解测试用例，三程序没有问题了
我认为，程序不可能没有问题，是测试用例设计的不好。 firego007 ，或许你需要新的测试用例。 看了这么长的帖子我也想说几句，在我的工作中我们把测试用例分为功能性和非功能性两个方面的Case，功能性的Case包括Spec中提供的一些基本的功能以及各子模块（小的功能）间的联系；非功能性Case则包括一些习惯操作，压力测试，稳定性测试等Case。 还有刚才关于“按照Test Case执行测试，但是还是没发现问题”，
首先，一个再好的程序不可能没有Bug。
我觉得很有可能是Test Case设计的问题；不过在实际测试中，其实很大一部分Bug不是靠Test Case发现的。
感觉
感觉理论方面说的多了些，可是有没有人能有针对性的说一下，比如举个例子，将该例子详细说一下， 这是个测试思路，但具体测试用例怎么写，还是不清楚呀。其实我觉得代码走查最能发现bug了
另外，如果你的测试流程别的阶段和你采取相同的测试方法，那你可能就发现不了bug了。我觉得谁写的case谁测的好，一者对bug比较敏感，可能出bug了，你都没意识到。另外，找错误也比较容易。没有完美的文档，在执行的时候经常又会有其他的思路了。测试用例大多还是要根据需求文档，界面根据界面的设计文档。
来做，一条一条的对应起来，一般一条需求对应很多case.会很多的说，也挺烦的,如果需求总变的话。
对于容易出错的地方，case 最好能100%覆盖。
20%的代码导治80%的错误；我很有体会。刚测了一个exposed interface
开始执行我的test code 出现了bug. 因为刚做测试半年怕是自己的driver的问题，就跟进去，发现这个developer 的 code 写的很不规范。又加了很多case居然测出很多的bug。
其实好的测试用例 ~就能让不了解的人能够轻松执行并发现错误
Originally posted by hongtang at 2005-2-27 11:31 PM:我觉的老兄说的很准确，赞！
什么才能写一份好的用例？
但是要什么样才能写出一份好用例，虽然到现在我有写这一些测试用例，但是在实际中的应用不大 大家应该把常用的经典测试用例总结一下，还有常见的缺陷。（可能不同的系统情况不同吧） 唉,我们公司不能上网,资料也不能带出来.所以不能拿出来和大家分享 感觉楼主所设计的测试用例是一个用例思路，如果要其他测试员执行的话可能可执行性会低一点，又或者出现BUG的机率会低很多；个人觉得要写出执行性高的用，还需要对测试的功能进行细分和规划，别外测试数据可以分开来管理和维护的话会更好点。顶一下！
有心得就互相交流嘛！这样大家才有技术积累，才能互相进步！爽也
测试需求分析怎么弄？
经常听说要测试需求分析，但是却不知道怎么弄！因为一般需求分析都是开发部的经理写的，而测试人员又很少能够参与他们写
需求分析的过程！到手的都是已经写好的了。
所以我们又怎么知道这个需求分析有问题，要测试？
而且我们还要根据这个需求分析写STP呢？
再说测它又怎么测？？ 我们刚培训完,部门分工,我搞测试用例设计,这刚开始,不怎么会写,望大家多多指导!!!在论坛上多发点帖子!! 一般测试用例都是由有经验的测试设计员来编写的，测试新手编写的测试用例可能不可靠，因为它对测试还不太了解，所以不能说谁的测试用例谁来测试比较好，这点事不正确的。好的测试用例不管那个测试人员来测试都是效率比较高的。 个人心得：
写测试用例不是为了反映问题，而是为了解决问题
