海量使用者-高並發SAAS產品測試上線流程

標籤：

海量使用者高並發SAAS產品測試上線流程SAAS產品測試上線流程-以Web外掛程式產品為例子1   概述

在互連網產品中，IT公司之間更加註重產品功能之間的協作，SAAS形態的產品扮演著越來越重要的作用。

一個典型的完全由宿主代理的SAAS服務的通訊流程如：

這樣的產品一般具有如下特點：

• 一般由第三方提供專門的服務
• 通常以網路為媒介來提供服務
• 具備嵌入的用戶端功能
• 具備第三方服務端功能
• 一般不以獨立的產品形式直接面向客戶
• 一般需要整合“寄生”在宿主產品中來面向客戶

SAAS形態的主要產品有：

• 天氣預報外掛程式
• 站長統計工具，如CNZZ
• 論壇外掛程式
• 網路廣告，如：百度廣告，Google Ads
• 站內搜尋引擎
• 分享社交外掛程式，如：JiaThis
• 移動app資料統計外掛程式,如：友盟
• 移動app廣告外掛程式

作為SAAS服務提供者，對於此類產品的開發和維護有優點也有缺點。

優點如下：

• 發布行為的成本很低，直接利用網路發布
• 版本維護成本較低，可以全網統一維護
• 小而快迭代發布能夠避免重大問題產生
• 直接透明化地面向客戶能夠保證資料的快速通達和反饋

缺點如下：

• 伺服器並發容量要高

  因為此服務是提供給B端使用者，B端使用者再打包提供給C端使用者，這個量的成長性是很可觀的。伺服器必須在效能上有較高要求

• 服務端和用戶端介面穩定性要高（有版本包袱）

  在使用量上升之後，作為SAAS產品，肯定是需要不斷的快速迭代升級。由於此產品在和宿主產品整合之後，就相當於 “一言既出” ，可能已經有成千上萬的使用者在使用此介面了。必須要注意前後的介面相容性

• 用戶端相容性強（有平台包袱）

  一般對於涉及到前端的Web產品來說，IE6/IE7/IE8是在PC下繞不過去的曆史包袱。如果Web產品還涉及到行動瀏覽器端，則以Android的片段化裝置的現狀，不同的主流機型也是繞不過去的曆史包袱

整體來說，一個完整的帶 服務端 和 用戶端 的產品的主要測試上線流程如下：

1. 伺服器/用戶端各自單元測試
2. 服務端介面測試
3. 伺服器端效能測試
4. 端到端功能測試(整合測試)
5. 平台相容性測試
6. 全網灰階測試

2   可測性架構

正如之前的文章裡面提到過，一個適合做測試的系統，必然是一個架構上 可測性 比較好的系統。目前比較典型和主流的互連網應用的系統基本上都有比較好的可測性，其典型的架構如所示：

此架構最典型的特點就是，做到伺服器和用戶端的有效分離，現在隨著平台的多樣化，用戶端已經有但不限於如下幾種：

• App

  • Android
  • iOS
  • Windows Phone

• Browser

• Client

備忘

為了便於描述，以上架構可以分別簡稱 A/S 、 B/S、 C/S ,整體架構圖可以認為是 “典型的ABC/S網路產品架構圖”

3   單元測試

單元測試是涵蓋在每個子項目裡面的，由開發人員完成的。主要涉及的內容是函數一層的，開發人員需要對主要的演算法函數進行輸入和輸出的校正，這樣在重構或者代碼修改的時候，可以進行有效迴歸測試，防止新的修改影響了舊的代碼。

單元測試是必須的，單元測試做得越多，問題就會發現得越及時。但是在實際操作過程中，考慮到投資報酬率，可以只對主要的核心函數功能進行單元測試的自動化代碼編寫，即只需要付出20%的代價就能產生80%的回報的這部分函數功能。使用這樣的2/8原則，也並不用擔心有 漏網之魚，因為後續還有其它的測試會進行有效補充的。

備忘

上面提到的2/8原則是指 單元測試自動化代碼 的開發原則，而不是說單元測試的原則，單元測試其實在開發過程中就已經在做了，用於驗證開發代碼的正確與否，單元測試其實是一直在使用，只是沒有寫成自動化的代碼，迴歸性差而已。對於迴歸要求很強的函數，則盡量編寫自動化的單元測試代碼。

4   介面測試

介面測試嚴格來說是屬於 白盒測試 的範疇。在如上的系統架構中，伺服器端為用戶端提供介面服務，即：用戶端向伺服器端發起請求（Http或者socket），然後伺服器端針對請求做相應的操作，並返回相應的流（一般是經過編碼的json/xml字串或者圖片二進位流）。

