1、執(zhí)行測試趙建華南京大學(xué)計算機(jī)系主要活動 分配測試時間 激發(fā)測試 標(biāo)志出現(xiàn)的失效分配測試時間 按照三個步驟進(jìn)行 在要測試的系統(tǒng)之間分配測試時間 在進(jìn)行可靠性增長測試的每個系統(tǒng)的功能,回歸,和負(fù)載測試之間分配時間。 在進(jìn)行負(fù)載測試的每個系統(tǒng)的操作模式之間分配測試時間。 對于進(jìn)行確認(rèn)測試的系統(tǒng)，所有的測試時間都被分配給負(fù)載測試。在被測試系統(tǒng)之間分配時間 對于系統(tǒng)的當(dāng)前版本 首先根據(jù)估計的風(fēng)險，將測試時間在超系統(tǒng)之間分配時間。 對于其他的系統(tǒng)，時間的分配原則上按照分配新的測試案例的比例分配測試時間。 分配案例的比率已經(jīng)反映了被測試系統(tǒng)之間的相對重要性和新成分的多少。 例如：Fone Follower中

2、，總共計劃320小時的測試，40小時分配給超系統(tǒng)。以前的測試案例的分配為0.714和0.286。所以各個系統(tǒng)得到的時間為，產(chǎn)品200小時，操作系統(tǒng)80小時。不同測試方式之間的再分配 如果系統(tǒng)進(jìn)行可靠性測試 首先分配功能測試的時間。 然后分配進(jìn)行回歸測試的時間。 剩下的時間分配給負(fù)載測試。 如果系統(tǒng)只進(jìn)行確認(rèn)測試，那么所有的時間都分配給了負(fù)載測試。 例如：Fone Follower中，超系統(tǒng)的40小時和操作系統(tǒng)的80小時，都分配給負(fù)載測試。對于產(chǎn)品測試的200小時，預(yù)計進(jìn)行10小時的功能測試，估計進(jìn)行10次每次1小時的回歸測試。這樣負(fù)載測試的時間分配為180小時。在操作模式之間分配測試時間 在操

3、作模式之間分配測試時間的基本規(guī)則為：按照各種模式在實(shí)際使用中被使用的比例。 對于Fone Follower，modeProportionSuper systemProduct timeOS timePeak hours0.14188Primehours0.72812656Off hours0.283616激發(fā)測試（1）SRE的測試需要在系統(tǒng)的單元經(jīng)過了測試或Verification，并且被集成后使得系統(tǒng)的各個操作都可以完成。一般按照以下的順序測試系統(tǒng)，主要的原因是：對于測試結(jié)果信息的需求的先后順序。也可以采取其他的順序。1.采辦組件2.產(chǎn)品和變體3.超系統(tǒng)激發(fā)測試（2） 對于單個系統(tǒng)的測試順序

4、： 功能測試負(fù)載測試（程序有改動后）回歸測試 功能測試：從所有新測試案例和以前版本的回歸測試案例集合中隨機(jī)選擇（包含了所有的關(guān)鍵性操作的測試案例）。 負(fù)載測試：按所分配的時間比例，使用合適的測試過程，調(diào)用每個操作模式。 回歸測試：調(diào)用所有功能測試的測試案例，或從中選擇一個子集（包括所有的關(guān)鍵操作）。案例選擇 總共執(zhí)行的案例的數(shù)量是由允許的時間決定的。 案例是按照測試操作剖面的概率，以隨機(jī)的順序，在隨機(jī)時刻被激發(fā)的。 對于負(fù)載測試，案例的選擇是可重復(fù)的。 一個案例被選擇并執(zhí)行之后，可能又被執(zhí)行。原因在于：負(fù)載測試中，案例的執(zhí)行數(shù)目遠(yuǎn)遠(yuǎn)大于允許的案例數(shù)目，且間接輸入變量有一定的影響。 對于功能測試

5、或回歸測試，案例的選擇是不可重復(fù)的。 一個案例只會被執(zhí)行一次。原因在于：間接變量的影響被嚴(yán)格控制，同一個案例執(zhí)行兩次而出現(xiàn)不同的行為的可能性要遠(yuǎn)遠(yuǎn)小于兩個不同案例的執(zhí)行。重復(fù)運(yùn)行 運(yùn)行重復(fù)的主要目的 增加有關(guān)失效的信息。 確認(rèn)失效（錯誤）已經(jīng)消除了。 失效的重現(xiàn)是必要的。為了能夠重現(xiàn)，我們必須紀(jì)錄每個運(yùn)行的相關(guān)信息 案例，激發(fā)的時間，操作模式，環(huán)境變量，操作選擇 在執(zhí)行測試的過程中，選擇操作的時候需要達(dá)是穩(wěn)定。 穩(wěn)定和不穩(wěn)定的例子： 操作A: 0.7；操作B: 0.3。 順序1：ABAABAAABA 順序2：AAAAAAABBB順序穩(wěn)定(1)不穩(wěn)定(2)11120.5130.67140.751

