怎樣讓測試更全面付文龍軟件測試的現狀軟件產業發展到今天，如果還是用以前的思路、辦法（公司里絕大部分、甚至全部都是開發人員在做產品，只要能做出來可以用就行），企業的產品肯定沒有競爭力，從而導致這樣的軟件企業生存極其困難。正是因為這個原因，以前軟件測試以往一直被中小IT企業所忽視，只有一些知名企業才有門的軟件測試人員。現在，更多的國內企業認識到測試的重要性，設立了軟件測試部門，配備了專業的軟件測試人員。既然我們有了測試部門，有了專職的測試人員，按理來說就不會再有質量問題存在了，但客戶還是反饋有或多或少的問題存在。那么這是為什么呢？我們應該從哪些方面來防止這些問題呢？

漏測的定義所謂漏測，是指軟件產品的缺陷沒有被測試組發現而遺漏到了用戶那里，最終被用戶所發現。進行漏測分析的目的是為了促進軟件質量和開發測試過程得到持續改進。具體來講，就是通過分析開發和測試過程中漏測的缺陷，制定相應的預防措施以避免今后再發生類似的漏測。測試過程的持續改進將提高測試環境的效果和測試執行的效率、降低遺留到用戶處的缺陷數和缺陷解決成本，從而提升軟件的質量、聲譽和銷售。在軟件產品開發過程中重視漏測分析并參與到漏測分析工作中的團隊越多，漏測分析的效果就越好。如果開發和測試團隊都重視漏測分析、并密切配合進行漏測分析工作的話，漏測分析將取得非常好的效果。·需求評審·梳理需求·用例設計與評審·測試執行·Bug回歸·發布前的功能回歸需求評審

參加需求評審會，理解需求文檔，在編碼前找出需求的bug，與客戶以及研發在需求的理解上達成一致的觀念。但是也可能存在以下的問題：沒有需求文檔？客戶對需要的產品目標不明確，研發人員也不明確，這個時候，只能使用敏捷開發，把產品開發出來之后，先給用戶使用，然后再根據用戶提示的問題進行修改，這樣的bug都比較難確定；需求總是不能固定？不固定需求就會引出問題，然后引出一系列的bug；需求已經定義，是否吻合客戶實際應用？

那么，這就需要我們在理解完需求之后，找負責人進行確認，并通知項目的參與人員，進行一個有效的需求評審會議。是大家對需求都達到一致的認識。日前一名張姓民眾到

南京市秦淮區的超市購買一款牛肉松營養面包，但仔細閱讀產品成分后，赫然發現小小一塊面包，成分竟高達20多種，但里面居然沒有牛肉相關成分。他憤而檢舉，認為店家故意欺騙消費者，痛斥“太不厚道了！”面對張先生的質疑，食品業者回應：“我們的意思是，這是很牛的肉松面包，而不是牛肉松面包”。業者表示，這個牛并非吃的牛，而是一種語氣詞，所以在包裝袋上宣傳并未不妥。而該公司的員工也認為，食品名稱與成分其實沒有相對等的關系，“紅牛（redbull）里面有牛嗎？”需求評審軟件需求是開發工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據，而我們只有在源頭上控制好，才能保證下面工作的平穩開展要保證軟件需求的可測試性。對于“可測試性”，就是要保證所有的需要實現的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業的業務。需要對軟件產品所涉及的行業的業務有一個全面的、深入的了解及時檢測出軟件需求文檔中具有不可測試性的需求點。（某功能模塊輸入可見，輸出不可見，無法驗證模塊功能是否正確；或是該功能模塊的輸出無參考標準來衡定）。及時發現軟件需求文檔的不完整性，從而提醒需求分析人員彌補描述。需求分析實例

題目：輸入三個數a、b、c分別作為三邊的邊長構成三角形。通過程序判定所構成的三角形是一般三角形、等腰三角形還是等邊三角形時。用等價類劃分方法為該程序設計測試用例。在三角形計算中，要求三角形的三個邊長：A

B

C。1、當三邊不可能構成三角形時提示錯誤，可構成角形時計算三角形周長。

2、若是等腰三角形打印“等腰三角形”，若兩個等腰的平方和等于第三邊平方和，則打印“等腰直角三

角形”。

3、若是等邊三角形，則打印：“等邊三角形”。4、畫出程序流程圖并設計一個測試用例。

需求分析實例有效等價類：

