Test Case所涵盖的范围足够了吗?

2014-07-23   出处: kojenchieh.pixnet.net  作/译者:kojenchieh



很多人常常问, 如何得知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的版本, 可能也没有数据可以参考

6. Test Case Type
在开立测试个案之前, 先将测试个案分类, 至于要分成哪些类别, 可以根据team的需求自行定义. 因此当QA在开case时, 要对其test case分类, 之后便可以检查是否他所开立的case种类涵盖度够. 可参考以下文章, 知道更进一步作法
http://www.wretch.cc/blog/kojenchieh/12801500
Pro
- 若是你没有分类, 这个QA所开的case可能都只是属于某几类, 即使个数很多, 代表性可能也不够
- 训练QA能从更多面向来思考
- 若是之后发现某些类别(type)要增加, 可以在要求所有QA针对这项目来加开
Con
- 要有哪些类别(Type)不容易定义完整
- 有些类别(type), QA不知道那是什么或是要怎么开case. 例如 security test case, state based test case等等.


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
333° /3338 人阅读/0 条评论 发表评论

登录 后发表评论