相信大家一直都在為面試的時候的筆試 以及面試官所提出的問題而煩惱吧 今天就來談談我的一些面試經驗以及面試復盤吧
剛入門的時候肯定是都是圍繞着黑盒測試也就是所謂的功能測試為中心，再進行發散性的測試，其中包括一些測試方法及其測試用例的設計讓你闡述一下你在日常工作中是如何進行測試的。相信大家都遇到過這種問題，直到前不久我去長沙面試找工作的時候，技術方面已經不僅僅只局限於功能的一點點，更多的是性能跟安全。接口自動化以及測開到沒有要求那么多，可見現在的趨勢發展慢慢的可以延伸到安全跟性能了，那么我總結一下我面試時遇到過的問題吧，可能在這篇文章的你也遇到過類似的，可以一起吐槽一下呀！
1、設計測試用例的八大要素
答：測試用例的編號、被測模塊、測試用例的標題、前置條件、操作步驟、預期結果、實際結果、測試用例的優先級。
2、整個軟件的測試周期是怎么樣的
3、如何對一部電梯進行測試
2.報警器是否能用
3.電梯上/下行運行是否正常
4.電梯通風口
5.顯示屏是否正常
6.手機在電梯中是否有信號
7.電梯門的打開/關閉是否正常
8.電梯是否與其他設備兼容
9.電梯門是否有感應裝置
2.根據按鍵次數不同選擇是否選擇和取消
2.電梯內部是否具有扶手
3.對特殊人群是否友好
4.按鈕的寬度
2.電梯的形狀（原型，方形）
3.電梯內的空間大小
2.電梯的繩索在一直上升狀態下最大的運行時間
3.電梯的繩索在一直下降狀態下最大運行時間
1.電梯在不同氣壓下的運行情況
2.電梯與樓層牆壁之間的縫隙
3.電梯在不同電壓下運行的情況
安全性：1.暴力測試（在電梯內中劇烈跳動，用錘子砸）
2.攝像頭能否正常看清楚電梯內的用戶
3.能否在電梯出現故障的情況下，容易將用戶解救出來
4.在電梯停電時是否有臨時電源進行供應
4、測試方法有哪些，請舉例說明一下
5、一個登陸接口 讓你去設計測試用例 請從 功能 安全 性能幾個方面做一個設計
用例設計：測試需求分析完成后，開始用例設計，主要可以從以下幾個方面考慮：
功能測試(Function Test)
1、輸入正確的賬號和密碼，點擊提交按鈕，驗證是否能正確登錄。（正常輸入）
2、輸入錯誤的賬號或者密碼, 驗證登錄會失敗，並且提示相應的錯誤信息。（錯誤校驗）
3、登錄成功后能否跳轉到正確的頁面（低）
4、賬號和密碼，如果太短或者太長，應該怎么處理（安全性，密碼太短時是否有提示）
5、賬號和密碼，中有特殊字符（比如空格），和其他非英文的情況（是否做了過濾）
6、記住賬號的功能
7、登錄失敗后，不能記錄密碼的功能
8、賬號和密碼前后有空格的處理
9、密碼是否加密顯示（星號圓點等）
10、牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），刷新或換一個按鈕是否好用
11、登錄頁面中的注冊、忘記密碼，登出用另一帳號登錄等鏈接是否正確
12、輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
13、什么都不輸入，點擊提交按鈕，看提示信息。（非空檢查）
界面測試(UI Test)
1、布局是否合理，2個Testbox 和一個按鈕是否對齊
2、Testbox和按鈕的長度，高度是否復合要求
3、界面的設計風格是否與UI的設計風格統一
4、界面中的文字簡潔易懂，沒有錯別字。
性能測試(Performance Test)
1、打開登錄頁面，需要幾秒
2 、輸入正確的賬號和密碼后，登錄成功跳轉到新頁面，不超過5秒
安全性測試(Security Test)
1、登錄成功后生成的Cookie是否有HttpOnly(降低腳本盜取風險)
2、賬號和密碼是否通過加密的方式，發送給Web服務器
3、賬號和密碼的驗證，應該是用服務器端驗證，而不能單單是在客戶端用javaScript驗證
4、賬號和密碼的輸入框，應該屏蔽SQL注入攻擊
5、賬號和密碼的的輸入框，應該禁止輸入腳本（防止XSS攻擊）
6、錯誤登錄的次數限制（防止暴力破解）
7、考慮是否支持多用戶在同一機器上登錄；
8、考慮一用戶在多台機器上登錄
可用性測試(Usability Test)
1、是否可以全用鍵盤操作，是否有快捷鍵
2、輸入賬號，密碼后按回車，是否可以登錄
3、輸入框是否可以以Tab鍵切換
兼容性測試（Compatibility Test）
1、主流的瀏覽器下能否顯示正常已經功能正常（IE6~11, FireFox, Chrome, Safari 等 ）
2、不同的平台是否能正常工作，比如Windows, Mac
3、移動設備上是否正常工作，比如iPhone, Android
4、不同的分辨率
6、如果用fiddler做斷點，設置弱網？
7、能具體說說安全測試中的sql注入嗎？如果讓你來做你會如何預防？
原文鏈接：https://blog.csdn.net/github_36032947/article/details/78442189
$sql = "SELECT * FROM article WHERE id =",$id
正常情況下，應該返回一個id=1的文章信息。那么，如果在瀏覽器地址欄輸入：learn.me/sql/article.php?id=-1 OR 1 =1，這就是一個SQL注入攻擊了，可能會返回所有文章的相關信息。為什么會這樣呢？
這是因為，id = -1永遠是false，1=1永遠是true，所有整個where語句永遠是ture，所以where條件相當於沒有加where條件，那么查詢的結果相當於整張表的內容
有這樣一個用戶登錄場景：登錄界面包括用戶名和密碼輸入框，以及提交按鈕。輸入用戶名和密碼，提交。
這是一個post請求，登錄時調用接口learn.me/sql/login.html，首先連接數據庫，然后后台對post請求參數中攜帶的用戶名、密碼進行參數校驗，即sql的查詢過程。假設正確的用戶名和密碼為user和pwd123，輸入正確的用戶名和密碼、提交，相當於調用了以下的SQL語句：
SELECT * FROM user WHERE username = 'user' ADN password = 'pwd123'
由於用戶名和密碼都是字符串，SQL注入方法即把參數攜帶的數據變成mysql中注釋的字符串。mysql中有2種注釋的方法：
1）'#'：'#'后所有的字符串都會被當成注釋來處理
用戶名輸入：user'#（單引號閉合user左邊的單引號），密碼隨意輸入，如：111，然后點擊提交按鈕。等價於SQL語句：
SELECT * FROM user WHERE username = 'user'#'ADN password = '111'
'#'后面都被注釋掉了，相當於：
SELECT * FROM user WHERE username = 'user'
2）'-- ' （--后面有個空格）：'-- '后面的字符串都會被當成注釋來處理
用戶名輸入：user'-- （注意--后面有個空格，單引號閉合user左邊的單引號），密碼隨意輸入，如：111，然后點擊提交按鈕。等價於SQL語句：
SELECT * FROM user WHERE username = 'user'-- 'AND password = '1111'
'-- '后面都被注釋掉了，相當於：SELECT * FROM user WHERE username = 'user'
因此，以上兩種情況可能輸入一個錯誤的密碼或者不輸入密碼就可登錄用戶名為'user'的賬號，這是十分危險的事情。
如何預防SQL注入？ 這是開發人員應該思考的問題，作為測試人員，了解如何預防SQL注入，可以在發現注入攻擊bug時，對bug產生原因進行定位。 1）嚴格檢查輸入變量的類型和格式 對於整數參數，加判斷條件：不能為空、參數類型必須為數字 對於字符串參數，可以使用正則表達式進行過濾：如：必須為[0-9a-zA-Z]范圍內的字符串 2）過濾和轉義特殊字符 在username這個變量前進行轉義，對'、"、\等特殊字符進行轉義，如：php中的addslashes()函數對username參數進行轉義 3）利用mysql的預編譯機制 把sql語句的模板（變量采用占位符進行占位）發送給mysql服務器，mysql服務器對sql語句的模板進行編譯，編譯之后根據語句的優化分析對相應的索引進行優化，在最終綁定參數時把相應的參數傳送給mysql服務器，直接進行執行，節省了sql查詢時間，以及mysql服務器的資源，達到一次編譯、多次執行的目的，除此之外，還可以防止SQL注入。具體是怎樣防止SQL注入的呢？實際上當將綁定的參數傳到mysql服務器，mysql服務器對參數進行編譯，即填充到相應的占位符的過程中，做了轉義操作。
8、如何使用Charles做斷點，修改入參請求
9、mysql 請寫出左表查詢的語句
10、mysql 請寫出右邊查詢的語句
歡迎轉載 請注明原出處 https://www.cnblogs.com/yushengaqingzhijiao/p/14514826.html 但未經本人允許轉載或復制 如有發現需要承擔法律責任 @罐裝七喜的后花園