1. 程式人生 > >關於使用者登入介面測試用例總結

關於使用者登入介面測試用例總結

  一、使用者註冊 
只從使用者名稱和密碼角度寫了幾個要考慮的測試點,如果需求中明確規定了安全問題,Email,出生日期,地址,性別等等一系列的格式和字元要求,那就都要寫用例測了~ 以等價類劃分和邊界值法來分析 
1.填寫符合要求的資料註冊: 使用者名稱字和密碼都為最大長度(邊界值分析,取上點) 
2.填寫符合要求的資料註冊 :使用者名稱字和密碼都為最小長度(邊界值分析,取上點) 

3.填寫符合要求的資料註冊:使用者名稱字和密碼都是非最大和最小長度的資料(邊界值分析,取內點)

 4.必填項分別為空註冊 

5.使用者名稱長度大於要求註冊1位(邊界值分析,取離點)

 6.使用者名稱長度小於要求註冊1位(邊界值分析,取離點)

 7.密碼長度大於要求註冊1位(邊界值分析,取離點)

 8.密碼長度小於要求註冊1位(邊界值分析,取離點) 

9.使用者名稱是不符合要求的字元註冊(這個可以劃分幾個無效的等價類,一般寫一兩個就行了,如含有空格,#等,看需求是否允許吧~)

 10.密碼是不符合要求的字元註冊(這個可以劃分幾個無效的等價類,一般寫一兩個就行了) 

11.兩次輸入密碼不一致(如果註冊時候要輸入兩次密碼,那麼這個是必須的) 
12.重新註冊存在的使用者 
13.改變存在的使用者的使用者名稱和密碼的大小寫,來註冊。(有的需求是區分大小寫,有的不區分) 
14.看是否支援tap和enter鍵等;密碼是否可以複製貼上;密碼是否以* 之類的加祕符號顯示 

備註:邊界值的上點、內點和離點大家應該都知道吧,呵呵,這裡我就不細說了~~

 二、修改密碼 

當然具體情況具體分析哈~不能一概而論~ 
實際測試中可能只用到其中幾條而已,比如銀行卡密碼的修改,就不用考慮英文和非法字元,更不用考慮那些TAP之類的快捷鍵。而有的需要根據需求具體分析了,比如連續出錯多少次出現的提示,和一些軟體修改密碼要求一定時間內有一定的修改次數限制等等。 1.不輸入舊密碼,直接改密碼 2.輸入錯誤舊密碼 3.不輸入確認新密碼 4.不輸入新密碼 

5.新密碼和確認新密碼不一致 

6.新密碼中有空格

 7.新密碼為空 

8.新密碼為符合要求的最多字元

 9.新密碼為符合要求的最少字元 

10.新密碼為符合要求的非最多和最少字元 11.新密碼為最多字元-1 12.新密碼為最少字元+1 13.新密碼為最多字元+1 14.新密碼為最少字元-1 
15.新密碼為非允許字元(如有的密碼要求必須是英文和數字組成,那麼要試漢字和符號等) 
16.看是否支援tap和enter鍵等;密碼是否可以複製貼上;密碼是否以* 之類的加祕符號 
17.看密碼是否區分大小寫,新密碼中英文小寫,確認密碼中英文大寫 
18.新密碼與舊密碼一樣能否修改成功 另外一些其他的想法如下: 
1 要測試所有規約中約定可以輸入的特殊字元,字母,和數字,要求都可以正常輸入、顯示正常和新增成功 
2 關注規約中的各種限制,比如長度,大否支援大小寫。 
3 考慮各種特殊情況,比如新增同名使用者,系統是否正確校驗給出提示資訊,管理員帳戶是否可以刪除,因為有些系統管理員擁有最大許可權,一旦刪除管理員帳戶,就不能在前臺新增,這給終端使用者會帶來很多麻煩。比較特殊的是,當用戶名中包括了特殊字元,那麼對這類



使用者名稱的新增同名,修改,刪除,系統是否能夠正確實現,我就遇到了一個系統,新增同名使用者時,如果以前的使用者名稱沒有特殊字元,系統可以給出提示資訊,如果以前的使用者名稱包含特殊字元,就不校驗在插入資料庫的時候報錯。後來查到原因了,原來是在java中拼SQL語句的時候,因為有"_",所以就呼叫了一個方法在“_”,前面加了一個轉義字元,後來發現不該呼叫這個方法。所以去掉就好了。所以對待輸入框中的特殊字元要多關注。 
4 數值上的長度 之類的,包括出錯資訊是否合理  

5 特殊字元:比如。 / ' " \ </html> 這些是否會造成系統崩潰 

6 注入式bug:比如密碼輸入個or 1=1 7 登入後是否會用明文傳遞引數 

8 訪問控制(不知道這個算不算):登入後儲存裡面的連結,關了瀏覽器直接複製連結看能不能訪問。




11.兩次輸入密碼不一致(如果註冊時候要輸入兩次密碼,那麼這個是必須的) 
12.重新註冊存在的使用者 
13.改變存在的使用者的使用者名稱和密碼的大小寫,來註冊。(有的需求是區分大小寫,有的不區分) 
14.看是否支援tap和enter鍵等;密碼是否可以複製貼上;密碼是否以* 之類的加祕符號顯示 
備註:邊界值的上點、內點和離點大家應該都知道吧,呵呵,這裡我就不細說了~~ 二、修改密碼 
當然具體情況具體分析哈~不能一概而論~ 
實際測試中可能只用到其中幾條而已,比如銀行卡密碼的修改,就不用考慮英文和非法字元,更不用考慮那些TAP之類的快捷鍵。而有的需要根據需求具體分析了,比如連續出錯多少次出現的提示,和一些軟體修改密碼要求一定時間內有一定的修改次數限制等等。

相關推薦

關於使用者登入介面測試總結

  一、使用者註冊  只從使用者名稱和密碼角度寫了幾個要考慮的測試點,如果需求中明確規定了安全問題,Email,出生日期,地址,性別等等一系列的格式和字元要求,那就都要寫用例測了~ 以等價類劃分和邊界值法來分析  1.填寫符合要求的資料註冊: 使用者名稱字和密碼都為最大長度

HTTP介面自動化經驗總結(四)Okhttp3 介面測試編寫

經過前面幾次的分享,我們已經有了方法和結果,那麼這篇文章我們就來寫測試用例。 首先我們新建一個TestNG class,名字為APITest,繼承我們的依賴方法DependeicesMethod 1.get介面測試 //測試Get方法,其餘校驗請自行新增 @Test

登入頁面測試(轉載)

具體需求: 有一個登入頁面, (假如上面有2個textbox, 一個提交按鈕。 請針對這個頁面設計30個以上的testcase.)   此題的考察目的:面試者是否熟悉各種測試方法,是否有豐富的Web測試經驗, 是否瞭解Web開發,以及設計Test case的能力   

介面測試和報告模板

一、介面用例模板 提到測試用例,我們知道,其中最重要的兩個要素就是: 測試步驟 預期結果  其實對於介面測試也同樣如此,介面測試的步驟中,最重要的是將實現向介面傳送預設請求,結果則要關注響應資訊及後續處理。 所以介面測試用例編排可以考慮下列兩種形式:  

通用介面測試設計

1.通過性驗證:   首先肯定要保證這個介面功能是好使的,也就是正常的通過性測試,按照介面文件上的引數,正常傳入,是否可以返回正確的結果。 2.引數組合:   現在有一個操作商品的介面,有個欄位type,傳1的時候代表修改商品,商品id、商品名稱、價格有一個是必傳的

介面測試設計點

1.是否滿足前提條件:有些介面需要滿足前提條件才能獲得資料 2.是否攜帶預設引數:帶預設的引數不填寫,不傳參,必填參正確填寫測試,其他不填寫 3.根據業務和功能需求進行設計 4.引數是否必填:每一條引數用例只設計某一個必填引數不填,其餘都正常填寫進行測試 5.引數直接存在制約和關聯:根據實際關聯設計用

介面測試設計詳細介紹

0 導語 隨著測試分析和分層測試的深化,“介面測試”出現在我們視野的頻次越來越高。那麼介面測的用例設計常用哪些方法呢?本文將詳細描述。 1 介面測試 1.1 介面測試 介面:主要是子模組或者子系統間互動並相互作用的部分。 這裡說的介面是廣義的,客戶端與後臺

介面測試設計(詳細乾貨)

https://www.tuicool.com/articles/E3m2Mn6導語隨著測試分析和分層測試的深化,“介面測試”出現在我們視野的頻次越來越高。那麼介面測的用例設計常用哪些方法呢?本文將詳細描述。1  介面測試   1.1  介面測試介面:主要是子模組或者子系統間

登入測試設計點

在看了一個有關登入的一個課程之後,發現自己以前對登入測試的用例設計簡直是井底之蛙,在跟領導聊天之後一致認為可以就這一課文章進行一個整理概括,加以完善,還望大家多多提意見,有借鑑到的內容還望見諒,本文章只是一個整理,與完善補充,並非抄襲,方便各位拿來參看借鑑同時也方便自己拿來借

web測試中的介面測試設計

測試用例 一、文字框、按鈕等控制元件測試 1、文字框的測試 如何對文字框進行測試: a、輸入正常的字母或數字; b、輸入已存在的檔案的名稱; c、輸入超長字元。例如在“名稱”框中輸入超過允許邊界個數的字元,假設最多255個字元,嘗試輸入256個字元,檢查程式能否正確處

使用者登入測試設計

具體需求: 有一個登陸頁面, (假如上面有2個textbox, 一個提交按鈕。 請針對這個頁面設計30個以上的testcase.)   此題的考察目的:面試者是否熟悉各種測試方法,是否有豐富的Web測試經驗, 是否瞭解Web開發,以及設計Test case的能力   

回歸測試中只有功能測試-Bug總結系列筆記

需求 特性 size 質量 mil 設計 陷阱 mar 定義 一、定義:測試人員只執行了變更引起的相關功能的回歸測試 二、發生時間段Always 三、陷阱表現1.只測試了系統或軟件功能2.回歸測試未包含系統質量測試3.未對架構、設計和實現約束的回歸測試 四、負面後果1.無

史上最全的測試設計方法總結

內部 就是 影響 中間 存在 計算公式 冗余 邊界 數組 測試用例的設計方法(全)等價類劃分方法:一.方法簡介1.定義是把所有可能的輸入數據,即程序的輸入域劃分成若幹部分(子集),然後從每一個子集中選取少數具有代表性的數據作為測試用例。該方法是一種重要的,常用的黑盒測試用例

轉-登入功能通用測試設計

https://www.cnblogs.com/jpr-ok/p/6418492.html 登入功能通用測試用例 具體需求: 有一個登入頁面,有一個賬號和一個密碼輸入框, 一個提交按鈕。 請針對這個頁面設計Test Case。 此題的考察目的: 1、瞭解需求(測什麼都是從瞭解需求開始); 2、是否

WEB測試設計總結

1易用性       1、便於使用、理解、並能減少使用者發生錯誤選擇的可能性   2、當資料欄位過多時,使用便於使用者迅速吸取資訊的方式表現資訊,突出重點資訊,標紅等方式   3、顯示與當前操作相關的資訊,給出操作提示。   4、介面要支援鍵盤自動瀏覽按鈕功能,即按Tab

關於“賬號登入”&“賬號註冊”&“修改密碼”通用的測試設計思路

原文:https://blog.csdn.net/mr_lady/article/details/48517985 1.賬號登入: 1.使用者或密碼為空 2.資料庫中不存在的使用者名稱,不存在的密碼 3.資料庫中存在的使用者名稱,錯誤的密碼 4.資料庫中不存在的使用

測試 -介面測試-測試編寫

一、.介面功能測試的測試方案規格建議可以有如下幾點: 1、需求所涉及的介面的背景描述 2、介面跟頁面功能互動的關聯關係 3、介面邏輯的流程圖 4、介面文件定義 5、介面所涉及的快取,以及快取對應的key值,失效時間定義 6、介面所涉及的SQL,以及資料庫表字段定義

登入介面測試總結

常見登入介面如下 功能測試點   1)空白   使用者名稱和密碼均為空/使用者名稱填寫,密碼為空/使用者名稱為空,密碼填寫   2)錯誤校驗   輸入錯誤的使用者名稱和密碼/使用者名稱錯誤密碼正確/使用者名稱正確密碼錯誤   3)大小寫區分(如:使用者名稱

python - 介面自動化測試 - TestLogin - 登入介面測試用

  # -*- coding:utf-8 -*- ''' @project: ApiAutoTest @author: Jimmy @file: test_login.py @ide: PyCharm Community Edition @time: 2018-12-22 09:33

移動端測試設計總結

一、前言    作為移動網際網路產品『最後一公里的守護者』,我們必須要清楚的知道自己該做什麼、怎麼做。但從版本迭代速度、需求量級、測試人員不斷變動等方面綜合來看,我們很多人都沒有做好充分的準備。測試方法落後、測試用例覆蓋不全、測試效率低下,使得測試將