1.明确需求范围和重点
在开需求会的时候，明确本次需求作用的是那个模块，可能会影响到哪些模块。之前有没有类似的需求，测试的重点是什么，需求模块之间的优先级是什么。将这些问题提前处理掉
2.设计高效的测试用例
- 画流程图，梳理流程和数据流转
- 画状态转换图，因果图等分析流程
- 编写测试用例，去重（异常测试等价类，测试数据等价类，测试步骤等价类，测试结果等价类）
3.测试用例评审，技术评审
4.核心用例开发自测
5.不做无效的测试
如果需求的冒烟测试质量比较低，由多个较为严重的BUG，甚至可能阻塞测试流程，测试可以将需求打回，让开发重新自测。一方面是因为功能阻塞，下游的功能无法完成测试，另一方面，新的问题可能还是由于已存在的BUG引起的。
6.不做重复的测试
熟悉整个项目的架构，相互的关系。很多看似不同的测试点，实际只是一个测试点，仅仅是外面的包装不同。
当一个测试点出现问题时，那么其他的测试点也可能有问题，其他的可暂时先不用测试了。提BUG的时候可以列出核心问题所在，并将其他涉及的点提出来。等验证的时候，再把涉及的测试点都过一遍，这样就减少了很多重复的工作，只是在验证的同时把测试点覆盖全。
7.不同测试版本的测试重点
对于测试来讲，基本上一个需求要验证三个版本，（test 环境，beta环境，product环境）。如果每个需求都要详细的过一遍，遇到大需求的话，测试估计会累死。
如果针对三个环境，进行一个合理的分配和取舍，测试也会减少很多工作量。
结合日常的工作，提供一个思路：
test环境：验证BUG，全面测试，尽可能找出所有的BUG。
beta环境：验证上一轮的bug;
prod环境：验证全部bug，并全面细测。
这样其实只是第一轮和最后一轮需要全面测试，这样对于测试轮数多的情况下又能节约很多测试时间。另外一般beta环境的数据库和线上的数据库是一个，数据不可以随便增删改，风险较高，对数据的操作更多的集中在test环境。即使生成脏数据也没有关系。
8.优化测试顺序
先接口，后功能；先异常情况，后正常情况。
冒烟测试的时候，开发基本会把正向工作流程走一遍，没有问题才会提测，这个无疑给我们节省了时间，那么接下来，作为测试，我们拿到一个产品，可以先从接口开始测试。
执行接口测试时候，可以先进行单接口测试，校验单接口的输入输出参数是否符合要求。如果接口有传入新的参数，可以从：合法但不符合要求的参数，不合法也不符合要求的参数等，然后再简单过一下正合法的参数。对于输出参数，也是同理。当单个接口么有问题，可以考虑将接口进行串联，流程性测试。
当接口测试通过，说明后端的处理逻辑基本符合要求，接下来就进行功能的测试，不关注产品内部如何交互，进行黑盒测试。再进行测试的时候，也可以优先考虑异常流程，
这里借助一个例子：
就拿注册功能来说，一般会分为3个步骤，注册，验证，登录，一般正常情况都是先测试正常注册，正常验证，正常登录，然后测试异常注册，异常验证，异常登录。但这样有一个缺点，会有重复无用的操作：
当完成正常测试后再测试异常之前，需要从登录状态退出，然后再点击注册入口进行注册。
当测试异常验证的时候，需要再次测试正常注册，不然就进入不了验证的步骤。
当测试异常登录的时候，又需要再次测试正常验证，不然就进入不了登录的步骤。就这3点也许大家觉得最多浪费几十秒的时间，但如果注册信息要填很多呢，如果验证邮件或者短信要延迟很久才收到呢，这样就是浪费了几分钟吧。如果有其中有bug，那可能要测试多次来定位问题，那就可能浪费了10分钟，而这仅仅是一个并不复杂的测试，如果涉及到更复杂的关联，可能会浪费更多的时间在于无效和重复的测试中。
那么问题来了，这么调整测试顺序呢?
先测试异常注册，输入各种错误的注册信息，如果没有bug的情况下是跳不到验证界面的
然后测试正常注册，可以正常跳到验证界面
接着测试异常验证，如果没有bug的情况下是跳不到登录界面的
再测试正常验证，可以正常跳到登录界面
再测试异常登录，如果没有bug的情况下是无法正常登录的
最后测试正常登录，可以登录完成这样其实覆盖的测试点一个没少，但却没有无效和重复的测试，调整顺序之后可以减少不必要的操作，积少成多的节约测试时间。
9.他山之石可以攻玉
对于实在无法避免的重复劳动，可以借助自动化测试技术取解决，这一点需要基础的编程能力，同时也需要适合的工具，