測試用例編寫規(guī)范說明及模板_第1頁
測試用例編寫規(guī)范說明及模板_第2頁
測試用例編寫規(guī)范說明及模板_第3頁
測試用例編寫規(guī)范說明及模板_第4頁
測試用例編寫規(guī)范說明及模板_第5頁
已閱讀5頁,還剩13頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、部門管理文檔系列*公司測試用例編寫標準及原則擬制 審核 批準修訂歷史記錄版本日期AMD修訂者說明1.0A初稿1.1M(A-添加,M-修改,D-刪除)1. 引言 51.1 背景 51.2 目的 51.3 適用范圍 51.4 縮寫和術(shù)語 52. 測試用例 52.1 概念 52.2 用途 62.3 設(shè)計依據(jù) 62.4 編號規(guī)則 62.5 用例內(nèi)容 62.6 用例設(shè)計方法 72.6.1. 等價類劃分法 72.6.2. 邊界值分析法 82.6.3. 錯誤推測法 82.7 功能性測試方法 82.7.1. 輸入非法數(shù)據(jù) 82.7.2. 輸入默認值 92.7.3. 輸入使緩沖區(qū)溢出的數(shù)據(jù) 92.7.4. 輸出

2、不符合業(yè)務(wù)規(guī)則的無效輸出 92.7.5. 數(shù)據(jù)結(jié)構(gòu)溢出 92.7.6. 文件內(nèi)容受損 92.8 軟件環(huán)境兼容性測試 102.8.1. 與操作系統(tǒng)的兼容性 103. 用例設(shè)計步驟 113.1 用例評審 113.1.1. 評審原因 113.1.2. 評審內(nèi)容 113.1.3. 評審過程 123.1.4. 評審人員 123.1.5. 評審方式 123.1.6. 結(jié)束標準 124. 用例規(guī)范 124.1 編寫用例規(guī)范 124.2 編寫用例標準 134.3 用例實例說明 134.3.1. 字段說明 134.3.2. 用例說明 144.4 用例級別劃分 155. 用例的維護 156. 風險分析 167.

3、測試用例模板 161. 引言1.1善E背景為保證測試用例對需求的覆蓋率,即對一個系統(tǒng)從整體功能到單個功能,都盡可能的高的覆蓋。而單個功能點主要強調(diào)的是不同的輸入及其組合所帶來的各種輸入動作,系統(tǒng)是否都做了處理;測試用例設(shè)計首先要明確該系統(tǒng)存在多少功能點,要通過各種常用的測試方法來保證用例的完整性,然后再對各功能點的邊界范圍進行考慮。所以要保證測試用例的設(shè)計按照一種合理的結(jié)構(gòu)組織進行,這樣才能夠更有效的保證系統(tǒng)所有功能點的覆蓋率。1.2 目的為測試用例的質(zhì)量負責,使測試工作能有序、合理化的進行,從而提高實施測試時對所測產(chǎn)品、系統(tǒng)或者模塊的測試質(zhì)量,也是作為各測試人員在設(shè)計用例時的一種規(guī)范,使之設(shè)

4、計的用例能有效的被管理。1.3 適用范圍本文檔適用于測試人員本文檔適用于X X系統(tǒng)進行測試時的測試案例設(shè)計本文檔適用于X X案例補充時的測試案例1.4 縮寫和術(shù)語無2. 測試用例2.2 概念是指為了實施測試而編寫的一組有規(guī)范性、有據(jù)可依的輸入數(shù)據(jù)與輸出數(shù)據(jù)的組合,也指為了實施測試而向被測對象提供的一組輸入、輸出數(shù)據(jù)以及由各種執(zhí)行條件和期望結(jié)果相組合的一個特定集合,以便測試某個程序路徑或者來核實是否滿足某個特定的需求。2.3 用途指導(dǎo)測試工作有序進行,使實施測試的數(shù)據(jù)有據(jù)可依確保所實現(xiàn)的功能與客戶預(yù)期的需求相符合完善軟件不同版本之間的重復(fù)性測試跟蹤測試進度,確定測試重點評估測試結(jié)果的度量標準增強

