测试小故事18：我不要写测试用例

  “我不想写测试用例”，又一次听到一起工作的测试人员这么对我说。想来“不想”只是客气，“不要或是不愿”才是真正的想法。

  问其原因，罗列了出了一系列的理由

   1. 目前使用的测试用例已经好久没有发现任何系统缺陷了。

   2. 前两天没有按用例执行，直接随机测试，结果发现了好几个从来没过的缺陷。

   3. 测试用例好入不更新，与实际的系统已经相差很远。

   4. 执行这么多的用例，我已经没有时间去做其它类型的测试，每天只是疲于标记通过还是不通过，没有新意，倦了。

  然后与我沟通是不是可以不写测试用例。

  我想了想：

   1. 倦了是正常现像也是实情，测试本身就是重复性的工作，从任何一个工作的本身来讲，创新只是小部分，多数是按步就搬的执行。

   2. 更新测试用例是每轮测试结整后必须要做的，是测试人员的责任，为什么不能及时更新，这个需要解决和改进，应该是如何维护测试用例的问题。

   3. 至于随机测试发现了新的问题，这个就需要考虑测试策略和测试数据的应用，应当是如何提升测试覆盖率的问题。

  所以，测试用例必须写，只是有简单写和详细写的区别。

  如果你是位大牛，系统架构、功能了然于胸，测试点、测试数据清清楚楚，执行的不差分毫，那么你可以不写测试用例，只要提交详细的测试报告即可。只是测试报告依然要写清楚测试了什么、没有测试什么，存在的问题和风险是什么。

  开始绕圈了，有点死循环的意思，到底是写还是不写，怎么写？让我们回到纺写测试用例最初目的，即测试用例设计和使用的原点上来：

  编写测试用例以覆盖系统测试需求，理清测试思路。 -- 这是我的理解

  简单的来说测试用例就是明明白白的为测试人员指明，你要在什么环境下、用什么样的数据做哪些测试、达到什么效果

  从统计指标上来讲，就是用来计算测试覆盖率：测试用例涉及功能点总量 / 待测试系统功能点总量

  然而，一个突出的现实问题就出现了：

    一个测试功能点从功能实现角度来讲会有正常和异常流程

    从用户操作层面讲也同样有正常操作和异常操作（操作者的习惯林林种种）

    从系统所允许使用的数据来讲就会有成千上万种可能

  因此测试用例的数量按如此测算将会是无穷尽的。还好，测试用例的设计原则给我们提供了一系列测试用例设计方法，可以帮助我们对种种操作进行分类分析、设计对应的测试用例，这里好像有点面向对像的味道。。。。。。

  >> 测试用例的简单写法和详细写法

  详细写法测试人员都很清楚：序号，测试点概要，测试项，测试环境，测试数据，测试步骤，测试期望结果，设计时间，设计人。。。。。

  简单写法呢？解决和描述清楚一个问题：在什么时间、什么环境、用什么样的数据、验证什么样的功能？结果是什么样？对还是不对？原因是什么？

  简单说来就是要有足够详细的测试功能列表、测试数据，以及测试数据作用于测试功能点上的预期结果。

  这样的一个测试功能列表（function list）或者我称之为测试大纲的东东，真正描述起来其实工作量真的不小，需要深思熟虑，需要花费足多的时间才能逐步理清，只是格式相对简单些。

  >>关于测试用例的维护

  测试人员的基础工作之一，不必多说，不要觉得费事，这是一种查漏补缺的重要手段，对于长期维护的项目，这将是一笔宝贵的项目财富。在没有成为大牛之前，把基本功练好。测试保证质量不是一时兴起、不是随随便便，功夫在平时，维护好测试用例也是维护好自己的测试思想。

  >>关于随机测试和探索性测试

  随机测试不是随便测试，不是所有的人都可以做随机测试的，如果随便一个人都可以做随机测试并且能够发现足以致命的缺陷，那么专业的测试人员真的就没有什么价值了，反之被测试系统也就无法称之为合格的系统。

  探索不是凭空想像，而是在前期工作的基础上的一种分析的深入。探索性测试是基于前期测试的数据，对缺陷的分布规律、业务逻辑的反复推演而进行的一种有针对性的测试活动，有一套测试分析方法和测试策略。可以用大数据的思想解释：不求因果，只看相关性，由此着手，步步深入。

  无论什么样的测试活动，都不要忘了反思测试过程、补充测试功能点、测试数据，为自己还不是那么强的记忆留个记录，也是为了其它测试留个参考，同时也是保证整个项目的长期有效运行的需要。

-----------------------------------------------------------------------------------------------------------

  停下来，思考才是进步的本质。