副作用缺陷，bug总是游离于测试用例之外，该怎么办？
本帖最后由 hugh1st 于 2010-11-2 20:24 编辑今天看到了一个名词：副作用缺陷，就是在测试中发现的缺陷，但是在测试用例中没有体现。
这也是我目前一直存在着的问题：
无论是执行别人写的测试用例，还是执行自己写的测试用例，发现的却是总是不多，大部分缺陷都是与测试用例不相关的。不知道大家是不是也存在这样子的问题？
我们公司的测试用例是根据需求文档（确定功能点，但是要比普通的功能点详细很多）、早期版本来设计的，大家也是这样子的么？
---------------------------------------------------------分割线-------------------------------------------------------
感谢同行前辈们对我的困惑的解答{:4_90:}。大师们都说，对于是刚参加工作不久的挨踢人，学会总结是很重要的。最近，都在组长的带领下写测试用例，所以就谈下自己对用例设计的一些理解吧。
与测试用例设计最相关的应该是需求文档吧。在软件工程中，我们会学到概要设计说明书、详细设计说明书等等，等自己进了公司，才知道那些都是浮云。所以我们要好好地学习软件需求。之所以用“学习”这个词，我觉得：在这个过程中，我们除了要了解软件的用途、前景等等之外，还要学习与项目相关的业务知识、业务规则等等。
我觉得测试用例的设计，实际上就是两个稀释的过程：软件需求——>功能点——>测试用例。这个过程，也就是一个逐步完善、扩大覆盖率的过程。此外，还要精益求精：在测试过程中发现有遗漏的地方，要及时补充。我们具体的实现方法就是，通过需求文档、软件旧的版本罗列出功能点，不过这个功能点已经挺详细了，只是缺少些操作步骤等等。而测试用例的实现往往要等到软件出版本之后，根据前期的版本补充用例。这也是我的一个困惑，大家的用例是在软件出来前就写好的，还是与我一样的呢?
一个很好的管理软件也是很有必要的，我们目前用的是TFS。管理软件一个很重要的作用就是实现了需求、用例、bug的关联，便于管理。尤其重要的是，一个bug至少要对应一条测试用例，如果某个bug没有对应的用例，就需要及时补充用例了。
见笑了，HOHO~ 本帖最后由 chxcyp 于 2010-10-29 17:34 编辑
有啊有啊:sleepy:，但是测试的效率跟测试用例的覆盖率也有很大关系的，
测试用例要记得在测试完之后进行更新。
我是这样感觉的，逻辑问题写详细点，界面什么细节的问题，就算没考虑到，但是在执行逻辑问题的用例时，大部分还是会发现的。
:P，我说的没考虑到的界面是指那些比如某个按钮单词写掉了一个字啊....字段的唯一性，长度等等都是在需求的文档里面定好的，
肯定会写在测试用例里面吧。 回复 2# chxcyp
花那么多的时间去设计、执行那些测试用例，又起不到多大的作用，感觉很浪费时间 这种情况说明写测试用例的经验不足 回复 4# msnshow
是的呢，今年毕业的呢，做测试也才几个月，但是我执行别人的用例，也是这样子的啊 用例覆盖度不够呗…… 人数少，写用例，就是浪费精力 但是写了测试用例可以保证不会有遗漏忘记测的功能 用例覆盖度确实是个问题，怎么样才能做到100%的覆盖率呢？ 用例是用来提醒的，如果不写用例，很多组合条件一加起来就是很多很多的功能了，那时候可不一定都能想得到。确实很多bug都是在用例之外发现的。 测试用例的用处还是很大的，一方面可以提高测试的覆盖面，在测试时不会遗漏什么重要的检查点。另一方面可以方便以后的维护和更新。副作用缺陷可以说是计划外发现的，这在我们测试过程中很常见的。 回复 5# hugh1st
这个只能慢慢去完善，当你有经验了写的用例就更容易发现BUG了 覆盖度不可能达到100%，只能不断总结与完善…… 回复 12# msnshow
嗯，现在考虑得总是不够全面 慢慢来 回复 1# hugh1st
我们提交bug时的描述是bug复现的步骤，跟测试用例有所区别，这样描述便于开发的理解 人的思维总是有限的 在拿到产品前写好了用例 但在测试产品时的会突然发现有很多遗漏 1.测试用例可以保证需求上要求的东西被测试到；测试用例编写的过程会发现很多需求中存在的问题，可以做到提早发现问题（和需求沟通过程就是发现bug的过程，只是那时后发现的bug不用提交，是讨论的过程）；测试用例可备以后版本升级或者补丁等复用（可以上新接收的测试人员很快熟悉业务）
2.一般用例中覆盖不到的bug主要包括以下几点：1）异常操作（如选择上传某个东西，选择后未点击确定前删除；或者一些并非操作等；） 2）不同模块之间调用的问题；3) 需求本身没考虑到的问题； 而这些一般的测试用例编写时也不这么发散的写下去，一、成本问题；二、每个人经验不同和测试方法的不同，这种异常操作可以说是无穷的；所以一般都是靠经验积累的；
3.你执行测试用例时很难发现bug可能是你测试的版本已经被测试过n遍了，一般第一轮的测试的话会发现很多bug的；
哈哈，综合以上几点，测试用例编写时非常有作用滴；尤其是开发初期可以避免很多考虑不到的bug以后发生哦 回复 16# lizhuo310
我们也是这样子，但是我们提BUG的时候还要表明用例 用TFS管理测试用例？请问是TFS 2008还是TFS 2010？
页:
[1]
2
