性能測試服務日記(2)

　　上午休息了下，下午還得馬上跟移動G經理匯報性能測試結果情況，所以下午3點左右我們三人一起從西北路的移動營業廳打車到xx移動。就性能測試報告結果我給G經理做了簡短的匯報，就性能測試報告、當前遇到的問題困難與風險以及性能測試工作下一步的開展一一做了專業的講解和解釋，所以整個匯報的過程完全在我們的控制范圍內，客戶也接受了我們關于下一輪性能測試策略調整、重點以及其他方面的建議，這時，我突然發現，原來我們做的工作是這么的有價值，也有了一點點的成就感，這個為我們第三、四輪的性能測試工程的開展做了一個很好的鋪墊。

　　項目第六天

　　意料之外的是三、四輪的性能測試工作竟然要在第二天凌晨來進行(后來才知道是LC也想盡快看看第一、二輪的問題是不是已經解決了，另外也不希望割接延期)，所以，沒有辦法，我們整個性能測試團隊，包括LC代表以及移動G經理晚上又做了兩輪，還是由我來主導整個性能測試過程，A負責配合資源的協調。有了前面第一二次的經驗以及發現的性能問題，根據客戶以及LC的要求與建議，第三、四輪我調整了測試策略，適當調整了性能測試的業務比例模型，加大了CRM前臺業務的比例，調整并發數到250和400兩個值，做了一次負載測試，順便得出在兩個不同并發下的平均事務響應時間以及TPS等關鍵的性能指標。

　　順利的是主要業務的性能指標基本理想，這樣以來LC的項目經理也發現了性能測試的核心價值。做完了，還是跟第一二次一樣，我連夜把性能測試報告趕出來。

　　項目第七天-第十一天

　　這段時間因為被測試系統功能上都還存在不少的問題，這樣也為我們測試腳本的修改、調試包括測試數據的準備帶來了很大的困難，這段時間我們主要和移動在交流。LC的項目每天晚上領一瓶牛奶、一小袋干果、一些面包就當著晚上加班的夜宵，一開始他們發東西的人不認識我們，所以我們自然沒有，所以a有時就自己掏腰包請我們吃夜宵。其實在這個過程中，遇到最大的困難反而不是技術上，而是我們的工作開展完全受制于LC的整體工作安排以及被測試系統開發進度等方面的問題。另外就是大部分CRM系統的腳本需要重新開發

　　我原以為腳本的開發對于我而言應該幾乎沒有難度，但是由于一些業務規則我們不是很熟悉以及客戶要求使用的LoadRunner的版本只能是8.0(受 Lincense限制)。另外結合前四次性能測試活動中的經驗與不足，比如為了趕時間進度、流程不規范、測試環境、測試數據包括測試腳本開發、測試場景設計等方面都存在明顯的問題，以及為了能夠很好的把這次經驗能推廣到其他省的NGBOSS，我把部分精力就調整到重新來設計和寫我們在NGBOSS領域專門的性能測試服務介紹材料，希望能在系統化、流程化、規范化等方面做一些嘗試。到現在為止，基本完成了相對完整的整體性、系統性的技術架構體系。當然，里面還有很多細節需要在后續由整個團隊一起來協調配合完整，因為按照我的規劃，這個工作量非常大。就拿咨詢體系的3大指導書、5大過程規范、12大模板以及8 大checklist就需要不少的時間精力甚至是靈感來完成。

　　項目第十二天

　　第五、六輪性能測試執行，相比前四輪，補充部分子系統的性能測試，整體的測試策略做了調整，第五次測試300并發，實際并發284，測試的是幾個關鍵子系統的完整的綜合業務模型，在這個過程發現了CRM系統WEB服務大量HTTP503錯誤以及少量HTTP500錯誤，另外WEB服務器內存泄露的問題依然存在。系統在TPS和相應時間反而比前兩次更差，后面分析原因是這兩次測試活動的環境跟前面幾次不一樣，另外系統除了在做性能測試以外，還在做信控等其他活動。為了更加驗證CRM系統存在問題，第六次性能測試專門針對CRM系統單獨做性能測試，測試出來的性能指標LC方面非常不滿意，尤其是項目經理，覺得無法向領導匯報，在這個過程中也出現了不少的突發事件，比如工具測試出來的響應時間跟手工測試的響應時間相差頗大，LC的項目經理就揪著這個問題不放，還好的是，這些問題都在我們以前的性能測試活動過程中遇到，分析其原因是因為測試數據選擇有問題，有些電話號碼屬于合帳號碼，他們做業務肯定會慢，從技術上來講，我們給客戶的解釋就只能是性能測試數據建模的意義，當然實質上要把這個東西搞好，光懂一個LoadRunner是遠遠不夠的，這方面需要非常豐富的實戰經驗。這點我最大的感觸是，現場的服務別人是把你當專家的，所以所有可能的現場問題都需要給客戶一個合理專業的解釋/

原文轉自：http://www.uml.org.cn/Test/201601082.asp