經典場景法，測試用例編寫

一．登錄界面的測試用例：

1.界面UI測試：
①布局是否符合需求文檔的要求；
②輸入框和按鈕的長度、高度是否符合要求；
③界面的設計風格是否與UI的界面設計風格統一；
④界面的文字是否簡潔易懂，無錯別字。
2. 功能測試：
①輸入正確的用戶名和密碼，驗證登錄成功；
②用戶名、密碼為空，驗證登錄失敗并提示信息；
③登錄成功后，是否跳轉到相應的界面；
④用戶名和密碼過長或過短是否有提示信息；
⑤用戶名和密碼之間有空格、特殊字符或者其他非英文的處理；
⑥登錄失敗后，不能有記住密碼的功能；
⑦密碼是否加密顯示；
⑧登錄頁面的注冊、忘記密碼、登出等用另一賬號登錄鏈接是否正確。
⑨輸入密碼，大寫鍵盤打開是否有提示信息；
⑩輸入錯誤的用戶名和密碼，查看提示信息。
3. 性能測試：
①打開登錄界面，需要幾秒（時長）；
②輸入正確的用戶名和密碼登錄成功，登錄時長不超過5s。
4. 兼容性測試：
①主流瀏覽器是否顯示成功；
②不同的平臺是否顯示成功；
③移動設備上是否顯示成功（Android iOS）；
④不同的分辨率；
5. 可用性測試：
①是否支持全鍵盤操作，是否有快捷鍵；
②輸入用戶名和密碼，按回車是否可以登錄；
③輸入框能否tab鍵切換。
6. 安全性測試：
①用戶名和密碼是否通過加密的形式發送給web服務器；
②用戶名和密碼的輸入，應該屏蔽SQL注入（是指web應用程序對用戶輸入的數據的合法性沒有判斷或過濾不嚴，得到相應的數據信息；；方式有：數字型注入、字符型注入以及其他型注入，比如cookie注入，post注入）；
③用戶名和密碼的輸入，應該禁止輸入腳本（依據一定的格式編寫的可執行文件）；
④錯誤登錄的次數限制；
⑤考慮是否支持多用戶在同一機器上的登錄；
⑥考慮一用戶在多態機器上的登錄。

二。針對王者里一個游戲的測試：

比如說亞瑟：
①技能能否使用，以及普攻能否正常使用；
②他能否出裝和賣裝；
能否換皮膚和購買新皮膚；
④亞瑟的口頭禪是否順利并且帶有感情色彩表達出來；
⑤每個技能的有效時長；
⑥不進行操作時，他是否自己會操作；
⑦帶的閃現、終結或者懲戒、弱化等驗證是否正常使用；
⑧回血技能是否可以使用；
⑨發起進攻、撤退等操作可否進行；
⑩快捷語能否實現；

三。微信充值的測試點：

1.賬號輸入檢查
①賬號位的長短；②賬號里帶有特殊符號、空格以及非英文的處理；③大寫字母的處理；④不存在的賬號的驗證及提示；⑤不輸入賬號提交會提示什么信息；⑥賬號輸入框所在行，點擊任意地方，均應獲取到焦點在輸入框，保證用戶可以正常使用。
2.充值界面顯示信息的檢查
①充值金額是否正常顯示；②選擇不同的面額來檢查支付金額是否正確；③溫馨提示的文字檢查，查看是否有錯別字或是語句不通的語句；④檢查客服熱線電話以及在線客服是否正常運營。
3.按鈕的檢查
①【立即充值】、【支付】、【提交】、【返回】、【返回充值首頁】、【清除】等是否能夠正常操作，能否正常跳轉到相應的頁面。
4.充值的不同場景
①正常充值流程，充值成功，訂單狀態為充值成功，支付狀態為支付成功。
②在支付界面，取消訂單，訂單狀態為待充值，支付狀態為待支付。
③供應商余額不足，不能進行充值處理，訂單狀態為充值失敗。
④不同的充值面額進行測試。
⑤充值明細的測試是否正常記錄。
⑥網絡環境佳或者網弱或者無網環境的測試；
⑦默認的充值面額是否可以進行修改。

