测试执行和缺陷跟踪

  • 时间:
  • 浏览:
  • 来源:互联网

测试执行方式

1、手工执行
根据前期完成的测试用例,按照测试计划的进度要求进行逐个执行,判断执行的实际运行结果与用例中的预期结果是否一致,如果一致则该测试用例通过,否则失败;如果失败,则需要提交一个bug报告。
2、自动化执行
前提是先要执行一遍手工测试,先把系统中的bug尽量地测试出来,并完成至少一次回归测试,从第二次(或者第三次)回归开始将测试用例转化为测试脚本(python+selenium+unittest+jenkins),既可以脚本定时自动执行啦。

缺陷的基本概述

缺陷的定义

  • 软件未实现产品说明书要求的功能
  • 软件出现了产品说明书指定的不应该出现的功能
  • 软件实现了产品说明书未提到的功能
  • 软件未实现产品说明书虽未明确提及但应该实现的目标
  • 软件难以理解 、不易使用、运行缓慢或者从测试者角度看会被最终用户认为不好

缺陷的属性

缺陷的类型:根据缺陷的自然属性划分的类型
功能缺陷
UI缺陷
文档
代码缺陷
设计缺陷
性能缺陷
缺陷的严重等级:由缺陷可能会引起的失效或者故障的严重程度
致命等级:

  • 主要核心流程功能完全丧失

  • 如果可能引起机毁人亡这情况

  • 核心数据计算失误

  • 由于软件问题导致硬件的不可用

  • app出现异常闪退并且不能恢复现场
    严重等级:

  • 主要核心流程部分功能丧失

  • 非核心功能未实现,对系统业务影响不大

  • 非核心数据计算不精确或错误

  • APP 闪退之后,重启可以恢复数据
    一般缺陷

  • 数据有效性验证的

  • 提示信息不准确、错误

  • 某个页面空白

较小缺陷、瑕疵

  • 使用不方便
  • 错别字
  • 排版不合理
  • over lap重叠
  • cutoff截断
  • 文字排列不整齐

其它严重等级缺陷划分标准:

  • p1致命
  • p2严重
  • p3缺陷
  • p4瑕疵
  • p5建议

缺陷的优先级:指的是缺陷被紧急修复的紧急程度,哪些缺陷是需要优先修复的,哪些是可以后续修复的

  • 立即解决:该缺陷可能会导致系统的主要流程走不通(系统阻塞),需要开发立即修复
  • 高优先级:缺陷严重,影响测试,需要优先考虑修复
  • 正常排序:缺陷按照正常的排队顺序 修复即可
  • 低优先级:缺陷可以在开发人员有时间的时候被修复

还有划分方式简洁的:

缺陷的状态:在缺陷的生命周期中,不同阶段所处的状态,使用缺陷管理工具的时候会用到

  • 激活或者打开:指的是缺陷提交后,公开给开发及相关人员看到
  • 已修正或修复:开发人员认可了缺陷,并且按照缺陷的描述在代码中修复了该问题,测试人员还未进行确认
  • 关闭:开发人员修复后,测试验证通过,则把状态更新为关闭
  • 重新打开:开发人员修复后,测试人员测试验证未通过缺陷还存在,把缺陷状态更新为打开
  • 推迟修复:在当前版本不修复,下个版本修复,必须相关负责人确认,不能关闭持续跟踪
  • 保留:缺陷是第三方输入插件的问题,开发没有修改权限,保留等待第三方授权或帮着修复
  • 不能复现:测试人员提交缺陷报告或缺陷描述不清晰,开发不能复现问题,我们要提供更多材料,比如截图视频或日志文件保证开发可以复现问题
  • 重复:多个测试人员提供了相同的问题,需要进行去重复,开发已经修复问题,后面相关问题就置为重复
  • 不是缺陷:不是软件的缺陷,直接删除掉

缺陷的起源:缺陷第一次被发现的位置
需求
设计
架构
测试
编码
用户
缺陷的来源
需求说明书
概要设计
详细设计
接口文档
数据库
代码

缺陷报告

主要讲一个缺陷报告应该包含哪些要素?模板是什么样的?
主要的因素
缺陷的ID:便于检索;用于与其他文档或者表交互;可以是主键数字或者自定义(YHJF-rej-bug-001)

关联的测试用例的ID:在执行哪一个用例的时候发现的缺陷,就用那个用例的ID
缺陷的标题:使用简洁的描述,把问题现象说清楚
例如:QQ授权登录时出现404
缺陷的前置条件:直接从测试用例拿来
缺陷的重现步骤:直接测试用例拿
实际结果:实际结果和预期结果的关系

缺陷的严重等级:
缺陷的优先级:
缺陷的类型:

提交人:
提交时间:
附件:图片、视频、日志文件等
缺陷报告的编写目的

  • 易于管理和检索测试过程中发现的缺陷
  • 报告的软件缺陷进行了必要的隔离,报告的缺陷信息更具体、准确
  • 软件开发人员希望获得缺陷的本质特征和复现步骤
  • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

预期读者
开发人员、质量管理人员、市场人员、运维人员
缺陷报告编写准则-5c准则

  • 准确:每个组成部分的描述准确,不会引起误解
  • 一致:按照一致的格式书写全部缺陷报告
  • 完整:包含复现该缺陷的完整步骤和其他本质信息
  • 简洁:只包含必不可少的信息,不包括任何多余的内容
  • 清晰:每个组成部分的描述清晰,易于理解

缺陷管理系统

  • Bugzilla(英文):安装比较繁琐
  • Bugfree:中文 安装简单 用例 缺陷的跟踪 功能单一
  • mantis:php软件,只能进行缺陷的管理
  • 禅道:中文 国产 项目 产品 测试 齐全 组织机构 人员 开源 免费
  • QC(ALM):18年之前是HP,之后卖给了英国microfocus公司,英文 功能齐全 企业自己开发

本文链接http://element-ui.cn/article/show-97905.aspx