6、50.6160.67170.71180.750.8890.670.78100.70.7找出系統(tǒng)失效 找出系統(tǒng)失效所需要做的事情 分析測試輸出，以找到行為偏離(deviation) 確定哪些偏離是失效 估計失效是什么時候發(fā)生的 確認(rèn)失效的嚴(yán)重程度等級分析測試輸出，確定偏離 偏離(deviation)是指系統(tǒng)的行為和原來預(yù)期的有偏差：通信失效，非法內(nèi)存引用，死鎖， 可以通過自動化的方法來檢測系統(tǒng)的失效行為。 可以使用特定的工具來完成失效的自動檢測。 也可以在代碼中插入斷言來完成失效的自動檢測。 也可以設(shè)計內(nèi)部狀態(tài)審計程序或者外部結(jié)果檢測器來檢測失效行為。 但是，一定程度的人工檢測是必須的 可能會有

7、難以預(yù)先估計的錯誤出現(xiàn)。 由于負(fù)載測試中，運(yùn)行的數(shù)量很多，有些不能自動監(jiān)測的失效會被忽略。不算偏離的行為偏差 通常不計算程序行為在性能上的偏差。 級聯(lián)偏離不計算：一個偏離可能引起其他的偏差。此時只應(yīng)該計算一個偏離。 即使開始的時候多計算了，如果發(fā)現(xiàn)他們是相關(guān)的就應(yīng)該合并。判斷哪些偏差是失效（1） 確定偏離是否失效需要人工的參與。 但是，可以一些很嚴(yán)重的錯誤可以通過自動的方式檢測到。 Process craches, incomplete transactions. 需要根據(jù)不同的情況判斷一個偏離是否失效。判斷哪些偏差是失效（2） 容錯系統(tǒng) 通常偏離不算失效。但是，如果容錯系統(tǒng)不能夠禁得起本來應(yīng)

8、該容忍的偏離，就是錯誤。 故障，麻煩，修改和變更報告不一定是錯誤 用戶報告的故障，事件不一定是錯誤。 可能是人為錯誤，希望有新的功能，或者文檔不夠清晰。判斷哪些偏差是失效（3） 當(dāng)系統(tǒng)沒有違反書面規(guī)范，但是用戶不滿意時 大部分原因是因?yàn)橐?guī)范沒有描述好，或者書寫不清晰。一般認(rèn)為這樣的東西是一種失效。除非承認(rèn)失效會引起大的損失。 一般不考慮單個用戶的不滿意。 故意不解決的失效實(shí)際上可以看作是需求變化。 如果失效沒有引起用戶不滿意，并且解決這個失效的代價比較大，那么可以考慮不消除這個失效。 這樣的“失效”可以不算是失效。判斷哪些偏差是失敗（4） 關(guān)于同一個錯誤引起的失效 在確認(rèn)測試中，一個錯誤引起的

9、多個失效需要被分別計算失效個數(shù)。 在可靠性增長測試中，這些失效應(yīng)該被計算為一個失效。 將一個錯誤引起的多個實(shí)效分別計算得到的失效強(qiáng)度表示的是客戶的體驗(yàn)。而將多個失效合并為一個計算，得到的是修改后的FI，也可以認(rèn)為是開發(fā)者的體驗(yàn)。確定失效發(fā)生的時間（1） 使用當(dāng)初確定FIO的度量方式來記錄失效發(fā)生的“時間”。 如果使用時間來表示FIO的話，那么我們需要用執(zhí)行時間來記錄失效何時發(fā)生。 通常，我們記錄錯誤發(fā)生時間是用的日歷時間，因此我們需要將他們換算成為執(zhí)行時間。最后還需要將他們重新?lián)Q算成為日歷時間。紀(jì)錄失效發(fā)生的時間（2） 對于確認(rèn)測試，需要紀(jì)錄失效發(fā)生的確切時間點(diǎn)。 而在可靠性增長測試中，你應(yīng)該

