文章轉載來源：微信公眾號-光榮之路，也歡迎大家關注我自己的公眾號，雖然很少發東西吧，，，

為了更方便的轉載於大家檢視，我對內容作了下排版。。。

1.10 Bug預防體系

1.10.1 web常見產品問題及預防

1.   多個ie同時訪問

使用者可能開啟不同的IE使用相同的使用者登入後進行操作，程式處理的時候要考慮到資料的一致性和同步問題。

多個IE使用不同使用者，則cookie操作不會出現使用者資訊混亂的問題

預防方法：

開發：提前考慮到多個IE操作和多使用者操作的使用場景，在使用cookie本地資訊時需要做好針對性的程式處理，依據以往出現的問題設計開發規範

測試：按照多瀏覽器和多使用者的使用情況，進行更多場景的測試

2.   安全考慮

在URL中不要帶有明文的使用者資訊寫程式碼的時候，不要把密碼等敏感的使用者資訊明文的顯示在url中。

即使要傳遞密碼引數也不要使用pwd、 passpord這樣的引數名稱來進行傳遞，防止被截獲。

要在傳遞引數的操作中使用NoCache引數，防止將url引數進行快取。

預防方法：

開發： 建立資料傳輸技術規範和引數命名規範標準，嚴格參照執行，防止資訊被攔截，造成應用系統的資訊洩露。

測試：在快取目錄驗證快取資訊是否有敏感資訊，通過抓包方式驗證是否暴露了敏感資訊。

3.   直接URL連結檢查

在Web系統中，匿名在位址列直接輸入各個功能頁面的URL地址，檢查系統是否處理了許可權控制。

預防方法：

開發：程式碼走查的方式確認所有頁面的具有許可權驗證邏輯。

         測試：獲取所有系統url，在非登入情況下進行遍歷截圖，或關鍵字判斷，驗證非登入狀態下無法訪問具有訪問許可權限定的。

4.   防止sql注入和跨站攻擊

不要把資料庫或者程式的任何報錯資訊顯示在頁面上。

資料庫中設計到操作許可權的表名和欄位名不要使用過於通俗易懂的命名，尤其是使用者和密碼之類的資訊，禁止使用明文儲存密碼。

頁面回顯的inputtext, input hidden中的文字內容需過濾 “ <、 >、 ”、 ’等字元（半形轉換為全形或者刪除掉），防止 Javascript 的跨站攻擊。

預防方法：

開發：出錯的時候使用錯誤處理頁面，建立標準的過濾關鍵字程式，統一資料庫設計命名規範將敏感的表名做特殊命名處理，密碼使用Md5或其他加密方式儲存。

測試：驗證所有頁面不會暴露系統的任何出錯資訊使用安全工具appscan 或其他工具掃描系統的sql注入漏洞和跨站攻擊漏洞。

5.   關於cookie

Cookie沒有設定過期時間IE不支援Cookie的時候沒有任何提示資訊Cookie中的敏感資訊沒有進行加密。

預防方法：

開發：明確cookie生存期，並對生成的cookie進行檢查，建立標準的檢查瀏覽器對cookie支援的程式函式

測試：檢查cookie的生存週期，以及是否存在敏感內容

6.   各種資源連結的釋放

有的時候，系統莫名訪問不了，有可能是資料庫連線沒有釋放壓力測試的時候，連線釋放如果效率不高，則有可能出現大量連線超時失敗記憶體洩露，長時間工作記憶體被佔滿了。

預防方法：

開發：系統資源的釋放過程，最好通過程式碼review的方式來互相監督

測試：進行穩定性測試，驗證長時間工作情況下的資源是否可以釋放

關於keepalive的設定：

如果需要在一個連線同時獲取多個資源，則需要開啟apache或者resin的Keepalive引數為On，來提高系統的處理能力，減少多次建立連線所消耗的資源。如果大量的處理只是一次性連線，則不要開啟Keepalive設定。在實際工作中，需要將keepalive分別設定On或者Off來驗證哪個設定的效能更好。

7.   系統上線的log配置

上線以後，要關閉無用大量除錯log資訊不要開啟過多的log

預防方法：

運維和開發：系統管理員對所有開啟log級別進行確認，並群發相關人確認

8.   使用者易用性

使用者刪除某個資料前，要明確提示使用者是否要刪除，預設把焦點選擇為“否”。

