初探異常測試副本

1、目錄異常測試21異常測試簡述22為什么要做異常測試23異常測試場景34異常測試場景抽象和設(shè)計(jì)方案44.1業(yè)務(wù)異常4業(yè)務(wù)流程4交互規(guī)范44.2外部異常64.1.1 獨(dú)立的服務(wù)不可用異常64.1.2 組合的服務(wù)部分不可用異常84.3網(wǎng)絡(luò)異常104.3.1 網(wǎng)絡(luò)超時(shí)104.3.2 網(wǎng)絡(luò)丟包114.3.3 網(wǎng)絡(luò)抖動134.3系統(tǒng)異常135異常測試在手機(jī)賬號項(xiàng)目中的實(shí)踐135.1 系統(tǒng)架構(gòu)135.2 用例設(shè)計(jì)145.3 測試方法156. 總結(jié)16異常測試1異常測試簡述軟件交付最終用戶使用之前，需要進(jìn)行各種類型的測試，其中就包括異常測試。異常測試，是檢測系統(tǒng)對異常情況的處理。異常測試覆蓋硬件或軟件異常時(shí)的

2、處理。測試方應(yīng)通過人為制造錯(cuò)誤情況測試系統(tǒng)對錯(cuò)誤操作、錯(cuò)誤報(bào)文的反應(yīng)，檢查程序中的屏幕或頁面是否給出了清晰且充分的提示或約束；一旦出現(xiàn)錯(cuò)誤情況，系統(tǒng)是否能正常報(bào)告，并檢查系統(tǒng)的錯(cuò)誤提示是否清晰且充分；測試系統(tǒng)是否處理了用戶的異常操作，還是造成死機(jī)或處理錯(cuò)誤。2為什么要做異常測試只有通過異常測試的軟件產(chǎn)品，才可以保證軟件在正式上線后長時(shí)間的保持良好的運(yùn)營狀態(tài)，給最終用戶以信心。異常測試的結(jié)果也有助于為我們進(jìn)一步的系統(tǒng)優(yōu)化設(shè)計(jì)積累經(jīng)驗(yàn)。3異常測試場景根據(jù)URS組內(nèi)的實(shí)踐，將之前調(diào)研的異常測試需求進(jìn)行一個(gè)分類并抽象成不同的場景，主要分為如下類1.業(yè)務(wù)異常，主要從業(yè)務(wù)操作或業(yè)務(wù)流程方面考慮，一般會涵蓋

3、在功能測試中的逆向測試；2.外部異常，一套完善的系統(tǒng)往往都有一些外部調(diào)用的服務(wù)，如依賴的DB，緩存，MQ，其他系統(tǒng)的接口等，在系統(tǒng)運(yùn)行時(shí)，如果調(diào)用的這些服務(wù)出現(xiàn)異常，系統(tǒng)會如何處理這種異常情況，也是需要關(guān)注的重點(diǎn)。3.網(wǎng)絡(luò)異常，非常常見的一種異常場景，測試過程中基本上不會發(fā)現(xiàn)，并且線上很容易出現(xiàn)此類有關(guān)的問題。4.系統(tǒng)異常，主要體現(xiàn)在系統(tǒng)健壯方面的能力，包含如內(nèi)存、磁盤、cpu、集群負(fù)載均衡等業(yè)務(wù)異常，基本上在URS項(xiàng)目中已經(jīng)在功能用例中做了體現(xiàn)，在此不多贅述。系統(tǒng)級異常，與部署在機(jī)器上的業(yè)務(wù)無關(guān)，也就是我們常說的體現(xiàn)在應(yīng)用性能上面的可靠性，這又包含兩方面內(nèi)容系統(tǒng)的高可用和高恢復(fù)，：（1） 當(dāng)

