測試能效平臺的誕生 - 國際化商城智慧物料平臺

技術指導性文章網上比比皆是，但對於不那麼擅於寫程式碼的測試同學而言，從頭開發一個平臺的經驗分享的文章相對較少。而在平臺開發過程中，技術其實沒什麼難點。難的在於你要利用最少的資源，最快的時間內，選擇最合適的實現方案來解決團隊中特定的問題。本文記錄我在國際化商城專案中，擔任智慧物料專案 PO，從零搭建一個快速建立測試物料的工具平臺的心得和經驗。該專案在四個月中，迭代了 5 個版本，有近 200 多個使用者，幫助團隊快速建立了兩千多個物料，粗略估計相當於節省了一個員工一年多的工時。想透過我作為 PO 的經驗，給大家在思路及心法上提供一點微薄的參考。

一. 為什麼要做這個平臺

國際化商城的物料建立（如商品、優惠券、促銷和下單等），一直是專案中多個角色最頭疼的事情。部分站點是找業務建立，部分站點是找負責相應模組的測試同學建立。無論哪種方式，這一來二去的溝通成本是極其高昂的。最極端情況下，物料準備的時間能佔到整個測試時間的三分之一到四分之一。所以解決測試物料建立的問題，可以突破商城相關測試人力佔用瓶頸。

二. 平臺從 0 到 1

1.專案 BRD

在接到這個任務的時候，是沒有任何詳細的需求，只有一個問題場景。所以要根據這個問題場景，梳理出平臺最核心的價值是什麼，要解決什麼樣的問題。從而延伸出需要解決的問題涉及的範圍是多大。我根據自己的理解編寫了 BRD，這個 BRD 包括以下內容：

1）功能列表和描述：顆粒度可以很粗，這是對平臺初期的一個定位。在開始沒有 demo 出來之前，一定不要規劃大而全的東西。實現出來的功能，一定是大家可能都會用到的功能，比如我們第一期做的就是透過選擇模板建立測試商品，因為一切的物料都是以商品為基礎。

2）專案計劃及排期：整個平臺規劃做多久，第一期做什麼，做多久，用到的人力是多少。大概示意是這樣的：

版本號	計劃時間	功能列表	投入人力
v 0.8	1.1 - 1.15	1. 功能 A；2.功能 B 3.功能 C	前端 15 天/人； 後臺 15 天/人
v 1.0	1.16 - 1.31	1. 功能 D; 2.功能 E；3.功能 F	前端 15 天/人； 後臺 20 天/人
v 0.9	2.1 - 2.15	1.功能 G；2.功能 H；3.最佳化功能 A	前端 20 天/人； 後臺 25 天/人

這個專案除了我從頭至尾是全職投入，其他同事都或多或少有其他的事。所以一份包含人力投入的專案計劃極為關鍵，這是向領導申請人力支援的憑證。如果有同事做到一半，業務纏身去做別的事情，領導一看這期要實現什麼功能，幾號就要上線，缺口了多少人力，一目瞭然。在還沒開始之前，不知道具體的功能會遇到什麼阻礙，具體需要多少人力投入，估個大概就行，實際在專案開發中，再動態調整。

3）產品原型

作為內部的工具平臺，不會有多少設計和產品資源支援。而且產品也不太瞭解你要做一個什麼樣的東西，你的流程你的期望你的訴求，產品都沒你清楚。自己要思路清晰，理出個框架，如果條件允許，可以找產品同事幫你畫出大家日常工作中熟悉的產品原型，當然你自己也可以照貓畫虎的畫出來，只要方便其他參與者更好理解和協作就行。至於功能細節及詳細的互動，在今後可以自己慢慢填充和完善。這時開始就不需要產品再次介入了。

4）UI 設計

這是一個看臉的時代，好看的介面會叫人願意多停留幾秒，挽留下來的這幾秒，會幫你爭取到寶貴的注意力。也許他這個啟用使用者就看到了他感興趣的東西了。得不到業務需求那樣的設計資源，讓設計同學幫你出一套頁面樣式規範還是可以爭取到的。做前端頁面時儘量遵照這套樣式規範做，不會醜到哪裡。看的人覺得賞心悅目，自然也願意多用。

5）需求

​ 首先你要清晰且明確的知道你們的平臺工具它的核心價值是什麼？它要解決的核心問題是什麼？圍繞這兩個問題，產品形態就會有個大概的輪廓，基於這個輪廓自己就可以往裡填充功能了。

​ 一個人或幾個人的角度畢竟有限，可以找以後的使用者做一下需求收集，聽聽他們的痛點和訴求。獲取到這些東西后一定要做過濾。從使用者側收集到的需求是有噪音的，他們會根據自己的立場和角度，可能給你一個小眾需求，只能解決少數幾個使用者的問題。這時要回過頭來審視之前那兩個問題：核心價值是什麼？解決的核心問題是什麼？

​ 舉個例子：商城中商品的建立會涉及到非常非常多的欄位，有普通屬性、銷售屬性、品牌、類目、運費模板等等。那在做商品物料建立的時候，是不是要給使用者塞很多輸入框或下拉框，這樣不就可以滿足很多不同場景的測試需求了。NO! 商品的建立介面，我們只給使用者一個下拉框選擇平臺定義好的最常用的幾個商品模板，兩個輸入框一個輸價格一個輸入庫存，就沒有了，簡單易用，完全是傻瓜式建立。

