【關鍵字】周期性，黑盒測試，自頂向下
引言
由于軟件企業對軟件質量的重視程度越來越高，軟件測試在軟件研發中的地位越來越重要。越來越多的企業領導也將注意力更多的投入到軟件測試方面來，確實測試很需要得到領導的重視與理解并且毫無疑問的支持，如果你所處的團隊目前已經很好的得到了領導的重視和支持，那真是一件幸事�？刹恍业氖�，目前很多國內軟件相關人士對軟件測職業崗位還出于不理解狀態，這其中當然包括領導一層，可能大家在日常工作中有時候會碰到領導過問到測試狀況或者BUG的事，特別是那些規模小，流程體系還不夠完善，處于人治狀態的公司也許幾率更高一些，通常來說，領導見到那些層出不窮的BUG，直覺反應是測試工作做的不夠理想而導致BUG的遺漏，當然這樣的假設不一定成立，到底為什么會有層出不窮的BUG呢?
層出不窮的 BUG
大家可能都有這樣一種感覺，軟件幾乎天天在修改，審核，驗證再測試，可相當長一段時間的測試過程中會發現居多這樣那樣的缺陷，層出不窮的發現BUG，到底是什么原因?
筆者總結以下幾種常見原因
.測試遺漏
測試的設計主要體現在測試用例的設計，以及通過測試策略將這些測試用例同測試計劃，測試執行，還有測試結果數據的收集整理結合在一起執行，由于測試人員水平的高低，測試工具使用的熟練程度，以及對所測試對象的理解深度等原因，測試設計很難完善，主要表現在測試用例設計的不全面，存在遺漏，或者測試方案的不周密，以及可能的測試人員執行時產生的偏差等等，這些測試方面的遺漏和偏差都可能導致軟件問題沒有及時發現，造成測試的遺漏。
.設計及修改原因
軟件需求或者設計方案經常被更改，特別是變更沒有導入一套成熟的變更管理體系的情況下，每次變更無疑于埋下大量的地雷，這些都為BUG提供滋生的環境。另外后期修改維護中對BUG未做準確的分析定位，修改方案未審核，或者修改過程中程序員出現“頭痛治頭，腳痛治腳”，“補了東邊漏了西邊”等不良修改過程中引發出新的問題，也是導致BUG被擴大的原因。
.BUG的概率性及偶然性
有些BUG的出現呈現概率的特性，它需要反常數量，頻率，或者資源的方式下執行系統才能被查找，即通常所說的壓力測試。
.BUG的潛伏性及階段性
有時候，BUG實際存在但由于觸發它的條件不滿足從而呈現潛伏狀態只能在某個階段才能被發現，單元測試，集成測試，系統測試等階段測試重點關注的對象就不同，如集成測試可以發現單元測試通過后的模塊之間接口上的錯誤。特別象嵌入式系統中多進程以及多任務處理問題、系統容錯性問題、內存問題等等，這些情況下表現出的潛伏性更加復雜多變，導致發現這些BUG需要一個特別長的周期或者需要某一特定測試環境能被有效搭建的情況下才能查找出。
.BUG的隱蔽性和周期性
該BUG實際存在但由于其他BUG的存在導致它所在的代碼沒有得到執行，因而無法暴露該BUG，這種情況在以黑盒測試為主的測試中表現尤為突出，只有通過周期性的BUG修復及測試才能發現該類BUG。
測試的周期性
上文提到BUG的隱蔽性和周期性決定了測試必須是一個周期性的工作，這個周期性不是表現為簡單的重復。下面針對黑盒測試的特點來詳細闡述這一特性。
黑盒測試的對象大多針對圖形用戶界面(GUI)，它以窗口，菜單以及按鍵的表現形式，針對它們的測試，通常通過模擬用戶的操作來完成，這種特性決定它只能通過自頂往下的測試方法，即只能通過菜單一級一級往下的方式測試，從程序的角度來說必須先有父窗口再到子窗口的過程。當然如果采用白盒測試的方法，可以通過驅動的方式來激發，這里就不闡述!
以手機這類嵌入式系統測試舉例，手機軟件的測試對象通常是窗口結構、信息流、控制流，以及邏輯控制等都具有很強的層次性，一旦某一窗口出現BUG，通過黑盒測試來引導程序運行的測試很可能就因該BUG的存在而就此中止了運行，從而無法執行剩余的測試用例來遍歷其他的路徑，這樣就無法查找到那些未遍歷的代碼中可能存在的缺陷。
假設下圖所示意的測試模塊中紅色框圈中的為BUG所處的節點，該模塊假設共在3個節點處存在錯誤。(為了方便大家的理解不防把各“節點“看成一窗口菜單，從而下圖就看成一菜單樹結構)。
測試周期 1 ：
上圖中，如果節點“2“處出現了BUG，程序在此中斷，黑盒測試無法遍歷從節點”2“到節點”4“，以及節點”2“到節點”3“的邊，測試就無法發現在節點”4“及節點”7a“處的的BUG，這就是因為節點”2“處的BUG存在將其它BUG隱蔽起來了，剩余遍歷其它路徑的測試用例無法再執行，測試在此中斷，等待修復節點“2“處的BUG。
測試周期 2 ：
新版本解決完節點“2“處得BUG，測試可以執行從節點”2“到節點”4“的邊，從而又暴露出節點”4“處的BUG，同樣的道理，測試繼續被中斷，無法遍歷從節點”4“-”6“-”7a“，以及節點”4“-“5-“7a””這兩條路徑，無法發現節點”7a“處的的BUG，這就是因為節點”4“處的BUG存在將其它剩余的BUG隱蔽起來，等待修復節點“4“處的BUG。
測試周期 3 ：
解決完節點“4”的BUG后，前一版本無法遍歷的路徑在此可以被執行，從而發現節點“7a”處的BUG，從上所敘的黑盒測試過程，需要通過整整3個周期的測試，才能執行完所有測試用例，達到遍歷上圖所有路徑。
上面只是一個簡單的例子，實際的測試情況比這要復雜得多，目的在于闡述BUG的隱蔽性決定了發現它們需要一個周期，從而說明查找BUG不能象大家想象得那樣，通過在某一個版本上投入大量的人力物力做盡量多的測試就可以暴露出所有的缺陷，同樣的道理，如果希望在某一個版本的測試報告中去評估一個系統的穩定性或者質量狀況，也是不科學的，上圖是一個很好的例子，一個節點處的錯誤足可以屏蔽數倍于它的BUG，有的甚至是致命的錯誤。
結論
筆者整理此文曾經是因為領導的一個疑問“為什么會有層出不窮的BUG?”，很慶幸遇到一位不恥下問又虛心學習的領導，通過對此文的解讀，讓他更深的理解了測試的周期性特征，測試很需要得到領導的重視與理解并且毫無疑問的支持，如果大家對測試理解更深入一點，就會對測試這行業更熱愛些，領導的注意力和投入也會更多一些，希望此文能給大家一些可以。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
