移动互联软件测试-2017 自动化测试 自动化测试之“好用例、坏用例”.docxVIP

自动化测试之“好用例、坏用例” 　　 自动化测试的重要性显而易见，但自动化测试又无法解决所有问题，所以说完全依赖自动化是不可能的，但完全没有自动化是万万不能。在 软件开发项目中，重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量，而队伍中的同学在每天重复劳动的工作之下，也丝毫得不到成长，看不到方向。 　　尽管自动化测试不能解决所有问题，但是却拥有一个优势：“Once” Written, Run Anytime as Desired（一旦写好，即可随意重复执行）。所以，自动化测试通常都会跟持续集成系统（比如Jenkins）配合使用，就像“良辰美景”要配上“月光杯”才算的上是极致。这样我们可以避免在软件上线或交付的最后一刻，还深陷软件问题的泥潭中。当然，这也是敏捷开发的关键所在，把问题消灭在过程中，只需持续关注增量内容。另外，在持续集成中，可以根据自己的需求来确定自动化测试的触发频次和时间，比如“代码提交”、“定时触发”等。 　　万物皆有阴阳两面，自动化测试有这么多优势，当然也有它的劣势。所以，至今仍然有很多公司自动化水平不高。我们分析一下这些劣势，主要有以下几方面： 　　1.对测试人员要求相对较高。 　　2.测试用例需要根据版本迭代进行更新，有一定维护成本。 　　3.测试结果不一定可靠， 测试用例也分“好”、“坏”。 　　前面两点也是大家公知的问题，每个公司各有自己的情况判断，今天也不做赘述。今天我主要讨论第三个问题，也就是：怎么保证我们花了时间和精力去做的自动化测试，其结果是有效的、是能够反映被测代码质量的？ 　　一、测试用例也分好坏 　　对于标题，你可能会有疑问，测试用例竟然也有好坏？的确，测试用例也有好坏之分，那么什么是坏用例？什么是好用例？那要先从测试用例的特征说起： 　　自动化测试或者测试用例的根本目的就是judge（判断）被测系统是否有问题，是以衡量被测产品的“标尺”存在的。所以，它具备一个重要的特征：在测试脚本和被测代码都保持不变的情况下，测试结果应该是稳定的、不变的。 　　根据这个原则，“坏用例”并不是指测试不通过的用例，更不是测试通过的用例，而是指那些在相同条件下，偶尔通过、偶尔不通过的测试用例。反之，“好用例”则是表现稳定的用例。 　　为什么说“坏用例”破坏性大？因为如果用例本身不具备稳定的结果输出，就无法准确的衡量被测产品是代码的问题还是用例本身的问题。如果每次测试结果都不能直接说明问题，需要进行反复分析，将直接导致大家对测试用例失去信心。也就是说，测试同学和开发同学会把测试用例的不通过，当成“Warning”而非“Error”,这样的最终效果就是自动化测试慢慢被抛弃。 　　 二、测试用例的生命周期 　　有了“好用例”、“坏用例”的区分，测试用例就是“鲜活”的了。事实上，我们也可以规划处一个测试用例从生到死的生命周期。 　　一般情况下，我们可以以测试用例通过率或通过次数来为其划分“好/坏”。随着执行次数的增多，测试用例可以切换“好/坏”状态，当“坏用例”持续一段时间之后，我们可以把它标记为“垃圾用例”，并从自动化执行的序列中剔除。“坏用例”和“垃圾用例”可以被开发或者测试同学修复，然后进入“未知状态”。“未知状态”中的应用随着执行次数的增加，不断的在这个生命周期里循环往复。 　　 三、 如何消灭坏用例 　　至此，我们明白了测试用例的“好/坏”之分，也了解了测试用例的生命周期。 　　那么，我们如何保证用例质量，“消灭坏用例”呢？ 　　1，通过“CI”（Continuous Integration持续集成）发现“坏用例” 　　“坏用例”指的是偶尔不通过、偶尔通过的用例。所以，你会发现在本地运行的时候很难发现“坏用例”，因为“坏用例”需要被执行很多次才能被检测出来。执行很多次的过程可以非常好地通过CI系统来帮助实现，所以，如果你还没有使用CI系统，也依然建议使用持续集成工具进行多次的执行用例，即便你的工程量很小。另外一点，CI系统可以在一天不同的时刻执行用例，而时间也是一个“坏用例”产生的可能属性。 　　当然，成熟的CI系统（比如Jenkins）都可以满足绝大部分人的业务需求 　　2，防微杜渐 　　可能大家都听过“破窗理论”：当房子上的一扇窗户的玻璃被打破，如果不及时修复，将会有破坏者破坏更多的窗户。“坏用例”现象也是一样的，当出现一个“坏用例”时，如果不抓紧修复，整个测试用例集甚至自动化测试结果的可信度都将快速下滑。 　　对“坏用例”采取零容忍的态度，有助于整体自动化水平和质量的提升。可以建立测试或开发人员“坏用例”档案，并自动追踪每一个“坏用例”的来源，督促负责人跟进解决。 　　3，避免执行环境差异 　　4，使用异步等待