软件测试的生命周期

软件测试的生命周期：需求分析→测试计划→测试设计、软件开发→测试执行→测试评估

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

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

测试用例设计

基本测试点：
（1）零钱支付功能（零钱充足时）
（2）零钱不足时，支付
（3）支付的钱数为为整数，小数
（4）首次使用微信零钱功能（必须要绑定银行卡）
（5）没有钱时支付
（6）扫微信收款码付款
（7）扫非微信付款二维码支付
（8）零钱支付上限（有上限）
（9）零钱可支付的最小金额（下线）
（10)收到转账或者红包零钱金额是否正确
（11）每次消费零钱，都有消息提醒
（12）可以将零钱提取到银行卡（收手续费，到账时间）
（13）可以向微信零钱充钱（从银行卡）
兼容性：
（1）测试不同的微信版本
（2）测试不同的手机系统（iOS，Android，包括不同安卓机不同品牌的机型）
性能：
支付零钱，给零钱充值，提取零钱的速度（单条，全部，清空）

如何描述一个bug

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

如何创建一个Bug

创建 Bug 的要素：问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等

案例

标题：二维码被登录模块遮挡，导致二维码描述登录失败
问题出现的版本：Microsoft Edge 版本
问题出现的环境：windows 11
问题出现的步骤：
1.打开浏览器，输入网址
2.页面渲染完成，结果与预期不符
预期结果：二维码不会遮挡登录模块
实际结果：二维码遮挡登录模块
Bug归属：前端问题

Bug的级别

Blocker（崩溃）

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
Critical（严重）

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

Major（一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

Minor（次要）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

Bug的生命周期

测试人员在执行测试的过程中，如有发现 Bug，需要在对应的 Bug 管理平台来创建 Bug

New：测试人员创建了一个 Bug
Open：开发人员要去确认是否是 Bug，是 Bug 状态就改为 Open，不是 Bug 就拒绝（rejected）
Fixed：开发人员在修复完成之后将 Bug 状态改为 fixed
Rejected：如果认为不是 Bug，则拒绝修改
Delay：确认是 Bug 之后，如果 Bug 优先级比较低且开发人员不能立即修复 Bug，状态改为 delay
Closed：Bug 确认修复完成，测试人员将 Bug 改为 closed
Reopen：Bug 确认修复未完成，测试人员将 Bug 状态改为 Reopen
测试人员和开发人员产生争执了怎么办？
多反思自己，是不是 Bug 创建的时候描述不太清楚
开发人员对 Bug 级别不认可，Bug 定级一定要有理有据，测试人员需要明确企业 Bug 定级规范，拿着规范和开发人员沟通，为什么这样定级
合理友好的进行沟通，站在用户的角度反问，如果你是用户，你能接受这样的功能吗，提 Bug 必定会增加开发人员的工作量，小问题不想解决
不仅能够发现问题，最好也能够提出解决方案给开发参考
如果确实是 Bug，友好沟通已经不能解决问题了，那就召开 Bug 评审，需要有相关的代表来参加：产品代表、开发代表、测试代表等（1. 如何解决 Bug 2. 如何预防类似的 Bug 再发生）