pythonav资源分享

#缺陷管理

##什么是缺陷

- 软件中任何不满足用户需求的问题，都可以识别为软件缺陷。
- 从产品内部看，缺陷是产品开发或维护中存在的错误，异常等问题。
- 从产品外部看，缺陷是违背了某种功能的实现。

##缺陷识别方法

- 用户体验差，进行反馈
- 界面上有明显错误信息
- 功能缺失，与需求说明书不符
- 程序运行崩溃，停止运行
- 程序逻辑不正确，与用户使用手册不符
- 程序性能差，不能够承载压力访问

与专业人员来沟通识别缺陷

**注意不得站在自己主观意识去判断缺陷**

## 缺陷出现的原因

- 需求不断变化
- 工期短，软件复杂
- 编码中出错
- 设计文档不完善
- 沟通交流少
- 软硬件不支持

## 常见软件缺陷术语

- bug	泛指软件程序的漏洞和缺陷。
- Debug  **调试**（英语：Debug）是发现和减少计算机程序或电子仪器设备中程序错误的一个过程。
- 错误(mistake)  人为造成软件的故障
- 缺陷(bug&defect)  软件产品中存在的错误
- 故障(Fault)  某个组件功能不能完成所有任务的一个意外情况
- 失效(Failure)  软件功能完全损坏，无法使用

![](/media/uploads/2019/11/17/pic/n22.png)

### 经典传话游戏

![](/media/uploads/2019/11/17/pic/n2.png)

`传话游戏`

老板对产品经理说：明早八点，我们公司可能来一个新的CEO，要求大家必须穿西服，打领带，新的CEO讲给大家开个会，指引新的战略。

产品经理对人事主管说：老板说，明天要来一个新的CEO，大家必须着正装，老板将给大家开会。

人事主管对研发主管说：根据老板意思，明天要新来一个新的副总，大家必须穿白衬衫，老板要开会。

研发主管对手底下人说：老板说了，明天早上开会，大家穿的干净点，听说要开掉那个副总。

## 为什么引入缺陷
![](/media/uploads/2019/11/17/pic/n3.png)

## 缺陷的类型

`功能遗漏`

规定的时间或功能未在产品系统中体验，如缺少忘记密码功能

`程序错误`

没有按照用户需求正确实现，可能需求理解出错，可能编码出错

`额外的功能`

## 尽早引入测试

单位时间内，尽早引入测试，可以更早的发现缺陷，减少修复成本

![](/media/uploads/2019/11/17/pic/n4.png)

##缺陷的重现

可以重现的缺陷，存在一系列明确的重现操作步骤，条件和数据使得缺陷可以稳定的反复出现。

不可复现的缺陷，无法找到明确的步骤，缺陷出现是随机的，只做记录，不做报告。

不可重现的缺陷，后续再深入的挖掘，尝试转为可再现的缺陷，再进行缺陷报告。

##缺陷报告

缺陷报告指的是测试执行过程中，发现软件缺陷，进行书写记录的文档，提供给开发人员或者测试负责人作为定位缺陷的依据，也用作缺陷数量统计的重要依据。

提供准确、完整、简洁的缺陷报告是软件测试专业性、高质量的评价标准

## 撰写缺陷报告5c原则

**5c原则**

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

**缺陷报告结构**

- 报告的缺陷信息具体、准确
- 缺陷特征描述与复现缺陷步骤
- 缺陷类型以及严重级别
- 缺陷标题
- 缺陷基本信息
- 测试环境描述
- 缺陷严重程度

**撰写缺陷报告注意点**

- 按照缺陷发生的因、果进行书写
- 避免模糊不清的词语，比如`功能不对`、`登录不起作用`，应该具体描述`某一个功能如何不对`、`登录具体流程如何不正确`
- 中立评价，公正表达自己对软件缺陷的理解，对软件错误以及造成的事实进行描述

## 常见软件缺陷

| 编号       | 问题描述                                                     |
| ---------- | ------------------------------------------------------------ |
| 中文英统一 | 不要使用中英文混合提示，不要去挑战用户的英文能力..           |
| 容错性     | 例如用户注册，需要限制手机号长度，年龄范围等，输入错误需要有醒目提示 |
| 用户体验   | 比如某高校学生信息登记网，填写一堆信息后，由于一个信息填写错误，内容全部被清空，还得重新输入，用户体验极差 |
| 兼容性     | 需要考虑操作系统、浏览器类型、版本，网络类型                 |
| 错别字     | 例如网站的"登录"写成"登陆"                                   |
| 安全性     | 注意SQL注入，XSS攻击                                         |
| UI友好度   | 比如删除、保存按钮离得太近，用户手指头难以正确点击...        |
| …..        | 未完待续                                                     |

![](/media/uploads/2019/11/17/pic/2.5.jpg)

##bug学习目标

- bug类型
- bug等级
- bug生命周期

##bug是什么

bug泛指软件程序的漏洞和缺陷。

值测试工程师或用户发现与提出的，软件可以改进的细节部分、或者与需求文档存在功能偏差的实现。

