「舊觀點」假設錯誤或疏失經常是人為惡意或無能造成的錯誤，常發生慣於咎責的文化中。
「新觀點」是理解 devops 運動的關鍵。此觀點鼓勵我們分享故事,因為任何的事情都是一次值得學習的機會。
名詞解釋:
模型(model)：是一種簡化。它是對現實的解釋:把與解決問題密切相關的方面抽象出來，而忽略無關的細節。領域(domain)所需的知識廣度可能令人望而生畏，龐大而複雜的資訊也可能超乎想象。模型正是解決此類資訊超載問題的工具。模型這種【知識形式】對知識進行了【選擇性的簡化】和【有意識的結構化】。
圖片來源：https://i1.kknews.cc/SIG=1sreuag/ctp-vzntr/86pp7r00r41o43pso28qr33847p0os34.jpg
重點摘要:
partI：
一、領域驅動的設計中，三個基本用途決定了模型的選擇；1.模型和設計的核心互相影響 2.模型是團隊所有成員使用的通用語言的中樞. 3.模型是濃縮的知識。
二、軟體的核心：軟體的核心是它為解決領域相關的問題的能力。所有其他特性，不管有多麼重要，都要服務於這個基本目的。
chapter 1:消化知識
一、模型透過不斷的與domain專家討論domain-knowhow後，產生不斷精化後模型的類別圖。
chapter 2:交流與語言的使用
一、討論以UML的類別圖及物件交互圖為主。但UML圖無法完整表達【模型所表示的概念】、【物件應該做那些事情】，這部份可以文字補充說明。圖是一種溝通的手段，精簡小圖效果最好。涵蓋整個物件模型的【綜合性大圖】反而失去了溝通或解釋的能力。所以我們應該使用【簡單】且【只包含物件模型重要概念】的圖。務必要記住模型不是圖 ，圖的目的是幫助表達和解釋模型。
二、書面設計文件（文件通用原則）
「全面性能測試方案」分成八個類別：
1
預期指標的效能測試：在需求分析設計階段，提出一些效能指標，完成和這些指標相關的測試是效能測試的首要工作之一。
2
獨立業務效能測試：指的是一些核心業務模組，通常具有功能比較複雜、且使用頻繁，屬於核心業務等特點。業務模組是效能測試的重點且加強測試核心業務模組，對平行處理使用者的回應情況。
2.1
平行處理測試區分為模擬一定數量使用者同時使用某一核心業務模組的「相同」或「不同」功能，並持續一段時間。
3
組合業務效能測試：模擬多位使用者的「相同」操作同一功能，加上同時模擬多位使用者操作「不同」的功能或多個模組的「不同」功能，綜合評估系統效能，此方式是最接近真實使用者的情境，通常按照使用的實際人數比例來模擬。
4
疲勞強度效能測試：指在系統穩執性的情況下，以一定的負載壓力來長時間執行系統測試。目的是確保長時間處理較大業務量時的效能。
5
大數據量效能測試：區分「三種」
5.1
一種是針對某些系統儲存、傳輸、統計查詢等業務進行大數據量的測試。
5.2
二種是在極限狀態下的資料測試，主要是指系統資料量逹到某種程度時，透過效能測試來評估系統回應狀況。
5.3
三種結合前兩種，主要測試在極限的狀態下，同時執行產生大量數據時的系統效能。
6
網路效能測試：主要為了準確顯現頻寛、延遲、負載和通訊埠的狀況及回應使用者的時間。
7
伺服器效能測試：分成初階及進階
7.1
初階：主要提指在業務系統工作或進行其它效能測試的時候，監控伺服器的一些計數器資訊，透過這些計數器資訊綜合分析，找出系統瓶頸。
7.2
進階：由專門的系統管理人員來進行，如DBA進行資料庫效能優化。
8
一些特殊測試：系統設定測試等等
「全面性能測試方案」主要分成四個部份內容。
一、效能測試策略制訂原則。
A.
軟體依照用途分成：系統類別軟體、應用類別軟體
B.
應用類別軟體分成：特殊應用類（保險、銀行、電信..等）、一般應用類（辦公自動化軟體）
|
軟體類別 使用者 重視程度 |
系統類別軟體 |
應用類別軟體 |
|
|
一般應用類 |
特殊應用類 |
||
|
高度重視 |
從設計階段開始就針對系統架構、資料庫設計等方面進行系統效能分析。 從單元測試階段即開始效能測試工作。 |
設計階段開始進行討論規劃工作，主要在系統測試階段開始進行效能測試實施。 |
從設計階段開始就針對系統架構、資料庫設計等方面進行系統效能分析。 從單元測試階段即開始效能測試工作。 |
|
中等重視 |
在系統測試階段的功能測試結束後開始進行效能測試實施。 |
||
|
一般重視 |
在系統測試階段的功能測試結束後開始進行效能測試實施。 |
||
|
不怎麼重視 |
可在軟體發佈前進行效能測試。 |
||
下表某銀行專案測試策略制訂案列
|
產品類型 |
信用卡審核業務系統，使用非常頻繁，業務量每年達到２００萬左右，屬於銀行領域的特殊應用軟體。 |
|
專案背景 |
系統屬於第二次重新開發，前一開發廠商在系統開發完成後沒有通過效能測試，１００個左右使用者平行處存取系統時資料庫伺服器當機，因此新的系統從專案開始，效能測試已成為使用者關注的焦點。 |
|
使用者要求 |
使用者提出效能方面首先要過關，否則功能再好也不會上線。 |
|
效能測試策略 |
從系統設計階段開始進行效能測試準備工作測試人員主要是參加系統的設計、評審。因為前一開發商失利的重要原因是資料庫設計不合理，所以重點討論了資料庫的設計。 系統設計階段，完成了效能測試方案的設計單元測試階段透過測試工具對一些重要模組的演算法進行測試，主要是一些平行處理控制演算法的效能問題，測試物件是一些核心業務模組。 整合測試階段進行組合模組的效能測試 整個系統測試階段都在進行效能測試，效能測試和功能測試同步進行。 對功能測試引起的一些相關修改，立刻進行效能測試 接受度測試階段時，在使用者現場的實際環境進行效能測試，根據測試結果對系統執行環境進行最佳化，達到較佳的執行效果。 |
二、測試場景設計通用模型。
A.
效能測試場景設計通常不會一次設計合格，而是一個反覆運算和不斷完整的過程，即使在使用過程中，也不是完全按照設計好的測試場景來執行，而是根據測試要素的變化調整和修改。而使用使用「測試場景設計通用模型」時，則和效能測試策略結合，對模型刪減或增加一定的內容使之符合特定的測試需求。在「測試場景設計通用模型」中，綜合了效能、強度、壓力、負載等多方面測試內容。
B.
預期效能指標測試：是一些十分明確的、在系統需求設計階段預先提出的期望系統效能指標。
下表為預定目標的測試場景設計範本
|
使用者案例編號 |
００１ |
|||
|
效能描述 |
對於普通的用戶端，系統上傳５ＭＢ以內的檔案，速度不能低於2MB/s |
|||
|
使用案例目的 |
測試系統上傳檔案的回應速度 |
|||
|
前提條件 |
測試機為I7 4core以上的條件 |
|||
|
特殊的程序說明 |
客戶端測試前處於空轉狀態,即沒有其他程式佔用系統資源 |
|||
|
使用案例間的相依關係 |
無 |
|||
|
步驟 |
輸入/動作 |
期望的效能(平均值) |
實際效能(平均值) |
回歸測試 |
|
1 |
選擇1MB左右檔案上傳，並用碼錶計時 |
上傳時間小於0.5s |
|
|
|
2 |
選擇3MB左右檔案上傳，並用碼錶計時 |
上傳時間小於1.5s |
|
|
|
3 |
選擇5MB左右檔案上傳，並用碼錶計時 |
上傳時間小於2.5s |
|
|
|
4 |
… |
… |
|
|
|
5 |
… |
… |
|
|
三、使用者平行處理效能測試
A.
使用者進行平行處理測試主要透過逐漸增加使用者數量排系統加壓，並透過測試工具對應用系統、各種伺服器資源進行監控，最.後透過其測試結果來分析系統性能。可區分「正常數量使用者」平行處理及「特殊數量使用者」進行平行處理。
B.
使用者平行處理測試是效能測試的核心，有關壓力測試、負載測試、強度測試等多方面的內容測試。又可區分為「獨立業務效能測試」和「組合業務效能測試」兩種。
C.
「獨立業務效能測試」實際上就是核心業務模組的某一業務的平行處理效能測試
D.
「組合業務效能測試」一個或多個模組的多個業務同時進行平行處理效能測試可視為整合效能測試．
E.
使用者平行處理測試要求選擇具有代表性的、關鍵的業務來設計測試場景，以便更有效的評測系統效能。
F.
設計場景時，可以把模組的功能劃分成更小的「交易」進行測試。
下表為核心模組的效能測試場景設計範本
|
功能 |
打線上使用者打到高峰時，發送和接收普通郵件正常。確保2000個以內的使用者可同時存取郵件系統，能夠正常發送和接收郵件 |
|||||
|
目的 |
測試系統有2000個以內的使用者同時上線，是否可正常發送郵件 |
|||||
|
方法 |
採用LoadRunner的錄製工具，錄製一個發送郵件的過程，可利用其完成測試，檢視資料庫伺服器和應用伺服器的效能。其中發送的郵件為普通郵件附件大小不能超過１０MB |
|||||
|
平行處理使用者數與交易執行情況 |
||||||
|
平行處理使用者數 |
交易平均回應時間 |
交易最大回應時間 |
平均每秒處理交易數 |
交易成功率 |
每秒點擊率 |
平均流量（bit/s） |
|
100 |
|
|
|
|
|
|
|
200 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平行處理使用者數與資料庫主機 |
||||||
|
平行處理使用者數 |
CPU使用率 |
Mem使用率 |
磁碟I/O參數 |
DB參數1 |
DB參數2 |
其他參數 |
|
100 |
|
|
|
|
|
|
|
…. |
|
|
|
|
|
|
|
150 |
|
|
|
|
|
|
|
200 |
|
|
|
|
|
|
|
平行處理使用者數與應用伺器的關係 |
||||||
|
平行處理使用者數 |
CPU使用率 |
Mem使用率 |
磁碟I/O參數 |
|||
|
100 |
|
|
|
|||
|
…. |
|
|
|
|||
|
200 |
|
|
|
|||
四、組合模組使用者平行處理效能測試場景設計
A.
「組合模組的效能測試」最能反映使用者真實使用情況的測試。也可稱為「整合效能測試」。
B.
「組合模組的效能測試」最重要的是模擬實際使用者的使用場景。
C.
使用者的使用場景，可用下列幾種方式取得。
i.
需求／設計文件。
ii.
現場調查。
iii.
透過系統來擷取資料。
D.
組合平行處理效能測試包含三方面的內容。
i.
具有耦合關係的核心模組，進行組合平行處理測試。
ii.
彼此獨立的、內部具有耦合關係的核心模組的平行處理測試。
iii.
以使用者場景為基礎的平行處理測試。
E.
大多數的效能問題都是由使用者經常使用的核心模組引起的。
下表為組合業務效能測試場景設計範本
|
功能 |
線上使用者達到高峰時，使用者可以正常使用系統，目標是滿足500個以內使用者同時線上使用系統 |
|||||||||||||
|
目的 |
測試系統500個以內的使用者同時線上時，是否可以使用比較常用的模組：公文系統、電子公告、線上討論區。 |
|||||||||||||
|
方法 |
採用LoadRunner的錄製工具錄製三個業務 業務1：在公文系統內，進行開啟、修改等操作 業務2：在電子公告系統內，檢視、發佈公告 業務3：在線上討論區系統內發佈文章，檢視文章 每個業務分配一定數目的使用者，利用LoadRunner來完成相關參數的測試 |
|||||||||||||
|
平行處理使用者數與交易執行情況 |
||||||||||||||
|
平行處理使用者數 |
交易平均回應時間 |
交易最大回應時間 |
平均每秒處理交易數 |
交易成功率 |
每秒點擊率 |
平均流量（bit/s） |
||||||||
|
業務１ |
業務２ |
業務３ |
業務１ |
業務２ |
業務３ |
業務１ |
業務２ |
業務３ |
業務１ |
業務２ |
業務３ |
|||
|
200 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
…. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
300 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
400 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
平行處理使用者數與資料庫主機 |
||||||||||||||
|
平行處理使用者數 |
CPU使用率 |
Mem使用率 |
磁碟I/O參數 |
DB參數1 |
DB參數2 |
其他參數 |
||||||||
|
100 |
|
|
|
|
|
|
||||||||
|
…. |
|
|
|
|
|
|
||||||||
|
150 |
|
|
|
|
|
|
||||||||
|
200 |
|
|
|
|
|
|
||||||||
|
平行處理使用者數與應用伺器的關係 |
||||||||||||||
|
平行處理使用者數 |
CPU使用率 |
Mem使用率 |
磁碟I/O參數 |
|||||||||||
|
100 |
|
|
|
|||||||||||
|
…. |
|
|
|
|||||||||||
|
200 |
|
|
|
|||||||||||
五、疲勞強度與大資料量測試
A.
目的是為了測試系統的穩定性與穩固性。其它的效能測試時間都不會很長，但疲勞強度的時間以「天」為單位。
B.
疲勞強度測試內容仍是以「核心模組群組使用平行處理」和「組合模組群組使用者平行處理」。
C.
大量資料測試主要是針對資料庫有特殊要求的系統進行的測試。
D.
大量資料測試分為三種
i.
即時大量資料：測試某些業務產生大量資料時，系統是否可穩定執行。
ii.
極限狀態下的測試：測試系統使用一段時間，累積一定資料量時，是否可以正常執行業務。
iii.
前面兩種的結合
E.
疲勞強度與大資料量測試是緊密相關的，因此在設計場景時可把兩種測試場結合起來設計。如設計執行２４小時的大數據量測試。
下表為疲勞強度測試場景設計範本
|
極限名稱 |
200個使用者同時使用系統的三個模組 |
|
|
前提條件 |
測試用的壓力機要有足夠的資源，否則用戶端當機失去測試意義。 |
|
|
執行時間 |
連續執行２４小時 |
|
|
測試方法 |
採用LoadRunner錄製三個工作，然後開始對系統做壓力測試 |
|
|
輸入／動作 |
使用者數量 |
|
|
工作１：進入郵件系統，進行發送、接收、刪除等操作 |
100 |
|
|
工作２：進入公告系統，檢視公告 |
50 |
|
|
工作３：檢視線上討論區，閱讀、發表文章 |
50 |
|
|
效能問題記錄 |
||
|
故障發生的時刻 |
故障描述 |
|
|
工作1：20時28分 |
郵件發送交易開始出現「網路逾時不能傳送」的現象 |
|
|
工作2：無故障 |
無 |
|
|
工作3：18時56分 |
閱讀發文交易逾時 |
|
下表為大數據量測試場景設計範本
|
功能 |
資料庫中的簡訊表可以儲存所有不能及時發送的簡訊，使用者上線後又能及時在發送已經儲存的資訊 |
|||||
|
目的 |
測試系統對大數據量業務的處理能力 |
|||||
|
方法 |
採用LoadRunner發送簡訊，後台動態控制使用者連線狀態的方式進行測試 |
|||||
|
平行處理使用者數與交易執行情況 |
||||||
|
輸入說明 |
交易平均回應時間 |
交易最大回應間 |
平均每秒處理交易數 |
交易成功率 |
每秒點擊率 |
平均流量（kbit/s） |
|
模擬8000使用者連不上線的情況:平行處理向資料庫輸入8000筆記錄 |
1.988 |
2.078 |
3980 |
100% |
無 |
236 |
|
模擬2000個使用者上線的情況:平行處理從資料庫中移除2000筆記錄 |
1.0009 |
2.068 |
5036 |
100% |
無 |
278 |
|
…………….. |
……. |
…… |
………. |
……… |
………. |
……. |
六、「全面性能測試方案」的設計原則
A.
制訂測試策略遵從低成本原則。
B.
策略為中心原則。
C.
適當修改原則：修改原則主要是針對性能場景設計而言，因為動態調整測試場景。
D.
增強方案原則：每個專案背景皆不同，故需動態調整測試模型及增強才能符合實際專案所需。
E.
方案具體化原則：指的是將測試方案實際運用到專案中。
七、效能測試的實施流程：分下列７個步驟，在一些「輕量級」的專案可以不必單獨寫效能測試計畫，因為在整個專案的測試計劃中已包含了效能測試。
1.
測試需求分析：在此階段測試負責人與專案關係人要定義清楚，使用者對效能測試的核心需求。並制訂「測試策略」及「測試範圍」。
2.
測試計劃制訂與評審：測試計劃包含測試內容與範圍、試試目標、方法、工具、測試策略說明、測試方案設計、測試實施排程、效能測試標準、測試環境部署、風險分析、人員需求與分工內容。測試計劃要通過評審才可生效。效能測試成本很高，故需訂定核心業務範圍來執行較具成本效益。
3.
測試案例設計與開發：主要包含測試場景的設計與測試指令範本的開發。「測試指令範本」開發主要指的是用測試工具錄製使用者操作，然後進行調整並參數化工作，工具有LoadRunner等，也可由測試人員撰寫測試程式。
4.
測試執行與監控：主要包含測試執行與過程的監控，為測試經理的主要責任，過程中測試經理通常依實際情況，進行測試情境調整。
5.
分析測試結果：主要根據前一步驟的測試資料來分析測試結果，為最佳化和調整系統提供依據。分析物件包含應用程式、AP Server、DB Server、OS及相關硬體資源。
6.
撰寫測試報告：測試報告內容主要包含測試過程記錄、測試分析結果和系統調整建議。
7.
測試經驗總結：總結歸納當次測試工作的經驗（包含好的與不好的經驗），供下次測試工作參考。
八、效能測試常見問題 一、專案開發延誤常會省掉效能測試
二、系統bug較多時會投入較多資源做功能測試而忽略效能測試。三、效能測試拖到最後會來不及修改，如果是系統架構設計方面的問題，嚴重時會導致整個重新開發。
九、效能測試à使用者平行處理測試範例
|
功能 |
系統支援多個使用者同時進行登入郵件系統操作 |
|||
|
目的 |
測試多使用者存取郵件模組時系統的處理能力 |
|||
|
方法 |
模擬多個使用者在不同用戶端登入郵件，然後進行平行處理進入郵件系統的操作。 |
|||
|
平行處理使用者數與交易執行情況 |
||||
|
平行處理使用者數 |
交易平均回應時間 |
交易最大回應時間 |
交易成功率 |
平均流量(bit/s) |
|
100 |
|
|
|
|
|
200 |
|
|
|
|
|
300 |
|
|
|
|
|
備註 |
1.
按照最大使用者的20%作為上限，然後每組之間每次增加1~1.5倍來設計平行測試使用者的數量。 2.
平行使用者的最大數量，一般不會超過最大使用者的20%。 3.
平行測試場景，可依業務場景不同分開設計模擬。 |
|||
