什么是公理？在百度百科中可以查到：
所謂公理，就是經過人們長期實踐檢驗、不需要證明同時也無法去證明的客觀規律，釋義如下：
1）經過人類長期反復的實踐檢驗是真實的，不需要由其他判斷加以證明的命題和原理。
2）某個演繹系統的初始命題。這樣的命題在該系統內是不需要其他命題加以證明的，并且它們是推出該系統內其他命題的基本命題。
那么在測試領域是否也存在這樣的客觀規律呢？
我們看到，在不同項目的測試過程中，測試行為的差異如此巨大。在軟件測試的七項基本原則中有一條“測試活動依賴于測試的Context”，也就是基于不同版本的應用目標、復雜程度、質量要求以及人員成熟度等等因素，每個測試過程都會有所區別，但不是質量上的差別，而是方法。
因此應該有一些客觀規律，它們并不依賴于所測試的對象（路由器還是手機），所采用的開發模型（瀑布還是迭代），TPI模型正是基于這一認識來建立的，不過在TPI模型中有157個非常詳細的Checkpoint，它們更像由公理推導出來的“定理”。
公理應該是簡潔的，作為測試域的初始命題，從2008年Paul Gerrard （2010年EuroSTAR測試杰出貢獻獎獲得者）第一次提出“測試公理”概念，目前已發展了16條公理，大家來看看Paul所提出下面這些公理是否可以反駁或證偽吧：
首先是測試第一等式，究竟哪些東西影響了測試的過程和方法：
AXIOMS + CONTEXT + VALUES + THINKING = APPROACH
公理 + 環境 + 價值 + 思想 = 方法
Paul按照3個方面來組織測試公理：利益干系人、測試設計、測試執行與交付。
利益干系人
公理1：測試需要利益干系人
公理2：測試的價值是為利益干系人提供決策依據
公理3：如果我們不約束測試的范圍，我們永遠無法符合利益干系人的期望
公理4：測試和驗收的范圍始終是妥協的結果
測試設計
公理5：測試設計基于模型（注：這一模型可能是正式的，由形式化來描述；也可能是非正式的，在測試人員的腦中）
公理6：測試人員需要知識來源（Sources of Knowledge）來選擇測試內容
公理7：測試人員需要知識來源（Sources of Knowledge）來評價被測對象的實際產出或行為
公理8：測試需要一個或多個覆蓋模型
公理9：測試需要一種機制來排序測試優先級
公理10：測試的知識來源（Sources of Knowledge）是模糊且不完整的
測試執行與交付
公理11：通過利益干系人做決策時的信心來衡量測試的價值高低
公理12：一些重復測試是不可避免的
公理13：先執行最有價值的測試——否則可能沒有時間執行它們
公理14：測試執行需要明確、可控的測試環境
公理15：測試永遠不會按計劃進展，測試所得到的證據按照離散量子化的模式出現
公理16： 測試永遠不會結束，只會停止
如果認可這些公理，那么根據它們也就可以推導出哪些實踐是正確的，哪些是不那么正確的。
例如公理10：測試的知識來源（Sources of Knowledge）是模糊且不完整的。在絕大多數開發項目中，都存在這樣的問題：需求質量很差，測試設計所依賴的許多知識：如應用場景，如系統在異常下的行為和結果，都是不明確的，這也是我們一直希望測試能夠盡早投入，通過詳細的測試設計來提升需求質量，達到預防缺陷的根本原因。
再例如公理16： 測試永遠不會結束，只會停止。無論何時，只要你進行測試，就一定會發現更多缺陷。因此，測試是“Stop”而不是“Finish”，停止的原因是因為我們提供了足夠的證據，使得決策者認為剩余的產品風險已經可以承擔，已經滿足客戶的應用期望，因此測試不是“蓋章放行”，不是質量的“看門人”。
我很欣賞2009年EuroSTAR中的一個演講“董事會中的測試人員”，其中Martin Kooij提出隨著軟件產品對人類的生活變得越來越重要，測試人員的終極職位將是“CRO”——首席風險官，負責監控和管理產品風險（注意，不是項目或金融風險），不過Martin也認為這是在2018年才會發生的事兒了！