測試的發展方向是什麼？效能對系統的架構和系統的選型起到多少的關鍵性」。
我當時隨性而發，也沒做過多的思考，大致寫了三個看法：
今天回想起來，覺得對這個話題還是需要補充一些。我從06年開始從事效能工程的工作，當時公司也沒有專門從事效能工作的團隊，所以我們團隊成立之初叫pel——performance engineering lab，是乙個實驗室，效能應該怎麼做，能夠怎麼做？去嘗試一下吧。經過1年多的摸索，大家八仙過海，各自研究。但最終基本上形成了效能模型研究學術派和效能測試調優實踐派兩大陣營，後來由於效能測試調優立竿見影，療效確切，慢慢便成為效能工程小組的主要手段。但是通過研究，大家對於系統效能有了更加全面的認識，也了解了什麼是排隊網路，什麼是馬爾科夫鏈。
確定了效能工程團隊的工作模式，團隊名稱變成了：peg——performance engineering group。團隊的組織架構則是放在架構部門，此時的架構組主要研究soa、系統安全和系統效能。效能小組應該算最接地氣，做了很多效能測試/優化專案。隨著名氣越來越大，工作也越來越多，最後沒有辦法支援，於是就有了矛盾，有了扯皮，有了責任不清。但是也沒有辦法通過加人來解決這個矛盾：一是因為效能測試/調優需要有非常紮實的技術功底，沒有這麼多這樣的人；二是專案增長的速度肯定是快於人員的擴張和培養的。怎麼辦？於是大家開始把知識工具化、流程化，給你個方便的eclipse外掛程式，開發自己去測效能吧；流程上更加重視效能評估，有所為有所不為；培養效能專家組，參與架構評審，**審查，把效能做到研發流程的前面。讓大家都知道，效能是軟體的乙個必備屬性，好的效能不是測出來的，是做出來的。
這樣做了有風險，也有挑戰，對於效能專家組的成員，必須足夠資深和有效能方面的經驗。必須要從流程、方法和工具層面給予充足的支援和專注；但是能力和經驗從何而來？必須是做專案做出來的，寫**寫出來的，作業系統、網路分析裡面折騰出來的。所以我們的技能發展通道就不能侷限在開發團隊，測試團隊這樣的單個團隊裡面。風險在於如果這種模式沒有很好的流程支援，團隊之間的良好協作就很容易形成割裂，最終回歸系統效能靠某個或者某幾個牛人的狀態。效能專家組日趨落寞，趨向於無。
所以我對於效能測試發展會有去測試化的想法。效能本事自家事，奈何更名瓦上霜。對自己的架構負責，對自己的設計負責，對自己的**負責，請從效能測試開始。很慶幸的看到，在**的效能自動化平台上，越來越多的開發、dba乃至架構師經常通過測試來驗證自己的設計、**，進行調優迭代。這又回歸驗證了效能是做出來而不是測出來的論點。當然針對這種工作模式，我們更需要從效能測試流程、平台和工具上去做好支撐。質量部門則更應從專案、流程和產出上面去把控整體的研發質量。
再談效能測試的發展方向
(出處: 門道測試論壇)
再談軟體測試人員的發展方向
大概在五年前，我寫了一篇部落格，題目叫 軟體測試員 你的路在這裡！大概論述了軟體測試人員發展的幾個方向。如果你不想轉開發，轉管理，轉產品，或自己創業買煎餅果子的話。那麼說明你是對測試是真愛。測試需要掌握的測試技術太寬泛了，所以，我們必須要選擇乙個方向。五年過去了，我想再試著寫寫對這幾個方向的認識。自...
效能測試高階發展方向
業界認為效能測試role劃分為 效能測試 工程師 偏重編寫效能測試指令碼 效能測試執行 和效能測試分析師 偏重效能分析 系統調優,也需要更加廣 深 的知識。根據個人的理解，效能測試高階 發展有如下一些方向 效能調優，架構評估，效能監控 容量規劃 應用效能管理 效能調優偏重系統級調優 級調優，需要非常...
軟體測試發展方向
檢視 127 評分 1 0 從 測試工程師的職業發展來看這個問題。一般來講，測試工程師的發展方向無外乎以下幾個方面，而每個方向的要求是不一樣的，談論測試人員的技術要求，我們也需要根據個人的職業規劃和公司的發展來看這個問題。級測試工程師 剛入門擁有電腦科學學位的個人或具有一些手工測試經驗的個人。開發測...