解放你的双手—iOS自动测试基础

每一个测试人员都有一颗要做自动化测试的心,这不仅仅是因为自动化测试能在一定程度上提高测试效率,还在于这是测试人员自我价值的一个较好的体现,似乎不做自动测试都不好意思跟人说自己是测试人员了。

1 软件自动化测试简介

自动化测试是用机器来替代人工执行测试的一种测试思想,以程序测试程序的一种测试方式。

自动化测试特别适用于重复度很高的测试场景。他通常是手工测试一种补充,而不能完全替代手工测试。但相对于手工测试,自动化测试有其独有的一些优势:

(1)测试更快速、高效

(2)可执行一些手工测试无法覆盖的测试

(3)更好得利用资源

(4)测试具有一致性

但是也有很明显的缺点,比如:

(1)无法完全全保证测试的正确性

(2)开发、维护成本过高,风险大

(3)不能替代手工测试

(4)无主观能动性

那既然这样,什么时候做、针对于什么功能模块去做自动测试,就是测试人员的一个大考验,在做自动测试之前,一定得充分分析被测试产品以及自动测试的实现难度,不然很难达到提高测试效率的目的,甚至可能会给产品带来不必要风险。我们一般会选择项目周期长、需求变更不频繁、需要反复测试的功能模块来进行自动化测试的考量。

自动测试通常可以分为白盒测试、黑盒测试、灰盒测试。

白盒测试是直接针对代码的测试,对于类、对象、函数、变量等的语法规则和逻辑作具体分析,保证每一条逻辑路径尽可能被执行,发现隐藏在代码中的错误,是白盒测试所需要做的事情。但很显然,这类测试的代价非常高,同时,对于代码中本身就缺失的路径,他是无法检测到的。通常一些训练有素的开发人员会在编码的过程中执行白盒测试,而测试人员一般不直接做这类测试。白盒测试也不作为重点讨论的对象。

黑盒测试指模拟测试人员的动作,以达到类似手工测试的效果。这个也是大部分测试人员最常使用的一种方式,简单易上手,对于一些特定的场景,能大大得提高测试效率。这个是我们文章后续要讨论的重点。

灰盒测试,是介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

2 iOS测试工具简介

测试工具通常已经为我们做好了那些烦锁的准备工作,可能很快速得上手到真正对测试有意义的工作中。iOS上有哪些已有的工具可以供我们选择呢?我们先来认识一下:

这里列举一下几个最常用的。

2.1 UITest

UITest是XCode上自带的UI自动化测试框架,是苹果官方大力推荐的新兴测试框架,后续也是会持续得跟进和优化,有苹果作为强大的后盾,这个框架想必也差不到哪里去,来认识一下他吧:

优点:

(1) 具有录制回放功能,能够快速上手

(2) 配置方便快速

(3) 测试运行速度很快

(4) 测试代码可调试

(5) 苹果官方主推的测试框架

(6) 支持UIWebview

(7) 每一部操作,框架都会自己截图一张,以便于结果的验证,而且几乎不占资源

缺点:

(1) 需要源码

(2) 无法脱机跑,需要连着Mac机器

(3) 框架本身不是很稳定,录制时可能会引起XCode的crash

适用场景:

(1) 开发过程中快速验证某一功能。

(2) 大规模的UI自动测试

2.2 UI Automation

UIAutomation是XCode自带的UI自动化测试工具,支持录制回放功能,支持javascript编辑脚本,能够在真机和模拟器上面执行自动化测试。由于是开发工具里集成的测试框架,使用的人自然不少,同时,UI Automation是iOS端很多其他测试框架的基础。

优点:

(1)具有录制回放功能,能够快速上手

(2)无须任何配置,使用方便

(3)测试脚本与程序代码独立,同时也和框架独立

(4)框架本身相对较稳定

(5)支持重要控件UIWebView

(6)有UI界面,也可以直接从命令行启动测试

(7)测试结果中可以包含代码覆盖率的结果

缺点:

(1)不支持自定义控件

(2)需要在开发者签名的包才能使用

(3)无法脱机跑,需要连着Mac机器

(4)JavaScript脚本语言,编写难度大

