安陽網(wǎng)站制作杭州網(wǎng)站seo價格
1:評審的過程
? ? ? A:開始前做好如下準(zhǔn)備
? ? ? ? ? ? ? ? ? ? 1、確定需要評審的原因
? ? ? ? ? ? ? ? ? ? 2、確定進(jìn)行評審的時機(jī)
? ? ? ? ? ? ? ? ? ? 3、確定參與評審人員
? ? ? ? ? ? ? ? ? ? 4、明確評審的內(nèi)容
? ? ? ? ? ? ? ? ? ? 5、確定評審結(jié)束標(biāo)準(zhǔn)
? ? ? ? ? ? ? ? ? ?6、提前至少一天將需要評審的內(nèi)容以郵件的形式發(fā)送給評審會議相關(guān)人員。并注明詳審時間、地點(diǎn)及償參與人員等。
? ? ? ? ? ? ? ? ? ? 7、 在郵件中提醒評審會議相關(guān)人員至少簡讀一遍評審內(nèi)容,并記錄相關(guān)的疑問,以便在評審會議上提出。
? ? ? ? ? ? ? ? ? ? 8、 會議主持者(一般為用例編寫人員)應(yīng)在會議前整理相關(guān)疑問,以便在會議上提出。
? ? ? ?B:開始評審
? ? ? ? ? ? ? ? ? ? 1、 召開評審會議。與會者在設(shè)計(jì)人員講解之后給出意見和建議,同時進(jìn)行詳細(xì)的評審記錄。
? ? ? ? ? ? ? ? ? ? 2、 通用郵件與相關(guān)人員溝通
? ? ? ? ? ? ? ? ? ? 3、 通用IM工具直接與相關(guān)人員交流
? ? ? ? ? ? ? ? ? ? 4、根據(jù)評審內(nèi)容進(jìn)行評審
2:評審內(nèi)容
? ? ?1、 用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理,是否利于高效對需求進(jìn)行覆蓋。
? ? ? 2、 優(yōu)先極安排是否合理。
? ? ? 3、 是否覆蓋測試需求上的所有功能點(diǎn)。
? ? ? 4、 用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確;期待結(jié)果是否有明顯的驗(yàn)證方法。
? ? ? 5、 是否已經(jīng)刪除了冗余的用例。
? ? ? 6、 是否包含充分的負(fù)面測試用例。充分的定義,如果在這里使用2&8法則,那就是4倍于正面用例的數(shù)量,畢竟一個健壯的軟件,其中80%的代碼都是在“保護(hù)”20%的功能實(shí)現(xiàn)。
? ? ? 7、 是否從用戶層面來設(shè)計(jì)用戶使用場景和使用流程的測試用例。
? ? ? ?8、 是否簡潔,復(fù)用性強(qiáng)。例如,可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。
3:參與評審人員(這里會分為多個級別進(jìn)行評審)
? ? ? ?1、 部門評審,測試部門全體成員參與的評審。
? ? ? ?2、公司評審,這里包括了項(xiàng)目經(jīng)理、需求分析人員、架構(gòu)設(shè)計(jì)人員、開發(fā)人員和測試人員。
? ? ? ?3、 客戶評審,包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見
1、用例評審目的
測試用例評審流程規(guī)范主要為開展測試用例評審工作提供指引,規(guī)范測試用例評審管理工作。
2、測試用例評審流程內(nèi)容
2.1 前提:測試人員編寫完一個完整的功能模塊的測試用例或已完成所有測試用例的編寫;
2.2 流程輸入:A.測試用例;???????? B.需求規(guī)格說明;
2.3 流程輸出:A.問題記錄清單;???? B.測試用例評審報告;
2.4 參與評審人員:項(xiàng)目經(jīng)理、測試負(fù)責(zé)人、測試人員、需求分析人員、架構(gòu)設(shè)計(jì)人員、開發(fā)人員;
2.5 評審方式:
1)召開評審會議。與會者在測試用例編寫人員講解之后給出意見或建議,同時記錄下評審會議記錄;
2)通過郵件、及時通訊工具與相關(guān)人員溝通。
無論采用哪種方式,都應(yīng)該在評審之前事先把需要評審的測試用例相關(guān)文檔以郵件的形式發(fā)給參與評審的相關(guān)人員,同時在郵件中提醒參與評審的相關(guān)人員在評審前查閱一遍評審內(nèi)容,并記錄相關(guān)問題,以便在評審會議上提出,以節(jié)省溝通成本。
2.6 評審用例檢查清單:
1)測試用例是否按照公司定義的模板進(jìn)行編寫的;
2)測試用例的本身的描述是否清晰,是否存在二義性;
3)測試用例內(nèi)容是否正確,是否與需求目標(biāo)相一致;
4)測試用例的期望結(jié)果是否確定、唯一的;
5)操作步驟應(yīng)與描述是否相一致;
6)測試用例是否覆蓋了所有的需求;
7)測試設(shè)計(jì)是否存在冗余性;
8)測試用例是否具有可執(zhí)行性;
9)是否從用戶層面來設(shè)計(jì)用戶使用場景和業(yè)務(wù)流程的測試用例;
10)場景測試用例是否覆蓋最復(fù)雜的業(yè)務(wù)流程;
11)用例設(shè)計(jì)是否包含了正面、反面的用例;
12)對于由系統(tǒng)自動生成的輸出項(xiàng)是否注明了生成規(guī)則;
13)測試用例應(yīng)包含對中間和后臺數(shù)據(jù)的檢查;
14)測試用例應(yīng)有正確的名稱和編號;
15)測試用例應(yīng)標(biāo)注有執(zhí)行的優(yōu)先級;
16)測試用例包含相關(guān)的配置信息:測試環(huán)境、數(shù)據(jù)、前置測試用例、用戶授權(quán)等;
17)每個測試用例步驟應(yīng)<=15 Step;
18)自動化測試腳本必須帶有注釋(注釋應(yīng)包括:目的、輸入、期望結(jié)果等);
19)非功能測試需求或不可測試需求是否在用例中列出并說明?
2.7 退出標(biāo)準(zhǔn):
1)評審過程中收集相關(guān)人員的反饋信息(即問題記錄清單),并在此基礎(chǔ)上進(jìn)行測試用例更新,直到評審?fù)ㄟ^;
2)評審結(jié)束后,測試負(fù)責(zé)人出測試用例評審報告給到相關(guān)人員;
3)評審結(jié)果經(jīng)項(xiàng)目經(jīng)理同意確認(rèn)。
2.8 控制機(jī)制:
采用評審會議時,主持人應(yīng)盡量把握會議進(jìn)度,盡量按時有效的完成評審工作;
附件1:問題記錄清單 附件2:測試用例評審報告
測試用例評審的意義何在:測試用例要符合產(chǎn)品需求,但是產(chǎn)品功能是開發(fā)寫的,開發(fā)實(shí)現(xiàn)的邏輯需要評審溝通,以免有不清楚的邏輯點(diǎn);可以提高測試用例的正確性、提高測試效率;提高測試用例的覆蓋度,更好的發(fā)現(xiàn)BUG。
三、用例評審時間
對于敏捷開發(fā)項(xiàng)目,建議控制在半小時以內(nèi)。
如果你認(rèn)為需求復(fù)雜,功能點(diǎn)太多,半小時講不完,那么建議你對功能點(diǎn)劃分優(yōu)先級,優(yōu)先評審優(yōu)先級高的用例,再針對疑問多的用例評審,最后對于功能簡單的用例可簡單帶過。時刻記住我們用例的評審目標(biāo),不能流于形式。
四、用例評審的形式
1、對照測試用例,從上而下,從左到右,逐條念。
這是目前很多公司的做法,如果你也這么做過,相信你并不一定喜歡這種方式,因?yàn)樗M(fèi)時,不分主次,參會人員的熱情與注意力逐漸降低,整個用例評審效率低,作為主持人也講的口干舌燥,事倍功半。
2、先對功能復(fù)雜,優(yōu)先級高,疑問多的用例進(jìn)行評審,再評審功能簡單,優(yōu)先級低的功能點(diǎn)。
對于評審過程中,一時半會沒有結(jié)論的問題,可以記錄下來,作為會后討論跟進(jìn)的重點(diǎn)。
這種做法,有很多優(yōu)點(diǎn),評審剛開始的一段時間,大家注意力集中,參與激情高,這段時間討論有難度有疑問的問題,效率高。最重要的事最先做。
另外,整個評審會主次分明,有高潮有緩點(diǎn),可以更高效的達(dá)到我們評審的目的。
五、正式評審
正式評審過程中需要注意幾個細(xì)節(jié),如果你都做到了,那么可以說整個評審是成功的,有價值的。
1、評審要按用例的優(yōu)先級,功能的復(fù)雜程度進(jìn)行;
2、評審過程中盡量做到,思路清晰,用最簡潔的語言闡述每一個功能點(diǎn);
3、超過5分鐘無法確定結(jié)果的問題留作會后討論跟進(jìn)。
六、評審結(jié)束后需要做些什么事?
不是說評審會結(jié)束了,就完事了,其實(shí)對于整個用例評審,這才做了一半。? ??
評審結(jié)束后,第一時間整理測試用例,把修正的內(nèi)容重新整理補(bǔ)全。
會上未確定的內(nèi)容,會后繼續(xù)跟進(jìn),直到確定結(jié)果。
沒有任何有疑問的地方了,再做個簡單的用例評審會議總結(jié)(如修正了哪些功能點(diǎn),補(bǔ)全了哪些?哪些模塊功能有變動?哪些功能推遲到下一期做?等),
這個總結(jié)是給自己整個用例評審工作總結(jié),同時需同步給項(xiàng)目組其他成員,做好信息共享,這點(diǎn)很重要。