探索式測試實踐之路速讀感

　　本來打算寫了這篇讀后感提交參與博客活動的，但是想了下，自己工作經驗不足，測試經驗更是不行。所以不打算拿出去“賣了”，唉。自己感慨感慨下.

　　這邊書基本都是說的探索式測試，什么是探索式測試，我看完之后的理解的就是一邊測試一邊修改測試方案，有一個雛形到一個完美的測試方案的測試方法。其實就類似“在黑暗中摸索前進”，過程中不斷學習和改進，想想猿人，能夠如此的“進化”，說不定人真是由此而來。

　　上面都是理論的，而且是空洞的，因此都是“廢話”，其實，我們讀大學也知道，很多選修課都是一大堆理論，我們學習完了，不知道如何運用，因此我們很”迷茫“。其實理論的東西還是有用的。

　　記得大學的時候，有一門課程就是軟件測試，當時寫軟件測試結課報告，用到了一個.jar的測試工具，能夠根據參數繪制出曲線，具體記不太清了。當時根本不知道所謂的軟件測試到底有什么用呢?接著寫了個等腰三角形的測試用例，就是一個大表格，然后把所有可能的情況，主要是邊界值和極限情況全部列舉了一遍，然后根據程序輸入，最后判斷情況。當時用的是c語言，所以在console下輸入的。當時的知識太少，不然可以利用腳本或者批處理文件來做，這樣省去了很多事情。如果你把程序寫的夠完美的話，可以定義一大堆出錯宏定義，每個值表示不同的情況，利用日志的方式將所有的出錯的返回的出錯宏去得到你自己定義的bug結果。而上面提到的腳本的方式，我只是知道簡單的利用腳本，從輸入出發，利用腳本得到輸出，也就是所謂的黑盒測試。輸入->輸出。

　　這些好像和探索式測試讀后感沒什么關系哈!其實還是有的。我們寫好了測試案例，以文檔的方式，然后逐個進行測試，把測試結果記錄到文檔里面，最終提交bug，提交測試文檔。很多公司大體上都是這樣的，至少我之前呆過的公司是這樣的。專門有個文檔記錄bug，如果沒有就不提交。這點我不太看好，我認為測試的所有的結果都應該記錄到測試用例文檔中。這樣便于我們根據情況進行改進和完善測試方案。而探索式測試之路這篇文檔，里面提到的這種測試方法的結構圖解，我不是很理解，我沒做過測試，呵呵呵。不過我覺得書中提到的基本上都是以一種文字方案的方法去執行測試，考慮各種情況。比如對于產品我們處理測試產品是否沒有很大問題，然后是否運行順暢之外，我們還需要考慮產品的用戶體驗，實用性，美觀性等等。如果比較嚴格的話，我們還可以根據產品的市場價值進行評估測試，這些就需要產品測試經理的豐富經驗了。而如果對于給公司部門做小插件的時候，我們考慮的更多的是代碼的質量，效率和接口的封裝性，其中質量是最重要的，直接影響效率。當然其實質量就包括了效率，封裝性，邏輯結構等等。

　　文章中我看的比較多的就是關于淘寶的測試案例：支付寶大家都清楚，完成了開發，很重要的就好似測試了，尤其是這種涉及到bank的交易，任意的bug都可能導致意想不到的不良后果。因此要求具有很高的安全性(操作錯誤了錢不會無緣丟失，不會輕易被黑客侵入等等)。網頁很重的就是用戶輸入的合法性檢查，以及密碼的安全性，交易過程中的安全性，不正當操作的容錯性等等。諸多情況都要求我們的測試任意要能夠想到，制定完善的測試方案，并且不斷改進。相信你進入公司后，你參與開發軟件或者其他產品，你的測試人員會經常和你打交道，時間久了，你自然就會以測試人員的角度去進行開發，當然你不可能完全考慮到，因為你的經歷不再測試上面，所以還是需要靠測試人員，而且越專業越好。

　　好的產品需要經的起任意“玩弄”，書中提到的反復執行同一個操作，目的就是為了看你的產品夠不夠“硬”，這點我覺得挺好。記得曾經在沈陽參加招聘會的時候，“京東商城”的人員提到了他們的依次活動由于某段時刻突然訪問量增大，然后服務器無法“抗壓”就崩潰了，不過得到了及時解決?？磥磉@些東西確實要“夠硬”才行。你是根據文檔也好還是利用腳本或者工具也好都需要認真的實施...當然這其中其實要求我們的開發人員能夠提高自身的技能，盡量考慮全面，這才是“王道”，為什么國外的軟件很多都很好，從數據上表面：國外的測試投入量遠遠大于開發，而國內真好相反，不過也沒辦法，國內講究的是敏捷開發，I think!

　　我算是也接觸過一些測試，主要就是不斷的輸入各種情況，然后根據數據庫進行對比，看是否正確，我基本上花了一個星期去修改和測試，反復的做。說實話，開發其實很早就完了，就光測試和修改就花了兩個星期，而且下班后還在思考，唉，都快成“精神病”了，嘻嘻。原因就是我開發的這塊功能是網頁的，然后本身邏輯比較麻煩，又考慮到要做窗體版的，因此又必須修改代碼，讓其適應兩套方案，當時頭都大了。到現在都記憶猶新啊!后來離開了....原因挺多的，但是不是背叛....去的那段時間，鍛煉了文檔的編寫，業務的學習...測試???

　　其實我認為的測試方法：測試文檔+性能，測試文檔就如探索式測試一書所描述的方法，根據不同具體情況進行測試方案策劃，其次我覺得應該考慮性能，軟件可能沒那么重要，但是軟件的反應速度，任何需求模塊的性能都要納入，整體響應時間都需要考慮，并且根據方案提高性能。對于硬件來說就更重要了，專業的測試才可以的。不然你的硬件都不行，其他“甭談”!

　　我目前聽過的測試方法比較“牛”的是一家“芬蘭”的公司，名字就不說了，他們公司在芬蘭很老牌了，而且公司本身實力不過，給芬蘭做了很多高質量的軟件。他們公司的氛圍是“每天按照安排完成就好了，不要太快”，在北京的分部每天下午都要開會，因此你就知道開發的時間不是很多，但是能夠在特定時間內完成，他們不趕進度，可以想象，代碼質量不會很低。這只是文化，最牛的在后面...

　　公司有自己的一套自動化測試系統，而且還在完善中，玩Linux的人知道git吧，我們一般開發完后都需要和其他人合并項目。該公司的系統會定時掃描提交的代碼，進行檢查，然后自動化編譯。如果你的變量命名或者函數命名不符合自動化測試系統的話就會在網頁上顯示本次測試的結果，不同顏色表面不同情況，然后根據具體情況去修改。我覺得太powerfull了，我特別崇拜這種系統。至少代碼質量特好，編譯器搬強大的功能。羨慕歸羨慕，其實我們需要做的是寫好代碼，技術第一。

原文轉自：http://www.anti-gravitydesign.com