在测试中最重要的文档，他是测试工作的核心，是一组在测试时输入输出的标准，是软件需求的具体对照。编写测试用例，是测试人员的基本功，真正能写好的人并不多。
.测试用例包含的内容：用例编号，用例名称，测试背景，前置条件，优先级，测试数据，测试步骤，预期结果，实际结果，备注。
当测试小伙伴拿到第一个需求文档的时候，进行分析，提取测试点，编写测试用例，然后叫上开发，产品以及相关人员进行用例评审。
编写测试用例常用的方法：等价类划分法，边界值分析法，错误推断法，流程图法等，
学会质疑需求，不要完全按照需求来写测试用例，要从用户角度去理解需求，看到需求之外的功能和体验。
一、用例状态等， 没有的不需要填写。
用例设计，一定要可执行（最好2分钟内能执行完）
改进建议：
1、用例状态：请置空
2、用例步骤不要过长， 根据目的适当拆分几条。
3、尽量提炼合并， 如文本框，下拉列表，文字界面，浏览器， 平台等等
二、测试分类：
UI/UE
通用测试用例
功能
冲突测试（并发）
与外部系统交互及影响等
兼容
浏览器测试， 就放在兼容性测试里面， 列出所有的浏览器
通用一套用例目标及步骤即可
用例的步骤， 就是为了验证这个点。与业务流程操作（类似操作手册）不同
当然， 我们前期，为了加强思考、想象和理解， 业务流程梳理
针对需要验证的点， 再提炼测试用例目标点
每个页面， 文本框功能验证， 可以写在一条用例里面
用通用文本框测试方法，逐一验证。然后实际测试时，都是快速组合验证， 让问题最大化暴露。
比如标题就可以改为，运营商授权页面正常业务流程 （这里可以用操作手册的方法写上，逐步记录），对比需求，这个时候也可能发现问题
预期结果， 也不用专门写这么细。都是所见即所得。写功能正常 即可
避免执行用例的人， 只盯着预期结果， 而丧失思考。
实际执行的时候， 扫一眼， 记住目标。就开始认真抓bug.
前期优等bug都是关于功能点和逻辑的，需要全心全意站在用户的角度思考。
一般是页面上全部，
全部录入（含各类特殊符号，文本长度）或者选择项。
完全默认，啥都不选
按照规律组合