qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

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

 很多人常常问, 如何得知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等等.

posted on 2014-08-04 09:46 顺其自然EVO 阅读(177) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年8月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