高工：我補充下剛才張工提到的think time，Think time本身是測試軟件里的一個名詞。它這個在ERP系統中是怎么體現的呢。我們可以這么理解，在這個實際ERP操作里拿出一張單據來講，它這個think time可能就在錄入的過程中有一些人工去校驗的時間，包括人工去核對的那個時間。因為核對正確以后我們才會保存，這個單據才算制單完成了。這是一個整個過程，像人工校驗和核對的這個時間就可以把它在ERP這個系統稱之為think time的一個時間。那按照一般經驗來講一個熟練的員工他完成一張單據的錄入，比如說一張入庫單或者一張銷售出庫單，可能最少的可能也要花個兩三分鐘吧。我們測試的時間其實就是機器系統的平均響應時間。這其實是遠遠低于實際中的操作時間的。
PConline：我們接下來就測試當中發現的一些問題咨詢下二位。這些問題可能相對的比較具體一點，比如說說在測試帳務模塊中的科目余額查詢。開始我們理解是一個查詢功能，但是實際測試的情況來看這個模塊響應的時間非常的長，甚至超過有十分鐘的。那么后來我們是簡單查閱了腳本。從功能表達上感覺科目余額查詢更像一個報表功能吧。就因為腳本設置中我們大概設置查詢的期間是2007-1-1至2007-8-31這一個時間段，科目數目大概有10來個科目。我覺得這樣功能他更像一個生成報表的功能，而不是一個簡單查詢的功能。
高：測試中對這模塊設置的并發數多了一些，因為實際操作中不可能達不到這么多并發數�？颇坎樵冊谶@個過程中對數據進行了一個復雜計算、匯總、統計、分析然后得出這么一個結果（顯示報表）來。另外我們準備的數據是在這個企業好幾年累計下來的一個數據。雖然查的是1-8月份的，但是實實在在的數據量擺在那里，查詢的時間長度也占了一定的時間。這幾方面都會造成這模塊的響應時間比較長。在企業實際使用的時候，它不會像我們這樣去查詢的。不會跨越這么長的時間段然后同時查那么多的科目。查的話可能只是查某一期間、某一科目的數據，那樣的響應時間不會很長。