- 缺陷报告
- 标题:简要描述缺陷的现象
- 描述:缺陷的详细描述
- 重现步骤:分点描述重现缺陷的步骤,确保开发和其他人员能够参考步骤重现缺陷
- 测试版本:软件版本
- 环境:OS/浏览器
- 期待结果:根据需求规格说明,描述正确的操作状态
- 缺陷的其他属性
- 严重程度
- 优先级
- 状态(缺陷的生命周期)
- 修复影响范围(开发者)
严重程度是缺陷对软件功能影响程度强弱的定义。
状态 | 状态说明 | 例如 |
---|---|---|
Fatal | 致命的软件缺陷。事件非常重要, 测试工作无法继续进行,需要马上给予关注解决。 | A.由于程序所引起的死机,非法退出, 运行中断,应用程序崩溃。 B.死循环。 C.导致数据库发生死锁。 D.数据通讯错误。 E.严重的数值计算错误。 |
Critical | 严重错误的软件缺陷。事件是重要的,并且应该在紧急的事件处理之后尽快得到解决,但应在发布前解决。 | A.主要功能部分丧失。 B.缺少功能,与需求不符。 C.数据流错误。 D.程序接口错误。 E.轻微的数值计算错误。 |
Major | 一般错误的软件缺陷。事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决,如果时间紧可以留下个版本解决。 | A. 次要功能没有完全实现但不影响使用 B.界面文字等错误。 C.打印内容、格式错误。 D.简单的输入限制未放在前台进行控制。 E.删除操作未给出提示。 |
Minor | 较小错误的软件缺陷。不影响功能的正常使用,可以在时间和资源允许的情况下再解决。 | A.辅助性说明描述不清楚。 B.显示格式不规范。 C.长时间操作未给用户进度提示。 D.提示窗口文字未采用行业术语。 E.可输入区域和只读区域没有明显的区分标志。 F.系统处理未优化。 |
Enhancemental | 建议问题的软件缺陷。测试建议(非缺陷),可以在发布后再商量是否改进。 | A. 测试建议。 |
软件被修复的紧急程度。
状态 | 状态说明 | 例如 |
---|---|---|
Immediate | 马上解决 | 问题必须马上解决,否则系统根本无法达到预定的需求。 |
High | 高度重视 | 有时间就要马上解决,否则系统偏离需求较大或预定功能不能正常实现。 |
Normal | 正常处理 | 问题不影响需求的实现,但是影响其他使用方面,比如页面调用出错,调用了错误的等。 |
Low | 低优先级 | 问题在系统发布以前必须确认解决或确认可以不予解决。 |
状态 | 状态说明 | 操作人员 |
---|---|---|
New | 首次录入。 | 测试人员 |
Open | 已经确认是缺陷,并等待修改。 | 开发经理/项目经理 |
Fixed | 修改完成后待回归测试验证。 | 开发经理/开发人员 |
Resolved | 回归测试验证通过。 | 测试人员 |
Reopen | 回归测试验证不通过,再次等待修改。 | 测试人员 |
Closed | 回归测试验证通过,且无需再跟踪。 | 测试人员 |
Rejected | 讨论后认为不是缺陷或拒绝修改。 | 开发经理/开发人员 |
Delayed | 延迟修改。 | 开发经理/开发人员/缺陷评审委员会 |
缺陷分析的过程,是对迭代过程复盘、缺陷根因分析的过程。通过缺陷分析,能够对迭代提供提升质量的方法和依据。
- 从缺陷本身产生的原因分析。
- 需求引入缺陷(需求有歧义、需求没有定义清楚等)
- 设计引入缺陷(设计阶段结构未考虑全面、接口数据库设计不合理等)
- 代码缺陷(未Review代码,开发人员未理解需求)
- reopen缺陷
- 从缺陷分布特点分析,能够对软件版本的质量有所评估。
测试前,不仅要了解产品需求,也要了解需求产生的背景及原因,从而知晓需求的来龙去脉。这样有助于更好的理解需求,也能针对业务场景的各种情况,设计出更合理和完善的测试方案。
业务出发,分析需求,注重用户场景
- 分析业务,对当前需求和产品有初步了解:
- 了解业务针对人群
- 了解业务根本出发点(核心、目的)
结构化思维,使用在测试过程中面对的各种类型的测试内容。比如需要从一个需求点衍生出测试点、测试用例等;有比如需要统计分析众多的缺陷,从而找到问题发生的根源,以便提升产品质量。推荐下面的文章,从2个角度来理解结构化。
- 问题型问题:先结构化,再抽丝剥茧,从结构自上而下,通过归类、拆解,形成一个有条理的树形结构然后逐个解决。
- 信息型问题:与问题型问题相反,信息型问题是一个自下向上的过程,这种思考过程是:信息罗列、信息归纳,得到规律,是一个不断收拢的过程。
测试的目的是要确保软件质量,测试也是不断推进团队提升质量的过程。
针对不同的测试对象,会进行不同类别的测试工作。测试类别其实与测试阶段和测试目的息息相关,不同的阶段和目的对应的测试类别和测试方法也不尽相同。
功能测试阶段,要测试软件的每一个功能是否已满足需求规格说明书规定的内容。
- 测试设计方法
功能测试,往往从需求分析理解入手,再进行用例设计。不同的功能运用不同的设计方式,能够有效的提高测试用例覆盖率,达到不遗漏需求点的目的。
- 等价类划分
- 边界值
- 异常类
- 因果图
- 正交表
- 缺陷
- 缺陷提交 测试人员将测试过程中发现的软件缺陷以书面方式提交给开发人员。有关缺陷报告如何书写,请参考上半部的测试规范相关内容。
- 缺陷分析 根据缺陷分析结果,有助于评估版本质量,根据当前质量确定测试策略的合理性。
性能测试通常是指测试软件在一定条件下处理事件的能力/效率。
- 测试指标 首先也是最重要的,要根据业务需求、用户场景等因素,确定出系统的性能指标。
- 性能测试分类
不同的测试目的,会做不同类型的测试,以下几种性能测试的区别可以通过下图看出。
- 性能测试
- 负载测试
- 压力测试
- 稳定性测试
兼容性测试主要用来测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。
机型的选择&测试内容
- 适配机型的选择 首先要定义软件的目标市场,确定当前软件支持的机型和系统版本、系统分辨率。比如,优先支持ios10以上的版本以及所有苹果机型;Android系统支持7以上的版本,且支持市场占有率top100的机型。
- 浏览器的选择 针对一些WEB程序,其需要依赖浏览器使用,不同浏览器表现也不尽相同。这也意味着在兼容性测试上,需要考量浏览器维度。
- 兼容性测试内容的评估 一般的兼容性测试主要关注模块UI层面的兼容,还有主要功能上的兼容性。
自动化测试需要依赖各种测试框架,结合代码编写,搭建适合产品的自动化测试平台。
从当前市面上的平台查找,只找到了网易的Airtest 平台支持测试Unity 游戏。其使用的是Poco UI自动化框架框架,能够识别unity的元素(按钮等)。
使用总结
- 搭建一整套环境后(ios),发现airtest的稳定性不好,较频繁的出现重连设备的问题,在自动化测试中,反应时间也过慢。导致其测试效率和成本并没有因为自动化平台的使用而改善。因此暂时不再使用此平台进行测试调试。
要素
- 目的
- 需求范围
- 测试对象
- 分析测试对象,有助于测试策略的制定。比如从功能角度看,有新增需求、影响的已有功能等。从性能角度看,何种业务场景下,达到何种性能指标。
- 测试策略
- 测试策略是指,在测试前期分析测试对象,针对其特点,确定合理的测试方法、测试轮次等信息。一旦测试策略确定
- 测试方法
根据不同的测试对象和测试阶段,可选用不同的测试方法。细分测试对象,使用不同的测试方法,可以提升测试覆盖率。
- 冒烟测试
- 功能测试
- 回归测试
- 探索性测试
- 性能测试
- 兼容性测试
测试设计是在测试框架里不可不提的内容。它是推进功能测试很重要的工具,并且系统化了待测试需求,用测试语言罗列了待测试的内容,即每一条Testcase。在这里仅做了非常简单的介绍。具体的测试用例设计方法,还需要通过网络或实践来了解并熟悉。
(包括但不限于)
- 等价类划分
- 边界值
- 异常类
- 因果图
- 正交表
- PICT 组合测试用例工具
- All Pair 配对测试工具
迭代、版本、发布、测试左移、质量控制等等
- 测试范围
- 测试内容(测试阶段、轮次以及测试方法)
- 缺陷分布(模块分布、版本分布、类型分布)
- 缺陷reopen情况
- 缺陷修复情况(收敛趋势)
- 遗留的原因和背景
- 遗留缺陷的解决方案
- 需求分析、需求评审、需求描述等过程的优化或改进
- postman 接口测试工具 向服务器发送GET\POST等 命令,测试http接口
- Loadrunner 性能测试 特点:支持各种协议,主要是性能测试(负载、压力),支持多并发,并且有图形化的统计分析功能
- Jmeter 性能测试 接口测试
- fiddler 抓包工具 特点:手机与电脑同一局域网,手机设置网络代理为电脑IP,电脑运行fiddler后,可以获取到手机http协议的访问包 限制:app不支持通过代理上网的话,就无法
- Badboy 脚本录制工具,可以录制web协议请求
- adb Android 系统的工具,部分功能需要手机的ROOT权限 adb命令可以连接手机,并对手机进行一系列命令操作 adb bugreport,获取手机的电池电量等信息文件
- Battery Historian 分析Android 手机bugreport的工具,图形化 能看到battery、camera、wifi、温度、电量等使用情况
- Chkbugreport 分析Android的bugreport.txt文件
- GT 监控ios Android的CPU、MEM等使用率