測試效能平臺最佳實踐 | 解決用戶痛點，比堆疊功能更重要！

本文為霍格沃茲測試學院優秀學員關于測試測試效能平臺開發（國際化商城智能物料平臺）的最佳實踐經驗分享。

測試效能平臺開發的難點是什么？

關于測試效能平臺開發，從技術上提供指導的文章網上比比皆是，但從 0 到 1 全面闡述測試平臺開發實戰經驗的文章就相對較少。

而且，即使對于不那么擅于寫代碼的測試同學而言，在平臺開發過程中，技術其實也沒什么難點。

最難的點在于你要利用最少的資源，在最快的時間內，選擇最合適的實現方案來解決團隊中特定的問題。

本文就記錄分享一下我在公司國際化商城項目中，作為智能物料項目 PO，從零搭建一個快速創建測試物料的工具平臺的一些心得和經驗。該項目在四個月中，迭代了 5 個版本，服務了近 200 多個用戶，幫助團隊快速創建了兩千多個物料，粗略估計相當于節省了一個員工一年多的工時。

以下是項目經驗總結，拋磚引玉，期待與大家一起探討。

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

項目 BRD

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

功能列表和描述

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

項目計劃及排期

整個平臺規劃做多久，第一期做什么，做多久，用到的人力是多少。大概示意是這樣的：

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

3.? 產品原型

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

4.? UI 設計

這是一個看臉的時代，好看的界面會叫人愿意多停留幾秒，挽留下來的這幾秒，會幫你爭取到寶貴的注意力。也許他這個激活用戶就看到了他感興趣的東西了。得不到業務需求那樣的設計資源，讓設計同學幫你出一套頁面樣式規范還是可以爭取到的。做前端頁面時盡量遵照這套樣式規范做，不會丑到哪里?？吹娜擞X得賞心悅目，自然也愿意多用。

5. 需求

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

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

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

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

這么做有兩個好處：

大降低使用者的上手成本；

實現起來也比較簡單，不用處理太多的邏輯判斷，節省寶貴的開發時間；

6.?減法藝術

做平臺工具也是做產品。做產品就要做減法?？捎锌蔁o的功能能不做就不做，交互和功能都要從減少用戶上手成本出發。比如攝影中畫面元素越少，越能凸顯主題，讓觀者一下抓住畫面的核心。

工具平臺的價值是提升工作和生產效率，如果用戶使用工具還要看很長的文檔，研究半天，我個人覺得它已經失敗一半了。有時候我們思維慣性，想把能呈現的功能能滿足的需求，都盡可能的交付給用戶，沒有考慮用戶能消化多少真正用多少。

要將用戶的使用場景代入進來，幫他恰到好處的解決了平臺能幫他解決的問題，沒有多余的操作、選擇、輸入。斷舍離很難，但很重要。

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

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

表明來意

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

找到利益共同點

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

風險規避，解除戒心

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

名單感謝

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

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

我個人以前只寫過 Python 自動化腳本，測 iOS 客戶端時學過一些 OC 和 Swift。物料平臺的后臺技術棧選擇的是 Spring，當時對于 Java 怎么使用，Spring 具體怎么用，完全是懵的。在架構師幫我們設計好架構后，買了一本 Spring 的書結合網上的教學視頻，學了依賴注入和切片就 clone 了一個公司內的 Spring 項目。

看里面的結構，啟動一個項目必備的配置文件有啥。一個簡單的 HTTP 請求從 contorller 到數據庫，需要經過哪幾層，分別做哪些處理。剛開始是十分痛苦的，都是陌生的概念和名詞，在寫通一兩個接口后，后面雖然還是有很多不會，但知道在 Google 和百度上通過哪些關鍵字搜索了。后因前端開發資源緊缺，又利用之前的套路，快速上手了 Vue.js，通過先解 bug 學習 Vue.js 的使用，再逐漸熟悉就可以慢慢的開發功能了。

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

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

自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。