從使用者反饋說起

“我備份的照片怎麼不見了”；

“出現伺服器錯誤-1001”；

“下載的照片無法顯示”。

使用者反饋，測試過程中經常遇到各種與後臺相關的非必現問題，對於一個重後臺功能的產品，包括很多業務邏輯和使用者的資料都與後臺強相關，若只是通過客戶端來測試後臺功能的話，在遇到上述問題時，分析和重現問題對於測試人員來說非常困難。

除此以外，在日常的測試中，後臺相關的測試還面臨以下幾類問題：

1、後臺測試的充分性和完整性的保證；

2、不與客戶端直接互動的功能，無法通過客戶端的用例來直接覆蓋到所有功能點；

3、面對一些偶現問題，無法定位問題，不知從何下手；

4、後臺的一些服務改動和釋出，迴歸測試非常耗時。

為了解決後臺測試面臨的問題，於是開啟了產品後臺測試的探索之路，按照以下思路進行：分析產品的後臺架構->客戶端互動的後臺介面測試->TAF後臺介面測試->後臺服務效能測試。

分析產品的後臺架構

下圖是產品後臺的部分架構，由分片上傳服務，業務處理服務，使用者資料服務，照片壓縮和照片加密服務組成。

業務處理模組：該服務主要實現業務邏輯功能，包括圖片上傳、圖片下載、建立相簿和圖片分類，如下圖所示。該服務中的介面都是與客戶端直接互動的。可以通過模擬客戶端的請求來測試業務處理模組中的介面。

使用者資料服務：使用者檔案儲存的是使用者圖片相關的資訊，例如圖片的SHA，URL等，使用者資料儲存的是聯絡人資訊和簡訊資訊。

圖片壓縮服務：壓縮圖片成為各種合適尺寸的圖片縮圖；

加密服務：加密服務包括加密資料介面和加密金鑰介面；

使用者資料服務，圖片壓縮服務和加密服務，這三個服務的介面是不直接與客戶端進行互動的，無法通過客戶端模擬請求來測試，因此針對這三種服務的介面通過訪問TAF介面的方式來進行測試的。

圖存平臺和TFS等屬於外部公共介面，暫時不在測試範圍內。

與客戶端的後臺介面測試

框架接入和問題解決

通過客戶端測試後臺因為其他產品已有現成的框架，新產品的接入只需要分析現有框架是否適用或是否需要做二次開發。

1、分析框架是否適用，產品前後臺介面通訊協議都是使用的shark協議，評估並測試後確認可以使用現有的框架來開發用例；

2、分析產品的介面，我們產品的介面功能都依賴於登入態，大部分介面都需要校驗登入態loginkey，因此需要搞定登入態的問題；

（1）參考手Q快速登入提供的WTLoginSDKDemo，修改其中的引數appid為對應產品相簿的appid，並且把該SDK整合到後臺測試框架中；

（2）啟動測試後，根據輸入的QQ帳號密碼拿到即通返回的A2票據，存入到SD卡中，A2票據的有效期為1個月；

（3）QQ帳號及A2作為登入介面的WTLogin的請求引數，解析介面的返回結果拿到登入態Loginkey；

（4）Loginkey是作為後臺登入態的唯一校驗。

3、產品介面請求引數photoInfos中的SHA是需要校驗的，需要獲取真實照片的photoInfos。

（1）單獨出一個公共類PhotoInfoUtil構造phtoInfos中的請求引數欄位；

（2）編寫獲取照片SHA的函式;

（3）介面測試用例中的請求引數SHA直接呼叫PhotoInfoUtil.create(path).sha賦值。

後臺介面應用案例

1、需求描述

新功能照片地圖的照片標籤功能，客戶端通過上傳本地照片的經緯度資訊到後臺，後臺通過呼叫騰訊地圖的API返回城市資訊給客戶端，客戶端顯示在照片地圖上顯示城市資訊

2、測試分析

（1）蘋果系統使用的是高德地圖的API，而我們的產品後臺使用的是騰訊地圖的API，需要測試城市資訊是否顯示一致；

（2）選擇城市的測試樣本，一是參考產品使用者照片地點的分佈，二是參考螞蜂窩熱門旅遊城市，最後綜合考慮選擇了螞蜂窩的270個熱門旅遊城市作為測試樣本；

