参考需求文档，充分熟悉产品业务需求，提取产品的测试点，运用好测试用例设计方法，步骤场景清晰，尽量覆盖测试场景，包括显性需求和隐性需求，既要覆盖功能特性，又要覆盖非功能特性界面易用性兼容性网络安全性能等方面,覆盖到所有的业务逻辑，覆盖到所有的典型用户场景，覆盖到所有需求点，最终尽量没用冗余的测试用例。
用例编号、用例标题、功能模块、优先级、前置条件、输入数据、操作步骤、预期结果
根据用户使频率进行划分
1). 测试用例编号
编号由字符和数字组合成的字符串, 用例编号具有唯一性、容易识别, 如下表
2). 测试项目
测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等
3). 预置条件
执行当前测试用例需要的前提条件, 如果前提条件不满足, 则后面的测试步骤不能进行或者得不到预期结果
4). 测试输入
测试用例执行过程中需要加工的外部信息. 根据测试用例的具体条件有手工输入、数据库等
5). 预期输出
测试用例的预期输出结果, 包括返回值内容、界面响应结果等.
6). 操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
7). 测试用例标题
对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。
8). 级别
对于测试用例的重要程度的区分. 包含如下几种:
- 高级别
保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例 - 中级别
重要程度介于高和低之间的测试用例 - 低级别
实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例
用例中包含那些内容？ 用例编号，用例标题，功能模块，优先级，前置条件，输入数据，操作步骤，预期结果
测试用例的级别根据什么划分的？ 根据用户使用的频率进行划分，经常使用的模块优先级高，不经常使用的优先级低
等价类划分法：有效等价类，无效等价类，举例输入框只能输入英文和数字
边界值法：有范围限制的，长度，取边界的点和边界相邻的点，输入框有长度限制常用于多条件、多结果、多组合场景
因果图法 正交表法
判定表法场景法：用各种场景覆盖可能的业务流程，基本流备选流，用户购物流程
错误推测法：根据以往经验，对可能出现的错误进行推测，用户注册情况
参考需求文档,充分熟悉产品的业务和需求,提取项目的测试点,运用好测试用例的测试方法 (等价类, 边界值, 判定表, 错误推测…),步骤场景清晰,尽量去覆盖所有的测试场景,包括显性需求和隐性需求,既要考虑功能又要考虑非功能 (UI, 易用性, 兼容性, 网络, 安全, 性能) 质量特性, 覆盖到所有的业务逻辑, 覆盖到所有的典型的用户场景, 覆盖到所有的需求点, 最终尽量没有冗余的测试用例.
测试用例要完全覆盖需求, 测试用例要 100% 执行
充分了解需求文档,采用测试用例设计方法,既要考虑功能,非功能 (界面, 易用性, 兼容性, 网络, 性能, 安全), 尽量覆盖所有用户场景, 同时还要进行测试用例评审, 进行查漏补缺, 有时间进行交叉测试.
一般在测试用例写完之后进行测试用例评审工作，我们会和开发以及测试团队成员一起进行测试用例评审，评审目的是为了找出是否有重复的测试用例，完善测试用例的覆盖率。 评审时间在半个小时到一个小时，评审方式是每个人阐述自己的测试用例，先对复杂的、优先级高的、疑问多的用例进行评审，如果时间紧，优先级低的用例先不进行评审。评审之后整理测试用例，把修改之后的用例进行补全，修改的内容用黄色标记，新增内容用绿色标记，有疑问的内容用红色标记。最终把测试用例交给老大最终审查，如果没有问题就按照测试用例执行测试。
- 界面 ui，检查界面是否与原型图和 ui 设定图一致，界面风格布局样式字体文字大小是否一致，是否有错别字，内容过长是否换行截断隐藏。图片是否显示正确，是否被裁剪拉伸。
- 易用性，是否支持快捷键，文字描述清晰易懂，操作流程简介易于理解，页面焦点是否合理，是否有新功能引导。
- 兼容性，web 兼容性考虑不同浏览器版本内核分辨率。需求有的测需求有的，未有的找前十浏览器。app 兼容性考虑不同手机品牌型号系统版本分辨率屏幕类型。安卓 10-13，ios 12-16. 屏幕 6.4-6.8 寸，10802400，10802340，14402560，14003200.
- 网络，弱网环境下是否正常，断网重连，网络切换。
- 性能，客户端性能，加载速度流畅度，占用资源情况。服务器性能，最大并发用户数，cpu 内存吞吐量响应时间响应成功率
- 安全，加密，掩码，越权访问，密码错误次数限制，