编写测试用例的流程:1、需求分析;2、提取测试点;3、测试用例编写;4、测试用例评审。需求分析分为业务需求、用户需求和功能需求,业务需求关注系统是否满足业务。
1、需求分析
- 业务需求:关注系统是否满足业务
- 用户需求:关注系统是否满足用户习惯
- 功能需求:关注系统是否满足功能需求
2、提取测试点
测试点是针对软件所列出的功能各个情况的梳理在某种程度上来说,他是功能模块的细化,但是又比写出的用例要粗糙,更像是用例编写之前的整体梳理,具体要测试某些方面。常见的软件功能测试点:
- 安装与卸载:应用的安装和卸载在任何一款app中都属于基本功能。一旦出错,就属于优先级为紧要critical的缺陷。因此app的安装和卸载应作为一个测试点多加重视。
- 运行:软件安装后检查软件能否正常运行,运行速度是否流畅,网络异常时是否会崩溃等。
- 注册和登录:用户注册和登录功能是很多app产品基础的构成之一,而主流的登录页面大致分为三种:账号密码注册登录;手机号注册登录;第三方授权登录。
- 日历控件:目前很多包含购票功能的app中都会设置日历控件方便选票,此时应注意月份和日期相对应。
- 权限设置:首次启动APP是否同意启用权限,是否接收消息推送,是否允许位置权限和网络权限等。
- 软件更新:是强制更新还是非强制更新,更新时老版本是否可用,当有新版本时,不删除客户端的情况下,直接更新是否成功等问题。
- 兼容性测试:主要考虑尽量覆盖该产品的主要用户,从不同系统,版本,分辨率等纬度进行适配测试,关注各功能界面在不同分辨率下是否存在UI展示问题。
- 网络环境:不同网络环境下各功能是否正常运行,网络异常时数据交换失败是否提醒,网络状态切换后数据是否可以自动恢复。
- 异常测试:主要考虑没有内存空间时APP能否正常响应,横竖屏切换展示是否异常,APP运行时网络中断等问题。
3、测试用例编写
测试用例编写的注意点:
- 根据项目的实际情况设计测试用例表格
- 用例格式不是固定的,不要生搬硬套
- 根据具体的情况编写
一般测试用例包含的内容:
- 用例编号:少数,如同身份证号;
- 用例名称:用例的名字,要求言简意赅,如同姓名;
- 测试背景:这条用例主要测试什么东西;
- 前置条件:执行这条措施之前应该先执行什么条件,比如测试登录功能,前提是要有账号密码;
- 优先级:测试用例的优先程度;
- 重要级:测试用例的重要程度;
- 测试数据:比如输入的账号密码,鼠标的操作也是一种测试数据;
- 测试步骤:测试进行的步骤;
- 预期结果:对应输入数据或条件等得到对应的现象;
- 实际结果:测试执行后的结果;
- 备注:其他特殊情况的信息。
测试用例编写的方法:
- 等价类划分法:如何选择适当的数据子集,来代表整个数据集。通过降低测试的数据去实现“合理的”覆盖,覆盖了更多的可能数据,以发现更多的软件缺陷
- 边界值分析法:使用边界值分析方法设计测试用例时一般与等价类划分结合起来,但它不是从一个等价类中任选一个例子作为代表,而是将测试边界情况作为重点目标,选取正好等于、刚刚大于或刚刚小于边界值得测试数据
- 场景法:通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。场景法一般包含基本流和备用流,从业一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。
- 猜测法:根据经验选择容易出错的地方。
4、测试用例评审
测试用例评审的内容:
- 测试用例是否是依据需求文档编写的。
- 测试用例中的执行步骤、输入数据是否清晰、简洁、正确;对于重复度高的执行步骤,是否进行了简化。
- 每个测试用例是否都有明确的预期结果。
- 测试用例中是否存在多余的用例(无效、等价、冗余的用例)。
- 测试用例是否覆盖了需求文档中所有的功能点,是否存在遗漏。
- 测试用例评审后,用例设计仍未结束,因为在软件做出来后,需求变更后,用例仍需要修改。测试用例需要一直维护。
延伸阅读
测试用例是什么
测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,最终形成文档。简单地认为,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软件需求。测试用例主要包含四个内容:用例标题,前置条件,测试步骤和预期结果。用例标题主要描述测试某项功能;前置条件是指用例标题需要满足该条件;测试步骤主要描述用例的操作步骤;预期结果指的是符合预期(开发规格书、需求文档、用户需求等)需求。
文章标题:怎么编写测试用例,发布者:Z, ZLW,转载请注明出处:https://worktile.com/kb/p/36234