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等等.


最新内容请见作者的GitHub页:http://qaseven.github.io/
相关文章
|
18天前
|
数据采集 数据库
System Generator学习——时间和资源分析
System Generator学习——时间和资源分析
21 3
|
3月前
|
人工智能 数据处理
kettle开发-AI分流之case/switch
kettle开发-AI分流之case/switch
59 0
|
3月前
|
存储 安全 C++
【C++14保姆级教程】lambda 初始化捕获 new/delete 消除
【C++14保姆级教程】lambda 初始化捕获 new/delete 消除
|
9月前
随机ID生成的几种 方式整理(现阶段基础)
随机ID生成的几种 方式整理(现阶段基础)
194 1
|
10月前
|
前端开发
前端 window.print() 打印方案、优化策略总结(一)
前端 window.print() 打印方案、优化策略总结(一)
529 0
前端 window.print() 打印方案、优化策略总结(一)
|
10月前
|
JSON 前端开发 JavaScript
前端 window.print() 打印方案、优化策略总结(二)
前端 window.print() 打印方案、优化策略总结(二)
249 0
ts重点学习92-分布式条件类型笔记
ts重点学习92-分布式条件类型笔记
69 0
ts重点学习91-分布式条件类型
ts重点学习91-分布式条件类型
76 0
ts重点学习91-分布式条件类型
switch-case和if-else的效率比较·必看(下)
switch-case和if-else的效率比较·必看(下)
151 0
switch-case和if-else的效率比较·必看(下)
|
Java 程序员 C#
switch-case和if-else的效率比较·必看(上)
switch-case和if-else的效率比较·必看(上)
391 0
switch-case和if-else的效率比较·必看(上)