對于BUG漏測的思考

1、1、概念描敘所謂的漏測，是指軟件產(chǎn)品的缺陷沒有被在測試過程中發(fā)現(xiàn)，而是在版本發(fā)布之后，客服或用戶在使用過程中發(fā)現(xiàn)存在有缺陷。如果軟件產(chǎn)品在客戶使用過程中出現(xiàn)問題，產(chǎn)生的后果是非常嚴重的。我們都知道，缺陷越早被發(fā)現(xiàn)，發(fā)現(xiàn)和解決缺陷所花的成本就越小，如果缺陷是在測試中發(fā)現(xiàn)的，那么所花的成本將小得多。測試是保證軟件質量的最重要手段之一，因此，進行漏測分析、預防漏測、促使缺陷盡可能在開發(fā)過程的早期被發(fā)現(xiàn)，是非常有意義的，它有利于降低軟件產(chǎn)品成本、提高軟件產(chǎn)品質量。2、原因分析誰都不敢打包票說自己經(jīng)手測試的東西沒有問題，包括老鳥，或多或少的會出現(xiàn)讓缺陷從自己的手中溜走，誰也不能把軟件所有的功能操作、運用

2、場景想周全，但是像神一樣的老鳥我就不知道了，畢竟“姜還是老的辣”這不是一句空穴來風的話。為什么會出現(xiàn)缺陷漏測，主要有以下幾方面的原因：（1）需求規(guī)格不明確，導致測試用例編寫過于粗獷需求還處于一個細化過程中，軟件產(chǎn)品就已經(jīng)在開發(fā)過程中了，而測試用例的編寫是基于需求規(guī)格的，規(guī)格描敘越細致，測試用例就越能編寫的準確，出現(xiàn)缺陷遺漏的情況就可能越少，所以在初期階段測試用例就只能較為粗獷，只能待規(guī)格進一步細化，再完善補充測試用例，在實際工作中甚至出現(xiàn)邊測試邊根據(jù)細化的規(guī)格完善測試用例的情況。當然如果測試用例編寫過于細致，后期的維護工作、成本將是巨大的，所有導致我們不能也不可能將測試用例編寫過于特詳細。（2

3、）需求規(guī)格變更，測試用例未及時更新規(guī)格變更了，我們需要及時將測試用例更新，避免出現(xiàn)測試用例與規(guī)格不一致。但是在實際工作中我們沒有養(yǎng)成隨著規(guī)格的變更去更新測試用例的習慣，第一，我們很少有人是固定測試某一軟件、某一功能模塊，可能這段時間測試這個功能模塊，下一階段又換了新的功能模塊，這樣就導致沒有精力和心思去更新測試用例；第二，不能在短時間內熟悉原來編寫該測試用例的作者的風格，隨意增刪修補，容易出現(xiàn)別的問題；第三，不知道由誰來主導測試用例的更新以及如何進行測試用例更新。（3）測試用例覆蓋不全面，場景出現(xiàn)遺漏雖然說測試是軟件質量保證的最重要的一關，也是最后一關，我們也需要盡我們的可能將BUG消滅在發(fā)布

4、之前，這也是我們的職責所在。但是，我們不可能窮舉出軟件在客戶現(xiàn)場使用的所有場景，我們只能在一些主要的場景下進行測試，并在測試過程中進行適當?shù)陌l(fā)散測試，在有限的時間內最大限度的發(fā)現(xiàn)BUG。（4）測試過程中未嚴格按照測試用例執(zhí)行按照測試用例執(zhí)行測試，可以讓我們盡可能的不出現(xiàn)遺漏一些測試點。但是我們一些同學，不嚴格按照測試用例來執(zhí)行測試，這樣出現(xiàn)了一些遺漏BUG實在是不應該。但是，換句話說回來，我們發(fā)現(xiàn)的很多BUG都不是按測試用例執(zhí)行發(fā)現(xiàn)出來的，都是在測試過程中隨意測試發(fā)現(xiàn)的，而這些步驟在測試用例中并未體現(xiàn)，這就回到了原因（3）的描敘，我們的測試用例不可能覆蓋所有的場景（5）測試任務緊張，留給測試的

