软件测试—基础篇网站首页 其他

软件测试—基础篇

哔卟哔卟_: ) 2023-05-20 00:00:02

简介软件测试—基础篇

软件测试—基础篇

🔎软件测试的生命周期
🔎如何描述一个BUG
🔎如何定义BUG 的级别
🔎BUG 的生命周期
🔎测试的执行与管理
- 测试的执行与管理
- 如何发现更多的BUG
🔎产生争执怎么办
🔎结尾

🔎软件测试的生命周期

软件的生命周期
某一软件从被提出并着手实现开始直到软件停止使用为止的时间
具体可分为(1))需求分析 (2)计划 (3)设计 (4)编码 (5)测试 (6)运行及维护

软件测试的生命周期
具体可分为(1)测试需求 (2)测试计划 (3)测试设计 (4)测试开发 (5)测试执行 (6)测试评估
(1)测试需求
判断对软件的需求是否完整, 对软件的需求是否正确

(2)测试计划
a. 确定软件由谁进行测试
b. 确定软件测试开始的时间
c. 确定软件测试结束的时间
d. 确定软件需要测试哪些模块

(3)测试设计
设计测试用例(手动测试用例, 自动测试用例)

(4)测试开发
编写测试工具

(5)测试执行
测试人员执行测试用例

(6)测试评估
测试人员编写测试报告

🔎如何描述一个BUG

(1)发现问题的版本
开发人员需要知道出现问题的版本, 才能够通过对应版本的代码重现BUG, 版本的标识有利于统计和分析每个版本的质量

(2)问题出现的环境
环境分为软件环境和硬件环境, 如果是web 项目, 需要描述浏览器版本, 客户机操作系统等, 如果是app 项目, 需要描述机型, 分辨率, 操作系统版本等, 详细的描述有利于故障的定位

(3)错误重现的步骤
描述BUG 重现的最短步骤

(4)预期行为的描述
要让开发人员知道怎么样才是正确的, 尤其要以用户的角度描述程序的行为是怎样的
(如果是依据需求提出的故障, 最好能写出需求的来源)

(5)错误行为的描述
描述BUG
(可以通过截图, 录屏等方式展现BUG)

(6)其他
某些公司会有一些其他的要求
例如
故障的分类: (1)功能故障 (2)界面故障 (3)兼容性故障
优先级的分类: 严重影响测试的, 可以将优先级调高

(7)不要将多个BUG 放在一起
在无法确认是由同一段代码造成的故障时, 不要将BUG 放在一起提交

🔎如何定义BUG 的级别

不同的公司对于BUG 的级别有着不同的叫法
比如
p0, p1, p2, p3等
崩溃, 严重, 一般, 次要等
但具体的意思都是差不多的

(1)Blocker(崩溃)
阻碍开发或测试工作的问题
造成系统崩溃, 死机, 死循环, 导致数据库数据丢失, 与数据库连接错误, 主要功能丧失, 基本模块缺失等问题
例如: 代码错误, 死循环, 数据库发生死锁, 重要的功能不能使用等
(一旦出现这种程度的BUG, 应立即中止当前版本的测试, 由测试人员打回给开发人员)

(2)Critical(严重)
系统主要功能部分丧失, 数据库保存调用错误, 用户数据丢失
功能设计与需求严重不符, 模块无法启动或调用, 程序重启, 自动退出, 关联程序间调用冲突, 安全问题, 稳定性等
例如: 软件中数据保存后数据库中显示错误, 用户所要求的功能缺失, 程序接口错误, 数值计算错误等

(3)Major(一般)
功能没有完全实现但是不影响正常的使用, 功能菜单存在缺陷但不会影响系统稳定性
例如: 操作时间长, 查询时间长, 格式错误, 删除按钮没有确认框等

(4)Minor(次要)
界面, 性能缺陷
不影响功能的执行, 可以优化性能的方案等
例如: 错别字, 界面格式不规范, 页面显示重叠, 提示语丢失, 文字排列不整齐等

🔎BUG 的生命周期

在这里插入图片描述

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