昨天临睡前看到一篇博客文章，看起来是一位java后端写的【转测试/测试开发】的系列文章

我把他的一系列10多篇文章都看完了，个人觉得特别适合刚开始接触测试或者想对测试做一些了解的朋友。

其中，对于测试用例的设计，我之前有分享一篇文章，像用户一样测试。

如果说我们是测试用例的创作者，需求文档以及相关业务及要求是测试用例设计的依据，那么，产品和开发就是用例的用户。测试用例不只是测试的执行依据，在用例评审这个环境，更是检验产研测三方是否理解一致的又一道保障。

在设计测试用例的时候，要明确一个原则，不论给到谁，都能做到开箱即用，见名知意，可以直接上手操作。

怎么设计出高质量高覆盖的用例？

常用的测试用例设计方法，等价格、边界值，场景法，错误推测法......

这些方法能帮我们想出更多的测试点，设计尽可能高覆盖的设计用例

我想说的是对业务的理解，对开发的熟悉，清楚上线后推广手段，用户操作习惯...这些能给我们带来更多测试场景，补充更多测试点

试想，当我们按照需求文档设计用例，执行用例，产品上线后，再发现运营的推广手段导致用户使用的场景和我们想的常规操作不一致呢？从业务实际情况来反观项目设计阶段，可以帮忙我们覆盖更多的场景。

对业务的理解，无论我们做什么类型的测试，自动化，性能还是安全，这都是必须且非常重要的，我始终认为大部分测试手段和行为都是基于“业务”需求基础上的，当我们足够熟悉系统，比产品熟悉，比开发熟悉，在接到一个需求时，能很快分析出其合理性和漏洞，这从开始就避免了很大的风险。

对开发的熟悉，这点我觉得完全在平时和开发的合作过程中积累，哪个前端容易出什么样子的问题，哪个后端容易在哪些地方大意，有些看起来应该“这么”实现的问题，但是开发偏就“那么”做了。

我想在平时中，积累测试经验，时常梳理，是很重要的。关注所在行业信息，注重业务积累，留意用户的反馈，我们作为用户时对产品的使用感受，这些都可以让我们在测试时，更多一份“力量”。