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/
相关文章
|
7月前
|
XML 机器学习/深度学习 人工智能
CLaMP 3:音乐搜索AI革命!多模态AI能听懂乐谱/MIDI/音频,用27国语言搜索全球音乐
CLaMP 3是由清华大学团队开发的多模态、多语言音乐信息检索框架,支持27种语言,能够进行跨模态音乐检索、零样本分类和音乐推荐等任务。
304 1
CLaMP 3:音乐搜索AI革命!多模态AI能听懂乐谱/MIDI/音频,用27国语言搜索全球音乐
|
7月前
|
网络协议 Linux Go
自己动手编写tcp/ip协议栈1:tcp包解析
学习tuntap中的tun的使用方法,并使用tun接口解析了ip包和tcp包,这是实现tcp/ip协议栈的第一步。
151 15
有哪些CAD软件支持(国产操作系统)麒麟操作系统
CAD梦想画图是由成都梦想凯德科技自主研发的轻量级CAD软件,专为国产操作系统如麒麟、统信设计。支持AutoCAD所有版本的dwg二维图纸,具备精准显示、测量、标注、绘图修改、文字查找及批注等功能,操作流畅,无需安装字体。用户可通过应用商店轻松安装,适合新手和专业人士使用。
|
8月前
|
存储 人工智能 OLAP
百炼融合AnalyticDB,10分钟创建网站AI助手
百炼融合AnalyticDB,10分钟创建网站AI助手。本课程由阿里云产品经理陈茏久分享,涵盖大模型行业变革、向量数据库驱动RAG服务化探索、方案优势及应用场景、产品选型配置及最新发布等内容。通过整合通义百炼和AnalyticDB,用户可快速搭建具备企业私域知识的AI助手,实现智能客服、教育、汽车等多行业的应用升级。教程详细介绍了从环境搭建到知识库配置的全流程,并提供了免费试用资源,帮助用户低成本体验核心能力。
307 7
|
10月前
|
安全 数据中心
数据中心服务器机架是什么
数据中心服务器机架是用于容纳服务器、存储器等IT设备的结构,旨在提升数据中心的管理与运营效率。常见的类型包括开放式机架、封闭式机柜和壁挂式机架,每种类型各有特点,适用于不同的场景需求。选择时需考虑尺寸、承重、冷却效率及安全性等因素,以确保最佳的使用效果。
653 4
|
11月前
|
机器学习/深度学习 人工智能 运维
智能运维:大数据与AI的融合之道###
【10月更文挑战第20天】 运维领域正经历一场静悄悄的变革,大数据与人工智能的深度融合正重塑着传统的运维模式。本文探讨了智能运维如何借助大数据分析和机器学习算法,实现从被动响应到主动预防的转变,提升系统稳定性和效率的同时,降低了运维成本。通过实例解析,揭示智能运维在现代IT架构中的核心价值,为读者提供一份关于未来运维趋势的深刻洞察。 ###
379 10
|
11月前
|
机器学习/深度学习 人工智能 JSON
微信小程序原生AI运动(动作)检测识别解决方案
近年来,疫情限制了人们的出行,却推动了“AI运动”概念的兴起。AI运动已在运动锻炼、体育教学、线上主题活动等多个场景中广泛应用,受到互联网用户的欢迎。通过AI技术,用户可以在家中进行有效锻炼,学校也能远程监督学生的体育活动,同时,云上健身活动形式多样,适合单位组织。该方案成本低、易于集成和扩展,已成功应用于微信小程序。
|
10月前
|
Cloud Native API 云计算
云原生架构的深度探索与实践####
本文深入探讨了云原生架构的核心概念、技术特点及其在现代软件开发中的应用实践。通过分析云原生架构如何促进企业数字化转型,提升业务敏捷性与可扩展性,本文旨在为读者提供一个全面而深入的理解框架。我们将从云原生的定义出发,逐步深入到其关键技术组件、最佳实践案例及面临的挑战与解决方案,为开发者和企业决策者提供宝贵的参考与启示。 ####
|
10月前
|
人工智能 自然语言处理 安全
AI技术在智能客服系统中的应用与挑战
【10月更文挑战第28天】本文将深入探讨人工智能(AI)技术在智能客服系统中的应用及其面临的挑战。我们将通过实例分析,了解AI如何改善客户服务体验,提高效率和降低成本。同时,我们也将关注AI在实际应用中可能遇到的问题,如语义理解、情感识别和数据安全等,并提出相应的解决方案。
|
11月前
|
存储 前端开发 JavaScript
深入理解Vue3的组合式API及其实践应用
【10月更文挑战第5天】深入理解Vue3的组合式API及其实践应用
422 0