在一般的软件公司中，设计和编写测试用例一直是测试人员一个非常重要的基本工作。
但是，很多软件测试从业者或者说其他部门的总是会觉得，测试用例是没有什么必要编写的。我们可以想一想一款软件的研发流程：
产品人员确定用户需求->产品人员、开发人员、测试人员、UE人员等进行评审->开发人员进行设计与开发（测试设计并编写用例->开发人员提交->测试人员按照需求和用例执行测试->上线发布。
我认为，测试用例是必须要编写的。但是很多软件测试从业人员认为测试用例的编写是无用功，因为最后执行测试时经常和测试用例有很大的出入。其实造成这种现象的原因，我觉得主要的就是在需求评审阶段没有做好，开发、产品、UE对需求的理解不一样，导致了后续需求的变动，甚至还有可能需求本身就不是很完善，因此在开发的过程中还在不断地变更需求。
但其实这些原因，我们都可以把它们控制在可接受的范围之内，当然，这主要是需求评审阶段的内容。就个人而言，即使需求评审的流程非常完善，几乎不会再有需求的变动了。在编写测试用例时，为了使用例有更高的覆盖率，还是经常会发现需求的一些遗漏，及时沟通，提高效率。由此可见，编写用例的过程更有助于测试人员理解需求。
测试用例就像是剧本或者是指挥棒，所以，编写测试用例是必要的。但是在很多的互联网公司，基本都走敏捷开发，产品迭代非常频繁，这样，测试人员执行测试的时间就非常短，更不用说编写测试用例的时间，此时我们可以将测试用例简化测试点。
但是建议遇到比较复杂的流程时，还是能尽可能用测试用例来详细描述。
其实也可以在编写测试用例之前和准备执行测试时，找开发人员聊聊开发是如何实现这个功能。这样会很容易把握到测试的注意点，并记录体现在用例中。例如a开发曾经用某种方式做了a功能，出现了某个bug，现在b开发用了同样方式实现，那么极有可能之前的bug这次还会出现。
用例评审也是非常必须的，特别是一些很有经验的软件测试老司机，可以很快帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来，结束后及时找相关人员确认，避免猜测。