思路|產品新人應如何撰寫測試用例(功能性測試)

46 評論 154289 瀏覽 1080 收藏 7 分鐘

如果你在大公司,那么恭喜你,你很幸福。因為你只需要寫好產品需求文檔就好了。但如果你恰恰在一個創業公司,那么你很可能要擔負器撰寫測試用例的重擔。那么,作為產品新人的你,該如何撰寫測試用例呢?

事先聲明,本文是給產品新人的一個指導方向,如果你是測試大牛,那更希望你能弄出一篇完整的教程來。

既然你公司沒有測試,那么作為產品汪,自然就得擔負起產品測試重責。

一、產品測試的意義

一個完整的開發流程。從提需求、開發、交付。這中間都應該有個結果。就如你做一件事,得有個東西來判斷你是否已經完成了這件事。那么測試結果就是這個東西了。

一般情況下,在開需求評審會議時同時會把測試需求列明,以確保產品按質量上線。

二、測試文檔的結構

一般情況下,測試文檔主要分兩個部分。即:非功能性測試需求、功能性測試需求。

所謂非功能性測試,主要指APP運行時在各種環境下是否能正常運行,而功能性測試是指每個具體功能是否按要求運行。

作為產品新人,測試文檔也不需要太復雜,直接使用excel編撰就可以了,請看下圖:

上圖是我剛剛編寫的,直接寫了一個簡單的注冊登錄模塊下的賬號密碼登錄部分測試用例。

一般情況下,功能性測試文檔直接使用該模板就能滿足大部分的需求。

三、具體編寫方法

在編寫測試用例之前,你得想好有哪些前置條件。這些前置條件滿足了才能達到你得預期。比如賬號密碼登錄,前置條件時賬號和密碼同時正確才能正常登錄成功。那么此時你就得編寫條件不符的時候,是否也會成功。如果成功了,那就屬于BUG,需要技術進行修復。

一般正常情況,請考慮一下幾個方面:

  1. 頁面布局是否合理,如導航欄上面應該顯示三個按鈕,實際上卻顯示了兩行。
  2. 頁面文字描述是否準確,如氣泡提示:密碼格式錯誤,請重新輸入。實際上卻顯示:賬號密碼錯誤。
  3. 如果有加載規則,是否符合加載規則。如:進入頁面加載20條內容,實際上卻加載了10條。
  4. 如果有排列規則,是否符合排列規則。如應按照時間倒序排列,實際上卻是正序排列。
  5. 操作是否符合要求,如單擊某個點,是否準確跳轉或顯示內容。如本應該進行跳轉,實際上卻未進行跳轉。
  6. 輸入框輸入的內容是否有符合格式要求。如:賬號不允許”,”,而實際上卻允許了。
  7. 輸入的內容是否符合合法性要求。如:賬號密碼是否一致等問題。
  8. ……

這些基本考慮內容都需要考慮進來。

大概理清楚需要考慮的內容之后,就可以開始動手寫了。

  1. 序號: 不用說,就是按順序下去的。
  2. 模塊:該功能點具體屬于哪個模塊的,填寫這個主要是方便查找,如:注冊/登錄模塊
  3. 編號:對每個用例進行編號,方便后期跟進。畢竟用文字說,容易口誤。不過此處建議編號設計的有點規則,方便快速定位查找。如:A0001。其中A表示注冊/登錄模塊。00表示賬號登錄,01 表示賬號密碼登錄下的第一個測試用例。
  4. 功能點:具體指某個功能,如:賬號登錄、首頁、發布等。
  5. 子功能點:具體指功能點,如:賬號密碼登錄、手機驗證碼登錄、郵箱登錄、第三方授權登錄等。
  6. 用例名稱:具體測試用例的名稱。如:輸入賬號、輸入密碼、密碼不合規等等。
  7. 前置條件:指要達到預期測試結果,需要滿足那些條件才能達到。如:賬號密碼不一致時,就需要登錄失敗,那么此時就得保
    證賬號正確或密碼正確以及賬號正確時是存在的。
  8. 操作步驟:指要達到預期測試結果,需要按這些步驟來。最好說明在什么頁面,點擊或操作什么內容,輸入什么內容。
  9. 預期結果:說明按照前面寫的應該呈現出怎樣的結果。
  10. 測試結果:如果符合預期結果,直接填寫正?;騉K,如果不符合,則說明不符合或NO,
  11. 結果描述:如果正常,可以不用填寫,如果不符合預期結果,則說明哪里不符合。
  12. 測試人員:填寫測試人的名字,方便后期跟蹤BUG。
  13. 測試日期:填寫測試的時間,方便后期查詢。
  14. BUGID:跟測試編號一樣,自己設定ID規則,方便快速查詢。
  15. BUG負責人:此處應該有技術那邊填寫,具體落實到某個人身上,才能更好的解決到問題。