預防方法：

開發：按照上述要求進行焦點設定

         測試：進行測試確認

9.   文件

程式實現和介面文件描述不一致

預防方法：

開發：團隊中專人定期對介面文件進行稽核和更新，保證文件、需求變更和程式實現保持一致

測試：僅參照文件進行測試

10.         多表操作

詳細設計文件缺失，介面對多表進行操作時候，經常會發生有些表的資料沒有被更新的情況

預防方法：

開發：稽核設計文件是否覆蓋必要的邏輯，加強程式碼審查

測試：通過查詢介面判斷所有插入介面的資料庫操作是否正確等等，這些我們完全可以在不斷測試過程中進行總結和積累，可以給開發進行培訓，讓他們瞭解這些常見的問題，在自測時注意這些問題，提高送測產品的質量。

1.10.2 app常見產品問題及預防

1.   介面適配

a：手機解析度為1920x1080的高解析度手機，在調整手機字型大小時，會導致頁面顯示出現變形；

b：因使用者設定的特殊字型導致列表的字母條不顯示；

c：某些 banner 圖片在部分機型只能顯示一半。

預防方法：

a：文字或者圖片需要適配不同解析度的機型時，建議使用dp方式進行開發，即使是使用dp,也需要考慮特殊解析度的機型顯示；

b：適應寬度/適應高度/高寬均適應的；

c：針對程式需求，設定合適的。

2.   系統適配

a：呼叫高版本API，導致某些機型進入主頁顯示空白頁面。

預防方法：

a：呼叫高版本API，需要考慮相容性，開發團隊需要制定程式API呼叫規範。

3.   互動適配（1）

a：在輸入框操作時，調出系統輸入法軟鍵盤後，沒有有效啟用鍵盤上的 “下一項”、“確定”、“搜尋”等按鍵；

b：系統軟鍵盤，在關閉當前頁面時沒有及時收起軟鍵盤。

預防方法：

a：需求設計過程中需要考慮輸入法操作鍵的使用細節，確保所有軟鍵盤的輸入鍵可使用；

b：設計規範：程式/頁面設計針對輸入法操作鍵的使用制定規範

4.   互動適配（2）

a：APP介面的“返回”操作與手機系統的“返回”按鍵操作效果不一致；或介面未提供“返回”，在無系統“返回”按鍵的手機上，無法返回。

預防方法：

a：設計規範：程式設計針對手機返回鍵制定使用規範；

b：在設計中要綜合介面需求設定是否提供 “返回”操作。

5.   介面風格

a：對話方塊標點、英文字元出現全形、半形的不統一；

b：對話方塊、提示浮動框提示語風格不同，顯示位置均不同，產品友好度下降；

c：字型和字號要在app中是不同的風格。

預防方法：-語言文字提示規範

a：全形字元和半形字元都要使用一個空格分開；

b：英文和數字之間要有空格分開；

c：漢字和英文、數字要有空格分開；

d：帶有漢字的話要使用全形字元；

e：語言中不要混用全形和半形標點；

f：字型和字號要保持統一的風格。

6.   效能優化(1)

a：進入一些列表，若數量較多則會出現卡死:；

b：介面顯示物件數量較多，某些會導致頁面操作卡頓，使用者體驗很差；

c：處理大量資料時，使用者等待時間過長，無進度條提示進度。

預防方法： 

a：程式對耗時較多的操作邏輯、判斷邏輯，不放入UI主執行緒；

b：對資料庫記錄較多的操作，可以改成資料庫批量操作，或者呼叫批量介面；c：程式在後臺處理使用者的輸入，則提供進度條或對話方塊。

7.   效能優化(2)

a：後臺播放記憶體洩露；

b：程式後臺執行的時候，手機一直處於佔用CPU的執行狀態；

c：頁面中的動態效果（如：馬燈滾動）次數無限制，導致介面不斷重新整理消耗資源。

預防方法： 

a：使用靜態分析工具或程式碼檢查方式檢查內容的分配和釋放；

b：WakeLock機制是防回收技術，當沒有播放、下載等操作時，應該主動關閉後臺的喚醒鎖，減少耗電。當再次需要使用播放、下載功能時才去開啟喚醒；

c：對重新整理消耗資源類操作，要有次數限制。

8.   多服務、多程序

a：某些功能操作後， app 無法連線網路；

