自动化测试 之 “好用例、坏用例”

摘要： 自动化测试的重要性显而易见，但自动化测试又没法解决全部问题，因此说彻底依赖自动化是不可能的，但彻底没有自动化是万万不能。在软件开发项目中，重度依赖人力进行持续回归是一件很是枯燥的重复工做。企业须要花费大量的时间和金钱来维持这样一支队伍以保证产品质量，而队伍中的同窗在天天重复劳动的工做之下，也丝毫得不到成长，看不到方向。

自动化测试的重要性显而易见，但自动化测试又没法解决全部问题，因此说彻底依赖自动化是不可能的，但彻底没有自动化是万万不能。在软件开发项目中，重度依赖人力进行持续回归是一件很是枯燥的重复工做。企业须要花费大量的时间和金钱来维持这样一支队伍以保证产品质量，而队伍中的同窗在天天重复劳动的工做之下，也丝毫得不到成长，看不到方向。

尽管自动化测试不能解决全部问题，可是却拥有一个优点：“Once” Written, Run Anytime as Desired（一旦写好，便可随意重复执行）。因此，自动化测试一般都会跟持续集成系统（好比Jenkins）配合使用，就像“良辰美景”要配上“月光杯”才算的上是极致。这样咱们能够避免在软件上线或交付的最后一刻，还深陷软件问题的泥潭中。固然，这也是敏捷开发的关键所在，把问题消灭在过程当中，只需持续关注增量内容。另外，在持续集成中，能够根据本身的需求来肯定自动化测试的触发频次和时间，好比“代码提交”、“定时触发”等。

万物皆有阴阳两面，自动化测试有这么多优点，固然也有它的劣势。因此，至今仍然有不少公司自动化水平不高。咱们分析一下这些劣势，主要有如下几方面：
　　1.对测试人员要求相对较高。
　　2.测试用例须要根据版本迭代进行更新，有必定维护成本。
　　3.测试结果不必定可靠，测试用例也分“好”、“坏”。

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

1、测试用例也分好坏

　　
对于标题，你可能会有疑问，测试用例居然也有好坏？的确，测试用例也有好坏之分，那么什么是坏用例？什么是好用例？那要先从测试用例的特征提及：

自动化测试或者测试用例的根本目的就是judge（判断）被测系统是否有问题，是以衡量被测产品的“标尺”存在的。因此，它具有一个重要的特征：在测试脚本和被测代码都保持不变的状况下，测试结果应该是稳定的、不变的。

根据这个原则，“坏用例”并非指测试不经过的用例，更不是测试经过的用例，而是指那些在相同条件下，偶尔经过、偶尔不经过的测试用例。反之，“好用例”则是表现稳定的用例。
　　
为何说“坏用例”破坏性大？由于若是用例自己不具有稳定的结果输出，就没法准确的衡量被测产品是代码的问题仍是用例自己的问题。若是每次测试结果都不能直接说明问题，须要进行反复分析，将直接致使你们对测试用例失去信心。也就是说，测试同窗和开发同窗会把测试用例的不经过，当成“Warning”而非“Error”,这样的最终效果就是自动化测试慢慢被抛弃。

2、测试用例的生命周期

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

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

3、 如何消灭坏用例

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

1，经过“CI”（Continuous Integration持续集成）发现“坏用例”

“坏用例”指的是偶尔不经过、偶尔经过的用例。因此，你会发如今本地运行的时候很难发现“坏用例”，由于“坏用例”须要被执行不少次才能被检测出来。执行不少次的过程能够很是好地经过CI系统来帮助实现，因此，若是你尚未使用CI系统，也依然建议使用持续集成工具进行屡次的执行用例，即使你的工程量很小。另一点，CI系统能够在一天不一样的时刻执行用例，而时间也是一个“坏用例”产生的可能属性。

固然，成熟的CI系统（好比Jenkins）均可以知足绝大部分人的业务需求

2，防微杜渐

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

3，避免执行环境差别

4，使用异步等待　　

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

5，解决并行执行的问题　　

若是测试用例存在并行执行的状况，请确保多个测试用例之间不会由于相互对被测系统的影响致使冲突，从而使用例变成“坏用例”。好比，在全部测试用例执行过程当中，数据库相关操做都采起事务的方式，用例执行完成后，就当即进行回滚。

6，避免测试用例互相依赖　　

若是一个用例集中的测试用例时相互依赖的，那若是其中有一个“坏用例”出现，将会致使整个用例集不稳定。因此，尽可能保证用例集中的每个用例没有相互依赖关系，每个均可以独立执行验证。

7，避免测试脚本太长　　

毫无疑问，一个测试用例的步骤越多，可能变成“坏用例”的几率越高，因此，通常状况下，一个App的测试用例不超过在30步最好。

8，提升测试用例代码水平　　

一个“好用例”除告终果足够稳定以外，还须要具有良好的结构设计，以及良好的可读性、可维护性。这一点对测试用例编写人员要求较高，固然，经过多读、多思、多写，可以很快的提升本身的自动化用例编写能力。

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

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