老司機教你如何優雅地完成一個小項目測試

時間 2019-11-12

標籤司機如何優雅完成一個小項目測試简体版

原文原文鏈接

歡迎你們前往騰訊雲社區，獲取更多騰訊海量技術實踐乾貨哦~html

做者：高苡新前端

團隊：騰訊移動品質中心TMQ 小程序

1、概述

本文以寫實風格記錄TBS Studio開發調試工具測試全過程。包括測試人力申請、測試策略制定、系統測試以及衆測體驗。對於測試初學者能夠了解到整個流程是如何一步一步走下來的。對於有必定經驗的同窗能夠領略到測試策略制定過程當中基於風險和成本的測試理念。windows

2、提測項目介紹

TBS Studio是面向基於TBS的Web開發者和移動應用開發商（包括微信、手Q，三方App等）打造的開發服務總體解決方案，以提高廣大開發者在真機環境下的開發效率，並幫助開發者分析和優化網頁的設計，主要功能有網頁Inspector調試，網頁性能分析等。瀏覽器

詳情：https://x5.tencent.com/tbs/guide/debug/season1.html。微信

3、測試人力申請

5月23日，開發同窗Brian找到我，說有一個tbs studio的產品要申請測試資源。通過電話溝通，我瞭解到這個屬於騰訊瀏覽服務（TBS）的附屬產品，提供給開發作網頁調試用的。因而我去找咱們測試組leader說明了狀況。Leader說Bonnie和mekhi對網頁調試比較熟悉，建議我拉上他們一塊兒去溝通測試需求 ——實踐證實，對於一個陌生的測試需求，多拉幾個相關的同事一塊兒去溝通準沒錯！app

次日，我和Bonnie、mekhi一塊兒去找到開發Brian溝通需求。通過半小時的講解，咱們對測試需求有了比較清晰的瞭解。也明確了主要工做是項目跟進（我比較擅長），而不是經過技術手段實現測試（Bonnie和mekhi比較擅長）。下面是溝通結果記錄：（從中你能夠知道測試需求溝通通常須要了解哪些東西）。ide

背景：工具

開發調試工具。主要用於提高TBS的影響力。以前都是小規模發佈，如今想經過完整測試保證質量加大推廣。目前日活xx（具體數據不方便公開，下同），上半年目標是日活xxx。性能

TBS Studio功能簡介及測試重點：

主要分2部分：adb檢測和inspector模塊。inspector模塊主要由開發自測保證。測試負責保證adb檢測模塊。adb檢測模塊有4步操做。分別是：

Step1：請鏈接手機，容許USB調試；

Step2：確認須要調試的App，檢測當前app是否接入X5內核；

Step3：檢測是否支持TBS調試；

Step4：設定TBS調試狀態。

Inspector模塊本次只須要測試元素更改功能。

TBS Studio發佈節奏：

每3週一個小版本，每6週一個大版本（跟隨TBS內核版本更新節奏）。

小版本發佈遵循以下流程：

（1）開發使用mochr方法自測；

（2）測試驗證修改點；

（3）開發內測；

（4）上線前測試。

大版本發佈遵循以下流程：

（1）開發自測（主要保證inspector模塊與新版本TBS內核兼容）；

（2）核心流程用例（比上線前用例更小。主要保證adb檢測正常）。

本次集成預計下週提測，發佈計劃還沒有明確。

TBS Studio參與角色：

產品：Brian

前端開發：April

終端開發：josh

測試：eason

測試點：

（1）功能點：覆蓋adb檢測模塊 step1-step4操做的不一樣分支；

（2）平臺適配：windows/mac(主要適配adb檢測第1步)；

（3）宿主適配：自有內核/共享內核/QB （主要適配adb檢測第3步）；

（4）機型適配：全部安卓手機（主要適配adb檢測第1步，第3步）

（5）tbs版本適配：全部線上版本（主要適配inspector模塊）；

（6）inspector模塊：本次只須要測試元素更改功能（https://x5.tencent.com/tbs/guide/debug/season2.html）。

