1)基本功能的实现.
2)异常情况的处理.
3)需求复盖率.
4)业务关联性.
5)数据正确性. Originally posted by jackei at 2004-10-27 05:52 PM:
其实关键在于导师想讨论的不是“测试用例的好坏”,而是测试用例的有效性。什么有效性呢?是否可以具体说说?比如:如何保证在需求或设计发生变化时测试用例可以仍然具有有效性?
关键还是问题没有问明白。
个 ...
没懂也 如果需求发生变更的话 那么很有可能模块设计也会产生变更 那么如何来保持用例的有效性呢? 感觉写测试用例时,首先要对业务熟悉才可以,其次是对测试的系统 太专业的话我也讲不来,现在对书上的一些说法也都搞不太清楚!我觉得还是要在实践中自己体会,然后自己总结!光听别人的有时还是一知半解!
不过还是多多讨论的好:)互相帮助嘛! 哎,可惜自己不是计算机专业,学校里接触的东西太少啊! 测试用例的有效性还应该考虑到性能测试方面的吧! 测试的有效性的含义我觉得应该有两个,第一个是测试用例描述的内容是否正确,是否符合软件需求,第二个就是测试用例是否是多余的用例。
我觉得保证有效性的一个方法就是建立需求与测试用例跟踪矩阵。测试用例维护要及时。
自己回答不了,看别人回答也挺有意思的。
外部因素:
1。需求的有效性。
2。文档的有效性。
内部因素:
1、用例分析的全面性。
2、用例的可执行性。
3。流程的有效性。 听起来很有道理!!呵呵 Originally posted by ok at 2004-10-26 09:55 AM:
每次我们在写测试用例时,都是根据:这个模块要实现什么功能,进行什么样的操作,选择什么样的操作数据,会产生什么样的预期结果,不能产生预期结果的就提交到问题卡中。我们有一个很好的管理bug的,写测试用例的 ...
在充分了解需求的基础上,才能编写出有效的测试用例啊!
而且,从软件的需求开始,测试就需要参与其中了 !
有了一定程度的了解,才能写出有针对性的东西 做代码白盒的最好,很多问题可以在开发期 集成期解决 用例有效,就似药一样,你说药有效,那证据是什么?就是因为它能治病,并且治好了病。测试用例也一样,并不是越细越好,也不是越多越好,也不是越多BUG越好,而是在现有的阶段,能解决现有的问题,就是有效的测试用例
页:
1
[2]