小型web產品的功能測試要點或測試大綱

2022-06-29 12:12:12 字數 3864 閱讀 5261

本文參考配置啦:-- web類產品功能測試大綱,黑盒測試參考測試範圍

【官網】:無

黑盒測試,功能測試中常常需要考慮很多問題,這裡根據本人的工作經驗遇到的進行了系列總結。給出了乙個常用的測試範圍和測試大綱。

產品具體業務
具體參考本行業的實際情況進行調整

問題分類

子問題

備註

測試環境

測試環境的搭建.

1.為了正式環境的穩定性,需要有測試環境作為支撐.

2.涉及調整比較多時, 先在測試網域名稱下測試,沒問題了再覆蓋正式。

發布與公升級

oem方案

1.根據網域名稱判斷

上線監測與運維輔助

1.需要增加類似友盟統計這樣的崩潰統計,使用者行為,分布統計的元件..方便後續調整,跟進.

伺服器作業系統相關

1.涉及php等跨平台的語言,如果在windows上開發測試的,那麼上線到linux之前需要注意linux上相關的相容性.

1.1)linux上嚴格區分大小寫,涉及php的包名,類名必須嚴格一致... 這也導致一些框架類似thinkphp中$this->fetch()可能需要改成$this->fetch("控制器名/action名");

1.2)一些php語法,類似header("location:");後面需要增加exit. 否則無法執行.

發布之前的**審查

1.白盒或專案經理應該在發布之前查閱開發人員待發布版本修改的具體內容.

1.1部分開發人員會刪除舊**重新寫,解決老問題引入新問題..可能考慮不周.

1.2部分開發人員在時間緊迫且**沒有封裝的情況下,會將修復**到處放,放多了,放錯了,放到位置不全等都有可能.

發布之前的配置檢查

1.伺服器位址,介面網域名稱(正式,測試),  應用id,秘鑰等.//正式和測試可能有區別.

發布之後的功能測試

1.每次涉及後台**的發布,都需要進行一次涉及範圍的測試(註冊,登入,支付,匯出等).

伺服器調整

伺服器遷移

1.需要緊急測試首頁,註冊,開通,匯入檔案,匯出檔案等.(對應測試的是指令碼執行,寫入許可權等)

網域名稱解析變更指向

1.涉及伺服器遷移後解析網域名稱變更時,先確保新的伺服器上本地能執行或用其它臨時網域名稱能測試他通,之後才進行網域名稱解析,否則將亂成一團。

業務流程

關聯後台的各角色測試

1.平台各類員工(角色)都需要進行相關的測試.

業務主分支覆蓋測試

1.有些時候為了省事,或因為陷於細節導致進度問題下,多數僅僅覆蓋了乙個或部分分支.

api相關

1.同版本:盡量以相容方式公升級

運營相關

查閱第三方監控資料

1.崩潰問題及趨勢:快速直觀的鎖定問題.

2.新增使用者等.

使用者手冊

1.每個重大版本都要撰寫(或更新)使用者手冊,使用者手冊需要從新使用者的角度開始出發,從0開始引導,介紹.

格式與容量

文字長度控制

多了會樣式擁擠,或者導致程式錯誤.

資料項的個數太多無法顯示全

有些容器下,下拉選資料項太多會無法顯示出來,因為沒有滾動條.

自定類的資料新增條數限制

有些樣式設計時考慮最多多少個,多了就錯亂了.

破壞json,xml格式的特殊字元.

1.)對xml如果包含&,<>等,以及json裡的",\r\n等都會導致格式錯誤.對該類問題需要進行編碼處理,比如base64等,之後收到了之後再單個進行處理.

ui互動

進度條等

類似登入等地方如果網速慢,如果沒有轉圈或進度條之類的,使用者會誤以為點選失敗或程式出錯

無資料記錄時

1.)有時無記錄時,部分頁面中如果初始化頁面沒有判空等處理,則會崩潰.

預設值與空值問題

1.因為某種原因,某些值為null或者沒有初始化時間..會顯示出null,0001-01-01等格式..應該對其

進行相關判斷處理,以友好的"空白","無修改","無內容"等代替.

分頁(下拉)

下拉是否可用,下拉(分頁)與實際數目的總頁數,總資料數是否和實際資料條數是否能對應上.

適當的資料聚合.

盡量相關的資訊在乙個手機頁面看到,不要來回點選跳轉.

支援中斷後再操作

1.比如使用者操作一批資料,中間打斷去做別的(或來**,或沒電關機,或其它操作),之後再進入,需要能夠處理好起點,避免重複無效的操作.

排序問題

一般使用者關心或對比都是關注最近發生的事情,所以一般來說都應該是按時間倒序.

虛擬鍵問題