測試方法考慮：

（1）主要是手工測試；

（2）初步分析不適合使用自動化，具體須要請教下應用寶；

（3）能夠考慮衆測來發現一些咱們考慮不到的問題；

（4）由於當前用戶量不大，因此考慮用最小的投入評估產品質量。

跟進計劃：

（1）eason先評估工做量和是否採用自動化測試；

（2）eason確認外包人力；

（3）eason編寫測試用例；

（4）外包執行測試。

4、測試策略制定

和開發溝通完需求以後，對該項目的狀況有了基本的瞭解。接下來須要評估工做量和制定測試策略。

工時預估：

（1）測試策略制定（選擇測試方法、測試機型、覆蓋範圍等）正職2h；

（2）測試用例編寫（集成用例-目前有16個測試點、上線前用例、核心流程用例）正職6h；

（3）測試環境準備（win八、win十、mac電腦，手機協調）正職4h；

（4）集成用例執行（單機全用例16條+平臺適配用例6條+宿主適配用例4條+機型適配用例60條+其餘6條=92條）外包2-3天；

（5）上線前用例（10條）外包2小時；

（6）核心用例（3條）外包1小時。

本次集成測試總共須要12h的正職人力以及3-4天的外包人力。

測試策略制定：

測試策略制定主要是解答「擔憂什麼」、「測多少」、「怎麼測」這3個問題，其中會結合風險及成本的考慮。

擔憂什麼（風險）：

本次提測是爲了瞭解和提升版本質量，爲產品加大推廣作好準備。因此目前擔憂的問題是版本發到用戶那裏會出現各類各樣的問題，影響到產品的口碑。那要解除這個擔憂，就須要瞭解用戶使用場景，咱們測試覆蓋到這些場景就沒問題。用戶場景能夠有2種方式獲取。一是看統計數據，二是找用戶（衆測和體驗）。

整體來講，本項目的風險較小。由於tbs studio目前只有89個日活用戶。假若通過系統測試和衆測，依然有個別問題泄漏到真實用戶也問題不大。經過用戶反饋渠道把問題收集起來就行。

測多少（成本）：

上面提到tbs studio風險較小。同時，tbs studio還沒有制定明確的發佈計劃，因此緊急性也不高。因此係統測試只須要使用初級外包覆蓋到最主要的場景，保證80%以上的用戶能順利使用就行。沒有覆蓋到的場景能夠交給衆測和體驗這兩種成本更低的方式去發現。有這兩道關，質量基本有保證。

怎麼測：

這裏主要是自動化測試、人工系統測試、衆測這集中方式的選擇。跟PC應用寶溝通後得知他們對adb鏈接這類功能也沒有使用自動化測試。因此咱們就放棄自動化測試了。系統測試確定不能少。衆測和公司內體驗能夠補充系統測試覆蓋不到的點，因此能夠用起來。

測試策略詳情：

平臺適配：

經過網上資料，咱們能夠看到win七、win十、mac10 這3個系統的市場份額之和達到78%。因此選擇這3個系統爲平臺適配系統。

https://www.idcps.com/news/20170420/94526.html。

由於window系統分爲32位和64位，因此經過查閱資料。咱們發現64位系統已是主流。因此咱們在測試中主要使用64位系統來測試。

http://digi.163.com/16/1103/08/C4UDM2QS001687H3.html

屏幕分辨率適配（全部交互界面）：

由於TBS studio是一個桌面應用，因此要考慮顯示器的分辨率問題。保證在不一樣的屏幕上界面顯示正常。經過網上數據，咱們能夠看到1366768（筆記本屏幕主流分辨率）和19201080（臺式機屏幕主流分辨率）佔了50%以上的比例，其餘分辨率的屏幕佔比都較低。因此屏幕適配選擇了1366768和19201080兩種屏幕。

宿主適配

經過tbs（騰訊瀏覽服務）的後臺統計數據，咱們能夠得知不一樣宿主（使用騰訊瀏覽服務的app）的用戶數。經過選擇每種類型的top宿主，咱們能夠得知測試用例能覆蓋多少用戶場景。

