摘錄自《探索式軟體測試》（注：作者模仿了聖經十誡的語氣和內容編寫了軟體測試戒律）
1.汝應用大量輸入重複錘煉汝之應用程式
2.汝應貪圖汝之鄰居的應用程式
3.汝應親自尋找睿智的預言家
4.汝不應崇拜無法重現的失效
5.汝應尊重汝的模型和自己主動化測試
6.汝應利用開發者的過錯與他們作對
7.汝應醉心於**應用程式（慶祝藍屏吧）
8.汝應保持安息日（指產品公布時刻）的聖潔
9.汝應貪圖開發者的原始碼
下面內容主要來自《探索式軟體測試》。本人依據自己的理解對部分內容稍作了改動
3.汝應親自尋找睿智的預言家
我們都知道，測試至少存在兩個部分。
首先我們使用輸入資料，然後對結果進行檢查。
我們將資料輸入到軟體中。然後測試該軟體是否依照既定的方式回應這些輸入。
假設我們無法對結果進行驗證，測試就無法有效進行。
關於所謂睿智的預言家。我們有興趣的是「應用某些測試後，該應用程式是否依照既定的方式執行？」。這就須要我們的預言家（也就是測試的基準）清楚的了解在給定特定的輸入和環境條件組合的情況下，程式應有的行為。
（博主的理解：即要事先知道你要執行的測試會有如何的預期結果。博主更願意把這個預言家叫做預期結果。假設不知道預期結果，你也就無法推斷程式返回的結果是不是正確。）
將測試基準進行自己主動化是一件非常困難的事，可是非常值得去最求，由於這不只能夠建立乙個非常有價值的測試工具，其本身也是乙個啟迪智慧型的追求過程。即通過自己主動化的活動，你得到了乙個更加聰明的測試者。不管你終於是否能成功地將測試基準自己主動化，強迫自己像它一樣思考。經常比你可能選擇做的其它不論什麼事情更有工作效率。
4.汝不應崇拜無法重現的失效
我們都曾遇到這樣的情況。不是嗎？你遇到乙個缺陷，一般是非常好的缺陷，可是卻無法重現。
缺陷越好，你的感覺越不好。
我以前見過很多優秀的測試人員，花了數小時甚至數天的時間試圖重現乙個他們僅僅見過一次的缺陷。
為了重現這樣乙個缺陷的嘗試一般是英勇的，可是沒有合適的工具，這些嘗試僅僅能是浪費時間。而我看到的情況是時間被白白浪費了，而測試人員卻沒有意識到這點。
我以前看到乙個測試人員花了一整天的時間試圖記起乙個崩潰缺陷的重現步驟，可是沒有成功。
我更願意那個測試人員把他的時間用在其他更好的地方。和其他不論什麼乙個測試人員一樣，我全然理解那種挫敗的感覺。可是最求乙個這種缺陷的結果往往是無法充分利用時間。
這條戒律的教育意義是雙重的。第
一、盡你最大努力注意並記住（或記錄下來）對軟體採取的測試步驟。同一時候記住應用程式的響應。
第二、考慮使用偵錯程式之類能追蹤動作和軟體狀態的工具。這將去除重現缺陷時不少推測成分，並防止優秀的測試人員違背這條戒律。
博主理解：縱觀全文，這條戒律的教育意義應該是有三重的，最後一條作者在前面提到了，但並沒有在最後的歸納中寫下
1、努力記錄步驟和結果
2、盡量使用工具輔助
3、假設重現太困難，不要在它上面浪費太多時間，將你的時間投入到其他更有效率的測試中。這樣對專案整體是更好的選擇。
James Whittaker的軟體測試戒律（一）
摘錄自 探索式軟體測試 注 作者模仿了聖經十誡的語氣和內容編寫了軟體測試戒律 1.汝應用大量輸入反覆錘煉汝之應用程式 2.汝應貪圖汝之鄰居的應用程式 3.汝應親自尋找睿智的預言家 4.汝不應崇拜無法重現的失效 5.汝應尊重汝的模型和自動化測試 6.汝應利用開發人員的過錯與他們作對 7.汝應醉心於 應...
container of 的的的原理
另外一篇，同樣精彩，揭開linux核心中container of的神秘面紗 華清遠見嵌入式學院講師。在linux 核心中有乙個大名鼎鼎的巨集container of 這個巨集是用來幹嘛的呢？我們先來看看它在核心中是怎樣定義的。呵呵，乍一看不知道是什麼東東。我們先來分析一下container of p...
存在的就是合理的，發生的即是必然的。
筆者有時候會想，什麼是對，什麼是錯？對於追求某一件事情之前首先會考慮，為什麼我要做這件事情。所以經過自我分析和生活周邊環境的總結。我認為，對於乙個人來，這是在站在個體的角度上說。什麼是對的？就是你自己覺得是對的，它就是對的。不過這個只是你自己的想法。主觀上的正確，不代表客觀上也受到了別人的認可。就拿...