用例分析模板

类型	场景
功能	正常场景，异常场景
UI
资损
性能
安全
兼容性
稳定性	监控，应急预案，灰度

测试用例场景设计

页面

功能点	场景
控件检查	按钮检查：跳转，权限，跳转信息 链接检查：链接跳转，后退，窗口重新打开，链接拼接，权限 输入框检查：字符限制，长度限制，前后空格，特殊字符，敏感词，xss脚本，多个tab页公用输入框检查管理影响 对话框检查：页面检查，文字提示，对话框重新载入 下拉框检查：所选和传入后端枚举值匹配
页面检查	元素布局 页面数据正确性 页面异常显示 页面权限检验
表单提交	页面初始检查 表单提交成功 表单提交-分支提交 表单提交-异常提交 表单提交-正常字段校验 表单提交-异常字段校验
查询类	页面初始检查 单条件查询 组合条件查询 查询结果排序 查询结果分页
数据正确性	前后端交互数据流转，入参出参 正确或失败返回后页面展示
性能测试	大数据量的查询 大数据量的导入导出 高并发 页面响应时间
安全测试	xss、csrf、越权、敏感数据、sql注入
兼容性测试	主流浏览器兼容性 操作系统兼容性 多语言支持

接口

功能点	场景
参数校验	必填项校验 类型校验 长度校验 取值范围校验 枚举值遍历
参数组合	必填组合 非必填组合
响应结果	返回值：正确返回，错误返回，返回的数据结构正确性，接收返回信息的系统能否正确解析 错误码：覆盖所有错误码的枚举
全链路	接口有对应页面：需要在页面上回归一遍流程 接口有上游调用方：需要从真正的调用方走一遍链路

业务通用

功能点	场景
业务功能	主干流程 正常分支流程 异常分支流程
全链路	从真实场景出发，结合上下游走主流程
资损	具体按照对应业务域资损场景进行评估
性能测试	并发 RT 响应时间，通常指请求+响应 <200ms CPU利用率 ≤ 75% 内存利用率 ≤ 80% 磁盘利用率 ≤ 80%
稳定性测试	监控 预案 灰度 弱依赖降级
安全测试	越权 敏感数据 SQL注入等
兼容性测试	新老代码兼容 新老数据兼容 刷数据等等

消息型

功能点	场景
参数校验	消息体入参出参 枚举值遍历
业务功能	正常场景：消息是否发送成功，下游是否消费成功 异常场景
消息乱序	对时序性高的业务，需要从业务层做消息乱序处理
消息重试	消息失败后重试
重复消费/幂等
稳定性测试	限流熔断：一般消息都有通用的熔断限流机制 监控
兼容性测试	新老消息体的消费兼容

缓存型

功能点	场景
通用	读缓存 写缓存 删除缓存 缓存自动过期 缓存更新 缓存空值 缓存一致性等等
高可用	缓存击穿 缓存穿透 缓存血崩 热点

客户端

功能点	场景
通用	安装 卸载 更新：跨版本、升级、降级：覆盖安装后用户数据正常保存 启动与停止：启动时间、启动页面、停止进程、重启后登录态获取 交互：滑动、点击、双击、长按、拖拽（不同方向、不同位置） 中断：关机、断网、来电、前后台切换
UI	页面展示：加载成功、加载失败、加载中 页面元素控件：按钮、日期、下拉框、选择框、输入框、…… 长文本信息 密文 链接、图片、视频 进度条、滚动条 弹窗提示
功能	正常功能 异常功能 等价类、边界值
接口	合法值 非法值
兼容性测试	不同机型 不用系统版本 不同屏幕尺寸 多语言 横竖屏 日夜模式
性能	CPU 内存 流量 耗电量 断电 断网 弱网 低电量 负载、压测、响应时间
安全测试	xss、csrf、越权、敏感数据、sql注入
权限	启动app时会弹出权限提示设置权限 已授权状态 未授权状态

测试用例内容

编号、模块、子模块、用例标题、前置条件、操作步骤、预期结果、测试阶段

编写测试用例的目的

① 防止测试遗漏
② 记录测试记录
③ 规范测试流程
④ 提前准备测试数据

软件测试用例设计方法

在测试用例的设计之前首先要仔细阅读开发的详细设计文档，充分了解产品的详细功能，不清的地方与开发人员进行沟通，搞懂每个功能，尽量详细到输入框、按钮等小功能，功能点清楚之后按照功能模块分类进行用例编写。在具体的用例设计中会运用到等价类 边界值等黑盒测试方法。