5、時間較少，導致功能點的測試在測試過程中被省略推薦精選測試任務緊張，我想在公司的每個人都曾經(jīng)經(jīng)歷過，因為項目緊張，軟件deadline是不可推遲的，而開發(fā)過程中可能應為種種原因，占用了大量的測試時間，測試時間被嚴重壓縮，導致原定的測試計劃不得不調整，一些功能點的測試無法測試到位。（6）測試人員私藏BUG私藏BUG，這是我們私下的一種稱呼發(fā)現(xiàn)缺陷不報告的情況，不管是測試人員礙于情面，不給開發(fā)打BUG，只是私下和開發(fā)溝通，希望對方將缺陷修復；或者是因為發(fā)布版本迫在眉睫，卻一而再、再而三的暴露出一些缺陷，導致測試人員產(chǎn)生了一些負擔的想法，對一些缺陷采取不報告。如果開發(fā)人員有負責的態(tài)度，會很快將缺陷問題

6、修復好，但工作是做不完的，可能一段時間之后就忘記了你曾經(jīng)描敘的缺陷問題，而可怕的是，在繁忙的工作中，你也一不小心的將這個問題給忘記了，缺陷就這么在明知的情況下打包到客戶現(xiàn)場去了。（7）測試環(huán)境受限，導致缺陷漏測客戶的實際使用環(huán)境可能是復雜的、多變的，我們可以盡可能的模擬、還原客戶的實際環(huán)境，但是畢竟是模擬、還原的，而不是真實的環(huán)境，由于環(huán)境的差異，可能出現(xiàn)很多意想不到的問題，這些問題可能只在特性的環(huán)境、特定的操作步驟下才會暴露出來，在我們的測試環(huán)境還原不出來，只能基于客戶現(xiàn)場的實際環(huán)境來解決問題。（8）開發(fā)人員引入的新BUG有一些開發(fā)人員只會針對你所提交的BUG中問題的描敘步驟解決，并不會去排

7、查該問題有可能涉及的所有點，有可能出現(xiàn)解決了這個問題，而引入了一個新的問題。其次，有極個別開發(fā)人員修復BUG的水平實在令人不敢恭維，不知道是不屑于修改這么弱智的BUG還是因為把心思用到了別的地方。再者，一個不熟悉功能模塊的開發(fā)人員來修復BUG，因為業(yè)務不熟悉，考慮不周全導致無意識的引入新的BUG。3、對應措施缺陷漏測問題發(fā)生了，我們該如何進行彌補，吸取教訓并采取一些對應的措施呢？這里就上面的一些原因分別分享筆者的一些想法供各位讀者參考：（1）需求規(guī)格不明確，導致測試用例編寫過于粗獷在需求規(guī)格不明確的情況下，我們是無法編寫出較為詳細、準確的測試用例，只能先編寫大概框架，待各條需求規(guī)格逐漸明確，再

8、將測試用例進一步細化。在測試過程中，如果碰到規(guī)格沒有明確的，需要和需求分析進行溝通，以便確定我們的一些疑惑點，完成測試工作。如果規(guī)格未進行定義，我們可以以溝通的結果作為基礎編寫一定的測試用例進行測試，待規(guī)格明確之后，再進行測試用例的增刪修補。（2）需求規(guī)格變更，測試用例未及時更新需求規(guī)格變更，導致原來的測試用例與現(xiàn)在的規(guī)格不相符合。我們在執(zhí)行測試用例過程中，如果碰到測試用例與規(guī)格不相符合的地方，我們需要記錄下，并根據(jù)新規(guī)格補充完善測試用例，對存在有疑問的地方需要和規(guī)格設計進行溝通和確認，可以要求需求規(guī)格進行明確定義，事后將新增的、修改的測試用例整理成文，發(fā)給組內同事組織評審，并將評審之后的用例

