1，分别设计不同类别的测试用例
测试用例需要先区分类别，然后再进行设计。如冒烟测试用例，主要用来支持开发自测试，以及开发提测后，测试人员用来验证提测质量。冒烟测试用例主要覆盖需求核心业务流程，如果测试用例通过不过，会影响测试工作的正常开展。全功能测试用例，覆盖整个需求的测试用例，用来在测试过程中执行用例，来验证开发的代码是否符合产品的需求，发现可能存在的问题。不同类别的测试用例有不同的用途，需要分别来对待的。
2，从用户角度出发，编写测试用例
虽然我们了解到很多设计测试用例的方法，可是在实际工作中不能完全按着这些方法来实施的。这个需求的目的是什么？比如说一个活动页，需要展示给用户我们推荐的商品优惠活动，从而增加商品的销量。所以我们的测试用例就要从这个目的出发，检测商品信息展示情况，商品的优惠信息，商品相关的操作，跳转与交互信息是否符合要求。活动页的兼容性如何，是否符合各种场景，活动页的并发性以及相关交易的安全性，都是测试用例设计的出发点。
3，边界值，意外情况，异常用例的编写
从用户角度出发编写用例后，再需要辅助边界值法，将意外情况，边界值等异常测试用例添加进来。如上面提到的活动页需求，对于活动时间边界，库存边界，优惠限制条件边界等等，都需要补充相应的测试用例去验证的；同时，性能边界，安全边界也是我们需要考虑的地方，只有补充了这些边界，才不会造成遗漏的地方。
4，根据业务流程，编写流程相关的用例
有的时候我们的新需求只是一个业务流程的一部分，在通过相应的方法编写测试用例，验证了本次需求的核心功能，边界条件后，还需要考虑相关的具体业务流程。编写业务流程相关的测试用例，来验证本次需求对业务流程上下游的影响，能否正确传递数据。本次需求可能影响到的地方，测试用例也必须覆盖得到。
5，根据代码实现方案编写用例
根据代码实现的方案编写测试用例，如编码采取前后端分离的方式实现的。我们就可以分开测试，后端接口和服务从代码层来保证接口或是服务功能的正确性和完整性。然后前端的测试用例主要关注业务逻辑，数据和样式的显示即可。根据接口测试和服务的使用场景，来设定测试用例的侧重点和粒度，这样也可以做到测试前置。
6，根据业务经验编写用例，新业务，影响到的业务
测试人员必须对你的业务有充分的了解，这也是一个测试人员必备的能力。然后地遇到新的需求的时候，可以从参加需求评审的时候快速评估出本次需求可能影响的范围，从而对相关要影响的地方添加用例覆盖，进行回归测试。如一个需求是对某接口响应时间的调优，我们就需要对调用这个接口的所有业务进行相关用例覆盖，测试的时候进行回归测试。有这样的技术敏感度，业务熟悉度，才能做到不会遗漏影响到的功能。
推荐阅读：
sales@spasvo.com
