5,215
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
Ioridy 2010-06-13
- 打赏
- 举报
运用各种方法来考虑用例.
有句话~怀疑那个点有问题就写想对应的case，我们怀疑所有的点都有问题
有句话~怀疑那个点有问题就写想对应的case，我们怀疑所有的点都有问题
cawangjun 2010-06-06
- 打赏
- 举报
测试分析、设计都是有工程方法可循的，从需求入手，逐步细化
wangdhmchao 2010-05-11
- 打赏
- 举报
测试用例是不可以穷举的，只能写一个有用的、有效的用例，尽量覆盖全面
可以用很多方法：正交法、边界值、判定表等……
可以用很多方法：正交法、边界值、判定表等……
AwL_1124 2010-04-30
- 打赏
- 举报
全面有点困难
我的思路是：先从checklist出手，再细分。当然细致的程度不一样，用例的复杂度也不一样。
我的思路是：先从checklist出手，再细分。当然细致的程度不一样，用例的复杂度也不一样。
csdnrobert 2010-04-27
- 打赏
- 举报
覆盖到什么程度，很难界定
kenshinssz 2010-04-23
- 打赏
- 举报
测试用例只能说尽可能的覆盖全面，这个覆盖全面可能需要很久的积累来做的。简单一点的可以按照下面几个步骤做。
第一，确认用例是否完全覆盖了需求说明书所描述的所有功能点及逻辑。可以使用各种用例的设计方法来满足，边界值，等价类，判定表，因果图，正交分析，场景法等等。别看这些东西大家都在说，真正用好很难。
第二，尽可能的考虑及补充需求说明书并未描述但是实际存在的功能及逻辑。这个可以通过需求评审，用例评审来做。
第三，尽可能考虑异常情况，可以从可靠性，安全性等方面入手。
第四，可以通过平时的积累来达到，比如建立用例库，经验库等。
第五，就是要靠自己的经验和第六感了，呵呵~这个不靠谱，但是确实可以利用。
做到完全覆盖基本不可能，但是我们可以尽可能覆盖。注意，在尽可能覆盖的同时也要考虑测试周期及项目时间的分配。
第一，确认用例是否完全覆盖了需求说明书所描述的所有功能点及逻辑。可以使用各种用例的设计方法来满足，边界值，等价类，判定表，因果图，正交分析，场景法等等。别看这些东西大家都在说，真正用好很难。
第二，尽可能的考虑及补充需求说明书并未描述但是实际存在的功能及逻辑。这个可以通过需求评审，用例评审来做。
第三，尽可能考虑异常情况，可以从可靠性，安全性等方面入手。
第四，可以通过平时的积累来达到，比如建立用例库，经验库等。
第五，就是要靠自己的经验和第六感了，呵呵~这个不靠谱，但是确实可以利用。
做到完全覆盖基本不可能，但是我们可以尽可能覆盖。注意，在尽可能覆盖的同时也要考虑测试周期及项目时间的分配。
hujing19880618 2010-04-23
- 打赏
- 举报
找出最有效的覆盖，记住：一个好的成功的测试用例是能够找出bug的，自己想想吧。
crazypeter2005 2010-04-20
- 打赏
- 举报
口气太大了，不应该追求100%覆盖啊。
测试是在规定时间尽可能的交付。
等价类的应用： 你一个函数可以去覆盖路径，一个对话框可以争取去覆盖各种边界值，负相值。
但是对整个被测系统，一定有很多覆盖不到的。
据说火箭发射的软件也才到99%，你一个游戏到不了100%的
再就是逆向思维，星际里面的好多Bug都是无意中玩出来的。得熟悉游戏吧，测试就是资深玩家啊。
测试是在规定时间尽可能的交付。
等价类的应用： 你一个函数可以去覆盖路径，一个对话框可以争取去覆盖各种边界值，负相值。
但是对整个被测系统，一定有很多覆盖不到的。
据说火箭发射的软件也才到99%，你一个游戏到不了100%的
再就是逆向思维，星际里面的好多Bug都是无意中玩出来的。得熟悉游戏吧，测试就是资深玩家啊。
