无忧测试QQ整理——多个模块间有很复杂的关联的集成测试，20/80原则
提问者1：对于多个模块间有很复杂的关联的集成测试,在操作的时候应该注意什么呢?
回答者1：接口
提问者1：能说些具体的内容吗?
回答者1：说不上来
回答者2：这是不是要看模块间是什么样的联系？
提问者1：如何能从错综复杂的关系中写出好的用例呢?
回答者2：有什么样的联系就设计什么样的用例喽。总有脉络可循吧。
提问者1：我总是害怕漏掉
提问者2：我们用什么衡量用例的质量呢？
回答者2：我觉得应该是用例覆盖被测程序功能的比率吧（功能方面的用例）。
回答者1：我觉得测试用例的好坏就是要看他是不是发现了至今没有发现的BUG
提问者1：一个很好的测试用例就是用最小的数据覆盖所有的测试点!!
回答者2：这里是不是应该有个80/20%的原则？
提问者1：80/20%的原则是什么？
提问者2：说说听听，何为80、20% ？
回答者3：Bug的80-20原则：
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。是这个吗？
提问者3：哪里有20？
回答者2：一般用20的时间，就能测出80%的BUG，如果你再去找那20%的BUG就要用80的时间了。
提问者1：那的确是理想的情况吧，因为做用例一般难以覆盖所有的测试点，总有情况是你没想到的
回答者2：这样会不会影响整个产品的进度？
提问者1：这是做用例的最困难的地方，个人意见
回答者2：这里我想是不是应该有个平衡点，也就是什么时候应该算是测试完成了。另有个问题就是测试用例所有覆盖的范围应该有多大？ 有没有有经验的老大帮忙解说一下？
提问者1：80％是合理的数字吧－－我没什么经验
提问者1：而且很多时候，时间不等人，没有什么特别多的时间吧，到了最后感觉整个项目组都在赶工
回答者2：到最后留给测试的时间很少了。要抓重点！
提问者1：到最后，应该说至少发现了80％的问题吧，但是有可能剩下问题有那种隐蔽性很强，但是性质又特恶劣的，那就惨了
[ Last edited by bobli on 2004-8-3 at 16:17 ]