10、盡量紀(jì)錄失效發(fā)生的時間點(diǎn)，但是有時你也可以記錄一個時間段中發(fā)生的失效個數(shù)。 測試過程中，用于錯誤定位和改正確認(rèn)的時間不計算在內(nèi)。時間之間的換算 一個軟件的執(zhí)行時間是非常難以準(zhǔn)確計算的。但是我們可以通過某些指標(biāo)來估計計算機(jī)的利用率：比如使用這個系統(tǒng)的用戶數(shù)。 通過估算利用率，我們就可以從時鐘時間得到執(zhí)行時間。 考慮的執(zhí)行時間是指執(zhí)行被測試的軟件的執(zhí)行時間。 對于分布式的軟件，最好使用某種自然單位來度量可靠性。不得不選擇時間時，可以考慮使用一個主要處理器的運(yùn)行時間來估算。時間換算的例子 從執(zhí)行時間到時鐘時間的轉(zhuǎn)換FailureExecution Ave. computer utilizationA

11、djusted time10.20.40.520.60.41.531.20.43估算計算機(jī)利用率的例子 利用用戶個數(shù)估算利用率 10am發(fā)生的失效和2pm發(fā)生的失效之間的執(zhí)行時間間隔是0.8+0.72+0.4+0.72 = 2.64小時HourNumber of UserutilizationHourNumber of userutilization8-9am160.321-2pm360.729-10am360.722-3pm400.810-11am400.83-4pm400.811-12am360.724-5pm360.7212-1pm200.45-6pm240.48失效信息的記錄 信息記錄

12、應(yīng)該標(biāo)準(zhǔn)化，并且包含盡量多的信息，使得人員的變換不至于引起信息的丟失。信息可以包括： 失效嚴(yán)重程度類； 具體的失效發(fā)生時間（不是發(fā)現(xiàn)時間） 失效現(xiàn)象，但是的運(yùn)行環(huán)境 是否可以重現(xiàn)，以及如何重現(xiàn) 發(fā)現(xiàn)失效可能是在程序運(yùn)行時刻，也可能是在1-2天后分析數(shù)據(jù)的時候。特殊情況 對于多配置軟件的測試。 確認(rèn)失效發(fā)生時間的不確定性。 處理具有多個版本的系統(tǒng)。對于多配置軟件的測試 兩種可能的多配置情況 單機(jī)軟件，但是可能運(yùn)行在不同的計算機(jī)上。 分布式系統(tǒng)，而硬件系統(tǒng)的平臺可能不同。 基本的方法是： 運(yùn)行多個版本，并且將這些版本運(yùn)行時刻的失效排列起來。失效發(fā)生的時間時這些版本的時間的總和。 如果不同的版本之間

13、有不同的運(yùn)行速度，那么可以以一個版本為基準(zhǔn)，將其他版本的時間進(jìn)行相應(yīng)的轉(zhuǎn)換。處理多配置軟件的測試?yán)?多配置軟件的時間累加timeEventConfig. AConfig. BFailure times8:00Start A08:30Start B3009:00Failure 16030909:20Failure 28050130不同版本處理速率不同時 Configure B的處理強(qiáng)度是Configure A的2倍time EventConfig. AConfig. B調(diào)整后的 Config. BFailure times8:00 Start A08:30 Start B3000309:00

14、Failure 1 6030601209:20 Failure 2 8050100180處理失效發(fā)生時間的不確定性的問題（1） 因?yàn)橛涗浀臄?shù)據(jù)太少，或者數(shù)據(jù)記錄后保存，匯報的問題，我們難以確定某些失效發(fā)生的準(zhǔn)確時刻。但是我們可以確定這些失效在某個時間段內(nèi)發(fā)生。 完全放棄這些數(shù)據(jù)將降低估算和預(yù)測的精確度。存在一個辦法來利用這些數(shù)據(jù)（和其他精確的失效數(shù)據(jù)）進(jìn)行比較精確的估算和預(yù)測。處理失效發(fā)生時間的不確定性的問題（2） 假設(shè)失效數(shù)據(jù)記錄中，有部分失效只記錄了發(fā)生的時間段。使用隨機(jī)數(shù)給這些失效確定一個假設(shè)的時刻。然后按照這樣的數(shù)據(jù)進(jìn)行數(shù)值估算。例子 不確定性的例子EventTimeRandom NumberAdj. FactorAssigned timeTime IntervalStart00Fail 1303030Fail 290-140675570.0005123.893.8Fail 318018086.2Stop240240Start240240Fail 4240-44026,4460.0002292.9112.9Fail 5240-44097,1590.0002434.3141.4Stop480480當(dāng)多個失效被記錄為同時發(fā)生 此時會使得對于系統(tǒng)FI的估算過于悲觀：在零時間段內(nèi)發(fā)生了多個錯誤。 最好做