b：程序被殺死後重啟，通知欄中顯示的資訊不正確，沒有顯示正確的資訊；

c：app未啟動，通過其他第三方app的呼叫入口呼叫app ,無法正常使用某些功能；

d：服務停止後，無法被啟動；

f：程式被手動退出後，程序仍然在後臺存在。

預防方法： 

a：重新初始化時獲取值時讀取到空值，因此賦予一個預設值；

b：服務重啟被回收重啟時，初始化物件時要判斷當前是否已存在，若存在則複用並更新內容

c：任務獨立，需要建立不同的服務，生命週期不會互相影響，服務獨立可以避免某個服務結束會影響到其他功能的正常使用。

總體，對有啟用多服務、多程序的程式，有需要做好服務、程序的一致性管理。

9.   外部呼叫

a：某些機型啟動app之後一直在呼叫某些外部服務（通過後臺服務可以看到其他服務程序，退出app後，有些服務程序消失）

b：某些功能模組被掃描成存在木馬病毒；

c：安全管家告警程式獲取絕密許可權（通訊錄許可權）。

預防方法： 

a：呼叫第三方功能作為統計或者監控作用時，需要考慮該sdk是否會一直喚醒app導致耗電或者程式無法真正關閉問題；

b：呼叫外部第三方SDK，要考慮被安全工具（上次有廣告被掃描到病毒）掃描的設計需求；

c：及時關閉不需要的服務程序，在能滿足需求的情況下，儘量減少使用敏感的系統許可權。

10.         網路機制(1)

a：網路重試操作機制不統一，導致頁面超時體驗風格不統一；

b：某些應用頁面，訪問響應慢。 

預防方法： 

a：對底層網路重試機制做統一封裝後，供上層呼叫；

b：固定好每次重試間隔（建議10s重試）和重試總次數（建議3次）；

c：為使頁面提示可以區分網路層與業務解析層不同錯誤，需對不同錯誤型別做分類的異常處理，並提示使用者原因或讓使用者重試；

d：對多個網路請求的介面，網路介面並行請求有利於提高響應速度。

11.         網路機制(2)

a：未載入完圖片時切換到相似tab，切回不再載入圖片；

b：進入一個tab，該頁面已經載入完成，選擇點選某個詳細資訊頁面返回時，頁面會閃一下。 

預防方法： 

a：一個頁面有多個tab頁時，使用者切換tab可不輕易取消執行緒，取而代之使用暫停執行緒，退出頁面時才回收清除；

b：啟動負載分攤機制的請求，可先儲存請求地址，供返回時判斷避免重複載入。

12.網路機制(3)

a：iOS弱網路下獲取不到配置，導致啟動卡死；

b：sim卡未啟用，無行動網路，某些功能卡死；

c：斷網下啟動，登入狀態丟失，某些功能資訊未正確顯示。

預防方法： 

a：啟動邏輯中的網路類請求不能阻塞UI主執行緒，即網路請求資料可不即時響應（可在下次啟動時生效）；

b：按鈕的點選事件不跟介面關聯，做成非同步處理不管是否有返回，都可以正常進行點選操作；

c：離線操作類，不因與當前網路狀態有影響。

13.下載空間有效性判斷

a：空間不足時，無法儲存資訊時，沒有提示和提前判斷；

b：本地儲存空間不足時，儲存檔案時沒有相應提示；

c：空間不足時，檔案下載不成功，導致重複不停下載，浪費使用者流量。

預防方法： 

a：對磁碟剩餘空間的判斷和自動清理邏輯可以做統一封裝，提供各不同下載業務使用

b：可結合系統硬體配置的10%作為有效剩餘空間閥值；

c：針對手機內外接SDCard，可以在空間不足情況下做分割槽切換機制。

14.下載檔案完整性判斷(1)

a：換膚圖片未下載完，就觸發換膚操作，導致換膚效果錯誤；

b：圖片無法下載完全，導致圖片展示不完整；

c：檔案下載完成後，由於網路錯誤與原始檔不符，導致下載後無法播放；

d：上傳檔案功能，目標物理檔案不存在（介面缺顯示存在），導致傳送檔案頁面一直處於等待中。 

預防方法： 

a：通過判斷下載前後文件的size或者檔案內容簽名，確保下載檔案完整後再觸發檔案使用相關的邏輯；