4、存在系統(tǒng)級的異常時(shí)，系統(tǒng)應(yīng)當(dāng)有其他的負(fù)載機(jī)器繼續(xù)接管服務(wù)，保證可用；（2） 負(fù)載機(jī)出現(xiàn)問題后的快速發(fā)現(xiàn)并恢復(fù)，無論是監(jiān)控系統(tǒng)，或是人為處理，這也是需要系統(tǒng)上線后應(yīng)有的保障體系URS系統(tǒng)主系統(tǒng)工程整套的集群體系以及監(jiān)控系統(tǒng)均已比較完備，所以針對這一塊的異常測試，在之前做過的情況下，后續(xù)便縮減了此處的測試。4異常測試場景抽象和設(shè)計(jì)方案4.1業(yè)務(wù)異常4.1.1業(yè)務(wù)流程業(yè)務(wù)需求是開發(fā)之源，也是測試之源。測試人員對業(yè)務(wù)需求的了解是非常非常重要的，針對于異常測試更是如此。異常測試就必須要熟悉所測軟件的業(yè)務(wù)流程、相關(guān)業(yè)務(wù)領(lǐng)域知識等信息，只有這樣才可以知道系統(tǒng)在什么情況下會發(fā)生異常，什么情況下容易發(fā)生人為錯(cuò)誤

5、。這需要測試人員和開發(fā)人員或者系統(tǒng)分析員甚至真正的業(yè)務(wù)人員一起討論，根據(jù)軟件的類型與特點(diǎn)設(shè)計(jì)測試案例，不能憑空猜想。只有這樣設(shè)計(jì)出的案例才能夠真正的測試到，由于關(guān)鍵業(yè)務(wù)需要或者變化發(fā)生了異常，在此時(shí)軟件的處理能力。這一類的測試案例可以包括：特殊業(yè)務(wù)工作流程測試：測試軟件不按照正規(guī)的流程，而是按照可能的但非正規(guī)的業(yè)務(wù)流程運(yùn)行，是否會生成錯(cuò)誤數(shù)據(jù)，或者造成原有數(shù)據(jù)的錯(cuò)誤，甚至造成系統(tǒng)的癱瘓；刪除或修改系統(tǒng)的重要數(shù)據(jù)或配置文件測試：測試情況發(fā)生時(shí)系統(tǒng)是否能夠正確的提示，指明系統(tǒng)的錯(cuò)誤。在進(jìn)行相應(yīng)修補(bǔ)后，系統(tǒng)是否能夠正常運(yùn)行；違規(guī)操作：這類測試可以包括，對現(xiàn)有重要業(yè)務(wù)數(shù)據(jù)的違規(guī)操作、用戶越權(quán)業(yè)務(wù)操作等

6、，測試系統(tǒng)是否有相關(guān)約束。如果發(fā)生類似事件，系統(tǒng)是否有補(bǔ)救措施，而不導(dǎo)致系統(tǒng)的癱瘓。4.1.2交互規(guī)范用戶正確的操作是系統(tǒng)正常運(yùn)行的前提。所以在測試的時(shí)候，一定要進(jìn)行錯(cuò)誤操作來測試軟件系統(tǒng)的健壯性。在從操作需求方面設(shè)計(jì)異常測試的測試用例時(shí)，需要從用戶或者操作者的每一步的操作中進(jìn)行提煉，而且這些測試用例一定要可操作性強(qiáng)，輸入、輸出、操作步驟都應(yīng)該明確。實(shí)際上這部分測試用例也是功能測試用例的一部分，只是他不是正常、按照用戶需求說明書的操作而已。這一塊的內(nèi)容包括輸入框內(nèi)容、頁面跳轉(zhuǎn)等一些方面，可以使用一些常用的測試用例設(shè)計(jì)方法來設(shè)計(jì)4.2外部異常系統(tǒng)的異常除了本身以外往往會出現(xiàn)在調(diào)用的外部的異常，通

7、常指的是一些外部依賴服務(wù)的異常，如DB、緩存、MQ、外部接口的調(diào)用等。 獨(dú)立的服務(wù)不可用異常.1 DB不可用數(shù)據(jù)庫是我們系統(tǒng)經(jīng)常要使用到的功能對于DB的調(diào)用，在系統(tǒng)長時(shí)間的運(yùn)行過程中，總是會有一部分線上問題是由于DB連接的異常導(dǎo)致的。我們常說的DB異?；旧峡梢钥偨Y(jié)為DB的不可用異常，DB不可用又可以分為：DB服務(wù)不可用，DB掛起，DB不存在， DB鎖等，一般不同的情況，代碼中會拋出不同的異常，但這些種現(xiàn)象表現(xiàn)在調(diào)用上往往都是表現(xiàn)為服務(wù)不可用，可做同一情況處理。方案一（1） 通過shell中的Kill -9 pid和kill -19分別可以關(guān)閉和掛機(jī)服務(wù)；（2） DB不存在可以通過sql中的d

8、rop 、truncate、delete函數(shù)實(shí)現(xiàn)；（3） 數(shù)據(jù)庫鎖的概念比較寬泛，本初所指的為排他鎖，又稱寫鎖，若事務(wù)T對數(shù)據(jù)對象A加鎖，則只允許T讀取和修改A，其它任何事務(wù)都不能再對A加任何類型的鎖，直到T釋放A上的鎖。Sql中的HOLDLOCK函數(shù)同樣可以實(shí)現(xiàn)，也可以通過客戶端使用整張table的鎖定。數(shù)據(jù)庫不可用時(shí)，要根據(jù)系統(tǒng)的邏輯去判斷是否會繼續(xù)對系統(tǒng)有影響，以及如果存在關(guān)系時(shí)，系統(tǒng)的日志和告警能力是否完備。盡量保障系統(tǒng)故障后的盡快通知和恢復(fù)，那么除了問題出現(xiàn)后的處理，如何在其他方面盡量避免有系統(tǒng)導(dǎo)致的DB不可用的導(dǎo)致呢？（1） 數(shù)據(jù)庫的容災(zāi)備份；（2） DB降級策略，導(dǎo)致D

9、B異常的情況有可能是因?yàn)橥饬σ灿锌赡苁窍到y(tǒng)調(diào)用的原因，這里就不得不說一個(gè)DB降級的概念，DB的降級策略是否完備，也會在很大程度上關(guān)系到DB異常時(shí)對系統(tǒng)的影響的范圍；（3） 系統(tǒng)SQL的優(yōu)化，測試時(shí)SQL語句檢查，可以一定程度上避免產(chǎn)生由系統(tǒng)導(dǎo)致的DB異常.2 緩存不可用比較常見的緩存有smemcache,nkv等，這類的異常也是大部分表現(xiàn)為緩存不可用，其中和數(shù)據(jù)庫有些稍微不同的地方：緩存在一些系統(tǒng)中有可能不會是業(yè)務(wù)流程上的強(qiáng)依賴。而我們針對這類異常，應(yīng)該要關(guān)注的是，業(yè)務(wù)出現(xiàn)異常時(shí)的返回信息，以及異常出現(xiàn)后對應(yīng)的異常通知是否完善。另外除了緩存不可用以外，緩存的異常還會有緩存數(shù)據(jù)的過期，這類問題無

10、論定位于業(yè)務(wù)上還是，外部依賴上都要驗(yàn)證到此部分的內(nèi)容。方案一 memcache異常（1） 通過shell中的Kill -9 pid和kill -19分別可以關(guān)閉和掛機(jī)服務(wù)，服務(wù)有可能包括socketserver或memcache（2） 通過緩存讀寫的工具或者java源生api對memcache操作，創(chuàng)建和修改緩存中不同的數(shù)據(jù)情況方案二 nkv異常Nkv系統(tǒng)包含兩個(gè)端，CS和DS，所以針對nkv的不可用應(yīng)該包含CS和DS兩個(gè)方面p CS:config serverp DS:data serverp ns:namespacep client:NKV Client（1） 在Nkv連接異常，查看業(yè)務(wù)的

