【软件测试】软件测试基础2

最新推荐文章于 2024-07-19 23:01:23 发布

小轩在不在哟

最新推荐文章于 2024-07-19 23:01:23 发布

阅读量979

点赞数

分类专栏：软件测试文章标签：单元测试测试用例

本文链接：https://blog.csdn.net/xqs196301/article/details/128687919

版权

软件测试专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1. 软件测试的生命周期

软件测试的生命周期：需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
● 需求分析：站在用户的角度：查看需求逻辑是否正确，是否符合用户的需求和行为习惯；站在开发人员的角度：思考需求是否可以实现，或者实现起来难度大小
● 测试计划：指定测试计划（包括但不限于测试的工时，人力的安排…）
● 测试设计：设计测试用例；测试开发：经验丰富的白盒测试人员可以开始单元测试
● 测试执行：参考测试用例来执行测试
● 测试评估：回顾项目，再次确定软件中可能存在的缺陷…

软件测试贯穿于软件的整个生命周期
软件的生命周期（软件测试怎么贯穿）：
● 需求分析：测试也要对需求进行分析，分析需求逻辑是否合理，是否符合用户的行为习惯，站在开发人员的角度思考技术实现的难度，针对技术难度来合理调整需求
● 计划：根据需求编写测试计划/测试方案
● 设计：测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计；编写一部分测试用例
● 编码：测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案
● 测试：测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
● 运行维护:测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人（测试往往是最了解需求的人，测试人员通常来进行产品的演示和功能的介绍，期间记录下来大家的反馈记录，反馈给产品经理，成为一个新的用户需求）

2. 如何描述一个bug

提bug方法：
标题：（谷歌浏览器打开首页之后，第一个banner页上面的二维码被登录注册控件遮蔽住，导致无法扫描）

发现bug的版本，环境（Chrome版本+win10）
发现bug的步骤（让开发人员能够复现bug）：
● 打开Chrome浏览器，访问XX链接：http://…
● 期望的结果：XXXXX
● 实际的结果：XXXXX
其他：（bug类型：前端问题，bug等级：次要…）

bug描述应当具备的内容：标题，版本，环境，步骤，期望的结果，实际的结果，其他…

不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

案例：
在这里插入图片描述

3. 定义bug的级别

实际工作中需要提前看一下企业对应的bug定级标准文档，这里学习仅供参考，是一种基本模板
● 崩溃：基本见不到
● 严重：也比较少
● 一般：居多
● 次要：居多

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

4. bug的生命周期

测试人员创建完bug之后，开发人员要修复bug，测试人员还需要进行bug回归验证！！！

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态

BUG状态转换图：
在这里插入图片描述
New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。（bug终态）
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed