最近剛接手一個新專案，在最開始的時候要求對這個專案做效能測試，產品經理也給不出效能需求，只因為這個專案是電商專案，可能會有高並行，秒殺的場景，所以產品經理要求我們對這個專案必須做效能測試，又因為這個專案是一個新專案，所以大家都沒有重視起來。過了一段時間，當領導問到這個專案的效能測試方案如何落地的時候，大家都懵了，都不知道該怎麼辦。然後測試組長就把目光投向了我-----整個測試團隊唯一的測試架構師，在這個時候，我就想起了還有研發架構師，於是我就找到了研發架構師，一起溝通這個專案的效能需求！！！
因為最開始的時候，產品經理也給不出效能需求。要想在專案最開始的時候給出效能測試方案，就必須要有對應的效能需求。但是現在這個專案只是剛開始，還沒有一些產品檔案，所以產品經理也給不出來效能需求。只能知道大概的產品方向，以及大概的功能模組有哪些，所以在這個時候，只能靠架構師和產品經理在一起進行溝通。
由於做的類似於一個電商APP，是前後端分離的專案，所以市場上有很多競品可以拿來分析，於是就我就主持召開了一個會議，會議主題：「如何落低效能測試」，參會人員：產品經理，專案經理，研發架構師、還有研發組長。但是在這個會議的進行過程中，發現大家並不是很願意討論效能測試，而是比較熱衷於產品需求和對應的效能需求，因為沒有產品需求和效能需求的話，就談不到效能測試這一步。
這裡再補充一點：其實我們平時在專案裡面做效能測試的話，也就有三種情況會做效能測試：
1，就是我們要對當前的系統做一個摸底，也就是系統效能兜底，看一下當前的系統能夠容納多少並行。
2，就是提出來具體的效能需求，比如我要實現3000人同時做什麼什麼事情，滿足1000並行，系統響應不超過2秒......
3，就是當系統出現效能問題了，我們需要進行效能排查和效能測試。
因為這是一個新專案，所以暫時就不會出現效能問題，主要還是要有效能需求才能夠的效能測試，但是這個效能需求沒有人能夠給出，產品經理給不出來，專案經理也給不出來，研發更給不出來。所以在這個時候，我們的重點是討論效能需求，在會議討論過程中發現，我們目前評估競爭產品，也就是競品分析，發現競品類APP需要至少滿足1000TPS，系統響應不超過2秒.......
綜合對比了幾款競品APP，發現：某一款競品APP在第一個版本要滿足 1000TPS的並行能力，但是現在這個1000TPS的並行能力應該如何設計，在這個時候就是另一個問題了，而且這個效能需求也是大家通過競品分析得來的，並不能算真正的效能需求，只能算暫時的一個偽需求。目前大家的會議討論的重點就是如何設計一個能夠滿足1000TPS的效能架構，等以後產品真正上線使用過程中再逐步調整優化需求！！！
在滿足1000TPS的效能架構的基礎之上完成的第一個測試版本，效能測試人員才能夠對系統進行測試，檢視系統到底能否達到1000的TPS，整個會議的目的都已經達到了，所以說，剩下的重點就是如何設計一套架構能夠滿足當前的1000TPS的業務。當然這個工作並不是一個測試人員來做的，也不是簡單的研發人員來做的，而是由系統架構師來做。
於是到最後，這個任務就交給了系統架構師，也就是Java架構師，當然測試架構師也要參與其中，但是目前的系統架構師一時間也給不出來具體的架構方案，因為，如果給出來1000TPS的架構方案，就必須在敲程式碼之前能夠設計出來一套具體的架構方案。
在敲程式碼之前，能夠評估能夠給出一套具體的架構方案，並且評估出該方案的吞吐量，TPS不小於1000，這個工作量只能由系統架構師來做，經過一段時間和系統架構師的溝通發現。這個事情只能憑架構師個人的經驗來設計了，各種框架、中介軟體設計、資料庫快取、微服務架構，表結構，負載均衡策略以及每個中介軟體能滿足多少並行。
這些都是要憑架構師的個人經驗了，畢竟還沒有敲程式碼，等整個架構設計好了之後才開始敲程式碼！在研發敲程式碼的時候，測試人員就可以設計開展效能測試相關的工作了！等整個效能測試環境搞定之後，我們就可以真正執行具體的效能測試了！那如果說，當效能環境都搞定了之後，程式碼也都完成的差不多了，資料也都造的差不多了，這個時候才開始評估效能方案都已經晚了，所以說一定要在敲程式碼之前就要評估出系統的吞吐量TPS。
當然這個對架構師的技術經驗要求都很高，一般人是做不好的，只有系統架構師才能做好，而且是經驗非常豐富的系統架構師也不一定能夠保證敲程式碼之前設計的這套方案就能夠滿足當時的效能評估，所以還是要等效能測試的時候看真正的結果。