11、連續(xù)性。（2） Nkv數(shù)據(jù)修改和刪除可以通過開發(fā)接口做操作，Tips：測試環(huán)境的nkv由于業(yè)務(wù)較多，測試中不能直接通過關(guān)閉服務(wù)的方式，可以在網(wǎng)絡(luò)側(cè)面做nkv的限制；.3 依賴的接口所在系統(tǒng)異常系統(tǒng)間的接口調(diào)用一般會出現(xiàn)調(diào)用系統(tǒng)升級，服務(wù)不可用等各種狀況，針對這種我們無法預(yù)知情況，我們應(yīng)該做好我們自身系統(tǒng)的異常測試策略處理。這一塊的異常主要體現(xiàn)在系統(tǒng)對于不同的http錯(cuò)誤返回碼是否有正確處理，如http返回狀態(tài)404、500、502、504等；這一塊的內(nèi)容盡量以mock的方式構(gòu)造出對應(yīng)的返回碼，查看系統(tǒng)對于這塊返回值的處理。4.1.2 組合的服務(wù)部分不可用異常所謂的組合服務(wù)，指的是一個(gè)流程中關(guān)聯(lián)

12、多個(gè)外接系統(tǒng)，比較常見的有DB和緩存組合的情況，如我所接觸到的系統(tǒng)中存在DB反寫緩存的情況-系統(tǒng)查詢數(shù)據(jù)時(shí)，首先查緩存，緩存未查到或有問題，去查數(shù)據(jù)庫，查詢完數(shù)據(jù)庫返回信息，并反寫數(shù)據(jù)到緩存中。類似于這種情況是應(yīng)該要考慮異常場景兩兩組合分析，DB緩存現(xiàn)象異常正?？梢垣@得數(shù)據(jù)，正常返回正常異常可以獲得數(shù)據(jù)，正常返回異常異常無法返回?cái)?shù)據(jù)，系統(tǒng)正常處理錯(cuò)誤碼Tips:針對于服務(wù)組合的情況，對于新的系統(tǒng)建議做debug調(diào)試，在代碼走到不同的步驟時(shí)，加入不同的測試場景，如上圖可以考慮增加：代碼第一次走到緩存時(shí)正常，然后去查庫，最后反寫緩存時(shí)異常，查看代碼邏輯處理是否正確。4.3網(wǎng)絡(luò)異常網(wǎng)絡(luò)異常也是線上系

13、統(tǒng)最常見，也是最難捕獲的異常。每一個(gè)用戶對應(yīng)每一種的網(wǎng)絡(luò)場景，有的可能是網(wǎng)絡(luò)丟包嚴(yán)重，有的可能是網(wǎng)絡(luò)抖動頻繁，還有一些網(wǎng)絡(luò)連接超時(shí)，在如此多的網(wǎng)絡(luò)情況下，我們的系統(tǒng)是否仍然能夠按照我們產(chǎn)品設(shè)計(jì)的結(jié)果展現(xiàn)，能否在出現(xiàn)網(wǎng)絡(luò)問題時(shí)盡快恢復(fù)，是我們QA需要嚴(yán)密檢查的重點(diǎn)。4.3.1 網(wǎng)絡(luò)超時(shí)網(wǎng)絡(luò)連接超時(shí)就是在程序默認(rèn)的等待時(shí)間內(nèi)沒有得到服務(wù)器的響應(yīng)。簡單的說：就是你向服務(wù)端發(fā)送數(shù)據(jù)請求，然爾服務(wù)器沒返回?cái)?shù)據(jù)，或返回?cái)?shù)據(jù)太慢導(dǎo)致未收到返回?cái)?shù)據(jù)。這塊的測試內(nèi)容一方面要保障系統(tǒng)調(diào)用外部服務(wù)的網(wǎng)絡(luò)超時(shí)后的恢復(fù)能力，業(yè)務(wù)可以正常延續(xù)；另一方面要檢查系統(tǒng)之間配置的超時(shí)時(shí)間是否合理。 超時(shí)后的恢復(fù)系統(tǒng)

