精準測試之項目案例實戰大剖析

精準測試之項目案例實戰大剖析

1、        前言
測試是保證產品質量的關鍵環節，不管是從開發人員開始的單元測試，集成測試，到測試人員的系統測試，產品的需求測試，客戶的驗收測試，都是爲了保證產品可以更健壯的在市場上服務於用戶，可是測試的整個工做和過程並不像開發的工做同樣有一個產品的產出，因此更大程度上增長了對測試工做質量的考覈，也就形成了對產品測試完成後沒法有一個可靠的依據去判斷是否可以保證產品在市場中穩定運行，測試過程當中也必然存在着在各類各樣的問題和困難。
在傳統的測試中，測試後期每每會出現以下幾個問題：
1.        測試範圍不足、漏測
常常出現開發改動測試不知道、或者測試範圍評估不足以及測試人員對產品沒有足夠的瞭解等都會致使測試漏洞風險高，成爲線上事故的導火線，並指望可以經過代碼覆蓋率工具提升覆蓋度。
2.        進度、時間趕，上線內心沒底
測試：「時間太緊，感受沒測試全就上線啦！再有幾天就行了。」時間緊迫，根本沒法規劃本身的測試思路和範圍，感受本身沒有測全，內心沒有底兒。若是能夠有工具幫助作測試的篩選和統計就行了，經過代碼覆蓋率判斷產品是否可以達到上線標準。
3.        測試迴歸範圍大、成本高
有時候開發給出的迴歸範圍太大，致使測試迴歸測試成本很高。時間上和人員上都須要大量的資源投入，仍是但願可以經過代碼覆蓋率工具作到精準測試，從而下降沒必要要資源的投入，提升工做的效率。

4.        測試與開發關係溝通問題
測試和開發在後期交流中因人爲交際因素每每產生各類不可預計的情況
如：

友好：
開發修改完代碼後，測試人員直接詢問開發是否測試過，若是開發本身測試過一遍，測試就認爲已經測試完畢。
矛盾：
出現重大問題後，開發和測試相互推卸責任，致使團隊開發和測試關係僵化。

下圖爲2015年某明星互聯網產品公司線上事故的範圍：

咱們能夠看到，在整個事故中一大半都是由於開發與測試溝通或測試對業務不瞭解，遺漏而產生的故障。要避免這樣的事故，首先須要把佔比高的問題解決，就能夠從很大程度上提高產品的質量。
那咱們該如何去解決這些問題，咱們從下面的九點鐘項目案例中講解對於提升測試的覆蓋率，測試開發的溝通，測試的遺漏，測試範圍評估錯誤等如何有效的利用現有資源進行解決。
2、        九點鐘項目簡介
九點鐘酒店控項目是一款酒店垂直細分領域的鐘點房預約APP，它可讓用戶經過手機端的應用預約上海的合做酒店，方便快捷，經過自動定位選擇附近的可預訂酒店，以及按照價格和距離等選擇合適的酒店進行預約，經濟實惠，提早預約，解決外出住宿問題。將來，它還會跟更多的旅遊頻道合做，發展空間很大。
  
3、        目的
本文描述九點鐘項目的安卓APP，在精準化測試平臺（星雲測試）經過測試獲得測試報告以及相關的測試數據分析，經過手工黑盒測試和程序內部的邏輯測試對整個應用的質量把控，下降產品上線後存在的問題。
4、        測試用例的設計
採用常規的邊界值分析法，正交分析，因果圖，以及等價類劃分等多種方法進行測試用例的設計，例如：
一、        對於輸入框字符長度有限制的採用限制字符數的邊界值進行測試用例設計
二、        對於搜索項進行因果圖方法設計測試用例
三、        對於酒店列表篩選進行正交分析法進行測試用例的設計
四、        根據用戶的體驗習慣進行探索性測試等
5、        測試環境與配置
一、        本地環境（雲測試版本，主須要配置本地的客戶端使用環境，服務在雲端不需配置）
二、        PC端測試網絡須要可以連通星雲測試服務端的地址便可
三、        手機端的可使用WIFI，或使用USB鏈接測試
6、        測試方法和測試工具
測試方法：
採用黑盒手工測試的方法，進行測試
測試工具：
採用星雲測試Android雲測試版客戶端2.1.4版本進行測試，該工具經過手動的黑盒測試驅動，檢測和記錄程序內部的執行邏輯，快速定位BUG，而且自動捕捉程序崩潰點，測試迴歸篩選，測試數據整合展現雲測試精準報表，對於測試人員、設備以及測試任務執行時間按照天爲單位進行統計用圖表形式展現整個過程的趨勢。而且對整個項目的代碼質量重複度，複雜度，可維護性等進行了指標分析和展現。
注意事項：
            下面的分析均有代碼表述，如測試人員無查看代碼權限，可只使用測試數據和開發人員進行交互分析，開發人員經過星雲平臺測試數據在本地關聯代碼進行配合分析。
7、        代碼的靜態分析



