今天写测试用例比较多，从需求的熟悉到测试用例的输出，还是一个比较复杂的过程，其中的难点主要有以下几个：
1）如何在短时间内理解需求
2）如何快速梳理测试点
3）如何快速写出逻辑条例较清晰的测试用例
测试对开发与产品，一直是一个一对多的过程，这已经是整体的行业普遍现状了，所以时间就是最大的资本，如何最大化的争取时间来提升效率，也是重中之重。
a) 首先是短时间内理解需求的部分，需求总是以市场为导向，一个优秀的产品可能会抓住市场的契机来提出各式各样的需求，或新颖或通俗易懂都有可能，所以注定了需求可能是不熟悉的内容，对此，还是从背景入手，通过背景来对需求有一个整体的思路构建，接下来就可以进行下一步了。
b) 明白了需求做什么 ，下一步就是测试点的梳理，测试点一般通常都是针对功能的，而功能这方面，也有可以快速入手的方式。因为虽然需求可以百花齐放，但是依靠的技术实现还是通用的那一些。举个例子，比如列表的实现、菜单栏的查询等等，测试流程和测试内容的框架也是逐渐形成了一个比较通用的测试方法，不同的可能是其中的内容需要随着需求做一个替换。
c) 整理完需求和测试点，之后就是写测试用例的部分了，从这部分开始，才算是一个真正的产出环节，前面的部分都是一些必要的铺垫。俗话说，磨刀不误砍柴工，铺垫好了，才有后面环节的顺利进行。测试用例的编写主要有以下几点：
1. 用例工具的选型
比较常用的一般是用excel或xmind来编辑，xmind相对而言更有优势一些，无论是操作还是分类的逻辑，会整体更有条理。
2. 编写顺序
对于每个需求的用例编写，为了做到不遗漏，从整体到局部，层层递进的来收缩范围，对局部的范围扩展测试用例，是一个比较好的思路。
3. 分类方式
对于每个需求的测试用例，都可以先进行一个整体的分类，无外乎功能、权限、兼容性/适配性、埋点、网络需求等几大类，根据日常工作的要求，分类进行编写，会更清晰。
4. 由易到难
柿子当然要先挑软的来捏，对于测试用例也一样，根据分类，先把简单的部分完成之后，能留出更多的精力去攻克复杂的部分，因为复杂的部分往往有很多的逻辑，会展开更多的分支，需要更多的精力去编写。
5. 形成自己的节奏和思路
这个看起来像是空话，其实更像是经验的累积。对于常用的测试内容，有一个自己的定位和预期，这个还是要在工作过程中逐渐积累起来的。形成了自己的节奏，养成一个比较好的测试习惯，之后的工作会顺利很多。
测试的工作虽然显得枯燥，但是还是有方法可循，找到合适的方式，来更好的应对工作的持续冲击。
