很多人常常问, 如何得知 cases是否已经开得足够了, 是否已经cover所有的范围了, 这还真的是很难回答的问题, 但是也是各很值得大家一起讨论的问题.
因此小弟在此先抛砖引玉, 先列出一些个人的看法, 希望大家能够一起参予讨论, 贡献一下不同的想法
1. Requirement - Test Cases Mapping 常见的手法, 是建立requriement/design 和test case的对应关系. 这样你便可以知道, 是否每个requirement已经有对应的test cases. 如果没有对应的部份, 便要加开 test case
- 提供一个high level mapping relationship
- 有这样的关系, 之后还可以进一步做一些分析, 例如 , test cases和requirement的关系
- 不容易对所有细项功能都做这样的mapping, 会花大多时间
- 通常常没有requriement/design的文件, 所以想mapping也mapping不起来.
经由coverage ratio你便可以知道哪些地方没有测到, 便可以要求加开test case
- 不是所有系统都可以找到可以使用的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帮助才能做到
由Beta 所找到的bugs分布或是数量, 可以知道目前的test case是否已经足够了. 若是有些部分被找到很多bug, 那便是这部份的test case还不足够
- 可以提供不同的角度来验证是否足够, 尤其这是real world的观点
- 这个时间点已经在项目后期, 因此可能会让你没有时间再补开更多test cases, RD也可能没有时间作design的修改.
- 可能有些公司是没有Beta这个阶段, 所以你没办法有这样的信息
- 有些project是不需要Beta这个阶段, 所以你没办法有这样的信息
由Alpha所找到的bugs分布或是数量, 可以知道目前的test case是否已经足够了. 若是有些部分被找到很多bug, 那便是这部份的test case还不足够. 和Beta不同的是, 一定会有Alpha这个阶段
- 可以根据找到的bug, 再加开test case以增加完整性
- 在Alpha阶段, 就要能一边 , 一边review测试个案是否足够, 否则也是会太慢才得知不够
可以根据历史数据, 来得知是否已经开足够的test case. 例如大约多少行的程序要开立多少的test case. 或是多少test case害找多少bug. 用他们还回推是否test case已经足够
- 通常下一个版本时, team的能力不会改变太多, 所以出来的数据是蛮准确的. 不会因为你做过一次或是功能不同, 而会差太多
- 真尴尬的是, 大部分的公司或是team, 没有记下任何历史数据
- 如果是1.0的版本, 可能也没有数据可以参考 在开立测试个案之前, 先将测试个案分类, 至于要分成哪些类别, 可以根据team的需求自行定义. 因此当QA在开case时, 要对其test case分类, 之后便可以检查是否他所开立的case种类涵盖度够. 可参考以下文章, 知道更进一步作法
http://www.wretch.cc/blog/kojenchieh/12801500
- 若是你没有分类, 这个QA所开的case可能都只是属于某几类, 即使个数很多, 代表性可能也不够
- 若是之后发现某些类别(type)要增加, 可以在要求所有QA针对这项目来加开
- 有些类别(type), QA不知道那是什么或是要怎么开case. 例如 security test case, state based test case等等.
最新内容请见作者的GitHub页：http://qaseven.github.io/