① 等价类
② 边界值
③ 因果图
④ 错误分析法
⑤ 场景法
⑥ 流程分析法
⑦ 正交实验法
⑧ 状态迁移法

例1：等价类：

QQ账号： 6—10位自然数

有效等价类：
1.6-10位的自然数
2.6位的自然数
3.10位的自然数

无效等价类：
4.小于6位的自然数
5.大于10位的自然数
6.字母
7.特殊符号
8.汉字
9.空格
10.小数
11.负数

例2：边界值：

数字范围（每个范围内都要测试到，随机取一个数）

——————————10————————15——————>

例3：因果图：

“有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。”试利用因果图法，建立该软件的因果图。

原因：① 投入1元5角硬币； ② 投入2元硬币；③ 按“可乐”按钮； ④ 按“雪碧” 按钮； ⑤ 按“红茶”按钮。　　
中间状态：① 已投币； ② 已按钮。　　
结果：① 退还5角硬币； ② 送出“可乐”饮料；③ 送出“雪碧”饮料； ④ 送出“红 茶”饮料。

硬件测试的方法

① 界面测试
② 性能测试（压力测试 稳定性测试）
③ 恢复性测试
④ 兼容性测试
⑤ 安全性测试
⑥ 破坏性测试
⑦ 可用性测试
⑧ 易用性测试（是否适用于不同人群）
⑨ 功能操作的测试

软件测试要从哪些方面去考虑测试点？

写测试用例的时候，不能想到什么就写什么，要按照一定的测试用例模板去写，要有自己的思路，不能完全去套用模拟以前的测试用例，按照一整套的测试流程来分析重要的关注点，时间长也会有自己积累的一套的测试模式，按照框架的思路，可能会达到事半功倍的效果

功能测试框架一般情况就是包含以下几类：界面友好性测试、功能测试、页面链接测试、容错测试、稳定性测试、性能测试（简单方面）等等。

1 界面友好性测试

风格、样式的协调性是否合理
　　界面布局是否整齐，尽量不要使用滚动条
　　界面操作、标题描述要恰当
　　操作符合大众的常规习惯
　　提示界面符合规范（不要出现中英混写）
　　界面中各个控件是否整齐美观
　　日期控件是否可正常编辑、长度是否合理，保证修改时可以把时间全部显示
　　查询结果列表列宽是否合理、标签描述是否合理、太宽需要有横向滚动提示
　　对于信息比较长的文本，文本框需提供自动竖直滚动条
　　支持Tab键，使用时不会出现乱跳情况
　　有没有提供相关的热键
　　控件的提示语描述是否正确
　　模块调用是否统一，相同的模块是否调用同一个界面
　　用滚动条移动页面时，页面的控件是否显示正常
　　时期的显示格式是否正确
　　页面是否有多余无用的按钮或标签
　　窗口标题或图标要菜单栏统一，且最大化最小化操作是否正常
　　对于正常的功能，操作简单明了
　　执行风险操作时，要有相关的提示
　　正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
　　系统应该在用户执行错误的操作之前提出警告，提示信息.
　　页面分辨率检查，不同的分辨率浏览是否会出现乱码等不友好的界面出现
　　合理性检查：做delete, update, add, cancel, back等操作后，查看返回的页面是否合理。

2 功能测试

先使用系统给出的默认值测试
　　遍历测试系统流程，参照相关文档资料
　　查看系统的流程逻辑是否合理
　　异常场景的分支遍历测试
　　根据需求文档的流程图遍历所有流程图路径
　　界面中的控件进行测试
　　如对于输入框测试：
　　一、字符型输入框：
　　字符型输入框：英文全角、英文半角、数字、空格、特殊字符“~！@#￥%……&？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。
　　长度检查：边界值测试，无效等价类的测试，已经复制比较多的文本是否能够粘贴进去。
　　空格检查：字符间有空格、空格在前或在后、前后都有空格
　　多行文本框输入：允许回车换行、仅输入回车换行，检查能否正确保存
　　安全性检查：输入特殊字符串：比如HTML格式的语言
　　二、数值型输入框：
　　边界值：最大值、最小值、最大值+1、最小值-1
　　位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数
　　3.异常值、特殊字符：输入空白（NULL）、空格或"~!@#$%^&()_+{}|[]:"<>?;‘,./?;:’-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、
　　输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）、
　　安全性检查：黏贴不能输入的内容检查
　　三、日期型输入框：
　　合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]
　　考虑开始日期与结束日历的比较，特别是在查询的时候.
　　异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符
　　安全性检查：黏贴不能输入的内容检查

