第231贴【2005－05－18】：基于需求的测试

天网

研究结果表明软件错误中超过50％错误根源在于错误的或不恰当的软件系统需求定义。事实上，很多软件开发项目并没有写软件系统需求定义。同时研究结果表明80％以上的用于定位软件错误的费用是基于软件系统需求定义的错误。通常，错误越早发现，用于纠正错误的开销越小。
    从这些研究可以看出：改进软件系统需求定义开发过程和功能测试设计过程，可以大大提高软件质量和降低研发成本。基于需求的测试就是这样一种技术。
     基于需求测试包括两大技术。第一种技术用于测试需求文档，称为二义性评审。测试需求文档时所要遇到的最主要的问题是需求文档近乎采用人类自然语言来描述，而自然语言不可避免地具有二义性与不一致性，从而采用自然语言定义的需求同样具有二义性与不一致性。这样就需要产生一框架以解释这些文档，因果图则提供这一框架。
     第二种技术是基于功能的一种黑盒测试用例设计技术，称为因果图法。此技术在七十年代早期为IBM公司威廉姆爱尔门道夫所开发使用，用于测试硬件逻辑的数学精确算法，这些算法称为“路径敏感化算法”。此算法效果已经被一些硬件产品的高可靠性所验证，例如，Intel公司80486芯片具有超过120万个晶体管，但运行至今只有一个逻辑错误。采用因果图可对需求定义进行非二义性的解释。因果图的产生是由一套有限的逻辑符号来实现，这些符号为：AND、OR、NAND、NOR、XOR及NEGATION。只需一天时间即可学会这些符号的含义及如何使用他们画因果图。所有的软件逻辑都可使用这套逻辑符号来构建。采用因果图可以表达软件需求定义。一旦表达需求的因果图开发出来后，可根据路径敏感算法自动设计测试用例，并在后期可以自动进行验证，并能够达到一定的覆盖率。

haven6

好贴  楼主  再发些类似的帖子

snake007008009

支持，期待更多天网的帖子

jackei

原文可以从这里下载

http://www.cnblogs.com/jackei/archive/2005/03/03/112201.html

jackei

对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的直白一点，就是要保证所有的需要实现的需求在最终实现后，都可以用某种方法来明确的判断是否符合需求文档中的要求。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。

上面一段文字摘自我发表在《程序员》杂志2004年第8期的《软件测试实践之测试需求与测试用例》，应《程序员》要求，转载或引用请注明出处。

luming

把两个都下载了，谢谢！

someone5

谢谢skinapi.^_^

skinapi

关于因果图可以参见以下两篇帖子：
http://bbs.51testing.com/viewthread.php?tid=2181&fpage=1
http://bbs.51testing.com/viewthread.php?tid=2180&fpage=1
至于应用到二义性评审中，没有尝试过，个人觉得还是可以考虑引入的。

someone5

要是有个例子就好了^_^

luming

谁了解因果图法，是否可以举个实际的例子说明？

szgnju

没用过，不太清楚实用性如何？

szgnju

没用过，不太清楚实用性如何？