為什麼需要前端自動化測試呢?

2021-12-21 前端Q

點擊上方 前端Q,關注公眾號

回復加群,加入前端Q技術交流群

本文為讀者投稿,感謝時光大佬。

原文為:https://www.wolai.com/4RCFtUJ1gqnP5eTNCkxCkB

我們先來回顧幾個公知問題

自動化測試就是面向這些問題而生的。

而接入前端自動化測試,可以幫助我們提前暴露bug並修復、降低bug產生的成本/提升測試的覆蓋率,降低對其他功能原有邏輯的幹擾。

接下來我們進入正題,向大家介紹前端自動化測試

前端自動化測試的種類

共四類:

單元測試單元測試是最基礎的自動化測試,用來檢測項目當中的最小可測單元,例如工具函數、基礎組件等

集成測試在單元測試的基礎上,不同功能集成在一起,驗證整體功能

ui測試並不是只對ui設計效果的驗證,而是只對數據渲染、交互上的驗證

在vue或react這種前端框架下,延伸出一種組件測試,根據組件的粒度,其實應該屬於單元測試、或者集成測試的部分。

自動化測試金字塔

介紹完自動化測試的種類,我們來簡單比較一下這四種測試

有下之上,測試用例的數量逐步減少、粒度變粗、驗證的功能變多變複雜。

同時受需求變化的影響變大,重複利率降低

同時編寫測試用例的時間變長 、執行的時間也響應變長

另一方面,由上至下,發先的bug數量逐漸變小。

所以,從發先bug數量/編寫測試用例時間&重複利用率的緯度上講,單元測試的收益最大,越向上收益越小。

這也是大部分項目中採用的自動化測試,是在單元測試這一層的原因。

滿足自動化測試的條件

說了那麼多,哪什麼情況下,我們適合使用前端自動化測試呢?

這裡我總結了一些情況,實際上只需要滿足幾點就可以了

一些常見的測試工具

單元測試(Unit Test)有 Jest, Mocha

端到端(E2E Test)Cypress.io、Nightwatch.js、Puppeteer、TestCafe

說了這麼多,其實應用的最廣泛的,收益相對來講最高的還是單元測試

所以後面我將具體給大家講一下,如何將單元測試融入到我們的開發當中

如何編寫單元測試

我們是先開發,後補充單元測試呢?還是先編寫單元測試再開發呢?

相信大多數第一次,接觸這個問題的人可能都想我一樣,覺得是先開發後補充

但是實際上應當是先編寫單元測試,在開發代碼。這種模式成為測試驅動開發(TDD)

很簡單的道理,如果你寫的代碼邏輯有問題,那麼按照錯誤邏輯寫的單元測試,永遠不可能驗證出問題來。

我們應當圍繞功能設計來編寫我們的單元測試,測試內容對我們來講就是一個黑盒,我們只需要驗證他是否滿足我們的設計預期就好了,而無關內部細節。只有這樣,才能保證測試用例的穩定,支撐重構

測試驅動開發流程

分節點開發,一邊開發一邊驗證,擴大測試通過範圍運行

單元測試步驟

準備(Arrange)為測試做好設置。渲染組件/執行條件/準備數據

行動(Act)
對系統執行操作,例如點擊按鈕、觸發鉤子函數

單元測試開發案例

假設現在我們要開發一個按鈕,

我們先來設計這個按鈕的功能

首先能接收自定義文字,能夠接收size設置不同尺寸,能夠觸發事件,然後還有禁用功能

接下來我們開始寫單元測試

// tests/button.spec.js
import Button from '@/components/Button.vue'
import { mount } from "@vue/test-utils"

const BUTTON_TEXT = '點擊'
describe('Button.vue', () => {
    it('render text', () => {
        const wrapper = mount(Button, {
            slots: {
                default: BUTTON_TEXT,
            },
        })
        expect(wrapper.text()).toBe(BUTTON_TEXT)
    })
    it('size', () => {
        const wrapper = mount(Button, {
            propsData: {
                size: 'small'
            }
        })
        expect(wrapper.classes()).toContain('btn-small')
    })
    test('handle click', async () => {
        const wrapper = mount(Button, {
            slots: {
                default: BUTTON_TEXT,
            },
        })
        await wrapper.trigger('click')
        expect(wrapper.emitted().click).toBeDefined()
    })
    test('handle disabled click', async () => {
        const wrapper = mount(Button, {
            slots: {
                default: BUTTON_TEXT,
            },
            propsData: {
                disabled: true
            }
        })
        expect(wrapper.classes()).toContain('is-disabled')
        await wrapper.trigger('click')
        expect(wrapper.emitted().click).toBeUndefined()
    })
})   

完成組件功能

<template>
    <button 
    :class="[
      'el-button',
        size ? 'btn-' + size : '',
      {
        'is-disabled': disabled,
      }
    ]"
    @click="handleClick">
            <span v-if="$slots.default"><slot></slot></span>
    </button>
</template>

<script>
export default {
    props:{
        size:{
            type:String,
            required:false
        },
        disabled:{
            type:Boolean,
            default:false,
            required:false
        },
    },
    methods:{
        handleClick(evt) {
            !this.disabled && this.$emit('click', evt)    
        }
    }
}
</script>

