前言
人们对测试工作的重视以及测试工作的不断深入,越来越多的公司开始使用自动化测试工具。如果能够正确地选择和使用自动化测试工具,就会提高测试的效率和测试质量,降低测试成本。
需求频繁变动会增加自动化测试的维护成本,因为自动化测试维护本身就是一个修改、调试的过程。因而,对相对稳定的模块可进行自动化测试,而变动较大的用手工测试。
自动化测试将手工测试繁琐重复的操作步骤以自动化的方式完成,节约手工测试时间,其关键在于脚本的复用性。
自动化测试实践并不容易,许多人将其视为实际结果与需求中提供的预期结果的比较,甚至认为自动化测试就是一系列重复和可重复的操作。如果仅仅停留在这些肤浅的理解往往会导致自动化测试的失败。
需要关注的主要因素:工具和技术、需求和风险、维护和安全。
一、工具和技术
软件测试发展至今,市面上已经有很多商业、免费和开源的测试工具。选择哪种工具取决于对产品当前形态的支持程度以及对产品未来演进持续的支持程度。
除了使用现成的自动化工具,也可以选择自研测试工具。而使用哪种技术实现自动化工具就至关重要。例如,Selenium的早期版本还不支持处理浏览器弹出窗口和自定义控件。HP QTP力求支持尽可能多的 UI 操作,这使得该工具使用起来非常笨重且速度缓慢。
购买工具测试经理必须考虑预算。而开发测试工具是一项需要等待回报的时间投资。无论采取何种方法,工具和技术都会对你的自动化项目产生持久的影响。
二、需求和风险
业务需求永远不会以完全确定性和完全特定的形式出现。模糊的需求仍然是完全可测试的,老练的测试人员将探索和经验用于业务测试,但自动化测试就显得那么捉襟见肘了。
不同的团队以不同的方式应对这一挑战。有些团队鼓励结对编程,开发与测试来定义这些原子的、细化的步骤和要求。而一些团队倾向招聘全栈员工,例如掌握测试思维的程序员。
至于风险,我们已经看到,就其本质而言,自动化测试从根本上限制了测试人员的探索能力。自动化脚本一旦创建就可以运行数千次,但它运行的仍然是相同的场景。与老练的测试人员探索测试相比,这大大降低了测试的范围和质量。
需求不够详细或需求频繁变化是测试人员经常头疼的问题,它也是自动化的一个风险。即由于需求不稳定,脚本将需要无休止地维护。
三、维护
我们只需要维护好300个主流程自动化测试脚本,不需要创建任何新的自动化脚本。可能吗?
创建自动化脚本并不困难。
事实上,许多工具中提供的录制回放功能使得脚本的创建相当简单。这些脚本起初可能很有用。
但随后需求更新,UI 变更,接口API 参数改变,数据变得不再适用,维护脚本的噩梦就来了。
在自动化测试中,维护问题经常被忽视,但它是区分自动化成功与失败的关键因素。
维护包括调试和测试。然后是输入数据和预期结果的更新,并与被测应用程序保持最新的交互点,无论是 API 还是 UI。
例如,在 UI 自动化中,更新 UI 控件的描述是维护的重要部分。
所有这些加在一起的时间和精力成本通常与开发自动化的初始成本相当或更甚。而且,当迫切需要测试结果时,根本没有足够的时间来调试脚本。
不同的团队以不同的方式应对维护自动化脚本的挑战。
有些人喜欢先检查被测应用,以找出可能导致自动化脚本失败的问题。这带来了自动化维护悖论:如果你测试了应用程序,那么修复自动化脚本的意义何在?
四、安全
现在大多数应用程序有登录功能,自动化脚本的实现通常需要将用户鉴权凭据保存在本文件中,甚至是一些访问预生产和生产环境的账户,而这存在极大的安全隐患。
工具和技术、需求和风险、维护和安全为自动化提供了一个思考框架,这些因素可以应用于规划阶段或作为现有自动化的评估。
自动化是一种测试服务一种可能被证明有用的测试实践,旨在不引入风险的情况下提升你的软件测试效率。
五、总结
严于自律:不能成为自己本身之主人者,将永远成不了他周围任何事物的主人。自律是完全拥有自己的内心并将其导向他所希望的目标的惟一正确的途径。
我习惯了不该习惯的习惯,却执着着不该执着的执着。有时候,在乎得太多,对自己而言也是一种折磨。
梦虽虚幻,却是自己的梦想;位虽低微,却是自己的岗位;屋虽简陋,却是自己的家;志虽渺小,却是自己的追求。