先講一個案例：

　　企業(yè)網站已經運行多年了，訪問速度越來越慢，近用戶反映，打開個網站首頁快的時候也要2、3秒，慢的時候需要喝杯茶了，還不如上外網新浪搜狐快，廠領導重視這個問題，信息部的領導當然不敢怠慢。

 

　　首先組織人員參觀附近的運行比較好的相關網站，比如總公司的，地方上的信息港等，現場咨詢了相關設計人員若干問題。

 

　　然后組織會議，召集相關人員討論、分析網站首頁慢的原因。網站的開發(fā)人員、維護人員、測試人員以及各方領導都參加了分析。結論很快出來了，接著領導們開始提改進建議。但會議卻好象陷入了僵局。

　　網站首頁慢的原因如下：

 

　　1、在首頁打開的數據庫(表)太多。因為首頁要各車間、單位的新數據列表，提取新數據占用了太多時間。


　　2、數據庫有問題。測試人員在逐個測試數據庫時發(fā)現，雖然網站涉及多個數據庫服務器，如辦公郵箱服務器、郵件服務器、文件服務器、各生產數據服務器等，但有一臺服務器明顯慢了許多，斷掉這臺服務器，網站首頁的打開速度進入毫秒級，將這臺數據庫的數據導出至另一臺備用服務器上，并將WEB服務器上的鏈接指定到備用服務器，訪問速度依然是毫秒級。

 

　　3、首頁中的SQL語句有問題。特別是Oracle中數據表指針的移動很費時間，需要優(yōu)化。

 

　　解決方案也接著出來了，如下：

　　將首頁改為靜態(tài)的。首頁中不再訪問所有的數據庫服務器，而是若干文本列表，這些文本由其它數據庫(表)在新增記錄時，同步在WEB服務器上生成。首頁是靜態(tài)的，速度會快多了。

 

　　測試人員表示反對這種方案，認為問題出在數據庫上，而不是網頁的動態(tài)或靜態(tài)上，但在討論的過程中，領導強調指出問題必須給出解決方案，否則不予考慮。于是，表態(tài)的人少了，會議沉默了，然后是方案的實現，解決問題的時限，散會……

　　這是個真實的案例。在本案例中，測試人員先期很積極的尋找網站速度慢的原因，但后來歸于沉默，是因為測試人員沒有能力解決這個問題，只能從多個方面尋找問題的原因，但誰找出問題誰負責解決的做法，打消了測試人員的積極性，測試人員是找問題的，不是解決問題的。多一事不如少一事？梢灶A見，這個方案終會不了了之。

　　這是在大多企業(yè)中軟件測試人員的一種窘境，測試人員即要發(fā)現問題，還要解決問題，并且測試人員和開發(fā)人員一般在同一個部門，發(fā)現的問題越多，自己不解決，給開發(fā)人員造成的返工量越大，開發(fā)人員和測試人員的矛盾很多，又得不到有效的解決。

　　總結企業(yè)中測試人員面臨的問題：

 

　　1、測試人員的工作量很大，同時要為多個項目做測試，但收入卻很低。

　　2、測試人員不具備獨立性，企業(yè)的信息部門很少設有測試組一類的，測試人員往往和開發(fā)人員在同一個科室，開發(fā)人員有時兼做另一個項目的測試人員，表面上是方便了與開發(fā)人員的交流，實際上卻阻礙了測試工作的進展，礙于情面，誰都要在組織內生存，誰都不愿以工作影響了同事關系。

　　3、領導對測試工作的輕視問題。有些領導不懂測試流程，甚至分不清集成測試和系統(tǒng)測試，不給測試人員說話的空間，喜歡自己說了算，當然這是題外話。

　　4、測試人員要解決自己發(fā)現的問題。雖然開發(fā)和測試角色可能出現重復，但兩者的側重點是不一樣的，測試是發(fā)現問題，而開發(fā)則是解決問題。在實際工作中往往不是這樣，特別是在一些技術問題分析會議中，誰提的問題多，誰終負責解決問題。迫于生存，測試人員一般不多表態(tài)。

　　5、測試人員的素質。程序員在干不動編程時，才會轉行做測試，做職業(yè)轉行的緩沖，一些的編程人員一般都安排做開發(fā)了，人員不做測試重要的原因是收入低，領導也不會安排這樣的人做測試，認為是人力資源浪費。所以，從開發(fā)崗位上轉行來的測試人員，即使有豐富的開發(fā)經驗，他也不能對所發(fā)現的問題全部解決。人員的缺席也導致了測試工作效率降低。

 

　　總之，一個軟件企業(yè)中，測試人員無法發(fā)揮他應有的作用，只能說明該企業(yè)的軟件過程能力有問題，這屬于管理人員的問題，而非測試人員所能做的。