◆ 也許大家會說不就是性能測試并不是單獨存在的。其實不是完全正確，如果有充足的優秀高手人力資源做性能測試當然很好，但性能測試也不能完全保證所有的項目完全沒有性能問題都完美無缺，因此，項目投入期間，同時性能測試是一個這個費時費力的工作，所以往往都是一般在資源不足的情況下開展的。作為測試主管，更應該，要學會判斷那些相對更加重要的問題項目影響面會更廣，需要集中做性能測試。這時你也許會問，那么會有人問其它相對不太重要的項目與問題怎么辦，?其實做過性能調優的人都知道，大部分的性能問題都是由于一兩個弱智的SQL語句導致的，所以可以從流程上加強對SQL查詢語句在I/O問題的跟蹤與評審,，從而避免大部分性能問題。
◆ 上面分析了不同公司根據上文的分析，不同類型的產品在測試流程上的是有很大差異的。這時，也許大家你也許可以把握測試流程大的方向了，但真正是否適合現有的測試團隊與研發團隊，則仍需要精心的調整，。當我遇到問題的時候， 時間往往有時候不是去尋找流程不對的問題，而是通過現有資源與執行的方法可能需要著手來微調一下你的測試流程，直到發現問題的所在，并紀錄下來，最后整合到原來設定的流程中。
◆ 這樣的情況大概常常發生：比如說在需求上的處理，可能會有很多的測試人員會經常指責需求人員撰寫的文檔非常粗糙不詳細，無法進行測試，。好像在我的記憶中，需求人員常常就是被罵的得灰頭土臉，但是經過這些年在測試崗位上的工作，我才漸漸發現，其實有時候需求人員更需要鼓勵鼓勵是比職責更加有效的工作方式。這可能是一個放之四海皆準的工作態度。，指責只能加深對立，。其實在驗收需求時，由于當時大家也只是知道一個大概我們的需求人員也只能從大致上把握核了解，可能大多數情況下是：原則上沒有問題就通過了，。但然而，這種不負責任的態度卻是給我們在做的測試工作帶來相當多的麻煩。也只有在這樣的時候，這些問題才能真正暴露出來，從而使測試設計時就會發現很多問題并沒有寫清楚，。一般情況下，很多測試人員這時就多半會放棄手邊的工作，并消極地認為認為無法做工作無法繼續下去。，等東西出來，并將問題最終歸結到是需求給的不詳細，而大加指責。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
