用例評(píng)審主要是QA、產(chǎn)品人員、開(kāi)發(fā)人員和測(cè)試人員針對(duì)測(cè)試用例能否用于項(xiàng)目的測(cè)試而做的,我在TestBird從事了多年的項(xiàng)目測(cè)試,測(cè)試用例是給測(cè)試人員執(zhí)行用的,所以要求盡量的詳細(xì)而不冗余,精湛而不紕漏,至于一些覆蓋率的問(wèn)題還是測(cè)試內(nèi)部評(píng)審時(shí)要考慮的問(wèn)題,與項(xiàng)目的用例評(píng)審沒(méi)有關(guān)系。
主要分為4個(gè)環(huán)節(jié):需求評(píng)審、需求實(shí)現(xiàn)流程圖評(píng)審、測(cè)試大綱評(píng)審、測(cè)試用例檢查每個(gè)環(huán)節(jié)都包含很多內(nèi)容,比如說(shuō)需求評(píng)審主要是:檢查需求理解無(wú)偏差、檢查需求講解思路清晰、檢查需求討論會(huì)議提出需求建議、需求討論的問(wèn)題都有體現(xiàn),并且記錄的詳細(xì)、檢查需求講解時(shí)存在問(wèn)題的記錄,跟進(jìn)結(jié)論。流程圖評(píng)審,包括要檢查實(shí)現(xiàn)邏輯的深度與仔細(xì)程度。
例如:軟件升級(jí)實(shí)現(xiàn)邏輯--什么時(shí)候獲取服務(wù)器版本信息?版本信息有什么? 版本信息獲取失敗的處理?獲取的版本信息版本比對(duì)策略是什么?比對(duì)后的下載邏輯策略是什么?下載的文件保存在哪里?下載過(guò)程的失敗處理?下載成功后的安裝策略是什么?安裝失敗的處理邏輯是什么?安裝成功后的數(shù)據(jù)加載時(shí)機(jī)以及加載哪些數(shù)據(jù)?等等建議你還是找找相關(guān)刊物,有很多具體的內(nèi)容。
4、評(píng)審內(nèi)容 評(píng)審的內(nèi)容有以下幾個(gè)方面: 1) 用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理,是否利于高效對(duì)需求進(jìn)行覆蓋。
2) 優(yōu)先極安排是否合理。 3) 是否覆蓋測(cè)試需求上的所有功能點(diǎn)。
4) 用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確;期待結(jié)果是否有明顯的驗(yàn)證方法。
5) 是否已經(jīng)刪除了冗余的用例。 6) 是否包含充分的負(fù)面測(cè)試用例。
充分的定義,如果在這里使用2&8法則,那就是4倍于正面用例的數(shù)量,畢竟一個(gè)健壯的軟件,其中80%的代碼都是在“保護(hù)”20%的功能實(shí)現(xiàn)。 7) 是否從用戶層面來(lái)設(shè)計(jì)用戶使用場(chǎng)景和使用流程的測(cè)試用例。
8) 是否簡(jiǎn)潔,復(fù)用性強(qiáng)。例如,可將重復(fù)度高的步驟或過(guò)程抽取出來(lái)定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。
個(gè)人認(rèn)為,一個(gè)“健康”的測(cè)試用例至少要通過(guò)前5個(gè)標(biāo)準(zhǔn)。 5、評(píng)審的方式 1) 召開(kāi)評(píng)審會(huì)議。
與會(huì)者在設(shè)計(jì)人員講解之后給出意見(jiàn)和建議,同時(shí)進(jìn)行詳細(xì)的評(píng)審記錄。 2) 通用郵件與相關(guān)人員溝通 3) 通用IM工具直接與相關(guān)人員交流 方式只是手段,得到其它人員對(duì)于用例的反饋信息才是目的。
無(wú)論采用那種方式,都應(yīng)該在溝通之前把用例設(shè)計(jì)的相關(guān)文檔發(fā)送給對(duì)方進(jìn)行前期的學(xué)習(xí)和了解,以節(jié)省溝通成本。 6、評(píng)審結(jié)束標(biāo)準(zhǔn) 在評(píng)審活動(dòng)中會(huì)收集到用例的反饋信息,在此基礎(chǔ)上進(jìn)行用例更新,直到通過(guò)評(píng)審。
主要是避免責(zé)任不清,出現(xiàn)扯皮,誤工等現(xiàn)象。
所以,必須參加測(cè)試用例評(píng)審。首先要清楚內(nèi)部評(píng)審的定義,是測(cè)試組內(nèi)部的評(píng)審,還是項(xiàng)目組內(nèi)部的評(píng)審。
評(píng)審的定義不同,內(nèi)容也不會(huì)相同。 如果是測(cè)試組內(nèi)部的評(píng)審,應(yīng)該著重于: 1.測(cè)試用例本身的描述是否清晰,是否存在二義性; 2.是否考慮到測(cè)試用例的執(zhí)行效率.往往測(cè)試用例中步驟不斷重復(fù)執(zhí)行,驗(yàn)證點(diǎn)卻不同,而且測(cè)試設(shè)計(jì)的冗余性,都造成了效率的低下; 3.是否針對(duì)需求跟蹤矩陣,覆蓋了所有的軟件需求; 4.是否完全遵守了軟件需求的規(guī)定。
這并不一定的,因?yàn)榧词乖賴?yán)格的評(píng)審,也會(huì)出現(xiàn)錯(cuò)誤,應(yīng)具體情況具體對(duì)待。 如果是項(xiàng)目組內(nèi)部的評(píng)審,也就需要評(píng)審委員會(huì)來(lái)做了,角度不同,評(píng)審的標(biāo)準(zhǔn)也不同。
主要是避免責(zé)任不清,出現(xiàn)扯皮,誤工等現(xiàn)象。
所以,必須參加測(cè)試用例評(píng)審。首先要清楚內(nèi)部評(píng)審的定義,是測(cè)試組內(nèi)部的評(píng)審,還是項(xiàng)目組內(nèi)部的評(píng)審。
評(píng)審的定義不同,內(nèi)容也不會(huì)相同。 如果是測(cè)試組內(nèi)部的評(píng)審,應(yīng)該著重于: 1.測(cè)試用例本身的描述是否清晰,是否存在二義性; 2.是否考慮到測(cè)試用例的執(zhí)行效率.往往測(cè)試用例中步驟不斷重復(fù)執(zhí)行,驗(yàn)證點(diǎn)卻不同,而且測(cè)試設(shè)計(jì)的冗余性,都造成了效率的低下; 3.是否針對(duì)需求跟蹤矩陣,覆蓋了所有的軟件需求; 4.是否完全遵守了軟件需求的規(guī)定。
這并不一定的,因?yàn)榧词乖賴?yán)格的評(píng)審,也會(huì)出現(xiàn)錯(cuò)誤,應(yīng)具體情況具體對(duì)待。 如果是項(xiàng)目組內(nèi)部的評(píng)審,也就需要評(píng)審委員會(huì)來(lái)做了,角度不同,評(píng)審的標(biāo)準(zhǔn)也不同。
用例評(píng)審主要是QA、產(chǎn)品人員、開(kāi)發(fā)人員和測(cè)試人員針對(duì)測(cè)試用例能否用于項(xiàng)目的測(cè)試而做的,我在TestBird從事了多年的項(xiàng)目測(cè)試,測(cè)試用例是給測(cè)試人員執(zhí)行用的,所以要求盡量的詳細(xì)而不冗余,精湛而不紕漏,至于一些覆蓋率的問(wèn)題還是測(cè)試內(nèi)部評(píng)審時(shí)要考慮的問(wèn)題,與項(xiàng)目的用例評(píng)審沒(méi)有關(guān)系。
主要分為4個(gè)環(huán)節(jié):需求評(píng)審、需求實(shí)現(xiàn)流程圖評(píng)審、測(cè)試大綱評(píng)審、測(cè)試用例檢查
每個(gè)環(huán)節(jié)都包含很多內(nèi)容,比如說(shuō)需求評(píng)審主要是:檢查需求理解無(wú)偏差、檢查需求講解思路清晰、檢查需求討論會(huì)議提出需求建議、需求討論的問(wèn)題都有體現(xiàn),并且記錄的詳細(xì)、檢查需求講解時(shí)存在問(wèn)題的記錄,跟進(jìn)結(jié)論。
流程圖評(píng)審,包括要檢查實(shí)現(xiàn)邏輯的深度與仔細(xì)程度。例如:軟件升級(jí)實(shí)現(xiàn)邏輯--什么時(shí)候獲取服務(wù)器版本信息?版本信息有什么? 版本信息獲取失敗的處理?獲取的版本信息版本比對(duì)策略是什么?比對(duì)后的下載邏輯策略是什么?下載的文件保存在哪里?下載過(guò)程的失敗處理?下載成功后的安裝策略是什么?安裝失敗的處理邏輯是什么?安裝成功后的數(shù)據(jù)加載時(shí)機(jī)以及加載哪些數(shù)據(jù)?等等
建議你還是找找相關(guān)刊物,有很多具體的內(nèi)容。
當(dāng)然應(yīng)該是你的測(cè)試用例的步驟,要讓別人能看懂,不然別人怎么執(zhí)行你的用例呢
什么樣的用例是好的用例?
一.質(zhì)量屬性
Quality Attributes
1.正確性:確保測(cè)試標(biāo)題描述部分的內(nèi)容正確性。
2.經(jīng)濟(jì)性:只為確定需要的目的設(shè)計(jì)相應(yīng)的測(cè)試步驟
3.適應(yīng)性:既能適應(yīng)短期需要,又能考慮長(zhǎng)遠(yuǎn)需要。
4.可追蹤性:用例能追蹤到一個(gè)具體的需求。
5.自我清理性:?jiǎn)蝹€(gè)用例不會(huì)影響整個(gè)測(cè)試環(huán)境,即用例執(zhí)行完了可以恢復(fù)原有的測(cè)試環(huán)境。
二.結(jié)構(gòu)化和可測(cè)試性
Structure and testability
1.含有規(guī)范的測(cè)試標(biāo)題和編號(hào)。
2.含有一個(gè)確定的測(cè)試某一個(gè)特定需求的目的。
3.含有關(guān)于測(cè)試方法的描述。
4.指定條件信息-環(huán)境、數(shù)據(jù)、預(yù)置的條件測(cè)試、安全入口等。
5.含有操作步驟和預(yù)期結(jié)果。
6.陳述任何輔助證據(jù),例如截圖報(bào)告并確保這些東西妥善保存。
7.確保測(cè)試環(huán)境的干凈(即用例不會(huì)影響整個(gè)環(huán)境)。
8.描述時(shí)使用主動(dòng)語(yǔ)氣結(jié)構(gòu)。
9.操作步驟不要超過(guò)15步
10.確保單個(gè)用例測(cè)試執(zhí)行時(shí)用時(shí)不超過(guò)20分鐘。
11.自動(dòng)化腳本用例添加必要的注釋,比如目的、輸入和期望結(jié)果。
12.如果可能,建議提供可選擇性的預(yù)置條件測(cè)試。
13.用例之間的先后順序是否跟業(yè)務(wù)流程一致,即用例在業(yè)務(wù)流程中的彼此順序關(guān)系是否合理。
三.配置管理
Configuration management
1.采用命名和編號(hào)規(guī)范歸檔。
2.保存為特定的格式,文件類型。
3.用例版本是否與當(dāng)前被測(cè)試軟件版本一致(對(duì)應(yīng))。
4.包含用例需要的相應(yīng)測(cè)試對(duì)象,如特定數(shù)據(jù)庫(kù)。
5.存檔閱讀。
6.存檔時(shí)按角色控制訪問(wèn)方式
一、首先測(cè)試需求分析要全面。
測(cè)試需求分析分兩步:1、測(cè)試需求的獲取 需求的來(lái)源:顯式需求:(1)原始需求說(shuō)明書(shū) (2)產(chǎn)品規(guī)格書(shū) (3)軟件需求文檔 (4)有無(wú)繼承性文檔 (5)經(jīng)驗(yàn)庫(kù) (6)通用的協(xié)議規(guī)范 隱式需求:用戶的主觀感受,市場(chǎng)的主流觀點(diǎn),專業(yè)人士的評(píng)價(jià)分析2,需求的分析 ,產(chǎn)生測(cè)試需求文檔 將不同的需求來(lái)源劃分成一個(gè)個(gè)需求點(diǎn),針對(duì)每一點(diǎn)進(jìn)行測(cè)試分析:(1)界定測(cè)試范圍 (2)利用各種測(cè)試設(shè)計(jì)的方法產(chǎn)生測(cè)試點(diǎn) 在測(cè)試方法方面,可做如下注意:其一,分析出口入口。從入口分析,將可能出現(xiàn)的環(huán)境,條件,操作等內(nèi)容分類組合,然后根據(jù)各位測(cè)試達(dá)人的方法進(jìn)行整合,逐一驗(yàn)證。
從出口分析,將可能出現(xiàn)的結(jié)果進(jìn)行統(tǒng)計(jì),根據(jù)結(jié)果的不同追根溯源,再找到不同的操作以及條件等內(nèi)容,統(tǒng)計(jì)成文檔,逐一驗(yàn)證。其二,多種測(cè)試手法的學(xué)習(xí)和使用。
大家可能更多的關(guān)心測(cè)試方法,但是具體操作的手法也是需要注意的。畢竟測(cè)試方法比較容易找到,各位達(dá)人都很熟悉。
如果將每個(gè)人不同的測(cè)試手法總結(jié)出來(lái)并在自己的測(cè)試實(shí)施中加以使用,可能會(huì)收到意想不到的成果。在測(cè)試流程方面,可作如下注意:其一,初期要做好需求分析。
將需求逐漸細(xì)化到小功能點(diǎn),針對(duì)每個(gè)功能點(diǎn)進(jìn)行測(cè)試設(shè)計(jì)。對(duì)于完成的測(cè)試設(shè)計(jì)文檔,經(jīng)過(guò)項(xiàng)目相關(guān)人員的檢查評(píng)審,做成所需要的初稿。
其二,在測(cè)試過(guò)程中,根據(jù)需求變更和具體測(cè)試執(zhí)行過(guò)程中遇到的問(wèn)題完善測(cè)試設(shè)計(jì)文檔。其三,測(cè)試執(zhí)行結(jié)束后,對(duì)于出現(xiàn)的問(wèn)題進(jìn)行總結(jié)。
其中包含自己本身發(fā)現(xiàn)的問(wèn)題,也可能會(huì)有客戶提出的問(wèn)題。將總結(jié)出來(lái)的結(jié)果融合到測(cè)試設(shè)計(jì)當(dāng)中去,進(jìn)一步完善測(cè)試設(shè)計(jì)文檔。
對(duì)于一次測(cè)試,是不可能有覆蓋度全面的測(cè)試的。需要多次去總結(jié)積累,才會(huì)使測(cè)試越來(lái)越全面。
在測(cè)試流思維方面,可作如下注意:其一,測(cè)試全面不等于全面測(cè)試。不同階段對(duì)于軟件測(cè)試有不同的要求,比如在0.8版本以前,對(duì)于不重要的畫(huà)面問(wèn)題或是細(xì)小的功能問(wèn)題就不需要關(guān)心。
但是在驗(yàn)收階段,這些內(nèi)容可能更需要注意。其二,學(xué)無(wú)止境,只有不斷的去學(xué)習(xí)不斷的去思考,才能使自己測(cè)試的能力更強(qiáng),測(cè)試對(duì)象的全面性也更完整。
二、當(dāng)測(cè)試需求分析完成,并且形成文檔后,要進(jìn)行測(cè)試需求評(píng)審,保證需求的準(zhǔn)確性以及完整性。三、測(cè)試需求完成以后,可以根據(jù)測(cè)試需求設(shè)計(jì)測(cè)試用例。
要保證測(cè)試用例能夠全面覆蓋測(cè)試需求,要包含所有的情況。測(cè)試用例設(shè)計(jì)上劃分為單功能測(cè)試用例和測(cè)試場(chǎng)景設(shè)計(jì),單功能測(cè)試覆蓋的需求中的功能點(diǎn),測(cè)試場(chǎng)景覆蓋需求中的業(yè)務(wù)邏輯。
在設(shè)計(jì)測(cè)試用例的時(shí)候,可以使用多種測(cè)試用例設(shè)計(jì)方法。●首先進(jìn)行等價(jià)類劃分,包括輸入條件和輸出條件的等價(jià)類劃分,合理設(shè)置有效等價(jià)類和無(wú)效等價(jià)類,這是減少工作量和提高測(cè)試效率最有效的方法。
● 必須使用邊界值分析,經(jīng)驗(yàn)表明,這種方法設(shè)計(jì)出的用例能發(fā)現(xiàn)很多程序錯(cuò)誤。● 可以使用錯(cuò)誤推測(cè)法追加一些測(cè)試用例,這需要依靠您的智慧和經(jīng)驗(yàn)。
● 對(duì)照程序邏輯檢查已設(shè)計(jì)出的測(cè)試用例的邏輯覆蓋度,如果沒(méi)有達(dá)到覆蓋標(biāo)準(zhǔn)應(yīng)當(dāng)再補(bǔ)充足夠的測(cè)試用例。● 如果程序的功能說(shuō)明中含有輸入條件的組合情況,一開(kāi)始就可選因果圖和判定表驅(qū)動(dòng)法。
●對(duì)于參數(shù)配置類的軟件,要用正交試驗(yàn)法選擇較少的組合方式達(dá)到最佳效果。● 對(duì)于業(yè)務(wù)流清晰的系統(tǒng),可以利用場(chǎng)景法貫穿整個(gè)測(cè)試方案過(guò)程,在案例中綜合使用各種測(cè)試方法。
當(dāng)測(cè)試用例設(shè)計(jì)完成后,要組織測(cè)試用例的評(píng)審,這樣可以吸取別人的意見(jiàn),減少遺漏,補(bǔ)全測(cè)試用例。四、測(cè)試用例編寫(xiě)完成后,就是測(cè)試執(zhí)行,● 測(cè)試用例執(zhí)行100%覆蓋。
●在測(cè)試執(zhí)行過(guò)程中,要繼續(xù)對(duì)測(cè)試用例補(bǔ)充完善,確保提高測(cè)試覆蓋率。五、在整個(gè)測(cè)試過(guò)程中,需求都是不可能不變的,所以要及時(shí)的更新測(cè)試需求、測(cè)試用例。
六、要將測(cè)試需求、測(cè)試用例以及發(fā)現(xiàn)的bug關(guān)聯(lián)起來(lái),便于管理和跟蹤,同時(shí)也便于查看覆蓋率。
聲明:本網(wǎng)站尊重并保護(hù)知識(shí)產(chǎn)權(quán),根據(jù)《信息網(wǎng)絡(luò)傳播權(quán)保護(hù)條例》,如果我們轉(zhuǎn)載的作品侵犯了您的權(quán)利,請(qǐng)?jiān)谝粋€(gè)月內(nèi)通知我們,我們會(huì)及時(shí)刪除。
蜀ICP備2020033479號(hào)-4 Copyright ? 2016 學(xué)習(xí)鳥(niǎo). 頁(yè)面生成時(shí)間:2.619秒