测试用例是什么？怎么写？最好实用的测试用例

---

前言

测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。

一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。

在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。

怎么写测试用例是老生常谈了，网上也有很多正式的教程，什么正交法、等价类、因果图、场景法等等，这些方法推荐都深度学习和掌握。

一、如何把握测试用例的颗粒度

作为一线的测试人员，测试用例是每天都要写都要看的，每个人都会有写测试用例的方法和习惯，此处不具体展开讨论方法的优劣，只谈测试用例颗粒度的理念。

测试用例颗粒度越大，即每个用例覆盖的feature范围越大，明面上测试的工作量会变小，测试人员会有更多自由发挥时间，例如进行更多的ad hoc测试，但是会有较大的风险，项目质量将严重依赖于测试人员的能力和责任心。

测试用例的颗粒度分得越小，测试用例编写和执行的工作量就越大，测试人员容易陷入呆板的机械的执行过程，但是开发越容易复现bug，所以颗粒度需要针对不同场景，具体研发流程，采用不同策略。

比如某个项目的人员小李是远近闻名的粗心篓子，那么在测试这个项目时，设计测试用例的时候就要越细越好。

另一方面，如果测试用例写的细，开发也认真按照用例写代码（TDD），那么bug就会比较少，产品交付质量会较高，维护成本也会很大，甚至大到无法维护的成本，需要辩证的去看这个事情。

二、测试用例库是一个持续完善的过程

测试团队需要有一套或者多套持续维护的用例库来对应各种业务测试场景。例如当app常规发布时，需要回归主流程，这样的一套用例库不需要很多。

但是假如微信sdk发生变更时测试需要回归全部涉及到微信的场景，这样的用例库势必变得非常庞大，以上