常見性能測試場景概述

性能測試通常不會覆寫所有業務場景，我們會選取一組具有代表性的場景，通過它來評估整個系統的性能狀況，場景的選擇将直接影響到性能測試的效果。常見的需要我們重點關注的場景有如下。、

1. 高頻發生的場景。
2. 關鍵的業務場景，例如與交易和支付功能相關的場景。
3. 資源高消耗的場景，包括CPU、記憶體、磁盤I/O、網絡帶寬等資源。要想進一步判斷哪些代碼會産生資源消耗，需要從開發工程師那兒了解代碼的實作方式。
4. 出現過問題的場景，要定期回歸測試這類場景，把性能測試腳本加入持續內建平台定時執行。

除了這些之外，還要根據故事卡的不同實作方式來确定測試場景，重點關注如下性能問題。

1. 慢SQL：原因比較多，例如用多個條件對一個表做查詢，沒有将傳回資料集少的條件放在前面；SQL語句中使用字段類型轉換、函數操作，沒有用到索引；單個事務操作的資料集過大等。
2. 跨表查詢慢：需要使用索引，一般來說，單表或兩張表的關聯查詢不會慢，但如果涉及更多表，例如6～7個，即使使用索引，仍會出現查詢慢的情況。

1. 資料庫鎖：盡量減少鎖的範圍，減少鎖定資源的數量和時間長度。如果鎖使用不合理，可能出現并發通路時的等待，引起性能問題。
2. 資料庫連接配接池：為了提高通路資料庫的性能，通常在程式中使用資料庫連接配接池，預先初始化一定數量的資料庫連接配接，并設定允許的最大連接配接數。當所有連接配接都處于使用中的狀态時，就會出現排隊等待釋放連接配接的場景。

1. 線程池：原理、性能問題和資料庫連接配接池類似，測試方法也相似，主要驗證線程池能否滿足業務需要的吞吐量。
2. 緩存：測試與緩存相關的性能場景時，要關注測試資料的多樣性，可以使用腳本批量生成測試資料，也可以使用脫敏後的産品資料。驗證擊中緩存和直接從資料庫讀取（緩存中找不到資料時會直接到資料庫查詢）的性能。由于緩存占用記憶體較大，可能會頻繁引發虛拟機的記憶體垃圾回收，導緻系統性能下降。測試時可以在緩存中加載大量資料，并長時間通路緩存，監控記憶體垃圾回收的頻率。
3. 第三方服務：第三方服務性能的好與壞通常不受測試人員控制，與第三方服務內建時，測試工作主要集中在自己的代碼上。可以Mock第三方服務做性能測試，測試之前需要和開發人員讨論，了解業務處理代碼中比較耗時的部分，這些場景就是測試重點。若處理第三方資料的代碼比較耗時，則需要在Mock中構造特定的傳回資料做驗證。
4. 資料傳輸速度：在内網部署的應用中，較少出現傳輸相關性能問題，而當跨機房調用時易出現性能瓶頸。驗證過跨兩個雲遷移資料庫的性能場景，在兩個雲上各自業務的處理速度都較快，但雲與雲之間的公網傳輸速度慢，導緻并發的遷移線程數無法提升。
5. 代碼的邏輯和算法：對測試工程師來說代碼的實作通常是一個黑盒，但其中很多代碼問題都可能造成性能缺陷。例如對同一個功能，在實作方式上，開發人員可以選擇性能好但線程不安全的類，也可以選擇線程安全但性能不好的類；程式中可能有不合适的排序算法，或者其循環内有過多不必要的對象。此外代碼中線程同步的範圍、集合類對象初始大小等設定也會造成性能隐患。為了發現代碼導緻的性能問題，在測試過程中測試人員需要同時提高線程數和測試資料量，一些代碼會因為測試資料量的增加而變慢，例如排序算法的代碼。