关于用例组合测试的讨论
当针对功能的用例建立完毕后，是否还要创建组合测试用例呢？因为有很多功能组合测试才可能更容易发现问题，但是要想把全部功能组合起来，当功能比较繁多时，可能就变成无穷尽的组合项了，该如何进行对这种用例的管理呢？请大家发表一下高见，在下洗耳恭听 自己的一点薄见：用例的设计主要还是分功能和流程 你说的用例的组合 我想可以理解为小些的流程用例设计 举例来说：一个页面可能有很多内容 但实际上一条线 可能就能囊括70%-80%的功能 我想到最后还是看用例的选取了 以最少的功能用例点描述来覆盖大部分的用例组合 在设计的时候 你可以进行标注 那些是关联性的用例 与哪些用例有关联
因为前期的文档和测试需求是可以进行指导的 跟你说的流程还不太一样，我们的软件不是那种工作流软件，功能都是独立的，但是测试时不能说把功能单独测试到就算测试工作进行全面了呀，有些功能可能覆盖或叠加时，会有一些错误出现
但是把这些功能进行穷举组合，可能又会使这种组合用例数量激增，而且似乎是无止境的了
最后管理起来也没有太好的办法，如果单纯把组合列出，不考虑用例间的执行顺序、操作步骤、预期结果，其测试执行者填写的执行结果似乎又不能反映出软件的实际质量，因为没办法知道他是否将用例组合的全部可能都测试到了 我想是不是能有一个这样的工具，可以对挑选出的用例进行自动组合，并且可以填写执行结果，最后生成报告，而且还可以将这种组合进行保存，在下次测试执行时直接调用 用例设计的时候，遵循一定的标准，而不是一味的去数学组合。
而且测试用例本来就需要达到一定的数量 现在我们的测试用例还在建设中，数量就已经很惊人了，如果把全部用例组合起来，再形成新的用例，最后的数目就不可估量了，将来维护起来恐怕也会有困难的
这种组合的标准到底是什么，现在没人能提出，而是要追求大而全，这就是个问题
用例对测试工作确实有指导意义，但现在是想把用例覆盖为测试的全部内容，这点是否是可行的？ 组合的标准去用户那找，用例就是要追求大而全，然后划分等级。 我们做的产品，按公司的规定是不直接接触用户的，需求都只能由另外一个部门去跟用户打交道，收集意见再反馈回来，用例确实可以大而全，但是用例组合用穷举法靠人工手写是怎么做到大而全的？最后怎么管理？怎么保证执行效果呢？
希望版主不要说的这么简单，最好能提出一些实际有效的建议，谢谢了 我们现在的软件中，这些功能点都不是非要有必然联系的，简单点说不是那种非要做A才能做B和C，完全是可以A，可以B，也可以C，但是很有可能A做完了，再做B和再做C时，会出现一些bug
打比方说，用windows的绘图工具，可以画直线，可以画圆，也可以写文字，也可以裁减和旋转、反色等等，这些功能用例都很容易覆盖到了，但是如果组合起来，其组合用例该怎么写才能覆盖完全呢？ 如果你们确实需要这样测试的话，我建议你们把用例尽量多的自动化，然后按照你们的执行顺序策略运行测试 是的，如果是自动化测试就好办了，但现在是编写手工测试的用例组合，有这样的工具么？如果全靠写实在是有点…… 我说说我的用例设计方法：
1、功能的组合实际上包含两个方面：功能的选取、功能的先后顺序
2、拿楼主提到的windows绘图工具作例子
用windows的绘图工具，可以画直线，可以画圆，也可以写文字，也可以裁减和旋转、反色
1)先把这些功能进行分类，比如可以把画直线、画圆、写文字等看成一类A，裁减等看成一类B，拉伸、旋转等看成一类C，反色等看成一类D，把这四类看成四个因子运用正交分析法确定功能的选取
2)然后再看每一组选出来的功能，比如现在选出来一个画圆-裁减-拉伸-反色的功能组合，下面考虑其功能的先后顺序，最简单的是考虑其全排列组合，如果你不想设计这么多，可以考虑让每个功能在每个顺序位置（1、2、3、4）都出现一次就可以了
以上是我大致的一个想法，欢迎大家讨论！！！ 谢谢版主的回复，不过我想你可能没明白我来咨询的目的，现在的想法是想把这些组合全部罗列出来，但是存在如下的困难：
上面说的那只是全部功能的冰山一角，所以单靠手工按用例的格式进行组合的编写的话，似乎工作量太大了，毕竟我们只是一个小的开发团队，而且也担心这样编写完以后，将来一旦有新功能加入或者功能变更，这些组合用例的维护工作量也不小啊，所以我想寻找一个解决途径。就是是否有这样的工具，可以利用现有用例，从中选出想要进行组合的做个登记，可以将每种排列顺序都记录下来，并且最好能够填写执行结果，并导出这个report，将来如果用例有变更时，不必对组合进行修改，只修改用例即可
我想问的并不是组合的办法，而是对组合进行管理的办法 有吗？我也要这个工具 我也是在寻找，我只知道有自动测试工具有具备这种功能的，可以将测试脚本排列组合，并输出结果，但手动测试的我找不到 或者说没有这样的工具，但是有好的管理办法，可以高效工作，也可以借鉴一下 有些东西是不能穷举的 所以才有覆盖率那么一说 关键是看你如何去选取 skinapi斑竹说了一些 我补充下 对于你所说的画图例子 是可以有很多组合 可单用 可组合用 但至少在前期做软件需求调研时 你们的需求分析部门 应该提供相应的用户习惯调查 而且对于重要功能点或经常使用功能点做划分 如果没有做到这点 就得依靠tester自己对需求的判断 而且还要说明一点的是 问题一般出现在接口和临界点 画图里使用完一个功能再继续使用另一个功能容易出问题 在使用中任意退出容易出问题 同时开两个使用相同（不同）的功能也容易出问题 而且同一类的功能可独立出来 从同一类的功能里选取一些具有代表性和共用性的 和另几类的功能进行组合测试 最后根据用户习惯选取一些功能组合项进行测试 要找出尽可能多的问题就是模拟用户 把自己想成用户来看。而且就自己的经验 我觉得用例只是做测试指导（步骤和数据范围选择） 并不是把无穷无尽的执行组合堆积在一起 除非使用者或交付者需要完整的用例。以上写的比较杂乱。。欢迎大家拍砖。 对于你所说的自身能判断并进行用例组合的工具暂时我还未见 可能也只是我未见而已
如果有 也请通知我一声 谢谢！ 我说过了我们没有功能需求，只有产品部门与客户接触时总结的一些用户需求，所以做测试设计时有很多的困难，而且我们部门中有人提出说写用例不要基于需求来写，而是要覆盖全部功能，这样就很麻烦了，即使是这些单一功能用例都不一定能保证覆盖完全，因为按他们的想法是想要覆盖全部条件分支和路径的，包括所有出错的可能性，在保证单一功能用例完全的基础上，再进行用例组合，最后生成的就是一个庞大的用例集合，感觉有点恐怖，而且这种集合最后维护起来也比较有困难，所以才想到要找一个这样的工具，不是要它进行自动判断，而是要能够将人工选择的用例以及用例顺序组合记录下来 看来只好自己开发了
页:
[1]
2
