審、測、評
---- 從測試過程看軟件測試
需求，是系統持續的、穩定的滿足客戶要求的能力。
“什麼時間介入測試。”，測試人員一直在不斷的思考着這樣的問題：什麼是軟件測試介入的最佳時間。
“儘可能早的測試”，無論從測試理論，還是測試人員自身，都會這樣的認爲。
風險前移，儘可能早的發現問題，改正問題，減少修正問題所帶來的花費，經濟化原則。
軟件開發是創造性活動，而軟件測試是保護性活動，也就決定了軟件測試活動只有在出現重大問題時纔會引起大家的注意和重視。
那麼，儘可能早是多早，從軟件有意向時就開始嗎？儘可能早的開始，那麼測試早開始要做什麼？採用什麼方式？達到什麼目的？
首先我們看一下軟件開發過程和軟件測試過程，典型是V模型
從需求開始，會有嚴格的V&V過程，可以做爲測試過程。執行人員會涉及到系統開發的各個崗位和角色。
在實現過程中，會有單元測試和接口測試。由開發人員執行。
編程結束後，會有功能測試、集成測試和系統測試，然後是反覆不斷的迴歸測試。由專業的測試人員執行。
系統交付後，會有驗收測試。由內部驗收和外部驗收人員執行，或是由第三方執行。
從整個過程來看，會將軟件測試過程分爲三大類：審 --> 測 --> 評
審：對應測試計劃階段，包含了測試執行前的全過程。
從市場調研、售前支持、需求獲取、需求分析、系統計劃、系統實現的整個過程，在這個過程中，軟件測試完全處於準備狀態。
在這個階段，軟件測試大量的在做評審工作，從不斷的“審”中，發現系統存在的問題和漏洞，使系統具有可測性前題。
同時，測試人員需要通過審，完成對軟件系統的瞭解，分解系統需求爲測試需求，並估算測試工作量，完成測試計劃的制定，確認測試策略。
這裏推薦X模型，強調測試和開發工作的平行進行，完成測試執行前的準備工作。
測：系統測試執行過程。
一但系統成型，達到測試標準，就可以釋放進行相關的測試。
這裏推薦使用X模型。
我們需要完全的集成後的系統測試，但是我們仍然要貫徹儘早測試的原則。把一些系統核心業務之外的模塊功能進行先期測試，保證不同階段、不同測試類型的測試的重點。
這裏提到持續集成的概念，也是敏捷的觀點。越少的集成，越早的測試，把非主流問題提前解決，使問題定位花費更少的時間、更少的投入。
先保證各模塊的穩定性和可靠性，其次是系統接口的穩定性和可靠性，最後是整個系統的穩定性和可靠性。
每個階段都會有自己的測試工作重心，每個階段都會有自己的測試工作流程，通過不斷的調整工作方式和方法，達到最佳的測試效果。
評：系統測試效果如何，系統是否達到要求，對軟件測試過程和結果進行定量的分析，從而對系統進行量化評估。
這裏的評分爲兩種：一種是內評；另一種是外評，也稱爲第三方評測。
無論哪種“評”，都需要採用審慎的態度，從軟件過程到系統本身均需要給出明確有效的“評”結果。
這裏的評，無論是內評還是外評，其實都是對測試工作的確認，從而量化分析得出系統的質量。因此建議採用“第三方”的形式。
內部組織需要項目相關負責人、相關參與者、測試人員、質量保障人員多方構成，保證系統開發的方方面面、系統實現的方方面都會有人蔘與和評估。
外部組織則藉助第三方的力量，通過第三方嚴格的測試和評估，形成對原有內部測試結果的對照，從而有效評估系統質量。
這裏需要指出，一個好的軟件開發過程不一定能保證系統的正確性，但是一個混亂的軟件開發過程則一定不會有良好的系統實現。
風險時時存在，任何的系統中都會存在問題，這也是軟件測試的重要原則。