UAT測試實戰(zhàn)(方法+實踐)

UAT測試實戰(zhàn)(方法+實踐)第一頁，共30頁。UAT測試測試目的準(zhǔn)入規(guī)則測試基準(zhǔn)缺陷分級案例運(yùn)用第一頁第二頁，共30頁。測試目的測試目的第二頁第三頁，共30頁。測試目的第一是確認(rèn)軟件的質(zhì)量。Dotherightthing：確認(rèn)軟件做了業(yè)務(wù)所期望做的事情----模塊Doitright：確認(rèn)軟件以正確的方式來做了這個事情-----流程第二是盡可能多地找出錯誤，如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷。第三給最終用戶提供具有一定可信度的質(zhì)量評價，提高用戶滿意度。注：UAT主要目的是驗證軟件是否滿足業(yè)務(wù)需求。應(yīng)由熟悉業(yè)務(wù)需求的使用用戶來進(jìn)行評審的。

第三頁第四頁，共30頁。測試的主要目標(biāo)和方法發(fā)現(xiàn)缺陷（實施測試來降低可發(fā)現(xiàn)的缺陷）正面測試反面測試

預(yù)防缺陷（通過測試避免使用發(fā)生缺陷范圍）通過測試得到降低軟件缺陷注：測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質(zhì)量第四頁第五頁，共30頁。準(zhǔn)入規(guī)則

準(zhǔn)入第五頁第六頁，共30頁。準(zhǔn)入規(guī)則檢查項是否通過不適用責(zé)任方備注是否提供了系統(tǒng)名稱及版本說明？

開發(fā)方

是否提供了對應(yīng)的需求規(guī)格及業(yè)務(wù)文檔？

開發(fā)方

是否提供了設(shè)計文檔？

開發(fā)方

是否提供了需求跟蹤矩陣？

開發(fā)方

是否進(jìn)行了開發(fā)自測？

開發(fā)方

是否提供了開發(fā)自測報告？

開發(fā)方

是否提供了程序清單（包括源碼、安裝包、數(shù)據(jù)結(jié)構(gòu)定義文件，數(shù)據(jù)邏輯圖等）？

開發(fā)方可選，可上線時提供是否提供了系統(tǒng)環(huán)境要求及安裝說明？

開發(fā)方可選，可上線時提供是否提供了測試文檔及用戶操作說明文檔？

開發(fā)方

是否提供了維護(hù)說明文檔？

開發(fā)方可選，可上線時提供是否提供了回退說明文檔？

開發(fā)方可選，可上線時提供第六頁第七頁，共30頁。測試的主要目標(biāo)和方法發(fā)現(xiàn)缺陷（實施測試來降低可發(fā)現(xiàn)的缺陷）正面測試反面測試

預(yù)防缺陷（通過測試避免使用發(fā)生缺陷范圍）通過測試得到降低軟件缺陷注：測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質(zhì)量第七頁第八頁，共30頁。

測試基準(zhǔn)基準(zhǔn)第八頁第九頁，共30頁。測試基準(zhǔn)測試過程中把控一下原則:Good-enough:權(quán)衡測試深度-項目進(jìn)度的原則保證測試的覆蓋程度，但窮舉測試是不可能的所有的測試都應(yīng)追溯到用戶需求不能為了便于測試擅自修改程序既應(yīng)該測試軟件該做什么,也應(yīng)該測試軟件不該做什么

