今天部門內部討論了在提交缺陷時在何種情況下應該註明是【需求不一致】。
提到這個問題，個人認爲應該先明確註明【需求不一致】的目的和作用。個人比較認同採用在缺陷中註明【需求不一致】來達到檢驗在前期評審需求和評審用例的質量。
那麼，需求文檔評審質量差對測試方而言會引發什麼大問題？
1、執行完用例後，手工測試發現一大堆缺陷。用例無法較完整覆蓋主體功能點。
2、產品經理和項目經理在後期頻繁地修改需求，導致項目週期延長，測試成員疲於奔命，編寫修改執行用例和手工測試成本上升。
3、在編寫測試用例發現需求問題，如描述不清，前後矛盾，設計不合理等。反覆溝通確認修改導致浪費人力物力。
評審用例質量差會導致什麼問題？
1、測試用例質量下降，導致在測試中容易功能點遺留測試，比較用例是軟件測試對產品檢測的主要依據之一。
2、執行用例人員對用例理解存在困難，增加反覆溝通的頻率。
3、增加手工測試的壓力，容易導致測試無法按時退出。
循着這個目的和影響範圍，可以考慮在以下幾種情況將缺陷定義爲【需求不一致的問題】
1、執行測試用例時發現和需求文檔實現不一致。需要考慮到測試人員在編寫用例發現問題，在口頭上和項目經理確認修改某個功能點，但是文檔未及時更新的情況。
2、對需求存在疑義，認爲設計不合理。
3、在測試過程中和產品經理、項目經理確認是需求存在問題，需要改動的情況。
4、發現產品實現和需求不一致，而且已經和相關人員確認是需求文檔存在問題，需求改需求的情況。
暫時寫到這吧，腦袋有點漿糊了。
順便回顧下自己對功能類缺陷定義的理解：
開發方面的缺陷（一般是在衝刺測試、集成測試、系統測試階段發現）：
1、和需求文檔不一致，包括軟需，用需，UI界面設計稿，產品功能點列表。
2、和其他同類產品進行比較，實現不合理。這類一般都是易用性，會被提爲建議類。例如用戶名字段正常不小於512個字符，但是設計是不大於30個字符。
3、需求文檔沒有描述到，但是從用戶角度操作上認爲有問題，不合理的功能點。例如增刪改查表單應該有提示信息，但是需求沒有描述到。
文檔方面的缺陷（一般是在成果評審階段和執行測試階段發現）：
1、需求文檔中直接存在矛盾，前後不一致。包括軟需和用需不一致、階段性發布的需求文檔不一致。
2、需求文檔設計不合理。
測試方面的缺陷（一般是在成果評審階段和執行測試階段發現）：
1、用例編寫錯誤。
2、測試報告錯誤，數據不準確等。
需求不一致的定義：1、