人
已閱讀
已閱讀
看一下APP開發公司的測試用例怎么寫
來源:www.bqtao.cn ?? ?? 發布時間:2019-05-17
專業一點的APP開發公司在開發一個項目時,都會寫測試用例。不管是測試人員寫,還是產品經理寫,總之會有這么一份文檔,用于產品測試和項目驗收。那么,一般在APP開發公司該如何撰寫測試用例呢?

一、產品測試的意義
一個完整的開發流程。從提需求、開發、交付。這中間都應該有個結果。就如你做一件事,得有個東西來判斷你是否已經完成了這件事。那么測試結果就是這個東西了。
一般情況下,在開需求評審會議時同時會把測試需求列明,以確保產品按質量上線。
一個完整的開發流程。從提需求、開發、交付。這中間都應該有個結果。就如你做一件事,得有個東西來判斷你是否已經完成了這件事。那么測試結果就是這個東西了。
一般情況下,在開需求評審會議時同時會把測試需求列明,以確保產品按質量上線。
二、測試文檔的結構
一般情況下,測試文檔主要分兩個部分。即:非功能性測試需求、功能性測試需求。
所謂非功能性測試,主要指APP運行時在各種環境下是否能正常運行,而功能性測試是指每個具體功能是否按要求運行。
測試文檔也不需要太復雜,直接使用excel編撰就可以了。
一般情況下,功能性測試文檔直接使用該模板就能滿足大部分的需求。
一般情況下,測試文檔主要分兩個部分。即:非功能性測試需求、功能性測試需求。
所謂非功能性測試,主要指APP運行時在各種環境下是否能正常運行,而功能性測試是指每個具體功能是否按要求運行。
測試文檔也不需要太復雜,直接使用excel編撰就可以了。
一般情況下,功能性測試文檔直接使用該模板就能滿足大部分的需求。
三、具體編寫方法
在編寫測試用例之前,你得想好有哪些前置條件。這些前置條件滿足了才能達到你得預期。比如賬號密碼登錄,前置條件時賬號和密碼同時正確才能正常登錄成功。那么此時你就得編寫條件不符的時候,是否也會成功。如果成功了,那就屬于BUG,需要技術進行修復。
一般正常情況,請考慮一下幾個方面:
頁面布局是否合理,如導航欄上面應該顯示三個按鈕,實際上卻顯示了兩行。
頁面文字描述是否準確,如氣泡提示:密碼格式錯誤,請重新輸入。實際上卻顯示:賬號密碼錯誤。
如果有加載規則,是否符合加載規則。如:進入頁面加載20條內容,實際上卻加載了10條。
如果有排列規則,是否符合排列規則。如應按照時間倒序排列,實際上卻是正序排列。
操作是否符合要求,如單擊某個點,是否準確跳轉或顯示內容。如本應該進行跳轉,實際上卻未進行跳轉。
輸入框輸入的內容是否有符合格式要求。如:賬號不允許”,”,而實際上卻允許了。
輸入的內容是否符合合法性要求。如:賬號密碼是否一致等問題。
……
這些基本考慮內容都需要考慮進來。
大概理清楚需要考慮的內容之后,就可以開始動手寫了。
序號: 不用說,就是按順序下去的。
模塊:該功能點具體屬于哪個模塊的,填寫這個主要是方便查找,如:注冊/登錄模塊
編號:對每個用例進行編號,方便后期跟進。畢竟用文字說,容易口誤。不過此處建議編號設計的有點規則,方便快速定位查找。如:A0001。其中A表示注冊/登錄模塊。00表示賬號登錄,01 表示賬號密碼登錄下的第一個測試用例。
功能點:具體指某個功能,如:賬號登錄、首頁、發布等。
子功能點:具體指功能點,如:賬號密碼登錄、手機驗證碼登錄、郵箱登錄、第三方授權登錄等。
用例名稱:具體測試用例的名稱。如:輸入賬號、輸入密碼、密碼不合規等等。
前置條件:指要達到預期測試結果,需要滿足那些條件才能達到。如:賬號密碼不一致時,就需要登錄失敗,那么此時就得保
證賬號正確或密碼正確以及賬號正確時是存在的。
操作步驟:指要達到預期測試結果,需要按這些步驟來。最好說明在什么頁面,點擊或操作什么內容,輸入什么內容。
預期結果:說明按照前面寫的應該呈現出怎樣的結果。
測試結果:如果符合預期結果,直接填寫正常或OK,如果不符合,則說明不符合或NO,
結果描述:如果正常,可以不用填寫,如果不符合預期結果,則說明哪里不符合。
測試人員:填寫測試人的名字,方便后期跟蹤BUG。
測試日期:填寫測試的時間,方便后期查詢。
BUGID:跟測試編號一樣,自己設定ID規則,方便快速查詢。
BUG負責人:此處應該有技術那邊填寫,具體落實到某個人身上,才能更好的解決到問題。
以上就是測試用例的具體填寫方法及作用。測試完了之后,記得進行回歸測試以確保測試的意義。
在編寫測試用例之前,你得想好有哪些前置條件。這些前置條件滿足了才能達到你得預期。比如賬號密碼登錄,前置條件時賬號和密碼同時正確才能正常登錄成功。那么此時你就得編寫條件不符的時候,是否也會成功。如果成功了,那就屬于BUG,需要技術進行修復。
一般正常情況,請考慮一下幾個方面:
頁面布局是否合理,如導航欄上面應該顯示三個按鈕,實際上卻顯示了兩行。
頁面文字描述是否準確,如氣泡提示:密碼格式錯誤,請重新輸入。實際上卻顯示:賬號密碼錯誤。
如果有加載規則,是否符合加載規則。如:進入頁面加載20條內容,實際上卻加載了10條。
如果有排列規則,是否符合排列規則。如應按照時間倒序排列,實際上卻是正序排列。
操作是否符合要求,如單擊某個點,是否準確跳轉或顯示內容。如本應該進行跳轉,實際上卻未進行跳轉。
輸入框輸入的內容是否有符合格式要求。如:賬號不允許”,”,而實際上卻允許了。
輸入的內容是否符合合法性要求。如:賬號密碼是否一致等問題。
……
這些基本考慮內容都需要考慮進來。
大概理清楚需要考慮的內容之后,就可以開始動手寫了。
序號: 不用說,就是按順序下去的。
模塊:該功能點具體屬于哪個模塊的,填寫這個主要是方便查找,如:注冊/登錄模塊
編號:對每個用例進行編號,方便后期跟進。畢竟用文字說,容易口誤。不過此處建議編號設計的有點規則,方便快速定位查找。如:A0001。其中A表示注冊/登錄模塊。00表示賬號登錄,01 表示賬號密碼登錄下的第一個測試用例。
功能點:具體指某個功能,如:賬號登錄、首頁、發布等。
子功能點:具體指功能點,如:賬號密碼登錄、手機驗證碼登錄、郵箱登錄、第三方授權登錄等。
用例名稱:具體測試用例的名稱。如:輸入賬號、輸入密碼、密碼不合規等等。
前置條件:指要達到預期測試結果,需要滿足那些條件才能達到。如:賬號密碼不一致時,就需要登錄失敗,那么此時就得保
證賬號正確或密碼正確以及賬號正確時是存在的。
操作步驟:指要達到預期測試結果,需要按這些步驟來。最好說明在什么頁面,點擊或操作什么內容,輸入什么內容。
預期結果:說明按照前面寫的應該呈現出怎樣的結果。
測試結果:如果符合預期結果,直接填寫正常或OK,如果不符合,則說明不符合或NO,
結果描述:如果正常,可以不用填寫,如果不符合預期結果,則說明哪里不符合。
測試人員:填寫測試人的名字,方便后期跟蹤BUG。
測試日期:填寫測試的時間,方便后期查詢。
BUGID:跟測試編號一樣,自己設定ID規則,方便快速查詢。
BUG負責人:此處應該有技術那邊填寫,具體落實到某個人身上,才能更好的解決到問題。
以上就是測試用例的具體填寫方法及作用。測試完了之后,記得進行回歸測試以確保測試的意義。
- 上一篇:做什么樣的APP產品成功的機率大
- 下一篇:2018最受歡迎的APP開發語言