3.上傳視頻（上傳和發布按鈕）的測試編寫

（1）功能測試
①選擇符合要求的視頻上傳，驗證上傳成功；
②上傳成功的視頻的名稱驗證顯示正常；
③驗證上傳的視頻可否查看與下載；
④上傳成功的視頻可否刪除、替換；
⑤上傳視頻是否支持中文名稱；
⑥視頻路徑檢查是否<可手動輸入>；分為：①手動輸入正確且不存在的視頻路徑，驗證上傳成功；②手動輸入正確且存在的路徑，上傳成功；③手動輸入錯誤的視頻路徑，驗證上傳失敗，并提示。<不可手動輸入>：分為：①選擇自動帶出的視頻，上傳成功；②按F12篡改正確的視頻路徑，上傳成功；③按F12篡改錯誤的視頻路徑，上傳失敗。
⑦上傳正確or不正確格式，驗證上傳成功or失敗；
⑧上傳過程中有無取消上傳的功能；
⑨選擇好但是未上傳的視頻是否可以取消選擇
⑩不選擇，直接上傳有無提示消息
（2）視頻大小測試
①符合視頻格式，總大小稍系小于限制大小的規定，上傳成功；
②視頻大小超過存儲剩余空間；
③視頻上傳時，存儲空間已滿。
（3）視頻名稱測試
①驗證視頻命名是否符合規范；
②視頻名稱過長、過短有無限制；
③視頻名稱包含特殊字符、空格等處理；
④視頻名稱純英、純中或者中英混合的驗證。
（4）視頻內容測試
①視頻內容相同、名稱相同，驗證上傳；
②視頻內容相同、名稱不相同，驗證上傳；
③視頻內容不相同、名稱相同，驗證上傳；
④視頻內容不相同、名稱不相同，驗證上傳；
（5）安全性測試
①上傳時服務器空間未滿、或已滿的驗證；
②上傳時跳過驗證的情況；
③上傳時視頻有無保存和加密的驗證；
④上傳的視頻有無敏感信息的處理；
⑤出錯上傳或者上傳失敗的次數限制；
（6）性能測試測試
①上傳時網絡環境佳、弱網與不佳的情況的驗證；
②上傳過程斷網的驗證；
③上傳過程中服務器的資源利用率；
④發送多個上傳請求；
⑤對接口進行壓力測試；
⑥上傳視頻的響應時間、吞吐量以及并發數的記錄
（7）易用性測試
①上傳和發布的按鈕是否清晰可見，是否點擊立即生效；
②提示語是否簡潔易懂
③是否支持快捷鍵，按回車鍵就可以發布等
④鼠標不管點擊哪里，是否有焦點、聚焦的功能
（8）界面測試
①界面的美觀性、設計風格、布局等是否與需求文檔一致；
②按鈕文字是否正確；
③正確還是錯誤上傳的提示語是否正確；
④上傳的頁面顯示和控制檢查；
（9）兼容性測試
①是否支持不同的瀏覽器以及瀏覽器的不同版本都可以進行上傳；
②是否支持不同的移動設備（Android、iOS）；
③上傳視頻的分辨率；

4.公交車刷卡測試用例

