测试用例理论与实践

1、测试用例理论与实践 - 测试用例设计方法 - 理论案例分析 - 真实场景案例 理论-演习-战场困惑：我们看过太多理论知识，也演练过无数笔试题，但是当一个软件摆在你面前的时候，却不知道如何着手。 演讲者：YOYO我们为什么要写测试用例制定计划-避免盲目测试并提高测试效率目标明确-重点突出、目的明确防止漏测-版本更新后只需修正少部分的测试用例，降低工作强度、缩短项目周期快速上手-当缺少人手时，可以把用例给新手分担工作量评审分析-通过用例来评审整个项目有哪些功能点没涉及到，便于评审分析版本归档-项目结束后可以归档，过很长时间后重新开始做这个项目时，可以快速熟悉 思考：设计用例我们用到哪些方法？设计测

2、试用例方法黑盒测试： 一、 等价类划分法 二、 边界值分析法 三、 错误推测法 四、 因果图法白盒测试： 逻辑覆盖法 基本路径测试法一、等价类划分-演习题 习题：设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的日期检查功能。功能点细分：日期类型及长度年份范围月份范围划分等价类并进行编号输入等价类有效等价类无效等价类日期的类型及长度6位数字字符有非数字字符少于6位数字字符多于6位数字字符年份范围在19902049之间小于1990大于2049月份范围

3、在0112之间等于00大于12设计的测试用例如下： 测试数据 期望结果 覆盖的有效等价类 200211 输入有效 、 测试数据 期望结果 覆盖无效等价类 95June 无效输入 20036 无效输入 2001006无效输入 。一、等价类划分-实战当我们拿到app后，打开手机页面，看到的情况是酱紫：思考题：我们如何设计姓名这个功能的测试用例？一、等价类划分-实战当我们拿到app后，打开手机页面，看到的情况是酱紫：-这时候我们回想下刚才的演习题-第一步需求分析-第二步功能点细分-第三步设计等价用例纳尼？需求在哪。功能点到底是啥。没需求文档啊。那么问题来了：当我们拿到软件没需求没功能说明时怎么设计用

4、例？等价类划分-实战当我们没需求文档时，如何探索功能点当我们拿到软件要测这个功能点时，我们首先得知道这个功能怎么用?-问开发？开发说我按设计图纸来的-问UI设计？设计只画了个效果图-问产品?产品自己也是不清楚这个具体功能，他只知道要有姓名这一栏的功能那么接下来只得靠自己来探索了等价类划分-实战编辑姓名探索功能点首先我们可以看到这个功能在资料编辑里，姓名后面一栏“请填写姓名”基本功能：编辑、保存那么编辑内容如何等价类划分呢编辑字符类型：特殊字符（数字、#￥%、）、中文、英文、其它语言（日文、韩文）、混合字符名字长度：这个我们无法知道它最长支持多少字，可以自己输入几百个试试，看它究竟支持多长，那么

5、这个长度范围：0长度2.插卡-3.开机-4.进系统-5.短信箱-6.编辑联系人-7.编辑短信内容-8.发送检验短信功能是否正常的标准仅仅依靠这些是不够的 -我们最容易忽视的是验收的标准场景设计法验收标准:对方接收到短信检验短信功能验收标准并不是仅仅短信能发送就ok，而是对方能收到短信那么发送之后还有如下流程：8.发送-9.短信中心-10.基站接收-11.基站转发-12.收件人-13.接收短信-中间有13个环节，也就是13个场景思考：是不是对方接收到短信了，短信功能就算验证通过了？场景设计法实战编辑姓名流程：1.基本资料-2.点击编辑框-3.跳出输入法-编辑内容-保存-查看姓名显示 验收标准：1

6、.能显示正常（无重叠、无乱码、长字串能截取）2.其它用户也能看到修改后的姓名3.软件其它相关地方：如发布、评论、社区等（最容易漏测）4.不同手机、pc环境都能显示（有些手机不支持多国语言会显示乱码）经典案例分析面试的时候经常会被问到：你遇到最经典的BUG？案例1:mtk功能机某平台，当手机联系人存满时拨打电话，会出现打通的号码不是当前你拨打电话人的情况案例2:mtk智能机某平台，编辑短信内容：#发送 会出现手机重启案例3:有个计费功能，30天包月。每到月底31号会出现反复计费包月-一个好的测试用例是在于它能发现至今未发现的错误测试用例设计总结总结：一、基本方法 -四大方法二、场景设计 -详细流程，考虑特殊环境三、验收标准 -多种验收环境 -发生概率-寻找bug就好像进入幽暗的丛林去探索惊喜！-b