唱吧UI自动化测试实践

由于频繁地重复，许多起初在我们看来重要的事物逐渐变得毫无价值。 ——叔本华

UI自动化在业内一直褒贬不一，爱它的认为，这是UI测试的一次革命，它极大的解放了测试的双手，拯救测试于重复。恨它的认为，这是劳民伤财，UI界面版版变，这版还没用上，下版就要重写。笔者认为，会造成后者这种尴尬的局面在于缺少因地制宜的分析，对自动化赋予过重的意义。下边是我们在实施自动化时的一些思考：

一、自动化实施原则

1. UI自动化不是简单的手工用例代码化，它是在测试过程中一种新的测试类型，有其独立的价值。

2. UI自动化在设计之初就要明确:用途目的，测试内容，执行时机，执行方式，期望结果。

3. 建立投入产出比公式，粗略讲：投入即编写维护的时间，产出即通过执行自动化替代的人工时间，设定准入值，比值大于准入值时可以引入。

4. 选择合适的框架，设计模式，编写语言，这里的选择不求最高大上，但求最熟悉。

5. 编写之前，细化业务逻辑，合理组件化，封装方法，减少耦合度，各条用例不要有依赖关系。

6. 小步快跑，少量编写后，快速部署，尽早发现问题。

二、自动化框架介绍

1）框架简介

唱吧的自动化框架是基于appium进行了二次开发，并对其封装，使用代理模式，降低了耦合度同时也为框架提供更大的灵活性。同时抽象了一些接口，包括页面操作，手势操作等提供给用例层调用。封装了性能测试相关工具，丰富了框架的功能。

2）功能特点

• 通过PO模式将代码以页面为单位进行组织，将测试逻辑同测试对象分离

• 封装了性能测试相关方法，执行用例时同时收集性能数据

• 输出内容丰富的测试报告

三、自动化用例编写

以唱吧录音功能自动化过程为例，介绍我们在编写用例时的思路。

决定对录制流程进行自动化之前，我们没有直接编码，而是先分析需求，录制功能需要验证的点有很多，我们要通过自动化验证什么？通过对录音功能进行拆分，以及历史测试经验，我们将不同场景的录制流程进行了自动化。

下图为录制功能可能的场景细分，不难发现不论场景如何变换，核心流程始终不变，所以我们选择将核心流程封装成公共方法，不同场景通过传递不同参数实现

在编写用例时，我们使用appium框架java语言，好处是：

• 跨平台，一套框架，一份 case两端都可以使用

• Appium PageObject 直接沿用了Selenium的PageObject设计模式，将UI元素与逻辑分离方便后期维护

• java语言的选用，主要考虑使用大家最熟悉的语言

具体实现：

Objects封装所有页面元素，这样的好处是，如果只是单纯的ui改变，只需修改此类即可

1.    @WithTimeout(time = 300, unit = TimeUnit.SECONDS)

2.    @AndroidFindBy(id = "com.changba:id/begin_btn")

3.    @SelendroidFindBy(id = "begin_btn")

4.    public static MobileElement startRecordingButton;

5.    @SelendroidFindBy(xpath = "//RecyclerView[@id='recycler_view']/child::*")

6.    @OverrideWidget(selendroid = AndroidPropsCellWidget.class)

7.    public static List<PropsCell> propCellList;

将具有同样父元素的子元素封装成一个widget，这样在去操作例如Android中List中的某个Item会很方便

1. public class AndroidPropsCellWidget extends PropsCell {

2.    protected AndroidPropsCellWidget(MobileElement element) {

3.        super(element);

4.    }

5.    @SelendroidFindBy(xpath = "//ImageView[@shown='true'][@id='download_image']")

6.    public MobileElement downloadImage;

7.    @Override

8.    public MobileElement getDownloadImage() {

9.        return downloadImage;

10.    }

11. }

Page页面封装元素操作

1.    public void startRecording() {

2.        if (getCabbie().waitFor(By.id("begin_btn"), 300) != null) {

3.            getCabbie().pressOnElement(PreviewRecordingPageObjects.startRecordingButton);

4.        }

5.    }

将核心业务逻辑封装，如果业务逻辑发生变化，只需修改此类中的方法即可

1. public String recordWithConcert(String songName, RecordingType recordingType, SingType singType, int recordTime) {

2.        singPage.searchSong(songName);

3.        singPage.clickSingButton(0);

4.        previewRecordingPage.switchRecordingType(recordingType);

5.        previewRecordingPage.switchsingTypeButton(singType);

6.        String recordingSongName = recordingPage.startRecordingAndFinish(recordTime);

7.        compeleteRecordingPage.waitForCompletePage(recordingType)

8.        compeleteRecordingPage.saveRecording(AccompanyType.concert);

9.        return recordingSongName;

10.    }

通过不同参数组合，实现不同的用例，减少代码冗余

1. @Test

2. public void testRecordWithConcertAudioSolo() {

3.    baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, solo, RECORD_TIME);

4. }    

5. @Test

6. public void testRecordWithConcertAudioChorus() {

7.     baseRecordingProcess.recordWithConcert(SONG_NAME, audio_recording, chorus, RECORD_TIME);

8. }

重写onTestStart方法，实现执行用例时如果用例名结尾包含"_Perf"，同时收集性能数据

1. @Override

2.    public void onTestStart(ITestResult result) {

3.        if (result.getMethod().getMethodName().endsWith("_Perf")) {

4.            if (getPerformance.getCS() != null) {

5.                getPerformance.setStart(true);

6.                getPerformance.callable();

7.            }

8.        }

9.    }

四、总结及展望

如上介绍了唱吧在UI自动化测试的一些成果，测试团队还在思考UI自动化测试的更多可能，以及如何在测试左移这个大目标下发挥更大作用。