是否有業務操作提示

1.對於一些重要按鈕或其它觸發操作,需要增加響應的懸浮提示或下方的提示,防止使用者看不懂導致溝通成本加大.

如果手機號繫結錯誤

1.)對於沒有卡或手機號繫結錯誤的情況,會不會丟失資料.

空格問題

有些時候輸入的內容前或後方會有空格,如果帶過去儲存了,會導致使用者下次登入時無法登入或無法使用.

錯誤提示

1.程式出錯時,盡量給使用者看到使用者能理解並知道怎麼做的提示..如果方便開發者定位問題,則還可以加上錯誤碼.

賬戶相關

登入互動提示

1.驗證碼,使用者名稱或密碼錯誤,賬號禁用等使用者需要理解或指導的原因要提示出來.盡量在每個

提示中能夠告訴使用者出現什麼問題並需要如何解決.

賬號狀態關聯行為

1.如果賬號禁用了,則無法登入,並無法參與一些正常的業務處理,比如分配,審核等.

賬戶授權與到期控制

1.賬戶授權是否生效.

2.賬戶授權到期是否能夠有相關響應.

使用者在多個不同裝置瀏覽問題

1.類似qq會有擠下線的處理及提示. 為了防止出現資料分配,同步資料等實時行為出現紊亂,應該避免乙個賬戶在多個裝置上登入的情況:可以通過裝置號與賬戶關聯,心跳擠下線等方案實現.

2.如果使用了裝置號賬號關聯的方案,則應該在後台有配套的解綁或重置的方案.

新賬戶測試

1.有時老賬戶隨著開發一路測試過來,小問題可能有特殊辦法解決了,甚至指令碼..那麼在後期需要通過新賬戶從零開始走一遍,暴露一些潛在問題.

一致性產品名的一致性

列名1.新增,編輯,查詢條件,列表頁欄位名保持一致.

資料一致性

安全性api的防sql注入

密碼等以*出現

類似密碼等以*呈現.

重複提交問題

1.訂單,請求重複提交,是否會造成相關的問題或錯誤.一般需要介面方進行協助處理.

刪除,覆蓋等操作有確認提示.

重要資料的刪除,覆蓋等操作有乙個確認提示,防止使用者誤操作.

**,文件, 簽名檔案安全性

團隊**,文件應該都有乙個伺服器端儲存備份.

測試資料

探針測試

比如webshell等可以將乙個檔案放入到上傳目錄是否能執行

關於除錯資訊

不管是原生**還是基於開源框架,都需要了解如何關閉除錯,防止sql等出現在前端.

專案人員管理

1.由於專案中人員有進有出,所獲得的svn,ftp,雲,第三方平台等的訪問口令,許可權都需要進行禁用,關閉等處理.

2.管理雲產品(伺服器,oss,資料庫等).

業務場景

資料場景/**

1.)密文來自營銷魔盒, 明文的業務也需要進行正規測試.

不按正常流程走,漏掉一些環節

1.)比如有些客戶沒有設定標籤分類,就開始分配線索,打**,這個過程沒問題,但是聯絡歷史中標籤分類列表集合沒有判空,進而導致出錯

**商及第三方

關注**商產品公升級

1.)ai產品中遇到**商在3.14日公升級,導致這邊介面有些時候會返回異常甚至返回sql語句了.  後面讓**商給還原到之前最近的版本才解決

WEB功能測試要點

web功能測試一般關注的點主要可以分ui及易用性測試 表單測試 cookies測試 鏈結測試 相容性測試。ui及易用性測試 1 各個頁面的樣式風格是否美觀統一,如大小 顏色是否統一,頁面 文字 是否居中等。2 各個頁面的標題和描述是否正確,有無錯別字,字型大小 顏色是否正確統一,文字描述準確,無歧義...

web功能測試要點總結

web功能測試一般關注的點主要可以分ui及易用性測試 表單測試 cookies測試 鏈結測試 相容性測試。ui及易用性測試 1 各個頁面的樣式風格是否美觀統一,如大小 顏色是否統一,頁面 文字 是否居中等。2 各個頁面的標題和描述是否正確,有無錯別字,字型大小 顏色是否正確統一,文字描述準確,無歧義...

Web測試要點(功能 效能 可用性 相容 安全)

一 功能測試 1 鏈結測試 1 測試所有鏈結是否按指示的那樣確實鏈結到了該鏈結的頁面 2 測試所鏈結的頁面是否存在 3 保證web應用系統上沒有孤立的頁面 所謂孤立頁面是指沒有鏈結指向該頁面,只有知道正確的url位址才能訪問 2 表單測試 1 註冊 登陸 資訊提交等,必須測試提交操作的完整性,以校驗...