原文發表於2008-12-27 11:55:26
上回講到在測試人員與開發人員“鬥爭”的泥淖中出現了一線曙光,看了這篇的題目千萬不要誤會我真是看醫生去了,只是去做另外一項工作了。
還是測試,還是這個項目,不過戰場還是不太一樣:由“功能測試”改作“效能測試”了。或許有前輩會說怎麼會讓一個連功能測試都做得亂七八糟的毛頭小子做效能測試這麼神聖的事情呢?只能說大千世界無奇不有啊,其實現在應該也會有類似的人出現在類似的場合做類似的事情吧,所謂類似的人就是一個對於基本的功能測試都不熟悉的測試新手(或許是像我當時一樣有了半年的草根測齡的測手,甚至就是一個剛進公司剛接觸測試什麼都不會的新手),所謂類似的事情就是比較麻煩的如效能測試之類的測試活兒,所謂類似的場合就是(頭兒自己都不知道測試為何物,或者知道一點皮毛然後就按照自己的理解交代給測試人員“測試工作”)。我相信,類似的情況在目前的中國小軟體作坊裡面大有“況”在。
我呢,反正就一毛頭小子又是“一人吃飽全家不餓”的類型,也就不怕什麼難不難,反正想著“組織這麼信任我,我一定不能讓組織失望”再加上初生牛犢不怕虎的豪氣,竟然樂呵呵地接受了任務。
現在想起這件事,真有點佩服當時的自己,雖然整個過程跌跌撞撞,但是那一段時間學到了不少東西——
在接受了任務之後,我立馬開始Google效能測試,一不小心直接Google到效能測試定義以及效能測試計數器上面去了,然後在效能測試是什麼上面糾結了幾天的時間,可是事情不能沒有進展報告啊,於是乎我湊了一份效能測試相關的資料作為進度報告擋了一陣子。說實話,當時雖然看了好多天,但是一直沒有搞清楚效能測試是怎麼回事,但是項目進度要緊,只能硬上弓,直接拿VSTS來試,幸虧是一個簡單的Web頁面操作,更幸虧微軟的VSTS還不錯(當然比較起專業的如LoadRunner來講,VSTS中的Web測試載入器錄製的指令碼的效率並不高也顯得囉嗦),我刷刷刷地錄製了一份指令碼。接著還是靠著VSTS自身的負載測試工具照著我心目中想的樣子“效能測試”。
結果怎麼樣呢?“一個停擺的鐘一天中也有兩次是正確的”,這次還真讓我碰上了,我竟然奇蹟般的發現了一個效能節點。別嫉妒我運氣這麼好,要怪就怪那個效能節點太明顯了,是一個並發測試很容易發現的問題:開發人員在設計的時候給每個使用者開了一個監聽器,這樣導致了伺服器端的記憶體CPU佔用率狂飆不止。其實我是通過查看“工作管理員”看出來的,壓根沒管什麼效能計數器,當時那水平看不懂這些啊。
效能節點找出來了,這次效能測試的目標在大家看來也達到了,可是事情還沒有完。還缺一份測試報告啊。
沒想到自己第一次整測試報告就直接整一效能測試報告。一開始還是老方法,先到網路上找效能測試報告的模板,然後東拼西湊整到一塊兒。提交上去的報告很快被打回來了,原因是與項目有關的資料沒有。
馬不停蹄的趕製了第二份報告,在第一份報告中加入了項目資料表格,羅列了一大堆我自己都看不懂的資料到報告中,一時間報告看起來漂亮多了,也貌似有點專業的味道了。於是信心滿滿地提交了第二份測試報告,這次拿到的回複是:報告很詳細,但是報告中不必要的套話太多,報告中表格過多而沒有圖表,不利於資料的分析。
再改。刪掉了在網路上找的大部分資料,將表格全部替換為圖表的形式,十幾頁的報告一下子改成了六頁的報告,看起來清楚多了,這回終於等到了我想要的回複了:這份報告目前來看可以了。
報告通過了,我的使命終於完成了。雖然在現在看來,我當時做的算得上亂七八糟了,而且報告很不專業,也不合理,但是在當時看來,已經是非常高興的事情了,畢竟我又完成了一件從來沒有完成過的事情,而且在這一過程中我又學到了很多新的東西。成長其實就是這個樣子,磕磕碰碰,這些都是成長所必需的。
效能測試的工作搞定了,假釋期也過了,該回到原來的道道上了。日子又回到了以前的糾結之中,人品一向不錯的我,在不久之後就又碰上好事了。