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