b：檔案傳輸時檢查檔案是否存在，若不存在則視為傳輸失敗，不阻塞後續傳輸。

15.阻斷連續操作

a：連續快速切換介面，或者頻繁觸發某些功能操作，導致程式卡死；

b：連續多次點選同一張圖片，導致該圖片下載錯誤。

預防方法： 

a：使用間隔響應、延遲響應的方式，達到多次相同操作只的觸發一次有效邏輯。

b：操作一次後，可將按鈕等元素設定為禁用狀態，防止使用者多次點選和請求。

16.有效統計邏輯

a：操作頁面某些元素，也會導致傳送頁面使用的統計資訊。

預防方法： 

a：為確保統計資料上傳的有效性，只針對真正展示的介面做上報統計，對於展示不完整、非針對性展示不做統計上報。

17.程式健壯性判斷(1)

a：分享到新浪微博（手機未裝新浪微部落格戶端） ,app崩潰；

b：後臺介面變更（返回值和型別發生變化），客戶端不相容新格式判斷，丟擲崩潰異常；

c：搜尋預設操作崩潰；

d：使用外部第三方資料，出現空資料或者非標準格式，則app崩潰

e：輸入框沒有限制字元長度，儲存時導致溢位崩潰。

預防方法： 

a：客戶端針對介面返回需做容錯處理，如返回為空、返回資料型別不一致；

b：任何文字框型別的需要限制輸入長度。

18.程式健壯性判斷(2)

a：某些功能的初始化邏輯沒有加入啟動邏輯，導致功能使用失敗；

b：退出重啟app，無法自動登入。

預防方法： 

a：制定啟動載入邏輯規範；

b：對於重要的業務建議加入啟動邏輯，並在業務實際使用時再根據狀態多一層判斷和載入；

c：產品人員需要考慮是否需要儲存自動登入功能，並明確告之開發和測試人員。

19.安全機制

a：在URL中不要帶有明文的使用者資訊寫程式碼的時候，不要把密碼等敏感的使用者資訊明文的顯示在url中；

b：即使要傳遞密碼引數也不要使用pwd、 passpord這樣的引數名稱來進行傳遞，防止被截獲；

c：要在傳遞引數的操作中使用NoCache引數，防止將url引數進行快取。

預防方法： 

a：建立標準的資料傳輸和命名規範，並製作一些網頁開發模板或者規範供參考。

20.日誌除錯管理

a：上線以後，除錯日誌沒有關閉，影響程式效能。

預防方法： 

a：日誌統一開關，編譯正式包需要關閉；

b：再程式介面有入口可以檢查是否關閉，方便及時校驗；

c：方便定位問題，可以做日誌動態開啟的隱藏開關；

d：方便收集問題，可以對問題型別做上報處理（典型如崩潰日誌上報）。

產品測試規範綱要

目  錄

第1章 產品測試規範

1.1 產品測試流程

1.1.1 測試流程圖

1.1.2 測試流程說明

1.2 需求梳理

1.2.1 需求梳理

1.3 測試計劃

1.3.1 測試工具選取

1.3.2 測試人員分配

1.3.3 測試業務場景選取

1.3.4 測試環境梳理

1.3.5 測試資料梳理

1.4 測試準備

1.4.1 程式碼管理

1.4.2 測試環境搭建

1.4.3 測試資料指令碼編寫

1.5 測試用例編寫(功能測試框架)

1.5.1 介面友好性測試

1.5.2 功能測試

1.5.3 業務流程測試(主要功能測試)

1.5.4 連結測試

1.5.5 容錯測試

1.5.6 穩定性測試

1.5.7 常規效能測試

1.5.8 易用性測試

1.5.9 相容性測試

1.6 測試執行

1.6.1 介面自動化測試

1.6.2 探索式測試

1.6.3 傳統測試用例測試

1.6.4 Bug跟蹤

1.7 測試結果分析

1.7.1 結果收集

1.7.2 結果分析

1.7.3 測試分析報告

1.8 上線準備

1.8.1 版本釋出

1.8.2 資料準備

1.9 上線測試跟蹤

1.9.1 跟蹤測試

1.10 BUG預防體系

1.10.1 web常見產品問題及預防

1.10.2 app常見產品問題及預防

1.11 BUG管理規範

1.11.1 bug提交規範

1.11.2 bug級別定義