一、产品需求确认
仔细阅读产品原型、需求文档、或者UI，反复和产品经理确认需求的细节，最好把需求拆分成一个个子需求。需求分析的越详细，对业务的理解程度就越高，对设计测试用例的帮助就越大，测试的过程中就更有目的性。
1、明确需求范围
了解该需求是为了解决用户的什么问题，是功能性需求还是非功能性需求，明确需求背后所隐藏的需求，将问题在需求阶段暴露的成本最小。
2、画业务流程图
根据需求中规定的业务流程，各业务流程分支的确定，并以流程图呈现出来。
3、功能点整理
根据产品需求整理出有哪些功能点，包括业务功能、数据约束、易用性需求、编辑约束、权限需求等等。
4、提取测试点
根据整理的思维导图，去提取每一个功能点中的细节需求，例如新增员工，在思维导图中，最小的颗粒度就到新增员工了，但是新增员工这个功能仍然有很多的需求点，员工姓名唯一性判定，手机号码是否必填等，这些更细的需求点组合起来就形成了测试需求文档。
5、确定测试范围
需求的确定，并不代表测试范围就是该需求的范围，很有可能一个需求分多个软件版本来实现，最后确定哪些需求是需要测试的，以及测试目标的优先级。
二、测试用例准备
熟悉完产品需求后，需要准备测试用例。用例是测试工作的基础，用例设计的好坏直接会决定测试的质量。测试用例常见的设计方法有：等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法。
1、等价类划分法
顾名思义，等价类划分，就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出若干个有代表性的值作为测试用例。
例如，我们要测试一个用户名是否合法，用户名的定义为：8位数字组成的字符。我们可以先划分子集：空用户名，1-7位数字，8位数字，9位或以上数字，非数字。然后从每个子集选出若干个有代表性的值。等价类的划分，最关键的是子集的划分。实际上，非数字还可以继续划分子集：字母，特殊字符。
2、边界值分析法
长期的测试经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值。
3、错误推测法
错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。这种方法没有固定的形式，依靠的是经验和直觉，很多时候，我们都会不知不觉的使用到。
4、判定表法
又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
5、正交实验法
用语言描述正交实验法会很抽象难懂，简单说，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。
功能测试方法还有很多，所有测试用例设计方法最终都需要以用例的方式呈现出来，设计的用例应该结构化，这样能够一目了然。这里我们以飞蛾为例，来进行测试用例管理。（如下图）
三、测试任务分配
分配测试任务前，需对测试团队每个成员都非常了解，然后根据每个成员的情况进行测试任务分配。分配测试任务需考虑以下情况。
1、测试人员水平不同，分配任务也应不同。
为了更好地完成测试任务，对于不同水平的人，分配的任务是不一样的，这需要我们对组内的测试人员的水平、特性都有比较深的了解，才能合理地分配任务。
2、重点模块需要重点关注，着重测试。
有些重点模块，需要我们重点关注。对于这些重点模块，一般而言需要找一个你最信得过的人来测试它们，关键是保证质量。当然，如果有必要的话，考虑多个人同时测试一个重点模块，这是为了人员备份，更为了测试质量。
3、试任务注意在测试人员中间互换，增加测试新鲜感。
一个人如果总是测试同一个模块，是会审美疲劳的，刚开始工作效率可能会不错，但几遍之后就会没有太多进展了。为了降低测试的泄露率，增加测试人员测试的新鲜感，提高测试人员的测试广度，不妨把测试人员的测试任务进行互换。
4、测试任务下发之前一定要与测试人员沟通。
分配测试任务之前，应首先与测试人员进行任务的沟通，让他们明白他们负责模块以及他们的重要性。如果他们存在一些不同的意见，你可以根据情况再进行相应调整。
5、分配测试任务需明确每个测试任务的优先级。
根据测试任务的难易程度，以及对整个业务的影响程度，为每条测试任务标注优先级。优先级高的测试任务需要优先测试，以保证整个测试工作顺利进行。
四、总结
在开始测试前，提前做好准备，明确产品需求、准备测试用例、分配好测试任务，除此之外还需要准备好测试数据。把基本的准备工作做好，测试过程就会更加顺畅，显著提升软件交付质量。
