項目測試過程Bug之平均測試

一、定義：

測試方法單一，不分測試點關鍵級別，嚴格水平相同 。

二、發生時間段

可能發生在任何時間。

三、陷阱表現

• 測試計劃文檔只包含通用、模板測試指南，而非適當的、針對系統的具體信息。

• 所有測試都采用相同方法， 未依據需求類型或所驗證系統的類型。

• 在任務、安全及保密上關鍵系統或組件，未比其他次關鍵的組件要求更嚴格和全面。

• 只有適用于測試功能性需求的一般技術 ，沒有驗證質量需求（可用性、容量、性能、可靠性、健壯性、安全性、保密性、易用性需求）的專門類型的測試描述。

四、負面后果

• 任務性、安全性等關鍵組件未經充分測試。

• 沒有專門的測試來驗證系統或軟件具有重要質量特性和屬性的足夠水平。如沒有***測試 或易用性測試。

• 無足夠資源充分測試所有軟件 ，有限資源被誤用于低優先級的軟件 ，而非測試更關鍵組件。

• 有些Bug未發現，通過測試進入了部署的系統。

• 系統不符合非功能性需求（即數據、接口和質量需求，及架構 、設計、實現或配置約束）

• 系統不足夠安全或保密安全。

五、原因

• 未區分關鍵與非關鍵組件的測試過程要求。

• 測試計劃模板和內容或格式標準不完整，未考慮任務、安全關鍵性對測試的影響。

• 無工程化質量需求 （安全性與保密安全性）

• 測試人員不熟悉安全性與保密安全性對測試的影響。（測試的高嚴格等級要求取得鑒定和認證）

• 測試人員與安全保密人員間溝通不暢。

六、建議

• 準備階段

為軟件開發及測試人員培訓，考慮包括項目特定的、專業測試信息的需要。

為測試計劃和開發文檔（流程、指南等）做模板，滿足項目和系統特定信息的需要。

• 啟用階段

更新開發、測試和過程文檔的模板或格式內容標準，以解決所需測試的類型、完整性和嚴密性。

• 執行階段

在開發測試計劃文檔中做到：

測試類型差異或完整性和嚴密性的程序和任務、安全關鍵性的關系 。

測試質量需求和專業工程測試方法和技術。

比次關鍵的組件或系統更完整、更嚴格的測試。

• 驗證階段

確定測試的完整性、類型和嚴密性是否：

在系統開發和測試計劃中考慮

系統或子系統的關鍵性相關

充分，基于被測系統或子系統的關鍵性程度。

七、相關Bug

測試優先級不足，測試溝通不充分。