由于频繁地重复，许多起初在我们看来重要的事物逐渐变得毫无价值。 ——叔本华
“天下武功，唯快不破”，移动开发更是如此，敏捷开发，敏捷测试，快速上线。测试做为上线前的最后一个环节，任务异常艰巨。对于其他团队而言，每个迭代的重心放到出新即可，唯独测试既要出新，又要守旧。换句话说，每迭代一个版本，测试下次要测试的内容就会多一分，增长的内容和快速的迭代的周期，如何保证既快又好，本文是唱吧测试团队的一些经验：
一、合理引入UI自动化，引入合理的自动化
UI自动化在业内一直褒贬不一，爱它的认为，这是UI测试的一次革命，它极大的解放了测试的双手，拯救测试于重复。恨他的认为，这是劳民伤财，产品界面版版变，这版还没用上，下版就要重写。笔者认为，会造成后者的尴尬境地，在于简单粗暴的引入。下边是我们在实施自动化时的一些思考：
UI自动化不是简单的手工用例代码化，它是在测试过程中一种新的测试类型，有其独立的价值。
UI自动化在设计之初就要明确:用途目的，测试内容，执行时机，执行方式，期望结果。
建立投入产出比公式，粗略讲：投入即编写维护的时间，产出即通过执行自动化替代的人工时间，设定准入值，比值大于准入值时可以引入。
选择合适的框架，设计模式，编写语言，这里的选择不求最高大上，但求最熟悉。
编写之前，细化业务逻辑，合理组件化，封装方法，减少耦合度，各条用例不要有依赖关系。
“小步快跑”，少量编写后，快速部署，尽早发现问题。
以唱吧录音功能自动化过程为例：
决定对录制流程进行自动化之前，我们没有直接编码，而是根据经验又对录制功能进行分析，图一，录制功能可能的场景细分，不难发现不论场景如何变换，核心流程始终不变，所以我们选择将核心流程封装成公共方法，不同场景通过传递不同参数实现
[图片上传失败...(image-31a35a-1513606584889)]
[图片上传失败...(image-f36c3a-1513606584889)]
在编写用例时，我们使用appium框架java语言，好处是：
- 跨平台，一套框架，一份 case两端都可以使用
- Appium PageObject 直接沿用了Selenium的PageObject设计模式，将UI元素与逻辑分离方便后期维护
- java语言的选用，主要考虑使用大家最熟悉的语言
Objects封装所有页面元素，这样的好处是，如果只是单纯的ui改变，只需修改此类即可
@WithTimeout(time = 300, unit = TimeUnit.SECONDS)
@AndroidFindBy(id = "com.changba:id/begin_btn")
@SelendroidFindBy(id = "begin_btn")
public static MobileElement startRecordingButton;
@SelendroidFindBy(xpath = "//RecyclerView[@id='recycler_view']/child::*")
@OverrideWidget(selendroid = AndroidPropsCellWidget.class)
public static List propCellList;
在定义页面时，将具有同样父元素的子元素封装成一个widget，这样在去操作例如Android中List中的某个Item会很方便
public class AndroidPropsCellWidget extends PropsCell {
protected AndroidPropsCellWidget(MobileElement element) {
super(element);
}
@SelendroidFindBy(xpath = "//ImageView[@shown='true'][@id='download_image']")
public MobileElement downloadImage;
@Override
public MobileElement getDownloadImage() {
return downloadImage;
}
}
Page页面封装元素操作
public void startRecording() {
//等待伴奏下载
if (getCabbie().waitFor(By.id("begin_btn"), 300) != null) {
getCabbie().pressOnElement(PreviewRecordingPageObjects.startRecordingButton);
}
}
将核心业务逻辑封装，如果业务逻辑发生变化，只需修改此类中的方法即可
public String recordWithConcert(String songName, RecordingType recordingType, SingType singType, int recordTime) {
singPage.searchSong(songName);
singPage.clickSingButton(0);
previewRecordingPage.switchRecordingType(recordingType);
previewRecordingPage.switchsingTypeButton(singType);
String recordingSongName = recordingPage.startRecordingAndFinish(recordTime);
logger.info("start and finish recording with {} time", recordTime);
compeleteRecordingPage.waitForCompletePage(recordingType);
clientUtils.waitForPlayStart(CompeleteRecordingPageObjects.playingTime);
compeleteRecordingPage.saveRecording(AccompanyType.concert);
return recordingSongName;
}
通过不同参数组合，实现不同的用例，减少代码冗余
@Test
public void testRecordWithConcertAudioSolo() {
baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, solo, RECORD_TIME);
}
@Test
public void testRecordWithConcertAudioChorus() {
baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, chorus, RECORD_TIME);
}
二、坚持三项原则
- 测试左移
- 合并测试
- 持续测试
具体思路：开发在进行某版本的开发时，会创建相应分支，测试在此分支创建之时，就在jenkins上构建版本并创建包含多项测试的组合任务，并每天自动执行。
下边是唱吧通过一次测试任务，完成apk大小检测，启动速度测试，checklist测试，部分功能性能测试：
首先在jenkins创建job: test_ktv_android_launchSpeed_apksize_Test
通过shell命令行执行apk size数据收集及启动启动速度测试脚本
if [ $APK_SIZE -gt $MAX_SIZE ]
then
echo "$APK_SIZE ," >>apksize.csv
fi
adb -s $deviceId install -r ${APK_PATH}
python ./ChangBaLaunchSpeedCollect.py
然后创建job:testUIautomation_ktv_checklist_Android_8.5_dev，用于执行核心功能测试及性能数据收集
该job的触发机制是
[图片上传失败...(image-76d335-1513606584889)]
如何在执行自动化用例时收集性能数据
目前唱吧的自动化基于 Appium+Maven+TestNG的形式
1.新线程后台收集性能数据
public static GetPerformance instance = new GetPerformance();
private GetPerformance() {
threadPool = Executors.newCachedThreadPool();
cs = new ExecutorCompletionService<>(threadPool);
}
public static GetPerformance getInstance(){
if (instance == null) {
instance = new GetPerformance();
}
return instance;
}
2.重写onTestStart方法
@Override
public void onTestStart(ITestResult result) {
if (result.getMethod().getMethodName().endsWith("_Perf")) {
if (getPerformance.getCS() != null) {
getPerformance.setStart(true);
getPerformance.callable();
}
}
}