通過嚴格的實踐來增強系統的性能和可恢復性，并對這些方面進行持續的測驗，是預先找到問題的好方法，與測驗的其他方面一樣，性能實踐的質量要比數量重要得多，這里有七個簡單的技巧可以幫助你在測驗系統的性能和可恢復性時更高效，
軟體的性能和可恢復性是用戶體驗的關鍵組成部分，但是隨著軟體行業對開發運維一體化（DevOps）模式的接納，它開始在性能和可恢復性方面表現出不足，
在軟體完全失敗之前，性能問題常常被忽略，
然而，我們都知道，性能不會突然下降，由于軟體是通過迭代發布的，每次添加更多代碼時都要付出性能成本，添加的邏輯回圈也可能導致故障，從而影響到整個系統的穩定性，
嚴重的性能或軟體可用性問題幾乎不可能是單個代碼的更改造成的，相反，它通常是問題一點點積累而導致的，
通過嚴格的實踐來增強性能和可恢復性，并對這些方面進行持續測驗，都是預先找到問題的好方法，與測驗的其他方面一樣，性能實踐的質量比正在執行的測驗數量要重要得多，
下面有七個簡單的技巧可以幫助你在測驗系統的性能和可恢復性時更高效，
使用基準 每次只更改一個變數
在性能和可恢復性工程中，基準是為了把問題標準化，作為定量或對比的基礎測驗，我們定義了這樣的測驗，以便可以將它們相互比較，
為了進行比較，我們更改了一個元素，并根據另一個測驗度量該更改的影響，
在我們持續集成程序中，對新版本的軟體進行基準測驗，以衡量代碼變化如何影響軟體的性能和可恢復性，
在其他一些基準測驗中，我們希望測驗軟體在不同規格的硬體上的性能，由于我們還支持多種架構、平臺、作業系統、資料庫和檔案系統，我們希望不僅能夠定義如何獲得最佳性能和可靠性，還希望能夠將它們相互比較，
這些都是有效的基準實踐，因為我們更改了一個元素并度量了該更改的影響，
然而，如果我們同時改變測驗中的軟體版本和測驗的硬體，然后嘗試比較結果，我們就無法確定變化是由于其中一種變化引起的，還是兩者的結合導致的，通常情況下，這些組合元素的更改會產生與單獨更改一個元素不同的效果，
在性能工程中，盡量進行同向比較，使用基準測驗，并在要比較的測驗的多個版本中一次只更改一個變數，
監控記憶體、cpu、磁盤和網路 的使用情況
由于性能和可恢復性是一項科學作業，只有設法客觀地解釋我們所觀察到的事件是可重現的，才能做到這一點，這意味著我們需要測量，
對于性能工程，我們不僅必須評估我們正在測驗的軟體，還必須評估我們正在測驗的硬體，監控記憶體、CPU、磁盤和網路使用情況是我們分析的關鍵，我們還必須了解這些資源是如何分配的，因為它和我們的處理需求相關，
在資訊科技發展的今天，我們總是需要點對點的傳輸資料，并對其進行轉換，
在此程序中，我們添加了冗余；其中一些冗余是浪費或開銷，而有些則是必要的，因為它允許我們確保資料的完整性和安全性，
性能工程的全部內容是消除開銷和增加資料完整性，
每次測驗至少運行三次
在比較測驗結果之前，我們需要確保要比較的數字是可信的，
每次我們運行一個測驗時，我們都希望，如果我們在相同的條件下，在不同的時間運行相同的測驗，我們應該得到相同的結果和度量，
但是，當我們第一次運行測驗時，在新的條件下，我們沒有這種測驗的歷史來決定我們所得到的結果是否可重復，
請記住，在某個組件不同的以前的測驗中，不能考慮結果的可重復性，只有多次執行相同的測驗才能使我們對結果獲得信心，
可以信任的結果是一個關鍵因素，所以我建議您不要考慮測驗的結果來進行性能比較，除非您至少執行了該測驗3次、5次甚至更多，對于向客戶發布的版本或通用的可用性版本，還需要更多次的執行，
實作3%以下的結果差異
關于結果這個話題，我們必須證明，同樣的測驗是可重復的，在不同的時間執行也應該產生相同的結果，
這方面的一個關鍵指標是主度量的方差(也稱為可變性)，方差是一種度量，它表示同一測驗的最佳執行和最差執行的百分比差異，
讓我們考慮一個性能測驗，其中主要的度量是事務中的吞吐量度量，如果測驗的執行吞吐量最差為每秒一百個事務，最佳執行吞吐量為每秒一百一十個事務，則我們的方差為10%：
(較大值-較低值)/較低值 (110 – 100) / 100 = 0.1
同樣，對于可恢復性測驗，主要的度量是以秒為單位的恢復時間，如果我們有一個最壞的恢復時間為5分鐘，最好的恢復時間為4分鐘，我們的方差將為25%，
方差是衡量我們的結果是否可信的關鍵指標，方差小于3%意味著我們的結果是可靠的，
3%到5%之間的差異意味著結果是可接受的和可重復的，但在測驗中的測驗、環境或軟體的穩定性方面仍有改進的余地，
6%到10%之間的差異意味著我們不能重復我們的結果，應該積極研究為什么我們有如此高的差異，任何方差大于10%的測驗根本都不能用它來衡量性能，
至少運行半個小時的負載測驗
負載測驗的目的往往是衡量一個系統的特定資源的能力，目標是得到系統在短時間內沒有失敗情況的最大負載力，為了使這些測驗的度量是基于實際的，在我看來，所測量的性能必須至少持續30分鐘，
考慮一下，您通過15分鐘的負載測驗所證明的唯一一件事是，系統可以處理15分鐘的負載，此外，運行時間越短，受人為方差的影響就越大，
在性能工程中，我們還需要熱身期，因為第一次執行，在第一次呼叫時總是比較慢，即使在熱身系統中，測驗的前幾個事務也可能比較慢，并且在多次運行之間不一定相同–因此產生了人為的差異，在30分鐘或更長時間的測驗中，這些測驗將不會顯示，也不太可能導致差異，
如果負載測驗持續時間小于30分鐘，從性能工程的角度來看，其結果將沒有多大意義，不包括任何熱身期，測驗應執行至少半小時，
證明你的負載結果 至少可以持續兩個小時
再次，我建議至少半個小時，正如在前一點中所解釋的，您通過30分鐘的負載測驗所證明的唯一一件事是，系統可以承受30分鐘的負載，
雖然30分鐘足夠檢測大多數新的性能變化，但為了使這些測驗是合理的，還必須能夠證明它們可以在同一負載下至少運行兩個小時，
由于空間不足，高峰負荷應該是可持續的，證明負載可以運行兩個小時是一個很好的第一步，我建議把6小時、12小時和24小時作為里程碑，并在可能的情況下，證明你可以連續5天運行這些負載，
請注意，這些耐久負荷測驗是為了證明負荷結果的可持續性，它們不需要針對每一個代碼更改運行，而只是為了證明負載數的可持續性，
首先要證明兩個小時是可持續的，任何少于兩小時的性能測驗和性能值都不應用于性能發布，也不應用于容量方面的參考，
確保你有良好的自動化能力
如果沒有良好的自動化，您就不可能擁有成功的性能工程，您是否花了更多的時間來分析您的測驗結果(良好的自動化)，還是執行測驗并對現有的自動化(糟糕的自動化)進行更改？
如果您認為可以改進自動化實踐，請從以下七個原則開始：
1.知道你為什么要自動化
2.了解自動化的步驟
3.不要只考慮容易實作或不容易實作
4.構建可以堆疊在一起的塊
5.及早做自動化計劃
6.將您的自動化場景化
7.從自動化中收集度量標準
設計你的測驗 以獲得有意義的結果
解決軟體性能和可恢復性的最有效方法是通過有效的測驗，但是，重新考慮和組織測驗并不十分復雜，遵循這七個簡單的技巧會在早期發現很多性能問題——在它們成為真正的問題之前，
技術行業要不斷地學習，學習肯定不要孤軍奮戰，最好是能抱團取暖，相互成就一起成長，群眾效應的效果是非常強大的，大家一起學習，一起打卡，會更有學習動力，也更能堅持下去，你可以加入我們的測驗技術交流扣扣群：914172719（里面有各種軟體測驗資源和技術討論）
送給大家一句話，共勉：當我們能力不足的時候，首先要做的是內修！當我們能力足夠強大的時候，就可以外尋了！
最后也為大家準備了一份配套的學習資源，你能在 公眾號：【傷心的辣條】免費獲取一份216頁軟體測驗工程師面試寶典檔案資料，以及相對應的視頻學習教程免費分享！，其中資料包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，
好文推薦
轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！
面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…
面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…
什么樣的人適合從事軟體測驗作業？
那個準點下班的人，比我先升職了…
測驗崗反復跳槽，跳著跳著就跳沒了…
包裝成1年作業經驗的測驗工程師，我給他的面試前的建議如下
“入職一年，那個被高薪挖來的自動化軟體測驗被勸退了，”
4個月自學軟體測驗面進阿里！如何從功能測驗轉成自動化…我經歷了什么
6000元報了培訓班，3個月后我成功“騙”進了騰訊大廠，月薪15000
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/389084.html
標籤：其他