歡迎大家前往騰訊雲社區，獲取更多騰訊海量技術實踐干貨哦~
作者：高苡新
團隊：騰訊移動品質中心TMQ
一、概述
本文以寫實風格記錄TBS Studio開發調試工具測試全過程。包括測試人力申請、測試策略制定、系統測試以及眾測體驗。對於測試初學者可以了解到整個流程是如何一步一步走下來的。對於有一定經驗的同學可以領略到測試策略制定過程中基於風險和成本的測試理念。
二、提測項目介紹
TBS Studio是面向基於TBS的Web開發者和移動應用開發商（包括微信、手Q，三方App等）打造的開發服務整體解決方案，以提升廣大開發者在真機環境下的開發效率，並幫助開發者分析和優化網頁的設計，主要功能有網頁Inspector調試，網頁性能分析等。
詳情：https://x5.tencent.com/tbs/guide/debug/season1.html。
三、測試人力申請
5月23日，開發同學Brian找到我，說有一個tbs studio的產品要申請測試資源。經過電話溝通，我了解到這個屬於騰訊瀏覽服務（TBS）的附屬產品，提供給開發做網頁調試用的。於是我去找我們測試組leader說明了情況。Leader說Bonnie和mekhi對網頁調試比較熟悉，建議我拉上他們一起去溝通測試需求 ——實踐證明，對於一個陌生的測試需求，多拉幾個相關的同事一起去溝通准沒錯！
第二天，我和Bonnie、mekhi一起去找到開發Brian溝通需求。經過半小時的講解，我們對測試需求有了比較清晰的了解。也明確了主要工作是項目跟進（我比較擅長），而不是通過技術手段實現測試（Bonnie和mekhi比較擅長）。下面是溝通結果記錄：（從中你可以知道測試需求溝通一般需要了解哪些東西）。
背景：
開發調試工具。主要用於提升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）外包執行測試。
四、測試策略制定
和開發溝通完需求之后，對該項目的情況有了基本的了解。接下來需要評估工作量和制定測試策略。
工時預估：
（1）測試策略制定（選擇測試方法、測試機型、覆蓋范圍等）正職2h；
（2）測試用例編寫（集成用例-目前有16個測試點、上線前用例、核心流程用例）正職6h；
（3）測試環境准備（win8、win10、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連接這類功能也沒有使用自動化測試。所以我們就放棄自動化測試了。系統測試肯定不能少。眾測和公司內體驗可以補充系統測試覆蓋不到的點，所以可以用起來。
測試策略詳情：
平台適配：
通過網上資料，我們可以看到win7、win10、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）發布公司內開發者有獎體驗。
五、系統測試
測試策略和計划指定后，開始編寫測試用例。
1、測試用例編寫
首先，為了保證用例能覆蓋到每個一個邏輯分支。
我先用思維導圖把每個邏輯梳理清楚：
但因為思維導圖直接給初級外包去執行不方便（我們很多中級以上的外包直接看着思維導圖執行用例，甚至自己編寫思維導圖用例），所以還需要將思維導圖轉換為用例。考慮到這個用例除了上線前的用例會每個月用一次之外，其他用例使用頻率都很低。所以只有需要交代的地方交代清楚。不需要交代的地方空着就行：
表格中最重要的信息是“功能點”和“測試點”這兩列。其他都是需要特別提醒的地方才補充信息。這種用例看起來比較亂，但勝在快速、實用。
編寫了單機用例之后，我又補充了各種適配用例：
這些用例都是以單機用例為基礎。根據需要適配的內容修改一些測試條件。比如說換一個平台，或者換一個宿主。
這里有一點經驗可以和大家分享：就是根據測試條件的影響范圍來選擇用例，而不是任意一個條件變了都測全用例。
比如說，覆蓋不同的平台。我們在單機測試的時候已經在win7電腦上跑了全用例。這里需要適配win10和mac系統，是不是也要跑全用例呢？答案是否定的。因為在和開發溝通的時候，我們已經提前了解到平台適配只對step1有影響，其他步驟的邏輯與平台無關。所以這里只用過step1相關的4條用例。用例量減少了80%。
用例編寫完成之后，有一個很容易被忽略的環節是用例評審。很多人覺得用例評審可有可無，或者線上評審一下就行。但按照個人經驗，筆者可以很負責任地告訴大家，對於小項目來說線下的用例評審很有價值！因為它不但可以發現用例的問題，還可以通過討論發現需求和代碼實現的問題，性價比很高！
2、單機測試
執行用例的過程大家都比較熟悉了，這里直接粘貼測試報告。
TBS Studio工具 單機用例測試結果：
測試版本：TBS Studio：v1.3.1
平台：windows7專業版64位
手機機型：OPPO A33（5.1.1 已root）
任務鏈接：略
測試結果：總共22條用例。19條通過，2條不通過，1條未能執行。
不通過及不能執行用例列表：
bug列表：
3、機型適配
單機用例通過后就陸續安排各種適配測試。這里不再展開，只分享一點經驗：
“全面”比“深入”重要！
我們在測試中發現了兩個有代表性的問題：
win10 32位PC上程序閃退；
7.0手機進入inspector手機閃屏。
這兩個問題都很明顯，一測就能測出來。而同樣的人力投入，如果我們繼續測win10 64位系統或者4.x-6.x手機，就很難有這么大的收獲。這是因為我們在同一條件下測試越深入，產生的邊際效益就會越小。
所以通常來說，“全面”比“深入”重要。
4、宿主適配
略。
5、適配平台
略。
6、Bug回歸及上線前測試
略。
六、眾測及體驗
上線前測試通過后，我們開始做眾測。
1、發布眾測
公司內有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%。說明程序的引導提示做得不夠。
2、發布公司內開發者有獎體驗
眾測完成后，我們又在公司bbs論壇發布了公司內部的有獎眾測。
在一個星期的時間內，我們收到了6份有效反饋。雖然反饋不多，但是反饋信息比較詳細。開發同事April對企鵝眾測和內部體驗的效果評價是：
“其實都還不錯，眾測覆蓋的比較廣，會容易碰到奇葩問題。這次也發現了一個inspector白屏的bug。
內部體驗的話，交流比較方便，而且大多都是需要這個工具的同事，更能給到一些建議之類的”。
七、線上數據監控
就此，tbs studio順利發布。從后台數據看，日活用戶數提高不少：（6月16日增長是因為眾測、內部體驗引入了新用戶，以及v1.3.1版本發布）。
