寫乙個好用，持續可用的測試工具，需要滿足如下幾個特徵：
完備、封閉
自排程結果可評價
易回歸case 所需要的資料都來自測試工具本身，不需要外部人工準備。例如做乙個大查詢測試工具，大查詢的資料應該由工具本身插入。
違反這個要求時，部署測試就會十分麻煩，容易出錯。
乙個複雜的測試可能需要多個邏輯相關的先後步驟，例如：準備資料階段、a測試階段、b測試階段、校驗結果階段、清理環境階段，其中，準備資料階段、b測試階段還會並行執行。這樣乙個先後順序，不應該依賴外部人工幫助排程，必須測試工具自身控制排程順序。
違反這個要求，由外部工具來做排程，排程順序很難保證。
就算是隨機測試，或者純粹的壓力測試，結果也必須是可評價的。評價的粒度、角度可以不同，但指標必須明確定義。例如，常見指標包括：資料正確，結果正確，沒有 core，沒有 error 日誌，效能符合預期，測試程式可終止，測試過程中無異常，中間狀態符合預期，等等。
這個要求看起來很自然，但在實踐中會遇到很多問題，需要努力去逐一解決。例如，randomquerygenerator（rqg） 測試結果對比中，ab兩個系統本就在某些地方不完全相容，結果必然不等，但這種不等是符合預期的，評價測試的時候就需要將這種情況過濾出來；再比如，測試程式不夠健壯導致測試結果難以評價；再比如，測試系統熱點，怎樣才算遇到了熱點，遇到熱點後的表現是怎樣的，如何程式量化？
個人認為，結果可評價，是設計資料庫測試工具中最難的。
自動回歸是測試的靈魂，任何乙個測試系統都必須具備可自動回歸的特徵。回歸成本越低，可能創造的價值越高。上面第一點、第二點特徵，很大程度上都是為 「易回歸」服務的。如果不需要回歸，手工完成準備資料，排程 case 的步驟，也未嘗不可。
junit測試的一點心得
相信大家都使用junti進行測試過，沒使用過也沒關係因為這篇文章內容和題目其實沒什麼關係，呵呵，只是在用junit時發現了一點小問題。在用junit測試由spring託管的程式時，有時會載入一些外部檔案例如如下配置 persistence.xml就是外部檔案，還有例如hibernate的配置檔案，i...
KMP的一點心得
int next next陣列儲存的是當模式串匹配不上的時候將要跳轉的下標 void getnext char b int kmp char a,char b 尋找主串中有多少模式串 return k int kmp char a,char b 判斷主串中是否有模式串 return 0 字串a代表的...
學習的一點心得
關於 理論上為每乙個實現的功能設計乙個函式，有利於 的分解 關於注釋 注釋有三個功能，1.說明用途 2解釋複雜 3.傳遞元資訊 作者，完成日期，修改的bug，待完成的功能，程式的功能，版權資訊等 因為 有時候並不是你來維護的。盡量使用英文注釋，乙個專案組要有統一的規範。關於命名 成員通常m開頭，布林...