輸入3個正整數或正小數：兩數之和大于第三數，如A<B+C；B<C+A；C<A+B兩數之和不大于第三數兩數相等，如A=B或B=C或C=A三數相等，如A=B=C三數不相等，如A！=B，B！=C，C！=A無效等價類：空負整數非數字

少于三個數梳理需求

在掌控了軟件項目的背景，了解了產品的質量要求和軟件測試的基本需求之后，同時，測試人員也會閱讀相關軟件需求文檔，參與需求評審。在這些基礎之上，可以進行測試的需求分析，即包括下面這些工作：明確測試范圍，了解哪些功能點要測試、哪些功能點不需要測試；知道哪些測試目標優先級高、哪些目標優先級低；要完成哪些相應的測試任務才能確保目標的實現。用例的設計與評審1、要參與需求評審，評審需求的過程實際也是熟悉業務需求的過程。只有對業務比較熟悉了，才能更好的，更充分的設計出高質量的測試用例。2、要多閱讀文檔，其中包括產品策劃書、規格說明書、需求文檔，接口文檔等，我們可以收集一切相關的文檔來幫助理解所要測試的產品需要完成的目標。3、盡量多參加項目組內的會議。比如需求討論、設計討論、計劃討論等會議，這樣在討論過程中也能加深對產品的理解。4、要善于溝通，多和開發、PM進行溝通。遇到不明確的問題、有疑問的需求，可以咨詢項目負責人或者客戶等。這樣才能提前解決需求理解偏差等。5、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明了，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，并且原則上每個用例的名稱不能重復。用例的設計與評審6、預置條件要明確，包括測試環境、測試數據、測試場景。因為許多BUG只有在特定的環境、特定的場景下才可以重現。沒有正確的前提條件，就無法進行后面的測試步驟或無法得到預期的結果。7、測試步驟描述要簡單、清晰，并且要清楚每一個步驟的描述，我們平常的鼠標和鍵盤的每一動作都代表一個操作步驟。比如：第一步，輸入用戶姓名；第二步，輸入登錄密碼；第三步，用戶點擊登錄。步驟寫的明確時就利于提高用例的可操作性。8、用例的預期結果要完整而且清晰，并且要將各個輸出的結果寫出來，包括：返回值的內容、數據庫相關字段的記錄、界面的響應結果、輸出結果的規則符合度、日志的檢查和對其它業務影響的檢查。9、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。

總是有些缺陷的出現是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那么，對于這部分缺陷，也應當添加到測試需求中，并設計相應的測試用例，以便于下次版本迭代時進行參考用例的設計與評審10、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況。一個用例檢查的情況太多，會導致用例的目的不明確。而且這樣組織用例，有利于需求覆蓋率的統計。一個功能點我們測試了哪些情況，以及哪些功能點我們在重點測試，一目了然。11、評審用例很關鍵，因為經過測試用例的評審可以發現：用例設計的結構安排是否清晰、合理；是否覆蓋所有的需求功能點；是否存在冗余的用例；是否具有很好的可執行性；是否存在對需求理解上的差異等。評審需要項目經理、需求分析人員、架構設計人員、開發人員和測試人員都參與，也需要客戶方的開發人員和測試人員。12、召開測試用例評審會議，在會議上大家可以提問互答，對模糊不清的地方可以進行討論。這樣可以站在不同的角度，站在很多人的思維和思考方式下設計用例。用例的設計與評審13、站在用戶的角度來設計用例，以用戶的使用邏輯及操作習慣為出發點，從用戶實際可能的操作場景考慮，一定要脫離系統提供功能。14、測試用例需要不斷更新和維護，不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發的不同的階段都要回來重新審視和完善測試用例。并且需要在測試執行時利用發散思維不斷的構造和完善測試用例測試執行在固定的時間內，盡可能全面地執行測試用例。1.在測試過程中不斷的添加遺漏的用例，一定要在發現時及時補充，有些用例是無意間操作發現的；2.詳細標識每一個被執行過的用例。問題回歸

測試過程中，遇到過一個小小的參數變動可能引起一個比較遠的功能點的大bug，開發不知道，測試不清晰，勢必引發遺漏。在修改bug的這種情況下，有可能是牽一發而動全身的，是非常危險的。如果研發考慮的不周全，只修改了此bug，并沒有考慮到與它接口的功能，那將會引發更多的bug。發布前的功能回歸首先保證所有修改的bug驗證通過，并且沒有引起別的bug；在測試的過程中，最好自己編寫checklist表，這樣到