移动测试基础 初谈自动化测试

hzhuangchong · 发布于 2016年11月19日 · 最后由 pepper 回复于 2016年12月04日 · 最后更新自管理员 Lihuazhang · 1730 次阅读

测试同学应该清楚,测试可以分为手工测试和自动化测试。按照经验和目前的测试理论,自动化测试还无法完全代替手工测试,但是可以代替稳定模块的回归测试。

自动化测试容易依赖模块的稳定度,随着版本迭代,旧版本的自动化用例可能会失效,这增加了自动化测试维护的工作量,也逐渐打击了自动化测试开发者的积极性。导致有些团队放弃自动化测试,甚至有些团队根本没考虑引入自动化。但是,随着项目越来越大,如果不逐渐积累自动化用例,回归时需要的人力需求就会逐渐增多,如果又不愿意拉长项目周期,就会造成测试不完全,埋下bug,诱发线上事故。

什么样的项目/模块适合引入自动化?

1.功能较稳定

功能稳定是必须的,极端一点,如果这个功能下个版本说不定都会被砍掉,那实在是犯不着做自动化。稍微不那么极端一点,功能会经常迭代/优化,对于测试脚本的影响,体现在接口变化、参数变化、UI变化。较小的变化,简单维护还可以接受。如果大量的变化,每个大版本都要花很多时间维护,那就要考虑是否值得做自动化。

2.测试开发人员的安排

一个测试组的分工,可以有按职责分,测试负责人,测试人员,测试开发人员;也可以按模块分,测试模块A,模块B的;可以按端分,测试iOS的,测试安卓的。当然这些分工标准也可以是混合的。见过一些项目组,只按模块分,模块A的QA要测试这个模块各端的表现;也有些项目组,比如我们,是按端+模块分,首先分iOS和安卓组,然后再按模块分;也听说一些项目组,会独立拿出一部分人员做自动化,当然这部分人要先熟悉业务。如果你不是专职做自动化的,那就说明你要兼顾版本测试以及自动化测试。这种情况下,版本测试的重要性会远远大于自动化,自动化任务就要安排在版本间隙,比如提测前,你写完了测试用例,完成了用例评审、需求确认等项目工作,你才会去完成下自动化的工作。当然如果排期合理,不变态紧凑,那还是可以有时间去完成的,而且在回归过程中,可以跑自动化,来验证你的测试代码。

我的自动化测试实践主要是应用于回归,除此之外,还应用于,比如打包、或是一些测试流程。初心,也是这些操作繁琐、稳定、可以实现,因而实现了自动化。完成之后,确实大大提高了效率,时间和经历上都得到了节约。

今天就谈这么多,如果你是新手,其实只要你有兴趣,都可以尝试。如果你是老鸟,其实只要对于功能稳定的模块都可以考虑是否有实现的可能和必要,相信有还是比没有强。

第一天写文章,希望对大家有帮助。

共收到 12 条回复
96

大神们,自动化除了ui,还能测哪些方面?接口?

—— 来自TesterHome官方 安卓客户端

96

#1楼 @caihan 兼容也可以测

2835

#1楼 @caihan 嗯,如果你指的客户端,做UI自动化的确实多,不过从接口层去做测试也是可以考虑的,但是会对测试开发人员要求更高,而且无法去测试ui的bug。还有的话,非主业务逻辑的,比如一些小工具的开发。

12883

恩 说的比较中肯啊,自动化必须计算ROI的,不管ROI的自动化很容易得不偿失

12800

接口和ui方面切入自动化更合理些,因为业务逻辑很容易随着产品需求变革,维护起来麻烦

609

#5楼 @cqtest 请问下ROI要怎么算呢?

2835

#5楼 @cqtest 嗯,你说的roi,有什么判断标准吗?

9楼 已删除
12882

目前就我一个人,主要是手工测试。公司目前有 PC(重构中) 、微信(维护)、 IOS(开发中)、 Android(开发中)端,如何解放双手?本人会一些java 、nodejs;了解一点appium 、webdriver,但是会基本,没具体实践过,求指点,如何从0到1.

12882

#10楼 @houzideyeye 为何被删除 有啥不妥吗?

9320

MRchong!!哈哈

96

刚开始学习 新手

2835 hzhuangchong 关闭了讨论 05月03日 17:02
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册