思路|產(chǎn)品新人應(yīng)如何撰寫測試用例(功能性測試)
![](http://image.woshipm.com/wp-files/img/49.jpg)
如果你在大公司,那么恭喜你,你很幸福。因?yàn)槟阒恍枰獙懞卯a(chǎn)品需求文檔就好了。但如果你恰恰在一個(gè)創(chuàng)業(yè)公司,那么你很可能要擔(dān)負(fù)器撰寫測試用例的重?fù)?dān)。那么,作為產(chǎn)品新人的你,該如何撰寫測試用例呢?
事先聲明,本文是給產(chǎn)品新人的一個(gè)指導(dǎo)方向,如果你是測試大牛,那更希望你能弄出一篇完整的教程來。
既然你公司沒有測試,那么作為產(chǎn)品汪,自然就得擔(dān)負(fù)起產(chǎn)品測試重責(zé)。
一、產(chǎn)品測試的意義
一個(gè)完整的開發(fā)流程。從提需求、開發(fā)、交付。這中間都應(yīng)該有個(gè)結(jié)果。就如你做一件事,得有個(gè)東西來判斷你是否已經(jīng)完成了這件事。那么測試結(jié)果就是這個(gè)東西了。
一般情況下,在開需求評審會議時(shí)同時(shí)會把測試需求列明,以確保產(chǎn)品按質(zhì)量上線。
二、測試文檔的結(jié)構(gòu)
一般情況下,測試文檔主要分兩個(gè)部分。即:非功能性測試需求、功能性測試需求。
所謂非功能性測試,主要指APP運(yùn)行時(shí)在各種環(huán)境下是否能正常運(yùn)行,而功能性測試是指每個(gè)具體功能是否按要求運(yùn)行。
作為產(chǎn)品新人,測試文檔也不需要太復(fù)雜,直接使用excel編撰就可以了,請看下圖:
上圖是我剛剛編寫的,直接寫了一個(gè)簡單的注冊登錄模塊下的賬號密碼登錄部分測試用例。
一般情況下,功能性測試文檔直接使用該模板就能滿足大部分的需求。
三、具體編寫方法
在編寫測試用例之前,你得想好有哪些前置條件。這些前置條件滿足了才能達(dá)到你得預(yù)期。比如賬號密碼登錄,前置條件時(shí)賬號和密碼同時(shí)正確才能正常登錄成功。那么此時(shí)你就得編寫條件不符的時(shí)候,是否也會成功。如果成功了,那就屬于BUG,需要技術(shù)進(jìn)行修復(fù)。
一般正常情況,請考慮一下幾個(gè)方面:
- 頁面布局是否合理,如導(dǎo)航欄上面應(yīng)該顯示三個(gè)按鈕,實(shí)際上卻顯示了兩行。
- 頁面文字描述是否準(zhǔn)確,如氣泡提示:密碼格式錯誤,請重新輸入。實(shí)際上卻顯示:賬號密碼錯誤。
- 如果有加載規(guī)則,是否符合加載規(guī)則。如:進(jìn)入頁面加載20條內(nèi)容,實(shí)際上卻加載了10條。
- 如果有排列規(guī)則,是否符合排列規(guī)則。如應(yīng)按照時(shí)間倒序排列,實(shí)際上卻是正序排列。
- 操作是否符合要求,如單擊某個(gè)點(diǎn),是否準(zhǔn)確跳轉(zhuǎn)或顯示內(nèi)容。如本應(yīng)該進(jìn)行跳轉(zhuǎn),實(shí)際上卻未進(jìn)行跳轉(zhuǎn)。
- 輸入框輸入的內(nèi)容是否有符合格式要求。如:賬號不允許”,”,而實(shí)際上卻允許了。
- 輸入的內(nèi)容是否符合合法性要求。如:賬號密碼是否一致等問題。
- ……
這些基本考慮內(nèi)容都需要考慮進(jìn)來。
大概理清楚需要考慮的內(nèi)容之后,就可以開始動手寫了。
- 序號: 不用說,就是按順序下去的。
- 模塊:該功能點(diǎn)具體屬于哪個(gè)模塊的,填寫這個(gè)主要是方便查找,如:注冊/登錄模塊
- 編號:對每個(gè)用例進(jìn)行編號,方便后期跟進(jìn)。畢竟用文字說,容易口誤。不過此處建議編號設(shè)計(jì)的有點(diǎn)規(guī)則,方便快速定位查找。如:A0001。其中A表示注冊/登錄模塊。00表示賬號登錄,01 表示賬號密碼登錄下的第一個(gè)測試用例。
- 功能點(diǎn):具體指某個(gè)功能,如:賬號登錄、首頁、發(fā)布等。
- 子功能點(diǎn):具體指功能點(diǎn),如:賬號密碼登錄、手機(jī)驗(yàn)證碼登錄、郵箱登錄、第三方授權(quán)登錄等。
- 用例名稱:具體測試用例的名稱。如:輸入賬號、輸入密碼、密碼不合規(guī)等等。
- 前置條件:指要達(dá)到預(yù)期測試結(jié)果,需要滿足那些條件才能達(dá)到。如:賬號密碼不一致時(shí),就需要登錄失敗,那么此時(shí)就得保
證賬號正確或密碼正確以及賬號正確時(shí)是存在的。 - 操作步驟:指要達(dá)到預(yù)期測試結(jié)果,需要按這些步驟來。最好說明在什么頁面,點(diǎn)擊或操作什么內(nèi)容,輸入什么內(nèi)容。
- 預(yù)期結(jié)果:說明按照前面寫的應(yīng)該呈現(xiàn)出怎樣的結(jié)果。
- 測試結(jié)果:如果符合預(yù)期結(jié)果,直接填寫正?;騉K,如果不符合,則說明不符合或NO,
- 結(jié)果描述:如果正常,可以不用填寫,如果不符合預(yù)期結(jié)果,則說明哪里不符合。
- 測試人員:填寫測試人的名字,方便后期跟蹤BUG。
- 測試日期:填寫測試的時(shí)間,方便后期查詢。
- BUGID:跟測試編號一樣,自己設(shè)定ID規(guī)則,方便快速查詢。
- BUG負(fù)責(zé)人:此處應(yīng)該有技術(shù)那邊填寫,具體落實(shí)到某個(gè)人身上,才能更好的解決到問題。
以上就是測試用例的具體填寫方法及作用。測試完了之后,記得進(jìn)行回歸測試以確保測試的意義。
如果你對我寫的這個(gè)感興趣,那么就期待我的下篇文章吧,下次認(rèn)真說下非功能性測試怎么弄。
本文由 @光點(diǎn)神奇?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
這是把產(chǎn)品當(dāng)狗使喚了唄?代碼我給研發(fā)碼好,測試用例寫好,原型圖出全真的,運(yùn)營方案也寫好,埋點(diǎn)寫好,數(shù)據(jù)分析也做了,其他人領(lǐng)工資不就行了唄
今天研發(fā)剛給我說讓我寫測試用例
這個(gè)確實(shí)是不該了
不會寫測試用例、碼代碼、設(shè)計(jì)效果圖、設(shè)計(jì)宣傳頁、賣東西、做PPT的產(chǎn)品經(jīng)理不是好產(chǎn)品經(jīng)理
天吶,太真實(shí)了
流程圖
圖不清楚啊,大佬
如果您具備系統(tǒng)產(chǎn)品知識技能,
有一套體系化的個(gè)人項(xiàng)目作品,
您覺得,工作和求職,是否會更加地順暢?
想體系化學(xué)習(xí)訓(xùn)練,看公開課點(diǎn)這里:?http://996.pm/7GVQ4
A0008-“賬號密碼不合法驗(yàn)證-賬號錯誤”測試中,預(yù)期結(jié)果提示有誤。系統(tǒng)怎么會判斷賬號錯誤呢?系統(tǒng)也不會通過密碼來反推賬號是否正確。所以,用戶端實(shí)際操作是“錯誤賬號,正確密碼”,而系統(tǒng)判斷只有兩種情況:1、賬號不存在時(shí)提示“賬號不存在”;2、賬號存在時(shí)提示“密碼錯誤,登錄失敗”
他這里是賬號不合法密碼正確,所以提示的該是“賬號格式錯誤”,而不是“賬號錯誤”,大約作者忽略了這倆字吧
請問一下正常走向產(chǎn)品需要給測試人員什么資料呢?我們公司的測試同事要產(chǎn)品提供測試用例(測試內(nèi)容,操作,預(yù)期效果),感覺工作量堪比需求文檔
很多人會吧測試用例寫在PRD里面,但是我覺得還是一張表格就差不多了,測試功能項(xiàng)目,前置條件,測試步驟,以及其他的一些日期項(xiàng)目名稱,等基本信息,表格可以請你們測試在后期幫你完善,這樣你的目的能達(dá)到,測試也會把自己的方式幫你豐富表格,一舉兩得 ??
12345
最近在走測試流程,公司有專業(yè)的測試人員,不用產(chǎn)品做測試用例,實(shí)際本來也不是產(chǎn)品的工作,通過測試人員的測試,還是發(fā)現(xiàn)了不少問題,專業(yè)的測試還是不能少的
正好需要,受教,感謝
您好,作者描述的很詳細(xì),本人在一家小公司,偶爾會負(fù)責(zé)到測試的內(nèi)容,原來正規(guī)的測試案例需要描述的如此詳細(xì),學(xué)習(xí)了很多,特別感謝!
有幾點(diǎn)小疑問,還請指教。
1.用例A0006中為什么賬號正確密碼也正確氣泡卻顯示該賬號不存在呢?
2.在文中描述的情況下,若賬號密碼均錯誤,氣泡該如何顯示?是顯示請輸入正確賬號,賬號不存在還是密碼錯誤呢?
3.測試登錄過程中,賬號密碼輸入格式方面是否需要增加如下異常情況的分類:a.賬號輸入非數(shù)字(此處若設(shè)置只允許數(shù)字輸入的限制,且如若賬號為手機(jī)號設(shè)置為首字符為1,可忽略);b.賬號和密碼輸入多位字符數(shù)(此處若設(shè)置字符數(shù)的限制,可忽略);c.密碼輸入特殊字符是否能照常登錄
帳號格式正確,不代表帳號正確吧。
我們沒有測試用例 直接手工測試記錄bug,測試時(shí)能想到什么測什么,業(yè)務(wù)流程能下來就是OK了
業(yè)務(wù)流程一般有很多交叉情況,你這樣會漏掉很多東西的。
產(chǎn)品是最后要什么都懂,不是什么都干,測試用例都要產(chǎn)品寫,想當(dāng)然也是讓產(chǎn)品測,一個(gè)產(chǎn)品的專業(yè)測試流程走下來是很費(fèi)時(shí)間的,而一個(gè)好的測試不僅僅是排除bug也會對產(chǎn)品有積極的建議,公司如果不重視測試可想而知做出來的產(chǎn)品多么粗糙
就一個(gè)項(xiàng)目來講,產(chǎn)品經(jīng)理是第一梯隊(duì),對產(chǎn)品的理解和要求是接近最準(zhǔn)確的,越是業(yè)務(wù)越復(fù)雜的,越需要一個(gè)優(yōu)秀的產(chǎn)品經(jīng)理寫出完善的測試用例。
寫完用例后,不一定非要產(chǎn)品測,制定者不一定是執(zhí)行者,可以安排測試人員,按照產(chǎn)品寫的用例去執(zhí)行和完善。
來過,受教,感謝
A007期望結(jié)果返回首頁應(yīng)該沒有吧
有點(diǎn)像接口的測試哈哈
非常感謝,感覺難點(diǎn)就是要將前置條件考慮全面,沒想到一個(gè)登錄就有這么多測試用例
學(xué)習(xí)了,非常感謝樓主,點(diǎn)99個(gè)贊! ??
有點(diǎn)小疑惑:用例A0008,賬號錯誤我理解只可能是賬號不存在(或是賬號格式錯誤,其實(shí)也是不存在),是不是和前面兩個(gè)case重復(fù)了呢。 ?
給你點(diǎn)個(gè)贊,說明你認(rèn)真看了。這個(gè)case是有錯誤,不過不是你說的錯誤,應(yīng)該是輸入錯誤的賬號,我寫成了輸入正確的賬號了。
這里的情況是這樣的:用戶輸入錯誤的賬號不代表這個(gè)賬號就不存在。比如A用戶的賬號是123,B用戶的賬號是124。但是用戶B把賬號輸入成:123了。密碼正確,這個(gè)時(shí)候就是這個(gè)case了。
這個(gè)時(shí)候系統(tǒng)應(yīng)該會判斷是A在登錄,然后提示密碼錯誤 ??
我也覺得
??
期待樓主的下一篇非功能測試
給樓主點(diǎn)個(gè)贊!
樓主你好!請教一個(gè)問題:你的測試用例表格中,是否還需要一項(xiàng)“輸入數(shù)據(jù)”?
我只想說,產(chǎn)品還要寫測試用例的公司~ 還是別干了吧~ 這個(gè)都省了~公司很難做起來~ 基本上斷定是個(gè) 大坑
說的很有道理,但是像這樣的公司還有一大堆。并不是每一個(gè)公司都有測試專員的。。
我公司就沒正經(jīng)測試,所以做出來的東西非常粗糙,這就是不重視的結(jié)果,直接降低了最終產(chǎn)品質(zhì)量。
?
想起了我第一家公司,才20幾個(gè)人的時(shí)候就已經(jīng)招了測試專員……而現(xiàn)在這家……
同感
非常基礎(chǔ)的文章
期待下一篇文章
哈哈,我們的測試用例基本差不多哈,我覺得應(yīng)該考慮一個(gè)情況:一個(gè)完整的功能性測試的用例需要盡可能的覆蓋所有的情況,所以會很長很長,一次測下來費(fèi)時(shí)費(fèi)力。但是可能由于版本迭代有點(diǎn)快,或者其他原因,不可能每次都測。這時(shí)候需要兩個(gè)維度去測試:1、去測有變動的模塊 2、類似冒煙測試,把每個(gè)模塊的核心環(huán)節(jié)中的主要場景測一下,發(fā)生概率小的或者次要的可以不測。
綜上(說了一堆廢話,哈哈),我的建議是:給測試用例也分個(gè)優(yōu)先級,重要的必須每次都測,不重要的視情況而定
嗯,是的,這些需要跟實(shí)際情況相機(jī)處理,除非是大公司,小公司一般都很少天天測全部功能??????
但我們公司會出現(xiàn)這樣的情況,:改了一個(gè)bug,其他已經(jīng)測試通過的功能又出現(xiàn)了bug;所以結(jié)果就是改一個(gè)bug,就全部要重測一遍
這就是最可怕的狀況了。。。