测试用例，怎么写 ？

本文的测试用例主要针对功能测试。
软件测试中最重要的因素是设计和生成有效的测试用例。

穷举的测试是不可能的，合理的测试策略是通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试。黑盒测试（数据驱动或者输入/输出驱动的测试）基于程序规格说明书黑盒测试的目标是找出程序不符合规格说明书的地方。 白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。

一个好的测试用例为具有相当高的可能性发现某个错误，最最广泛的测试用例设计能够保证每个错误都有被曝光的机会。

1 了解需求范围

测试涉及的模块有哪些，用户有哪些，不同用户角色功能权限是否一样？

测试用例设计-测试用例概述
确定测试原始需求
功能测试需求分析
测试用例设计
测试用例设计

2 功能测试用例编写步骤

1、拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，使用场景法、状态图法覆盖主场景流和分支场景流。
2、针对具体的功能点或者控件进行测试。如注册功能的账号输入框要求，下拉框控件，使用等价类分析法，对正常和异常等价类进行测试。对于有边界要求的，如字符长度要求，使用边界法，在边界值进行测试。
3、UI测试：UI展示内容是否符合需求、UI展示效果是否符合设计图。

根据需求文档，列出所有可以测试的功能点。
对功能点进行分层分析，后扩展功能点为测试点。（思考需求里包括哪些组件，如按钮，列表，删除功能，搜索功能，有哪些通用功能，从通用用例角度考虑测试点）
建议用思维导图形式。
考虑一个功能的增删查改。
单个用例最小化原则，即一条用例只做一件事，先从单个模块或者功能点入手写用例

登录界面分析

3 根据测试用例设计方法

利用用例设计方法（等价类、因果图、判定表、边界值、错误猜测、场景法，状态图） + 经验 + 拆分后的测试点 + 通用用例规约，来设计最终的详细测试用例。
建议先进行用例设计，再将用例整理至用例系统或者Excel中。
确定测试方法的参考原则：
（1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用 场景法
先用visio画流程图，然后进行路径覆盖。（先考虑流程，再考虑控件）

（2）需要输入数据的地方，考虑采用 等价类法划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。通过定义条件和错误类来帮助减少测试的工作量。
（3）在任何情况下都必须采用 边界值法分析法。测试等价类中每一个分类取边界值时的情况，既要考虑输入等价类，也要考虑输出等价类。这种方法设计出的测试用例发现程序错误的能力最强。
（4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用 因果图法和 判定表法。
状态图
（5）对于参数配置类或者输入有多个情况的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的的测试覆盖率）。
（6）对照程序逻辑结构，检查已设计出的测试用例的逻辑覆盖程度。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前5个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。
白盒测试方法
（7）采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧。
输入输出错误猜测法

4 非功能用例

挖掘隐性需求，覆盖非功能测试层面
需要考虑兼容性问题、浏览器兼容性、操作系统兼容性，如果是app侧的还要考虑中断测试、弱网测试等等

1. 设计测试用例时也要注意涉及到的数据库中的字段值是否正确
2. 需要注意关联模块的用例设计
3. 注意新增接口、新增字段的用例的设计

文章 测试用例这回事

5 测试用例编写原则

1.预期唯一
2.描述清晰
3.可执行
4.优先级
5.易维护。
用例不仅自己看，也会给别人看。
你写的用例，其他人能否执行？

6 借助AI工具

借助文心一言/chatgpt，输出测试用例。
提问：点击上传按钮，上传图片，并展示，请输出测试用例。

7 用例评审

测试用例是一定要评审的，因为每个人都有自己的测试盲区，所以不要认为自己考虑的是全面的

评审参与人员，相关产品、开发、测试参与即可

评审的意义：将测试用例编写中遇到的疑问在此得到答案，并引导开发、产品功能进行思考补充现有用例（查缺补漏）

测试用例更新：一是评审后需要更新，在者就是测试过程中需要更新，测试结束后根据线上反馈情况进行更新

8 怎样能够快速准确找到bug？

1. 紧扣需求文档，挖掘需求细节。梳理测试重点（测试用例设计~思路分析）。
2. 发散思维进行用例设计。
3. 网上找常见功能点的测试。
4. 多与同事交流，测试不是一个孤立的存在。
5. 看历史bug库，用例库。
6. 与开发沟通，系统薄弱点，需要重点测试的部分。
   软件测试基础—流程和用例设计方法
   https://www.cnblogs.com/deliaries/p/12393843.html