3 业务流程测试(主要功能测试)

业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。
　　如某一功能模块具有最基本的增删改查功能，则需要进行以下测试：
　　单项功能测试（增加、修改、查询、删除）
　　增加——>增加——>增加 （连续增加测试）
　　增加——>删除
　　增加——>删除——>增加 （新增加的内容与删除内容一致）
　　增加——>修改——>删除
　　修改——>修改——>修改 （连续修改测试）
　　修改——>增加（新增加的内容与修改前内容一致）
　　修改——>删除
　　修改——>删除——>增加 （新增加的内容与删除内容一致）
　　删除——>删除——>删除 （连续删除测试）

4 链接测试

主要保证链接的可用性和正确性。

5 容错测试

输入不符合规则的数据检查
　　停止某模块，检查对当前系统的影响
　　配置出现错误和删除配置文件检查
　　数据库错误注入

6 稳定性测试

系统7*24不间断运行，检查是否会出现内存泄露、系统其他资源是否存在泄露
　　一般压力很大的情况下，数据库连接数问题、内存泄露问题会曝露的比较快但是死锁可能不能体现。

7 常规性能测试

连接速度测试
　　如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
　　负载测试
　　测量Web系统在某负载级别上的性能，以保证Web系统在需求范围内能正常工作。可以是某个时刻同时访问的用户数量，也可以是在线数据处理的数量。例如：最多支持多少用户同时在线？如果超出，系统会怎么样？
　　压力测试
　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。只有放在Internet上负载测试，其结果才是正确可信的。
　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
　　压力测试包括表单、登陆和其他信息传输页面等

8 易用性测试

系统界面的控件是否可以通过tab键遍历，并且顺序合理
　　主要功能的入口和操作是否易于理解
　　界面是否布局合理，功能是否易于查找和使用
　　操作步骤和习惯是否符合逻辑
　　有足够的提示信息，且信息文字描述准确

9 兼容性测试

兼容性测试不只是指不同操作系统或浏览器下的兼容，
有些功能实现也会因为兼容性问题出现故障，这功能测试要考虑到兼容性问题

测试用例设计的点与思路

1、ui

关注：页面元素、元素位置
把每一个页面当做一张图片，关注页面元素的位置，元素的层级，页面整体的组合，元素（如，icon的样式、种类，文案的字数、内容，图片的大小等），还有一些特殊状态（如夜间状态还有未加载成功时的兜底状态以及默认图）

2、功能

关注：边界值、等价类
根据需求文档确定功能的范围，以及无明确要求但行业确定的，用户操作的需求（从用户（非专业）的角度功能是否有效以及是否好操作）

3、交互

关注：滑动、点击、双击、交互组合
页面上下、左右、或上左角度的滑动，单次和多次点击页面元素、元素边缘、页面边缘，页面点击后再次点击，页面滑动后再次点击

4、接口

关注：合法值、非法值
接口的存在和接口值得合法与非法

5、判断

关注：判断的真与假
在判断为真时的代码逻辑，功能交互
在判断为假时的代码逻辑，功能交互
还需要关注是否有代码没有覆盖的逻辑

6、打点

打点需要提供打点文档，确定哪些打点应该存在，哪些打点不该存在，打点的值应该是什么

7、网络

关注：4g、5g、wifi、弱网
不同网络下的交互与性能

8、数据

关注：数据的显示、数据的安全、数据的边界值、还有内存的情况
查看数据是否有空白和乱码的情况，以及在多条数据请求时的展示

9、兼容

关注：不同的系统（安卓、ios、重点关注基于安卓开发的系统如小米的miui）
不同的系统版本、不同的机型、不同的屏幕比和屏幕大小

设计APP测试用例需要考虑哪些维度？

一、APP的安装与升级

1）升级中用户数据、设置、状态是否正常保留
2）是否支持低版本、高版本的覆盖安装。覆盖安装后用户数据正常保存
3）测试升级安装，升级安装后用户数据正常
4）需考虑灰度升级的问题，提示是否友好，可以X掉
5）强升是否正常，不升级app无法使用

二、APP的启动与停止

1）首次启动app正常进入loading页，loading页展示的时间、页面都正常
2）启动时间符合需求
3）手动kill掉app可以重新打开
4）app遇到crash后可以正常启动
5）重启app后登录态正常拉取

