我們的產品在性能方面贏得了不好的聲譽。那麼，這是一個13歲的大企業應用程序，需要提供點心，特別是其性能的提升。爲開發者性能測試搭建實驗室
我們決定在本版本中戰略性地解決性能問題。我們正在評估如何做到這一點的幾個選項。
我們確實有一位經驗豐富的負載測試工程師配備了市場上最好的工具，但通常他們在版本開發生命週期的後期獲得穩定版本，因此在最新版本中開發人員沒有足夠的時間來修復他們的所有發現。 （是的，我知道我們需要提供一個穩定的版本，我們也在研究這個過程，但它不在我的區域）
我推動的一個方向是設置一個實驗室環境，每晚構建，以便開發人員可以測試其代碼的性能影響。 我希望通過模擬真實用戶體驗的腳本不斷加載這個環境。在這個加載的環境中，每個開發人員都必須編寫測試其代碼的特定腳本（即在真實世界環境中的單一用戶體驗）。我想生成一份報告，顯示每個迭代對現有功能的影響，以及新功能的性能。
我有點擔心，我的目標太高了，它就會變成變得過於複雜。
您對這樣的想法有什麼看法？ 有沒有人有設立這樣的環境的經驗？ 你能分享你的經驗嗎？
這聽起來像一個好主意，但在所有誠實，如果組織不能得到積累到昂貴的負載測試團隊已經使用只是爲了這個目的，那麼它會不會把你的想法工作。
先去低垂的果實。在此過程的早期獲取性能測試團隊的夜間構建。
事實上，如果這個版本是所有關於性能，爲什麼沒有球隊只是把這個版本以解決所有來晚在迭代的最後一個版本的性能問題。
編輯：「不要開發商有責任性能測試代碼」是一個註釋。是的。我個人會希望每個開發人員都有一份YourKit java profiler（它便宜且有效）並知道如何使用它。然而，不幸的是，性能調整是一項非常有趣的技術活動，如果您希望更好地開發功能，可以花費大量時間做這件事。
如果你的開發團隊反覆對性能或更好的程序員開發明顯減慢代碼，然後教育是唯一的答案，而不是更昂貴的過程。
我們構建了一個小測試平臺，用來做理智測試 - 也就是說，當按鈕被按下，驗證工作等時，應用程序啓動並按預期工作。我們是一個Web應用程序，我們使用基於ruby的Watir工具包來驅動瀏覽器。這些運行的輸出創建爲Xml文檔，我們的CI工具（巡航控制）可以輸出結果，錯誤和性能作爲每個生成日誌的一部分。整個事情運行良好，可以擴展到多臺PC進行適當的負載測試。
但是，我們所做的一切都是因爲我們的身體比工具多。有一些大的壓力測試終端可以滿足您的所有需求。它們的成本，但這將比手工滾動的時間少。我們遇到的另一個問題是讓我們的開發人員編寫Ruby/Watir測試，最終落到一個人身上，測試工作幾乎是一個瓶頸。
每晚構建都非常出色，實驗室環境非常好，但是您可能會因爲我認爲直接進行錯誤測試而陷入混亂的性能測試。
確保您的實驗室條件是隔離且穩定的（即，一次只能改變一個因素，無論這是您的應用程序還是Windows更新），並且硬件反映了您的目標。請記住，您的基準比較只能在實驗室內部進行防禦。
編寫代碼的開發人員編寫的測試腳本往往是一件有毒的事情。它不會幫助你消除實施時的誤解（因爲在測試腳本中會出現同樣的誤解），並且實際發現問題的動機有限。更好的做法是採用TDD方法，並首先將測試作爲一個組（或一個單獨的組）進行編寫，但如果通過協作編寫腳本仍然可以改進此過程，那麼就會失敗。希望您在設計階段可以看到一些用戶故事，並且可能會重播日誌以體驗真實世界（應用程序不盡相同）。
生產力的最大提升之一是自動生成系統，該系統在一夜之間運行（這稱爲持續集成）。今天早上發生的錯誤今天清晨，當我還清新，當我仍然記得我昨天做了什麼（而不是幾個星期/幾個月後）。
所以我建議先做這件事，因爲它是其他任何事情的基礎。如果你無法可靠地建立你的產品，你會發現很難穩定開發過程。
完成此操作後，您將擁有創建性能測試所需的全部知識。
儘管有一條建議：不要試圖一次性完成所有的事情。一步一個腳印，一個接一個地修復一個問題。如果有人提出「我們也必須這樣做」，那麼您必須按照其他功能要求進行相同的分類：這有多重要？有多危險？需要多久才能實施？我們將獲得多少？
推遲艱難但重要的任務，直到你已經理清基礎。
每晚構建是性能測試的正確方法。我建議你需要每晚自動運行的腳本。然後將結果記錄在數據庫中並提供定期報告。您真的需要兩種報告：
其他一些建議：
我同意，但是開發人員不對測試他們的代碼的性能負責任嗎？就像他們在提交任何其他代碼之前必須運行單元測試一樣。 – LiorH 2009-02-13 08:58:23