對于BUG漏測的思考

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

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

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

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

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

6、工作是做不完的，可能一段時間之后就忘記了你曾經(jīng)描敘的缺陷問題，而可怕的是，在繁忙的工作中，你也一不小心的將這個問題給忘記了，缺陷就這么在明知的情況下打包到客戶現(xiàn)場去了。(7)測試環(huán)境受限，導(dǎo)致缺陷漏測客戶的實際使用環(huán)境可能是復(fù)雜的、多變的，我們可以盡可能的模擬、還原客戶的實際環(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ā)人員修復(fù)BUG的水平實在令人不敢恭維，不知道是不屑于修改這么弱智的BUG還是因為把心思用到了別的地方。再者，一個不熟悉功能模塊的開發(fā)人員來修復(fù)BUG,因為業(yè)務(wù)不熟悉，考慮不周全導(dǎo)致無意識的引入新的BUGo3、對應(yīng)措施缺陷漏測問題發(fā)生了，我們該如何進(jìn)行彌補(bǔ)，吸取教訓(xùn)并采取一些對應(yīng)的措施呢？這里就上面的一些原因分別分享筆者的一些想法供各位讀者參考：(1)需求規(guī)格不明確，導(dǎo)致測試用例編寫過于粗獷在需求規(guī)格不明確的情況下，我們是無法編寫出較為詳細(xì)、準(zhǔn)確的測試用例，只能先編寫大概框架，待各條需求規(guī)格逐漸明確，再將測試用例

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

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

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

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

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

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

14、、WIN2000上使用我們的軟件，所有還需要測試WINVISTA、WIN2000。對于網(wǎng)絡(luò)環(huán)境，我們一般是在以太網(wǎng)環(huán)境中測試，對于客戶的其余網(wǎng)絡(luò)環(huán)境，我們在有條件、有需要的情況下也需要進(jìn)行常規(guī)測試。(8)開發(fā)人員引入的新BUG開發(fā)人員是否會因為修復(fù)某個BUG而引入新的BUG呢？開發(fā)人員一般都會說沒問題，我們要做的就是將開發(fā)人員修復(fù)的BUG確認(rèn)驗證，并將相關(guān)聯(lián)的功能點盡可能的遍歷到，因為如果出新問題的話，在與修復(fù)的BUG相關(guān)聯(lián)的功能的地方可能性比較大，當(dāng)前BUG修改之后開發(fā)自己會進(jìn)行測試后才會提交，但與之相關(guān)聯(lián)的功能點并不一定會去測試一把。如果碰到極個別開發(fā)人員修復(fù)BUG的情況實在令人不敢恭維，

15、或者是因為一個不熟悉模塊業(yè)務(wù)的開發(fā)人員修復(fù)的BUG,我們就只能多花點時間，將回歸測試的功能點盡量覆蓋全面，避免出現(xiàn)缺陷遺漏。開發(fā)人員修復(fù)已知BUG引入新的BUG,是開發(fā)團(tuán)隊提交代碼流程的范圍，比如華為的代碼提高很嚴(yán)謹(jǐn)，層層審核，引入新BUG的可能性較小，但是中小型公司，代碼管理混亂，甚至自己組長都不審核，出問題簡直是必然的。所以規(guī)范代碼提交流程是重中之重。4、漏測分析的好處不管是因為什么原因?qū)е氯毕萘鞯娇蛻衄F(xiàn)場，問題發(fā)生了，我們首先要做的就是彌補(bǔ)缺陷帶來的影響，項目組要評估由此帶來的風(fēng)險、損失，修正缺陷，提供完善的版本給客戶使用。做完前面的這些工作之后，我們可以、甚至是需要自覺的進(jìn)行思考總結(jié)，

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