通過客戶端手工測試，需要人工準備270個熱門城市的照片，測試結果也需要人工判斷，預計耗時需要5天；

（3）分析後臺介面，請求引數中填寫照片經緯度資訊，批量構造270個熱門城市的經緯度資訊存入陣列中，通過請求介面CSBatchGetAddrByCoord返回270個熱門城市的城市資訊，預計耗時1.5天；

（4）照片地圖照片標籤功能，客戶端只是上傳照片的資訊到伺服器和顯示城市資訊結果，無複雜業務邏輯和互動操作，照片標籤功能適合用後臺介面測試來完成。

3、測試效果

一共發現了六類城市資訊顯示問題，已經通過對映的關係解決部分重點問題，測試效率提升了70%，特別在後續的迴歸測試中5分鐘即可以完成一次測試。

後臺TAF介面測試

使用者資料服務的介面不與客戶端互動，是後臺TAF介面，通過直接訪問TAF介面來進行測試。

TAF知識準備篇

JCE檔案：JCE檔案是TAF框架中客戶端和服務端的通訊協議，是一種類C++語言的識別符號，用於生成具體的服務介面檔案，瞭解JCE的語法規則，關鍵字，基本型別，複雜型別，名字空間和介面是做TAF介面測試的基礎。詳細知識可參閱《TAF-使用指南和規範》。

Makefile：TAF框架提供了一個makefile.taf的基礎Makefile，使用TAF實現的服務，需要遵從Makefile規範：（1）原則上一個目錄是一個Server或者程式，即Makefile只能有一個Target，（2）需要包含其他庫時，根據依賴關係倒序include在Makefile檔案底部。

TAF框架使用：做TAF介面測試僅需要了解C++客戶端的使用，客戶端對服務端完成收發包操作是通過通訊器(communicator)來實現的，通訊器可以使用配置檔案初始化通訊器，也可以直接使用屬性初始化，通訊器不需要自己建立，直接採用服務框架中的通訊器即可。

單個介面測試

（1）連線伺服器, 定義初始化伺服器變數taf::CommunicatorPtr _comm;
伺服器init函式。

Locator:registry服務的地址，必須有ip port的，如果不需要registry來定位服務，則不需要配置。

Property：屬性上報地址，如果沒有配置，則上報的資料直接丟棄。

（2）請求TAF介面，選擇轉換DataInteface.jce檔案成 c++語言，在生成的DataInteface.h中找到服務的介面操作類typedef taf::TC_AutoPtr DataInterfacePrx;定義變數QQPIM::DataInterfacePrx client;

以上是介面long getDataList(long UIN, string dbdir, out vectorreslist)請求服務操作，getDataList是介面名，UIN和”cont”是請求引數，relist是伺服器響應結果。
（3）編譯執行，寫好的介面測試程式碼放到linux伺服器上執行，可以通過跳板機登入，編譯通過的可執行檔案，傳送到伺服器上執行。

Makefile檔案包括編譯需要的JCE檔案外，還需要有編譯依賴的工具類庫檔案，值得注意的是不同的服務Makefile檔案可能不一樣。

舉例：加密服務和使用者資料服務的Makefile檔案所包含的庫檔案就有區別：

多個介面測試

分析介面之間的關係，其中多個介面之間存在依賴關係的（即前一個介面的輸出結果是後一個介面的輸入引數），則可以通過在一個測試類中實現多個介面測試函式來實現。

TAF介面每日監控執行

1、是由一個shell指令碼qqpimtest.sh執行所有介面的可執行檔案，並把執行結果重定向到檔案qqpimtest.txt中；
2、解析介面測試生成的報告文件，將文件報告資料進行HTML編碼；
3、通過伺服器上的郵件系統，將郵件定時傳送出去，郵件模版如下圖所示。

未來測試計劃

本篇文章介紹的是在專案中如何從0開始做後臺測試，主要側重的是專案後臺架構的分析，測試後臺介面功能，能解決後臺功能測試的問題。涉及到介面穩定性和高負載情況下伺服器處理超時問題是部分偶現問題出現的源頭，因此下一步會重點研究後臺效能測試。

關注微信公眾號，獲取更多測試乾貨：騰訊移動品質中心TMQ！