🔎软件测试的生命周期
软件的生命周期
某一软件从被提出并着手实现开始直到软件停止使用为止的时间
具体可分为(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，开发人员重新修改。
🔎测试的执行与管理
测试的执行与管理
测试人员发现BUG 后, 将BUG 提交到公司的系统中
开发人员将存放在系统中的BUG 进行修改
开发人员将修改好的BUG提交到公司的系统中
测试人员将存放在系统中的修改好的BUG 进行测试
如何发现更多的BUG
(1)软件测试存在二八原则, 80%的故障集中在20%的模块中, 如果某部分问题较多, 加强对该部分测试的深度和广度
(2)开发人员存在二八原则, 80%的故障集中在20%的开发人员, 如果某些开发人员的BUG 较多, 加强对他开发模块的测试深度和广度
(3)多进行逆向思维和发散性的思维
(这点比较依赖测试人员的经验)
(4)不要局限于用例和需求文档
(5)尽早介入项目, 不要等到开发的差不多了再介入项目
🔎产生争执怎么办
作为一名测试人员, 一般会遇到以下几种情况
- 这不是BUG
- 这个BUG 的级别太高了
- BUG影响不大, 暂不修改
处理方法🥝
前提: 一定不要吵架
(1)先检查自身, 是否bug描述不清楚
(2)站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰, 这样才能促使开发人员更加积极地、高质量地修改Bug. 在争执时, 可以问一句：如果你是用户, 你可以接受么？
(3)BUG定级要有理有据
(4)不光要发现问题, 还要对问题提出相应的解决方案
🔎结尾
创作不易,如果对您有帮助,希望您能点个免费的赞👍
大家有什么不太理解的，可以私信或者评论区留言，一起加油
