关于测试用例的详细程度

一直迷惑于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

......