[TOC] ## B/S架構與C/S架構的區別 * 由于瀏覽器的內核不同，所以b/s架構需要重點考慮在不同瀏覽器中的兼容性問題 * c/s架構則需要著重考慮在不同平臺的安裝、卸載與升級 <br /> ## 簡述HTTP協議 HTTP協議是一個超文本傳輸協議，由請求與響應組成，常見的請求方式有`get`與`post` 通常用get請求的請求參數會跟隨請求地址一起發送，通常用來向服務器上獲取數據，傳輸速度快，但相對不安全。 而post請求的請求參數會在請求體中單獨發送，通常用來向服務器傳遞數據，傳輸速度比get慢，但相對安全。 常見的HTTP狀態碼有`200 請求成功`，`301 永久移動`，`302 臨時移動`，`404 找不到資源`，`403 權限被拒絕`，`500 服務器內部錯誤` <br /> ## cookie與session的區別與聯系 1. cookie的數據存放在瀏覽器上，而session的數據存放在服務器上的。 2. cookie不是很安全，別人可以利用本地的cookie進行cookie欺騙，考慮安全的話，應該使用session 3. session會在一定時間內，保存在服務器上，當訪問增多時，會占用服務器資源。 <br /> ## 什么是軟件測試？軟件測試的定義是什么？ 用簡單的話來概述，就是在把軟件交付給用戶使用前，我們先用一遍，站在用戶的角度，模擬各種正常的和異常的場景來使用軟件。 <br /> ## 測試的目的是什么？ 軟件測試不僅僅是為了發現軟件缺陷與錯誤，而且也是對軟件質量進行度量和評估，以提高軟件的質量，降低軟件開發成本。 <br /> ## 軟件測試的原則 1. 所有的軟件測試都應追溯到用戶需求。 2. 盡早地和不斷地進行軟件測試 3. 完全測試是不可能的，測試需要終止。 4. 充分注意測試中的群集現象。 5. 程序員應避免檢查自己的程序。 6. 盡量避免測試的隨意性 <br /> ## 軟件測試分為哪幾個階段 單元測試、集成測試、系統測試、驗收測試。 <br /> ## 軟件測試的風險有哪些？ 風險也包括進度風險、質量風險、人員風險、需求變更等 <br /> ## 什么是單元測試（Unit Testing） 單元測試是指對軟件中的最小可測試單元進行檢查和驗證。 <br /> ## 集成測試的關注點 在把各個模塊連接起來時，查看穿越模塊接口的數據是否會丟失。 <br /> ## 系統測試范圍/策略/類型 功能測試、用戶體驗測試、性能測試、UI測試、兼容性測試、安裝測試、文檔測試、穩定性測試等 <br /> ## а測試與?測試的區別 а測試是公司組織內部人員對即將上市的產品進行測試。 ?測試是公司組織的典型客戶在日常工作中實際使用，然后公司再進行完善。 <br /> ## 正式的驗收測試怎么做？ 在驗收測試之前，我們會制定測試方案，選擇級別高的用例，在UAT測試環境上進行測試，如果測試通過，驗收測試就通過了。 <br /> ## 質量的六大特性/測試一個軟件從哪些方面進行測試 功能、安全、用戶體驗、兼容性、性能、可靠性 <br /> ## 常見的安全測試類型 1. 檢查敏感信息是否在前端加密，在網絡傳送過程中是否加密； 2. 檢查系統是否存在SQL注入漏洞； 3. 檢查系統是否存在XSS注入漏洞； 補充；XSS注入又稱(跨站點腳本攻擊)，使用的就是JS腳本 <br /> ## 白盒、黑盒與灰盒測試的區別 * 白盒測試主要是對程序的內部結構與算法 * 黑盒測試是不考慮程序內部邏輯情況下， 檢查程序是否滿足需求 * 關注接口所實現的功能，是否與需求一致。 <br /> ## 冒煙測試的目的 檢查系統的主要流程能夠使用，確保基本功能正常。 <br /> ## 全量回歸與部分回歸的區別 * 全量回歸主要是對軟件的新版本測試時，重復執行上一個版本測試時使用的測試用例，防止出現“以前沒有問題的地方現在出問題了” * 部分回歸就是在測試過程中，發現bug，開發修復后，我們會去驗證該缺陷是否被修復，以及驗證相關聯的模塊是否受影響。 <br /> ## 回歸測試怎么做？ 首先，把bug單對應的用例執行一遍，還要檢查有數據交互的模塊會不會受影響，有沒有引入新的問題； 項目上線前，還要把當前版本的重要功能以及冒煙測試的用例都回歸一遍，確保重要功能上線后不出問題。 <br /> ## 需求分析的目的 澄清需求，提取測試點 <br /> ## 常見軟件的默認端口 * http :`80` * https:`443` * tomcat:`8080` * mysql:`3306` * oracle:`1521` <br /> ## tomcat 目錄內容 * tomcat的`bin`目錄是存放啟動或者停止tomcat服務的指令 * tomcat的`webapps`目錄，是存放項目的安裝包的目錄 * tomcat的`logs`目錄，默認是存放日志的目錄 <br /> ## 為什么要編寫測試計劃？/測試計劃的目的 為了規范軟件測試內容、方法和過程，所以在對軟件進行測試之前，必須創建測試計劃。 <br /> ## 什么時間開始編寫測試計劃？ 需求分析后編寫測試計劃，在整個測試工作過程中，不斷修改 <br /> ## 由誰來編寫測試計劃？ 具有豐富經驗的項目測試負責人 <br /> ## 測試計劃的內容是什么？ **測試項目的背景、測試范圍和測試策略、測試環境、測試開始和結束條件、進度安排，測試組織，以及與測試有關的風險**等方面的內容。 <br /> ## 軟件開始和結束條件 軟件測試開始的條件是在項目啟動、需求分析開始時隨之啟動。 結束條件(項目上線的條件)：是需要需求覆蓋率、用例執行率、缺陷遺留率達到預定質量目標。 一般 用例對需求的覆蓋率達到100%；致命、嚴重級別的缺陷必須當天解決，一般、輕微級別的缺陷，遺留率是30%以下。 <br /> ## 用例的級別如何劃分 測試用例級別的劃分，一般是依據用戶使用該場景的頻率，和該功能對系統的影響程度來確定 <br /> ## 什么是用例顆粒度？ 顆粒度，指的是粗細程度。粒度大，就是說一個用例所涵蓋的關注內容比較多，反之同理。 通常，一個用例測試一個場景即可。 <br /> ## 寫好測試用例的關鍵 熟悉業務，了解系統； 充分考慮用戶的各種正常和異常的使用場景，覆蓋用戶的需求； 用例的顆粒大小要均勻。通常，一個測試用例對應一個場景； 用例各個要素要齊全，步驟應該足夠詳細，容易被其它測試工程師讀懂，并能順利執行； 做好用例評審，及時更新測試用例。 <br /> ## 怎樣保證覆蓋用戶需求？ 項目開始前，我們會先熟悉需求，畫好流程圖，保證整個流程都覆蓋全面，小組之間每個人都要根據各自的流程圖，各個功能點有哪些限制條件，來講解一下自己對測試點的理解，防止之后編寫測試用例時出現遺漏；用例編寫完之后，再進行用例的評審，看看測試點有沒有用遺漏，對需求理解有沒有錯誤，測試場景是否覆蓋完全。 <br /> ## 測試用例的狀態有哪些 當用例還尚未被執行時，是`No Test`,`未執行狀態` 當執行結果與預期結果相符時，是`Pass`,`通過狀態` 當執行結果與預期結果不符時，是`Fail`,`失敗狀態` 當因為軟件有缺陷而妨礙了用例步驟的執行，且該缺陷并不是我們的測試點，則用例是`Block`,`阻礙狀態`。 當用例正在執行中，但是需要耗較多時間去觀察其結果，是`Investigate`,`觀察中狀態`。 <br /> ## 測試用例的要素 用例編號，用例標題，優先級，預置條件、測試步驟、預計結果 <br /> ## 測試環境怎么搭建的？ 搭建環境前，開發都會給到我們一份系統發布手冊，我們會根據這個手冊來搭建。比如，我最近這一個項目，就是搭建在Linux系統下的，web服務器用的是Tomcat8，MySQL版本是5.7，程序是JAVA編寫的，首先我們向開發拿到編譯好的安裝包，然后用CRT遠程連接上Linux系統，把tomcat服務器停掉，把程序包放到webapps目錄下，然后再啟動tomcat服務器就可以了。 <br /> ## 偶然性問題的處理 1. 發現bug之后，我們會先截圖，如果確定是偶然性的問題，會將日志和截圖一起提單給開發定位； 2. 如果缺陷在當前版本無法復現，且缺陷的影響程度比較低，可以提交問題單進行跟蹤，跟蹤三個版本，如果后三個版本都無法復現，就可以關閉該缺陷； 3. 如果是很嚴重的Bug，比如導致系統崩潰等，并且，實在沒有再次出現，除了要及時反饋給上級之外，最后還要寫到測試報告中，說明出現了什么現象，但無法再現！ <br /> ## 當我們認為某個地方是bug，但開發認為不是bug，怎么處理？ 1. 先跟開發溝通，確認系統的實際結果是不是和需求有不一致的地方；有些地方可能需求沒提及，但是用戶體檢不好，我們也可以認為是bug。 2. 如果開發以不影響用戶使用為理由，拒絕修改，我們可以和產品經理，測試經理等人員進行討論，確定是否要修改，如果大家都一致認為不用改，就不改。 <br /> ## 產品在上線后用戶發現bug，這時測試人員應做哪些工作？ 1. 測試人員復現問題后，提交問題單進行跟蹤； 2. 評估該問題的嚴重程度，以及修復問題時的影響范圍，回歸測試需要測試哪些功能； 3. 問題修復后，先在測試環境上回歸，通過后再在生產環境上打補丁，然后再進行回歸測試； 4. 總結經驗，分析問題發生的原因，避免下次出現同樣問題。 <br /> ## 二八定理 80%的缺陷出現在 20%的模塊。 <br /> ## 如何跟蹤缺陷 當發現缺陷后，我們要在禪道上提交問題單給開發，并每隔一段時間(間隔一個小時，或兩個小時都可以)去檢查缺陷是否被處理，如果沒及時處理，就要提示開發，讓開發及時修復問題，問題修復后，要及時進行回歸測試。 <br /> ## 缺陷的狀態 激活,確認,已解決,關閉 <br /> ## 缺陷的等級 致命,嚴重,一般,輕微 <br /> ## 缺陷單應該包含這些要素 缺陷標題，嚴重級別，問題所屬模塊，復現步驟，預期結果，實際結果，有關的日志和截圖。 <br /> ## 測試報告的主要內容 人力投入，用例統計，問題單分類統計，遺留bug情況，測試風險，測試對象評估，測試結論 <br /> ## 如何定位bug： 1. 檢查測試環境配置是否有問題，測試數據是否有問題 2. 用fiddler抓包，分析請求和響應數據是否存在問題 3. 查看應用服務器的日志 4. 然后再查看數據庫的數據是否存在問題 <br /> ## 開發沒時間修復，如何推進bug的修復： 1. 和開發說明該問題的嚴重性，會怎樣影響產品的正常使用，如何還是堅持不改，就上報領導，讓領導輔助推進； 2. 確認問題的嚴重程度，如果影響不大，不是非要改的bug，并且修復風險比較大，和領導商量后，如果認為暫時可以不用修復，也可以不修復。 <br /> ## 軟件測試流程 我們這個項目是兩個人負責測試的，按模塊進行分工，我負責xxx模塊。項目啟動后，我們會到服務器上下載相關的需求文檔，熟悉項目的流程，進行需求澄清，提取測試點；然后編寫測試用例，再進行組內的評審，修改，定稿；在開發階段，開發人員寫完一個接口，我們就測試一個接口；等開發轉測后，我們從svn上獲取安裝包，搭建測試環境；之后我們開始進行冒煙測試，冒煙通過后，我們就進入系統測試，就開始執行用例，發現bug就提交bug，并跟蹤bug，直至bug解決，之后進行用戶驗收測試，驗收通過后，編寫測試報告。 <br /> ## ATM機吞卡的吞卡現象是不是BUG? 不一定，看是什么情況下吞卡。如：輸入三次密碼錯誤吞卡是正常的，不屬于BUG；若輸入一次密碼錯誤吞卡則是不正常的，屬于BUG。 <br /> ## 有個程序，在windows上運行很慢，怎么判斷是程序存在問題，還是軟硬件系統存在問題？ 將程序放在其他的windows上運行，如果運行的還是很慢則是程序的問題。 <br /> ## 項目介紹 參考思路：項目叫什么名字，什么架構，有哪些模塊，用來干什么的，主要的操作流程 * 參考：我就說一下最近的一個項目，是集書蕓管理系統，主要是一款基于B/S架構的電商分銷管理系統，前臺模塊有店鋪首頁，購物車，會員中心，申請分銷等，后臺模塊有店鋪管理，書籍管理，訂單管理，分銷管理等，在后臺可以上架新的商品，設置店鋪活動，管理訂單等，用戶可以在前臺注冊成為會員，然后登陸系統，搜索上架的商品，將商品加入購物車之后進行結算下單，或者直接進行結算下單，下單后在用戶的‘我的訂單’能看到該訂單信息，訂單狀態為待付款，在系統后臺的訂單管理列表也能看到該訂單的信息，買家付款后，訂單狀態為待發貨狀態 ，賣家就可以進行發貨，買家收到產品后進行確認，評論，整個購物的流程就結束了。這就是我這個項目的大概情況。 <br /> ## 你們發現bug會怎么處理。 答:發現bug后，我們會先自己定位一下，比如，抓個包，看看是前端的問題，還是后端的問題，檢查下數據庫的數據是不是正確的，盡量把問題發生的原因或者產生的日志找出來，方便開發定位問題，然后就提單給開發，然后開發做出相應的處理，開發修復完后就進行回歸測試，回歸測試通過后就關閉這個bug，沒有通過就繼續給回開發修復。如果遇到開發認為這個不是bug的話，那么我們就要和開發溝通，然后我們要堅持自己的立場，通過討論后一致認為是bug就給開發修復，不是就關閉這個bug。如果開發和我們意見一直不一致，那么就要將問題升級，召集開發經理和測試經理一起討論，再做決定。 ## 一個項目完成時，有多個重要的缺陷沒有被修復，但是項目負責人說可以不修改，你認為測試是不通過的，請簡述你的理由。 測試是對軟件的質量進行的把關，如果一個項目仍然有很多的缺陷未被修復，那么從質量的角度上我們會認為這個軟件質量是不達標的，一般來說缺陷的遺留，是不允許嚴重、致命bug的遺留，輕微和一般的bug遺留率不超過30%。 <br /> ## 在需求文檔不太詳細的情況下，如何開展測試？ 首先，把需求文檔中有異議的部分標識出來，再找產品和開發一起討論，把需求明確下來； 提取測試點，然后再叫上產品和開發一起對測試點進行討論，看有沒有遺漏，是不是合理的， 然后再編寫測試用例，再評審，評審通過后，再進行后續的測試。 <br /> ## 判定表用在哪些時候/哪些功能 判定法，是用在不同的輸入組合，可能會產生不同的輸出這種情況，比如，一個有多個查詢條件的查詢功能，輸入不同的查詢條件組合，輸出的結果是不一樣的，這樣的功能就要用到判定表 <br /> ## 什么時候用到場景法 使用場景法通常是在冒煙測試中或者 一些流程性比較強的軟件/功能(比如安裝，卸載等等) <br /> ## 三角形測試用例設計 **解題思路** 我們可以設三角形的3條邊分別為A，B，C。如果它們能夠構成三角形的3條邊，必須滿足： A B C均是正數且大于0，還需滿足 * A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。 * 如果是等腰的，還要判斷A=B，或B=C，或A=C。 * 如果是等邊的，則需判斷是否A=B，且B=C，且A=C。