最終選擇測試宿主以下：

自有內核宿主：微信/手Q（覆蓋95%用戶場景）；

共享內核宿主：QQ音樂/騰訊新聞/京東/應用寶/王者榮耀/惟品會（覆蓋55%用戶場景）；

QB：手機QQ瀏覽器（覆蓋100%用戶場景）。

機型適配：

對於機型覆蓋，咱們在選擇機型的時候會考慮top覆蓋，主流系統版本覆蓋，主流手機廠商覆蓋3個方面。而由於adb鏈接和廠商關係較大。因此咱們優先經過廠商排名來選擇測試機型。經過tbs後臺監控數據，能夠了解到華爲、vivo、oppo、三星、小米爲排名前5的廠商。用戶數佔tbs總用戶數的80%。

結合測試組現有機型，咱們選擇的機型覆蓋列表以下：

oppo A33

vivo x7plus

華爲p8

小米4

三星S6

測試計劃：

（1）跑通上線前用例（冒煙測試）；

（2）跑通單手機全用例；

（3）跑通機型適配top5品牌各1臺手機（根據top5測試1臺手機測試通過決定要不要增長機型適配）；

（4）宿主適配；

（5）跑通平臺適配用例（加屏幕適配測試）；

（6）發佈衆測；

（7）發佈公司內開發者有獎體驗。

5、系統測試

測試策略和計劃指定後，開始編寫測試用例。

一、測試用例編寫

首先，爲了保證用例能覆蓋到每一個一個邏輯分支。

我先用思惟導圖把每一個邏輯梳理清楚：

但由於思惟導圖直接給初級外包去執行不方便（咱們不少中級以上的外包直接看着思惟導圖執行用例，甚至本身編寫思惟導圖用例），因此還須要將思惟導圖轉換爲用例。考慮到這個用例除了上線前的用例會每月用一次以外，其餘用例使用頻率都很低。因此只有須要交代的地方交代清楚。不須要交代的地方空着就行：

表格中最重要的信息是「功能點」和「測試點」這兩列。其餘都是須要特別提醒的地方纔補充信息。這種用例看起來比較亂，但勝在快速、實用。

編寫了單機用例以後，我又補充了各類適配用例：

這些用例都是以單機用例爲基礎。根據須要適配的內容修改一些測試條件。好比說換一個平臺，或者換一個宿主。

這裏有一點經驗能夠和你們分享：就是根據測試條件的影響範圍來選擇用例，而不是任意一個條件變了都測全用例。

好比說，覆蓋不一樣的平臺。咱們在單機測試的時候已經在win7電腦上跑了全用例。這裏須要適配win10和mac系統，是否是也要跑全用例呢？答案是否認的。由於在和開發溝通的時候，咱們已經提早了解到平臺適配只對step1有影響，其餘步驟的邏輯與平臺無關。因此這裏只用過step1相關的4條用例。用例量減小了80%。

用例編寫完成以後，有一個很容易被忽略的環節是用例評審。不少人以爲用例評審無關緊要，或者線上評審一下就行。但按照我的經驗，筆者能夠很負責任地告訴你們，對於小項目來講線下的用例評審頗有價值！由於它不但能夠發現用例的問題，還能夠經過討論發現需求和代碼實現的問題，性價比很高！

二、單機測試

執行用例的過程你們都比較熟悉了，這裏直接粘貼測試報告。

TBS Studio工具單機用例測試結果：

測試版本：TBS Studio：v1.3.1

平臺：windows7專業版64位

手機機型：OPPO A33（5.1.1 已root）

任務連接：略

測試結果：總共22條用例。19條經過，2條不經過，1條未能執行。

不經過及不能執行用例列表：

bug列表：

三、機型適配

單機用例經過後就陸續安排各類適配測試。這裏再也不展開，只分享一點經驗：

「全面」比「深刻」重要！

咱們在測試中發現了兩個有表明性的問題：

win10 32位PC上程序閃退；