功能測試+非公能測試
（1）功能測試：
①公交卡在公交刷卡機上正常感應，并正常扣費；
②根據路程長短，扣費是否符合標準；
③充值金額的最高值
④低于多少金額，卡片不能使用，導致刷卡失敗
⑤金額不足，驗證不能刷卡；
⑥驗證卡片注銷后，無法執行消費、充值等業務；
⑦消磁后不能產生感應；
⑧更換卡片后，驗證卡里的金額正確；
⑨充值時，驗證可以充值，使用時，驗證金額一致；
⑩余額不足時，驗證卡片余額有無提醒；
?驗證非公交卡刷時，是否收費
（2）UI界面測試
①外觀是否符合需求文檔；
②公交卡的長度、寬度、厚度以及質量和光滑程度等，材質是否與設計一致；
③公交卡的圖案與文字的排版是否協調，關鍵字的標識度，文字的清晰度等；
④公交卡的注意事項是否明確；
⑤卡片上的字是否簡潔易懂，you無錯別字等。
（3）性能測試
①驗證頻繁多次刷卡的處理；
②公交卡的有效刷卡次數，最大刷卡次數，能否一次性刷卡成功；
③能否彎曲，最大彎曲程度；
④文字圖案的耐磨性、持久性；
⑤卡的耐熱性、耐寒性；以及高溫、低溫等是否正常使用；
⑥與手機等電磁設備裝在一起，消磁程度；
⑦水洗后，卡片的文字、圖案等不受影響并能正常使用；
⑧非關鍵部位殘缺后，驗證不影響使用
（4）兼容性測試
①在規定適用范圍之外的刷卡機上使用該卡，是否會感應；
②與其他卡片接觸，消磁程度；
③在不同的公交上以及不同的設備上，驗證是否能正常使用
④在高鐵、地鐵、繳水電等刷卡，驗證是否成功。
（5）易用性測試
①卡片是否易攜帶、是否輕便以及防滑。
②使用是否簡單易操作；
③驗證是否感應靈敏度高、反應及時；
④刷卡時，驗證不貼近刷卡機是否會感應到
（6）安全性測試
①卡片是否不鋒利、不傷手；
②個人信息是否有所加密；
③驗證掛失的處理；
④卡片材質是否在不同溫度下對人體有害。

5.一個輸入法的測試用例：

（1）功能測試：
①輸入法的大小寫、特殊和非特殊字符驗證能否輸入成功；
②輸入法的設置功能（包括中英文設置、9/26鍵拼音的設置、繁體字、五筆輸入、手寫設置、語音設置、布局設置、皮膚設置、快捷語、詞庫、其他語言以及消息通知、幫助反饋…）
③輸入法的布局、高度、寬度等的驗證
④手寫設置里的筆跡粗細、顏色、識別速度、橫豎屏識別…；
⑤按鍵方面的驗證，聲音、振動以及氣泡…
⑥表情是否更新、搜索以及顏文字、斗圖…
⑦賬號登錄功能等
⑧鍵盤方面游戲鍵盤、正常鍵盤等的切換…
⑨復制前貼等功能
⑩校準功能
（2）兼容性測試
①屏幕分辨率的驗證
②各個瀏覽器以及其版本的驗證；
③手機品牌的驗證
④網絡兼容性方面的驗證
⑤與其他軟件平臺的兼容性
⑥與其他輸入法的兼容性
⑦與殺毒軟件的兼容性
（3）安全性測試
①輸入的數據是否進行加密
②防止SQL注入
③防止XSS腳本
④敏感詞匯的處理
⑤錯誤輸入文字的次數
（4）易用性測試
①識別速度是否客觀
②有無不易理解詞匯
③各個功能點是否清晰易操作
④校準是否很精確
（5）性能測試
①同時輸入很多個文字時，輸入法是否會崩潰、閃退等
②輸入框升起的時間；
③識別文字的速度時長。
（6）UI測試
①輸入法布局、設計風格是否符合
②輸入法you無錯別字，是否易懂易操作
③輸入框和按鈕的長短、高度等的驗證。

6.設計如下場景的測試用例：

