济南网站建设行知科技不错a,广州铁路投资建设集团网站,最近的新闻热点,云霄网站建设摘要#xff1a; 自动化测试的重要性显而易见#xff0c;但自动化测试又无法解决所有问题#xff0c;所以说完全依赖自动化是不可能的#xff0c;但完全没有自动化是万万不能。在软件开发项目中#xff0c;重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费…摘要 自动化测试的重要性显而易见但自动化测试又无法解决所有问题所以说完全依赖自动化是不可能的但完全没有自动化是万万不能。在软件开发项目中重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量而队伍中的同学在每天重复劳动的工作之下也丝毫得不到成长看不到方向。
自动化测试的重要性显而易见但自动化测试又无法解决所有问题所以说完全依赖自动化是不可能的但完全没有自动化是万万不能。在软件开发项目中重度依赖人力进行持续回归是一件非常枯燥的重复工作。企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量而队伍中的同学在每天重复劳动的工作之下也丝毫得不到成长看不到方向。
尽管自动化测试不能解决所有问题但是却拥有一个优势“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使用异步等待
通常一个测试用例多个测试步骤组合而成每一个测试步骤都需要特定的执行时间所以大家写测试用例一般的做法就是等待特定的时长比如5秒。但是相同的测试步骤在每次用例执行过程中的时长并不相同并且有时差异还会很大。这往往会导致上一步还未完成下一步就开始执行导致“坏用例”的产生。 另外即便是步骤执行没有超时但依然可能造成时间上的浪费比如一个步骤等待5s但实际执行只用了2s就有3s的时间浪费。 理论上解决这个问题有两种方式回调、轮询。回调是指上一步执行完成后通知执行测试用例的进程/线程继续下一步。但这种方式在实际中并不采用因为它需要紧耦合被测系统可能为被测系统带来新的问题和维护成本。所以实际中更多的采用的是以“观察者”身份存在的轮询。比如说以很小的时间间隔来不断查询是否到达下一步执行的状态。这样就能够避免一定程度的“坏用例”的产生。
5解决并行执行的问题
如果测试用例存在并行执行的情况请确保多个测试用例之间不会因为相互对被测系统的影响导致冲突从而使用例变成“坏用例”。比如在所有测试用例执行过程中数据库相关操作都采取事务的方式用例执行完成后就立即进行回滚。
6避免测试用例互相依赖
如果一个用例集中的测试用例时相互依赖的那如果其中有一个“坏用例”出现将会导致整个用例集不稳定。所以尽量保证用例集中的每一个用例没有相互依赖关系每一个都可以独立执行验证。
7避免测试脚本太长
毫无疑问一个测试用例的步骤越多可能变成“坏用例”的概率越高所以一般情况下一个App的测试用例不超过在30步最好。
8提高测试用例代码水平
一个“好用例”除了结果足够稳定之外还需要具备良好的结构设计以及良好的可读性、可维护性。这一点对测试用例编写人员要求较高当然通过多读、多思、多写能够很快的提高自己的自动化用例编写能力。
四、 MQC让测试用例“转”起来
“坏用例”的产生跟被测应用、编写方法、测试环境等都有非常大的关系很难找到一个“all in one”的解决方案。但是只要我们认真分析解决就可以让所有测试用例达到都是“好用例”这个状态。接下来需要做的就是大家共同维护好这样一个最佳状态避免“破窗理论”的发生。 在解决“坏用例”这个问题上阿里云测MQC提出并实施了众多有效方案例如对于未通过的用例增加N次重跑避免“坏用例”的产生比如“在线录制”可以帮助用户短时间内获得稳定性和兼容性都很高的测试用例比如“用例管理”可以跟踪所有测试用例的通过率及通过次数及早发现和处置“坏用例”再比如阿里云测MQC还提供了“Jenkins插件让大家无需关心硬件资源等问题方便大家将MQC云上的服务添加到自己的持续集成流程中来真正做到“Once Written, Run Anytime”。这也是为什么只有在MQC平台上测试用例才能真正“流转”起来。
