一直迷惑于test case应该详细到什么份上，作为存档的test case文档，太过详细貌似内容过于繁琐。因为自己刚入行，刚进公司的时候参加了一个项目，照着spec基本上就是一通随机测试，也没设计什么test case，结果可想而知，覆盖率很差，甚至项目过去了两个月，被项目leader问到当初有个case有没有跑，才恍然大悟，原来有很多小的细节case全都疏忽掉了。最近一个月又有一个新项目上马，但真正测试要到下一个月，照着spec写了全部的case，基本上还是非常粗的，因为是作为文档形式上交的，但想来自己以后真正测试起来总不能这样吧，所以想尝试一下以下方法：
1. 自己建立一份test case文档，test case所涉及的面要尽可能的覆盖率要高，每个细的test case个人认为步骤就可以省略掉了，基本上自己心中知道怎么做就可以了。
2. 对一个粗的test case细分要尽可能的使用测试方法理论，如等价类划分、边界值、流程图等
3. 另外思维图或许能帮上点忙，理清杂乱无章的头绪
以上体会完成于09年10月份，如下的体会是在5个月后完成的（10年2月份）
1.对spec中规定的比较细的功能点，测试case设计更侧重于测试数据的设计，这部分可以粗一点
2.对spec中没有规定的，应该集合开发和产品经理的意见设计测试case，这部分可以粗一点
3.对于系统中涉及的比较重要的业务流程，应该设计比较详细的测试场景，尽可能做到全面覆盖，这部分一定要细，毕竟这是系统中最重要的。用户允许某些细节有bug，但觉不允许业务流程上有重大bug。
迅雷下载电影举例（不考虑本地磁盘空间是否满足的条件）：
场景1：下载队列为空，点击下载电影A
场景2：下载队列中有影片在下载，点击下载电影A
场景3：下载队列中存在电影A，点击下载电影A
场景4：下载队列中不存在电影A，但是本地下载目录存在已经下载好的电影A，点击下载电影A
......
今天和所带项目的一位组员探讨测试用例的时候，关于测试用例的详细程度发生了明显的分歧。静下心来，还是想好好整理一下思路。
对于软件测试用例（只涵盖功能测试，不包括性能测试）大类，个人目前的认知基本由以下几部分组成：
n 业务场景测试：验证软件核心业务流程，包含主要功能点的逻辑路径覆盖。
n 功能点测试：包括测试方法和测试数据的组织两个部分。
关于业务场景测试，个人认为要画出详细的业务流程图及路径覆盖组合，因为这部分是软件的核心功能，在任何种类的回归测试中都要着重进行测试。至少在每次基线版本发布前进行全回归测试。如果条件允许，将之逐步实现成自动化测试将会带来非常大的效率改善。这里并不是说不强调其中穿插的测试数据和测试方法，只是对于其本身，更多想说明的是业务流程的高覆盖率的重要性。
关于功能点测试中测试方法和测试数据的设计，网上有很多非常好的文章可以参考，这里不再进行另行探讨。
对于项目组员的些许观点，这里想着重引出，在每个观点后给出自己的意见和说明，这也是写下本文的主要目的：
观点1：这个场景额组合设计情况太复杂了，没有必要这么做吧！
答：场景是非常复杂，至少本人下午花了一个多小时才刚刚理清楚开始的头绪，但不能因为复杂，任务量重就不做了，毕竟这是核心业务功能。按道理来讲，其他枝节末梢的功能点在时间进度或资源受限的情况下可以选择放弃，但是这个还真得做。
说明：被测试的软件这次是第二次新版本的发布，在早些时候第一次版本发布之前的测试中没有涉及场景的逻辑覆盖，全凭随机测试和探索性测试，幸运的是，软件合同方进行过验收测试后没有发现较大的缺陷。
观点2：你不可能将情况组合设计的面面俱到的，就像你不可能发现软件中所有的缺陷一样
答：或许在组合设计的过程中有遗漏存在，那么势必就需要进行组内甚至联合开发进行评审，以确定覆盖率和有效性。其实个人认为上述两者之间没有实质上的可比性。前者注重逻辑覆盖，这是写代码时候必须要思考清楚的；后者是一个概率学上的问题，有时候存在一定的缺陷是被允许甚至被推崇的，特别是一些细节缺陷在发布之前肯定是不会修改的，但是你跟开发说在业务流程上发现了个缺陷，开发估计会先想到出现的概率，如果用户经过此路径的概率在一定比例之上，那么势必会考虑版本的延迟发布或其它方案！
观点3：对于场景组合设计我不需要设计成表格吧，我只要按照我的思路顺着写测试用例就行了
答：个人推崇表格设计的方法，其实灵感来自于我现在的Leader，一位有7年测试经验的老测试。之前我在一个项目上也采用了当前这位组员的方式，顺着自己的思路写场景用例，后来发现其缺点还是比较多的：第一，其条理没有表格设计方法来得清晰，别人和自己都会看得比较晕；第二，相关用例之间的条件和结果对比没有表格测试法来得清楚，且表格测试法可以通过用例之间各信息的对比，能快速发现遗漏的，没有覆盖到的用例。
观点4：开发其实自己都不是很清楚其中的逻辑流程，让我们测试先理清楚其中的流程覆盖，然后他们去看代码以修复我们其中可能发现到的问题，这好像不是测试要做的事情吧
说明：现有的核心代码并不是当前的开发团队所完成，开发他们核心代码也是在不久前刚刚拿到。
答：开发的意见或许有些让人觉得不爽，OK，那换种说法，总不能要求开发去把代码看完，然后给你画个流程图，告诉你流程图上有哪些路径需要覆盖，如果真的是那样，要测试做什么？并且那样也容易被开发绕进他们的思维流程中去，做测试最忌讳就这个，我们要发现问题，势必要自己挖掘现有测试软件中可能涉及到所有路径，然后一一去验证。其实测试本身和开发是一样的，如果你把主要场景流程捋顺了，那么你相当于走了一遍开发走过的设计道路，如果你再会一门语言，那么差不多你能也模仿着做出相同功能的软件。
观点5：碰到场景中涉及到的有些似问题，又好像不是问题的问题，开发自己都说不管了，我们也就别管了
答：开发可以不用管，但QA不能不管，因为软件最终的质量保证靠的是我们，从某种程度上说，我们测试受制和听命于开发，但为了分清楚责任，我们有必要罗列清楚所有情况的组合，并且在出现问题的组合情况后面列出问题结果，然后将最终结果发给开发，由他们决定是否进行修改，我相信，这是有震慑力的，因为他们必须以白字黑字的形式进行表态。这是0或1的结果。如果开发说这个问题可以skip，那行，最终如果真出问题了，那不是我们测试的问题，因为我们已经做了我们能做的所有事情！
观点6：那你进行组合设计吧，完了我follow你的case执行，如果中间有遗漏，你负责
答：我不想过多的说明责任归谁的问题，其实作为项目Leader，我很清楚自身的责任，即使设计由组员完成，且发生了遗漏，那么显然责任也是我的，且我的责任最大，原因是我没有引导和开展好必要及正确的测试工作方法。我想这是作为一个领导者应该具备的素质。
联系客服
