关于软件测试用例的一些看法

在一般的软件公司中，设计测试用例和编写测试用例一直是测试人员一个非常重要的基本工作。

但是，很多软件测试从业者或者说其他人总是会觉得，测试用例是没有什么必要编写的。

软件的研发流程是这样的：

产品人员确定用户需求->产品人员、开发人员、测试人员、UE人员等进行评审->开发人员进行设计与开发（测试设计并编写用例->开发人员提交->测试人员按照需求和用例执行测试->上线发布。

我认为，测试用例是必须要编写的。但是很多软件测试从业人员认为测试用例的编写是无用功，因为最后执行测试时经常和测试用例有很大的出入。其实造成这种现象的原因，我觉得主要的就是在需求评审阶段没有做好，开发、产品、UE对需求的理解不一样，导致了后续需求的变动，甚至还有可能需求本身就不是很完善，因此在开发的过程中还在不断地变更需求。

但其实这些原因，我们都可以把它们控制在可接受的范围之内，当然，这主要是需求评审阶段的内容。就个人而言，即使需求评审的流程非常完善，几乎不会再有需求的变动了。在编写测试用例时，为了使用例有更高的覆盖率，还是经常会发现需求的一些遗漏，及时沟通，提高效率。由此可见，编写用例的过程更有助于测试人员理解需求。

测试用例就像是剧本或者是指挥棒，所以，编写测试用例是必要的。但是在很多的互联网公司，基本都走敏捷开发，产品迭代非常频繁，这样，测试人员执行测试的时间就非常短，更不用说编写测试用例的时间，此时我们可以将测试用例简化测试点。但是建议遇到比较复杂的流程时，还是能尽可能用测试用例来详细描述。

其实也可以在编写测试用例之前和准备执行测试时，找开发人员聊聊是如何实现这个功能的。这样会很容易把握到测试的注意点，并可以体现在用例中。比如说，开发人员A曾经用某种方式做了某功能，出现了bug，现在开发人员B用了同样方式实现了类似的功能，那么之前的bug很有可能还会再次出现。

用例评审也是一个非常重要的阶段，特别是一些很有经验的软件测试“老司机”，可以很快帮忙指出用例的遗漏点，有助于打开思路，尽可能多的覆盖用户场景。

值得注意的是用例评审的时候遇到不确定的情况，应立即记录下来，结束后及时找相关人员确认，及时处理。