功能测试（二）测试用例设计

测试用例：测试执行过程的所有记录（执行大纲）
测试用例的作用
能够覆盖系统要求功能
给执行人员指导方向
测试用例的内容 excel表格书写
1、ID
2、测试标题（测试点）
例：正确用户名和错误密码登录
3、优先级
需求中明确规定的功能
常用功能
基础功能
特色功能
4、前置条件（执行用例关键步骤的客观条件或前提条件）
5、步骤（不要超过10步）
6、预期结果
（1）描述出界面的跳转：如登录成功后界面跳转
（2）界面显示：如跳转后显示无异常（ui检测）
7、测试结果：设计用例时不需要写，执行的时候填写
pass:预期结果和实际结果一致
fail:实际结果和预期结果不一致
（1）bug不一致，很明显的报错
（2）实际结果可以接受，甚至比预期结果更好，但是和预期不一致
NA：由于环境或者工具原因造成该条测试用例不能执行
Block阻塞：由于BUG造成导致该用例不能执行
8、实际结果：该字段可以没有（用文字描述结果）
9、备注
（1）当没有实际结果字段时，可以用来描述实际结果
（2）当测试结果为Fail时，可以用来备注bug ID和标题
（3）根据需要填写其他信息（测试人员、时间、版本等）
常用的测试用例方法
（1）等价类边界值
大多数用输入框的地方
数据类型：等价类（数字、字母、字符【特殊符号、空格】、汉字、表情符号）
长度\范围相关用边界值（年龄、内容长度【字符和汉字所占长度不同】）
（2）场景法，流程图
流程图：业务流程–数据流转
测试对象划分：数据哪里来–>模块–>数据那里去
场景法:用户操作的场景（客观环境）
在测试一个模块/功能的时候，不仅需要考虑数据从哪里来到哪里去，还要考虑有哪些客观因素，外界因素对这个功能有影响
（3）因果图
涉及输入、输出；多个输入之间的关系
（4）判定表
（5）错误推测法/猜测法/探测性测试
依赖于经验
（6）正交实验
依赖计算公式，生成组合
正交工具：pict
（7）分类树（关注覆盖率）
根据界面元素镜像测试用例设计的思考
1、输入框
根据字段的含义和业务，结合等价类、边界值设置
考虑数据类型和长度、字段意义（应该有什么不能有什么）
2、选择框
（1）单选：圆框，最多只能选择一个
（2）多选：方框，可以至少选择一个
1）选一个
2）选两个或多个
3）选多个后点击全选按键
4）直接点击全选（全选按钮变为取消全选）
5）全选后取消全选
6）全选后部分取消
3、链接
1）链接的有效性
2）链接的跳转的地址是否正确
3）返回操作（浏览器的返回键/页面上的返回操作）
4）内容（正确、排版）
5）点击后字体颜色发生变化
6）后台配置（更新）
4、图片
1）后台配置（更新）
2）放大
3)放大缩小-鼠标滚动等操作
4）右击操作
5）长按操作
5、按键
1）操作区域
6、滚动条
1）鼠标滚动
2）拖动滚动
3）浏览器放大缩小后滚动条的变动
7、下拉列表
1）数据固定（超过5个以上，随机测试；5个以内挨个测试）
2）数据不固定（随机测）
8、分页（输入框+按键组合）
1)以数字测试为主，汉字字母可以测，但优先级不高
如何开始及设计测试用例
1、根据需求文档设计

提取功能点（需求文档中可操作性、可现实的功能）
测试点：用户在不同条件下，场景下操作该功能的点
2、系统已经提测
（1）单个界面中，基于控件对业务进行测试
a、该界面是什么功能
b、字段信息：必填和选填项
c、针对必填项尽量测试详细，选填项尽量覆盖
（2）单个页面中，字段之间相互影响
（3）模块和模块之间的数据流转
（4）系统整体测试：用户体验
模块整体-例信息填写模块
【1、标签切换、关闭、刷新等
2、模块中表单中tab键使用
3、填写信息界面，填写部分，锁屏操作，解锁进入系统，数据显示是否正常，可以继续填写信息】
整个系统的整体
【1、输入界面表单tab键切换
2、浏览器大小拖拽对界面的影响
3、电脑键盘快捷键的使用
4、滚动条，锁屏、睡眠等操作的影响
5、登录时间体验、页面加载速度、各界面提示信息、各界面布局、UI是否统一 】
测试用例的存储和禅道的用例执行
一、工具
思维导图：整理功能点和测试点
excel:整理测试用例
禅道：测试用例管理
【导入和导出:
1、先导出一条用例，格式CSV，另存为excel格式
2、根据已有的用例格式设计测试用例
3、另存为CSV格式，再导入禅道（注：字段信息必须一致；用例步骤和预期结果必须一一对应-没有结果也要有标号）】
二、执行
功能测试阶段，用例一般执行2-3轮
a.开发体测第二轮，用例第一轮还没结束
b.用例第一轮已结束，开发第二轮还没出来
例：用例600条
第一个版本：459条；第二个版本：从460条开始
第二版600条结束，第三版未出，则从1开始在第二个版本上测
负责模块该版本测试结束，未有新版本，则考虑探索性测试，并记录测试点
三、维护-增删改
增加：
1、发现用例中没有覆盖的bug
2、产品需求变更
3、项目要求用例细化
删除：当一条用例至少两个版本没有用到
修改：直接在原用例更改

具体测试用例分析

分析设计优先级
需求文档中明确提出来的功能或者异常操作
基本功能（登录）
常用功能
特色功能
前置条件（实现用例的客观条件或提前的操作）：
1、网络
2、账号
3、其他需要实现的条件
操作步骤：
步骤最好不要超过10条
预期结果（描述执行该步骤后出现的现象）：
（1）功能实现
（2）数据库确认
（3）界面显示
测试结果：
Pass：成功，测试结果和预期结果一致
Fail：失败，测试结果和预期结果不一致
NA（No action）:没有执行[因为没有环境或者没有工具造成给用例无法执行]
Block:阻塞[因为bug的存在导致用例无法执行]
备注：
（1）如果测试的结果是fail过block，则写上bugID和标题
（2）实际结果的现象或者内容
（3）测试对象的相关信息【版本、测试人员、执行人员】