1）能看懂需求文档，找准测试测试依据
作为测试人员，需求文档是测试软件的依据，首先需要看懂产品的需求文档。对于需求文档涉及的测试点能够整理出来，简单理解就是把大段的文字描述转化为思维导图的过程，推荐大家通过Xmind的形式整理。
其次，在需求文档的基础上结合测试环境或者产品人员，加深对需求的理解，方便后续更好的熟悉需求，整理测试点编写用例。
2)整理测试点
整理测试点的好处就是给编写用例的人员提供一个全面可靠的思路，防止设计用例过程的遗漏或者错误。同时也可以降低直接拿着需求文本编写用例的难度。编写的宗旨，最起码确保能覆盖所有需求。
将需求文档中的需求转化为测试点，方便编写测试用例，一般按照需求文档拆分成小的功能点，分别去验证。拆分到直接能够编写用例的程度，这个过程中可以使用一些设计用例的方法，即分别验证每一个小的测试目的。
公司新来的阿里P8把设计用例规范的整理成下面的PDF文档，包含了测试用例原则，测试用例主要元素，测试用例编写规范，测试用例编写细则，测试用例编写方法。看完这个PDF，你的测试用例再也不用担心出问题了。
1.目的..12.范围.23.术语解释4测试用例原则
4.1系统性
4.2连贯性
4.3全面性
4.4正确性
4.5符合正常业务惯例.
4.6仿真性
4.7可操作性
5测试用例主要元素6测试用例编写规范6.1常规的测试用例：
6.2初始化的测试用例：
6.3边界的测试用例.
6.4空值的测试用例：
6.5格式错误的测试用例：
6.6溢出的测试用例：
6.7关联的测试用例：
6.8唯一值的测试用例：
6.9权限不足的测试用例：
6.10角色权限的测试用例：
7测试用例编写细则.….7.1测试用例命名规则...
7.2测试用例编号规则..
8测试用例编写方法..8.1测试用例编写准备..
8.2测试用例编写方法.
篇幅所限，测试用例编写规范无法完全撰写，需要本PDF的可以关注并私信我关键词“软件测试”获得
