日期：2021年7月20日
Deb Cobb，企業產品經理
當涉及到應用程序測試時，許多項目經理和測試主管不會例行地進行性能和負載測試在早期開發生命周期。相反，他們在應用程序完成後，在應用功能測試的地方進行性能和負載測試。事實上，在許多組織中，性能測試通常是應用程序投入生產之前的最後一步——幾乎是事後的想法。
這種方法產生了一個經典問題:後期測試。每當測試人員發現問題時，開發人員必須修改長期完成的代碼來修複它們。這些代碼更改會影響應用程序的其他部分，從而導致中斷。事後解決問題既耗時又昂貴。此外，延遲發布新功能或新應用會直接影響收益、競爭地位、品牌和應用。
即使在運行敏捷開發過程的組織中，性能測試也可能不是以真正的敏捷方式進行的。延遲“最後衝刺”的性能測試作為預發布任務，將應用程序測試視為瀑布開發步驟，並承擔所有相關的成本和風險。這篇文章討論了如何通過將SLA提升到敏捷任務板，使負載測試成為定期的“早期和經常”的練習。
在DevOps的世界裏，後期測試是不可持續的
在今天的應用經濟中，組織必須優先考慮創收和用戶體驗，後期測試不再是一個可持續的策略。為了讓品牌在這個不斷發展和競爭激烈的市場中生存，他們需要平衡創建代碼的速度和質量與他們發布的代碼的速度和質量。
為了應對這些競爭壓力，許多組織已經實現了DevOps和敏捷以及類似敏捷的開發方法。因此，開發團隊正在以更快的速度創建更多的代碼——這些代碼需要以更快的速度進行徹底的測試。所有這些壓力混合在一起創造了更加敏捷的測試環境，測試人員通常擁有整個端到端測試過程，包括自動化、單元測試、回歸測試以及負載和性能測試。在這些環境中，測試人員必須跟上開發的速度，同時還要滿足對質量的高度期望。
為了確保測試工作的成功，QA團隊和性能測試人員越來越依賴sla，並將其包含在敏捷任務板中。
什麼是性能SLA?
服務水平協議(SLA)是服務提供商(內部或外部服務公司)與客戶之間的合同。SLA定義了服務提供者必須交付的服務級別，以確保令人滿意的客戶體驗，包括描述如何交付服務的各種屬性和定義性能的不同閾值。例如，一家外包其服務台操作的大公司可能要求所有收到的客戶支持電子郵件經過分類，從而在一小時內觸發接收確認電子郵件響應。該協議允許客戶建立其業務和品牌，知道所需的服務水平將根據操作規範執行。
定義sla
通過關注性能sla，測試團隊可以將性能和負載測試納入他們的持續集成(CI)過程中。性能測試人員應該考慮他們關於性能參數的sla，因為這是與最終用戶達成的隱式契約。sla因組織而異，但它們中的每一個都將描述應用程序必須滿足的特定基準或標準。從測試的角度來看，SLA詳細描述了可測量的需求，這些需求可以被測試並標記為“通過”或“失敗”，並且通常與係統可用性和響應時間相關。例如，SLA可能規定所有頁麵應在2秒內加載，或者搜索結果的第一頁應在4秒內顯示。雖然它們不是固定不變的契約，但sla確定了所需的性能基準。
當測試人員指定SLA項目在應用程序設計過程中，他們可以將它們轉化為敏捷任務板上的需求。這樣，開發人員在開發應用程序時就會考慮到性能，而不是事後再考慮。
SLA應該處理的性能指標
sla可以處理各種各樣的網站指標。性能測試人員的目標是生成預先指定的關鍵參數。當這一步在組織行為中根深蒂固時，開發人員可以在開發周期的開始為性能編寫代碼。
作為第一步，我們建議QA團隊在他們的性能sla中指定足夠的細節來支持自動冒煙測試。想想在煙霧測試中會發生什麼。構建完成後，將部署應用程序，並運行一係列測試以確保一切正常。一係列必要的測試之一可以像設置用戶和執行用戶登錄一樣簡單。向冒煙測試添加性能SLA可能需要在給定的時間範圍內完成登錄過程。
當團隊將這一需求添加到敏捷任務板時，他們突然之間就完成了一開始就自動化性能測試的發展過程。隨著更多應用程序的開發，性能測試人員可以添加更多與所創建的模塊和特性相關的需求。
盡管每個應用程序都有其關鍵的性能指標，但最好確定一組基本頁麵進行定期測試。這些頁麵可以包括主頁、購物車、聯係表單、搜索結果、聊天窗口等。團隊創建的sla應該定義一組指標的需求，例如:
- DNS解析時間
- 顯示
- Time-to-last-byte
- 係統正常運行時間
最後，確定每個SLA將處理的網絡類型(例如Wi-Fi、4G、5G)和平台、操作係統和瀏覽器的基本級別。多設備和變量組合可能令人望而生畏。為了減少開發人員的怨恨和不滿，請確保提供適用於大多數應用程序最終用戶的現實期望。這會讓每個人都開心!
負載和性能測試的頻率
一旦sla就位，團隊應該多久執行一次性能和負載測試?記住，在整個敏捷開發過程中，測試發生在不同的規模上。在許多敏捷組織中，自動構建過程包括一些測試，這些測試在構建編譯時執行。在這一點上，可能會有額外的測試發生在更徹底的基礎上，盡管不那麼頻繁。在許多情況下，隻要代碼簽入，測試腳本就會執行。
努力對齊自動化性能測試到開發過程階段。期望每次應用程序進行冒煙測試時都執行全負載測試是不合理的，但是一些簡單的東西可以匹配冒煙測試的範圍、意圖和周轉時間。這些更有限的測試將很好地適應已經發生的事情。如果QA團隊應用他們最好的判斷，並將sla與過程中的工作結合起來，那麼實現性能目標的機會就更大。
SLA:快速高效負載測試的商業秘密
每個應用程序都必須滿足最低性能sla。因為敏捷團隊被授權為應用程序添加更多的特性和功能，所以優化應用程序性能可能成為事後的想法。此外，用戶故事往往是從功能角度編寫的;他們很少指定應用程序性能需求。如果敏捷團隊想要以應有的嚴肅態度來考慮性能，那麼它就需要出現在敏捷任務板上的顯著位置。
將sla融入到敏捷任務板的創建中，可以促進開發人員和測試團隊之間的協作，並增強對實際應用程序性能的可見性。當QA團隊采用這種策略時，他們會體驗到一些好處。隨著他們的應用程序和過程的成熟，他們將在整個測試結構組合中擁有豐富的SLA需求庫。此外，他們將擁有一組自動化測試，這些測試可以在正確的測試構造中驗證那些sla:煙霧測試、全麵的自動化測試、單元測試等等。確保這些規模經濟將證明對性能測試人員是有價值的，因為他們競相跟上積極的開發和發布周期。最終，團隊能夠更快、更高效地測試代碼。
Deb Cobb的簡介LinkedIn
本博客最初於2018年10月發布，並於2021年7月更新。
日期：2021年7月20日