軟件測試的具體內(nèi)容就是進(jìn)行驗證和確認(rèn)。驗證軟件是否和規(guī)定要求相一致；通過操作確認(rèn)軟件邏輯的正確性。第九頁第十頁，共30頁。缺陷管理第十頁第十一頁，共30頁。缺陷管理一、缺陷管理流程第十一頁第十二頁，共30頁。二、缺陷嚴(yán)重度-嚴(yán)重度等級定義嚴(yán)重度1—非常嚴(yán)重的缺陷：產(chǎn)品在正常的運(yùn)行環(huán)境下無法給用戶提供服務(wù)，或者不能執(zhí)行正常工作功能或重要功能?；蛘哕浖斐扇松韨蛭＜叭松戆踩?。嚴(yán)重度1的例子：軟件的意外退出甚至操作系統(tǒng)崩潰，造成數(shù)據(jù)丟失系統(tǒng)重啟引起模塊之間或者單元之間或者系統(tǒng)之間數(shù)據(jù)的傳輸失敗無法提供系統(tǒng)主要的…缺陷管理第十二頁第十三頁，共30頁。二、缺陷嚴(yán)重度-嚴(yán)重度等級定義嚴(yán)重度2—嚴(yán)重度缺陷：嚴(yán)重影響了系統(tǒng)提供給用戶的服務(wù)。嚴(yán)重影響系統(tǒng)要求或者基本功能的實現(xiàn)，且沒有辦法來減輕這個缺陷的影響。嚴(yán)重度2的例子：系統(tǒng)中的某些模塊會重啟，但不影響系統(tǒng)數(shù)據(jù)的處理和傳輸用戶使用系統(tǒng)提供的功能，有時候會導(dǎo)致系統(tǒng)系統(tǒng)掛起，不影響系統(tǒng)數(shù)據(jù)處理和功能處理軟件的某個菜單不起作用，或者產(chǎn)生錯誤的結(jié)果…缺陷管理第十三頁第十四頁，共30頁。二、缺陷嚴(yán)重度-嚴(yán)重度等級定義嚴(yán)重度3—一般的缺陷：系統(tǒng)需要增強(qiáng)的或存在的一些缺陷，擔(dān)憂相應(yīng)的補(bǔ)救方法來解決這個缺陷。嚴(yán)重度3的例子：系統(tǒng)的某個模塊失效了，但系統(tǒng)沒有上報相應(yīng)的告警功能特征設(shè)計不符合系統(tǒng)的需求，不影響系統(tǒng)的業(yè)務(wù)，并且有相應(yīng)的補(bǔ)救方法。本地化軟件的某些字符沒有翻譯或者翻譯錯誤…缺陷管理第十四頁第十五頁，共30頁。二、缺陷嚴(yán)重度-嚴(yán)重度等級定義嚴(yán)重度4—輕微的缺陷：細(xì)小的問題，不需要補(bǔ)救方法或功能增強(qiáng)的請求。操作不方便或容易使用戶誤操作，但不影響執(zhí)行基本功能。嚴(yán)重度4的例子：上報的信息不符合系統(tǒng)的需求，描述不精確或可能對用戶有些誤導(dǎo)GUI界面問題，不精確或肯呢個對用戶有些歧義某個空間沒有對齊，某個標(biāo)點(diǎn)符號丟失…缺陷管理第十五頁第十六頁，共30頁。三、缺陷嚴(yán)重度-優(yōu)先級缺陷優(yōu)先級優(yōu)先級是表示處理和修正軟件缺陷的先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先處理，哪些缺陷可以稍微修改。確定缺陷的優(yōu)先級，更多的是站在軟件開發(fā)和軟件測試的角度來考慮，是個復(fù)雜的過程，有時候可能并不是純技術(shù)問題。需要同時考慮修改缺點(diǎn)的難度和存在的風(fēng)險。優(yōu)先級也需要考慮缺陷發(fā)生的頻率，以及對目標(biāo)客戶的影響。嚴(yán)重度和優(yōu)先級的關(guān)系缺陷的嚴(yán)重度和優(yōu)先級是含義不同但相互聯(lián)系密切的兩個概念，從不同的側(cè)面描述了軟件缺陷對軟件質(zhì)量、最終用戶、開發(fā)過程的影響程度和處理方式。一般來說，嚴(yán)重度高度缺陷具有較高的優(yōu)先級。嚴(yán)重度高說明缺陷對軟件造成的質(zhì)量危害性大，需要優(yōu)先處理，而嚴(yán)重性低端缺陷可能只是軟件不盡善盡美，可以稍后處理。但是優(yōu)先級和嚴(yán)重度并不總是一一對應(yīng)的，也存在低優(yōu)先級、高嚴(yán)重度的缺陷，或者高優(yōu)先級、低嚴(yán)重度的軟件缺陷。缺陷管理第十六頁第十七頁，共30頁。四、缺陷嚴(yán)重度-處理方式在UAT測試階段，系統(tǒng)一般不會再發(fā)生特別嚴(yán)重的問題，比如系統(tǒng)崩潰等。即使真的發(fā)生特別嚴(yán)重的問題，也一般會采用特殊流程進(jìn)行追蹤，以便迅速得以解決。所以，為便于缺陷管理，我們可以簡化缺陷嚴(yán)重度劃分，將其分為：高（嚴(yán)重）、中（一般）、低（輕微）。嚴(yán)重缺陷系統(tǒng)主要功能未完全實現(xiàn)或者實現(xiàn)方式有誤。這類缺陷在UAT階段應(yīng)該予以極大重視，并優(yōu)先得到修復(fù)。一般缺陷系統(tǒng)的一些功能在實現(xiàn)上不盡如人意。這類缺陷也較為嚴(yán)重，在條件允許的情況下，要及早修復(fù)。輕微缺陷一般是指與界面相關(guān)的一些細(xì)微缺陷，如錯別字、界面風(fēng)格和易用性問題等，不會涉及到系統(tǒng)功能，不影響使用，但影響用戶體驗。這類缺陷不那么嚴(yán)重，但影響感知的應(yīng)優(yōu)先處理。如瀏覽器兼容性問題等，在標(biāo)準(zhǔn)終端標(biāo)準(zhǔn)下可正常使用的，可不用修復(fù)。缺陷管理第十七頁第十八頁，共30頁。案例運(yùn)用案例運(yùn)用第十八頁第十九頁，共30頁。案例運(yùn)用一、測試報告涵蓋度不夠

