我最近在学习大话移动测试Appium部分,已经搭建好环境并且可以写简单的测试用例,但是不知道如何有效的用在工作中,工作中客户端测试还是手工测试,我想问一下您们在工作中自动化测试主要用在什么地方,怎么做的,谢谢
最近加我微信问Appium相关问题的同学有点多,说实在写完Appium那一章,我就鲜少接触Appium,我的工作中也基本用不到Appium,加上很多人加上微信招呼也不打,就直接抛一个大问题。我遇到这样的,脑袋就端的一下,然后拒绝回答。
但是今天这位同学的问题比较有代表性,加之他也比较礼貌,所以我就凭自己的经验来试着回答这个问题,有不对的地方请指正。
我把这位同学的问题拆成三个:
- 如何把一个工具有效地运用在工作中?
- 客户端测试中,手动测试和自动化测试怎么配比?
- 自动化测试主要用在哪些方面?
如何把一个工具有效地运用在工作中?
这个问题很大,我就拿Appium举例子。从选择工具开始,很多人手机里一堆app,真正用的没几个。UI自动化测试工具很多,如果不能很好的评估,对工具的研究反而会占去大量的时间,目前很多玩Appium的同学,花了大把时间在环境部署或者如何真机运行Appium上,反而到了真正要用Appium来写业务自动化时候,摸不到方向。
写移动应用自动化,目前Appium的确是较好的选择,Macaca也是不错的选择。但是这两个工具的学习成本都相当高。这也是移动互联网测试的一个特点,就是学习成本,想要在当下移动互联网环境下做好测试工作,对于移动应用的各种特性都要了如指掌,尤其是移动自动化,你需要清楚它背后运转的原理,才能更好运用工具。但是即便如此,我们依然不能把调研工具的工作作为大头,真正重要的是使用工具去辅助或者完成业务。
所以反过来,从业务出发,理清楚,哪些业务可以通过哪些工具完成哪些业务场景?你不能说我选了Appium,所以我想做UI自动化,而应该是我想使用自动化来覆盖一些稳定的业务场景,以此来缓解回归压力。然后再去考虑选择Appium还是Macaca,当然还要权衡自己的能力,比如你擅长Java,那么选择Java client,如果你擅长nodejs,那么Macaca是不错的方案。
选择了一个工具或者一个方案之后,就要避重就轻,别想着把Appium吃透,而是想着用Appium把业务自动化测试玩转。你也许会担心,这样对自动化不够理解,别担心,你在写自动化测试的时候,会反推这些东西的。比如,你觉得串行跑用例慢,你就会想到搭建grid,你发现Appium Server不稳定,你就会想办法加心跳,检测服务是否live,以便随时唤醒。总之,在业务场景中运用技术,会让技术更加接地气,也更加有成就感。
客户端测试中,手动测试和自动化测试怎么配比?
老实说,如果一个app全是自动化测试跑出来的,我敢保证质量肯定不高。首先需要明确一点,一个经过完整的需求宣讲,系分,测分,几轮手动测试出来的应用质量都不一定高到哪里去。
软件测试工作中,尤其是业务导向的软件,估计在未来很长一段时间内还将是手动为主,自动化为辅。这句话也许是错的,但是我敢说错的是手动为主,也许未来开发水平高到,写出来的app可以直接达到上线的标准,然后通过在线监控来反推app质量,或者其他的手段,但是自动化依然还会使辅助。想想看,我们生活中的自动化工具,什么时候反客为主了?
所以在客户端测试中,还是采用手动测试并没有什么问题。问题在于我们是否能利用自动化测试用户来减少手动测试的压力?比如容易穷举的代码分支用单元测试覆盖,稳定的接口用接口测试覆盖,客户端老版本,不变的路径,用ui自动化覆盖。这些才是应该花精力的地方。所以没有什么配比好坏的说法,别人公司的经验值在你公司也许就是shit。如果你的app一天一个样,你做什么自动化都是白瞎。
自动化测试主要用在哪些方面?
见上。同时在补充一点,自动化并不只有测试。当你做一件同质的事情做多了而且有些厌烦了,你就可以考虑使用下自动化了。不需要全自动化,半自动化足够了。