以上就是測試用例的具體填寫方法及作用。測試完了之后,記得進行回歸測試以確保測試的意義。

如果你對我寫的這個感興趣,那么就期待我的下篇文章吧,下次認真說下非功能性測試怎么弄。

 

本文由 @光點神奇?原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 這是把產品當狗使喚了唄?代碼我給研發碼好,測試用例寫好,原型圖出全真的,運營方案也寫好,埋點寫好,數據分析也做了,其他人領工資不就行了唄

    來自湖北 回復
    1. 今天研發剛給我說讓我寫測試用例

      來自江蘇 回復
    2. 這個確實是不該了

      來自上海 回復
  2. 不會寫測試用例、碼代碼、設計效果圖、設計宣傳頁、賣東西、做PPT的產品經理不是好產品經理

    來自廣東 回復
    1. 天吶,太真實了

      來自廣東 回復
  3. 流程圖

    回復
  4. 圖不清楚啊,大佬

    來自遼寧 回復
  5. 如果您具備系統產品知識技能,
    有一套體系化的個人項目作品,
    您覺得,工作和求職,是否會更加地順暢?

    想體系化學習訓練,看公開課點這里:?http://996.pm/7GVQ4

    來自廣東 回復
  6. A0008-“賬號密碼不合法驗證-賬號錯誤”測試中,預期結果提示有誤。系統怎么會判斷賬號錯誤呢?系統也不會通過密碼來反推賬號是否正確。所以,用戶端實際操作是“錯誤賬號,正確密碼”,而系統判斷只有兩種情況:1、賬號不存在時提示“賬號不存在”;2、賬號存在時提示“密碼錯誤,登錄失敗”

    來自北京 回復
    1. 他這里是賬號不合法密碼正確,所以提示的該是“賬號格式錯誤”,而不是“賬號錯誤”,大約作者忽略了這倆字吧

      來自江蘇 回復
  7. 請問一下正常走向產品需要給測試人員什么資料呢?我們公司的測試同事要產品提供測試用例(測試內容,操作,預期效果),感覺工作量堪比需求文檔

    來自浙江 回復
    1. 很多人會吧測試用例寫在PRD里面,但是我覺得還是一張表格就差不多了,測試功能項目,前置條件,測試步驟,以及其他的一些日期項目名稱,等基本信息,表格可以請你們測試在后期幫你完善,這樣你的目的能達到,測試也會把自己的方式幫你豐富表格,一舉兩得 ??

      來自上海 回復
    2. 12345

      來自廣東 回復
  8. 最近在走測試流程,公司有專業的測試人員,不用產品做測試用例,實際本來也不是產品的工作,通過測試人員的測試,還是發現了不少問題,專業的測試還是不能少的

    來自北京 回復
  9. 正好需要,受教,感謝

    來自北京 回復
  10. 您好,作者描述的很詳細,本人在一家小公司,偶爾會負責到測試的內容,原來正規的測試案例需要描述的如此詳細,學習了很多,特別感謝!
    有幾點小疑問,還請指教。
    1.用例A0006中為什么賬號正確密碼也正確氣泡卻顯示該賬號不存在呢?
    2.在文中描述的情況下,若賬號密碼均錯誤,氣泡該如何顯示?是顯示請輸入正確賬號,賬號不存在還是密碼錯誤呢?
    3.測試登錄過程中,賬號密碼輸入格式方面是否需要增加如下異常情況的分類:a.賬號輸入非數字(此處若設置只允許數字輸入的限制,且如若賬號為手機號設置為首字符為1,可忽略);b.賬號和密碼輸入多位字符數(此處若設置字符數的限制,可忽略);c.密碼輸入特殊字符是否能照常登錄

    來自湖北 回復
    1. 帳號格式正確,不代表帳號正確吧。

      來自北京 回復
  11. 我們沒有測試用例 直接手工測試記錄bug,測試時能想到什么測什么,業務流程能下來就是OK了

    回復
    1. 業務流程一般有很多交叉情況,你這樣會漏掉很多東西的。

      來自香港 回復
  12. 產品是最后要什么都懂,不是什么都干,測試用例都要產品寫,想當然也是讓產品測,一個產品的專業測試流程走下來是很費時間的,而一個好的測試不僅僅是排除bug也會對產品有積極的建議,公司如果不重視測試可想而知做出來的產品多么粗糙

    來自廣東 回復
    1. 就一個項目來講,產品經理是第一梯隊,對產品的理解和要求是接近最準確的,越是業務越復雜的,越需要一個優秀的產品經理寫出完善的測試用例。

      來自北京 回復
    2. 寫完用例后,不一定非要產品測,制定者不一定是執行者,可以安排測試人員,按照產品寫的用例去執行和完善。

      來自北京 回復
  13. 來過,受教,感謝

    來自浙江 回復
  14. A007期望結果返回首頁應該沒有吧

    來自廣東 回復
  15. 有點像接口的測試哈哈

    來自廣東 回復
  16. 非常感謝,感覺難點就是要將前置條件考慮全面,沒想到一個登錄就有這么多測試用例

    來自湖北 回復
  17. 學習了,非常感謝樓主,點99個贊! ??
    有點小疑惑:用例A0008,賬號錯誤我理解只可能是賬號不存在(或是賬號格式錯誤,其實也是不存在),是不是和前面兩個case重復了呢。 ?

    來自北京 回復
    1. 給你點個贊,說明你認真看了。這個case是有錯誤,不過不是你說的錯誤,應該是輸入錯誤的賬號,我寫成了輸入正確的賬號了。
      這里的情況是這樣的:用戶輸入錯誤的賬號不代表這個賬號就不存在。比如A用戶的賬號是123,B用戶的賬號是124。但是用戶B把賬號輸入成:123了。密碼正確,這個時候就是這個case了。

      來自廣東 回復
    2. 這個時候系統應該會判斷是A在登錄,然后提示密碼錯誤 ??

      來自上海 回復
    3. 我也覺得

      來自福建 回復
  18. ??

    來自北京 回復
  19. 期待樓主的下一篇非功能測試

    來自山東 回復
  20. 給樓主點個贊!

    來自遼寧 回復
  21. 樓主你好!請教一個問題:你的測試用例表格中,是否還需要一項“輸入數據”?

    來自北京 回復
  22. 我只想說,產品還要寫測試用例的公司~ 還是別干了吧~ 這個都省了~公司很難做起來~ 基本上斷定是個 大坑

    來自廣東 回復
    1. 說的很有道理,但是像這樣的公司還有一大堆。并不是每一個公司都有測試專員的。。

      來自福建 回復
    2. 我公司就沒正經測試,所以做出來的東西非常粗糙,這就是不重視的結果,直接降低了最終產品質量。

      來自廣東 回復
    3. ?

      來自福建 回復
    4. 想起了我第一家公司,才20幾個人的時候就已經招了測試專員……而現在這家……

      來自廣東 回復
    5. 同感

      來自上海 回復
  23. 非常基礎的文章

    來自四川 回復
  24. 期待下一篇文章

    來自廣東 回復
  25. 哈哈,我們的測試用例基本差不多哈,我覺得應該考慮一個情況:一個完整的功能性測試的用例需要盡可能的覆蓋所有的情況,所以會很長很長,一次測下來費時費力。但是可能由于版本迭代有點快,或者其他原因,不可能每次都測。這時候需要兩個維度去測試:1、去測有變動的模塊 2、類似冒煙測試,把每個模塊的核心環節中的主要場景測一下,發生概率小的或者次要的可以不測。

    綜上(說了一堆廢話,哈哈),我的建議是:給測試用例也分個優先級,重要的必須每次都測,不重要的視情況而定

    來自廣東 回復
    1. 嗯,是的,這些需要跟實際情況相機處理,除非是大公司,小公司一般都很少天天測全部功能??????

      回復
    2. 但我們公司會出現這樣的情況,:改了一個bug,其他已經測試通過的功能又出現了bug;所以結果就是改一個bug,就全部要重測一遍

      來自上海 回復
    3. 這就是最可怕的狀況了。。。

      來自山東 回復