一、模型概覽
開放源碼軟件測試模型以“滿意測試”為基本原則，強調迭代發展。
· “滿意測試”基本定義
是一個過程，通過該過程可以合理的成本獲取足夠的產品質量評價信息，從而使得與產品有關的決策更為明智和及時。
· 模型基本需求
以下給出開源軟件測試模型應滿足的一些基本要求，將在實踐中不斷豐富和完善：
1. 應充分考慮開放源碼的早發布和常發布特點，對每一次代碼的提交、滯后、變更能夠作出適當反應，允許對仍處于開發、尚未集成的元素進行及時測試；
2. 明確鼓勵測試人員在進行測試設計時充分利用各種信息源，而不于項目文檔；
3. 允許測試工作由于較差的或滯后的項目文檔而受負面影響，但應防止完全阻塞測試工作的情況發生；
4. 允許每個測試案例可以利用不同的信息源進行設計，允許在獲得新的信息源時對測試進行重新設計；
5. 應包含反饋機制，使得測試執行過程中的發現可被及時考慮到測試設計中；
· 開放源碼軟件測試模型框架
以上述需求為基礎并結合開放源碼特點，給出開放源碼軟件測試模型。該模型是一個軟件測試啟發式模型，基本目標是用于提醒測試人員在創建測試時應著重考慮的各種因素，進而可被用來定制測試。
1. 協商并理解項目的測試目標；
2. 理解并協商與測試技術選擇相關的各種因素，理解與測試工作有關的限制、要求和可用資源，從而使得測試更為高效；
3. 在充分考慮和利用其他各種因素的前提下選擇合適的測試技術以達到測試目標；
4. 隨時監控項目項目的狀態，并在需要時調整測試計劃，以使得目標、測試技術的選擇和各種因素保持統一。
測試目標 明確項目測試應優先考慮的任務和側重點。
測試環境 包括資源、限制和其他可能影響測試執行效果的外部力量，應確保在限制范圍內充分利用了各種可用資源。
產品元素 指被測試的對象，應確保檢查了產品所有方面，包括軟件、硬件和操作。
質量準則 包括各種可用來確定產品是否存在問題的規則和數值，具有多維特點，并且常常是隱含的或相互矛盾的。
測試技術選擇 給出各種創建測試的策略和方法，在對測試目標、測試環境、產品元素和質量準則進行綜合分析的情況選擇和使用，并根據測試執行情況及時調整。
二、測試目標
· 發現重要問題 · 評估質量 / 風險
· 標準符合性認證 · 完成過程委托監理
· 讓受益人滿意 · 責任擔保
· 針對 QA 的改進建議 · 針對測試的改進建議
· 針對質量的改進建議 · 效率大化
· 成本小化 · 時間小化
三、測試環境
有許多因素對于項目測試工作能否成功完成具有重要影響，在此將這些因素統稱為測試環境。下面給出一些通用的信息類別，考慮其中各個因素對于測試工作是起促進作用還是阻礙作用，大限度利用各種可用資源，同時將各種阻礙因素的影響小化。
3.1 受益人
指任何對于產品質量能夠發表意見以施加影響的人。所有的需求都直接或間接地來源于一個或多個受益人，軟件測試人員在整個測試過程中作為受益人的代理。
3.2 測試信息
指測試工作所需要的與產品或項目有關的信息。
· 進度
測試： 何時 開始測試以及要持續多長時間？
開發 : 何時構建可以被測試、何時增加新功能、何時凍結代碼，等等？
文檔 : 何時用戶文檔可被評審？
· 預算
需要購買或開發的測試資源和材料的費用如何？
· 過程
項目管理： 項目采用的生命周期模型、項目計劃和監控手段如何。
配置管理： 項目配置管理方法和實施如何？
· 測試條目
可用性： 能否獲得被測產品？能否從開發人員或其他人員那里獲得測試所需信息？
易變性： 獲取的 信息是否新？如何獲得有關新信息或信息變更方面的通知？產品設計和實現經常變更嗎？
可測試性： 產品是否足夠可靠以便于進行有效測試？
交付性： 需要生成何種的報告，是否要共享中間測試結果還是僅提交終結果？
3.3 測試團隊
指任何將要執行或支持測試的人員。
· 工作負載
是否有足夠人力按來照期望時間完成所有計劃好的測試工作？
· 專家能力
是否擁有與項目有關的正確知識以很好地完成計劃好的測試工作？
· 組織
所有測試工作是否得到有效協調并目標一致？
3.4 測試工作平臺
指用于支持和管理測試的軟硬件平臺。
· 測試平臺
是否擁有測試執行所需的全部設備和平臺？
· 測試工具
需要那些測試工具？他們是否可用？
· 測試庫
是否測試過程中的任意文檔和結果均要保存并進行跟蹤嗎？
· 錯誤跟蹤系統
如何進行錯誤報告和跟蹤？
