》我觉得这并不恐怖，恐怖的是你们有时间和精力去执行这些组合吗？
如果你们想毫无策略的组合测试用例，除非你们的是个小产品，否则测试执行基本是不可能完成的。我从你的留言看到的意思就是你们想穷举组合关系，然后进行测试，这样是不可行的 这种穷举组合测试是开发人员提出来的，而且他希望我们能把这种组合作为用例写出来，否则他觉得用例不够完整，执行结果也不能真实反映出质量情况，但我觉得如果把组合按用例那么去写，这个最终将变成“不可能的任务”，所以我想找一个工具，把组合单独进行管理，用例单独建设单独维护
我现在也很担心执行的效果，我想任何一个测试人员看到我们的成千上百条用例会不头晕，开发人员总是希望能把所有的可能性都测试到，我说这个是不能在系统测试里保证的，需要单元测试和集成测试集体来完成，但他们想让我设计用例来保证这种覆盖率，所以我也只好把不可能来变为可能了 我目前正在测试的软件功能也具备这样的特点：各功能相对独立,各功能可以任意组合。一个功能可能包括1个或者多个case，我们所要进行的是功能之间的组合，不是case之间的组合。组合的最小单位应该是相互独立 的功能。而一般的软件功能个数不会太多，因此功能模块之间的组合也不会是无穷的。所以我觉得遇上类似软件的测试，最重要的是要把握各功能之间的界限。 个人认为：
组合用例还是要创建的，但不可能包括所有组合。一般说一级组合（即两两组合）还是会很容易出现的，这些都是必须要写的。对于多级组合，要有目的有针对性去写，那些出现机会很大的必须写，那些可能出现但机会很少很少的，当然就没有必要了，必定我们测试人员没有那么多的时间和精力。 测试用例确实需要一定的组合，一般我们认为功能接近或有关联的进行组合，但是有时看似不相关的功能点相互之间也是有影响的，这个只能通过多次的测试，个人认为此时开始写测试用例的组合不是很现实，因为组合无穷多，不可能尽列。可以通过长时间的随机测试，似乎没有任何目的，当发现问题后，在针对发现问题的操作功能之间作详细的测试用例的设计。 我也正遇到楼主这样的困惑呢。
我现在只是把单个模块的用例都写了，但组合的地方只是很笼统了写了几个，实在不知道都组合下去会怎么样。只是分了几类，按类别组合了一下。
页:
1
[2]
