很多人常常问, 如何得知test cases是否已经开得足够了, 是否已经cover所有的范围了, 这还真的是很难回答的问题, 但是也是各很值得大家一起讨论的问题.
因此小弟在此先抛砖引玉, 先列出一些个人的看法, 希望大家能够一起参予讨论, 贡献一下不同的想法
1. Requirement - Test Cases Mapping
常见的手法, 是建立requriement/design 和test case的对应关系. 这样你便可以知道, 是否每个requirement已经有对应的test cases. 如果没有对应的部份, 便要加开 test case
Pro
- 容易开始作
- 提供一个high level mapping relationship
- 有这样的关系, 之后还可以进一步做一些分析, 例如 bug, test cases和requirement的关系
Con
- 不容易对所有细项功能都做这样的mapping, 会花大多时间
- 通常常没有requriement/design的文件, 所以想mapping也mapping不起来.
2. Test Coverage
经由coverage ratio你便可以知道哪些地方没有测到, 便可以要求加开test case
Pro
- 可以精确知道哪里没有test case包含到
Con
- 不是所有系统都可以找到可以使用的coverage tool
- coverage criteria是一个重点, all statement coverage 100%, 和all decision coverage 100%是不同程度的coverage. all statement coverage 100%只是最低程度的要求(我是以学术研究的角度来看, 呵呵)
- 如果都不写erro handling的程序, coverage ratio通常最高, 但我想这应该不是你要的结果
- 需要RD协助, QA才能进行的比较顺利. 因为要分辨3-party的 codes, 或是exception handling, error handling的执行, 这些地方常需要RD帮助才能做到
3. Beta Bugs
由Beta 所找到的bugs分布或是数量, 可以知道目前的test case是否已经足够了. 若是有些部分被找到很多bug, 那便是这部份的test case还不足够
Pro
- 可以提供不同的角度来验证是否足够, 尤其这是real world的观点
Con
- 这个时间点已经在项目后期, 因此可能会让你没有时间再补开更多test cases, RD也可能没有时间作design的修改.
- 可能有些公司是没有Beta这个阶段, 所以你没办法有这样的信息
- 有些project是不需要Beta这个阶段, 所以你没办法有这样的信息
4. Alpha Bugs
由Alpha所找到的bugs分布或是数量, 可以知道目前的test case是否已经足够了. 若是有些部分被找到很多bug, 那便是这部份的test case还不足够. 和Beta不同的是, 一定会有Alpha这个阶段
Pro
- 可以根据找到的bug, 再加开test case以增加完整性
Con
- 在Alpha阶段, 就要能一边测试, 一边review测试个案是否足够, 否则也是会太慢才得知不够
5. History data
可以根据历史数据, 来得知是否已经开足够的test case. 例如大约多少行的程序要开立多少的test case. 或是多少test case害找多少bug. 用他们还回推是否test case已经足够
Pro
- 通常下一个版本时, team的能力不会改变太多, 所以出来的数据是蛮准确的. 不会因为你做过一次或是功能不同, 而会差太多
Con
- 真尴尬的是, 大部分的公司或是team, 没有记下任何历史数据
- 如果是1.0的版本, 可能也没有数据可以参考
