缺陷管理及质量

本文探讨了软件开发中的缺陷管理流程,包括测试人员如何发现、记录和跟踪bug,以及如何制定严格的测试原则和过程。强调了早介入、详尽的测试和清晰的缺陷报告对于保证产品质量的重要性。
摘要由CSDN通过智能技术生成

缺陷bug
没有实现、实现过多
应该实现但没实现(隐性需求)
难理解、不易使用、运行缓慢、最终用户认为不对

缺陷管理
1、生命周期( bug 处理关系)
测试人员  发现缺陷   new 
提交缺陷  PLM/缺陷管理系统
QL 确认缺陷  open/discard/duplicate/postpone/reject
分配缺陷   开发经理  assign/postpone
修复缺陷  开发人员 fixed
验证缺陷  reopen
关闭缺陷   closed /重复/不是 bug /更多信息/不复现/保持

测试原则
尽早地和不断地介入测穷举是不可能
必要时进行回归测试
2-8原则
制定严格的测试计划
测试用例要考虑各种情况,测试用例是包含测试输入和预期输出
追溯到需求,从需求出发
写bug缺陷报告,严谨简单易懂
程序员应该避免检查自己的程序

2.软件测试过程理念
尽早 全面 全过程 独立的 迭代的测试

3.不认可的bug
需求 竞品 经理

4.不能重现的问题
rarely 
先抓取手机log
附上日志 详细描述遇到bug的过程和环境配置
后续再进行相应的尝试,复现它
有耐心  
关闭问题时,验证多版本多次。

缺陷报告模板
缺陷ID bug标题 用例ID 测试模块 优先级 严重程度 缺陷状态 前提条件 测试步骤 预期结果 实际结果 复现率 软件版本 对比信息
日志信息时间戳 报告人 附件
(准确 简洁 清晰 完整 一致)

缺陷属性
    1.type(function ui document package实施 performance验收  interface集成)
    2.severity 对软件质量的破坏程度
致命: crush 数据丢失 意外退出
严重 :一个功能导致多个相关功能失败
一般: 单个功能失效
提示/较小: 界面UI

    3.priority 
立即解决 高优先级 正常排队 低优先级
status 
    4.origin阶段
    5.source 文档
    6.root团队 方法 
    7.cause 

测试方法:黑白盒
测试策略:技术和工具 完成的标准

常见的测试类型
阶段测试: 单元 集成 系统 验收 
代码可见: 黑 白 灰
执行手段:手动 自动
测试目的: GUI 接口 性能 
其他: 回归 冒烟 探索

单元测试: 对程序的最小单元进行测试
验收测试: 交付给客户或最终用户时,与客户一起完成的测试
阿尔法测试: 内测,由用户在开发环境下进行 受控
贝塔测试: 公测 ,用户在实际使用环境下进行 后汇报
回归测试: 检查bug是否修复 以及是否引入新bug  完全回归和选择性回归

测试结束的标准是:
用例已全部执行完毕
覆盖率达到标准(功能 100%  非功能 95% 一二级100%  三四级80%  五级60 % )
缺陷率达到标准
其他指标达到质量标准

测试时间紧急 
确定优先级 加班

测试总结报告:
测试用例通过数 未通过数 通过率 未通过集中在哪个模块 缺陷汇总与分析 测试工作过程与结果 测试工作总结与改进

软件的生命周期
计划(开发什么产品 可行性研究 进度安排 制定实施计划)
需求分析(需求项 需求说明书 产品原型)
设计(概要设计 详细设计)
编码
测试
运行和维护(产品部署 运行维护 功能升级 性能提升)

质量模型 从不同维度判断产品的质量
功能性:完整 正确 适合 功能性的依从性
可靠性:成熟 可用 容错 易恢复(长时间/异常可用?)
易用性:易理解 易学 易操作 吸引性
安全性:保密 完整 真实 不可推卸责任
兼容性:共存 互操作(与其他产品对接)
性能效率:时间特性 资源利用率
维护性:易分析 易改变 可重用(更新)
可移植性:适应 可安装 可转换(不同系统平台)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值