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

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

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

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

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

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

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

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

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

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

见笑了，HOHO~

hugh1st · 发表于 2010-11-8 12:38:40

回复 22# liangshi
花了多少钱我就不清楚了。以前用的是自己开发的bug管理系统，平时的测试记录都在Excel里实现。用TFS，输入用例还算好的，可以直接导入，但是执行的时候还要操作用例什么的，很烦

liangshi · 发表于 2010-11-8 12:20:36

回复 21# hugh1st

贵公司愿意买TFS 2010，一是资金充裕，二是对质量比较看重。在这样的公司做测试，还是比较幸运的。

您提到用TFS管理测试用例有些繁琐。以我的观点：确实如此！任何测试用例管理系统都存在这个问题：有可能花太多时间在测试用例输入与管理上，以至于挤占了测试时间和精力。

我的看法是，应该多做实际测试，只将其中重要的用例录入测试管理系统。至于什么才是重要的，需要测试者自己去斟酌。

hugh1st · 发表于 2010-11-8 08:23:45

回复 21# liangshi
2010的，我们公司也是才刚刚开始用

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

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

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

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

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

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

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

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

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

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

回复 1# hugh1st

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

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

慢慢来

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

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

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

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

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

回复 5# hugh1st

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

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

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

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

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

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

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

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

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

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

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

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

用例覆盖度不够呗……

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

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

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

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

相关帖子

站长推荐 /1