測試報告本身問題，常見問題如下：測試用例的結(jié)構(gòu)和層次不清晰； 測試用例的重點(diǎn)是否突出，是否抓住新增或修改的功能或系統(tǒng)的薄弱環(huán)節(jié),如流程節(jié)點(diǎn)控制； 測試用例是否覆蓋了顯式和隱式功能需求； 測試用例是否涉及了正常情況和異常情況； 測試用例中是否包含測試數(shù)據(jù)或測試數(shù)據(jù)規(guī)則； 測試用例是否描述了前提條件，步驟是否簡明清楚； 測試步驟是否包含了檢查點(diǎn)與預(yù)期值； 測試用例是否覆蓋了所有測試需求，如右圖。

第十九頁第二十頁，共30頁。案例運(yùn)用-WEB測試一、WEB測試1.功能測試Web應(yīng)用軟件的功能測試主要包括表單測試、Cookies測試、設(shè)計語言測試、鏈接測試以及數(shù)據(jù)庫測試等。1）表單測試指的是測試服務(wù)器是否能夠正常接收和保存用戶填寫的表單數(shù)據(jù)以及測試表單信息正確性等內(nèi)容，測試程序在后臺運(yùn)行時能否正常使用這些表單信息。見反例，流程在反向流轉(zhuǎn)過程中保存提示如下信息，就是單據(jù)信息丟失導(dǎo)致。

第二十頁第二十一頁，共30頁。案例運(yùn)用一、WEB測試2）Cookies測試指的是測試程序的Cookies能否正常使用，并且對這些加密的信息驗證次數(shù)累計是否正確；反例，在單據(jù)更換人員時未做校驗導(dǎo)致。第二十一頁第二十二頁，共30頁。案例運(yùn)用一、WEB測試3）數(shù)據(jù)庫測試，表單數(shù)據(jù)輸入與數(shù)據(jù)庫內(nèi)信息是否匹配，與表單讀取數(shù)據(jù)庫信息是否一字等。例：使用轉(zhuǎn)譯字符進(jìn)行測試，如“<head>,/n”等字符處理，查看轉(zhuǎn)譯是否正常，右圖反例，出現(xiàn)特殊字符：4）各模塊可用測試，包括各模塊導(dǎo)航，界面顯示，內(nèi)容顯示，圖形顯示。主要看模塊功能是否正常，顯示是否符合預(yù)期。第二十二頁第二十三頁，共30頁。案例運(yùn)用一、WEB測試5）兼容性測試，測試WEB應(yīng)用在與不同操作系統(tǒng)、瀏覽器、打印機(jī)等進(jìn)行兼容測試，測試應(yīng)用的健壯性。重點(diǎn)測試IE兼容性。6）接口測試除測試各接口鏈接情況，更應(yīng)側(cè)重測試軟件遇到接口錯誤是否有錯誤處理能力。第二十三頁第二十四頁，共30頁。案例運(yùn)用二、APP測試1）測試APP安裝、運(yùn)行、卸載，最好在多個主流實體終端測試，其余模擬終端測試。測試關(guān)注點(diǎn)：安裝是否正常；軟件是否能夠正常運(yùn)行；安裝中途是否可以進(jìn)行取消安裝操作、當(dāng)安裝空間不足時是否有相應(yīng)的提示信息等內(nèi)容。直接卸載程序時是否有提示信息、卸載后安裝的文件夾及文件是否被全部刪除；是否可以取消已經(jīng)進(jìn)行的卸載操作，以及直接刪除安裝文件夾是否有提示信息等內(nèi)容。第二十四頁第二十五頁，共30頁。案例運(yùn)用二、APP測試2）功能測試，驗證APP的各個功能是否準(zhǔn)確實現(xiàn)。測試關(guān)注點(diǎn)：運(yùn)行，比照web功能進(jìn)行對比；前后臺切換，查看切換情況；免登錄時使用情況跟蹤；測試時考慮等價類劃分、邊界值分析、場景回滾、關(guān)聯(lián)測試等測試類型對其進(jìn)行全面覆蓋。第二十五頁第二十六頁，共30頁。案例運(yùn)用二、APP測試3）UI測試，也叫用戶界面測試，關(guān)注人機(jī)交互界面。用戶交互部分一般是指菜單、對話框、按鈕等控件和可見外觀，如友好的用戶界面、人性化的頁面布局、易操作的功能按鈕。4）交叉事件測試，又叫事件或者沖突測試，它是指一個APP程序正在執(zhí)行過程中，同時另外一個事件或操作對該過程進(jìn)行干擾的一種測試。關(guān)注的幾個方面:多個APP同時運(yùn)行時，是否會影響終端正常功能的使用。APP運(yùn)行時，前臺后臺切換的時候是否影響功能的正常使用。APP運(yùn)行時，是否可以正常接聽或撥打電話，或者可以正常接收或發(fā)送短信。在移動智能終端上運(yùn)行APP時，是否會影響其他應(yīng)用的使用。例如能否查看新的QQ消息、微信消息等信息。第二十六頁第二十七頁，共30頁。事實上，測試活動的結(jié)束與否并不完全依賴于準(zhǔn)出檢查單中的所有項目是否都已通過。還應(yīng)當(dāng)參考項目的預(yù)期和項目本身等因素。比如當(dāng)前