编写测试用例的流程：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
微信扫一扫 
支付宝扫一扫 
