天天看點

APP或者Web的相容性測試的設計方法都是這樣的相容性測試的相容測試的因素從哪裡來客戶的需求埋點日志其他服務

相容性測試的相容測試的因素從哪裡來

相容性測試的相容測試因素就是SUT系統需要支援的終端類型,這裡如果是一個Web的PC服務,就需要知道那些浏覽器以及對應的版本,支援的作業系統等,如果被測系統是一個移動端的服務,那麼終端支援的作業系統、終端裝置品牌和型号等,這些也不是我們幾個測試小夥伴關在會議室裡面拍腦門拍出來的,而是通過一些必要的輸入而擷取的,這些必要的輸入有哪些呢?

客戶的需求

任何一個系統,無論是PC端的還是移動端的,要支援的裝置的需求都是從最終使用者那裡來的。那麼我們相容測試因素的一個來源就是需求,這個需要産品經理在和業務方收集需求的時候可以一起收集,但是這也是相容測試因素的收集條件之一,雖然看似最合理,但是往往卻很難拿到一個準确的答複。

埋點日志

很多已經上線的系統都有些前端埋點,我們可以從埋點日志中擷取所有通路我們服務的終端資訊,進而可以整理出一個通路我們系統的終端的類型,我們可以通過它擷取我們目前的相容性測試因素來源之一,如果擷取的種類特别多,我們往往會擷取95%的終端類型,進而支援我們絕大部分使用者,其他的就人齊自然更新裝置了,這樣就類似我們近似擷取了2個西格瑪的相容名額。當然,如果一個系統是一個全新的系統,這一個擷取方式就不起作用了。

其他服務

如果一個全新的系統,我們完全不知道怎麼處理,那麼浏覽器可以通過

https://gs.statcounter.com/

擷取目前占有量,進而來知道我們設計相容測試因素。移動端可以通過搜尋類似服務來為我們的相容性測試因素提供一些支援。

相容性矩陣設計

假設我們統計的相容性測試因素設計如下所示:

APP或者Web的相容性測試的設計方法都是這樣的相容性測試的相容測試的因素從哪裡來客戶的需求埋點日志其他服務

依據上面的相容性測試因素,結合正交實驗測試用例設計方法,我們選擇按照因素水準,我們選擇強度為2的正交計算後得到的如下正交實驗的結果:

作業系統,分辨率,浏覽器,
1,1,1,
1,2,2,
1,3,3,
2,1,2,
2,2,1,
2,3,4,
1,1,3,
2,1,4,
1,1,5,
2,1,6,
1,1,7,
2,1,8,
1,2,3,
2,2,4,
1,2,5,
2,2,6,
1,2,7,
2,2,8,
1,3,1,
2,3,2,
1,3,5,
2,3,6,
1,3,7,
2,3,8,
      

得出的相容性測試矩陣如下:

APP或者Web的相容性測試的設計方法都是這樣的相容性測試的相容測試的因素從哪裡來客戶的需求埋點日志其他服務

這樣我們就可以開始準備環境,進行相容性測試了。