(5)UIWebView的状态不可访问

适用场景:

开发过程中快速验证某一功能。

测试脚本:

2.3 Appium

Appium是一个开源的、跨平台的自动化测试工具,适用于测试原生或混合型移动App 。Appium的核心是一个web服务器,他使用WebDriver json wire协议,来驱动系统的UIAutomation库。WebDriver Json wire协议的Server端采用node.js封装了iOS UI Automation的接口,提供提供出一套RESTFul web service的接口,这样Client端以HTTP请求获得操纵UI的能力。说到底,真正执行测试的还是 UIAutomation,Appium只是封装或解释了UIAutomation的执行脚本,作为UIAutomation和被测试APP的中间层传递消息。

优点:

(1)跨平台

(2)支持多种语言

(3)不依赖源代码

(4)开源

(5)测试脚本与程序代码独立,同时也和框架独立

(6)支持重要控件UIWebView

缺点:

(1)环境配置较繁琐

(2)不支持自定义控件

(3)UIWebView的状态不可访问

(4)无法脱机跑,需要连着Mac机器

适用场景:

多平台的应用测试或是web应用测试。

测试脚本:

2.4 KIF

KIF是一个开源的专为iOS设计的移动应用测试框架,使用Objective-C语言开发,能和应用的代码工程完美结合。它是使用私有API对UI界面进行操作的自动化测试框架,这种类型的测试框架已大行其道,非常受欢迎,KIF就是其中出色的一个,同时,KIF还继承了XCTest,很多大的软件公司比如Google都在用这个测试框架。

优点:

(1)继承XCTest,UI测试可以和白盒测试相结合

(2)适合做持续集成

(3)测试接口和方法很丰富

(4)支持iOS5.1以后的所有系统

(5)集成配置很简单

(6)开源

(7)单用例调试,编码调试轻松愉快

(8)可以脱机,执行测试只需要一部iOS设备

缺点:

(1)需要被测试工程源码

(2)对自定义的控件支持不好

(3)不支持UIWebView

(4)测试框架和被测试app在同一进程,测试框架的问题可能会影响被测试app

适用场景:

(1) 需要脱机运行测试的场景

(2) 较为复杂的UI测试或者是UI测试和白盒测试相结盒的测试

测试代码:

上面介绍了几种iOS端最常用的几种测试框架,各有各的特点,功能都不可谓不强大,选择某一种框架需要根据自身的项目实际情况,从测试需求出发。但框架选择只是所有工作的第一步而已,在对框架有了初步了解并作出选择以后,关于如何使用框架去实现自己想做的事才是整个事情的核心。下面我们就以上三个测试框架如何在实际工作中进行使用进行详细的说明。

3 UITest

UI Test集成很简,首先创建工程时,就默认是选择了包含UI测试。如果是已有的项目,直接新建一个iOS UI Testing的target即可。

3.1 脚本录制

UITest是可以通过录制来生成测试代码的,在以test开头的方法中(必须以test开头,框架才会认为这是个测试用例),点击录制即可:

再次点击时停止录制。

录制的脚本可读性很差,健壮性也不好,如果直接拿录制好的脚本去执行测试,通过率是很低的,所以还是得手动去作二次编辑的。不管是录制也好,手动编辑也好,都是可以选择用Objective C或者用Swift语言去实现的。

3.2 XCTest UITesting API

在我们开始录制动作之前,必须要决定需要断言什么内容。我们可以使用XCTest框架来对UI中的某些内容进行断言,现在框架中已经包含下面三个新API。

XCUIApplication。这是你正在测试的应用的代理。它能让你启动应用,这样你就能执行测试了。它每次都会新起一个进程,这会多花一些时间,但是能保证测试应用时的状态是干净的,这样你需要处理的变量就少了些。

XCUIElement。这是你正在测试的应用中UI元素的代理。每个元素都有类型和标识符,结合二者就能找到应用中的UI元素。所有的元素都会嵌套在代表你的应用的树中。对于每个元素,都可以对执行想要的操作,如

tap() :单击

twoFingerTap():两个手指单击

swipeUp():向上滑