介面層次做自動化相對其它層次是最容易的，同時也是 投資報酬率（ROI） 最高的。因為最上層面向客戶的UI，本質上是通過業務層的資料來驅動的。而此處業務層的資料的最直接體現就是服務端的介面。

以目前主流的服務端介面（通過http通訊，以json作為字元編解碼）為例子，可以很容易通過一些自動化架構，例如： pyunit，在資料層面類比介面操作產生的業務流，進行資料的自動化比對判斷。

一般通行的技術手段是：

• pyunit自動化測試架構組織用例
• requests庫類比http請求
• json庫進行編碼解碼
• pyunit的assert的函數進行判斷

具體執行效果如下：

備忘

使用了可視化的python的IDE運行pyunit程式得到的結果，左邊的提示如果全部是綠色的，表示本檔案中的所有單元測試用例都通過。

介面測試的主要內容：

• 請求介面，對單介面的輸入和輸出內容進行判定
• 類比業務操作，對多介面實現的業務流進行判定

由於本文的重點在於講述流程，關於具體的工具的使用，後續的文章裡面會詳細介紹，在此就略去不表。

基本上，如果測試案例足夠而且基本上採用了自動化的方式，伺服器端的90%以上的問題都能以很低的測試成本在此階段給暴露出來。

5   效能測試

服務端通過介面測試之後，這樣還不夠，在正式在生產伺服器上發布前，需要做效能測試。因為之前的介面測試也只是類比了單用戶端，在正式上線時，不僅僅是代碼邏輯問題，還會涉及到代碼效能問題。

比較典型的就是12306火車票線上購買網站，雖然在商務邏輯上是走通的，沒有問題的。但是只要逢節假日，來自全國各地買票請求極度密集，但是伺服器的負載能力沒有跟上，就直接導致服務崩掉。所以在上線前，需要進行效能測試，能夠得出一些具體的效能指標，然後和實際的生產環境做對比，做好一些預案工作。

預案工作包括但不限於如下幾點：

• Web應用程式調優
• Web伺服器核心調優
• 中介軟體緩衝等等調優
• 增加Web叢集機器

截至此時，伺服器端的測試工作算是基本上完成了。

6   功能測試

並不是所有的功能都是可以做介面測試的。介面測試只是在資料層面對伺服器端提供服務的能力進行檢測，但是面向使用者的程式，最終互動的對象畢竟是人而不是代碼，所以就存在像介面顯示等等涉及到終端使用者的互動層次的問題，而這些問題只能通過 端到端（End To End） 的功能測試來解決了。

端到端的測試主要是對互動介面層的檢測，由於有了介面測試，端到端的功能測試的工作量也會顯著得到減輕。

在首次進行端到端的功能測試時，可能會講究覆蓋率，和介面測試的用例有大量的重複，但是隨著時間的推移和測試次數的增加，測試人員也會變得有經驗，後期的迭代工作中功能測試的工作量將顯著減輕。有經驗的測試人員會逐漸挑選出和介面測試等價的功能測試用例進行剔除，最後只留下少量的介面測試實在是無法完成的功能測試用例。

由於端到端的功能測試是把產品或服務當作一個整體進行驗證，是類比真實的使用者情境的測試，而且基本上只能靠手工來實現，所以是最耗時和測試策略，而且迴歸性差，一般不建議大量使用此策略，建議能夠在單元測試或者介面測試階段發現和解決的，盡量在那些階段發現和解決的，就不要留在使用者級。使用者級的功能測試只是用來驗證，而不應該用來做發現。

備忘

此處所說的功能測試還不是平台相容性測試，而是在介面測試的基礎之上，在互動介面層進行 功能通透 的操作測試，只需要在最主流和平台上進行驗證即可。例如，Web應用一般使用Chrome瀏覽器作為主流驗證平台

7   相容性測試

SAAS產品的優點在於不用過多考慮全網的版本統一的問題，但是缺點很明顯，因為受眾是全網的使用者，所以要盡量保證全主流平台的相容性問題。

目前流行的應用程式平台有：

• PC端瀏覽器

  • IE6/7/8/9/10/11
  • Chrome
  • Firefox
  • Safari
  • 搜狗/獵豹/360/QQ瀏覽器

• 移動端瀏覽器

  • UC
  • /手Q/QQ瀏覽器
  • Chrome
  • FireFox
  • Safari
  • Andoird原生瀏覽器
  • iOS原生瀏覽器
  • 搜狗/獵豹/360

• PC系統

  • XP/Win8/Win8以上
  • Mac OS
  • Linux Desktop

• 移動平台

  • Android
  • iOS
  • Windows Phone

測試人員需要酌情對這些平台進行相容性測試。

這些還只是不同的平台，還沒有考慮一些片段化的裝置，例如以 片段化 著稱的Android生態系統，不同的機型的表現力都會有差異。

