精準測試之項目案例實戰(zhàn)大剖析
一、 前言
測試是保證產(chǎn)品質量的關鍵環(huán)節(jié)，不論是從開發(fā)人員開始的單元測試，集成測試，到測試人員的系統(tǒng)測試，產(chǎn)品的需求測試，客戶的驗收測試，都是為了保證產(chǎn)品能夠更健壯的在市場上服務于用戶，但是測試的整個工作和過程并不像開發(fā)的工作一樣有一個產(chǎn)品的產(chǎn)出，所以更大程度上增加了對測試工作質量的考核，也就造成了對產(chǎn)品測試完成后無法有一個可靠的依據(jù)去判斷是否能夠保證產(chǎn)品在市場中穩(wěn)定運行，測試過程中也必然存在著在各種各樣的問題和困難。
在傳統(tǒng)的測試中，測試后期往往會出現(xiàn)如下幾個問題：
1. 測試范圍不足、漏測
經(jīng)常出現(xiàn)開發(fā)改動測試不知道、或者測試范圍評估不足以及測試人員對產(chǎn)品沒有足夠的了解等都會導致測試漏洞風險高，成為線上事故的導火線，并期望能夠通過代碼覆蓋率工具提高覆蓋度。
2. 進度、時間趕，上線心里沒底
測試：“時間太緊，感覺沒測試全就上線啦！再有幾天就好了?！睍r間緊迫，根本無法規(guī)劃自己的測試思路和范圍，感覺自己沒有測全，心里沒有底兒。如果可以有工具幫助做測試的篩選和統(tǒng)計就好了，通過代碼覆蓋率判斷產(chǎn)品是否能夠達到上線標準。
3. 測試回歸范圍大、成本高
有時候開發(fā)給出的回歸范圍太大，導致測試回歸測試成本很高。時間上和人員上都需要大量的資源投入，還是希望能夠通過代碼覆蓋率工具做到精準測試，從而降低不必要資源的投入，提高工作的效率。
4. 測試與開發(fā)關系溝通問題
測試和開發(fā)在后期交流中因人為交際因素往往產(chǎn)生各種不可預計的狀況
如：
友好：
開發(fā)修改完代碼后，測試人員直接詢問開發(fā)是否測試過，如果開發(fā)自己測試過一遍，測試就認為已經(jīng)測試完畢。
矛盾：
出現(xiàn)重大問題后，開發(fā)和測試相互推卸責任，導致團隊開發(fā)和測試關系僵化。
下圖為2015年某明星互聯(lián)網(wǎng)產(chǎn)品公司線上事故的范圍：
我們可以看到，在整個事故中一大半都是因為開發(fā)與測試溝通或測試對業(yè)務不了解，遺漏而產(chǎn)生的故障。要避免這樣的事故，首先需要把占比高的問題解決，就可以從很大程度上提升產(chǎn)品的質量。
那我們該如何去解決這些問題，我們從下面的九點鐘項目案例中講解對于提高測試的覆蓋率，測試開發(fā)的溝通，測試的遺漏，測試范圍評估錯誤等如何有效的利用現(xiàn)有資源進行解決。
二、 九點鐘項目簡介
九點鐘酒店控項目是一款酒店垂直細分領域的鐘點房預定APP，它可以讓用戶通過手機端的應用預定上海的合作酒店，方便快捷，通過自動定位選擇附近的可預訂酒店，以及按照價格和距離等選擇合適的酒店進行預定，經(jīng)濟實惠，提前預定，解決外出住宿問題。未來，它還會跟更多的旅游頻道合作，發(fā)展空間很大。
三、 目的
本文描述九點鐘項目的安卓APP，在精準化測試平臺（星云測試）通過測試得到測試報告以及相關的測試數(shù)據(jù)分析，通過手工黑盒測試和程序內(nèi)部的邏輯測試對整個應用的質量把控，降低產(chǎn)品上線后存在的問題。
四、 測試用例的設計
采用常規(guī)的邊界值分析法，正交分析，因果圖，以及等價類劃分等多種方法進行測試用例的設計，例如：
1、 對于輸入框字符長度有限制的采用限制字符數(shù)的邊界值進行測試用例設計
2、 對于搜索項進行因果圖方法設計測試用例
3、 對于酒店列表篩選進行正交分析法進行測試用例的設計
4、 根據(jù)用戶的體驗習慣進行探索性測試等
五、 測試環(huán)境與配置
1、 本地環(huán)境（云測試版本，主需要配置本地的客戶端使用環(huán)境，服務在云端不需配置）
2、 PC端測試網(wǎng)絡需要能夠連通星云測試服務端的地址即可
3、 手機端的可以使用WIFI，或使用USB連接測試
六、 測試方法和測試工具
測試方法：
采用黑盒手工測試的方法，進行測試
測試工具：
采用星云測試Android云測試版客戶端2.1.4版本進行測試，該工具通過手動的黑盒測試驅動，檢測和記錄程序內(nèi)部的執(zhí)行邏輯，快速定位BUG，并且自動捕捉程序崩潰點，測試回歸篩選，測試數(shù)據(jù)整合展示云測試精準報表，對于測試人員、設備以及測試任務執(zhí)行時間按照天為單位進行統(tǒng)計用圖表形式展示整個過程的趨勢。并且對整個項目的代碼質量重復度，復雜度，可維護性等進行了指標分析和展示。
注意事項：
下面的分析均有代碼表述，如測試人員無查看代碼權限，可只使用測試數(shù)據(jù)和開發(fā)人員進行交互分析，開發(fā)人員通過星云平臺測試數(shù)據(jù)在本地關聯(lián)代碼進行配合分析。
七、 代碼的靜態(tài)分析
很多項目到了后期都會出現(xiàn)較難維護的情況，主要是因為代碼量的增加以及開發(fā)人員的變動或代碼的編寫規(guī)范導致對其后續(xù)人員對內(nèi)部邏輯理解困難。
通過靜態(tài)監(jiān)測分析我們可以看出九點鐘項目在代碼中缺少了大量的注釋，并引用了大量的重復代碼以及違規(guī)的代碼，重復代碼會造成重復部分容易出現(xiàn)缺陷重復等問題，違規(guī)代碼會造成代碼的易讀性和維護變得困難，并且還會存在潛藏的代碼邏輯BUG以及資源關閉等等代碼中容易出現(xiàn)錯誤的地方，因此要根據(jù)一個特定的規(guī)則集進行代碼的規(guī)范，這些雖然在項目生成以及使用上不存在問題，但是考慮到開發(fā)人員的交替以及后期的維護缺存在了大量的風險。
通過靜態(tài)指標可是化查看違規(guī)以及重復的代碼位置，用此數(shù)據(jù)報告和開發(fā)進行交互并可要求對代碼進行改善
八、 測試用例執(zhí)行與分析
1. 測試用例執(zhí)行分析
測試用例總數(shù)：136
執(zhí)行測試用例：129
缺陷數(shù)目：60
測試用例通過率：67%
根據(jù)測試用例的執(zhí)行來了解測試人員工作量和工作效率，以及整個測試的最終大概結果，通過率以及完成度，管理人員能夠隨時根據(jù)實際情況做出進度和工作上的安排調整，更好的管理團隊和監(jiān)督整個產(chǎn)品的測試進度。
2. 缺陷分類：
根據(jù)BUG分類和嚴重程度的數(shù)據(jù)課判斷該版本的整體質量，若是嚴重的BUG占比太高，則可能根據(jù)項目需要是否打回開發(fā)重新測試后再交于測試進行測試，保證不會有太多的流程上的缺陷，導致測試工作停滯不前，影響版本發(fā)布的實際時間。
3. 測試用例與缺陷的情況：
通過星云測試測試過程監(jiān)控趨勢圖，我們分析清晰地看到，項目九點鐘在這幾天的測試中的BUG發(fā)現(xiàn)情況，并通過測試用例執(zhí)行得日期與BUG提交日期以及描述判斷出，具有大量BUG的模塊。如9點鐘在2015-12-7號的時候做了很多測試用例以及提交了不少的BUG。
通過直觀的曲線繪制圖能夠看到一周內(nèi)或截至目前為止整個測試工作期間BUG的發(fā)現(xiàn)率和測試用例的執(zhí)行情況，測試人員的參與人數(shù)，根據(jù)實際要求進行管理和調整。
我們查看詳細信息的描述
BUG的詳細列表顯示的是所有發(fā)現(xiàn)的BUG以及每個BUG對應的提交人員和出現(xiàn)的測試環(huán)境以及對應的測試用例，都有利于我們判斷BUG出現(xiàn)的主要因素和修復的方法，便于開發(fā)去修復并且也會考慮到同類環(huán)境下的兼容情況。
如：可以看出2015-15-7我們測試的重點主要在優(yōu)惠卷、訂單、支付等領域模塊，在這個模塊中出現(xiàn)不少的友好度或者操作上的問題，測試人員就可以拿此數(shù)據(jù)和開發(fā)進行交互，要求對這些模塊進行總計修改。
九、 測試覆蓋率與漏洞分析
按需求文檔以及功能說明書設計并進行測試運行，通過星云測試查看出每日覆蓋率增長趨勢
在這幾天的測試中，測試人員雖然遍歷了完整的流程，但是覆蓋率一直不高，段覆蓋率才41.1針對這種情況，我們通過漏洞分析進行查找原因。
首先我們通過星云報表找出復雜度高密度以及覆蓋率0，這些都是測試漏洞，風險較高的遺漏點，若不逐一解決，后期上線后產(chǎn)生的問題造成的影響可能是相對比較嚴重地，為了避免這一現(xiàn)象的產(chǎn)生，我們必須把這些毒素攻克掉。這時，如果測試人員不懂代碼可以邀請開發(fā)進行協(xié)助查看，通過可視化界面查看該函數(shù)的代碼。
如1：函數(shù)ID 1465 handleMessage 通過代碼可視化和開發(fā)交流得知，此模塊為處理列表的上拉下拉的事件，但是在最新的九點鐘項目中已經(jīng)不在使用，這就造成了測試人員無法遍歷到該模塊的原因，對于這些廢代碼，測試人員有義務要求開發(fā)對其注釋掉，或者進行刪除處理，這樣使得后期對代碼的維護有了保障。
如2：函數(shù)ID 1880 isrefreshview scroll通過代碼可視化和開發(fā)交流得知，此模塊為優(yōu)惠卷拉升加載功能，但是此功能需要優(yōu)惠卷超過一定量后才會出現(xiàn)，但是實際測試中，測試人員只得到了一張優(yōu)惠卷的賬號，在遍歷中自然無法覆蓋到該功能。
如3：函數(shù)ID 1530 zoom通過代碼可視化和開發(fā)交流得知，此模塊為主界面地圖功能，覆蓋率不高的原因是：
該函數(shù)主要針對地圖的比例進行不同的比例值選擇，地圖調節(jié)的情況，但是在九點鐘中的地圖是調用百度地圖，如果要全部覆蓋，需要后臺對其代碼進行相應的改動模擬。此狀況主要針對核心功能的測試，測試人員需要預判該模塊是否需要各種后臺狀態(tài)的處理測試，并和開發(fā)交互后進行配合性覆蓋率提升。
如4：函數(shù)ID 1449 onClick通過代碼可視化和開發(fā)交流得知，此模塊為酒店評論功能， 根據(jù)可視化分析
查到因為沒有測試到酒店評論中評的情況，所以沒有覆蓋到，執(zhí)行次數(shù)是0，需要設計用例，酒店評論中評的情況，提高測試的覆蓋率，保證沒有嚴重的測試漏洞
十、 代碼級測試BUG快速追蹤
Eg: BUG ID : 1
BUG描述：無網(wǎng)絡情況下，列表和菜單無法點擊，需要優(yōu)化，友好一些
通過BUG代碼級追溯得到原因：雙向追溯頁面根據(jù)BUG用例追蹤到代碼，顯示無網(wǎng)絡情況下點擊菜單后，沒有任何提示，也不能夠正常調用和執(zhí)行，因此需要優(yōu)化，建議開發(fā)人員添加相關提示。
測試不但是從功能上進行測試，還要以用戶的身份去用戶交互測試，體驗測試，這些是直接影響到用戶直接使用的，要想用戶對產(chǎn)品有粘性，必須要做到用戶體驗更好，所以一些建議是很有必要的，這也是測試職責內(nèi)需要做到的。
十一、 測試團隊人員分析
在以往的測試中，評價一個功能測試團隊和測試人員，主要看他的尋找BUG的能力，但是在實際中，因測試項目的質量以及測試人員對業(yè)務的理解和測試人員的工作年限，不光只能靠BUG來進行評定。
星云報告通過對測試人員運行的測試用例、測試用例的覆蓋率、測試用例BUG等關聯(lián)，直接反映測試人員的測試狀況，避免前言第4條測試與開發(fā)關系溝通問題，以及有針對性的對測試人員進行指導。
如：某個測試人員設計的測試用例很全面，運行遍歷后，星云測試的報表覆蓋率也很高，但是卻始終發(fā)現(xiàn)不了BUG，這時我們可以判定為2種情況：第一種，該測試人員測試的項目確實沒有很大的問題，第二種，測試人員對業(yè)務的理解有可能存在偏差，雖然運行了大部分的功能，但是BUG也包括友好度、邏輯輸出等，這些都是業(yè)務理解層面的，針對這種情況，可以對該測試人員進行業(yè)務上的指導。
十二、 測試設備分析
在很多測試場景中，測試人員在測試過程中沒有發(fā)現(xiàn)任何問題，但是客戶在使用過程中缺平凡出錯，這些問題有不少是因為兼容性導致。如九點鐘項目，開發(fā)在15/11/23發(fā)的最新版中，測試人員出現(xiàn)主界面點擊功能無效和閃退等現(xiàn)象，但是開發(fā)那邊缺沒有任何問題，進排查開發(fā)使用的是android5.0以上手機，而測試人員使用的是android4.2-4.4手機。
針對上述問題，一般公司或者甲方都會要求測試團隊配備主流的機型以及常用分辨率的手機，避免該事故。
星云測試報告會在測試人員在測試過程中記錄該測試人員使用的測試設備，并和測試用例、BUG等進行關聯(lián)，可以有效地管理整個測試設備的使用以及對應情況。
十三、 測試用例、代碼、模塊的追溯關聯(lián)
開發(fā)人員的變更時導致項目維護困難的重大原因之一，在九點鐘項目中，我們通過運行平臺進行測試，把測試用例與其運行的函數(shù)進行關聯(lián)，這使得后續(xù)開發(fā)人員或測試人員對起功能的理解可以通過測試用例與代碼的關聯(lián)進行，大大降低了開發(fā)人員通過開發(fā)文檔、交接文檔、自己閱讀別人寫的代碼所消耗的時間。
在前言中提到：考慮不全，開發(fā)修改，測試范圍評估錯誤，在傳統(tǒng)的測試中，開發(fā)人員改動某個功能后，因開發(fā)人員不知道該功能會影響多少其它的調用功能，導致在和測試交代改動功能時候，往往會出現(xiàn)遺漏，以至于測試范圍評估錯誤，通過星云測試用例、代碼、模塊的追溯關聯(lián)，開發(fā)人員很明確的能看出某條代碼對應的測試用例，以至于在修改過程中更多的考慮一致性修改。
十四、 回歸測試用例自動選取
在回歸中因開發(fā)回歸范圍大或避免測試遺漏回歸范圍，往往在回歸過程中要求測試進行全部回歸，但是又因時間緊等因素導致測試不全，上線后測試心理沒底。
在9點鐘項目中，星云平臺通過回歸測試用例的自動選取，提取需要回歸的版本的測試用例以及該版本之前所有版本的測試用例進行查詢，獲取每條測試用例最后運行的版本進行數(shù)據(jù)提取，并通過測試用例、代碼、模塊的追溯關聯(lián)技術，與要回歸的版本進行比對。分析出開發(fā)改動所影響大的回歸測試用例。
在測試時間不充足的情況，可以通過該功能和開發(fā)人員一起對其測試用例進行評估，圈定測試用例回歸的范圍，從而降低測試回歸的成本。
以上的分析和講解是星云測試平臺對九點鐘app進行測試后的真實數(shù)據(jù)，并且所有的案例都是我們的測試人員和開發(fā)人員相互溝通協(xié)同完成的，讓開發(fā)和測試互動溝通，能夠提高整個團隊的工作效率，并且從該工作過程中也鍛煉了測試發(fā)現(xiàn)問題的能力和判斷問題的源頭的分析能力，對產(chǎn)品內(nèi)部程序的邏輯有更深刻的接觸和了解，達到精準測試，減少不必要的工作量，保證產(chǎn)品質量，無高風險測試漏洞，上線更穩(wěn)定。
重慶分公司
重慶分公司
