|
提问者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 ] |
|