通常，有經驗的相容性測試人員，會知道一些平台的問題 等價性 ，從而盡量避免輪詢式的測試。

下面分享一些相容性測試的經驗：

• PC瀏覽器

  • 基本上IE6的問題最多，最老的古董
  • IE6/7/8可以劃分為一個大類，IE7和IE8基本上也容易出問題
  • Chrome上測試沒有問題的，IE9及以上基本上也不會有問題
  • 緩衝問題需要注意，防止出現測試環境就沒有搭建好的誤測

• 移動端瀏覽器

  • 基本上Chrome沒有問題的，其它瀏覽器都沒有問題

    因為移動智能終端出現得比較晚，出身的時候就是基於webkit核心來產生的瀏覽器

  • 注意移動端瀏覽器的  雲加速 功能

    這樣的緩衝會導致出現測試環境就沒有搭建好的誤測

  • 手機QQ和內建瀏覽器需要單獨重點測試

    這兩個APP的使用使用者量大，而且針對普通瀏覽器做了較多修改，目前很多基於IM分享的頁面都是直接在此app裡面內嵌開啟

• 移動端

  • Android和iOS關於擷取webview的寬度的方法不同，存在前端布局相容問題
  • 不是所有的裝置都能對h5完美支援
  • Android/iOS/WindowsPhone關於Web的觸摸響應會有一些不同

8   灰階測試（發布）

之前的測試要麼是在開發環境要麼就是在測試環境，但是最終服務是需要上線到生產伺服器上來產生價值的。由於要往生產伺服器上進行遷移，就產生了環境的變化，使用灰階測試（發布）有如下好處：

• 儘早發現  代碼環境原理級 問題並提前解決

  生產環境和開發環境無法保證完全一致，故可能存在 代碼環境原理級 問題。雖然說已經事先約定了盡量保持開發環境和生產環境的一致性，但是顯然也是無法完全做到一致（比如生產伺服器一般使用linux-server，但是開發人員則可能使用的是linux-desktop或者mac-os）

• 儘早發現  規模量級 的問題並提前解決

  面向生產環境的代碼存在效能和網路節點等等 規模量級 的問題。對於並發量，實際承受值和理論值可能有差距;使用者訪問由於地區問題，可能存在網路不通暢或者緩衝問題而導致服務不能正常

灰階測試（發布）可以避免“非黑即白”這種絕對的發布境況，能夠有效避免新版本上線後造成全網所有使用者功能不能正常使用的情景，能夠在問題擴大之前，就發現並解決問題。

關於如何做好灰階測試（發布）也是有具體的方法策略，此處先只闡述流程，方法另講。

灰階測試的具體實現方法，需要對軟體工程，具體商務程序，應用程式部署，系統架構都要有相當的瞭解才能設計出比較好的針對自己應用的灰階流程，有如下注意事項：

• 應用系統具有可  灰階 性

  這點和 可測性 差不多的意思，需要在結果上有所調整，能夠通過一些配置來對同一時間的使用者做A/B分開的測試

• 應用系統需要具有一定的  復原 能力

  一旦灰階過程中出現重大問題，需要回撤的時候，應該盡量有補救復原措施

以上注意事項，都是需要有良好的技術能力才能實現好。

9   小結

不同的測試策略應用於不現的測試階段：

• 單元測試

  在開發階段由開發人員編寫和使用。用於函數層級的模組測試和故障診斷

• 介面測試

  在設計完畢後參考設計文檔由測試開發人員進行編寫，在伺服器生產代碼構建並部署測試環境後進行使用。用於介面層級的模組測試和故障診斷。基本上服務端的絕大多數問題都要在此處發現並進行解決，後面的流程只是做輔助驗證工作而已

• 效能測試

  在測試環境下對服務的負載能力進行測試，提前知道其負載能力

• 功能測試

  在用戶端和伺服器端完成聯調，構建好用戶端，在使用者層面用於功能完整性驗證

• 灰階測試

  對生產環境的遷移進行驗證式的測試，形成平滑的發布

截至此處，本文也只是對SAAS產品的基本測試理論和流程進行宏觀的介紹，後續再講具體的實現方法，畢竟光有好的模式 還不夠， 必須要有相應的 先進方法 進行實踐落地，才能產生巨大的 生產力 。

作者:	Harmo哈莫
作者介紹:	https://zhengwh.github.io
技術部落格:	http://www.cnblogs.com/beer
Email:	[email protected]
QQ:	1295351490
時間:	2015-10
著作權聲明:	歡迎以學習交流為目的讀者隨意轉載，但是請 【註明出處】
支援本文:	如果文章對您有啟發，可以點擊部落格右下角的按鈕進行 【推薦】

海量使用者-高並發SAAS產品測試上線流程