pressForDuration:(NSTimeInterval)duration:长按一段时间

XCUIElementQuery。 当你想要找到某个元素时,就会用到 element query。每个 XCUIElement 里都包含一个query。这些query搜索XCUIElement 树, 必须要找到一个匹配的。否则当你视图访问该元素时,测试就会失败。 例外是exists属性,你可以使用这个属性来检查一个元素是否展示在树中。 这对于断言很有用。 更一般地你可以使用XCUIElementQuery 来找到对accessibility可见的元素。Query会返回结果的集合。

用label\key\text去访问一个控件:

XCUIApplication().buttons["Login"].tap()

用控件类型访问:

app.tableschildrenMatchingType:XCUIElementTypeCell]

用index访问

elementBoundByIndex:index

3.3 执行测试

可以在命令行执行:

xcodebuild-workspace /Users/ja/svn/MttBrowser_iPhone_Release1.0/mtt/mtt.xcworkspace -scheme mttlite -sdk iphonesimulator -destination'platform=iOS Simulator,name=iPhone 6s,OS=9.1' -derivedDataPath './output' test

但是请注意,这个一定要在iOS9.1以上系统才支持输出derivedDataPath,9以上系统才支持test命令。

4 UI Automation

由于是官方提供的自动化解决方案,又是一些其他测试框架的基础,我们就先了解他吧。

4.1 脚本录制

(1)将iPhone连接MAC电脑;

(2)打开Xcode5中的Instruments:Xcode --> Open DeveloperTool-Instruments;

(3)在Instruments界面选中Automation,然后点击Choose(或者双击Automation)进入Automation界面;

(4)在Automation界面choose Target选择iPhone5真机和该真机上待测的目标应用。(应用必须是从本机中build到真机中的debug版本,有开发者签名,否则无法使用Automation);

(5)创建测试脚本:在Scripts下的点击Add按钮,选择Create,即可自动创建automation测试脚本(即JavaScript脚本) 。

(6)录制脚本:点击下图中的红色按键,便可以开始录制脚本。

录制脚本虽然方便,但这种脚本是非常不健壮的,也没有结果的判断或是LOG的输出的部分。所以我们经常都还需要手动去编码。

4.2 获取控件

首先看看这个程序:

那么UIAutomation中有个接口logElementTree()能把这个APP的控件树给打印出来,如下:

UIATarget: 你可以把它理解成你的设备

想获得上图中的UIATarget:

UIATarget.localTarget();

想获得上图中的UIAWindow:

UIATarget.localTarget().frontMostApp().mainWindow();

以此类推,比如想获取如下图中的控件

可以这样:

UIATarget.localTarget().frontMostApp().mainWindow().tableViews()[0].cells()[0];

这时各位可能就会问了我不能老用顺序来找我需要的对象很多时候他的顺序是不定的。于是还有这样的方式:

UIATarget.localTarget().frontMostApp().mainWindow().tableViews()[0].cells()[0].elements()["ChocolateCake"];

可以通过element的name属性来找到它。每个element一共有4种属性:

(1)name: 控件的name和accessibility label一致(但如果没有设置accessibilitylabel的话,就无法访问了)

(2)value: 目前的值

(3)elements: 子节点们

(4)parent: 父节点

4.3 执行操作

(1)点击:appWindow.tabBar().buttons()["Unit Conversion"].tap();

也可以看坐标点来点:UIATarget.localTarget().tap({x:100, y:200});

(2)双击:UIATarget.localTarget().doubleTap({x:100, y:200});