不少項目到了後期都會出現較難維護的狀況，主要是由於代碼量的增長以及開發人員的變更或代碼的編寫規範致使對其後續人員對內部邏輯理解困難。
經過靜態監測分析咱們能夠看出九點鐘項目在代碼中缺乏了大量的註釋，並引用了大量的重複代碼以及違規的代碼，重複代碼會形成重複部分容易出現缺陷重複等問題，違規代碼會形成代碼的易讀性和維護變得困難，而且還會存在潛藏的代碼邏輯BUG以及資源關閉等等代碼中容易出現錯誤的地方，所以要根據一個特定的規則集進行代碼的規範，這些雖然在項目生成以及使用上不存在問題，可是考慮到開發人員的交替以及後期的維護缺存在了大量的風險。
經過靜態指標但是化查看違規以及重複的代碼位置，用此數據報告和開發進行交互並可要求對代碼進行改善
   
8、        測試用例執行與分析
1.        測試用例執行分析
測試用例總數：136
執行測試用例：129
缺陷數目：60
測試用例經過率：67%

根據測試用例的執行來了解測試人員工做量和工做效率，以及整個測試的最終大概結果，經過率以及完成度，管理人員可以隨時根據實際狀況作出進度和工做上的安排調整，更好的管理團隊和監督整個產品的測試進度。
2.        缺陷分類：


根據BUG分類和嚴重程度的數據課判斷該版本的總體質量，如果嚴重的BUG佔比過高，則可能根據項目須要是否打回開發從新測試後再交於測試進行測試，保證不會有太多的流程上的缺陷，致使測試工做停滯不前，影響版本發佈的實際時間。
3.        測試用例與缺陷的狀況：

經過星雲測試測試過程監控趨勢圖，咱們分析清晰地看到，項目九點鐘在這幾天的測試中的BUG發現狀況，並經過測試用例執行得日期與BUG提交日期以及描述判斷出，具備大量BUG的模塊。如9點鐘在2015-12-7號的時候作了不少測試用例以及提交了很多的BUG。
經過直觀的曲線繪製圖可以看到一週內或截至目前爲止整個測試工做期間BUG的發現率和測試用例的執行狀況，測試人員的參與人數，根據實際要求進行管理和調整。
咱們查看詳細信息的描述
  
BUG的詳細列表顯示的是全部發現的BUG以及每一個BUG對應的提交人員和出現的測試環境以及對應的測試用例，都有利於咱們判斷BUG出現的主要因素和修復的方法，便於開發去修復而且也會考慮到同類環境下的兼容狀況。
如：能夠看出2015-15-7咱們測試的重點主要在優惠卷、訂單、支付等領域模塊，在這個模塊中出現很多的友好度或者操做上的問題，測試人員就能夠拿此數據和開發進行交互，要求對這些模塊進行總計修改。
9、        測試覆蓋率與漏洞分析
按需求文檔以及功能說明書設計並進行測試運行，經過星雲測試查看出每日覆蓋率增加趨勢



在這幾天的測試中，測試人員雖然遍歷了完整的流程，可是覆蓋率一直不高，段覆蓋率才41.1針對這種狀況，咱們經過漏洞分析進行查找緣由。

首先咱們經過星雲報表找出複雜度高密度以及覆蓋率0，這些都是測試漏洞，風險較高的遺漏點，若不逐一解決，後期上線後產生的問題形成的影響多是相對比較嚴重地，爲了不這一現象的產生，咱們必須把這些毒素攻克掉。這時，若是測試人員不懂代碼能夠邀請開發進行協助查看，經過可視化界面查看該函數的代碼。
如1：函數ID 1465 handleMessage 經過代碼可視化和開發交流得知，此模塊爲處理列表的上拉下拉的事件，可是在最新的九點鐘項目中已經不在使用，這就形成了測試人員沒法遍歷到該模塊的緣由，對於這些廢代碼，測試人員有義務要求開發對其註釋掉，或者進行刪除處理，這樣使得後期對代碼的維護有了保障。

如2：函數ID 1880 isrefreshview scroll經過代碼可視化和開發交流得知，此模塊爲優惠卷拉昇加載功能，可是此功能須要優惠卷超過必定量後纔會出現，可是實際測試中，測試人員只獲得了一張優惠卷的帳號，在遍歷中天然沒法覆蓋到該功能。

如3：函數ID 1530 zoom經過代碼可視化和開發交流得知，此模塊爲主界面地圖功能，覆蓋率不高的緣由是：
該函數主要針對地圖的比例進行不一樣的比例值選擇，地圖調節的狀況，可是在九點鐘中的地圖是調用百度地圖，若是要所有覆蓋，須要後臺對其代碼進行相應的改動模擬。此情況主要針對核心功能的測試，測試人員須要預判該模塊是否須要各類後臺狀態的處理測試，並和開發交互後進行配合性覆蓋率提高。



如4：函數ID 1449 onClick經過代碼可視化和開發交流得知，此模塊爲酒店評論功能， 根據可視化分析
  
