吃软件测试这碗饭的，如果基础理论都不懂，谈何长久？
前言
给你个需求，你要怎么转变成最终的用例？
老点工拿到需求后的标准操作：
第一步：解析需求
先解析需求-找出所有需求中的动词，再列出所有测试点。测试点过程不断发散，对于模糊不清的标准，要及时跟产品经理交流确定。
比如：“这里要弹出一个toast弹窗” ，老点工会问产品经理，这个弹窗要几秒钟消失。
比如：“这里头像要先读取缓存头像，没有的时候再去接口请求头像。” 老点工会让产品经理补充一下：接口拿到头像后，是先写入缓存，还是先展示到app上。
信我的，产品经理以后再也不敢随便提需求了。
第二步：划定测试点测试范围
这步主要是对刚刚的所有测试点，进一步的审核和确定测试范围。
比如：“测试用户名输入框”，那么是否要选用功非接进行测试，是否要测试可见不可见字段，输入处理和输出三项都要测么？划分好所有测试点测试范围。
第三步：运用十一种黑盒测试方法写用例
老点工写出来的标准用例，在用例评审的时候，往往能让现场所有人鸦雀无声，全部睡着....
第四步：用例属性标头完善
用例标头分为：【需求编号】【用例编号】【测试项目】【测试标题】【重要级别】【预置条件】【输入参数】【执行步骤】【预期输出】【备注】【用例提交人】
第五步：写用例规程
什么叫用例规程？就是设计一个用例的执行顺序，来让执行者可以大幅减少执行时间。
比如播放器的俩条用例：“A：在播放过程中点击停止按钮” 和 “B：点击播放按钮后快进到1小时处。” 。这俩条用例如果按照A-B的顺序执行，那么执行者就要先 点击播放按钮-然后播放一段时间后点击停止按钮-然后再点击播放按钮-再快进到1小时处。
如果按照B-A的顺序执行，那么就可以：先点击播放按钮-快进到1小时处-点击停止按钮 。即可完成俩条用例的执行了。节省了环境准备时间。
这个用例规程是最复杂也是最考验智商的步骤，很多公司无能力进行也压根不知道这个步骤。
当然用例规程是一场成本豪赌，除非老点工轻车熟路，否则一般新人还是不要浪费时间好。
