软件测试基础(1)

拼搏现实的明天。 2024-04-06 15:53 72阅读 0赞

## 软件测试的生命周期 ##

软件测试的生命周期: **需求分析 -> 测试计划 -> 测试设计, 测试开发 -> 测试执行 -> 测试评估**.

### 软件测试 & 软件开发的生命周期 ###

> 1.需求阶段
> 
> 测试人员了解需求, 对需求进行分解, 得出测试需求.
> 
> 2.计划阶段
> 
> 根据需求编写测试计划/测试方案
> 
> 3.设计阶段
> 
> 测试人员适当地了解设计, 对于设计测试用例是很有帮助的, 测试人员搭建测试用例框架, 根据需求和设计编写一部分测试用例.
> 
> 4.编码阶段
> 
> 测试人员一般是不需要编码的, 但已经编码的模块, 专业的白盒测试人员可以计划执行单元测试, 完善, 细化测试用例以及调整测试计划和方案.
> 
> 5.测试阶段
> 
> 测试阶段是软件测试人员最为重要的工作阶段, 根据测试用例和计划执行测试, 在执行的过程中记录, 管理缺陷, 测试完成后编写测试报告.
> 
> 6.运行维护
> 
> 测试人员需要参与项目的实施工作. 测试人员对项目产品的业务和操作非常了解, 加上测试人员的沟通表达能力一般都比较强, 所以测试人员可以参与用户使用软件的培训, 在试运行项目时收集问题并及时反馈给相关负责人.

### 如何描述一个BUG ###

**一个合格的bug描述应该包括以下几个部分:**

> 1. 发现问题的版本(这个软件/项目是什么版本)
> 
> 开发人员需要知道出现问题的版本, 才能够获取对应版本的代码来重现故障. 并且版本的标识也有利于统计和分析每个版本的质量.
> 
> 2.问题出现的环境(与PC/手机端, 操作系统, 浏览器什么的有关)
> 
> 环境分为硬件环境和软件环境, 如果是web项目, 需要描述浏览器版本, 客户机操作系统等, 如果是app项目, 需要描述机型, 分辨率, 操作系统版本等. 详细的环境描述有利于故障的定位.
> 
> 3. 错误重现的步骤
> 
> **描述问题重现的最短步骤.**
> 
> 4.预期行为的描述
> 
> 要让开发人员知道怎么样才是正确的, 尤其要以用户的角度描述程序的行为是怎样的. 如果是依据需求提出的故障, 能够写明需求的来源是最好的.
> 
> 5.错误行为的描述
> 
> 描述错误的现象. crash等可以上传log, UI问题可以有截图.
> 
> 6.其它
> 
> 某些公司会有一些其它的要求, 例如故障的分类: 功能故障, 界面故障, 兼容性故障等. 有些有优先级的分类, 严重影响测试需要开发人员优先修改的, 可以设置优先级为高.
> 
> 7.不要把多个bug放到一起
> 
> 在无法确认是同一段代码造成的故障时, 不要将bug放在一起提交.

案例:

> 提交了如下bug:
> 
> 1.在短信列表, 选择一条短信, 进行删除, 删除失败
> 
> 2.在短信列表, 选择一条短信, 进行查看, 在查看页面中进行删除, 删除失败.
> 
> **明显可以看出, 描述2要比描述1更好**.

> 故障发现版本: VPS20180226\_01
> 
> 故障类别: 兼容性
> 
> 故障优先级: 中
> 
> 故障标题: ie下界面显示异常, 界面文字有重叠
> 
> 故障描述:
> 
> 测试环境: win7 + IE8
> 
> 测试步骤:1.打开vps首页, 点击"通知"链接, 进入通知页面.
> 
> 预期结果:通知页面显示正确, 一页显示10条通知, 按时间顺序倒序排列.
> 
> 实际结果:页面显示10条通知, 通知顺序正确, 但是页面文字有重叠.
> 
> 附件:上传截图

### 如何定义bug的级别 ###

**bug的定义每个公司都不一致, 在定义级别之前需要查看公司规范.**

以下为样例:

> 1.Blocker(崩溃):
> 
> 阻碍开发或测试工作的问题; 造成系统奔溃, 死机, 死循环, 导致数据库数据丢失, 与数据库连接错误, 主要功能丧失, 基本模块缺失等问题.
> 
> 2.Critical(严重):
> 
> 系统主要功能部分丧失, 数据库保存调用错误, 用户数据丢失, 一级功能菜单不能使用但是不影响其它功能的测试. 功能设计与需求严重不符, 模块无法启动或调用, 程序重启, 自动退出, 关联程序间调用冲突, 安全问题, 稳定性等. 如: 软件中数据保存后数据库显示错误, 用户所要求的功能缺失, 程序接口错误, 数值计算统计错误等. (该等级问题出现在不影响其它功能测试的情况下可以继续该版本测试).
> 
> 3.Major(一般):
> 
> 功能没有完全实现但是不影响使用, 功能菜单存在缺陷但不会影响系统稳定性. 如:操作时间长, 查询时间长, 格式错误, 边界条件错误, 删除没有确认框, 数据表中字段过多等(该问题实际测试中存在最多).
> 
> 4.Minor(次要):
> 
> 界面, 性能缺陷, 建议类问题, 不影响操作功能的执行, 可以优化性能的方案等. 如: 错别字, 界面格式不规范, 页面显示重叠, 不该显示的要隐藏, 描述不清楚, 提示语丢失, 文字排列不整齐, 光标位置不正确, 用户体验感受不好, 可以优化性能的方案等(此类问题在测试初期较多, 优先程度较低; 在测试后期出现较少, 应及时处理).

### bug的生命周期 ###

**每个公司, 每一个工具对bug生命周期的定义都是不一致的, 下面仅是一个常见的例子.**

测试人员应该跟踪一个Bug的整个生命周期, 从Open到Closed的所有状态.

**BUG状态转换图**

![1f2dee24bc8d4b0f93d364303ab69156.png][]

> New:新发现的Bug, 未经评审决定是否指派给开发人员进行修改.
> 
> Open:确认是, 并且认为需要进行修改, 并指派给相应的开发人员.
> 
> Fixed:开发人员进行修改后标识为修改状态, 有待测试人员的回归测试验证.
> 
> Rejected:如果认为不是bug, 则拒绝修改.
> 
> Delay:如果认为暂时不需要修改或者暂时不能修改, 则延后修改.
> 
> Closed:修改状态的Bug经测试人员的回归测试通过, 则关闭bug.
> 
> Reopen: 如果经验证Bug仍然存在, 则需要重新打开bug, 开发人员重新修改.
> 
> 无效的bug: open->closed, open->rejected->closed

缺陷状态的变更流程每个项目团队的实际做法可能不太一样. 并且需要结合实际的开发流程和协作流程来使用.

例如, 测试人员新发现的Bug, 必须由测试组长评审后才决定是否Open并分派给开发人员.测试人员Open的Bug可以直接分派给Bug对应程序模块的负责人, 也可以要求都先统一提交给开发主管, 由开发主管审核后决定是否分派给开发人员进行修改. Bug的跟踪以及状态的变更应该遵循一些基本原则:

> 测试人员对于每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试, 确保相同的问题不再出现, 才能关闭缺陷.
> 
> 对于拒绝修改和延迟修改的Bug, 需要经过包含测试人员代表和开发人员代表, 用户方面的代表(或代表用户角度的人)来评审.

[1f2dee24bc8d4b0f93d364303ab69156.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/ecceb1e3df39498d8ce2dd0a100509d3.png