5、軟件的可信任度分析缺陷的標準2.4 設(shè)計依據(jù)需求說明書項目測試需求功能點所屬行業(yè)的業(yè)務(wù)知識掌握程度測試工程師本人的理解程度(個人經(jīng)驗)2.5 編號規(guī)則以xx版本.需求一級菜單號.二級菜單號.用例排序為編號規(guī)則,例如: CS.1.1.1以各項目制定的規(guī)范為依據(jù)2.6 用例內(nèi)容用功用標刖用輸預(yù)實問執(zhí)Bug需用測執(zhí)備例能例題置例入期際題行編求例試行注編占八、級概條步數(shù)結(jié)結(jié)描結(jié)號編編執(zhí)日號別述件驟據(jù)果果述果號寫行期者者用例編號:唯一標識,與需求編號對應(yīng),為多對一關(guān)系用例編寫者:設(shè)計用例的人員被測對象:要測試的功能點(模塊、系統(tǒng))用例標題:對測試項簡短的描述用例級別:確定用例執(zhí)行的級別。參考5.4前提條

6、件:執(zhí)行用例時需要的預(yù)置條件輸入條件:執(zhí)行該動作需要輸入的數(shù)據(jù)操作步驟:執(zhí)行該動作需要完成的操作預(yù)期結(jié)果:執(zhí)行完該動作后程序的表現(xiàn)結(jié)果實際結(jié)果:實際輸出的結(jié)果問題描述:執(zhí)行該用例出現(xiàn)后系統(tǒng)顯示的錯誤驗證結(jié)果:該測試用例是否執(zhí)行通過BUG 編號:填寫 BUGBASE 中對應(yīng)此用例的 BUG 編號需求編號:唯一標識,與用例編號對應(yīng),為一對多關(guān)系測試執(zhí)行者:按照該用例執(zhí)行測試的人員測試日期:執(zhí)行測試的時間備注:對未執(zhí)行或不能進行執(zhí)行的用例進行說明2.7 用例設(shè)計方法2.7.1. 等價類劃分法1) 概念是一種最典型的黑盒測試方法,它完全不考慮程序的內(nèi)部結(jié)構(gòu),而是只根據(jù)對程序的要求和說明進行測試用例的設(shè)

7、計。測試人員要求對需求說明書中的各項功能需求進行細致分析,把程序的輸入域劃分成若干個部分,然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例,經(jīng)過這種劃分后,每一類的代表性數(shù)據(jù)在測試中的作用都等價于這一類中的其他值。2) 分類有效等價類:是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合無效等價類:是指對程序的規(guī)格說明來說是不合理的、無意義的輸入數(shù)據(jù)構(gòu)成的集合3) 步驟從需求說明書中找出各個輸入條件對找出的每個輸入條件劃分兩個或兩個以上的等價類4) 方法在輸入條件規(guī)定了取值范圍或值的個數(shù)時,可以確定一個有效等價類和兩個無效等價類在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件情

8、況下,可以確定一個有效等價類和一個無效等價類在輸入條件是一個布爾量時,可以確定一個有效等價類和一個無效等價類在規(guī)定了輸入數(shù)據(jù)的一組值(假定 n 個) ,并且程序要求對每一個輸入值分別處理的情況下,可確定 n 個有效等價類和一個無效等價類2.7.2. 邊界值分析法是等價類測試的特例,主要考慮等價類的邊界條件,在等價類的邊緣處選擇元素,是指輸入和輸出的等價類中那些恰好處在邊界,恰好超過邊界或恰好在邊界以內(nèi)的數(shù)據(jù)集合組成的用例。對邊界值設(shè)計測試用例原則:如果輸入條件規(guī)定了值的范圍,則應(yīng)取剛達到這個范圍的邊界的值,以及剛剛超出這個范圍邊界的值作為測試輸入數(shù)據(jù)如果輸入條件規(guī)定了值的個數(shù),則用最大個數(shù)、最

