1.併發測試
最近小屌絲一直在埋頭苦練性能的知(zi)識(shi)~。
很是努力。
但是，小屌絲的最近遇到的問題，可是挺棘手的，
例如：
小屌絲：魚哥，你說這性能測試，是不是就是併發測試？
小魚： 性能測試和併發測試，是兩個概念，且併發測試不等同於性能測試。
小屌絲：魚哥，那你說，性能測試是不是包含併發測試？
小魚：吐血ing… 性能測試只是併發測試的一個小類而已
小屌絲：哦，那性能測試…
小魚：住嘴！！ 你別問，我慫~我給你詳細的講什麼是併發測試，以及從我實際的項目中 給你解析常見的併發問題！
小屌絲：挖草，這次賺大發了 ！
小屌絲：魚哥，請開始你的表演！！
1.1併發測試的定義
1.併發測試的定義中，最主要的有兩點
①點層面上的：
例如：週一早上7:30半，小學生要統一到操場升國旗。
>>即：同一時間做某件事
②線層面上的：
例如：中午11:30-13:00，小學生有的跳皮筋，有的踢足球，但同時對服務器產生壓力。
>>即：一個時間段做不同的事
2.併發測試不等於性能測試
這個問題，我面試的時候，問過多個求職者，大部分求職者的第一反應都是說併發測試就是性能測試！
性能測試中把併發又分爲負載和壓力測試。
雖然併發測試與性能測試有交集，但是，併發測試並不僅僅應用於性能測試。併發測試更多被運用於其他領域。
1.2併發測試的分類
併發測試不僅僅是性能測試，它存在各個測試階段，並且測試目的各不相同。
①功能併發測試：要先進性測試單業務功能場景的併發測試，在進行混合業務功能場景的併發測試。
>>功能併發測試目的爲驗證系統功能是否符合需求規格說明書的要求。
②性能併發測試：同時滿足某些系統性能指標的前提下，讓被測對象承擔不同的工作量，以評估被測對象的最大處理能力及是否存在缺陷。
>>性能併發測試的目的爲驗證系統性能指標是否符合需求規格說明書的要求
③穩定性的併發測試：判斷測試系統的長期穩定運行的能力。
>>穩定性併發測試目的爲驗證系統穩定性是否符合需求規格說明書的要求。
④異常性併發測試：模擬系統在較差、異常資源配置下運行，以評估被測對象在資源不足的情況下的工作狀態。
>>異常併發測試的目的爲驗證系統的異常響應機制是否滿足需求規格說明書的要求。
2.常見併發問題
當下流行一種時尚的軟件設計理念，叫"微服務"。
把複雜功能組合拆分成若干個獨立的服務進行開發，然後有選擇性的組合執行各服務。
微服務開發框架有利於併發測試設計，每個服務都是測試的切入口，可以單獨執行。換句話說，測試切入口越多，越有利於測試場景的設計，有效的執行併發用例。
併發切入口從以下三個方面查找統計：
①客戶端操作：使用工具捕獲提交到服務器的請求，分析鏈接、參數進行測試。
②系統接口：查閱相關的接口文檔，開發並模擬其他系統功能進行測試。
③定時任務：定時任務視開發框架，可能需要二次開發，以接口形式進行測試。
併發測出的問題，是一種綜合證，往往有多種錯誤交織在一起的，所以不能亂用"藥"。
解決這類問題，通常分以下5個步驟(比把大象放冰箱多了2步)：
①通過併發測試找到故障點；
②以鼓掌點的現象分析問題原因；
③確定產生原因後討論解決方案；
④根據解決方案實施修復；
⑤同併發測試炎症修復情況。
2.1事務併發的問題
由於事務處理而導致的併發問題，我們需要先了解什麼是事務。
事務的定義：是數據庫操作的最下單元，是作爲單個邏輯工作單元執行的一些列操作；這些操作作爲一個整體一起向系統提交，要麼執行，要麼不執行；事務是一組不可在分割的操作集合(工作邏輯單元)。
系統內部事務控制：事務的控制好壞往往取決於碼農們的開發技術、業務理解能力、專注程度，由於這類錯誤而導致的bug是非常低級別且嚴重的(必須出示黃牌 進行警告)！
我們舉例來說明
某一天，小屌絲接到白富美的邀約，說要去看"xx牌"電影，讓小屌絲幫忙訂個票。
挖草~~小屌絲雞凍的，趕緊掏出他的iphone4，打開某團，找到某電影，選擇位置，並點擊"確定選擇"，然後進入到支付頁面，提交訂單，選擇支付寶去支付，支付成功收到短信。
●我們來分享一下故事場景的上半部分：
小屌絲 用手機打開某團，找到白富美想看的電影，選擇了座位，提交訂單到支付頁面。
"選座"與"提交訂單"都是某團 內部接口。
如果將這兩個作爲一個事務，有以下四個特性：
①原子性：要麼都整，要麼都不整。
②一致性：鎖定座位提交訂單後必鬚生成訂單號，取消訂單則解鎖座位。
③隔離性：座位被別人選中，沒有網絡，操作日誌記錄失敗等。
④持續性：事務提交後永久存在，不會受到任何故障影響。
而作爲測試人員，需要考慮的測試點有：
①一個座位被多個賬號鎖定，生成了訂單；
②座位鎖定成功，但沒有生成訂單；
③取消訂單，座位未解鎖；
④生成重複訂單號；
⑤操作日誌沒有完整的記錄所有行爲。
●我們再來分析股市場景的下半部分：
小屌絲在支付頁面，使用了支付寶進行支付，支付成功後收到平臺短信。
"支付成功"是外部接口。對於外部接口的事務控制，需要考慮兩個系統的設計。
對支付接口進行併發接口測試，要考慮的事務問題：
①同一筆訂單，不能同時選擇多種方式，不能進行多次支付；
②重複通知上傳支付結果(支付成功，支付超時)，只能處理一次訂單。
③日誌記錄完整記錄發送、接受的支付信息，與測試用例內容相匹配。
2.2極限值併發的問題
由極限值而導致的併發問題，那麼，什麼又是極限值呢？
極限值：標準要求的數值範圍的界限，“極限值"也被稱爲"極限數值”、“臨界值”、“界限數值”。
我們舉例來說明
那是2020年的第一場雪，白富美要搞一個生日party，爲了活躍氣氛，白富美想搞一個抽獎環節，於是找到小屌絲，告訴小屌絲的具體安排，然後讓小屌絲去擼碼。
具體安排爲：當天23:00 ~ 23:59還在場的朋友，每人一個禮物(華爲P50 必須安排)，每個人另外有3次抽獎機會(挖草~ 這是炫父？？)，同時發朋友圈高調炫耀的，還能在獲得1次抽獎機會，已經抽到一等獎 的，不能再獲得二等獎和三等獎，中獎概率按照預估概率進行計算，如果已中獎數量達到上限，必須停止抽獎。
小屌絲根據白富美的需求，開發完代碼，進行併發測試。
小屌絲設計的併發測試場景：
①當天時間23:00 ~ 23:59，給在場每個人一份禮物；
②在場每個人有3次抽獎機會；
③高調發朋友圈，可以再來一次抽獎機會；
④已獲得一等獎的，不能在獲得二等獎和三等獎；
⑤中獎概率按預估概率進行設定；
⑥已中獎數量達到獎品數量上限，該獎項停止。
在這個場景中，先分析測試對象分別有：活動時間、抽獎次數、中獎概率、獎品數量上限、中獎規則。
小屌絲設計的併發測試用例覆蓋點爲：
①測試活動：不在活動時間範圍內，也能參與抽獎；
②抽獎次數：未分享朋友圈炫耀的，抽獎次數超過3次；
③抽獎次數：朋友圈高調炫耀的，抽獎次數超過1次；
④中獎概率：設置中獎概率有效的小數位數；
⑤簡化數量上限：獎項數量上限控制；
⑥中獎規則：已中一等獎，是否還能中二等獎、三等獎。
2.3壓力併發的問題
由壓力負載而導致的併發問題，可以歸類於性能問題。
關於性能的問題，我之前有寫過幾篇，如：
① 性能分析流程
②性能調優
③MySQL性能監控
如果有不太明白的或者懵懂的，可以直接翻閱這三篇文章。
但是今天我要在這裏說一些數據庫事務的隔離級別。
>>>隔離級別有4個，有低到高依次如下：
①Read uncommitted （未授權讀取、讀未提交）
如果一個事物已經開始寫數據，則另外一個事務不允許同時進行寫操作，但允許其他事務讀此行數據。該隔離級別可以通過"排他寫鎖"實現。
該隔離級別避免了更新丟失，卻可能出現髒讀。
>> 即事務B讀取到了事務A未提交的數據。
②Read comitted （授權讀取，讀提交）
讀取數據的事務允許其他事務繼續訪問該行數據，但是未提交的寫事務將會禁止其他事務訪問該行。
該隔離級別避免了髒讀，但是卻可能出現不可重複讀。
>> 即事務A先讀取了數據，事務B緊接着更新了數據，並提價了事務，而事務A再次讀取該數據時，數據已經發生了改變。
③Repeatable read（可重複讀取）
讀取數據的事務將會禁止寫事務，寫事務則禁止任何其他事務。
該隔離級別避免了不可重複讀取和髒讀，但是有時可能出現幻讀。這可以通過"共享讀鎖"和"排他寫鎖"實現。
④Serializable（序列化）
提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接着一個的執行，但不能併發執行。如果僅僅通過"行級鎖"是無法實現事務序列化的，必須通過其他機制保證新插入的數據不會被剛剛執行查詢操作的事務訪問到。
序列表是最高的事務隔離級別，同時代價也花費最高，性能最低，一般很少使用。在該級別下，事務都會乖乖的順序執行，不僅避免髒讀、不可重複讀，還避免了幻讀。
那麼，什麼是 髒讀、不可重複讀、幻讀，能不能解釋一下呢？
這難不倒小魚。
(1)髒讀
一個事物讀取到了另一個事務未提交的數據操作結果。
(2)更新丟失
更新丟失包含以下兩種情況：
①回滾丟失
>>當2個事務更新相同的數據源時，如果第一個事務被提交，而另外一個事務卻被撤銷，那麼會連同第一個事務所做的更新也被撤銷，即第一個事務做的更新丟失了。
②覆蓋丟失
>>當2個或多個事務查詢同樣的記錄然後個自己會最初的查詢結果更新該行時，會造成覆蓋丟失，因爲每個事物都不知道其他事務的存在，最後一個事務對記錄做的修改將會覆蓋其他事務對該記錄做的已提交的更新。
（3）不可重複讀(Non-repeatable Reads)
一個事務對同一行數據重複讀取2次，但是卻得到不同的結果，包括以下情況。
①虛讀：事務R1讀取某一數據後，事務R2對其做了修改，當事務R1再次都該數據時得到不同的值。
②幻讀：事務在操作過程中進行兩次查詢，第二次查詢的結果包含了第一次查詢中未出現的數據或者取消了第一次查詢中出現的數據(不要求兩次查詢的sql語句相同)。這是由在兩次查詢過程中由另外一個事務插入數據造成的。
通常的數據庫設置默認隔離級別爲Read committed（授權讀取、讀提交）。
2.4異常數據干擾併發的問題
對於這類情況的異常數據測試也可以稱之爲系統健壯性測試。
測試重點是，要根據業務邏輯或系統相關的配置情況構建能夠造成異常的測試數據，要求這些數據不能被當做正常數據處理，也不能影響其他正常數據(這挺難的)。
例如：
測試人員構建測試場景爲不斷觸發定時批處理任務，如果碼農在代碼中忽視對異常數據邏輯處理，就會造成數據庫連接池飽滿、內存溢出、遇到異常數據直接報錯中斷(待執行任務隊列越來越多)等問題。
此類併發測試關注點不是同步併發，而是逐步加壓的併發數量。
這個難點相對於前幾個問題，提升了一個level，
因爲這要求對測試人員瞭解系統架構配置及數據流邏輯，所以，這就需要測試的大佬們多多努力。爭取各個都是全棧！！
小魚：小屌絲，常見的併發問題總結的差不多了，
況且這都快一點了，我能不能先去喝杯咖啡？
小屌絲：魚哥，用我給你倒，嗎？
小魚：你能不能實在點？
小屌絲：不…能 …吧…
小屌絲：魚哥，聽說你早上四五點起牀，這晚上又十二點多還不睡，你這精神頭，也挺牛叉啊！
小魚：貧窮使我努力！！
小屌絲：魚哥，你開玩笑呢？
小屌絲：魚哥，你現在這狀態，似曾相識啊…
小魚：額…誰相識？？
小屌絲：馬爸爸…
小魚：額，小屌絲，你看，白富美微你了！
小屌絲：挖草~ ~ 拜拜，魚哥，我先忙了~ ~
小魚：…
