副作用缺陷，bug总是游离于测试用例之外，该怎么办？

hugh1st · 发表于 2010-10-28 20:53:22

本帖最后由 hugh1st 于 2010-11-2 20:24 编辑

今天看到了一个名词：副作用缺陷，就是在测试中发现的缺陷，但是在测试用例中没有体现。
这也是我目前一直存在着的问题：
无论是执行别人写的测试用例，还是执行自己写的测试用例，发现的却是总是不多，大部分缺陷都是与测试用例不相关的。不知道大家是不是也存在这样子的问题？
我们公司的测试用例是根据需求文档（确定功能点，但是要比普通的功能点详细很多）、早期版本来设计的，大家也是这样子的么？

---------------------------------------------------------分割线-------------------------------------------------------

感谢同行前辈们对我的困惑的解答

。大师们都说，对于是刚参加工作不久的挨踢人，学会总结是很重要的。最近，都在组长的带领下写测试用例，所以就谈下自己对用例设计的一些理解吧。

与测试用例设计最相关的应该是需求文档吧。在软件工程中，我们会学到概要设计说明书、详细设计说明书等等，等自己进了公司，才知道那些都是浮云。所以我们要好好地学习软件需求。之所以用“学习”这个词，我觉得：在这个过程中，我们除了要了解软件的用途、前景等等之外，还要学习与项目相关的业务知识、业务规则等等。

我觉得测试用例的设计，实际上就是两个稀释的过程：软件需求——>功能点——>测试用例。这个过程，也就是一个逐步完善、扩大覆盖率的过程。此外，还要精益求精：在测试过程中发现有遗漏的地方，要及时补充。我们具体的实现方法就是，通过需求文档、软件旧的版本罗列出功能点，不过这个功能点已经挺详细了，只是缺少些操作步骤等等。而测试用例的实现往往要等到软件出版本之后，根据前期的版本补充用例。这也是我的一个困惑，大家的用例是在软件出来前就写好的，还是与我一样的呢?

一个很好的管理软件也是很有必要的，我们目前用的是TFS。管理软件一个很重要的作用就是实现了需求、用例、bug的关联，便于管理。尤其重要的是，一个bug至少要对应一条测试用例，如果某个bug没有对应的用例，就需要及时补充用例了。

见笑了，HOHO~

chxcyp · 发表于 2010-10-29 17:32:05

本帖最后由 chxcyp 于 2010-10-29 17:34 编辑

有啊有啊

，但是测试的效率跟测试用例的覆盖率也有很大关系的，
测试用例要记得在测试完之后进行更新。
我是这样感觉的，逻辑问题写详细点，界面什么细节的问题，就算没考虑到，但是在执行逻辑问题的用例时，大部分还是会发现的。

，我说的没考虑到的界面是指那些比如某个按钮单词写掉了一个字啊....字段的唯一性，长度等等都是在需求的文档里面定好的，
肯定会写在测试用例里面吧。

hugh1st · 发表于 2010-10-31 00:02:08

回复 2# chxcyp
花那么多的时间去设计、执行那些测试用例，又起不到多大的作用，感觉很浪费时间

msnshow · 发表于 2010-10-31 21:16:18

这种情况说明写测试用例的经验不足

hugh1st · 发表于 2010-10-31 21:49:44

回复 4# msnshow
是的呢，今年毕业的呢，做测试也才几个月，但是我执行别人的用例，也是这样子的啊

愚人 · 发表于 2010-10-31 22:05:31

用例覆盖度不够呗……

twinsczl · 发表于 2010-11-1 14:35:18

人数少，写用例，就是浪费精力

gsj326 · 发表于 2010-11-1 15:00:46

但是写了测试用例可以保证不会有遗漏忘记测的功能

megan0228 · 发表于 2010-11-1 15:20:44

用例覆盖度确实是个问题，怎么样才能做到100%的覆盖率呢？

lizhuo310 · 发表于 2010-11-1 17:36:14

用例是用来提醒的，如果不写用例，很多组合条件一加起来就是很多很多的功能了，那时候可不一定都能想得到。确实很多bug都是在用例之外发现的。

wzw880 · 发表于 2010-11-1 18:07:18

测试用例的用处还是很大的，一方面可以提高测试的覆盖面，在测试时不会遗漏什么重要的检查点。另一方面可以方便以后的维护和更新。副作用缺陷可以说是计划外发现的，这在我们测试过程中很常见的。

msnshow · 发表于 2010-11-1 19:55:18

回复 5# hugh1st

这个只能慢慢去完善，当你有经验了写的用例就更容易发现BUG了

愚人 · 发表于 2010-11-1 22:41:51

覆盖度不可能达到100%，只能不断总结与完善……

hugh1st · 发表于 2010-11-2 19:36:07

回复 12# msnshow
嗯，现在考虑得总是不够全面

msnshow · 发表于 2010-11-2 22:20:52

慢慢来

lizhuo310 · 发表于 2010-11-3 10:28:12

回复 1# hugh1st

我们提交bug时的描述是bug复现的步骤，跟测试用例有所区别，这样描述便于开发的理解

nickxmn · 发表于 2010-11-3 10:35:12

人的思维总是有限的在拿到产品前写好了用例但在测试产品时的会突然发现有很多遗漏

liyuan_400 · 发表于 2010-11-3 10:47:36

1.测试用例可以保证需求上要求的东西被测试到；测试用例编写的过程会发现很多需求中存在的问题，可以做到提早发现问题（和需求沟通过程就是发现bug的过程，只是那时后发现的bug不用提交，是讨论的过程）；测试用例可备以后版本升级或者补丁等复用（可以上新接收的测试人员很快熟悉业务）
2.一般用例中覆盖不到的bug主要包括以下几点：1）异常操作（如选择上传某个东西，选择后未点击确定前删除；或者一些并非操作等；） 2）不同模块之间调用的问题；3) 需求本身没考虑到的问题；而这些一般的测试用例编写时也不这么发散的写下去，一、成本问题；二、每个人经验不同和测试方法的不同，这种异常操作可以说是无穷的；所以一般都是靠经验积累的；
3.你执行测试用例时很难发现bug可能是你测试的版本已经被测试过n遍了，一般第一轮的测试的话会发现很多bug的；

哈哈，综合以上几点，测试用例编写时非常有作用滴；尤其是开发初期可以避免很多考虑不到的bug以后发生哦

hugh1st · 发表于 2010-11-3 18:48:48

回复 16# lizhuo310
我们也是这样子，但是我们提BUG的时候还要表明用例

liangshi · 发表于 2010-11-7 22:28:33

用TFS管理测试用例？请问是TFS 2008还是TFS 2010？

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

[讨论] 副作用缺陷，bug总是游离于测试用例之外，该怎么办？

相关帖子

站长推荐 /1