观点1：这个场景额组合设计情况太复杂了，没有必要这么做吧!
　　答：场景是非常复杂，至少本人下午花了一个多小时才刚刚理清楚开始的头绪，但不能因为复杂，任务量重不做了，毕竟这是核心业务功能。按道理来讲，其他枝节末梢的功能点在时间进度或资源受限的情况下可以选择放弃，但是这个还真得做。
　　说明：被测试的软件这次是第二次新版本的发布，在早些时候第一次版本发布之前的测试中没有涉及场景的逻辑覆盖，全凭随机测试和探索性测试，幸运的是，软件合同方进行过验收测试后没有发现较大的缺陷。
　　观点2：你不可能将情况组合设计的面面俱到的，像你不可能发现软件中所有的缺陷一样
　　答：或许在组合设计的过程中有遗漏存在，那么势必需要进行组内甚至联合开发进行评审，以确定覆盖率和有效性。其实个人认为上述两者之间没有实质上的可比性。前者注重逻辑覆盖，这是写代码时候必须要思考清楚的;后者是一个概率学上的问题，有时候存在一定的缺陷是被允许甚至被推崇的，特别是一些细节缺陷在发布之前肯定是不会修改的，但是你跟开发说在业务流程上发现了个缺陷，开发估计会先想到出现的概率，如果用户经过此路径的概率在一定比例之上，那么势必会考虑版本的延迟发布或其它方案!
　　观点3：对于场景组合设计我不需要设计成表格吧，我只要按照我的思路顺着写测试用例行了
　　答：个人推崇表格设计的方法，其实灵感来自于我现在的Leader，一位有7年测试经验的老测试。之前我在一个项目上也采用了当前这位组员的方式，顺着自己的思路写场景用例，后来发现其缺点还是比较多的：第一，其条理没有表格设计方法来得清晰，别人和自己都会看得比较晕;第二，相关用例之间的条件和结果对比没有表格测试法来得清楚，且表格测试法可以通过用例之间各信息的对比，能快速发现遗漏的，没有覆盖到的用例。
　　观点4：开发其实自己都不是很清楚其中的逻辑流程，让我们测试先理清楚其中的流程覆盖，然后他们去看代码以修复我们其中可能发现到的问题，这好像不是测试要做的事情吧
　　说明：现有的核心代码并不是当前的开发团队所完成，开发他们核心代码也是在不久前刚刚拿到。
　　答：开发的意见或许有些让人觉得不爽，OK，那换种说法，总不能要求开发去把代码看完，然后给你画个流程图，告诉你流程图上有哪些路径需要覆盖，如果真的是那样，要测试做什么?并且那样也容易被开发绕进他们的思维流程中去，做测试忌讳这个，我们要发现问题，势必要自己挖掘现有测试软件中可能涉及到所有路径，然后一一去验证。其实测试本身和开发是一样的，如果你把主要场景流程捋顺了，那么你相当于走了一遍开发走过的设计道路，如果你再会一门语言，那么差不多你能也模仿着做出相同功能的软件。
　　观点5：碰到场景中涉及到的有些似问题，又好像不是问题的问题，开发自己都说不管了，我们也别管了
　　答：开发可以不用管，但QA不能不管，因为软件终的质量保证靠的是我们，从某种程度上说，我们测试受制和听命于开发，但为了分清楚责任，我们有必要罗列清楚所有情况的组合，并且在出现问题的组合情况后面列出问题结果，然后将终结果发给开发，由他们决定是否进行修改，我相信，这是有震慑力的，因为他们必须以白字黑字的形式进行表态。这是0或1的结果。如果开发说这个问题可以skip，那行，终如果真出问题了，那不是我们测试的问题，因为我们已经做了我们能做的所有事情!
　　观点6：那你进行组合设计吧，完了我follow你的case执行，如果中间有遗漏，你负责
　　答：我不想过多的说明责任归谁的问题，其实作为项目Leader，我很清楚自身的责任，即使设计由组员完成，且发生了遗漏，那么显然责任也是我的，且我的责任大，原因是我没有引导和开展好必要及正确的测试工作方法。我想这是作为一个应该具备的素质。