專案的測驗流程
-
拿到需求檔案后，寫測驗用例
-
審核測驗用例
-
等待開發包
-
部署測驗環境
-
冒煙測驗（網頁架構圖）
-
頁面初始化測驗（查看資料庫中的資料內容和頁面展示的內容是否一致，并且是否按照某些順序排列）
7 .具體執行測驗用例（幾乎所有的功能測驗、流程法、場景法）
-
發現缺陷就要再填寫缺陷表
-
非功能性測驗（sql、js注入、頁面效率、繞過js驗證直接添加資料到資料庫）
-
書寫最終的測驗報告
測驗用例設計方法
等價類、邊界值、正交試驗法、狀態遷移法、因果圖、場景測驗法、例外分析法、因果圖、錯誤猜測法、判定
測驗用例的要素
Id 主題 測驗名稱 創建日期 設計者 描述 步驟名 步驟描述 預期結果 執行狀態
測驗的優先級
-
先測驗經過變更的部分，然后測驗沒有變更的部分
-
先測驗程式的核心功能，然后測驗一般功能
-
先測驗邏輯性的功能，然后測驗業務性的功能
-
先測驗常規情況，然后測驗例外情況
-
先測驗功能，然后測驗性能
測驗報告包含哪些內容
1.寫測驗背景
2.測驗目標
3.測驗范圍
4.測驗環境
5.測驗資料
6.測驗標準（重點）
7.測驗進度
8.測驗結果
9.測驗結論
有的公司會采用非標準的測驗報告
大致會包含 測驗所用時間 測驗環境 測驗人員 測驗發現bug數量 已修復bug數量 遺留bug 遺留bug原因
BUG的生命周期
提交–開發驗證–接受–拒絕–開發解決–測驗人員驗證–關閉–不通過打開
BUG的狀態
-
NEW：所有提交到開發對接的問題狀態為NEW，表示為未處理
-
OPEN：開發對接人初判為需流轉問題，指定測驗人員和開發人員，狀態為OPEN，
-
REFUSE：開發對接人判斷為不需要流轉至下環節的問題，狀態為REFUSE，并且填寫原因
-
FIXED：開發人員完成修復，待測驗，狀態為FIXED
-
REOPEN：測似人員針對開發人員的修復結果測驗部通過，狀態為REOPEN
-
CLOSE：測驗人員判斷問題為需求或其他問題，需填寫原因；
缺陷的要素
缺陷標題 缺陷狀態 提交人 負責人 優先級 嚴重程度 缺陷描述 時間 截圖
缺陷的級別
致命問題 核心功能不可用或系統崩潰
嚴重問題 業務主要流程無法使用，業務主要流程中的某個功能存在缺陷導致主要流程無法繼續使用
一般問題 一般性問題，非主要流程上的功能缺陷
輕微問題 界面ui問題 提示不規范等
建議性問題 根據自己的經驗提一些建議性的問題
WEB測驗與APP測驗的區別
- 架構不同，
web端是b/s架構的，b/s架構是基于瀏覽器地址訪問的
app端是c/s架構的，c/s架構是要有客戶端作為載體的
- 版本發布的方式和流程不同，
web發版本，開發部署新的代碼到對應服務器地址，就可統一實作web端的更新
app發版本，開發需要打包（apk包和ipa包），打包之后需要發布到對應的渠道
- 兼容性
web，測驗不同瀏覽器的兼容性（ie、chrome、firefox、360、QQ）
app，測驗不同的解析度、螢屏尺寸、手機品牌、系統版本
- 性能方面
web，測驗回應的時間
app，測驗回應時間、流量、耗電量、CPU、GPU、memory
- 安全性
web，sql注入，xss攻擊等
app，https加密、簽名、加固、密碼加密等
6、app測驗特點
適配性測驗
網路測驗
在線升級測驗
中斷測驗
耗電量測驗
弱網測驗
安裝卸載測驗
流量測驗
如果對軟體測驗有興趣，想了解更多的測驗知識，解決測驗問題,以及入門指導，幫你解決測驗中遇到的困惑，我們這里有技術高手，如果你正在找作業或者剛剛學校出來，又或者已經作業但是經常覺得難點很多，覺得自己測驗方面學的不夠精想要繼續學習的，想轉行怕學不會的， 都可以加入我們1079636098，群內可領取最新軟體測驗大廠面試資料和Python自動化、介面、框架搭建學習資料！
app測驗的主要內容
- 功能測驗
業務邏輯正確性的測驗
- 兼容性測驗
系統版本
解析度
如果一個bug，開發認為不是一個bug，怎么處理
常用linux命令
什么情況下定位不到元素
GET請求和POST請求的區別
網路情況
- 例外測驗
熱啟動
網路切換
電話資訊終端恢復
-
升級、安裝、卸載
-
健壯性測驗
手機資源消耗
流量消耗
電量測驗
崩潰恢復
如果一個bug，開發認為不是一個bug，怎么處理
-
將問題提交到缺陷管理庫里面進行備案，
-
獲取判斷的依據和標準
根據需求說明書、產品說明、設計檔案等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有檔案依據，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
-
合理的論述，向測驗經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒，
-
等待測驗經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定，
常用linux命令
-
ifconfig 查看IP地址
-
cat 用于顯示指定檔案的全部內容
-
more 用分頁的形式顯示指定檔案的內容
-
mkdir 創建目錄
-
touch 創建新的檔案
-
grep 查找檔案里符合條件的字串
-
find 查找指定的檔案
-
tail -f 用于自動重繪顯示檔案后N行資料內容
-
kill -9 強制結束
-
netstat -anp | grep 埠號 查看埠
-
chmod -R 777 賦予777權限
什么情況下定位不到元素
-
代碼寫錯
-
元素未出現（需要元素等待）
-
元素在iframe中
-
多視窗
-
出現彈窗（系統彈窗、JS彈窗）
-
元素屬性值是動態加載的
-
元素無法確定唯一性
-
只讀屬性（元素不可操作）
GET請求和POST請求的區別
-
GET使用URL或Cookies傳參，POST將資料放在BODY中
-
GET的URL會有長度上的限制，POST的資料則可以非常大
-
POST比GET安全，因為在地址欄不可見
-
一般GET用來獲取資料，POST用來發送資料
為什么要做介面測驗
-
越底層發現BUG，修復成本越低
-
前端發生變化時，后端介面可以不用變
-
檢查系統的安全性、穩定性，前端傳參不可信
介面測驗是怎么做的
–由于我們專案前后端呼叫主要是基于http協議的介面，所以測驗介面時主要是通過工具或代碼模擬http請求的發送與接收，工具有很多如：postman、jmeter、soupUI等，
–也可以用 介面自動化來實作，就是用代碼實作，框架和UI自動化差不多，發送請求用斷言來判斷，
介面測驗的重點
-
檢查介面回傳的資料是否與預期的結果一致
-
檢查介面的容錯性，加入傳遞的型別錯誤時是否可以處理
-
介面測驗的邊界值
-
介面的性能
-
介面的安全性
http狀態碼
-
1xx：請求正常，但是無回應，只有在實驗狀態下使用
-
2xx：2開頭的表示發送成功
-
3xx：3開頭的代表重定向，常見302
-
4xx：400代表客戶端發送的語法有錯誤，401代表訪問的頁面沒有授權，403 無權限訪問該網頁，404代表沒有這個頁面，415 格式錯誤
-
5xx：5開頭的代表服務器例外，500代表服務器內部例外，504代表服務器超時
cookies和session的區別
-
cookies資料存放在客戶的瀏覽器上，session資料放在服務器上
-
cookies不是很安全，別人可以分析存放在本地的cookies并進行cookies欺騙考慮到安全應當使用session
-
session會在一定時間內保存在服務器上，當訪問增多，會比較占用，你服務器的性能考慮到減輕服務器性能方面，應當使用cookies
常用的adb命令
-
adb start-server 啟動adb服務
-
adb kill-server 關閉adb服務
-
adb devices 查看設備號
-
adb push 電腦 手機
-
adb pull 手機 電腦
-
adb logcat | grep 包名（unix）
-
adb logcat | findstr 包名 （win）
-
adb shell 進入shell命令列
-
adb install 安裝app到手機上
-
adb uninstall 卸載app到手機上
-
adb logcat > 檔案名 輸出log到檔案
-
adb shell top 測驗app的資源消耗命令
產品的業務流程
決議
問你簡歷上寫的某個專案整體的業務流程
比如電商專案中的注冊功能，從開始注冊到注冊成功的整個程序
版本符合上線的標準是什么
驗收標準
(1) 軟體需求分析說明書中定義的所有功能已全部實作，性能指標全部達到要求，
(2) 在驗收測驗中發現的錯誤已經得到修改，各級缺陷修復率達到標準
(3) 所有測驗項沒有殘余緊急、嚴重級別錯誤，
(4) 需求分析檔案、設計檔案和編碼實作一致，
(5) 驗收測驗工件齊全（測驗計劃、測驗用例、測驗日志、測驗通知單、測驗分析報告，待驗收的軟體安裝程
序，）
缺陷修復率標準
(1) 緊急、嚴重級別錯誤修復率應達到100%;
(2) 普通級別錯誤修復率應達到95%以上;
(3) 優化級別錯誤修復率應達到60%以上;
注：專案緊急時，普通級別錯誤修復率達60% 以上；優化級別錯誤修復率達20% 即可，
服務器運行狀態回應指標
(1) cpu% 并發期間最大使用率應不超過70-80%，如有集合點并發可允許短暫接近或到達100& 但大部分不
應查過95%;
(2) memery 測驗期間保證記憶體充足可用記憶體不少于20%;
(3) disk 監控硬碟是否有讀寫不超過40%;
(4) cpu load average 不應超過cpu 核心數*2 或者不超過cpu 核心數，
測驗用例評審程序及相關參與人員
1:評審的程序
A:開始前做好如下準備
1、確定需要評審的原因
2、確定進行評審的時機
3、確定參與評審人員
4、明確評審的內容
5、確定評審結束標準
6、提前至少一天將需要評審的內容以郵件的形式發送給評審會議相關人員，并注明詳審時間、地點及償參與人員等，
7、 在郵件中提醒評審會議相關人員至少簡讀一遍評審內容，并記錄相關的疑問，以便在評審會議上提出，
8、 會議主持者(一般為用例撰寫人員)應在會議前整理相關疑問，以便在會議上提出，
B：開始評審
1、 召開評審會議，與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄，
2、 通用郵件與相關人員溝通
3、 通用IM工具直接與相關人員交流
4、根據評審內容進行評審
2：評審內容
1、 用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆寫，
2、 優先極安排是否合理，
3、 是否覆寫測驗需求上的所有功能點，
4、 用例是否具有很好可執行性，例如用例的前提條件、執行步驟、輸入資料和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法，
5、 是否已經洗掉了冗余的用例，
6、 是否包含充分的負面測驗用例，充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟體，其中80%的代碼都是在“保護”20%的功能實作，
7、 是否從用戶層面來設計用戶使用場景和使用流程的測驗用例，
8、 是否簡潔，復用性強，例如，可將重復度高的步驟或程序抽取出來定義為一些可復用標準步驟，
3：參與評審人員（這里會分為多個級別進行評審）
1、 部門評審，測驗部門全體成員參與的評審，
2、公司評審，這里包括了專案經理、需求分析人員、架構設計人員、開發人員和測驗人員，
3、 客戶評審，包括了客戶方的開發人員和測驗人員，這種情況在外包公司比較常見
寫在最后：
愿你我相遇，皆有所獲！ 歡迎關注微信公眾號：程式員一菲
1.免費領取一份216頁軟體測驗工程師面試寶典檔案資料，
2.軟體測驗學習路線以及相對應的視頻學習教程免費分享！
在這里推薦一個軟體測驗交流群，qq:642830685,群中會不定期分享軟體測驗資源，測驗面試題以及測驗資源，大家可以在群中積極交流技術問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/252503.html
標籤：其他