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

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

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

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

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

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

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

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

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

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

见笑了，HOHO~