<style>
//省略樣式
</style>

總結

在開發中引入前端自動化測試,可以幫我們帶來很多好處。但是同時不能忽視的一個問題,就是成本、無論是編寫自動測試的時間成本,平臺的搭建成本,項目成員學習自動化測試的成本。要考慮驗證的的內容是否有價值需要自動化測試,我們費勁心血寫的自動化測試是否足夠穩健,不會頻繁變更。

總之只有合適的才是最好的。

相關焦點

  • 前端自動化測試:Jest 測試框架應用
    相對其他測試框架,其一大特點就是就是內置了常用的測試工具,比如零配置、自帶斷言、測試覆蓋率工具等功能,實現了開箱即用。Jest 適用但不局限於使用以下技術的項目:Babel、TypeScript、 Node、 React、Angular、Vue 等。
  • 前端自動化測試:TDD 和 BDD 哪個好?
    >業務耦合度高,測試用例中使用了業務中一些模擬的數據,當業務代碼變更的時候,要去重新組織測試用例;關注點過於獨立,由於單元測試只關注這一個單元的健康狀況,無法保證多個單元組成的整體是否正常; 個人理解在前端應用實際開發過程中 TDD 更適合開發純函數庫,比如 Lodash、
  • 自動化測試學習路線
    自動化的成效初步形成,仿佛你開始懂得如何用自動化提升效率了。開始接觸自動化框架unittest/testNG等你學會單元測試框架unittest/testNG,當你學會了selenium後,你會發現大部分的線性腳本,很難去管理,並且每個腳本需要去一個個run,而且還無法統計測試結果,這個時候,就需要單元測試框架登場了!
  • 一文搞定前端自動化測試(Vue 實戰)
    這次通過實現一個 Button 組件並完善其測試用例帶大家學習 Vue 中的自動化測試。編寫測試用例組件寫好了,人工測試好像也沒啥問題啊,為啥還要寫測試用例呢?而且這裡還沒採用 TDD 的思想,先寫測試用例再寫代碼,為什麼呢?人工測試當然沒問題,組件能正常運行,也沒發現什麼問題,但是萬一以後要重構呢?
  • 自動化測試實踐經驗分享(附視頻)
    那到底有什麼區別呢?我這裡講的自動化測試是分層自動化測試的概念,分層自動化是最近這幾年測試的一個流行趨勢。何謂分層自動化?就是指我們做自動化測試不能一直只是往UI層的自動化測試方向發力,為什麼不能這樣發力呢?因為UI層的自動化比較脆弱、不穩定,開發和維護成本比較高。
  • 我從功能測試進階到自動化測試工程師的經驗總結~|Atstudy
    所以花了很多時間在功能測試用例的設計上,隨著項目越做越多,用例設計也變得手到擒來。自己的內心也不滿足於只做功能測試,覺得自動化測試很厲害的樣子,就去學了代碼基礎。但是有一個問題,學了代碼基礎還是不會做自動化測試,因為那時候還傻傻分不清自動化到底有哪幾種。隨著學習的深入,知道軟體測試中常見的自動化主要分為2種:一種是UI自動化,一種是接口自動化。那麼先學哪個呢?
  • 接口自動化測試與Tesla自動化測試平臺
    引言我們今天要講的tesla,不是電動汽車,而是字節跳動內部的服務端自動化測試平臺——Tesla。在服務端測試中,接口測試是非常重要的。【為什麼從接口層面進行測試(對標UI或資料庫)】「接口層是問題多發的層級」由於接口是人與人協作的界面,每個人對自己負責的模塊是會進行調試和自測的;所以接口與接口之間的測試會是bug相對較多的地方
  • Python自動化測試踩坑記錄(企業中如何實施自動化測試)
    作為軟體測試這個行業,在當下,你學好自動化,你去哪面試都不怕。說是這麼說,但是你想提前下班,自動化測試解放勞動力、提高效率,讓程序腳本在不需要看守的情況下「起飛」如果你的代碼、腳本掉到了坑裡,你覺得你還能提前下班嗎?有可能,你甚至不如別人做功能測試的。別人一個功能都測試完好久了,你的自動化腳本報了一堆錯,還不知道找這個錯誤的原因。
  • 前端測試集錦——如何寫好前端測試保證代碼質量?
    「自動化測試」這個主題相關的文章千千萬萬,但是仔細去看會發現有很大一部分都是後端或BFF的測試,它們的測試覆蓋率幾乎可以達到100%(根據不同團隊不同的要求)。今天這篇是一個前端測試集錦,從測試金字塔原理來剖析前端測試包涵的幾種測試類型,介紹了每種測試類型的性價比、使用場景以及每種測試常採用的測試框架或者工具。因為單元測試經常是佔比最大的自動化測試,所以從2個方面介紹了怎麼去寫好一個單元測試,怎麼合理的使用測試替身隔離測試依賴,提高測試的獨立性。
  • 答疑解惑丨進行Web自動化測試,為什麼總是定位不到元素?
    關注我,每天分享軟體測試技術乾貨、面試經驗,想要領取測試資料、進入軟體測試學習交流群的可以直接私信我哦~~一、寫在前面本文討論的基礎,是基於Robotframework(簡稱RF)+Selenium測試框架的Web前端自動化測試。
  • 如何做前端單元測試
    前言對於現在的前端工程,一個標準完整的項目,通常情況單元測試是非常必要的。但很多時候我們只是完成了項目而忽略了項目測試。我認為其中一個很大的原因是很多人對單元測試認知不夠,因此我寫了這邊文章,一方面期望通過這篇文章讓你對單元測試有一個初步認識。
  • 做好自動化測試,少不了這麼強大的平臺!
    對於服務端接口的API測試來說,就是由自動化測試工具模擬需要人工在軟體界面上的各種操作後發起的一連串接口請求,並且自動驗證其結果是否符合預期。  (二)UI 界面測試  最上層的UI測試佔比少,是因為UI界面的不穩定性以及UI定位腳本的識別難度較高,且本身對於前端的代碼規範性也會有一定的要求,所以一定程度會導致腳本維護成本也非常高。UI自動化測試更適用於測試需要大量重複的、測試功能穩定性和兼容性的單個場景。
  • 前端UI自動化利器 Katalon掃盲UI篇
    對象庫:管理對象,對於UI自動化來說,此文件夾內保存各UI自動化需要使用的元素Test Suites測試集:測試用例集合,在katalon中真正執行自動化時測試需要執行哪些用例,均在此維護Data Files
  • 前端開發,測試,後端,該如何選擇?
    因為前端開發這一行,是需要你不斷去學習的。停滯不前的同學,這幾年都找不到合適的前端崗位,都慢慢被這個行業淘汰了,到時候可以連8K的工作都找不下,因為公司覺得8K,為何不找個更年輕的,學習能力更強的,可塑性更高的。最後,迫不得已只能轉行去做了別的。到時候你又該思考,我該去幹個什麼工作比較好。在沒有搞清楚自己對哪個方向感興趣,就盲目轉行,此為惡性循環。
  • 基於自動化用例的精準測試探索
    產品線的接口自動化測試用例隨著迭代積累,用例數多達幾千個,如果讓這些自動化用例發揮它們的效用呢?對於背景1,2的問題,我們可以總結為:測試覆蓋面是否可以很容易客觀數據衡量,測試覆蓋面是沒有置信度,且在達到這個置信度的過程中有沒有工具可以支持QA更快更有效達成?
  • 【免費】自動化測試視頻教程Selenium Java
    課時1:1.1 軟體測試分類課時2:1.2 分層的自動化測試課時3:1.3 什麼樣的項目適合自動化測試課時4:1.4 自動化測試及工具簡述課時5:1.5 Selenium 工具介紹課時6:1.6 前端技術介紹課時7:1.7 前端工具介紹課時8:1.8 開發語言的選擇第2 章
  • 技術 Docker+Jenkins打造自動化測試以及部署升級環境
    由此體現了升級測試的極度必要性。通常在對TDH進行版本升級測試時,我們的開發人員不僅要考慮到前端界面,還要考慮到後端升級程序的執行。升級完成後,需要給出詳細的測試報告,比如每個階段的執行時間、啟動時間、是否成功等關鍵信息。由於Python自帶的或者第三方開發的模塊生成測試報告基本都是UT級別的,因此無法使用現成的模塊,需要自己進行開發。我們參考Python中對應的模塊HTMLTestRunner對生成的測試報告進行二次開發。
  • 高級自動化測試常見面試題(Web、App、接口)
    5.你的自動化用例的執行策略是什麼?自動化測試與軟體開發本質上是一樣的,利用自動化測試工具,經過測試需求分析,設計出自動化測試用例,從而搭建自動化測試的框架,設計與編寫自動化腳本,驗證測試腳本的正確性,最終完成自動化測試測試腳本(即主要功能為測試的應用軟體)並輸出測試結果6.自動化測試的時候是不是需要連接資料庫做數據校驗?
  • 自動化測試基礎篇:Selenium 框架設計(POM)
    自動化測試框架1.什麼是自動化測試框架簡單來說,自動化測試框架就是由一些標準,協議,規則組成,提供腳本運行的環境。自動化測試框架能夠提供很多便利給用戶高效完成一些事情。用戶自定義庫,這個很好理解,我們很多功能需要重複調用,這樣我們就寫成一個公用方法,放到工具包下,每次方便調用,例如瀏覽器引擎類和basepage.py的封裝。管理和執行腳本的方式,例如Python中單元測試框架unittest使用率非常高。第三方插件,有時候,我們一些功能,需要藉助第三方插件,能夠更好實現,例如AutoIT,來實現文件上傳和下載。
  • 南京捷希科技有限公司在5G射頻前端的探索與測試介紹
    據悉,捷希主要圍繞著通訊的主設備以及終端,為設備廠商的射頻前端提供一些自動化的射頻測試解決方案以及性能驗證解決方案。南京捷希研發中心研發總監王成勇在會上詳細介紹了南京捷希科技有限公司在5G射頻前端的探索與測試。