测试工程师职责就是发现bug，提交bug信息给研发人员，研发人员修复bug。

### bug案例

例如登录时，要求输入账号密码。

输入正确的账号密码:

结果提示：用户名不存在/密码

再三确认账号密码是否错误，可以重新再注册一个账号进行登录

如新账号也是账号不存在，此登录已经是bug了！

##bug的类型

想要确定bug的类型，需要对产品有较深的理解。

禅道系统中对bug定义划分如下：

- 代码错误(指的是研发代码有误，功能未实现)
- 设计缺陷
- 界面优化
- 性能问题
- 配置相关
- 安装部署
- 安全相关
- 标准规范
- 测试脚本
- 其他(功能类、界面类、性能类、易用性类、兼容性类、其他)

##bug严重程度

顾名思义就是软件缺陷对软件质量造成的破坏程度，将会给软件使用带来怎样的影响。

Bug等级越高，可能被修复的等级也越高，公司也会根据测试提交的bug数量以及bug等级作为绩效考核标准。

判断bug的等级，如下分类：

`1.致命错误`

- 常规操作缺引起系统崩溃、死机、死循环
- 造成数据库泄露的安全问题，如恶意攻击造成的账户私密信息泄露
- 涉及金钱隐患，金钱计算bug(如金额不足，还可以购买产品，对公司金额造成重大损失

`2.严重错误`

- 重要功能未实现，如点击注册无反应，无法登录
- 非常规操作（误操作）导致程序崩溃、死机、死循环
- UI界面的严重问题
- 密码明文显示，数据库泄露

`3.普通错误`

- 不影响产品运行，不会影响故障，但对产品外观界面影响较大，如删除了好友，好友却未消失
- 功能无法正常显示功能
- 操作界面错乱
- 查询数据错误
- 页面未做输入格式限制
- 删除错误未给与提示

`4.错误提示`

- 网页UI错误，
- 错别字
- 标点符号

## bug处理优先级

优先级(Priority)指的是缺陷被修复的紧急程度。

- 立即解决：软件缺陷已导致软件系统崩溃，需立即修复
- 高优先级：缺陷比较严重，已经影响用户正常使用
- 普通优先级：缺陷排队，等待修复
- 低优先级：等待开发人员闲时进行修复，缺陷影响很小

## 常见bug管理状态

在不同的缺陷管理系统中，对bug的标记状态有如下种类：

- New 缺陷初始状态
- Open 缺陷修复中
- Fixed 缺陷修复完毕
- Closed 缺陷已通过回归测试，关闭缺陷
- Reopen 缺陷未通过回归测试，重新修复
- Postpone：推迟修改缺陷
- Rejected：开发拒绝修复缺陷
- Duplicate：重复提交的缺陷
- Abandon：开发与测试经过讨论，确定不是缺陷，可以标记缺陷关闭

##bug生命周期图

![](/media/uploads/2019/11/17/pic/11.jpg)

## 缺陷跟踪管理系统

早期缺陷管理大多是以缺陷记录表单形式完成，如今也还有很多项目使用此方法，但是随着用户需求提升，软件复杂度提升，缺陷缺陷也随之增长，管理也就愈加麻烦。

软件行业发展，出现大量缺陷管理系统。

- JIRA
- BUGZILLA
- HP Quality Center（QA）
- 禅道（中文、优秀！）

实力雄厚的公司还会自研缺陷跟踪管理系统，大部分公司则是选择禅道来缺陷跟踪以及项目管理。

## 测试执行过程

![](/media/uploads/2019/11/17/pic/m213.png)

**执行测试的主要任务**

- 确定测试用例的优先级
- 创建测试数据，准备测试工具以及编写自动化测试脚本
- 根据测试流程创建测试套件，提升测试执行效率
- 搭建测试环境
- 根据测试计划的执行顺序，通过功能测试或是代码测试
- 记录测试结果，编写测试报告
- 将测试结果和预期结果进行比较，将结果的差异提交上报，分析差异原因
- 缺陷修复后，进行回归测试，验证产品

## 测试准入标准

`没有经过自测的代码，就是在耍流氓`

`通过冒烟测试`

`测试范围已明确`

- 开发编码结束，并且在开发环境完成单元测试
- 开发需求规定的功能均实现，如没有完全实现，请提供测试范围
- 已经完成集成测试，被测系统的基本流程已经走通，界面上功能均实现，经过代码评审并符合软件编码规范
- 开发提交最新版本代码，告知测试组进行测试
- 测试环境兼容性确认
- 安全测试与性能测试的要求确认

## 测试停止

- 测试人员首次冒烟测试，若是发现重大缺陷或缺陷过多，导致测试卡壳基本流程无法进行，可以暂停测试回馈开发。
- 被测项目由于需求调整，被迫暂停测试
- 存在更高级的测试任务，需要暂停测试
- 被测系统达到系统准出标准，测试流程结束，可以停止测试

## 测试准出标准

![](/media/uploads/2019/11/17/pic/m214.png)