基础知识掌握 推荐大家阅读 《软件测试 第二版》 另欢迎大家纠错
此篇主要梳理如下几个方面:
测试流程 、测试用例 、测试计划、测试报告、bug生命周期、bug管理工具
1. 测试流程
因公司而易 ,我们公司不是纯软 有硬件所以简单的描述一下我们公司的流程
如果是原型机阶段到小批量阶段,会根据立项中需求规格说明书做需求分析, 编写测试用例,测试组长编写测试计划,用例编写完成先组内审核,最后项目组评审测试用例,硬件组和软件组 研发完毕后测试介入,根据阶段不同分工测试,执行过程中将发现的问题提交到mints,最要的问题提交到mints并口头告知开发人员,提交测试报告时注明严重问题下个版本需改正,直至缺陷管理平台 缺陷率达到结项标准,发布发版报告 , 出货后续关注客户反馈意见
如果是产品稳定阶段 我们会根据项目经理发送邮件中的需求说明书,编写测试测试用例,我们三个+项目经理 审核测试用例看看大家是否有意见,通过后提交到银行订制项的测试用例,发布版本后搭建测试环境,执行测试用例 最后汇报结果即可
2. 测试用例
测试用例包含哪些内容?
常用的设计测试用例有哪些?
等价类、边界值、错误推测法、因果图、场景法等
如何应用到项目中?
等价类: 是将所有可能输入的数据划分为若干个子集，在每个子集中如果任意输入一个数据对于揭漏程序中潜在的错误都有一样的效果，那么这样的子集就构成了一个等价类 ,选择代表性的子集测试即可
边界值: 边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001.....等等，来判定是否超出了我们的范围。
错误推测法: 基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。
因果图: 因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。
3. 测试计划
测试计划包含哪些方面?
工作中测试计划都是领导在编写,知道包含的内容如下:
背景
测试目标
测试范围
测试方式
进度安排
测试人员安排
测试环境
风险评估
4. 测试报告
测试报告包含哪些内容? 测试报告的重点是什么?
这里指的是版本测试报告 发送邮件时 描述清楚版本号 简单明了 ,通俗易懂
- 此版本测试用例执行情况,通过多少条、失败多少条
- changeLog测试情况
- bug库中剩余bug数量 新增bug
- 将非常严重的缺陷列在最前边 且标红 @开发以及他的领导人员影响到下个版本测试必须修复
5. bug生命周期
提交缺陷 -- 分配缺陷个开发人员-- 开发人员确认/返回 缺陷 -- 处理缺陷 -- 回归缺陷 -- 关闭缺陷 -- 若再次复现 -- 重现打开重复以上
6. bug管理工具
bug记录包含哪些内容?
所属模块
所属版本
bug标题
步骤 / 测试数据
严重等级
指派人
预期结果
实际结果
如何判断bug的优先级?
- 1级 必须优先改 需要马上解决
导致崩溃 、死机的问题
安全性问题涉及金钱类 支付计算错误等 - 2级 严重错误 急需解决
未实现需求规格说明中的需求
主功能部分丧失
系统的次要功能完全丧失
数据不能保存
非 常规 操作导致的死机 崩溃现象
密码明文显示
界面画质非常差 - 3级一般错误 正常处理
次要功能没有完全实现，但是不影响用户使用 例如提示信息不准确，操作后反应时间过长 - 4级
界面问题 错别字、洁面不整齐
你提交了一个bug开发不认为怎么办?
这个问题几乎我们都碰见过 ,放平心态我们的职责就是发现问题的
首先先问清楚 不认可的理由是什么?找出需求文档看看大家的理解是否有偏差 / 没有需求文档对应 从客户的角度出发 讲述这个问题的重要性,如果还未达成一致 找上级领导确认问题
复现率不高的bug怎么处理?
- 一定要提bug，并且要在bug单中说明复现的概率 详细记录当时的环境细节 并保留截图、日志
- 尽量多尝试可能出现的步骤。排除环境和自己电脑配置的原因,
- 在接下来的测试中 重视这个问题 每个版本多复现几次
- 跟踪4个版本仍然未复现 ,暂时关闭bug,并写上备注 跟踪 xxx 几个版本后未复现 暂时关闭
怎么去定位bug? 如何知道是前端还是后段bug?
利用抓包工具抓包
前端从 URL地址是否正确 传参 数据是否正确 这两个方面判断
后端的话从响应数据 判断