賦能，顧名思義是指賦予某項能力或能量，對於本次服務端效能測試技術賦能來說，旨在增強研發人員對於效能的意識及主觀能動性，提高**質量，提高研發效能。
在日常工作中我們發現了如下問題：
1、效能成為盲點：有些同事並不清楚效能測試的工作內容是什麼，以及效能測試意義
2、遺漏效能問題：有些同事不清楚怎樣的系統表現或處理結果表示出現了效能問題，遇到時可能會直接忽視
3、遺漏效能需求：有些同事不確定哪些新需求需要提前進行效能測試，可能會導致上線後暴露效能問題
4、效能問題型別集中：很多效能缺陷屬於同一類程式設計方式造成的，甚至是相當明顯的問題引起（比如迴圈呼叫、執行緒池寫死或設定過小、limit設定過大），導致整個研發進度低效。
低效的原因分析：木桶效應，乙個系統能提供多大的效能，取決於最短的那塊板。所以效能測試有個特點是，解決了乙個效能問題後，可能才會暴露出另乙個問題。
常見流程是：提出效能需求->壓測執行->發現效能問題->開發優化->功能驗證->效能回歸->發現效能問題->開發優化->功能驗證->效能回歸->……
如果存在多個低階問題，這個流程需要經過多次迭代才能結束，效率極低。
那麼為什麼不從編碼階段開始規避這些顯而易見的問題呢？
5、人力有限：效能組目前面向多個產品，新需求、系統重構、技術優化每天都在進行，誰都不能保證沒有遺漏的效能風險。
從根本上提高產品質量才是最可靠的方法。
1、提高全員效能意識，從架構設計、編碼階段開始控制系統效能及穩定性風險，提高主觀能動性（有意識地自覺地想問題、辦事情）、提高效能。
2、提高產品質量，避免因效能意識不夠或效能測試點的遺漏引起的線上問題。每年都是新人一茬又一茬，培訓不到位，問題也會是一茬又一茬。
3、提公升專案組成員個人能力，學到了就是你的。
1、專案組成員了解效能測試的意義、工作模式及工作內容
2、專案組成員了解哪些編碼方式對效能、穩定性造成影響
3、專案組成員了解如何用更簡單的方式發起併發壓力、進行故障演練、分析簡單的效能問題等。
也許日常工作中不會經常用到，但是當你需要用的時候，至少能夠知道怎麼做。比如：
出現過這種情況：某個效能問題回歸時發現因為缺少**配置或未提交成功導致優化未生效。那麼功能提測前有開發自測，效能問題回歸前為什麼沒有？
核心是注重專案組的實際痛點。--討論點：了解各位大佬對於效能工作的關注點、盲點及疑問。
宗旨是化繁為簡、突出重點、能夠讓新人快速上手。
1）效能基礎知識宣講
效能基礎概念、流程規範、指標評估標準、當前產品的效能覆蓋情況
2）工具類宣講
壓力發起工具，監控工具，分析工具
3）方**宣講
介紹常見效能問題的分析方法
1、研發流程中增加研發效能自測
2、新人入職培訓（新人大禮包，本文不展開）
提測打回率、bug數及bug質量環比
規範方**
自動化工具及平台
關於CMM在專案中的實施
關於 cmm在專案中的實施 隨著cmm 理念的引入，國內軟體公司激起了實施 cmm的熱潮。雖然 cmm的主要思想很清楚，標準的條例也很明確，但如何達到這種標準的可操作性比較差。在缺乏基礎和經驗的情況下，許多企業在實施 cmm的過程中，往往感到迷茫，不知從何處下手。而 cmm實施的難點在專案的具體實施...
專案管理在LIMS系統實施中的應用
為了讓大家更詳細地了解lims，一起來看下專案管理在lims系統實施中的應用吧。隨著社會的發展，科技的進步，計算機的應用在社會各領域中都得到了普及，越來越多的人都感受到利用計算機進行各類管理的科學和便捷，認識到資訊管理系統對於管理工作的重要性。21世紀是資訊時代，最具發展潛力行業當屬資訊管理。乙個具...
傳統金融專案實施中關於敏捷開發的思考
本人就職的是乙個三線城市金融軟體外包的小公司，主要在做專案管理，因為服務行業的特殊性和公司技術水平，目前專案開發實施中仍然按照傳統瀑布和快速模型開發模式，對於敏捷開發和devops屬於只聞其名。但最近接觸到一些專案招標檔案中，要求系統建設全生命週期應滿足敏捷及devops的要求。且最新接觸的一些專案...