自动化测试的重要性显而易见，但自动化测试又无法解决所有问题，所以说完全依赖自动化是不可能的，但完全没有自动化是万万不能。在软件开发项目中，重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量，而队伍中的同学在每天重复劳动的工作之下，也丝毫得不到成长，看不到方向。
尽管自动化测试不能解决所有问题，但是却拥有一个优势：“Once” Written, Run Anytime as Desired（一旦写好，即可随意重复执行）。所以，自动化测试通常都会跟持续集成系统（比如 Jenkins）配合使用，就像 “良辰美景” 要配上 “月光杯” 才算的上是极致。这样我们可以避免在软件上线或交付的最后一刻，还深陷软件问题的泥潭中。当然，这也是敏捷开发的关键所在，把问题消灭在过程中，只需持续关注增量内容。另外，在持续集成中，可以根据自己的需求来确定自动化测试的触发频次和时间，比如 “代码提交”、“定时触发” 等。
万物皆有阴阳两面，自动化测试有这么多优势，当然也有它的劣势。所以，至今仍然有很多公司自动化水平不高。我们分析一下这些劣势，主要有以下几方面：
对测试人员要求相对较高。
测试用例需要根据版本迭代进行更新，有一定维护成本。
测试结果不一定可靠，测试用例也分 “好”、“坏”。

前面两点也是大家公知的问题，每个公司各有自己的情况判断，今天也不做赘述。今天我主要讨论第三个问题，也就是：怎么保证我们花了时间和精力去做的自动化测试，其结果是有效的、是能够反映被测代码质量的？

一、 测试用例也分好坏

对于标题，你可能会有疑问，测试用例竟然也有好坏？的确，测试用例也有好坏之分，那么什么是坏用例？什么是好用例？那要先从测试用例的特征说起：
自动化测试或者测试用例的根本目的就是 judge（判断）被测系统是否有问题，是以衡量被测产品的 “标尺” 存在的。所以，它具备一个重要的特征：在测试脚本和被测代码都保持不变的情况下，测试结果应该是稳定的、不变的。
根据这个原则，“坏用例” 并不是指测试不通过的用例，更不是测试通过的用例，而是指那些在相同条件下，偶尔通过、偶尔不通过的测试用例。反之，“好用例” 则是表现稳定的用例。
为什么说 “坏用例” 破坏性大？因为如果用例本身不具备稳定的结果输出，就无法准确的衡量被测产品是代码的问题还是用例本身的问题。如果每次测试结果都不能直接说明问题，需要进行反复分析，将直接导致大家对测试用例失去信心。也就是说，测试同学和开发同学会把测试用例的不通过，当成 “Warning” 而非 “Error”,这样的最终效果就是自动化测试慢慢被抛弃。

二、 测试用例的生命周期

有了 “好用例”、“坏用例” 的区分，测试用例就是 “鲜活” 的了。事实上，我们也可以规划处一个测试用例从生到死的生命周期。

一般情况下，我们可以以测试用例通过率或通过次数来为其划分 “好/坏”。随着执行次数的增多，测试用例可以切换 “好/坏” 状态，当 “坏用例” 持续一段时间之后，我们可以把它标记为 “垃圾用例”，并从自动化执行的序列中剔除。“坏用例” 和 “垃圾用例” 可以被开发或者测试同学修复，然后进入 “未知状态”。“未知状态” 中的应用随着执行次数的增加，不断的在这个生命周期里循环往复。

三、 如何消灭坏用例

至此，我们明白了测试用例的 “好/坏” 之分，也了解了测试用例的生命周期。那么，我们如何保证用例质量，“消灭坏用例” 呢？

1，通过 “CI”（Continuous Integration 持续集成）发现 “坏用例”
“坏用例” 指的是偶尔不通过、偶尔通过的用例。所以，你会发现在本地运行的时候很难发现 “坏用例”，因为 “坏用例” 需要被执行很多次才能被检测出来。执行很多次的过程可以非常好地通过 CI 系统来帮助实现，所以，如果你还没有使用 CI 系统，也依然建议使用持续集成工具进行多次的执行用例，即便你的工程量很小。另外一点，CI 系统可以在一天不同的时刻执行用例，而时间也是一个 “坏用例” 产生的可能属性。
当然，成熟的 CI 系统（比如 Jenkins）都可以满足绝大部分人的业务需求