三、网络和流量

1）查看弱网下app能否正常运行，不会频繁报错
2）分别查看wifi/数据流量情况下的升级情况
3）非wifi，移动网络下app可以正常使用

四、文本框输入

1）点击输入框，app可以自动调起手机输入法
2）可以正常输入
3）支持复制粘贴的功能

五、权限安全问题

1）启动app时会弹出权限提示设置权限

六、中断测试

1）关机 2）断电 3）来电 4）push 5）前后台切换

七、兼容

1）横竖屏切换 2）中英文切换、字体切换、日夜模式 3）机型适配（安卓、ios）

八、性能

1）CPU 2）耗电量 3）流量 4）稳定性

测试用例编写原则及规范

1.统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。
2.测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。
3.编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。

用例模块划分规范

要求：
　　1.产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等；
　　2.产品是指产品线下大的业务模块。如交易购物车、交易下单；
　　3.功能点指业务模块下的子功能点，是最小功能点叶子节点。如01 功能_02 购物车展示_01 顶部及导航；
　　4.功能点目前无法再细分层级，后续会扩展功能点层次，在此之前，允许使用功能点名进行分层用例划分。如06 边境仓_03 发货单管理_02 创建发货单；
　　5.产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称；
　　6.主干用例库中产品、功能点已废弃的需要删除；
　　7.主干用例库中产品、功能点是之前QC迁移过来的，命名格式需要修改标准格式；
用例颗粒度划分规范
　　用例颗粒度原则：测试用例是执行的最小实体
　　用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：
　　1.一个功能正常流程，编写一个测试用例；
　　2.一个功能中多个异常流程，应分开编写多个测试用例；
　　3.同一功能不同入口，可合并编写一个测试用例；
　　4.同一功能不同数据准备，应分开编写多个测试用例；
　　5.同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；

用例编写要求规范

用例编写最基本的要求：
　　1.具有清晰名称、前提条件、操作步骤、期望结果的；
　　2.可被他人理解的；
　　3.可被他人执行的；
具体分项要求如下：
1.用例名称
　　1）常用的结构“主、谓、宾”；
　　2）名称简洁易懂，不要包括具体操作步骤；
2.前置条件
　　1）执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
　　2）不可将其他用例作为前置条件，前置条件需要语言描述；
　　3）完整清楚，包括入口、帐号类型、账号权限、数据准备等，具体要求如下：
　　 3.1）入口：覆盖所有功能入口，包含URL直接访问；
　　 3.2）账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如子账号权限，disable会员权限；
　　 3.3）数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条；件，写明数据库表字段值，如OFFER.status=TBD；对于复杂的数据准备，写清具体SQL
3.操作步骤
　　1）操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
　　2）操作和结果是一一对应的，但操作中不要包含结果的检查；
　　3）用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
　　4）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
　　5）用例描述中不允许出现二义性语句；
4.预期结果
　　1）原则上每个用例必需要有预期结果，结果不能为空；
　　2）结果中只能包含结果，不能有步骤；
　　3）一个结果有多个检查点时，确保检查点完整；
　　 3.1）结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
　　 3.2）结果涉及页面，需明确页面提示结果、数据变化；
　　 3.3）结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
　　 3.4）结果涉及消息：需明确关键查看内容；
　　 3.5）结果对应不同输入数据有差别时需分别对应描述清晰；

用例维护规范

测试用例编写完成后，应对测试用例进行持续的维护：
　　1.新项目需求变更，应及时对测试用例进行修改；
　　2.维护期项目，可根据项目组情况周期对用例进行维护；
　　3.所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例；
　　4.项目发布后的三个工作日内，需将项目用例根据具体情况归入产品功能用例库下

编写测试用例的方法与原则

编写测试用例常用的方法：

白盒：
代码检查与走查
桌面检查
同行评审
逻辑覆盖

黑盒：
等价类划分法
边界值分析法
错误推论法
因果图法
判定表驱动法
正交试验法
功能图法
场景法

测试用例的综合策略：

1、在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2、必要时用等价类划分方法补充一些测试用例。
3、用错误推测法再追加一些测试用例。
4、对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5、如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

测试用例的制定原则：

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
　　1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
　　2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
　　3、安全性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
　　4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
　　5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
　　6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。

8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
　　11、可操作性：理解和使用该系统的难易程度（界面友好性）。
　　12、可移植性：在不同操作系统及硬件配置情况下的运行性。
　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较