●.功能性測試
–輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功;
–輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示信息正確;
–輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示信息正確。
–用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示信息正確;
–用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示信息正確;
–如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登錄成功;
–如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登錄失敗，并且提示信息正確。
–用戶名和密碼是否大小寫敏感;
–頁面上的密碼框是否加密顯示;
–后臺系統創建的用戶第一次登錄成功時，是否提示修改密碼;
–忘記用戶名和忘記密碼的功能是否可用;
–前端頁面是否根據設計要求限制用戶名和密碼長度;
–如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼,
–更換后的驗證碼是否可用;
–刷新頁面是否會刷新驗證碼
–如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性;
–用戶登錄成功但是會話超時后，繼續操作是否會重定向到用戶登錄界面;
–不同級別的用戶，比如管理員用戶和普通用戶，登錄系統后的權限是否正確;
–后臺系統創建的用戶第一次登錄成功時，是否提示修改密碼;
–頁面默認焦點是否定位在用戶名的輸入框中;
–快捷鍵Tab 和Enter 等，是否可以正常使用。
●安全性測試用例包括:
口用戶密碼后臺存儲是否加密;
口用戶密碼在網絡傳輸過程中是否加密;
口密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼;
口不登錄情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面;
口密碼輸入框是否不支持復制和粘貼;
口密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看;
口用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗證系統的返回面;
口用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串,驗證系統行為是否被篡改;
口連續多次登錄失敗下，系統是否會阻止后續的嘗試以應對暴力破解;
口同一用戶在同一終端的多種瀏覽器.上登錄，驗證登錄功能的互斥性是否符合設計預期;
口同一用戶先后在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
●性能壓力測試用例包括:
口單用戶登錄的響應時間是否小于3秒;
口單用戶登錄時，后臺請求數量是否過多;
口高并發場景下用戶登錄的響應時間是否小于5秒;
口高并發場景下服務端的監控指標是否符合預期;
口高集合點并發場景下，是否存在資源死鎖和不合理的資源等待;
口長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏。
●兼容性測試用例包括:
口不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性;
口相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性;
口不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性;
口不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。

擴展一些在面試中的有關測試其他問題

1.如果在公司發現忽然不適合這份工作我會怎么樣
首先說明我對這份工作其實很喜歡、很熱愛，才來面試這份工作；如果入職一段時間后，公司發現我個人有某些地方不太適合這份工作，我希望公司能夠立即提出，對于缺點和不足，我會盡力改正，希望能盡力跟上公司的步伐；
但若真的是能力不足，不能勝任這份工作，我可能會想到去其他比較適合我的崗位，我會和公司協商后交接工作，以免給公司造成重大損失。

2.在公司3-5年的規劃
我會努力踏實做好我自己的本職工作，在工作中不斷學習提高自己XXX方面的水平（通過XXX考試獲得證書），在1-2年時間內建立起對市場的全面了解。積累我自己的經驗，爭取成為一名合格的員工，在一年內，成為獨當一面的員工，在兩年內成為骨干方面，通過業余時間學習，通過在工作中學習，并且希望從公司的資源得到幫助。也希望通過自己的努力給公司爭取一些業績。

3.排序算法有哪些？

排序(Sorting) 是計算機程序設計中的一種重要操作，它的功能是將一個數據元素（或記錄）的任意序列，重新排列成一個關鍵字有序的序列。
排序就是把集合中的元素按照一定的次序排序在一起。一般來說有升序排列和降序排列2種排序，在算法中有8中基本排序：

(1)冒泡排序；
(2)選擇排序；
(3)插入排序；
(4)希爾排序；
(5)歸并排序；
(6)快速排序；
(7)基數排序；
(8)堆排序；
(9)計數排序；
(10)桶排序。

4.進程調度的算法有哪些？

1、先來先服務（FCFS）
處于就緒態的進程按先后順序鏈入到就緒隊列中，而FCFS調度算法按就緒進程進入就緒隊列的先后次序選擇當前最先進入就緒隊列的進程來執行，直到此進程阻塞或結束，才進行下一次的進程選擇調度。
FCFS調度算法采用的是不可搶占的調度方式，一旦一個進程占有處理機，就一直運行下去，直到該進程完成其工作，或因等待某一事件而不能繼續執行時，才釋放處理機。操作系統如果采用這種進程調度方式，則一個運行時間長且正在運行的進程會使很多晚到的且運行時間短的進程的等待時間過長。

2、短作業優先（SJF）
其實目前作業的提法越來越少，我們姑且把“作業”用“進程”來替換，改稱為短進程優先調度算法，此算法選擇就緒隊列中確切（或估計）運行時間最短的進程進入執行。它既可采用可搶占調度方式，也可采用不可搶占調度方式。可搶占的短進程優先調度算法通常也叫做最短剩余時間優先（Shortest
Remaining Time
First，SRTF）調度算法。短進程優先調度算法能有效地縮短進程的平均周轉時間，提高系統的吞吐量，但不利于長進程的運行。而且如果進程的運行時間是“估計”出來的話，會導致由于估計的運行時間不一定準確，而不能實際做到短作業優先。

