(1)性能
性能测试,首先需要有具体的、明确的性能指标需求。
性能关注指标:CPU、Memory、IO、网络传输速率等。
a.单品(模块)性能,比如SDK、算法、单独性能要求
b.整体性能,系统集成后的性能要求
c.网络传输性能
(2)可靠(稳定)性
a.时间维度
b.负载稳定性
(3)健壮性
a.看门狗
b.异常掉电
c.反复重启
(4)易用性
a.安装易用性
b.运维易用性
c.功能操作易用性
(5)客户体验
比如视频播放效果、操作是否顺手、开机时间等等。
(6)安全性
a.数据存储安全
b.网络传输安全
2、测试用例编写
2.1、测试用例编写前提
1、测试范围已经确定
2、测试点已经梳理完成
3、用例转换路径:业务需求-功能需求-测试需求-测试点-测试用例
2.2、用例标题
概述测试用例的主要内容,明确用例测试意图
1、语言简洁,阐明本条用例是干什么
2、一句完整的话
3、遵循“条件/动作"规则
2.3、用例级别分布
1、Lve 1:基本(~10%)
系统基本功能用例,可用于版本提交时的冒烟测试,可作为版本是否转测试通过和业务验收的依据。
划分依据:该用例执行的失败会导致多处重要功能无法运行的。
例如:开关机、升级等。
2、Lve 2:重要(~20%)
系统中的重要功能用例。
划分依据:主要包括一些功能交互相关、各种应用场景、客户使用频率较高的正常功能测试用例。
例如:设备上报、录像回放效果、预览等功能。
3、Lve 3:一般(~60%)
系统的一般功能。
划分依据:一般功能用例,包括异常路径的测试用例;使用频率低于2级用例。
例如:表单输入边界值、特殊字符的校验等。
4、Lve 4:生僻(~10%)
该级别用例一般比较少。主要是一些使用频率非常少的功能等。如果用例执行不通过,不会对系统和业务造成太大的伤害的测试用例。
划分依据:该用例对应较生僻的预置条件和数据设置。
例如:日志记录错误等。
2.4、预置条件
1、执行测试用例关键必备条件
2、让用例的执行者更加明确系统当前状态
3、预置条件不能阻塞测试用例的执行
2.5、操作步骤
1、需要明确“测试关键输入”数据
2、操作路径唯一,不唯一则多条用例覆盖(降低耦合)
3、以“面向过程”的形式编写
(1)过程描述准确、无歧义。
(2)上下文必须衔接一致。
好处:降低执行成本、降低后续维护成本
2.6、预期结果
1、每一步操作都有对应的预期结果
2、预期结果一定是客观的、可判定的
(1)即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。
(2)期望结果禁止使用正确,正常,错误之类的含糊主观的字眼。
3、预期结果一定是符合需求的
4、预期结果一定是确定的
即对同样的测试用例,系统的执行结果应当是相同的、确定的。
3、测试用例评审
3.1、评审前
1、让评审对象提前熟悉测试用例
2、反串讲需求
3、阐明最终测试范围
3.2、评审中
1、测试
(1)测试用例讲解。
(2)再一次对需求做深入理解。
2、开发
(1)站在开发编码角度,检查测试用例是否有遗漏。
(2)站在代码实现的角度,提供模块内部关联逻辑建议。
3、产品经理
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
漏。
(2)站在代码实现的角度,提供模块内部关联逻辑建议。
3、产品经理
[外链图片转存中…(img-YF21OHXP-1719259326543)]
[外链图片转存中…(img-QcHoWNou-1719259326545)]
[外链图片转存中…(img-lTyj1Bc2-1719259326546)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!