一、测试用例设计:
从用户使用角度出发、基于产品需求文档、了解详细功能策略及业务流程。
1、按照用例设计维度:
功能测试:数据校验、业务场景(正向场景)
功能有没有,好不好用,特殊情况处理
易用性:安装易用性、维护易用性、操作易用性、客户体验
兼容性:能够兼容不同的软硬件平台
浏览器类型及版本:Safari、Chrome、IE、Firefox
操作系统
PC: Windows/Linux/Unix/MacOS
移动端:iOS& Android(华为、小米、OPPO、三星)
终端设备、不同分辨率/屏幕尺寸、语言环境、网络环境(移动、联调、电信/2G/3G/4G/5G/WIFI)
可维护性:对于后期的修复维护是否方便快捷,例如:日志
可移植性:能否在不同环境条件下无故障运行
性能测试:需要有具体的、明确的性能指标需求
压力、负载、可靠性(不易出问题,万一出问题容易恢复)、稳定性
模块性能、整体性能、网络传输性能、对应系统的资源耗费程度及响应时间
安全性:对于用户的安全保障(外在的人生安全、内在的信息安全等)例如:数据存储、网络传输
组合测试:
异常场景(逆向场景):异常掉电、反复重启、弱网、中断、异常输入等
2、按照用例设计方法:
等价类、边界值、错误推导、因果图等
二、测试用例编写:
1、测试范围已经确定
2、测试点已经梳理完成
3、用例转换路径:业务需求-功能需求-测试需求-测试点-测试用例
1、按照用例设计规范:
标题--概述测试用例的主要内容,明确用例测试意图
要求:阐明本条用例是干什么、一句完整的话、遵循“条件/动作"规则
预置条件--执行测试用例关键必备条件、明确系统当前状态
操作步骤--粒度控制在4-6步、数据明确、操作过程准确完整无歧义
预期结果--每一步操作都有对应的预期结果、客观可判定(禁止使用“正常”等主观字眼)、符合需求且确定的
优先级--(不同行业及产品优先级划分标准不同,此处以博主前公司产品为例进行划分)
1/1---约10%,系统基本及主要功能用例,可用于冒烟测试。
划分依据:该用例执行的失败会导致多处重要功能无法运行。
1/2---约20%,系统中的重要功能用例。
划分依据:主要包括一些功能交互相关、各种应用场景、客户使用频率较高的正常功能测试用例。
1/3---约50%,系统的一般功能。
划分依据:一般功能用例,包括异常路径的测试用例;使用频率低于2级用例。
1/4---约10%,主要是一些使用频率非常少的功能等。如果用例执行不通过,不会对系统和业务造成太大的伤害的测试用例。
1/5---约10%,该级别用例一般比较少。对应较生僻的预置条件和数据设置。
其他:测试人员、测试结果、编写人员、备注
2、按照用例设计原则:
1、“边界值””等价类划分场景“全覆盖原则
2、一条用例仅覆盖一个测试点。“单条用例覆盖最小化”可降低漏测风险,当用例执行失败时,也可降低复现/定位复杂度
3、“测试用例与测试用例之间最低耦合度”,便于测试用例拉取、复用、可维护、减少后续投入成本。
三、测试用例完成后--评审:
评审前:串讲需求(开工会材料,明确需求详情(背景及实现)、测试范围及通过标准)
评审中:同行评审、通用评审(电子流)
1、测试
(1)测试用例讲解。
(2)再一次对需求做深入理解。
2、开发
(1)站在开发编码角度,检查测试用例是否有遗漏。
(2)站在代码实现的角度,提供模块内部关联逻辑建议。
3、产品经理
(1)检查测试用例场景是否符合业务需求。
(2)站在客户角度给测试用例提供建议。
评审后---根据评审建议更新测试用例
四、测试用例完成后--刷新:
网上问题分析增加测试点
新员工拓展测试
版本测试过程中发现遗漏
学习参考途径如下:
原文链接:https://blog.csdn.net/Blllllll_/article/details/109646142
原文链接:https://www.zhihu.com/question/51558124/answer/1494934653