9、小個數(shù)、比最小個數(shù)小 1 、比最大個數(shù)多 1 的數(shù)作為測試數(shù)據(jù)如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合,則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu),則應(yīng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)邊界上的值作為測試用例分析規(guī)格說明,找出其他可能的邊界條件2.7.3. 錯誤推測法是根據(jù)經(jīng)驗和直覺設(shè)計測試用例。其思想是:如某處發(fā)現(xiàn)了缺陷,則該處可能會隱藏更多的缺陷,在實際操作中,列出程序中所有可能的錯誤和容易發(fā)生的特殊情況,然后依據(jù)測試者經(jīng)驗作出選擇;而該用例設(shè)計方法不是一個系統(tǒng)的測試方法,只是作為輔助手段,其優(yōu)點是測試者能快速且容易的切入,并能體會到程序的易用與否,缺點是

10、難以知道測試的覆蓋率,可能丟失大量的未知區(qū)域。2.8 功能性測試方法2.8.1. 輸入非法數(shù)據(jù)處理非法數(shù)據(jù)的方法:防止不正確的輸入進入被測軟件輸入了不正確的數(shù)據(jù)后,軟件提示錯誤信息,拒絕不正確輸入允許不正確的輸入進入系統(tǒng)并處理,軟件失效時調(diào)用異常處理程序測試的方法:輸入數(shù)據(jù)的類型 輸入數(shù)據(jù)的長度輸入數(shù)據(jù)邊界值2.8.2. 輸入默認值測試方法:接收軟件顯示的默認值 鍵入空值 將默認值改為另一個值,這樣會使應(yīng)用程序以不同值來允許 將默認值改為另一個值,然后再變?yōu)榭罩?.8.3. 輸入使緩沖區(qū)溢出的數(shù)據(jù)測試方法:弄清楚測試的輸入域長度,輸入最大字符串測試輸入一個比最大字符串更長的字符串2.8.4.

11、輸出不符合業(yè)務(wù)規(guī)則的無效輸出測試方法:列出所有無效輸出,然后逐一測試熟悉業(yè)務(wù)規(guī)則及行業(yè)背景知識(如日期、時間、金額等小數(shù)問題)2.8.5. 數(shù)據(jù)結(jié)構(gòu)溢出所有數(shù)據(jù)結(jié)構(gòu)的大小都有上限,開發(fā)人員經(jīng)常對有關(guān)數(shù)據(jù)結(jié)構(gòu)的內(nèi)容進行編碼,忘記結(jié)構(gòu)本身的物理局限。測試方法:嘗試將過多的值輸入數(shù)據(jù)結(jié)構(gòu),測試上溢 嘗試多刪除一個數(shù)據(jù),測試下溢 全面理解需求文檔,確定數(shù)據(jù)結(jié)構(gòu)的界限2.8.6. 文件內(nèi)容受損當文件上傳時,需要對上傳文件的類型及內(nèi)容進行測試測試方法:上傳不同類型的文件,檢查系統(tǒng)怎樣處理上傳內(nèi)容受損的文件,檢查系統(tǒng)怎樣處理上傳不同路徑的文件,檢查系統(tǒng)怎樣處理2.9 軟件環(huán)境兼容性測試2.9.1. 與操作系

12、統(tǒng)的兼容性操作系統(tǒng)的兼容性測試內(nèi)容不僅包括軟件的安裝,還需對關(guān)鍵流程和功能點進行檢查。而需要測試哪些操作系統(tǒng)的兼容性,首先取決于軟件用戶文檔上對用戶的承諾,其次就需要對一些常用操作系統(tǒng)兼容的檢查。手機操作系統(tǒng)包括WAP 版及 CS 版WAP 版:AndroidiPhone OSLinuxLinux Smartphone OSMymobilePalm OSRIM OSSymbian OSwebOSWindows Mobile OSCS 版:iPhone OSLinuxLinux Smartphone OSRIM OSSymbian OSWindows Mobile OSB/S系統(tǒng)兼容的瀏覽器為i

13、e6、IE7、IE8、火狐2、火狐3C/S 或 B/S 系統(tǒng) 兼容操作系統(tǒng)windows XP 、 windows2000 、 windows2003 、 windows7 等等3. 用例設(shè)計步驟測試需求分析: 從軟件需求分析文檔中, 找出待測軟件/模塊的需求,通過自己的分析、理解,整理成為測試需求,要清楚被測對象具體包含哪些功能點業(yè)務(wù)流程分析:對所在行業(yè)的業(yè)務(wù)知識要熟悉,然后對被測軟件/模塊的業(yè)務(wù)流程要進行全盤的整理出來(可畫簡單的流程圖作為參考) ,主要包含該業(yè)務(wù)流程的主流程、備選流程、數(shù)據(jù)流向、關(guān)鍵判斷條件以及完成該操作的非必要條件測試用例設(shè)計:測試用例設(shè)計的類型主要包括功能測試、邊界測