查到由於沒有測試到酒店評論中評的狀況，因此沒有覆蓋到，執行次數是0，須要設計用例，酒店評論中評的狀況，提升測試的覆蓋率，保證沒有嚴重的測試漏洞
10、        代碼級測試BUG快速追蹤
Eg: BUG ID :  1
BUG描述：無網絡狀況下，列表和菜單沒法點擊，須要優化，友好一些
經過BUG代碼級追溯獲得緣由：雙向追溯頁面根據BUG用例追蹤到代碼，顯示無網絡狀況下點擊菜單後，沒有任何提示，也不可以正常調用和執行，所以須要優化，建議開發人員添加相關提示。

測試不可是從功能上進行測試，還要以用戶的身份去用戶交互測試，體驗測試，這些是直接影響到用戶直接使用的，要想用戶對產品有粘性，必需要作到用戶體驗更好，因此一些建議是頗有必要的，這也是測試職責內須要作到的。
11、        測試團隊人員分析
在以往的測試中，評價一個功能測試團隊和測試人員，主要看他的尋找BUG的能力，可是在實際中，因測試項目的質量以及測試人員對業務的理解和測試人員的工做年限，不光只能靠BUG來進行評定。
星雲報告經過對測試人員運行的測試用例、測試用例的覆蓋率、測試用例BUG等關聯，直接反映測試人員的測試情況，避免前言第4條測試與開發關係溝通問題，以及有針對性的對測試人員進行指導。
如：某個測試人員設計的測試用例很全面，運行遍歷後，星雲測試的報表覆蓋率也很高，可是卻始終發現不了BUG，這時咱們能夠斷定爲2種狀況：第一種，該測試人員測試的項目確實沒有很大的問題，第二種，測試人員對業務的理解有可能存在誤差，雖然運行了大部分的功能，可是BUG也包括友好度、邏輯輸出等，這些都是業務理解層面的，針對這種狀況，能夠對該測試人員進行業務上的指導。


12、        測試設備分析
在不少測試場景中，測試人員在測試過程當中沒有發現任何問題，可是客戶在使用過程當中缺平凡出錯，這些問題有很多是由於兼容性致使。如九點鐘項目，開發在15/11/23發的最新版中，測試人員出現主界面點擊功能無效和閃退等現象，可是開發那邊缺沒有任何問題，進排查開發使用的是android5.0以上手機，而測試人員使用的是android4.2-4.4手機。
針對上述問題，通常公司或者甲方都會要求測試團隊配備主流的機型以及經常使用分辨率的手機，避免該事故。
星雲測試報告會在測試人員在測試過程當中記錄該測試人員使用的測試設備，並和測試用例、BUG等進行關聯，能夠有效地管理整個測試設備的使用以及對應狀況。
    


十3、        測試用例、代碼、模塊的追溯關聯
開發人員的變動時致使項目維護困難的重大緣由之一，在九點鐘項目中，咱們經過運行平臺進行測試，把測試用例與其運行的函數進行關聯，這使得後續開發人員或測試人員對起功能的理解能夠經過測試用例與代碼的關聯進行，大大下降了開發人員經過開發文檔、交接文檔、本身閱讀別人寫的代碼所消耗的時間。

在前言中提到：考慮不全，開發修改，測試範圍評估錯誤，在傳統的測試中，開發人員改動某個功能後，因開發人員不知道該功能會影響多少其它的調用功能，致使在和測試交代改動功能時候，每每會出現遺漏，以致於測試範圍評估錯誤，經過星雲測試用例、代碼、模塊的追溯關聯，開發人員很明確的能看出某條代碼對應的測試用例，以致於在修改過程當中更多的考慮一致性修改。


十4、        迴歸測試用例自動選取
在迴歸中因開發迴歸範圍大或避免測試遺漏迴歸範圍，每每在迴歸過程當中要求測試進行所有迴歸，可是又因時間緊等因素致使測試不全，上線後測試心理沒底。
在9點鐘項目中，星雲平臺經過迴歸測試用例的自動選取，提取須要迴歸的版本的測試用例以及該版本以前全部版本的測試用例進行查詢，獲取每條測試用例最後運行的版本進行數據提取，並經過測試用例、代碼、模塊的追溯關聯技術，與要回歸的版本進行比對。分析出開發改動所影響最大的迴歸測試用例。

在測試時間不充足的狀況，能夠經過該功能和開發人員一塊兒對其測試用例進行評估，圈定測試用例迴歸的範圍，從而下降測試迴歸的成本。
以上的分析和講解是星雲測試平臺對九點鐘app進行測試後的真實數據，而且全部的案例都是咱們的測試人員和開發人員相互溝通協同完成的，讓開發和測試互動溝通，可以提升整個團隊的工做效率，而且從該工做過程當中也鍛鍊了測試發現問題的能力和判斷問題的源頭的分析能力，對產品內部程序的邏輯有更深入的接觸和了解，達到精準測試，減小沒必要要的工做量，保證產品質量，無高風險測試漏洞，上線更穩定。