14、出現(xiàn)因?yàn)榫W(wǎng)絡(luò)原因?qū)е碌某瑫r(shí)后恢復(fù)網(wǎng)絡(luò)，業(yè)務(wù)應(yīng)該可以正常繼續(xù)，系統(tǒng)應(yīng)該保證，超時(shí)時(shí)所發(fā)送的請求異常已被處理，而不是網(wǎng)絡(luò)恢復(fù)后，調(diào)用的系統(tǒng)仍然會處理之前超時(shí)的請求。QA可以使用一些jvm的監(jiān)控工具或者通過日志的方式，模擬此場景，檢查被調(diào)用接口響應(yīng)策略，及時(shí)檢查風(fēng)險(xiǎn)。 網(wǎng)絡(luò)超時(shí)時(shí)間網(wǎng)絡(luò)超時(shí)的原因有多種，而我們也可以在測試中通過一些手段，模擬出網(wǎng)絡(luò)超時(shí)的情況。通過設(shè)置不同的超時(shí)時(shí)間，數(shù)據(jù)對比出，設(shè)置哪個(gè)超時(shí)時(shí)間是最合理的。如何選擇最合理的，這主要體現(xiàn)在超時(shí)時(shí)間配置原則上超時(shí)時(shí)間配置應(yīng)該考慮一下因素：用戶的最大可以接受時(shí)間。站點(diǎn)的頁面完成時(shí)間一般保證小于超過5秒。接口性能的情況。需要設(shè)置比

15、接口實(shí)際響應(yīng)時(shí)間長，以容忍接口響應(yīng)時(shí)間的波動。通俗講，發(fā)送的請求在處理中時(shí)，盡量不要返回超時(shí)。網(wǎng)絡(luò)環(huán)境的現(xiàn)狀。根據(jù)響應(yīng)體的長度，計(jì)算所需的數(shù)據(jù)包個(gè)數(shù)?？紤]到超時(shí)重傳，需要超過一次網(wǎng)絡(luò)重傳的時(shí)間，以免因網(wǎng)絡(luò)臨時(shí)丟包造成連鎖反映。如果是機(jī)房網(wǎng)絡(luò)，則可不關(guān)注此種情況這樣一套系統(tǒng)調(diào)用，其中每個(gè)之間都存在超時(shí)時(shí)間設(shè)定，而這些之間的超時(shí)時(shí)間如何配置便需要我們通過異常測試出的數(shù)據(jù)予以分析說明。上圖中的網(wǎng)絡(luò)超時(shí)時(shí)間應(yīng)該按照如下去配置：（1） 首先配置主系統(tǒng)-DB的超時(shí)時(shí)間：通過大范圍的測試主系統(tǒng)到DB的調(diào)用時(shí)間；（2） 遵循上面所列的原則再次去配置ngnix到主系統(tǒng)的超時(shí)時(shí)間，這里同樣需要多次的調(diào)用數(shù)據(jù)報(bào)告。

16、（3） 其次配置web服務(wù)到nginx服務(wù)的的超時(shí)時(shí)間（4） 再次配置nginx服務(wù)到web服務(wù)的的超時(shí)時(shí)間（5） 最后配置nginx響應(yīng)請求的時(shí)間。（6） 最后對比開發(fā)提供的時(shí)間給出說明。4.3.2 網(wǎng)絡(luò)丟包首先先介紹下網(wǎng)絡(luò)丟包的概念：數(shù)據(jù)在internet上是以數(shù)據(jù)包為單位傳輸?shù)?，這就是說，不管網(wǎng)絡(luò)線路有多好、網(wǎng)絡(luò)設(shè)備有多強(qiáng)悍，你的數(shù)據(jù)都不會是以線性傳輸?shù)?，中間總是有空洞的。數(shù)據(jù)包的傳輸，不可能百分之百的能夠完成，因?yàn)榉N種原因，總會有一定的損失。碰到這種情況，internet會自動的讓雙方的電腦根據(jù)協(xié)議來補(bǔ)包和重傳該包。如果網(wǎng)絡(luò)線路好、速度快，包的損失會非常小，補(bǔ)包和重傳的工作也相對較易完

