如何編寫產品的黑盒測試用例

發表于:2020-12-07 10:03  作者:言水丫子   來源:知乎

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 測試用例 黑盒測試

  每次需求一出bug,不管最后追責殺到誰的頭上,前邊一定是產品剛在第一線。為了少出事,就在測試階段多干活。
  建議不管有多忙,產品也要在需求上線前驗一遍。這樣至少有兩個好處:
  ·少背鍋。需求上線前,什么事情都比較好解決,比上線后扯皮強。
  ·多露臉。部門那么大,不一定都認識,行走江湖靠朋友,各部門混個臉熟才是正道。
  在不看觸代碼和接口,僅看功能邏輯的測試,就是黑盒測試
  那末,從產品的角度,黑盒測試該如何編寫用例,才顯得比較專業呢?
  STEP1 改造測試的測試用例
  找測試要一份測試用例文檔,有些公司還會要求開測試用例評審會。
  假如要不到,網上也能百度搜下來一份,然后刪掉一些測試部門統一要求方便管理,但是產品不需要的內容,比如案例作者、案例工號之類的內容。我們再整合一下作為產品需要哪些信息,最終就能整理出一份用例框架。
  STEP2 找出需求主流程/拆分條件分支
  產品要梳理出系統主流程那簡直是分分鐘能搞定的事情。假如是臨時接手的需求,也可以參考業務流程圖來找出主流程。
  找出主流程后,開始將主流程拆分,每個點擊跳轉、每個條件判斷,都要作為一條用例寫下。
  并拆分出分支,例如判斷,內容,可以先測否定判斷,再測肯定判斷等等。
  STEP3 找出需求邊界
  找出需求邊界,即測試需求要求的邊界內容。比如此行內容限定18位數值,那就可以測試四類場景:
  ·未填寫
  ·填寫少于18位、
  ·填寫大于18位
  ·填寫符號
  測試需求邊界,查看極限狀態下邏輯能否正常運行,頁面展示正常程度等等,可以有效分擔測試的工作量,同時也能探查到測試容易忽略的bug。
  STEP4 找出異常測試
  異常類型測試,通常來說是白盒較為方便,更改參數,模擬異常場景更加簡單;但黑盒也可以完成部分異常場景。比如:
  A:余額不足、斷網/斷電/死機;
  B:產品狀態變化引起的異常;
  C:操作中應該選的選項沒有選的場景等等。
  上面列舉的AC實現都非常容易, B需要稍加舉例,假如用戶正在訂購已上架的α商品,在加入購物車前下架此商品和在加入購物車后下架此商品會不會有表述不同。
  這四步完成,產品的黑盒測試用例就完成了。等到需求轉測時,拿出來無腦按步驟測試吧,裝裝13的同時,也能保證自己盡最大努力推進需求,少背鍋。剩下那些莫名其妙的BUG,那都開發跟測試的....
  最后再列舉一些常用的測試內容。
  特殊類:特殊數字(小數點后10位數的正數、負數、0)、特殊空值(NULL,NONE)、特殊字符(True\Flase\and\or)、特殊符號(全角、半角)、中文(繁體、簡體)、emoji表情
  重復類:添加重復值、修改為重復值、刪除重復值、修改為空值
  要求類:個數、長度、精度、層次、深度、空值,以及其它不在范圍內的情況
  最后祝大家在產品道路上一去不復返。

  本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海信義律師事務所 項棋律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2021, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

日本av