7.0手機進入inspector手機閃屏。

這兩個問題都很明顯，一測就能測出來。而一樣的人力投入，若是咱們繼續測win10 64位系統或者4.x-6.x手機，就很難有這麼大的收穫。這是由於咱們在同一條件下測試越深刻，產生的邊際效益就會越小。

因此一般來講，「全面」比「深刻」重要。

四、宿主適配

略。

五、適配平臺

略。

六、Bug迴歸及上線前測試

略。

6、衆測及體驗

上線前測試經過後，咱們開始作衆測。

一、發佈衆測

公司內有2大衆測平臺：企鵝衆測和QQ衆測。企鵝衆測傾向於發散性的測試，而QQ衆測傾向於用例測試。咱們提衆測的目的是爲了發現系統測試無法覆蓋到的點，因此咱們選擇了企鵝衆測。

首先，我跟企鵝衆測的業務接口人vincent溝通了他們是否能承接咱們這類PC客戶端的測試，Vincent說能夠。

而後，我就編寫了測試要求給vincent。關於測試要求的設計，這裏提供2點經驗：

（1）測試要求要足夠簡單明確。由於用戶都是非專業認識，太複雜了他們會不懂。以tbs studio的提測爲例，咱們開始想讓用戶覆蓋不少第三方app。可是要給用戶解釋第三方app裏邊怎麼進入一個網頁是很困難的。因此咱們左後只選擇了騰訊新聞1個第三方app做爲表明。由於它進入網頁最簡單。

（2）要有明確的反饋要求，作好是格式化反饋。好比說，咱們須要瞭解用的pc和手機的信息。若是讓用戶在正文裏文字反饋，收集到的結果會很亂，也很差統計。因而，咱們把這些信息都作成了選項或獨立文本框。手機到的信息更規範也方便統計。

具體的測試要求見附件。

通過2天的問題收集。咱們獲得了40多個反饋。我對問題進行了統計分析，輸出了衆測結果報告：

TBS Studio工具衆測結果分析

測試版本：TBS Studio：v1.3.1 上線前測試版本。

測試時間：2天。

測試要求：見附件。

數據分析：

（1）公共收集反饋42條（衆測審覈後），其中成功30條，問題反饋有8條。說明遇到問題的用戶比例還很多。

（2）8個反饋中，以「inspector頁面白屏」反饋最多，有5個。另外，出現crash的用戶爲1個，佔全部win10 64用戶的1/18（以前也有很多開發者反饋這個問題）。

（3）按PC類型統計，總共32臺PC參與測試（認爲一個QQ用戶對應臺PC）。win10 64位用戶比例最大。沒有收到mac用戶反饋。

（4）按手機品牌統計，總共覆蓋8個品牌的手機。參與衆測的小米手機最多。沒有發現哪一個品牌的手機出現問題特別集中。

（5）按手機rom版本統計，覆蓋到4.x-7.x的rom版本。其中6.x的手機最多。

（6）按使用app統計，大多數用戶使用微信、手Q測試。使用騰訊新聞測試的用戶爲0。

（7）QB瀏覽器的6個反饋中，在沒有打開網頁的狀況下開始調試的用戶佔50%。說明程序的引導提示作得不夠。

二、發佈公司內開發者有獎體驗

衆測完成後，咱們又在公司bbs論壇發佈了公司內部的有獎衆測。

在一個星期的時間內，咱們收到了6份有效反饋。雖然反饋很少，可是反饋信息比較詳細。開發同事April對企鵝衆測和內部體驗的效果評價是：

「其實都還不錯，衆測覆蓋的比較廣，會容易碰到奇葩問題。此次也發現了一個inspector白屏的bug。

內部體驗的話，交流比較方便，並且大多都是須要這個工具的同事，更能給到一些建議之類的」。

7、線上數據監控

就此，tbs studio順利發佈。從後臺數據看，日活用戶數提升很多：（6月16日增加是由於衆測、內部體驗引入了新用戶，以及v1.3.1版本發佈）。