14、試、異常測試、性能測試、壓力測試等,在設(shè)計用例時要盡量考慮邊界、異常等情況測試用例評審:由測試用例設(shè)計者發(fā)起,參加的人員需包括測試負責人、項目經(jīng)理、開發(fā)人員及其他相關(guān)的測試人員測試用例完善:測試用例編寫完成之后需不斷完善,軟件產(chǎn)品新增功能或更新需求后,測試用例必須配套修改更新;在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周,需要對測試用例進行修改完善;在軟件交付使用后客戶反饋的軟件缺陷,而缺陷又是因測試用例存在漏洞造成,也需要對測試用例進行完善3.2 用例評審3.2.1. 評審原因測試用例是軟件測試的原則,但由于軟件人員對在需求理解、設(shè)計等理解程度不同等因素的影響,首次產(chǎn)生的測試用例質(zhì)量難以避免會有不

15、同程度的差異,故對編寫的測試用例進行評審是很有必要的,其作用是測試用例的評審過程能夠起到用例結(jié)構(gòu)清晰化、場景覆蓋全面化以及優(yōu)先用例的合理化安排等。3.2.2. 評審內(nèi)容用例設(shè)計的結(jié)構(gòu)安排是否清晰合理,是否高效的需求進行覆蓋用例的優(yōu)先級別是否安排合理是否覆蓋了測試需求的所有功能點,包括需求中的業(yè)務(wù)規(guī)則、所有用戶可能使用的流程或場景等用例是否有很好的可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確是否已經(jīng)刪除了冗余的測試用例是否包含充分的負面測試用例是否簡潔、復(fù)用性強是否易于管理3.2.3. 評審過程基于項目需求的測試計劃完成之后,進行初審,主要是對測試范圍和測試要點進行審

16、查在測試用例的設(shè)計完成之后進行復(fù)審,主要是對測試用例的結(jié)構(gòu)和覆蓋率進行評審所有測試用例結(jié)束后,主要是對測試用例的具體描述是否有很好的可執(zhí)行性,是否有冗余用例的存在進行評審3.2.4. 評審人員部門評審:測試部全體成員參與的評審項目評審:項目組全體測試人員與部分開發(fā)人員、需求人員等組成的小組公司評審:包括項目經(jīng)理、需求分析人員、開發(fā)人員、測試人員客戶評審:包括客戶方的開發(fā)人員和測試人員內(nèi)部評審:全部參與測試的人員3.2.5. 評審方式會議評審(包括內(nèi)部評審及客戶評審) 。由設(shè)計該用例的人員進行講解,參與會議評審的相關(guān)人員給出意見或建議,并記錄評審的意見和建議其他類形式。非正式的評審,話聊、主動請

17、教周邊同事等3.2.6. 結(jié)束標準經(jīng)評審的用例由用例設(shè)計者根據(jù)評審的建議或意見進行修改,更新用例,再次發(fā)起評審、修改、更新用例,反復(fù)評審后,直至用例達到要求。 (反復(fù)評審時存在時間問題)4. 用例規(guī)范4.2 編寫用例規(guī)范系統(tǒng)性。對系統(tǒng)業(yè)務(wù)流程要完整說明整個系統(tǒng)的業(yè)務(wù)需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關(guān)系;對模塊業(yè)務(wù)流程要說明子系統(tǒng)內(nèi)部功能、重點功能以及它們之間的關(guān)系連貫性。對系統(tǒng)業(yè)務(wù)流程要說明各個子系統(tǒng)之間是如何連接在一起,若需要接口,各子系統(tǒng)之間是否有正確的接口,若是依靠頁面鏈接,則頁面的鏈接是否正確;對模塊業(yè)務(wù)流程要說明同級模塊以及上下級模塊是如何構(gòu)成一個子系統(tǒng),其內(nèi)部功能接口是否連