9、更新到用例庫中去。推薦精選（3）測試用例覆蓋不全面，場景出現(xiàn)遺漏因為測試用例場景設計導致缺陷遺漏是在所難免的，編寫測試用例的同事不可能把所有的場景都能想周全，把所有的場景下的    情況都寫成測試用例這也是不大現(xiàn)實的。對于外部反饋的缺陷，是因為場景設計不全引起的，我們先分析出現(xiàn)問題的場景是客戶必須的場景還是偶然的場景，如果該場景是客戶操作習慣，我們可以通過和技術接口人溝通，確認該場景的一些具體細節(jié)，在完善測試用例的過程中我們也要考慮一些和該場景相關聯(lián)的場景，將多種場景下測試用例及時完善、評審，增加到用例庫中去。（4）測試過程中未嚴格按照測試用例執(zhí)行我們需要面對現(xiàn)實

10、，測試用例并不能覆蓋所有的使用場景，但是，測試用例是經(jīng)過由經(jīng)驗的人根據(jù)規(guī)格編寫的，經(jīng)過了需求分析、開發(fā)、測試及其他相關人員的評審，最大程度的保證用例的準確性、全面性。測試用例不一定能保證所有的場景和功能點都能覆蓋到，但是嚴格按照測試用例執(zhí)行測試，能最大程度上保證我們的軟件質量，盡量避免出現(xiàn)缺陷。就一句話，我們在測試過程中要嚴格按照測試用例執(zhí)行，不要因為測試用例的繁瑣而拋棄測試用例，進行隨意的測試。如果是因為測試過程中隨意的測試，導致出現(xiàn)遺漏問題，實在是不應該。（5）測試任務緊張，留給測試的時間較少在測試任務明顯緊張的情況下，為避免出現(xiàn)明顯缺陷遺漏，我們可以采取一些方式來最大程度上保障缺陷的遺漏

11、：第一，根據(jù)功能模塊劃分測試優(yōu)先級，主要的功能模塊優(yōu)先級最高，安排有經(jīng)驗的人測試，安排新手測試一些不重要的功能模塊或者很少使用的功能模塊，在后續(xù)測試過程中，由有經(jīng)驗的同學將新手測試過的模塊進行冒煙測試，確認是否有明顯BUG；第二，采用加班，對于加班，估計在座的各位同學沒有誰不反感強制加班的，但是對于測試時間明顯不足的情況下，加班是必不可少的，還是靜下心來老老實實的加班干活，最起碼能在領導面前圖個好表現(xiàn)；第三，盡量避免在一些和開發(fā)扯不清的情況下浪費自己的時間，如果因為開發(fā)人員排查問題占用的時間較長，可以告訴測試負責人，由測試負責人采取相應措施，通過協(xié)商來避免類似問題蔓延；第四，增加測試人手；（6

12、）測試人員私藏BUG發(fā)現(xiàn)了問題，在確定是問題之后就提交BUG庫，不能因為和開發(fā)私下關系好就手下留情，我們需要區(qū)分好工作關系和私人關系，不要因為私人關系而影響工作，同時BUG數(shù)量也是測試人員的工作績效體現(xiàn)之一。對于版本發(fā)布在即，而缺陷卻未得到有效控制，這是項目管理者最頭大的事情。對于測試人員來說，抱著負責任的工作態(tài)度，不管在什么時間下發(fā)現(xiàn)了缺陷，都需要第一時間報告提提交，不能因為版本發(fā)布在即，而自己負責測試的模塊發(fā)現(xiàn)了多個缺陷而心存畏懼，從而采取將BUG私藏而導致缺陷溜了出去，遲發(fā)現(xiàn)總比沒發(fā)現(xiàn)好，在家里發(fā)現(xiàn)比在客戶現(xiàn)場被發(fā)現(xiàn)的帶來的損失要低得多。如果遲發(fā)現(xiàn)而不報告，對管理者來說就是沒發(fā)現(xiàn)，測試人

