缺陷是測試過程中測試人員的重要輸出，它不僅是和其他專案利益相關者進行溝通的橋梁，也是證明測試人員測試能力的重要手段。但是，在實際的測試過程中，測試人員提交的缺陷常常會被開發人員以各種理由拒絕。
為了減少被軟體開發人員拒絕的缺陷的數目，我們首先需要了解為什麼開發人員會拒絕測試人員提交的缺陷，或者說他們為什麼不願意花費時間和精力解決測試人員提交的缺陷。本文將從幾個不同的視角分析缺陷被拒絕的原因，從而有針對性的提出一些建議，幫助測試人員儘量減少被開發人員拒絕的缺陷的數目。根據筆者的經驗，開發人員拒絕研究和修改缺陷的原因是多方面的，例如：
° 開發人員無法復現缺陷（無法復現）；
° 缺陷報告中提供的資訊不足，或者復現缺陷需要奇怪而複雜的步驟（難以理解）；
° 開發人員認為是系統的乙個功能點，而測試人員認為是乙個缺陷（缺陷還是功能點）；
° 開發人員不理解測試人員的角色和職責定位（測試人員的角色）；
1）缺陷無法復現
開發人員拒絕研究和修復測試人員提交的缺陷的第乙個可能理由是：這個缺陷我無法復現，或者這個問題在我的環境中並沒有發現。
在測試過程中，測試人員經常會碰到一些不可復現或者很難復現的問題，特別是在進行非功能性測試的時候，例如：穩定性測試、壓力測試、滿配置測試、相容性測試等。通常來說，這些難以復現的問題，其導致的結果一般都是比較嚴重的，例如：系統效能不穩定，系統隨機重啟等。同時，這些問題常常也是使用者最關注的地方。假如使用者在使用過程中出現這樣的嚴重問題，將會極大的降低使用者對產品的信心。
即使是難以復現的問題，建議測試人員還是需要提交缺陷報告。只是，測試人員在提交缺陷報告之前，需要採取一些合適的策略和建議，盡量為開發人員定位和修復這樣的問題提供合適的資訊，幫助他們盡快解決問題。我的建議包括：
° 首先，測試人員養成這樣的習慣：開啟系統的除錯視窗（假如系統提供），時時記錄測試過程中系統的列印資訊。發現系統的異常表現的時候，測試人員就可以捕獲其中異常的系統列印資訊，這些資訊可以幫助開發人員跟蹤和定位缺陷發生的原因，從而有利於開發人員解決這種型別的缺陷；
° 其次，測試人員碰到系統的異常表現的時候，可以先判斷該問題是否可能難以復現。假如覺得難以復現，測試人員可以先保留當前的測試環境，要求開發人員到現場來定位和分析其中可能的原因。假如開發人員可以從當前的環境中分析得到可能的原因，那麼測試人員編寫缺陷報告就可以輕鬆得多；
° 第三，測試人員報告不可復現的缺陷的時候，應該在缺陷報告中明確告知開發人員不可復現或者難以復現，從而避免在有限的時間和資源情況下，開發人員過多的將精力放在這樣的缺陷修改上面；
° 第四，建議測試人員提交難以復現的缺陷，組織內可以不斷的收集和分析難以復現的缺陷資料庫。定期瀏覽這些缺陷，並進行集中的分析，可能會在不同的缺陷描述中發現一些共同的或者可能有聯絡的資訊，有助於問題的解決；
2）缺陷報告難以理解
開發人員拒絕測試人員提交的缺陷的第二個可能理由是：缺陷報告中提供了太多的內容和資訊，開發人員甚至不知道測試人員想說什麼，也很難了解測試人員想闡述的問題是什麼。
缺陷報告是測試過程中測試人員的重要輸出。很多的時候，專案利益相關者通過缺陷報告認識測試人員。好的缺陷報告可以為測試人員帶來良好的聲譽，而差的缺陷報告可能會為利益相關者帶來額外的工作。如果測試人員的缺陷報告，浪費了專案利益相關者太多的時間和資源，他們潛意識中就會抵制和拒絕他們的缺陷報告。
編寫良好的缺陷報告是測試人員應該具備的幾個基本技能。高效的缺陷報告，對測試人員而言具有重要的意義，除了可以減少被開發人員拒絕的缺陷數量，也有助於提高測試人員的可信度、改善開發人員和測試人員之間的合作關係。
好的缺陷報告是測試人員在測試過程中發現了什麼，而不僅僅是告訴開發人員我們做了什麼。這對於編寫高質量的缺陷報告很重要。另外，我們在編寫缺陷報告的時候，還應該使缺陷報告盡量具備以下特徵：
° 精簡的：缺陷的描述應該是清晰而簡要的。首先在缺陷報告中剔除不必要的語言。其次，不要增加無關的資訊。在缺陷報告中包含所有缺陷相關的資訊，並且確實是相關的。多餘的資訊只會增加缺陷描述的含糊不清；
° 正確的：提交的問題確實是乙個缺陷。假如提交的缺陷最後證明是由於理解錯誤或者配置錯誤引起的，測試人員將在開發人員面前失去可信度，同時會對彼此之間的溝通帶來一些影響；
° 隔離：盡量尋找簡短的步驟來復現缺陷，即將缺陷進行隔離。例如：哪個模組中發生了問題？是哪個輸入條件觸發了這個缺陷？是哪個動作引起了這個失效等。對問題的隔離定位能力，很大程度上可以為測試人員加分，同時可以提高大家的測試效率和專案整體的效率；
° 推廣：確定系統其他部分是否可能也存在同樣的問題，以及使用不同的資料時是否也會出現這種問題等等。測試人員在缺陷方面的推廣能力，可以幫助節約開發人員修改缺陷的時間，同時提高缺陷解決的效率；
° 復現：確定系統是否可以復現這個問題，需要什麼樣的步驟輸入來復現這個問題。對於能夠復現的問題，提供簡單的步驟和輸入。對於難以復現的問題，盡量提供一些告警資訊、日誌資訊給開發人員，或者問題發現時，可以和開發人員一道進行跟蹤除錯和定位。對於實在無法復現的問題，在缺陷報告中明確說明，並且在後續測試中留意跟蹤；
除了上面的要求之外，測試人員在編寫好缺陷報告之後，假如時間允許，可以請求有經驗的測試人員或者測試經理，在提交缺陷報告之前閱讀一遍。這有助於缺陷報告質量的提高。
3）缺陷還是功能點
開發人員拒絕測試人員提交的缺陷的第三個可能理由是：他們認為這是乙個正常的功能特性（或者功能點），而測試人員認為這是乙個問題。
引起開發人員和測試人員對系統的同乙個表現行為出現分歧的主要原因，可能是他們對系統的輸入，例如：需求文件的理解不一樣。通過合理的定義系統人員、開發人員和測試人員的角色和職責定義，可以較好的解決這樣的問題。下面是三者關係的示意圖：
研發人員關係示意圖
圖1說明了系統人員是軟體開發和軟體測試的基礎和核心。通過系統人員將產品的使用者需求轉化為詳細的需求規格說明。在需求規格說明基線化後，軟體人員以此作為基礎進行系統概要設計和詳細設計，而測試人員根據需求規格說明來進行軟體測試策略和詳細測試用例的設計。同時，軟體人員和軟體測試人員都需要和系統人員緊密合作和交流，將各個階段的開發活動和測試活動得到的資訊反饋給系統人員，來完善和優化系統需求規格說明。按照這樣角色和職責的定義，假如開發人員和測試人員針對某個產品的表形行為有分歧的時候，可以通過系統人員來做最後的決定。通過軟體開發過程控制和管理，開發人員和測試人員就可以較好的避免糾纏「是缺陷還是功能點」此類問題，從而提高我們的測試效率，同時也可以更好的實現專案利益相關者之間的溝通。
4）測試人員的角色
開發人員拒絕測試人員提交的缺陷的第四個可能理由是：產品的需求規格中並沒有這樣要求，需求規格中的功能和特性已經實現了。
引起這個問題的原因主要是開發人員對測試人員角色和職責的定位不清楚。假如開發人員並不能很好的理解測試人員的工作，那麼開發人員和測試人員之間在缺陷方面的溝通也會存在一些問題。那麼，測試人員的角色和職責應該是什麼呢？我們認為測試應該是貫穿於整個軟體開發生命週期，而不僅僅只是**階段之後的測試執行活動。這裡引入verification和validation兩個概念：
° 驗證（verification）：通過檢查和提供客觀證據來證實指定的需求是否滿足。也就是說，輸入與輸出之間的比較。也就是說，是檢驗軟體是否已正確地實現了產品規格所定義的系統功能和特性，即「are you building the product right」。
° 確認（validation）：通過檢查和提供客觀證據來證實特定功能或應用是否已經實現。在確認時，應考慮使用和應用的條件範圍要遠遠大於輸入時確定的範圍。一般是由客戶或代表客戶的人執行。也就是說，是確認所開發的軟體是否滿足使用者真正需求的活動，即「are you building the right product」。
根據verification和validation兩個概念，我們可以看到，測試人員除了要驗證產品是否正確實現了需求規格說明之外，他還需要站在客戶的角度，分析產品是否真的是客戶所要求的。因此，測試過程中，測試人員除了報告功能性的缺陷之外，特別需要注意一些非功能的特性，特別是使用者所關注而需求規格中可能並沒有明確定義的要求，例如：產品是否容易使用，圖形介面是否布局合理等。
前面分別談了開發人員拒絕修復測試人員提交的缺陷4個主要原因，以及根據筆者的經驗提出的一些建議。當然，測試過程中我們肯定還會碰到其他的一些原因，導致開發人員不願意修復某些缺陷。不管是什麼原因，都需要我們測試人員具備良好的溝通能力、規範嚴謹的缺陷報告編寫能力，以及通過良好的合作讓開發人員更好的理解測試工作，從而達到更好更快的發現和修復缺陷，實現高質量產品的及時發布。
思考 開發人員為什麼拒絕修改我的缺陷
缺陷是測試過程中測試人員的重要輸出，它不僅是和其他專案利益相關者進行溝通的橋梁，也是證明測試人員測試能力的重要手段。但是，在實際的測試過程中，測試人員提交的缺陷常常會被開發人員以各種理由拒絕。為了減少被軟體開發人員拒絕的缺陷的數目，我們首先需要了解為什麼開發人員會拒絕測試人員提交的缺陷，或者說他們為...
思考 開發人員為什麼拒絕修改我的缺陷
缺陷是測試過程中測試人員的重要輸出，它不僅是和其他專案利益相關者進行溝通的橋梁，也是證明測試人員測試能力的重要手段。但是，在實際的測試過程中，測試人員提交的缺陷常常會被開發人員以各種理由拒絕。為了減少被軟體開發人員拒絕的缺陷的數目，我們首先需要了解為什麼開發人員會拒絕測試人員提交的缺陷，或者說他們為...
為什麼要有經驗的開發人員？
為什麼要有經驗的開發人員？1，可以更有效的溝通，因為開發需要很多專業知識，不懂這些就會有更多的溝通成本，甚至理解不一樣，導致結果都很不一樣，2，可以更有效的解決問題，開發中遇到棘手的問題，如果乙個有經驗的開發會拿出乙個成熟的解決方案，很快解決問題，否則就會一步乙個檻，進展緩慢，浪費大量的時間，3，可...