17、成，因此可以近似的將所傳輸?shù)臄?shù)據(jù)看做是無損的。但是，如果網(wǎng)絡(luò)線路較差，數(shù)據(jù)的損失量就會非常大，補(bǔ)包工作又不是百分之百完成的。這種情況下，數(shù)據(jù)的傳輸就會出現(xiàn)空洞，造成丟包。所以說網(wǎng)絡(luò)丟包在網(wǎng)絡(luò)條件不理想的情況時(shí)，也是比較容易出現(xiàn)的一種場景，不同的網(wǎng)絡(luò)丟包情況下系統(tǒng)的調(diào)用也會出現(xiàn)不同的情況，以及當(dāng)網(wǎng)絡(luò)丟包情況逐漸恢復(fù)時(shí)，系統(tǒng)業(yè)務(wù)處理能否正常統(tǒng)計(jì)系統(tǒng)間不同網(wǎng)絡(luò)丟包，業(yè)務(wù)的成功率嚴(yán)格上來說當(dāng)系統(tǒng)有比較多的外部系統(tǒng)調(diào)用，針對每個(gè)系統(tǒng)都要有網(wǎng)絡(luò)丟包驗(yàn)證，針對網(wǎng)絡(luò)丟包的測試需要不同數(shù)據(jù)的分析，盡量在設(shè)計(jì)網(wǎng)絡(luò)丟包用例時(shí)，能覆蓋不同丟包范圍的數(shù)據(jù)測試。首先創(chuàng)建網(wǎng)絡(luò)丟包的環(huán)境，可以在服務(wù)器環(huán)境上通過

18、shell語言模擬出系統(tǒng)間調(diào)用的丟包率（我們組內(nèi)有工具可以使用）其次制定范圍，引流或者創(chuàng)建較多的請求來統(tǒng)計(jì)當(dāng)前丟包率，系統(tǒng)正常及失敗的情況，這里不得不提一點(diǎn)的是做此測試需要大量數(shù)據(jù)的支持最后統(tǒng)計(jì)出不同網(wǎng)絡(luò)丟包時(shí)的業(yè)務(wù)表現(xiàn)，總結(jié)出系統(tǒng)的能力網(wǎng)絡(luò)丟包恢復(fù)時(shí)，業(yè)務(wù)恢復(fù)能力我們都知道了網(wǎng)絡(luò)丟包是會有網(wǎng)絡(luò)重發(fā)的機(jī)制，那么如果我們在網(wǎng)絡(luò)丟包嚴(yán)重情況下有大量的數(shù)據(jù)請求過來，當(dāng)前任務(wù)堆積重發(fā)，待網(wǎng)絡(luò)正常是否會影響后續(xù)任務(wù)的處理呢。這其實(shí)也是我們需要關(guān)注的內(nèi)容。我們可以模擬出大量請求并發(fā)過來的情況，如果網(wǎng)絡(luò)正常后，新的請求排隊(duì)，系統(tǒng)日志仍然在打印處理網(wǎng)絡(luò)抖動時(shí)請求的任務(wù)的話。對于服務(wù)器的性能，以及