13、員需要在發(fā)現(xiàn)缺陷就立馬報告出來，修改還是掛起，缺陷的風險如何，項目管理者會做全局考慮的，畢竟大多數(shù)同學還沒有達到能對缺陷進行風險評估的水平。報告缺陷讓項目管理者考慮總比自己私藏而被客戶所發(fā)現(xiàn)要好，私藏BUG總會讓自己有吃不了兜著走的一天。（7）測試環(huán)境受限，導致缺陷漏測推薦精選環(huán)境的組合是無窮的，我們沒有足夠的時間、足夠的成本在足夠多的環(huán)境中測試軟件。我們要保障在主要的操作系統(tǒng)環(huán)境、主要的網(wǎng)絡環(huán)境中，我們的軟件的功能、性能能達到我們預期的設計，對于操作系統(tǒng)環(huán)境，我們需要針對當前的使用比例來排序。這里以某產(chǎn)品線上一款軟件為例：對于Client軟件來說，WIN XP 和WIN 7的使用的最多。除了

14、WIN 7 和WIN XP之外，我們不知道客戶是否還會有人在WIN VISTA、WIN 2000上使用我們的軟件，所有還需要測試WIN VISTA、WIN 2000。對于網(wǎng)絡環(huán)境，我們一般是在以太網(wǎng)環(huán)境中測試，對于客戶的其余網(wǎng)絡環(huán)境，我們在有條件、有需要的情況下也需要進行常規(guī)測試。（8）開發(fā)人員引入的新BUG開發(fā)人員是否會因為修復某個BUG而引入新的BUG呢？開發(fā)人員一般都會說沒問題，我們要做的就是將開發(fā)人員修復的BUG確認驗證，并將相關聯(lián)的功能點盡可能的遍歷到，因為如果出新問題的話，在與修復的BUG相關聯(lián)的功能的地方可能性比較大，當前BUG修改之后開發(fā)自己會進行測試后才會提交，但與之相關聯(lián)的

15、功能點并不一定會去測試一把。如果碰到極個別開發(fā)人員修復BUG的情況實在令人不敢恭維，或者是因為一個不熟悉模塊業(yè)務的開發(fā)人員修復的BUG，我們就只能多花點時間，將回歸測試的功能點盡量覆蓋全面，避免出現(xiàn)缺陷遺漏。開發(fā)人員修復已知BUG引入新的BUG，是開發(fā)團隊提交代碼流程的范圍，比如華為的代碼提高很嚴謹，層層審核，引入新BUG的可能性較小，但是中小型公司，代碼管理混亂，甚至自己組長都不審核，出問題簡直是必然的。所以規(guī)范代碼提交流程是重中之重。4、漏測分析的好處不管是因為什么原因導致缺陷流到客戶現(xiàn)場，問題發(fā)生了，我們首先要做的就是彌補缺陷帶來的影響，項目組要評估由此帶來的風險、損失，修正缺陷，提供完

16、善的版本給客戶使用。做完前面的這些工作之后，我們可以、甚至是需要自覺的進行思考總結，吸取經(jīng)驗教訓，并將出問題的這些情況補充、完善到測試用例中去，對一些常見的情況還需要進行組內學習，避免在以后的工作中再次犯下同樣的錯誤。如果能做的更好一步，我們可以學習并進行統(tǒng)計，對這些遺漏的BUG予以分類，缺陷的嚴重程度、所屬功能模塊、遺漏原因分類等等。我們在進行缺陷漏測分類活動時，可以由專人組織發(fā)起討論，將需求、開發(fā)、測試、技術支持以及其他所有產(chǎn)品生命周期中相關部門的代表組織到一起對近期的漏測進行分析討論，特別是技術支持人員能夠提供很多非常詳細的關于漏測缺陷的信息，這對漏測分類、累積經(jīng)驗、教訓吸取非常有幫助。進行缺陷漏測分析的目的是為了促進軟件質量和開發(fā)測試過程得到持續(xù)改進，使我們在測試過程中可以考慮得更加周全，彌補思維僵局。具體來講，就是通過分析測試過程中漏測的缺陷，采取一些相應的預防措施以避免今后再發(fā)生類似的漏測。測試過程的持續(xù)改進將提高測試環(huán)境的效果和測試執(zhí)行的效率、降低遺留到用戶處的缺陷數(shù)和缺陷解決成本