添加客服微信
400 035 7887
021-60725088-8054
泽众云测试 - 新闻动态 - AR365自动化测试 - 正文
随时开始测试以在云中运行 - 无论您位于世界何处。当苹果和谷歌发布新的浏览器版本时,升级云服务器并无缝启动测试。不再让测试人员消失在会议室里,然后在三四天内出来,宣称“可能没问题”。
一旦测试脚本存在,只需按一下按钮,就可以在不同的外形和设备上重新运行它。就此而言,如果您将测试组装为组件或构建块,则可以在其他测试中重用这些组件。这意味着只写登录一次,然后重复使用它。当您的应用程序为“客户类型”(个人或企业)添加新的下拉菜单时,您可以在一个地方更改登录功能,然后突然所有测试再次通过。人工测试脚本越详细,它们要么过时,要么需要昂贵的维护工作才能保持在新状态。
过去,通过自动化运行意味着软件可以运行至少一个特定场景。计算机在意识到更改使屏幕“看起来很有趣”或造成可用性问题方面非常糟糕。在坏的情况下,整个表单域可能会被隐藏或锁定以防止接收击键,但自动化仍然可以找到一种输入方式。在这些情况下,通过测试甚至不能保证可以通过场景!
现代测试自动化工具不仅可以播放失败的视频,甚至可以播放通过的测试运行。以 2 倍或更快的速度查看这些逐个游戏,可以结合人的力量来发现问题与计算机一遍又一遍地做完全相同的事情的能力。拥有故障视频可以将调试时间从几小时缩短到几秒钟。
一旦您创建了一个可以在 iOS 平台上运行的测试,您就可以从数千种设备、操作系统和浏览器的组合中扩展它。Android 分散的生态系统提供了数十万种选择。如果应用程序是也可以在笔记本电脑上运行的直接 Web 应用程序,则有数百万种组合。您没有一次运行所有这些。对每个提交进行单独的测试运行,您可能每天运行十几个。创建一百个受欢迎的组合列表,并在测试运行中轮换,免费实现合理的平台覆盖。或者选择十个重要的测试,并在一夜之间在一百台设备上运行它们,成本不会更高。更好的是,
云,加上测试的可重复性,意味着您可以同时在多个平台上运行完全相同的测试,寻找细微的差异。这可以提供对编程实践甚至性能的洞察。考虑一下与新版本相比,在旧 iPhone 上测试运行的已知时间以及平均页面响应的差异。
很有可能同时工作的两个开发人员引入破坏软件的更改——或者引入破坏软件的合并问题。这严重坏了;“无法登录”坏了。人类测试人员在引入问题几个小时后发现问题,并被告知“不应该发生”,或者等待新的构建。下一个工作日,测试人员就失败与开发人员联系,他们说它“在开发环境中有效”,或者可能会拖累操作。终于在第四天,问题解决了。
如果你的经历比这更好,那么你比大多数人更幸运。或者,也许,中断登录很少见,但在测试中发现问题很常见,或者至少是更改的意外后果。
在每个构建上运行回归测试套件可以及早发现问题,确定导致问题的更改,并将问题直接指向创建它的开发人员。这可以防止浪费、延迟、相互指责,并大大减少调试和修复所花费的时间。
大多数领导人类测试的团队都有一个“回归测试”,或“发布前的检查”测试周期。这个周期很贵;可能需要一周时间。测试周期长,很难经常出货。多年来,我曾两次与团队合作,将月度发布转变为季度发布,以此作为“流程改进”的一种形式。
转向不那么频繁的发布允许团队花费更少的时间来编写新代码。但是,回归时间的变化量会更大,这将需要更多的回归测试周期来发布。这些更多的周期使测试看起来更昂贵,从而导致减少发货的压力。从经济角度来说,这是一个恶性循环。
工具可以彻底改变这些数字。结合软件工程中的现代策略,例如多个部署点、弹性和快速恢复时间,团队可以创建一个良性循环,其中更频繁的部署会导致部署的更改更少,所需的测试更少,并更快地为客户创造价值。
一旦存在“只读”测试脚本,您就可以翻转它并使用它来监控生产。添加更改,您可以找出功能何时出现故障,或者是否在几秒钟内错误地应用了配置标志。添加时间以获得生产的性能监控——真正的、端到端的、实际客户体验的性能监控——大约是一个繁忙的午餐时间的成本。同样,当页面加载超过合理阈值时添加警报以立即查找和修复问题。
随着应用程序的老化,它往往会增加逻辑和数据库大小,并且性能会随着时间的推移而下降。添加时间以注意到性能差异并不需要太多。这意味着您甚至可以在客户出现问题之前识别出趋向于出现问题性能的功能!
同样,从模拟用户的独立测试的测试套件开始。然后大规模同时运行它们以深入了解性能。这里的见解有两个方面。首先,您可以查看您为上面的生产监控编写的性能计数器。或者,让人类在类似负载下的生产环境中探索功能。
如果团队在每个 sprint 中添加新代码,那么每个 sprint 中测试“覆盖”的“空间”都会增加。使用自动化工具,这项工作相对简单:编写一个故事,编写一些测试。通过人工测试,覆盖的空间量呈线性增长。在一个冲刺中,测试 10 个故事,在第二个冲刺中,测试 20 个,在第三个冲刺中,测试 30 个。测试要么需要变得更加先进,随机抽样,否则测试时间需要增加。
做得好,测试工具会随着时间的推移降低测试成本。
好的工具采用用户可能做的一些小子集——频繁或重要的操作——并将它们制度化,一遍又一遍地运行,完全相同。试图涵盖所有可能的用途和组合是愚蠢的差事。这为小错误留下了足够的空间,也为让客户感到烦恼的事情留下了空间。请记住,计算机正在测试是否符合规范;规范总是有可能是错误的,或者是过时的。大多数公司使用自动化测试来发现简单、频繁、核心操作中的错误,例如登录应用程序、创建新帐户或在忘记密码时发送电子邮件。这就是自动化测试所做的。
特定场景下的 App 崩溃仍需手动测试。众所周知,机器非常先进,但“真正的”人工智能的应用有限且昂贵,至少目前如此。
自动化测试不会做的另一件事是测试设计的有效可用性,例如按钮的位置,以及实际使用应用程序的难易程度。这仍然必须通过手动用户友好测试来完成。
总之,自动化和手动测试各有利弊。有些人会争辩说这种区分是有帮助的,因为大量的手工工作是由计算机辅助的。泽众软件认为,由计算机进行的独立测试执行和评估与人类坐在驾驶座时不同,应该区别对待。这篇文章的目的是为了展示 。
为了获得不错的结果,您需要结合使用这两种类型:针对重复、简单用例的自动化测试;以及用于重现特定错误、复杂用例并确保不错的用户体验的手动测试。
推荐阅读:
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-60725088-8054),我们将立即处理,马上删除。