昨天讀到一篇朋友推薦過來brian marick的部落格，很有意思。
部落格中主要說了作為乙個測試諮詢師如何使用ant這個方法跳脫常規的習慣，幫助客戶找到問題所在。
鏈結如下：
如果想省點眼力可以往下看我的翻譯，嘿嘿。
ant就是actor network theory 的簡稱，大概也就是說「參與者網路理論」吧。是法國的哲學家/社會學家bruno latour 提出來的。
開始原文逐字翻譯如下：
「我是乙個諮詢師，在乙個專案中有大概乙個星期了。在專案中我跟別人合作- 結隊，測試，還有其他。在這個過程中，我需要做的是發現他們沒有發現的問題，給出他們沒有嘗試過的建議，這一切都是為了幫助他們更好的構建他們的軟體。
乙個艱苦的工作：這些專案很複雜，很多東西都在變動。對諮詢師來說，他們很容易只看到習慣於見到的東西。更糟的是：他們看到不存在的東西，就因為他們這些東西是他們最擅長看到的。
所以，作為乙個諮詢師，他們需要在找到一些思維上的技巧，這樣可以幫他們擺脫常規與習慣。我使用ant作為乙個訣竅。
乙個例項：在敏捷專案中的測試角色
ant群體共同做的一件事情是：把注意力放在事情本身上，看他們是如何變動的。
在70年代中後期，bruno latour -- 乙個幾乎不懂英語的而更是不懂生物化學的哲學家-- 來到了加利福尼亞聖地牙哥的salk institute。他不光是幾乎不懂學院裡的人們都在幹什麼，他甚至還故意的忘記他知道的東西。那時候，他只想在學院裡像乙個人類學家到訪乙個完全陌生 和未知的部落一樣一切從零開始。
正如你可以想象得到的一樣，他的觀察結果很奇怪。比如說，他看到在實驗室裡只有乙個地方會定期的被放置裝訂好的被叫做「報紙」的東西。
（為了便於理解，我把圖留下了）
在其他地方，那些被叫做技師的人們負責管理那些好像是用來在紙上做標記（劃線，打點繪圖，標識數字等等諸如此類）的機器，機器看上去好像很昂貴並且 結實的說。這兩類紙會被送到第三個地方，就是「科學家們」的「辦公室」。科學家們會把2這兩類紙-- 報紙和試驗結果-- 放到一塊來做比較。在作比較的過程中與結束後，他們會寫一些東西到另一批新的紙上，然後送到有「打字員」的地方，這些打字員會「把字打好」（就是格式弄得 好點），然後把他們寄到叫做「出版商」的人那裡，出版商會把他們跟其他「紙」在一起裝訂好，再把這些「報紙」送到。。。 總之接下來還有送到更多的實驗室去。
對於latour來說，這看上去實驗室就像是乙個把一堆紙變成更多堆紙的地方。
現在karl popper, （這個人可能是科學界最具影響力的哲學家） 把latour的所見描述為「附帶現象」，這種附帶現象不是科學所要研究的，科學所要研究的是：
1. 乙個理論家要提出理論。無獨有偶，那些例子好像總是用非常棒的、早已為人所熟知的理論家。
2. 有些人-- 或許是非常厲害的理論家，當然也可能就是別的什麼人-- 從那些理論裡得到一些預言：在x情況下，這個世界可能會出現y。
3. 乙個實際動手的人-- 通常你是不會聽過這些人的-- 就會創造出x狀況，並且觀察是不是y出現了。
4. 如果這個y並沒發生，理論學家只好丟棄掉他/她的那個理論，從頭來過。
5. 如果y發生了，那還不足以肯定這個理論的正確性。沒有太多被確認確有其事的預言能夠符合邏輯的證明乙個理論是正確的。然而，如果這個理論還真是經受得住足夠多的具有挑戰性的測試，科學家們就可以開始在他們的工作做使用這個理論了。
popper同學的觀點對我來說還蠻重要的。因為一些軟體測試人員類很明顯的在測試中使用了popper的觀點。
1. 程式設計師是乙個理論家，提出了乙個類似「對於任何輸入到文字框的x值，程式就會計算f(x)」
2 . 測試人員把它當作一種預言。「所以程式應該計算f(x)，如果輸入是叫做sql注入的任何一種的話」
3. 測試人員搭好環境，嘗試sql注入
4. 如果程式不如預期那樣工作，那麼程式設計師需要回去改動他們的東西，再來試一試
5. 如果程式通過了測試，這個並不能說明它就完全對了-- 還沒有通過足夠多的測試來證明它是無bug的。但是如果通過了足夠多的測試，經理們就吃了定心丸：「行了，發布吧」。
那麼結果是，其中乙個人預見這個**面世以後可能面臨的問題，並且提出意見，使**能更好的得到接受。然而，我不認為著當時我意識到了，這個方式，是richard p. gabriel從創造性寫作協會引入設計模式協會的乙個合作方式。（writers』 workshops and the work of ****** things
.）我意識到了，這個是乙個把測試人員的技能使用到產品與團隊團結合作的氛圍的方式。所以，我開始在我的諮詢工作中運用這個方法。給什麼樣的建議要看是什麼樣的團隊。我可能會把測試人員放到支援產品owner這個角色裡面。他們可能會幫助產 品owner更明晰和全面的了解她想要什麼，然後他們就可以把她所表達的那些東西轉換成更清晰的測試場景描述，程式設計師可以在測試驅動開發中使用。或者我會 把測試人員放到幫助程式設計師了解領域知識這個角色，一次乙個測試。（這個會影響到你寫的測試的型別，以及使用他們的順序）。等等。
我想這個思考的方式在敏捷世界中是非常普遍的。沒有我，它可能也會這麼發生。-- 我絕不是唯一乙個這麼想的人。這不重要:重要的是如果沒有吸收latour看問題的方式的精髓，我可能不會這麼看敏捷團隊合作的問題。
ant 構建單元測試
1 使用ant對 進行編譯構建，編譯到 dist目錄下，步驟省略。2 單元測試構建指令碼，單元測試的classpath需要包含之前編譯目錄和testcase的編譯目錄 3 find bugs 開始用findbugs檢查 錯誤.findbugs檢查 錯誤完成.findbugslib目錄jar包列表 a...
軟體測試方法與測試策略
測試方法 是指解決問題的技術手段或工具的集合。測試策略 是指如何選擇和運用方法來解決具體問題。策略定義了 要使用的測試方法和工具 測試要完成測試和測試成功的評價標準。如測試用例通過率95 表示可進行驗收測試截斷。影響資源要求及涉及進度的特殊考慮。策略重點關注元素 測試型別和針對該型別所要進行的測試目...
硬體測試流程及方法 測試流程與測試方法
1.產品 開發 測試流程 需求分析 需求分析由產品人員制定，細化每乙個功能的細節，每乙個按鈕的位置，對於稍大或複雜一點的需求進行建模。需求評審 這裡會叫上所有參與專案人員進行，開發人員 測試人員。測試人員提出需求，開發人員考慮功能實現的方案與可行性 當然開發負責也是要參與的。測試人員主要是對需求的理...