3、時間片輪轉（RR） RR 調度算法與FCFS
調度算法在選擇進程上類似，但在調度的時機選擇上不同。RR調度算法定義了一個的時間單元，稱為時間片（或時間量）。一個時間片通常在1～100
ms之間。當正在運行的進程用完了時間片后，即使此進程還要運行，操作系統也不讓它繼續運行，而是從就緒隊列依次選擇下一個處于就緒態的進程執行，而被剝奪CPU使用的進程返回到就緒隊列的末尾，等待再次被調度。時間片的大小可調整，如果時間片大到讓一個進程足以完成其全部工作，這種算法就退化為FCFS調度算法；若時間片設置得很小，那么處理機在進程之間的進程上下文切換工作過于頻繁，使得真正用于運行用戶程序的時間減少。時間片可以靜態設置好，也可根據系統當前負載狀況和運行情況動態調整，時間片大小的動態調整需要考慮就緒態進程個數、進程上下文切換開銷、系統吞吐量、系統響應時間等多方面因素。

4、高響應比優先（Highest Response Ratio First，HRRF）
HRRF調度算法是介于先來先服務算法與最短進程優先算法之間的一種折中算法

進程間的通信有哪些方式？

進程間通信（IPC，InterProcess Communication）是指在不同進程之間傳播或交換信息。
IPC的方式通常有管道（包括無名管道和命名管道）、消息隊列、信號量、共享存儲、Socket、Streams等。其中
Socket和Streams支持不同主機上的兩個進程IPC。

知道游標嘛。。。數據庫里的(幾乎不考)？

游標，也有人稱為光標。概括的講，它是基于記錄的。 過去，關系型數據庫沒有象現在這樣被廣泛的應用。那時候，人們大多使用 dBase
這樣的小型數據庫軟件。這類數據庫確切的說應為數據文件管理軟件。他們是面向記錄的。
不過，這種方式也許更符合人們的習慣。比如，我們在電話本中查找號碼，在學生檔案中查找檔案，最終都要歸結于其中的一個號碼，一個檔案，那就是一條記錄。現實生活中，我們在一張表格中尋找某一項時，可能會用手一條一條逐行的掃過，以幫助我們找到所需的那條記錄。對應于數據庫來說，這就是游標的模型。所以，你可以這樣想象：表格是數據庫中的表，而我們的手好比是游標

http協議狀態碼
①1xx: 臨時的響應
②2xx: 服務器成功接受了客戶單的請求；
③3xx: 請求失敗，客戶端瀏覽器必須采用更多的操作來實現請求；
④4xx: 發生錯誤，客戶端似乎有問題，客戶端請求不存在的頁面，未提供有效地身份驗證信息 404–網頁未找到；；403是指無權限訪問，服務器接受了請求但拒絕執行
⑤5xx: 服務器由于遇到錯誤不能完成該請求。服務器內部錯誤。

.測試用例八大要素：
ID 所屬項目 用例標題 重要級別 預置條件 測試輸入 操作步驟 預期結果 用例作者 測試結果

http與htpps的區別：

①傳輸信息安全性不同：http明文輸入----HTTPS是具有安全性的ssl加密傳輸協議；
②連接方式不同：
http連接簡單，無狀態；------HTTPS由SSL+http協議構建的可以進行加密傳輸、身份認證的網絡協議。
③端口不同： 80 -----443
④證書認證方式不同：http—免費申請；------HTTPS：需要ca申請證書。

測試工作的步驟：

需求評審—制定測試計劃—設計測試用例—執行測試用例—測試用例評審—冒煙測試—一輪/N輪測試(發現bug使用缺陷管理工具jira\redmine\禪道)—回歸測試—撰寫文檔(測試報告、用戶手冊等)

對異地工作的態度（發散題）：

年輕人就應該多出去，想鍛煉一下自己的能力，而且XXX地方發展勢頭很好，很適合我個人能力的提高，而且我適應能力很強，自理能力也不差，所以外地工作對我來說不是個問題。

總結

以上是生活随笔為你收集整理的经典场景试题，测试用例编写的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。