(3)缩放:UIATarget.localTarget().pinchOpenFromToForDuration(({x:20,y:200}, {x:300, y:200}, 2);

UIATarget.localTarget().pinchCloseFromToForDuration(({x:20,y:200}, {x:300, y:200}, 2);

(4)滑动:

UIATarget.localTarget().dragFromToForDuration(({x:160,y:200}, {x:160, y:400}, 1);

UIATarget.localTarget().flickFromTo(({x:160,y:200}, {x:160, y:400});

(5)输入:

UIATarget.localTarget().frontMostApp().mainWindow().textFields()[0].setValue(recipeName);

4.4 验证机制

UI Automation预设元素的isValid()方法来判断是否成功(方法返回true or false).像这样:

if(cell.isValid()) {

UIALogger.logPass(testName);

}

else {

UIALogger.logFail(testName);

}

4.5 执行测试

(1)UI界面的方式,跟录制方式类似,Import进脚本后点执行测试即可。

(2)脚本运行的方式:instruments -t xxx.tracetemplate -w DeviceID appName -e UIASCRIPT testScript.js 其中-t 后面的参数为 Automation.tracetemplate 的路径,每个版本的位置都有所不同,在命令行下使用 instruments -s 命令进行查询

5 Appium

作为强大的跨平台的自动测试框架,appium一直是测试人员的重点研究对像。作为优秀的测试框架代表,我们有必要深入了解一下。

5.1 原理

Appium是由client和server组成,client提供多种语言的API,这些API是对WebDriver的扩展和封装,利用这些API就可以快速编写测试用例;client和server间通过符合Mobile JSON Wire Protocol的http请求进行交互。下面是Appium在iOS上的一个架构图:

上图左边为Appiumclient端,除手机外的部分为server端,client和server的通信是通过http进行的,所以不管用什么语言实现,只要client能发出符合协议的http请求就可以,这就是Appium支持多种语言的原因。又由于WebDriver已经够好的了,为了避免重复造轮子,Appium对WebDriver的API进行了扩展,WebDriver已经binding的语言都可以拿来用,省去了为每种语言开发一个client的工作量。

Appium的server部分主要功能是监听一个端口,接收由client发送来的http请求后进行翻译,调用苹果官方提供的UIAutomation库来进行模拟点击等操作,操作后移动设备把执行结果返回给server,server再把结果返回给client。图中的Instruments command server维护了一个command队列,Instruments command client从中取走命令并在iOS的instruments环境中的bootstrap.js中执行。

5.2 安装及配置

(1) brew安装。brew之于OS X如同apt之于Ubuntu。

(2) Node安装

brew installnode

(3) 安装Appium server

l installglobally

npm install-g appium

npm installwd

(4)安装Appium Client

安装 seleniumpython-client

下载 https://pypi.python.org/packages/source/s/selenium/selenium-2.42.1.tar.gz

pythonsetup.py install

安装 appiumpython-client

下载 https://github.com/appium/python-client/archive/master.zip

pythonsetup.py install

(5) 启动Appiumserver

~ appium

info: Welcome to Appium v1.1.0 (REV e433bbc31511f199287db7724e1ce692bcb32117) info: Appium REST http interface listener started on 0.0.0.0:4723 info: LogLevel: debug

5.3 获取控件

(1) 根据"class"定位

el =self.driver.find_elements_by_class_name('UIAButton')

(2)根据"xpath"定位

el =self.driver.find_element_by_xpath('//UIAMapView[1]')

(3)iOS uiautomation

sum =self.driver.find_element_by_ios_uiautomation('elements()[3]').text

(4)一个递归地、使用本地Accessibility的Name进行元素搜索的字符串

element =self.driver.find_element_by_name(“Test Gesture”)

同时,Appuim还提供一个第三文的工具Appium Inspector,以方便定位控件:

5.4 执行操作

(1)滑动屏幕

self.driver.execute_script("mobile:swipe", {"touchCount": 1 , "startX": x1,"startY": y1, "endX": x2, "endY": y2,"duration": 2})

(2)点击

self.driver.execute_script("mobile:tap", {"tapCount": 1, "touchCount": 1,"duration": during_time, "x": x1, "y": y1 }

(3)获取元素内容

element =self.driver.find_element_by_xpath(r"%s" % elementinfo)

Element.txt

(4)截图

screenshot =self.driver.get_screenshot_as_base64()

5.5 执行测试

在启动服务器后,执行测试脚本即可。但是测试脚本里要包含以下内容,作为Appium的初始化,告诉Appium要测试哪台机器上的哪个app,以及其他信息。

6 KIF

6.1 原理

KIF是继承XCTest的,所以KIF的测试执行方式和XCTest是一样的,可以单用例执行。

6.2 配置

(1)下载好KIF框架工程文件后,把KIF.xcodeproj文件拉进被测试工程里

(2)新建一个测试target,点“Add Target”,选择iOS -> Test -> iOS Unit Testing Bundle。

(3)对于这个target,把KIF里的静态库libKIF.a和系统的IOKit.framework和它关联

(4)对于这个target,在Build Settings中的Other Linker Flags选项加一个值-ObjC

(5)可以编写测试用例了,有两个重要的KIF测试类KIFTestCase(XCTestCase的子类)以及KIFUITestActor,看名字就知道哪个是做什么事的了。

6.3 执行操作

首先说明一下,KIF的UI控件操作和获取都是封装在一起的,每个接口里都包含了以什么属性获取控件,以及对这个控件执行什么操作两个部分。所以就没有获取控件这个部分的说明了。也因为这个原因,KIF的操作接口会非常的多,这里列举几个常用的。

(1)点击某个位置

tapScreenAtPoint:(CGPoint)screenPoint

(2)点击以label命名的控件

tapViewWithAccessibilityLabel:(NSString*)label

(3)长按以label命名的控件,时间长为duration

longPressViewWithAccessibilityLabel:(NSString*)labelduration:(NSTimeInterval)duration;

(4)在一个控件里输入一段字符

enterText:(NSString*)textintoViewWithAccessibilityLabel:(NSString *)label

(5)滑动某个控件

swipeViewWithAccessibilityLabel:(NSString*)labelinDirection:(KIFSwipeDirection)direction

6.4 验证机制

(1)UI层面

if(tryFindingViewWithAccessibilityLabel:”label”error:error)

{ //test pass}

else { //testfail}

(2)非UI层面

由于是继承XCTest的,所以XCTest所具有的那些断言在KIF里都是可以通用的。共有18个。

XCTFail(format…)生成一个失败的测试;

XCTAssertNil(a1,format...)为空判断,a1为空时通过,反之不通过;

XCTAssertNotNil(a1,format…)不为空判断,a1不为空时通过,反之不通过;

XCTAssert(expression,format...)当expression求值为TRUE时通过;

XCTAssertTrue(expression,format...)当expression求值为TRUE时通过;

XCTAssertFalse(expression,format...)当expression求值为False时通过;

XCTAssertEqualObjects(a1,a2, format...)判断相等,[a1 isEqual:a2]值为TRUE时通过,其中一个不为空时,不通过;

XCTAssertNotEqualObjects(a1,a2, format...)判断不等,[a1 isEqual:a2]值为False时通过;

XCTAssertEqual(a1,a2, format...)判断相等(当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以);

XCTAssertNotEqual(a1,a2, format...)判断不等(当a1和a2是 C语言标量、结构体或联合体时使用);

XCTAssertEqualWithAccuracy(a1,a2, accuracy, format...)判断相等,(double或float类型)提供一个误差范围,当在误差范围(+/-accuracy)以内相等时通过测试;

XCTAssertNotEqualWithAccuracy(a1,a2, accuracy, format...) 判断不等,(double或float类型)提供一个误差范围,当在误差范围以内不等时通过测试;

XCTAssertThrows(expression,format...)异常测试,当expression发生异常时通过;反之不通过;(很变态)XCTAssertThrowsSpecific(expression, specificException, format...) 异常测试,当expression发生specificException异常时通过;反之发生其他异常或不发生异常均不通过;

XCTAssertThrowsSpecificNamed(expression,specificException, exception_name, format...)异常测试,当expression发生具体异常、具体异常名称的异常时通过测试,反之不通过;

XCTAssertNoThrow(expression,format…)异常测试,当expression没有发生异常时通过测试;

XCTAssertNoThrowSpecific(expression,specificException, format...)异常测试,当expression没有发生具体异常、具体异常名称的异常时通过测试,反之不通过;

XCTAssertNoThrowSpecificNamed(expression,specificException, exception_name, format...)异常测试,当expression没有发生具体异常、具体异常名称的异常时通过测试,反之不通过。

6.5 测试执行

由于被测试APP和框架以及测试代码都是在同一个进程里的,所以启动APP时,测试自然就开始了,不用再做其他的事情。

7 自动测试举例---基于UI automation的Monkey测试

UI Automation对于控件的获取和支持是比较好的,但是由于获取的方式通常都是用索引的方式,对于精确的测试又是一大挑战。基于这样的考虑,我们认为UI automation 是不是更适合做monkey即随机的测试。我们通过获取到当前界面上的所有控件,随机对其中一个作一个随机的操作,然后保存每一个操作后的屏幕截图,达到以下目的:长时的无序测试,记算crash的次数,对软件的稳定性作出评估。

说说我们设计的原理

(1)获取当前界面上的所有控件

在Instrument的Automation中,可以使用logElementTree()函数来打印出当前界面上的所有控件,如下图所示:

UIATarget.localTarget().frontMostApp().logElementTree()

由上图可知,一个界面上的控件是树结构的形式组织的,并且UIAutomation中还提供了获取某个控件节点的所有子节点的方法

那满足这两点之后,我们就能使用递归的方式来遍历当前界面上的所有控件,并将这些控件按条件(有些控件是不需要care的,例如keyboard)加入到一个数组中。获取控件主要就是一个递归算法,关键流程如下:

(2)基于控件的随机测试

主要流程为:获取当前界面上的所有控件、从这些控件中随机选出一个、根据控件类型决定要执行的随机操作、操作控件、按概率执行一些自定义的随机操作(可选)。然后讲上述流程放在一个while循环中来执行,就能达到持续测试的目的。

(3)命令行执行UIAutomation,执行测试

还好苹果提供了从命令行执行instrument的能力,让测试可以更方便。

(4)crashlog的收集与统计,主要是供开发定位具体的crash原因,以及对整体软件的稳定性作出评估。长期的数据统计是稳定性有力的佐证。

这样整个测试已基本形成闭环,但是,具体这样的测试每天能发现多少个有效的问题,会不会经常因为工具不稳定造成各种问题,对于有效的问题的原因定位,有没有提供充分的线索。这些都是我们需要去考虑的点,基于这些,我们仍可以作以下的优化:

(1) 将常用操作封装成一个接口,有序得执行:因为很多功能都需要数次的点击或其他操作才能触,比如删除一个书签,就得打开书签管理器---》点击编辑---》点击某一个书签---》点删除,这样的操作,用随机的方法不可能会触发到。其实像这样需要2次操作以上才能完成的,用随机的方法都太难被覆盖到。所以为了覆盖到这样功能,都会把他的操作路径封装成一个接口,有顺序的执行,中间不加其他的随机操作。这样的随机就可以覆盖绝大部分的功能。

(2)记录每一次启动测试后的测试路径,当程序出现crash后,重新拉起进行测试时,优先执行上次出现crash时记录的测试路径,当不出现crash时,再执行随机的测试。这样做的目的主要是为了确认本次的crash是不是随机出现的,出现的概率是不是比较高,如果出现概率高的话,那么这个问题的解决优先级就更高些。

(3) 录测试过程中的log,为事后分析crash问题提供更多的线索。很多时候,从最后的堆栈还是看不出问题所在,这时就需要通过记录一些其他的信息,来帮助我们定位问题。以浏览器为举例,如果根据堆栈不能定位到问题,那么在闪退之前记录下浏览器当前的一些状态,比如当前打开了哪些页面,打开了多少个窗口,每个窗口对应哪个页面,占的内存是多少等等,这样对于定位问题有比较大的帮助。

其实能做的事情远不止不这些,帮助发现更多问题和定位问题一直是有东西可以深挖的,这些辅助的东西能让测试的效果更佳,真正得为产品的质量提供保证。

8 结语

先看看一个实际的案例:

N年前某大型通信设备公司的测试部门发起一场轰轰烈烈的测试转型运动,驱动转型的动力非常简单:人手太紧了,要释放人力,当时该部门有95%以上的测试精力都投入系统测试上,导至其他测试试,比如组网测试、协议测试一致性测试、性能测试、还有白盒测试根本顾不上。部门经理贾XX决心很大,先部门总动员,历经艰难,后来终于从各产品测试组抽调20多位骨干来研发自动测试工具。

半年过去,终于有一两个自动工具的初始版本做出来了,选测试组进行试验,为让自动测试跑起来,测试组额外多投了20%的精力饲候这个脆弱系统,后来工具研发人员几经努力,又用了半年时间,自动系统终于能稳定的跑起来了。大家舒了一口气,都指着这个系统能帮他们节约出几个人来,结果,两个版本测试周期过去了,人力没节省,反倒多搭进50%的人力写测试脚本,维护测试脚本。部门经理贾XX并不因此灰心,他认为这是测试自动化推行初期必然要经历的。

这次,他们调整策略,只从所有产品中选择1/3容易做自动化的测试组,给每个测试组指定一个测试自动化率指标,拿这个指标考核测试经理。如此又坚持了一年半,最后统计发现,这1/3测试组中又只有1/3是出效果,自动化测试助于减少测试工作量,而见到显著效果的,却只是个别产品。

有效的自动测试能做人工不能做的事情,而且事办公倍,关键是看测试人员如何去设计了。这里要提出的是,并不是每个产品,每个功能都适合作自动测试,而且自动测试也需要从实际的测试需求出发,需要测试什么才针对性去实现什么。一味得想把所有的工作都自动化去实现,不但投入具大,而且往往适得其反。步子迈得大了容易扯着蛋的道理谁都懂,自动测试更加是应该小步小步走的一件事,急不来。

原文发布于微信公众号 - 腾讯移动品质中心TMQ(gh_2052d3e8c27d)

原文发表时间:2016-05-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Android机动车

程序员必定会爱上的10款软件

TrueCrypt可能很多人没用过,它是一个加密软件,能够对磁盘进行加密。还在担心自己电脑中的重要文件、私密档案被人查看。什么,你以为把文件设置了隐藏属性别人就...

12420
来自专栏JackieZheng

AngularJS in Action读书笔记1——扫平一揽子专业术语

前(fei)言(hua):   数月前,以一个盲人摸象的姿态看了一些关于AngularJS的视频书籍,留下了我个人的一点或许是指点迷津或许是误人子弟的读后感。自...

19970
来自专栏前端架构与工程

前后端分离和模块化-58到家微信首页重构之路

微信钱包内的58到家全新首页已经上线,感兴趣的同学们可以在微信中打开“我的->钱包->58到家”查看。 58到家全新首页提出重构主要是为了解决以下问题: 每个城...

25980
来自专栏安富莱嵌入式技术分享

emWin视频播放器,含uCOS-III和FreeRTOS两个版本

第10期:视频播放器 配套例子: V6-918_STemWin提高篇实验_视频播放器(RTX版本,仅支持MDK4.74)

30020
来自专栏张善友的专栏

MongoDB 客户端 MongoVue

今天在同事那里看到了一个很不错的MongoDB的客户端工具MongoVue,地址是http://www.mongovue.com/。做的不错,1.0版本的开始收...

67850
来自专栏Sorrower的专栏

不美翻怎么开发!Ubuntu 16.04 LTS深度美化!(2017年度定稿版)

54930
来自专栏Youngxj

杨小杰工具箱网页源码带后台

59530
来自专栏静晴轩

Win下必备神器之Cmder

诚言,对于开发码字者,Mac和Linux果断要比Windows更贴心;但只要折下,Windows下也是有不少利器的。之前就有在Windows下效率必备软件一文中...

1.1K40
来自专栏小白安全

FreeBuf官网发布《简易Python Selenium爬虫实现歌曲免费下载》

主要思路就是爬取播放页里的播放源文件的url,程序可以读取用户输入并返回歌单,,,因为在线网站包含大量js,requests就显得很无奈,又懒得手动解析js...

37950
来自专栏张戈的专栏

利用JS生成二维码图片,优化WEB性能及页面加载速度

移动互联网的蓬勃发展绝对离不开二维码的“推波助澜”,一张小小的图片,省去了繁琐的苦逼输入,也拉近了 PC 端和移动端的距离!虽然是东洋人最初发明的,但我还是要给...

47540

扫码关注云+社区

领取腾讯云代金券