18、貫 全面性。應(yīng)盡可能覆蓋各種路徑、盡可能覆蓋各個業(yè)務(wù)點,并要考慮跨年、跨月的數(shù)據(jù)以及大數(shù)據(jù)量并發(fā)測試的準備正確性。輸入界面后的數(shù)據(jù)應(yīng)與測試文檔所記錄的數(shù)據(jù)一致,而預(yù)期結(jié)果也應(yīng)與測試數(shù)據(jù)發(fā)生的業(yè)務(wù)吻合符合正常業(yè)務(wù)規(guī)則。測試數(shù)據(jù)要符合用戶實際工作中的業(yè)務(wù)流程,同時也要兼顧各種業(yè)務(wù)的變化以及當前該業(yè)務(wù)行業(yè)的法律、法規(guī)可操作性。測試用例中要寫清楚測試的操作步驟,以及不同的操作步驟相對應(yīng)的測試結(jié)果4.3 編寫用例標準測試案例編寫應(yīng)該制訂統(tǒng)一的模板進行,并約定模板的使用方法;測試案例編寫應(yīng)當根據(jù)項目實際情況編寫測試案例編寫手冊,包括案例編號規(guī)則、案例編寫方法、案例編寫內(nèi)容、案例維護等內(nèi)容;案例編寫應(yīng)根據(jù)手

19、冊中約定的編寫方法、內(nèi)容等進行編寫;案例編寫要步驟明確,輸入輸出要素清晰,并且與需求和缺陷相對應(yīng);案例編寫應(yīng)嚴格根據(jù)需求規(guī)格說明書及測試需求功能分析點進行,要求覆蓋全部需求功能八、,注重案例的可復(fù)用性,即在以后相似系統(tǒng)的測試過程中可以重復(fù)使用,減少測試設(shè)計工作量。4.4 用例實例說明4.4.1. 字段說明序號功能點用例總 數(shù)結(jié)果Y結(jié)果N結(jié)果H執(zhí)行率Y%N%H%編寫人執(zhí)行人備注1登錄2首頁3賬戶管理4轉(zhuǎn)帳匯款5網(wǎng)上支付6網(wǎng)上催款總計功能點:按照系統(tǒng)一級菜單名稱列出整個系統(tǒng)的大功能點,功能點順序與系統(tǒng)菜單順序相符結(jié)果為Y:表示用例執(zhí)行通過,軟件實現(xiàn)的功能與用例描述相符結(jié)果為N:用例執(zhí)行不通過,軟件

20、功能與用例描述不相符,軟件功能錯誤結(jié)果為 H :用例暫不執(zhí)行,現(xiàn)有軟件暫不能達到該條用例的執(zhí)行條件編寫人:編寫該功能點測試用例的人員姓名執(zhí)行人:執(zhí)行該功能點測試用例的人員姓名備注:當此模塊無法完成測試,或該模塊被刪除時,在備注中填寫無法完成此功能測試的原因或不能進行測試的原因4.4.2. 用例說明Sheet表:每個一級菜單為一個單獨的sheet表,每個sheet表中包含此一級菜單下所有二級菜單及功能點二級菜單命名規(guī)則:菜單序號二級菜單名稱序號編寫規(guī)則:以手機版本.需求一級菜單號.二級菜單號.用例排序為編號規(guī)則用例步驟1) 編寫完整的測試用例步驟2) 列出必要的前提條件3) 列出明確的輸入數(shù)據(jù)4

21、) 語言表達清晰明確預(yù)期輸出1) 測試結(jié)果的可判定性,即測試執(zhí)行結(jié)果的正確性是可判定的,每一個測試用例都應(yīng)有相應(yīng)的期望結(jié)果2) 測試結(jié)果的可再現(xiàn)性,即對同樣的測試用例,系統(tǒng)的執(zhí)行結(jié)果應(yīng)當是相同的編寫測試用例順序1) 驗證整體頁面的元素2) 驗證各個功能點,包括文本框、鏈接、按鈕等(注:按照頁面從上而下,從左至右的順序驗證)3) 驗證業(yè)務(wù)流程測試用例填寫規(guī)范1) 當驗證結(jié)果為Y 時,需要填寫需求編號、測試人和測試日期項2) 當驗證結(jié)果為N 時,需要填寫問題描述(描述由此用例測試出的BUG ) 、 BUG 編號(提交到缺陷管理工具的 BUG 編號) 、需求編號、測試人和測試日期項3) 當驗證結(jié)果為