2，防微杜渐
可能大家都听过 “破窗理论”：当房子上的一扇窗户的玻璃被打破，如果不及时修复，将会有破坏者破坏更多的窗户。“坏用例” 现象也是一样的，当出现一个 “坏用例” 时，如果不抓紧修复，整个测试用例集甚至自动化测试结果的可信度都将快速下滑。
对 “坏用例” 采取零容忍的态度，有助于整体自动化水平和质量的提升。可以建立测试或开发人员 “坏用例” 档案，并自动追踪每一个 “坏用例” 的来源，督促负责人跟进解决。

3，避免执行环境差异
例如，保证本地用例执行时的环境与 CI 执行用例环境是一致的。

4，使用异步等待
通常，一个测试用例多个测试步骤组合而成，每一个测试步骤都需要特定的执行时间，所以，大家写测试用例一般的做法就是等待特定的时长，比如 5 秒。但是相同的测试步骤在每次用例执行过程中的时长并不相同，并且有时差异还会很大。这往往会导致上一步还未完成，下一步就开始执行，导致 “坏用例” 的产生。
另外，即便是步骤执行没有超时，但依然可能造成时间上的浪费，比如一个步骤等待 5s，但实际执行只用了 2s，就有 3s 的时间浪费。
理论上，解决这个问题有两种方式：回调、轮询。回调是指，上一步执行完成后，通知执行测试用例的进程/线程继续下一步。但这种方式在实际中并不采用，因为它需要紧耦合被测系统，可能为被测系统带来新的问题和维护成本。所以，实际中，更多的采用的是以 “观察者” 身份存在的轮询。比如说，以很小的时间间隔来不断查询是否到达下一步执行的状态。这样就能够避免一定程度的 “坏用例” 的产生。

5，解决并行执行的问题
如果测试用例存在并行执行的情况，请确保多个测试用例之间不会因为相互对被测系统的影响导致冲突，从而使用例变成 “坏用例”。比如，在所有测试用例执行过程中，数据库相关操作都采取事务的方式，用例执行完成后，就立即进行回滚。

6，避免测试用例互相依赖
如果一个用例集中的测试用例时相互依赖的，那如果其中有一个 “坏用例” 出现，将会导致整个用例集不稳定。所以，尽量保证用例集中的每一个用例没有相互依赖关系，每一个都可以独立执行验证。

7，避免测试脚本太长
毫无疑问，一个测试用例的步骤越多，可能变成 “坏用例” 的概率越高，所以，一般情况下，一个 App 的测试用例不超过在 30 步最好。

8，提高测试用例代码水平
一个 “好用例” 除了结果足够稳定之外，还需要具备良好的结构设计，以及良好的可读性、可维护性。这一点对测试用例编写人员要求较高，当然，通过多读、多思、多写，能够很快的提高自己的自动化用例编写能力。

四、 MQC让测试用例 “转” 起来

“坏用例” 的产生跟被测应用、编写方法、测试环境等，都有非常大的关系，很难找到一个 “all in one” 的解决方案。但是，只要我们认真分析解决就可以让所有测试用例达到都是 “好用例” 这个状态。接下来，需要做的就是大家共同维护好这样一个最佳状态，避免 “破窗理论” 的发生。
在解决 “坏用例” 这个问题上，阿里云测 MQC 提出并实施了众多有效方案，例如，对于未通过的用例，增加 N 次重跑，避免 “坏用例” 的产生；比如 “在线录制” 可以帮助用户短时间内获得稳定性和兼容性都很高的测试用例；比如 “用例管理” 可以跟踪所有测试用例的通过率及通过次数，及早发现和处置 “坏用例”；再比如，阿里云测 MQC 还提供了 “Jenkins 插件，让大家无需关心硬件资源等问题，方便大家将 MQC 云上的服务添加到自己的持续集成流程中来，真正做到 “Once Written, Run Anytime”。这也是为什么只有在 MQC 平台上，测试用例才能真正 “流转” 起来。
下一篇文章将重点介绍 “测试用例” 如何在阿里云测 MQC 上进行流转，“坏测试” 如何被甄别。