為什麼這麼做？多數人對於商品這些琳琅滿目的繁雜欄位是不敏感的，他們也不清楚那些到底有啥含義。給他那麼多輸入項，反而造成了困擾，不知道如何入手。他們的訴求很簡單，就是要一個某個型別測試商品，能用就行。我們挑選一些最最常用的幾種型別的商品（不同欄位的組合），透過模板事先定義好，供使用者選擇。對於商品某些欄位有高要求的使用者，他們本身已經明白這些欄位的含義，完全可以在運營端自己去操作。即使滿足了多欄位選擇的需求，他們後面也有可能不用。因為你再全也沒有運營端全。

​ 這麼做有兩個好處：一、極大降低使用者的上手成本 二、實現起來也比較簡單，不用處理太多的邏輯判斷，節省寶貴的開發時間 。

6）減法藝術

​ 做平臺工具也是做產品。做產品就要做減法。可有可無的功能能不做就不做，互動和功能都要從減少使用者上手成本出發。比如攝影中畫面元素越少，越能凸顯主題，讓觀者一下抓住畫面的核心。工具平臺的價值是提升工作和生產效率，如果使用者使用工具還要看很長的文件，研究半天，我個人覺得它已經失敗一半了。有時候我們思維慣性，想把能呈現的功能能滿足的需求，都儘可能的交付給使用者，沒有考慮使用者能消化多少真正用多少。你要將使用者的使用場景代入進來，幫他恰到好處的解決了平臺能幫他解決的問題，沒有多餘的操作、選擇、輸入。斷舍離很難，但很重要。

三、跨團隊協作

做工具平臺免不了其他團隊的支援和協助，比如物料平臺需要涉及多個研發團隊和部門，有的甚至是跨地域的部門。在此特別感謝一下在平臺建設過程中曾經幫助過我們的同事們。在他們百忙的工作中，抽空幫忙處理和解決與他們業務以及績效毫無相關的事情。

後來接觸的部門和人多了以後，也逐漸有了一點點自己尋求幫助的方式和心得。

1）表明來意

在尋求不認識的同事協助的時候，要清晰明確言語簡潔的表達清楚目的和意圖。

2）找到利益共同點

比如我們搭建了物料平臺後，對於某些模組的研發同事來說。測試同事可以擠出更多的時間，好好測試他們的開發的需求，同時物料平臺解決了因測試物料建立不當而引發的事故，就再沒有人找他們緊急處理事故了。最後他們自己在除錯功能時，再不需要找測試同學幫忙建立物料了。

3）風險規避，解除戒心

物料平臺會調很多模組的介面，輕者入參錯誤觸發報警，重者介面暴露使用不當會有一定事故風險。本來是想著幫你，但一不小心，給自己添了麻煩。這就要我們事先幫他解除顧慮。我會事先和他們講出我想到的風險，並告訴我的風險規避方案。比如我在調介面的時候先撈線上的 log 模擬入參，再在測試環境調介面，調沒問題了，再切預發或線上。又比如我在調商品建立的介面時，硬編碼寫死某個商品的屬性，來和線上正式商品做隔離，避免使用者使用不當或誤操作引發的事故。

4）名單感謝

平臺上線後，在開發者人員名單中，一一感謝曾經幫助和提供協助的同事們，這本來就供內部使用的平臺，名單再長也無礙。雖然他們不一定會看，有一天一旦在這個名單中搜尋到自己的名字時，看到你如此珍視他們哪怕一點點的付出，也是讓人心悅的。

四. 做平臺，作為測試，需要做哪些技術準備

我的答案是，用什麼學什麼。

我個人以前只寫過 Python 自動化指令碼，測 iOS 客戶端時學過一些 OC 和 Swift。物料平臺的後臺技術棧選擇的是 spring，當時對於 Java 怎麼使用，spring 具體怎麼用，完全懵的。在架構師幫我們設計好架構後，買了一本 spring 的書結合網上的教學影片，學了依賴注入和切片就 clone 了一個公司內的 spring 專案。看裡面的結構，啟動一個專案必備的配置檔案有啥。一個簡單的 http 請求從 contorller 到資料庫，需要經過哪幾層，分別做哪些處理。剛開始是十分痛苦的，都是陌生的概念和名詞，在寫通一兩個介面後，後面雖然還是有很多不會，但知道在 google 和百度上透過哪些關鍵字搜尋了。後因前端開發資源緊缺，又利用之前的套路，快速上手了 vue，透過先解 bug 學習 vue 的使用，再逐漸熟悉就可以慢慢的開發功能了。

技術的革新很快，行業變革的也很快。不論研發還是測試，我們所面對的是日新月異的測試框架、技術和工具。在這個快速變化的行業裡，掌握一招吃一輩子的情況越來越少見了。有了紮實的基礎技術儲備，比如熟練掌握一門程式語言，知道計算機和網路傳輸的原理，程式的幾種常見設計模式等等，就能快速掌握和駕馭新框架、技術和工具。上層東西是不斷變化的，向下走，他們底層原理都是大同小異，就像建築造型無論怎麼改變，他都是需要有地基和承重的。

希望這些對於大家在測試平臺的搭建上有一些思路上的幫助。