22、 H 時,需要填寫測試人、測試日期、需求編號和備注(備注信息填寫 Hold 原因或由于某個BUG 影響而無法進行測試)4) 4. 用例級別劃分目的:保證所設(shè)計的用例在實施測試時真正起到指導(dǎo)作用突出測試的重點,可以有針對性的實施測試對測試用例進行優(yōu)先級的劃分,一般需要從三個方面考慮:P1:確保系統(tǒng)基本功能及主要功能的測試用例P2:確保系統(tǒng)功能的完善方面的測試用例P3:關(guān)于用戶體驗,輸入輸出的驗證以及其他較少使用或輔助功能的測試用例對應(yīng)的,我們可以對測試用例分為三個級別:高、中、低高(優(yōu)先執(zhí)行) :即關(guān)鍵路徑的測試用例,包括最常執(zhí)行的功能、基本流程的輸入以及界面數(shù)據(jù)有效性校驗作為高級別的測試用例;

23、若該級別的測試用例完全執(zhí)行通過,則表示該軟件功能漸趨穩(wěn)土定;中(次級執(zhí)行) :即可接收級測試的用例,包括不常執(zhí)行的功能、異常流程的輸入、邊界值以及異常數(shù)據(jù)的輸入作為中等級別的測試用例;若該級別的測試用例完全執(zhí)行通過,則表示該軟件可以進行發(fā)布了;低(最后執(zhí)行) :即建議執(zhí)行的測試用例,也就是說該級別的測試用例不是不重要,而是該級別的用例在整個項目的生命周期內(nèi)不是常常被運行,包括: GUI 、界面顯示、錯誤信息提示不統(tǒng)一、可用性、壓力和性能測試等。備注:對已有的用例級別說明,包括 A-正常流程測試、B-異常流程測試、C-頁面元素正常輸入測試、D-頁面元素異常輸入測試、E-頁面元素顯示測試,可具體歸

24、類如下(僅供參考) :高:A-正常流程測試、C-頁面元素正常輸入測試中:B-異常流程測試、D-頁面元素異常輸入測試低: E- 頁面元素顯示測試5 . 用例的維護刪除過時的測試用例 因為需求的改變等原因可能會使一個基線測試用例不再適合被測系統(tǒng),那么這些測試用例 就會過時,需要對這些測試用例進行及時的刪除,在刪除過程中,不能夠?qū)⒄械臏y試用 例刪除,應(yīng)該將要刪除的測試用例整行置灰,并將該行的用例計數(shù)器清為空;當整個功能 模塊需要刪除時,則將整個 SHEET狀態(tài)置灰,并將用例計數(shù)器清空修改的測試用例隨著軟件項目的進展,測試需求可能會有部分變更,甚至大范圍的變更,這個時候我們就會根據(jù)需求的變化相應(yīng)的對

25、測試用例進行維護,修改已經(jīng)不符合目前需求的內(nèi)容,并在備注欄中加以說明刪除冗余的測試用例如果存在兩個或更多測試用例對一組相同的輸入和輸入進行測試,則需要對其進行刪除,只需留下其中的一個增添新的測試用例對新增的功能、在評審過程及測試過程中發(fā)現(xiàn)缺少測試用例或者系統(tǒng)出現(xiàn)BUG但是沒有與之對應(yīng)的測試用例,需要按照測試用例的設(shè)計標準進行增添,增加測試用例時,需要在相應(yīng)功能模塊的最下方插入新增的測試用例,并在備注欄中加以說明6 .風險分析沒有正式需求的測試用例。用例編寫進度跟不上項目進度用例的評審只是走形式需求變更后未及時通知測試人員測試人員后期加入項目,對需求了解不透徹7 .測試用例模板測試用例根據(jù)以下模板進行填寫用例ID考勤_1_1_1用例名稱門禁權(quán)限變更管埋流程1測試目的驗證門禁權(quán)限

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論