19、正常業(yè)務(wù)的使用都會產(chǎn)生很大的影響。所以我們在做網(wǎng)絡(luò)丟包的測試時(shí)，除了關(guān)心不同情境下系統(tǒng)的表現(xiàn)，還要測試到網(wǎng)絡(luò)丟包從嚴(yán)重到輕微到正常時(shí)的系統(tǒng)處理是否有問題。4.3.3 網(wǎng)絡(luò)抖動網(wǎng)絡(luò)抖動也是通信傳輸中另一種常見的現(xiàn)象，它所代表的是端和端之間傳輸?shù)姆纸M延遲變化的程度，網(wǎng)絡(luò)超時(shí)和連接斷開都屬于抖動的情況，測試方式基本上和超時(shí)和丟包相似，所觀察的指標(biāo)包括JVM的線程池情況，以及服務(wù)器的性能指標(biāo)，一般來說之前的網(wǎng)絡(luò)超時(shí)和丟包已經(jīng)測試詳盡，這塊內(nèi)容可以忽略。4.3系統(tǒng)異常系統(tǒng)上線需要考慮到多用戶和數(shù)據(jù)的壓力，我們所說的系統(tǒng)問題，包括cpu、內(nèi)存、磁盤等服務(wù)器監(jiān)控指標(biāo)。系統(tǒng)的穩(wěn)定，除了做好服務(wù)器性能評估，還需

20、要驗(yàn)證系統(tǒng)的負(fù)載均衡是否正常，負(fù)載均衡正常主要體現(xiàn)在兩個(gè)方面：一、 單個(gè)節(jié)點(diǎn)異常，其他節(jié)點(diǎn)會接管任務(wù)二、 節(jié)點(diǎn)有異常到恢復(fù)，流量恢復(fù)正常。對于系統(tǒng)異常的內(nèi)容，更多的依賴于項(xiàng)目的部署架構(gòu)，如果已經(jīng)穩(wěn)定的架構(gòu)體系，這一塊的內(nèi)容可以篩減來做。5異常測試在項(xiàng)目中的實(shí)踐5.1 系統(tǒng)架構(gòu)我所在的項(xiàng)目系統(tǒng)架構(gòu)基本如圖所示：根據(jù)系統(tǒng)的結(jié)構(gòu)，最終制定了如下的異常測試策略5.2 用例設(shè)計(jì)一、總體分成兩大部分，應(yīng)用層和系統(tǒng)層，在這里我把網(wǎng)絡(luò)傳輸?shù)漠惓＞唧w到了具體系統(tǒng)中；二、應(yīng)用層異常細(xì)化分了主系統(tǒng)的異常，外部依賴的服務(wù)異常，內(nèi)部業(yè)務(wù)異常；三、主系統(tǒng)本次新增部分接口對數(shù)據(jù)庫和緩存有依賴，所以在主系統(tǒng)異常中，我把緩存異常和數(shù)據(jù)庫異常都列舉出來，并且分別在不同的網(wǎng)絡(luò)超時(shí)和不同的網(wǎng)絡(luò)丟包率的環(huán)境設(shè)計(jì)用例。由于主系統(tǒng)中緩存和DB存在著反寫以及流程串的關(guān)系，所以也拎出緩存和DB的聯(lián)合做另外一條用例；四、手機(jī)賬號系統(tǒng)對主系統(tǒng)存在接口調(diào)用關(guān)系，讀寫數(shù)據(jù)于nkv，設(shè)計(jì)用例時(shí)，主要針對調(diào)用nkv和調(diào)用主系統(tǒng)時(shí)，不同的網(wǎng)絡(luò)條件下查看兩端間的超時(shí)時(shí)間是否設(shè)置合理，以及通過查看log日志，統(tǒng)計(jì)出不同場景時(shí)的手機(jī)賬號系統(tǒng)的響應(yīng)和調(diào)用系統(tǒng)處理異常場景的能力。五、手機(jī)賬號業(yè)務(wù)是一個(gè)web項(xiàng)目，針對web服務(wù)的一些特點(diǎn)，我這邊對cookie和靜態(tài)資源這塊設(shè)計(jì)了cookie替換、靜態(tài)資源找不到等做了一定的用例設(shè)計(jì)，對于