关于用例有没有必要写，这其实是无可争议的，那肯定要写的。
那为什么还会问有没有必要写呢？
- 时间不够。现在互联网企业发版周期短，需求变化频繁，项目繁多，测试人员配比不足；
- 团队管理混乱，对测试重视不够，觉得随便点点，看起来 没有问题就行了；
- 敏捷附身。敏捷不是有探索式测试了么？探索式测试不就是不要用例去测么？
如何应对呢？
- 时间不够，可以以测试点编写为主，也就是理清测试范围，着重测试的内容。测试点不在乎形式，不用设计数据和步骤。当然最建议的编写方式是思维导图（xmind）；
- 如果是团队对测试重视不够，那需要单独写一篇文章来谈了；
- 探索式测试是一种对经验要求很高的测试方法，而且探索式测试也只能作为一种辅助，不能作为主要的测试方法。特别对于经验不足的测试人员来说，没有经验的自测，探索式测试就像在迷宫打转，很容易在同一个功能来来回回测试，反而浪费更多时间，还不容易测试完全。
用例的重要性在哪？
世上很多事，都需要先设计后实施，测试用例就是测试的设计过程；
设计与编写测试用例的过程，也是熟悉需求、深入理解需求及测试需求的过程。虽然前期有需求评审，但是需求评审之于测试人员始终是参与，因此难免会有很多考虑不到的地方，但是编写用例的过程需要详细考虑输入输出，会进一步熟悉需求；
测试用例的设计与评审，可以使测试方向和思路处于一个可控制的范围，避免测试思路的产生偏差。特别对于测试管理者，当你的团队中有新人或者测试经验较浅的成员，如何才能保证他/她的测试不会出现太大的偏差？最好的办法就是用例评审；
在开始测试之前设计好测试用例，可以避免盲目测试并提高测试效率。盲目的测试会导致大量的漏测甚至方向性的错误；
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“大概完成 95 % 的测试”更有意义；
更好的估算测试工作量。测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。测试工作量有很多因素影响，因此估算是很难的，如果能以用例作为参考，可以一定程度上更容易估算；
测试用例的可以使软件测试的实施重点突出，目的明确。通过测试用例划分出优先级和重要性，可以在测试时间紧张的情况下，让测试更有效；
功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化使软件测试易于开展，并随着测试用例不断精化，其效率也不断攀升。
