1.B/S架構和C/S架構區別

B/S 只需要有作業系統和瀏覽器就行，可以實現跨平臺，客戶端零維護，但是個性化能力低，

響應速度較慢C/S響應速度快，安全性強，一般應用於區域網中，因為要針對不同的作業系統,

需要針對性的開發,並且維護成本高

2.HTTP協議

1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、daohttp是超文字傳zhuan輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
4、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全

3.Cookie和Session的區別與聯絡

Session和Cookie的主要區別在於：
Cookie是把資料儲存在瀏覽器端的記憶體中
Session把資料儲存在伺服器端的記憶體中
cookie與session的聯絡：
當伺服器端生成一個session時就會向客戶端傳送一個cookie儲存在客戶端，這個cookie儲存的是session的sessionId。

這樣才能保證客戶端發起請求後客戶端已經登入的使用者能夠與伺服器端成千上萬的session中準確匹配到已經儲存了

該使用者資訊的session，同時也能夠確保不同頁面之間傳值時的正確匹配。

5. 測試的目的

1）軟體測試是為了發現錯誤而執行程式的過程。

2）測試是為了證明程式有錯，而不是證明程式無錯。（發現錯誤不是唯一目的） 3）一個好的測試用例在於它發現至今未發現的錯誤。 4）一個成功的測試是發現了至今未發現的錯誤的測試。

注意：

1、測試並不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分佈特徵。可以幫助專案管理者發現當前所採用的軟體過程的缺陷，以便改進。同時，通過分析也能幫助我們設計出有針對性的檢測方法，改善測試的有效性。 2、沒有發現錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。詳細而嚴謹的可靠性增長模型可以證明這一點。例如Bev Littlewood發現一個經過測試而正常運行了n個小時的系統有繼續正常執行n個小時的概率。

6. 軟體測試原則

1）應當把“儘早地不斷地進行軟體測試“作為軟體開發者的座右銘。

2）測試用例應由測試資料和與之對應的預期輸出結果這兩部分組成。

3）程式設計師應避免檢查自己的程式。

4）在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

5）充分注意測試中的群集現象。

6）嚴格執行測試計劃，排除測試的隨意性。 7）應當對每一個測試結果做全面的檢查。

8）妥善儲存測試計劃、測試用例、出錯統計和最終分析報告，為維護提供方便

7. 軟體測試分為哪幾個階段？

軟體測試分類 按照階段 單元測試：是指對軟體中的最小可測試單元進行檢查和驗證 整合測試：整合測試是單元測試的下一個階段，是指將通過測試單元模組組裝成系統或者子系統，再進行測試，重點測試不同模組的介面部分。 系統測試：指的是將整個軟體系統看做一個1個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。 驗收測試：以使用者為主的測試，軟體開發人員和質量保證人員參加 按照是否檢視原始碼劃分 白盒測試:指的是把盒子蓋開啟，去研究裡邊原始碼和程式結構(單元測試，ui/介面自動化測試) 黑盒測試:把被測試的軟體看做一個黑盒子，我們不去關心盒子裡邊的結構是什麼樣子，只關心軟體的輸入資料和輸出結果 功能測試 邏輯功能測試:測試應用是否符合邏輯，比如應該先註冊賬號之後，才能進行登入,登入之後才能看我的購物車 介面測試:視窗大小，按鈕大小，點選按鈕彈出什麼樣的提示框，是否有滾動條，下拉選單是否有展示內容 易用測試:從軟體使用的合理性和方便性等角度對軟體系統進行檢查,比如，軟體視窗長寬比例是否合適，顏色色彩是否賞心悅目，字型大小是否合適 安裝測試:安裝磁碟空間不足，安裝中斷(關閉程式，關機，，)下次安裝時是否繼續上次的安裝等。。。 相容測試:硬體相容性測試和軟體相容性測試（硬體相容性:比如一款軟體在pc機，筆記本,主機上是否相容，軟體相容性測試:比如一款軟體在window8和window10上是否相容） 效能測試 一般效能測試 穩定測試: 負載測試: 讓被測系統在其能夠忍受的壓力範圍之內連續執行，來測試系統的穩定性。（測試載重） 壓力測試:持續不斷的給被測試的系統增加壓力，直到被測試的系統壓垮為止，用來測試系統所承受的最大壓力。（測試強度） 其他 迴歸測試：迴歸測試是指修改了舊程式碼後，重新在新環境上進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。 冒煙測試：指對一個軟體進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性。 隨機測試：是指測試中所有的輸入資料都是隨機生成的，其目的是模擬使用者的真實操作，並發現一些邊緣性的錯誤

8. 單元測試與整合測試的側重點

單元測試

  是在軟體開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試，測試重點是系統的模組，包括子程式的正確性驗證等。 

整合測試

   也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出來，影響功能的實現。測試重點是模組間的銜接以及引數的傳遞等。 

9. 系統測試範圍

指的是將整個軟體系統看做一個1個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。 系統測試由黑盒測試人員在整個系統整合完畢後進行測試，前期主要測試系統的功能是否滿足需求，後期主要測試系統執行的效能是否滿足需求，以及系統在不同的軟硬體環境的相容性等

10. a測試與ß測試的區別

α測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由程式設計師或測試員完成。

β測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。

它們都是驗收測試！

α測試是指把使用者請到開發方的場所來測試 β測試是指在一個或多個使用者的場所進行的測試。

α測試的環境是受開發方控制的,使用者的數量相對比較少,時間比較集中。 β測試的環境是不受開發方控制的, 使用者數量相對比較多,時間不集中。

α測試先於β測試執行。通用的軟體產品需要較大規模的β測試,測試周期比較長

11. 驗收測試怎麼做？

驗收測試主要包含兩個階段：二輪測試和冒煙測試。在測試階段的先後順序上，二輪測試在一輪測試(需求的系統性測試)之後，在冒煙測試之前。在測試粒度上，按照由細到粗的順序，依次為二輪測試和冒煙測試;冒煙測試，眾所周知是對功能主路徑的迴歸驗證，而二輪測試則是執行較冒煙更細粒度的測試，另外也包含了一輪測試階段中出現bug較多的場景等等。 一輪測試：系統的測試驗證需求的階段，包含全部功能點的驗證、相容性驗證、效能驗證等等;

二輪測試：作為一輪測試後的整體迴歸驗證階段，主要側重驗證功能的主流程和一輪測試中問題較多的場景的相關用例 開始標準

一、測試自身

1、一輪測試執行完畢;

2、一輪階段的待檢驗bug迴歸完畢;

3、發起核心程式碼遷移郵件，確認核心開發要整合到正式釋出分支的程式碼，且均已驗證完畢。 二、配合方

1、各配合方均已上線驗證完畢;

2、例如：產品配置項、服務端、前端、第三方等;

3、反例：小編最近碰到個問題，由於沒有在二輪測試開始前做好上線驗證工作，導致在二輪執行階段遇到多方聯調問題，影響專案進度。

4、具體表現：在二輪測試執行階段，發現已經上線了的服務端和第三方相關功能無法順利走通，經過定位排查發現是在上線時，服務端和第三方的介面沒有聯調成功。

5、三方(開發、產品、測試)確認無阻塞二輪測試的bug;

6、程式碼整合完畢;(視具體專案組而定)

7、新功能或有較大改動模組，產品&互動驗收通過並已回覆郵件;

8、新功能或有視覺改動模組，視覺走查通過並已回覆郵件;

9、備註：當專案發版緊張時，開發評估一輪未結束的模組對其他模組均無影響(如，獨立外掛的功能模組)，可以先執行其他不受影響的模組的二輪測試

12. 白盒、黑盒和灰盒測試區別

白盒測試:指的是把盒子蓋開啟，去研究裡邊原始碼和程式結構(單元測試，ui/介面自動化測試) 黑盒測試:把被測試的軟體看做一個黑盒子，我們不去關心盒子裡邊的結構是什麼樣子，只關心軟體的輸入資料和輸出結果 灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過使用者介面測試，但是測試人員已經有所瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。甚至於還讀過部分原始碼。 因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。這樣做的意義在於:如果你知道產品內部的設計和對產品有透過使用者介面的深入瞭解，你就能夠更有效和深入地從使用者介面來測試它的各項效能

13. 冒煙測試的目的

冒煙測試：指對一個軟體進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性。 使用冒煙測試是為了正式測試前，驗證是否產品或系統的主要需求或預置條件是否存在bug

14. 迴歸測試怎麼做？

迴歸測試：迴歸測試是指修改了舊程式碼後，重新在新環境上進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。 1、在測試策略制定階段，制定迴歸測試策略 2、確定需要回歸測試的版本 3、迴歸測試版本釋出,按照迴歸測試策略執行迴歸測試 4、迴歸測試通過，關閉缺陷跟蹤單（問題單） 5、迴歸測試不通過，缺陷跟蹤單返回開發人員，開發人員重新修改問題，再次提交測試人員迴歸測試

15. 全部迴歸與部分迴歸的區別？

對軟體的新版本測試時，重複執行上一個版本測試時使用的測試用例，防止出現“以前應用沒有的問題現在出問題了”，這是全部迴歸；當在測試過程中，發現某個模組存在缺陷，開發修復後，測試人員重新驗證該缺陷是否被修復，以及驗證相關聯的模組是否受影響，這叫部分迴歸。

16. 需求分析的目的

1、把使用者需求轉化為功能需求：

1）對測試範圍進度量   2）對處理分支進行度量  3）對需求業務的場景進行度量  4）明確其功能對應的輸入、處理和輸出  5）把隱式需求轉變為明確。

2、明確測試活動的五個要素：測試需求是什麼、決定怎麼測試、明確測試時間、確定測試人員、確定測試環境：測試中需要的技能，工具以及相應的背景知識

，測試過程中可能遇到的風險等等。測試需求需要做到儘可能的詳細明確，以避免測試遺漏和誤解。

17. 測試計劃的目的

1、測試的目的是為了bai發現du儘可能多的缺陷，不是為了說zhi明軟體中沒有缺陷。

2、成功的測試在於發現了迄今尚未發現的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟體裡的缺陷

18. 什麼時候開始寫測試計劃

在專案開始後，在前期你需要了解測試的背景，範圍和工作量，以及人員的分工，所需的資源，工期等，在這些瞭解清楚後開始撰寫測試計劃

19. 由誰來編寫測試計劃

測試計劃一般由資深的測試人員來做， 要對整zhi體的專案有非常好的掌控，有豐富的測試經驗的人員來編寫測試計劃。

1. 測試計劃一般由測試經理來編寫。

2. 測試組其他人員， 會針對自己分配的任務估算自己任務的時間，統一彙總到測試經理那裡

20. 測試計劃的內容

測試背景 測試目標 測試範圍 測試輸出文件 測試策略 測試規模工作量分析 測試程序 測試進度及時間安排 測試資源 人力，裝置， 風險管理

（1）測試環境：測試環境+生產環境

（2）測試範圍：新增需求+全功能迴歸

（3）測試重點：優先順序為high的

（4）注意事項：開發提供修改點

（5）測試級別：常規啥的

（6）測試方法：功能測試？效能測試

（7）測試文件：測試依據、測試條件、測試用例

（8）計劃測試資源：人員以及安排的工作日

（9）是否需要外部支援：是/否

（10）測試出口：釋出時間

21. 結束條件(專案上線的條件)

結束條件： 1.測試用例執行比例，一般功能測試用例全部執行完畢，非功能測試用例執行達95%以上

2.測試缺陷修改數量，一般及以上的用例全部修復並驗證通過，已修復缺陷佔比95%以上

3.測試覆蓋需求程度，測試覆蓋全部的需求且達到上線的要求或標準

上線條件： 1.編寫目的：明確軟體測試工作的開始和結束標準。

2.軟體測試合格標準：以上比例為錯誤佔總測試模組的比例。

3.缺陷修復率標準

　　1) A、B、C級錯誤修復率應達到100%

　　2) D級錯誤修復率應達到96%以上

4.覆蓋率標準

　　測試需求執行覆蓋率應達到100%（業務測試用例均以執行）。

5.錯誤級別 A級：不能完全滿足系統要求，基本功能未完全實現；或者危及人身安全。系統崩或掛起等導致系統不能繼續執行。

B級：嚴重地影響系統要求或基本功能的實現，且沒有更正辦法（重新安或重新啟動該軟體不屬於更正辦法）。使系統不穩定、或破壞資料、或產生錯誤結果，或部分功能無法執行，而且是常規操作中經常發生或非常規操作中不可避免的主要問題。

C級：嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法（重新啟動該軟體不屬於更正辦法）。系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果等影響有限的問題

22. 常見的測試風險

D級：使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。介面拼寫錯誤或使用者使用不方便等小問題或需要完善的問題

23. 測試用例的要素

1. 測試用例編號 字元和數字組合成的字串，用例編號應具有唯一性、易識別 系統測試：產品編號-ST-系統測試項名-系統測試子項名-XXX 整合測試：產品編號-IT-整合測試項名-整合測試子項名-XXX 單元測試：產品編號-UT-單元測試項名-單元測試子項名-XXX

2. 測試專案 當前測試用例所在測試大類、被測試需求、被測模組、被測單元等 系統測試用例測試專案 軟體需求項 整合測試用例測試專案 整合後的模組名或介面名 單元測試用例測試專案 被測函式名

3. 測試標題 簡單描述，需要用概括的語言描述用例的出發點和關注點，原則上每個用例的標題不能重複

4. 重要級別 對基本和普通測試項的區分 高級別 保證系統基本功能、核心業務、重要特性、實際使用頻率比較高的用例 中級別 重要程度介於高和低之間的測試用例 低級別 實際使用的頻率不高，對系統業務功能影響不大的模組或功能的測試用例

5. 預置條件 執行當前測試用例需要的前提條件，如果這些前提條件不滿足，則後面測試步驟無法進行或無法得到 預期結果

6. 輸入

用例執行過程中需要加工的外部資訊。根據軟體測試用例的具體情況，有手工輸入、檔案、資料庫記錄等

7.操作步驟 執行當前測試用例需要經過的操作步驟，需要明確的給出一個步驟的描述，測試用例執行人員可以根據該步驟完成測試用例執行 8.預期輸出 當前測試用例的預期輸出結果，包括返回值內容，介面的響應結果，輸出結果的規則符合度等

測試用例額外的要素 1.用例設計者 能準確的找到測試用例設計人員，對用例修改時能方便找準人員 2.用例設計日期 方便檢查用例設計的進度 3.用例版本號 方便用例設計人員對用例的跟蹤

4. 對應的開發人員 出現BUG後能及時找到相應的人員進行修復

24. 測試用例級別的劃分

優先順序一般都是和缺陷的嚴重程度對應的。 一般可以把優先順序分為三種：

高：保證功能性是穩定的，是按照需求的正常使用和實現點進行用例設計的，重要的錯誤和邊界測試的測試用例的集合。

中：更全面的驗證功能的各方面，包括流程中的各個節點出錯情況、異常情況測試、中斷、UI展示、使用者體驗等方面的測試用例設計

低：不常被執行的測試用例。比如壓力和效能測試用例設計，介面測試用例設計隨著時間的推移已經從低級別變化到了中級別

25. 怎樣保證覆蓋使用者需求？

覆蓋使用者的需求；

從使用者使用場景出發，考慮使用者的各種正常和異常的使用場景；

用例的顆粒大小要均勻。通常，一個測試用例對應一個場景；

用例各個要素要齊全，步驟應該足夠詳細，操作應該明確，容易被其它測試工程師讀懂，並能順利執行；

做好用例評審，及時更新測試用例。

測試完成應找業務人員進行驗收，便於發現非測試角度的問題

26. 寫好測試用例的關鍵 /寫好用例要關注的維度

測試用例：測試用例為驗證某一特定軟體產品準備的一組有編號，輸入，預期輸出的描述 //記得《軟體測試過程與管理》上是這樣寫的,而我個人覺得應該是有編號，輸入，預期輸出，測試步驟，測試描述等等一些資訊的描述

以下Shared by Mikhail Rakhunov 好的測試用例：一個發現Bug概率很大的用例就是一個好的測試用例

測試用例設計應該具備的以下的特點

Test Case ID: 用來標記測試用例的編號，這個編號必須是唯一的

測試描述: 用來描述你將要進行的測試是怎樣實施的

修訂歷史: 為了明確測試用例由誰建立或者修改，所以每個測試用例都應該有其修訂歷史

功能模組: 測試功能模組的名字

測試環境: 用來描述你的測試環境，當然包括硬體環境和軟體環境

測試準備: 測試之前除了你所測試的程式之外還應該準備的東西，如印表機，網路等等

測試執行: 用來詳細描述你的測試步驟.

期望結果: The deion of what you expect the to do. 描述該功能所要實現怎樣的結果

實際結果: 通過/失敗 如果成功——紀錄實際執行的過程 如果失敗——描述你觀察到的現象，這將有利於發現Bug的起源

----------

一個很好的測試所應具有的特徵: 發現Bug的機率很大 沒有多餘 不是太簡單也不會太複雜

---------- ps.當你的期望結果有很多的時候，測試用例就會變得很複雜

27. 測試用例的狀態

排隊（In Queue）：

測試用例已經指定給某個測試人，不準備在這一個測試階段執行。

進行中（IP）：

該測試正在進行，並且會持續一段時間。（如果一個測試所需要的時間少於一天，我就不會講一個測試標為進行中，因為我每天會跟蹤測試用例的狀態）

阻塞（Block）：

一些因素會導致測試不能進行到底，例如某個功能欠缺或者測試環境的某個部分欠缺。我通常會在測試用例總結工作表的意見欄記錄下阻塞的狀態。你可以把阻塞理解為：我希望執行測試，但是目前還不能執行測試。

跳過（Skip）：

你決定在當前測試階段跳過某個測試，可能是因為它的優先權相對較低。（同樣地，我會在測試用例總結工作表的意見欄記錄下我跳過這個測試的原因。）你可以把跳過理解為：我現在可以執行這個測試，但是我不想執行它。

通過（Pass）：

測試執行結束，測試人得到了預料中的測試結果狀態和測試行為。

失敗（Fail）：

在很多情況下，測試人得到預料之外的測試結果，狀態或行為，這些結果與測試目標相差甚遠。這就引發了關於系統質量的疑問。一個或多個測試錯誤需要記錄下來。

警告（Warn）：

在很多情況下，測試人得到預料之外的測試結果，狀態或行為，但是這些結果與測試目標差別不是很大（我通常會在測試包總結工作表的通過一欄記為警告，而不是另加一欄）。另一種想法是，警告意味著當前的錯誤是無關緊要的，或者對正在測試的特徵是沒有意義的。系統報出了更多的錯。我處理這個問題的一個標準是隻和延期的或不是一定要改的錯誤相關的測試可以標記為警告，而不是失敗。

關閉（Close）：

一個測試在第一個迴圈中被標為失敗或警告，第二個測試釋出中將第一個測試迴圈出現的錯誤修改了。重新運行了整個測試用例後，沒有錯誤出現。將這類測試標記為關閉而不是通過，使得你可以跟蹤測試在某一個測試釋出中失敗的實事（同標記為警告的測試一樣，我在測試包總結工作表中將標記為關閉的測試也納入成功的範疇）。

28. 常見的測試用例設計方法

用例編寫步驟：

拿到測試需求 -> 分析需求（畫思維導圖） -> 編寫用例 -> 劃分用例優先順序

用例編寫特性：

· 一致性：主要包括用例模板一致；各同事的編寫手法一致；以及用例的細粒度一致。

· 覆蓋率：主要包括對需求的覆蓋（也包含隱含的需求）；新需求可能對那些功能會產生影響的覆蓋；對各種場景的覆蓋等 。

·可執行性：主要是指步驟易於理解、資訊描述準確、且能快速識別出測試點 。

·執行準確性：是指用例執行的準確度，本身沒什麼技術含量。但這裡需要注意的是執行人對待執行用例的態度。不要因為用例簡單或者一些外界的因素，導致部分用例未實際執行標為通過的情況。

·持續更新：要及時不斷的更新，要儘量減少用例庫中失效的用例 。

·複用性：主要用例可以被不斷的複用，從而減少維護成本

用例設計方法：

1. 等價類與邊界值**（重點方法）**

等價類：等價類劃分法是把所有可能輸入的資料，有無效等價類和有效等價類（即正確輸入和非法輸入），即程式的輸入域劃分策劃國內若干部分（子集），然後從每一個子集中選取少數具有代表性的資料作為測試用例。方法是一種重要的、常用的黑盒測試用例設計方法。

邊界值：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

與等價類區別：

· 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

· 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。

等價類與邊界值的結合使用：

例：一個文字框的輸入長度為 6-10 個字元

分析：有效等價類： >=6個字元，<=10個字元

無效等價類：<6個字元，>10個字元

邊界值：5,6,7,9,10,11個字元

2. 場景法**（重點方法）**

定義：通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發生的事情，通過事件來觸發某個動作的發生，觀察事件的最終結果，從而用來發現需求中存在的問題。

基本流：是經過用例的最簡單的路徑（無任何差錯，程式從開始直接執行到結束）

備選流：一個備選流可能從基本流開始，在某個特定條件下執行，然後重新加入基本流中，也可以起源於另一個備選流，或終止用例，不在加入到基本流中；（各種錯誤情況）

場景法的運用：

例：有一個線上購物的例項，使用者進入一個線上購物網站進行購物，選購物品後，進行線上購買，這時需要使用帳號登入，登入成功後，進行付錢交易，交易成功後，生成訂購單，完成整個購物過程。

· 基本流

· 備選流： 1) 進入購物網站，選擇物品，登入賬號，付費，生成訂單

2）賬號不存在

3) 賬戶餘額不足

更多的備選流。。。。。。

\3. 正交排列驅動法

定義：在介面中有多個控制元件，控制元件之間有多種組合關係，如果組合的數量巨大（一般超過20種），沒有必要將所有組合都測試，可以通過正交排列法將組合中最優，最少的組合進行測試。

正交表公式：

Ln（m^k）

· L（line）行

n:表示正交表的行數

提示：正交表確定後，n值是固定的，不需要測試人員計算

m：表示正交表中資料的最大值

測試時：m表示每個控制元件的取值個數

K:表示正交表的列數

　　　　　測試時：k表示參與組合的控制元件的個數

與判定表驅動法的區別：正交表一般用於組合較多的場合（一般>20種），判定表一般用於組合較少的情況

判定表示例：https://baike.baidu.com/pic/%E6%AD%A3%E4%BA%A4%E8%A1%A8/948850/0/ac345982b2b7d0a2394108ccc9ef76094a369ad2?fr=lemma&ct=single#aid=0&pic=ac345982b2b7d0a2394108ccc9ef76094a369ad2

4. 因果圖

1.定義：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程式輸入條件的各種組合情況。

2.因果圖法產生的背景：

等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關係。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。

如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮採用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。

3.因果圖介紹

1) 4種符號分別表示了規格說明中向4種因果關係。

2) 因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱原因），右結點表示輸出狀態（或稱結果）。

3) Ci表示原因，通常置於圖的左部；ei表示結果，通常在圖的右部。Ci和ei均可取值0或1，0表示某狀態不出現，1表示某狀態出現。

\4. 因果圖概念

1) 關係

①恆等：若ci是1，則ei也是1；否則ei為0。

②非：若ci是1，則ei是0；否則ei是1。

③或：若c1或c2或c3是1，則ei是1；否則ei為0。“或”可有任意個輸入。

④與：若c1和c2都是1，則ei為1；否則ei為0。“與”也可有任意個輸入。

2) 約束

輸入狀態相互之間還可能存在某些依賴關係，稱為約束。例如, 某些輸入條件本身不可能同時出現。輸出狀態之間也往往存在約束。在因果圖中,用特定的符號標明這些約束。

A.輸入條件的約束有以下4類：

① E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。

② I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。

③ O約束（唯一）；a和b必須有一個，且僅有1個為1。

④R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。

B.輸出條件約束型別

輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制為0。

\5. 採用因果圖法設計測試用例的步驟：

1)分析軟體規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個識別符號。

2)分析軟體規格說明描述中的語義，找出原因與結果之間, 原因與原因之間對應的關係，根據這些關係,畫出因果圖。

3)由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不可能出現，為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。

4)把因果圖轉換為判定表。

5)把判定表的每一列拿出來作為依據,設計測試用例。

5. 判定表

定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

判定表的優點

· 能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。

·在一些資料處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題。

判定表通常由四個部分組成如下圖所示：

1)條件樁（Condition Stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。

2)動作樁（Action Stub）：列出了問題規定可能採取的操作。這些操作的排列順序沒有約束。

3)條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。

4)動作項（Action Entry）：列出在條件項的各種取值情況下應該採取的動作。

6. 錯誤推測法

定義：基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法

錯誤推測方法的基本思想：列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例

29. 判定表用在哪些時候/哪些功能

判定表比較多用在多層條件判斷組合的場景，比如巢狀的if語句這種

使用場景： 1：等價類和邊界值無法覆蓋到控制元件與控制元件之間的聯絡，此時我們需要判定表來覆蓋控制元件與控制元件之間的影響 什麼是判定表： 判定表是分析若干輸入條件下，被測試物件根據不同的條件作出不同的響應的工具，適用於業務邏輯關係和多種條件組合情況 判定表的結構： 名詞解釋：

• 條件樁：被測物件所有的輸入

• 動作樁：針對條件樁所有的動作

• 條件項：被測物件可能輸入的真假值 T F

• 動作項：針對條件項的動作T F

使用判定表的步驟

1.列出所有的條件和動作
2.根據提取出來的條件樁和動作樁，設計判定表確定規則的個數（假如有n個條件，每個條件有2個取值 （0、1），就可以產生2的n次方種規則）
3.填寫判定表
4.簡化判定表【合併判定表會減小測試的充分性，8條以內的規則不建議合併】
5.一個規則就可以轉成一個測試用例
12345

以登入模組為例 正確的賬號密碼登入成功 使用者名稱和密碼為空：提示使用者名稱或密碼不能為空 使用者名稱輸入錯誤：提示使用者名稱或密碼錯誤，使用者名稱和密碼清空 使用者名稱正確，密碼錯誤，提示：密碼錯誤，使用者名稱保留，密碼清空 生成判定表如下圖 判定表優點 判定表法主要針對功能需求中的處理過程，處理過程越是複雜，就越有必要使用判定表法。判定表法充分考慮了輸入條件間的組合，對組合情況覆蓋充分，且可得出每個組合的預期輸出。其實，做測試需求分析的目的也就是得出完整的測試用例。重測試需求分析，輕測試執行過程。 判定表缺點 當被測試特性輸入較多時，會造成判定表的規模很龐大。當輸入條件間的約束條件不能有效區分輸入是否需要進行組合測試時，有可能產生冗餘。需手工剔除冗餘用例。

30. 什麼時候用到場景法

• 場景法適用於解決業務流程清晰和業務比較複雜的系統或功能，場景法是一種基於軟體業務的測試方法。

• 使用場景法，目的是用業務流把各個孤立的功能點串起來，為測試人員建立整體業務感覺，從而避免陷入功能細節忽視業務流程要點的錯誤傾向。例：語音通話典型業務流程就把語音通話、同振順振、語音留言、呼叫保持、來電轉駁這些功能都串到一起來。

• 基本上每個軟體都會用到場景法，因為每個軟體背後都有業務的支撐。

• 場景法主要用來測試軟體的業務邏輯和業務流程。當拿到一個測試任務時，我們並不是先關注某個控制元件的細節測試（等價類+邊界值+判定表等），而是要先關注主要業務流程和主要功能是否正確實現，這就需要使用場景法。當業務流程和主要功能沒有問題，我們再從等價類、邊界值、判定表等方面對控制元件細節進行測試（先整體後細節）。

Note：場景法測試用例設計的重點是測試業務流程是否正確，測試時需要注意的是，業務流程測試沒有問題並不代表系統的功能都正確，還必須對單個功能進行詳細的測試，這樣才能保證測試的充分性。

31. 測試環境怎麼搭建的？

關於軟體測試的測試環境搭建，需要根據實際的需求來進行安裝特定的軟體，下面就簡單介紹下java+tomcat+mysql安裝方法。

1.java的安裝

因為很多程式的程式碼都是通過java程式語言進行編寫的，因此為了測試需要，我們需要安裝支援java程式語言的安裝包，即jdk。下載好指定的安裝包後雙擊安裝包，預設下一步即可。完成這些步驟後需要配置環境變數，右鍵點選我的電腦-屬性-高階系統設定-環境變數-系統變數(s)-選中path-編輯 將安裝好的java中的bin和jre的路徑新增到環境變數中即可。在cmd中輸入java -version和javac -version驗證是否安裝成功。

2.tomcat的安裝

在java安裝無誤的情況下，下載好tomcat安裝包，直接點選下一步即可。

3.mysql的安裝

下載好安裝包，將其解壓到想要安裝的碟符中；按照1中的方法，將mysql中bin的路徑新增到環境變數中；開啟cmd，切換到英文，輸入mysqld -install(安裝命令)；輸入mysqld --initialize-insecure(初始化命令)；輸入net start mysql(啟動資料庫命令)，如果能夠順利執行這些命令無報錯，則資料庫安裝成功。倘若已經存在舊版本的mysql想將其解除安裝替換可依次執行net stop mysql和mysqld -remove，然後再進行mysql的安裝。

32. 偶然性問題的處理

一、一定要提交!!

1. 記得有這麼個缺陷，以後再遇到的時候可能就會了解發生的原因。

2. 盡力去查找出錯的原因，比如有什麼特別的操作，或者一些操作環境等。

3. 程式設計師對程式比測試人員熟悉的多，也許你提交了，即使無法重新，程式設計師也會了解問題所在。

4. 無法重現的問題再次出現後，可以直接叫程式設計師來看看問題。

5. 對於測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程式設計師那裡，既然測試人員犯錯誤，使用者也可能會犯同樣的錯誤。錯誤發生的時候，Tester最大。

　　二、程式不是測試人員寫的，出問題也不是測試人員的原因。

　　至於無法重現，可能的原因很多，因為測試人員看到的只是程式的外部，無法深入程式內部，所以把責任推給測試人員是不對的。

　　測試人員的任務只是盡力重現問題，而不是必須重現!!

　　三、下次再遇到的時候，拉他們來看就可以了。

　　因為問題如果無論如何無法重現，程式設計師確實也沒有什麼好的解決方法。

　　而且此類問題即使程式設計師說修改了，測試員也沒有好的方法去驗證是不是。 : )

　　四、你可以告訴程式設計師，測試過程是沒有錯誤的。

　　測試人員只是檢查程式中可能存在的問題，雖然測試人員使用一定的手段方法努力去覆蓋所有的情況，但這些都是理論的推測。在實際中，可能因為人員、環境、配置等種種原因出現各種各樣的問題，在測試人員這裡發現問題是公司內部的事情，程式發到外面可就是公司的形象問題了。

　　需要讓程式設計師理解，測試人員是幫助他們的，不是害他們的。

　　客戶那裡發現問題比測試員發現問題結果要嚴重的多。

　　五、測試部門是獨立與開發部門的呀，真的打交道，也是經理對經理。

　　在我們這裡，工作上面的事情，和程式設計師相互只能商議解決，並沒有誰高誰低。

　　問題無法重現，也要提出，程式設計師那裡可以回覆無法再現。問題放在那裡，等到再次出現的時候，就立刻叫程式設計師過來檢視。

　　實在沒有再次出現，最後可以寫到報告中，說出現了什麼現象，但無法再現(比較嚴重的問題才如此處理，小問題經理之間商量商量可能就算了)。

　　

　　這種事情是無法避免的，並不能說測試人員無法重現問題，就是工作不到位(哼，程式有bug，是否可以說程式設計師工作不到位的呀)。

　　六、測試部門要獨立，最好不受開發的制約。其實真正要重視，就應該有否決的權利。

　　我們公司就是專案承包，要拿最後的專案尾款，就要測試部簽字通過，這樣就避免了很多的問題。

　　其實只要自己盡到心就可以了，管別人怎麼說呢。

　　七、我們使用的狀態有：

　　程式設計師處理的狀態(由測試員提交的Action)：等待處理的，再次出現的。

　　測試員處理的狀態(由程式設計師提交的Action)：已經修改的，暫不修改的，系統限制的，使用錯誤的，無法再現的。測試員可以修改記錄。

　　經理處理的狀態(由測試員提交Action)：管理員處理的。經理還可以刪除記錄。

　　按照比較標準的說法，其實對於缺陷還應該有“等待確認的”、“已經確認的”和“重複提交的”的狀態，我們為了省事，統一使用了“等待處理的”。

　　最後結項的時候，缺陷的狀態對我們來說有兩種，“已經關閉的”(由測試員或經理確認)和“暫不修改的”(比如下一個版本處理等)。

　　呵呵，狀態多，有些煩瑣，特別是程式設計師很多的時候都不清楚應該回復什麼狀態，但我個人覺得對測試人員來說，這些狀態比較清晰明瞭，容易處理。

　　八、一個叫doer_ljy(可戰)的網友回覆了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰)的內容：

　　關於“無法重現”我看是有這麼個問題存在。

　　首先如果你在測試之前有嚴格的測試計劃，就很難出現“無法重現”這種現象。“無法重現”的意思是不知道怎麼操作才能再次看見這個BUG。那麼這個BUG多半是“計劃外”的。

　　不清楚你是否是測試人員。“計劃外”這個詞，對測試員來說應該不存在。測試用例的粒度一直是個在討論中的問題，測試人員很難有時間和精力寫出包含內容、資料、步驟等等全部操作一切的測試用例。即使真的有，意義也不大，測試很多的時候，是發散性的思維，帶點創造性，想事先考慮完全，很難。所以更多時候，是在測試過程中逐步對用例等進行完善，所以說“計劃外”最好不要提。

　　說說我現在測試的一個專案，有一個業務，首先查詢出人員，有個“全選”按鈕，“全選”後，再用滑鼠一個一個取消選擇，這個時候進行業務辦理的時候，就會提示“沒有選擇人員”，至今為止一切都正常，但是這個時候再次點選人員進行業務處理，仍然會提示“沒有選擇人員”，這就是一個缺陷了。這個問題我想一般人都不會在測試用例中考慮到吧，因為發生的條件很苛刻：不用“全選”按鈕的時候不會發生;全選後點選“取消全選”按鈕再辦理業務不會發生;全選全消後，先點選人員再辦理業務也不會發生。

　　其次，成熟的測試人員及時無法再現BUG，也能準確的描述出BUG發生之前幾個步驟的操作方法，測試用例情況。這些對開發人員分析BUG原因很重要。所謂的BUG發現環境。

　　呵呵，看來我不是成熟的測試人員。手工測試，比較熟練的時候，和打字可以說差不多，應該進行到哪裡，心中是有數的，但讓我完全從頭到尾的重複，不容易呀。寫測試缺陷報告單的時候，也只是說明操作步驟和發生的現象。其實無法重現的問題，既然說“無法重現”，也就是測試人員已經對這個現象進行了多次的驗證，一般從程式外部來說，測試人員的操作比程式設計師要熟練的。

　　最後，我不同意測試人員不假思索把發現的“問題”直接推給編碼人員的做法。畢竟是大家合作，目標是一致的。測試人員總是處在BUG發生的第一現場，應該幫助分析出現問題的原因。確認是不是自己的此時Miss.

　　測試人員提交任何一個問題，都會經過反覆的驗證，如果容易重現，早就提出來了。絕對不是在推脫責任，還是那句話，對程式的結構，做的人當然比不做的人要清楚。另外，除非程式設計師詢問，否則我不會給程式設計師提出修改分析和建議!!測試人員的任務是發現問題，解決問題是程式設計師的事情。這麼做可能會影響程式設計師思考問題的思路;而且測試人員做的多了，程式設計師不但不感激，可能反而會反感(好像程式設計師對測試人員有好印象的不多)。

　　再說兩個我這兩天遇到的問題。第一個就是我們的程式有一個鎖定資料的功能。鎖定後，在其它的業務，此資料將不能再使用。我當時發現這個功能無效，而且經過了幾次的驗證都不行，我當然就提出了。但是程式設計師那裡說此功能好使，我再驗證的時候，就沒有問題了，這個問題當時可以重現(但是我不可能遇到問題就拉程式設計師來看吧)，後來卻沒有了，只能放在那裡，最後關閉掉。第二個就是在一個介面中，錄入有順序要求，必須先選擇一個ListBox(必填)再進行Edit的錄入，但一次操作我沒有選擇 ListBox就錄入的Edit，也正常儲存了。後來無論我怎麼操作此問題都沒有出現(不夠成熟呀)，我就放棄了，也沒有提交記錄(為了避免麻煩)。

　　測試人員的時間是有限的，進度給的都很少，一般連用例都沒有時間寫，還要去花很多時間驗證“無法重現”的問題?反正10分鐘如果試驗不出來，我就會放棄。嚴重的就提交，不影響的就當不知道。

　　下面是其它一些人的觀點：

　　doublefalse(散諸懷抱)：如果不能重現的bug確實比較麻煩，但最好在測試過程中注意乾淨環境、正確的操作、相同的資料來源，只要真的有問題，一定能否復現的。呵呵，多試試!!!我們以前一直有客戶反映入庫的資料經常有無關資料，但在家裡測試沒有問題，後來才發現是漢字編碼錯位，這樣同樣的字，錯位後就變成另外的東西了。

　　liuxiaoyuzhou(蟀哥)：遇到過同樣的問題!主要是記住BUG出現的環境!測試的時候這是關鍵!在我們這裡不能從現的BUG，是測試人員的工作不到位!我們這裡程式設計師比測試人員說話有力度!鬱悶呀!

　　ericzhangali(另一個空間)：首先一定要提交bug;其次不要企圖RD一定去解這個bug;某些時候還得關閉這個bug。如果RD認為是測試錯誤，(不明白什麼叫測試錯誤，是不是說他從測時要告訴你千萬不要怎麼怎麼做，否則後果自負啊，)那也沒什麼辦法，如果溝通解決不了，愛咋認為就咋認為吧。

　　darkcat_c(錯了重來)：沒有bug是不可以重現的，bug本事是建立在標準的規程上所出現的異常，如果你按test case步驟做的話不太可能出現此類bug。作為測試人員一定要具備良好的記憶能力，一旦出現一些不知如何產生的bug，至少你要知道剛才你大致進行了那些操作。良好的分析能力，儘管你只是測試，但你應該全面的瞭解程式的架構，和一些重要的內部細節，不然你這個測試就是不合格的。定位bug是開發的事情，而重現一個bug是測試的本職工作，不要把所有的事情推給開發，不然你的確比開發要低一等。(編者按：這種話，不願意去辯駁，標準開發人員的看法，也許應該讓他們也來做做測試)

　　liyan_1014(雁子)：我覺得應該是這麼處理：

　　1、一定提交bug，必須由負責bug的tester詳細描述測試操作步驟，bug發生的症狀，並將bug發生的具體環境也描述清楚;這樣對於再次重現也有一定的參考性。

　　2、測試和開發之間是需要良好溝通的，如果得到的回覆是操作錯誤，那麼請開發人員解釋，為什麼會允許存在操作錯誤，一般來說，對於錯誤控制，開發那邊應該能很好的把握。

3、溝通方面是需要方式的，開發人員對於自己完成的程式有一種滿足感，一般來說是不允許別人來破壞他的這種感覺，如果溝通的時候儘可能是一種建議的形式，讓開發人員自己指出自己的程式缺陷，這樣對於開發人員來說是可以接受。

33. 當我們認為某個地方是bug，但開發認為不是bug，怎麼處理？

1.找到需求文件或者是原型圖進行匹對 2.嘗試多種測試環境和多種測試方式來確認是否為bug 3.整理bug的復現的步驟和出現的頻率 4.開發堅持不認為是bug的時候找專案經理測試經理進行溝通來確認是否為bug 5.將客戶經理 測試 測試經理和專案經理進行開確認會來判定是否為bug 6.測試人員需要將bug整理並寫入測試總結中

34. 產品在上線後用戶發現bug，這時測試人員應做哪些工作？

首先測試人員可以做的是重現這個問題並及時反饋給開發人員，找到解決方案進行修復。

如果問題只在線上才出現，測試環境重現不了，那麼可能是版本或環境配置的問題；

如果問題不僅線上能重現，測試環境也存在，那麼很有可能是測試人員在測試過程中未發現的Bug。

總之，專案組成員需要儘快修復Bug。

開發人員修復Bug之後，測試人員需要反思。

若是由於疏忽造成測試用例執行遺漏，測試人員需要在下次執行測試的過程中避免這樣的情況。

若是由於用例評審的不嚴格、中途需求變更或者某些其他因素造成的測試用例覆蓋不全，測試人員需要補全測試用例。

---

在測試過程中遇到未發現的Bug，測試人員不要自怨自艾，

也不要像沒回事兒一樣，需要正確對待“線上Bug”、汲取經驗教訓、不斷提高測試能力。

測試人員需要不斷學習，不斷擴充，掌握測試工具、提升測試技能，從而設計出更全面的測試場景和測試用例。

35. 二八定理

80%的缺陷出現在20%的程式碼中，體現了軟體缺陷群集現象

36. 如何跟蹤缺陷

在執行用例的過程中發現了跟預期實際不符的情況，就提交缺陷,跟蹤缺陷修改，跟蹤缺陷流程主要有四個(一個正常的修改結束的流程，三個特殊處理流程)

1. 新建 -- 開啟 -- 修改 -- 關閉 提交缺陷後開發人員確認修改後迴歸通過；

2. 新建 -- 拒絕 開發人員未確認缺陷拒絕修改，這個時候需要在確認需求理解正確(跟產品確認)和復現步驟(多次復現)的基礎上, 跟開發人員溝通是否需要修改；

3. 新建 -- 開啟 -- 修改 -- 重開 修改後提交的版本回歸不通過，這是需要重新開啟缺陷,為了加快缺陷正確修改，可以跟開發人員溝通，協助開發人員定位缺陷；

4. 新建 -- 開啟 -- 延期 部分開啟的缺陷，由於無法復現, 難以修改，進度壓力等原因,可能需要延期修改，這個時候，是否延期，是需要多方確認的(測試、產品、開發、領導)。

37. 缺陷的狀態

1. New（新的）：bug提交到缺陷庫中會自動的被設定成New狀態

2. Assigned（已指派）：當一個bug被認為New之後，將其分配開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為“Assigned”

3. Open（已開啟）：開發人員開始處理bug時，他將這個bug的狀態設定為“Open”，表示開發人員正在處理這個“bug”

4. Fixed（已修復）：當開發人員進行處理（並認為已經解決）之後，他（她）就可以將這個bug的狀態設定為“Fixed”並將其提交給開發組的負責人，然後開發組的負責人將這個bug返還給測試組

5. Rejected(被拒絕)：測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之後認為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設定為“Rejected”

6. Postponed（延期）：有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試資料，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設定為“Postponed”

7. Closed（已關閉）：測試人員經過再次測試後確認bug已經被解決，將bug的狀態設定為“Closed”

8. Reopen（再次開啟）：如經過再次測試發現bug仍然存在，測試人員將bug再次開發組，將bug的狀態設定為“Reopen”

38. 缺陷的等級

bug缺陷等級一般劃分為四個等級，致命、嚴重、一般、提示

致命（一級bug） **通常表現為:主流程無法跑通，系統無法執行，崩潰或嚴重資源不足，應用模組無法啟動或異常退出，主要功能模組無法使用。

比如：1.記憶體洩漏；2.嚴重的數值計算錯誤；3.系統容易崩潰；4.功能設計與需求嚴重不符；5.系統無法登陸；6.循壞報錯，無法正常退出。

嚴重（二級bug） 通常表現為：影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性。

比如：1. 功能未實現；2.功能存在報錯；3.數值輕微的計算錯誤。

一般（三級bug）** 通常表現為：介面、效能缺陷。

比如：1.邊界條件下錯誤；2.容錯性不好；3.大資料下容易無響應；4.大資料操作時，沒有提供進度條。

提示（四級bug） 通常表現為：易用性及建議性問題

比如：1.介面顏色搭配不好；2.文字排列不整齊；3.出現錯別字，但是不影響功能；4.介面格式不規範。

39. 缺陷單應該包含這些要素

缺陷標題，缺陷描述，重現步驟，預期結果，實際結果，缺陷優先順序，缺陷嚴重程度，附件

40. 測試報告的主要內容

1. 概述：一般會在概述中新增專案背景、需求描述等資訊。

2. 測試過程主要包含評審記錄、測試範圍、測試用例

3. 羅列出是否已按本次測試計劃實現功能

4. 包括資源統計、執行情況、問題統計、問題列表、遺留問題

5. 主要總結本次測試測了哪些內容、用例覆蓋程度、bug解決程度等，以及最終是否決定通過本次測試。

6. 測試風險沒有放在測試總結裡，而是單獨劃分為一個模組，可見其重要性。

41. 如何定位bug：

1. 檢視狀態碼
​
2. 檢視伺服器日誌
​
3. 檢視需求文件
​
4. F12（開發者工具）
​
5. 前臺UI介面，我所提到的介面，包括介面的顯示，相容性，資料提交的判斷以及頁面的跳轉等等，這些bug基本都是一眼可見的，不太需要定位。

42. 開發沒時間修復，如何推進bug的修復：

導致開發不修改bug的因素

1、 開發與測試對bug的定義理解不一致產生的問題，例如暴力操作、非常規操作出現的問題、問題路徑深、伺服器返回的資料不規範、競品同樣有的問題、個別機型問題等情況，開發可能會不願意修改。

2、 工作流程方面的原因，例如開發有更高優先順序的任務沒有時間修改、上線時間緊急，來不及修改、開發不關注名下的bug、開發認為目前的實現比產品需求好等情況

3、 當然還有個人能力原因，例如找不到好的解決方案、影響範圍大、找不到bug原因，沒有解決方案、技術實現難，不知道怎麼修改等等原因

4、 另外還有一些不可抗力的客觀因素，例如系統問題，第三方應用問題等等

開發不修改bug的原因有四：bug路徑較深、上線時間緊急、改動影響範圍大、第三方應用問題。解決方案

1、 針對路徑較深的bug，測試在推動開發修復bug時，需要注意以下幾點

a) 從使用者的角度分析問題的嚴重性，分析使用者的遇到此問題的概率，引導開發站在使用者角度去思考，從而使開發意識到問題的嚴重性

b) 可以和開發人員列舉一個之前的類似問題，為開發提供參考

c) 產品是負責這個軟體的人員，當測試與開發意見無法達成一致時，不要因為無法推動開發修改而放棄，一定要找產品確認，最終的決定權交給產品人員。

2、 上線時間緊張，開發來不及修改了，這個時候測試應該分析問題的嚴重性，和產品人員商議是否需要修改

3、 修改bug改動較大，影響範圍廣，沒有最優的解決方案等情況在專案即將上線的節點比較忌諱這種事情的發生。面對這種情況，建議開發人員做調研工作，請教其他的同事，或者組織一個臨時會議，集眾人之力研究好的修改方案

4、 第三方應用問題，開發無法修改。確認原因之後需要找相關的工作人員，例如產品，聯絡第三方輸入法的工作人員，反饋問題，儘量推動應用解決問題

43. 軟體測試流程

在立項會中制定需求文件，由UI設計原型圖，開發根據需求文件進行編碼，我們測試會根據需求文件進行編寫測試計劃，根據模組的顆粒度劃分並編寫測試用例以及對用例的評審，開發結束後測試對主要功能進行冒煙測試，執行測試用例，提交bug開發進行修改，修改成功後關閉bug，進行迴歸測試，在上線前進行測試總結。

44. 專案介紹

45. 對一支圓珠筆進行測試，要從哪些方面進行測試？三角形測試用例設計

圓珠筆

1. 能否正常書寫

2. 寫出來的字遇水是否會消失

3. 是否有筆油洩露

4. 筆帽是否能正常按下彈起來

5. 一支筆可以用多少時間、寫出的字是否褪色

6. 筆的長短粗細是否順手

7. 一根筆芯用盡是否方便更換

8. 外形是否美觀

9. 筆油是否含有有害物質

10. 筆尖是否容易傷到人

11. 筆油或者墨水保質期多長 過期是否產生有害物質

12. 在不同的溫度、氣壓、和重力下能否正常使用 在不同的紙質和力度下書寫結果如何

13. 長時間按住彈簧，鬆開後看彈簧是否可以恢復

14. 筆芯彈出彈回的快慢。

15. 連續按，看彈簧能經受多少次伸縮。

16. 如果以極快的速度按壓彈簧，該筆是否會崩潰？

17. 有些圓珠筆，不關掉，或者不蓋蓋子很容易乾燥，時間久後是否可以正常使用

18. 掉在地上是否會壞掉

19. 被踩了後是否容易壞，承受最大壓力

20. 筆芯的顏色

21. 是不是可擦掉的筆

22. 圖案是否會掉色

23. 筆墨的氣味

24. 墨水多久能幹

25. 筆桿折斷，材質是不是容易刮傷手

26. 誤食筆墨是否引起中毒

27. 流暢度

28. 在木板或牆壁上書寫，在其他物體上書寫

29. 這個筆芯的筆尖/筆殼摔壞了，我換其他的筆芯的尖能不能繼續用

30. 高溫和低溫環境下對筆芯出墨和筆殼的影響

三角形測試用例設計

（參考）

https://blog.csdn.net/junjunba2689/article/details/82587612

https://www.cnblogs.com/jpr-ok/p/6374742.html

1、構成三角形的條件：任意兩邊之和大於第三邊；

2、構成等腰三角形的條件：任意兩邊相等；

3、構成等腰直角三角形的條件：任意兩邊相等，而且兩條邊的平方和等於第三邊的平方和；

4、構成等邊三角形的條件：三條邊都相等。

一、等價類劃分：三角形三條邊A、B、C的資料型別不同

我們再分析一下三角形的等價類：

有效等價類：

輸入3個正整數或正小數：

1、兩數之和大於第三數，如A<B+C；B<C+A；C<A+B

2、兩數之和不大於第三數

3、兩數相等，如A=B或B=C或C=A

4、三數相等，如A=B=C

5、三數不相等，如A！=B，B！=C，C！=A

無效等價類：

1、空

2、負整數

3、非數字

4、少於三個數

等價類表：

測試用例

46. 在專案中發現哪些經典bug？什麼原因導致的？

註冊資訊中的錯誤提示資訊：如手機資訊欄應填入11位有效電話號碼，但提示資訊卻為“13位電話號碼”，這是因開發人員粗心大意造成的

介面bug：傳的欄位值為空，但是開發沒給預設值設個0導致接收不到資料

47. 一個專案完成時，有多個重要的缺陷沒有被修復，但是專案負責人說可以不修改，你認為測試是不通過的，請簡述你的理由。

1. 影響使用者體驗
2. 如果不修改，在上線時可能會引起其他bug發生
3. 如果在版本迭代在修改，時間久了對bug的認知就沒有現在清楚了
4. 拖得越久越難修復
5. 不符合需求產品需求

48. 在需求文件不太詳細的情況下，如何開展測試？

軟體生命週期中，需求是整個週期的源頭。良好的開端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企業中，並沒有對需求引起足夠的重視。原因並不是PM們不知道需求的重要性，而是商業競爭中不得不裁剪某些看似不能獲得很大利益的步驟。

什麼是需求？很多PM和開發人員都未必真正考慮過這個問題。IEEE對需求有以下兩種定義的方式。

1. 解決使用者問題或達到使用者目標需要具備的條件或能力

2. 遵守合同、協議、規範或其他要求

然後用規範的文件描述出來，就成了我們熟悉的SRS。

我們常說的需求，其實並不是我們認為的SRS。SRS應該叫做需求規格說明書。那需求是什麼呢？與需求規格有什麼區別？

需求：對要實現的功能的粗略描

需求規格：對需求的精確定義

我們知道，在軟體開發過程中，只有得知了需求的精確定義，才能開展工作。比如功能方面，編輯框能支援多少位字元。效能方面，時間和容量規定等。當然還包含其他非功能，效能方面的定義。

除了以上所說的需求，對於測試人員，還必須有測試需求。這個環節，很少有企業會重視。測試需求分為2方面：

需要測試哪些方面

軟體是否可測，需要增加哪些開發需求

其中第一條，很多企業都列到了測試計劃中，這也可以，沒有規定一定要放到哪個文件裡。但是對於第二條，可以說幾乎沒有多少企業去做。

接下來，在沒有明確需求，需求規格，測試需求的情況下，我們怎麼去做測試呢？現在很多企業，其實就是在這種情況下做專案的。

當測試人員接手一個專案後，第一件事情一定是想了解這個系統的功能，背景，架構。於是，馬上就會想得到需求文件。但結果往往是失望的，根本沒有文件，或者文件根本不具備參考價值。此時不必太失望，因為這種情況實在是太常見啦。這時，請試著從以下幾個步驟著手。

查閱文件：文件是最具權威的，也是記憶最長久的。有時，我們的專案可能是在原有產品的基礎上，進行版本升級。這時，先去找找，有沒有原有版本留下的需求，或者是使用者手冊等文件。從這些文件中，瞭解專案的背景，系統的基本功能。這對了解新專案是有很大好處的。並且，在產品升級的專案中，驗證老版本的功能在新版本中是否正常，也是一個必要的工作。可以先參考老版本的相關文件，設計新版本中的用例。

也有時，我們的專案是一個行業專案，比如金融專案。我們可以參

考一些行業知識的書籍，文件。這對理解系統也有很大的好處。

實在沒有文件，那隻好暫時跳過這一步驟了。

在進入下一步驟之前，你可能得到了一些相關文件，也可能什麼也沒得到。無論如何，你可能對系統已經有了一些瞭解。這時，請記錄下來，寫成文件。無論是對自己，還是對別人，在以後都可能極有參考價值。試想一下，如果前人已經給你留下了這些文件，你是否可以輕鬆很多？還要注意及時更新你的文件。因為你對系統的理解，隨時都在變化著，一定要保證你的文件和當前你對系統的理解是一致的。

試著使用系統，根據經驗和常識猜測：既然沒有需求，那可以推測，該專案的管理一定是很糟糕的，對測試也不會投入很大的成本。因此，測試人員一般都是在編碼完成後才進入專案。這時，應該已經可以看到成型的系統了。在沒有需求的情況下，試著先“玩”一下系統吧。在這過程中，你應該對系統有可更深入的認識，在上一階段中，你可能留下很多疑惑或是猜測，這時應該能排除一部分了。

使用系統的同時，你應該具備行業知識。系統可能是針對某個專業領域設計的。例如一個期貨交易系統。你沒有基本的期貨知識，比如什麼是持倉，什麼是平倉。那麼你如何能真正理解這個系統呢？當你有了業務知識以後，你會進行更深入的思考，來全面測試系統。

你還需要具備良好的軟體知識。比如某些控制元件的特性。單選框只能單選，不能多選。日曆控制元件是否可以手工輸入非法格式等。這些都是應具備的意識。

最後加上你的主觀判斷，你對系統的整體感覺怎麼樣？是否越用越厭煩，為什麼厭煩。系統的反應速度是否可以容忍，細節處理是否圓滑，等等。

在你認識系統的時候，可以使用一些方法，來幫助你更有效率地學習。比如可以畫一些流程圖。一圖勝萬語。同時，你也留下寶貴的文件。當然，這個步驟中，你也要隨時注意保留和更新文件，以備後用。

溝通：需求規格不一定非要以文件的形式表現出來。軟體既然能做出來，那肯定是有需求的。而最清除需求的，一定是軟體的直接製造者，開發人員。開發人員自己知道需求，但一般不會主動和測試人員溝通。因此，測試一定要主動和開發人員溝通。可以安排會議，讓開發人員給測試人員介紹系統，並演示系統。讓測試人員對系統有一個整體瞭解。然後測試人員能進行更細緻的測試。在進行細緻測試的時候，一定會有更多不明確的地方。這時就需要利用自己的行業知識，計算機知識等，猜測一

部分。不需要每個細節都去詢問開發人員。因為開發人員也有自己的工作，他們不希望花太多時間來給你解釋。

有些專案中，客戶會直接參與到專案組來。這時，測試人員在許可權允許的情況下，可以和客戶進行溝通。客戶那得來的需求，是最原始的需求。但是，客戶未必有良好的表達能力來描述希望的功能，也未必有計算機知識，因此不能描述出一些隱式的需求。在被允許的情況下，測試人員可以和客戶進行交流，不僅可以幫助客戶正確描述出真實需求，測試人員也能詳細瞭解需求。但是專案是要考慮成本的，客戶的期望是無限制的。在客戶提出需求以後，測試人員要先和PM或其他相關負責人協商後，才能將與客戶交流得來的需求，作為測試的依據。同事，第一時間告知相關開發人員最新的資訊，也記錄成文件。這時，你就將非文件形式的需求，轉換為文件形式了。至於文件的格式，不一定要按照標準SRS的格式。因為它本身就不是個規範的SRS。以任何容易理解的方式，組織你的文件。

有時候，會根本找不到可以溝通的人。不要奇怪，確實就是有這種時候。比如：

1. 測試一個開源軟體

2. 接到一個測試外包，但又沒有得到相關文件，為了追求利益，還是接下了

3. 軟體專案組的部分人員已經聯絡不上等等

這時候，一方面需要PM協調獲取相關資料，聯絡相關人員。另一方面，測試人員也可組織頭腦風暴，利用集體的智慧，共同探討和猜測軟體中的各個環節。也可以安排Bug Bash，讓儘可能多的人員參與隨機測試。一定會有人提出具有創造性的意見的。

在進行以上步驟的時候，利用良好的工具，能讓你事半功倍。我經常在使用的一個工具，就是Mindjet MindManager。這是一個很好的，幫助擴充套件思維的工具。它以分支的形式，來表現你的思維層次。你可以先列出個最基本的系統整體結構，然後逐步細化，增加分支。不要急於一次就將真個系統分析透徹，這是不可能的。你在進行以上步驟的時候，隨時會細化這個結構。當專案結束後，看看這個結構圖，簡直可以當作SRS來參考。

49. 如何儘快找到軟體中的bug?

1、儘快熟悉公司的產品業務，根據產品的業務屬性來熟悉產品的業務流程，這樣才能迅速找出軟體中存在的一些重要的缺陷，這樣發現的軟體的價值才是有價值的，否則即使你能找到一些軟體缺陷，那也是純軟體的缺陷，價值不大。

2、把自己當成是使用者，把自己當成使用者去使用該軟體，比如在試用軟體的過程中，思考使用者是這樣操作的麼

3、善於懷疑 ，世界上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事，我卻認為可能發生；別人認為是對的，我卻認為是錯的。假如一個水平很高的程式設計師編寫的程式，不要有“他寫的這個程式應該沒有問題吧”這種想法，這樣很容以遺漏軟體中的Bug。

4、不用讓程式開發員“使用者不會這樣操作”的觀點說服自己，遇到這樣的情況，你要堅持自己的正確的觀點，把這種現象作為一個Bug。

5、在測試的過程中要跟蹤一條資料的完整流程，比如“點選商品—收藏商品—加入購物車—訂單結算—付款—消費二維碼—消費—二維碼失效”，如果在測試軟體過程中業務流程邏輯都走不通的話，還麼這個軟體測試與不測試就沒有什麼區別的。

6、在測試的過程中要跟蹤一條資料的完整程，要注意的事項 ，程式設計師提交新的版本後，作為測試人員應該立即與程式設計師溝通這個修改的功能，並瞭解這個新修改的功能影響那些功能。而被影響的功能，是在迴歸測試中優先重點測試的地方，而且也是最容易產生Bug的地方。

7、軟體的邊界值 ，眾所周知軟體最容易在邊界值上出現問題，所以作為測試人員一定要在邊界值上多測試，比如測試使用者輸入框中的數值的最大數和最小數，以及為空的情況；

8、非法容錯性，比如在需要輸入數字的地方輸入字母，在需要輸入字母的地方輸入數字，在需要使用者輸入的文字框中拷貝字數很多的整編文章到這裡測試看看軟體是如何做處理的；

9、學習他人經驗：三人行必有我師焉，人外有人，天外有天。

50. 什麼是bug？

• 當且僅當規格說明是存在的並且正確，程式與規格說明之間的不匹配才是錯誤。

• 當沒有需求規格說明書時，判斷標準以終端使用者為準：當程式沒有實現其終端使用者合理預期的功能要求時，就是軟體錯誤。

• 和預期不一致的軟體行為。

  一個軟體行為既可能是bug也可能不是bug，那是因為預期的主體千姿百態。

  和測試員預期不一致的軟體行為。 和程式設計師預期不一致的軟體行為。 和文件預期不一致的軟體行為。 和管理者預期不一致的軟體行為。 和客戶預期不一致的軟體行為。

51. ATM機吞卡的吞卡現象是不是BUG?

1.由於保護機制，你一次取錢數額有限，需要多次操作的時候每次現出卡你會覺得麻煩無比。

2.吞卡當然是為了安全，這沒有什麼爭論吧。

3.至今從沒見過吞了的卡還能吐出來的，根據後邊ATM機的構造，也不可能再退出來，是直接掉在一個小盒子裡的。

4.不可能你隨時去取吞卡別人就給你取，首先ATM必須雙人操作才能進，第二營業廳也必須雙人在場，不能一人在營業廳，所以一般都是加鈔的時候順便取出來。

5.現在在任何地方應該都不會有不核實情況直接給人吞卡的，外行卡除外，外行卡被吞，本行毫無辦法核實任何資訊，只能讓你出示身份證資訊並登記，確保是被你這個人取走的。

52. 如何減少非問題單的提交？

熟悉專案需求，充分了解各個各個功能模組的功能、引數、約束條件，弄清存在資料互動的模組之間的資料來源、資料流向；

53. 有個程式，在windows上執行很慢，怎麼判斷是程式存在問題，還是軟硬體系統存在問題？

同類型軟體在你的作業系統硬體環境上執行，如果一慢一塊，則是軟體問題

同一軟體在別人的作業系統上，如果執行速度加快，則是你的作業系統或硬體的問題

54. 你們發現bug會怎麼處理。

首先要做的是重現這個問題並反饋給研發人員，儘快出patch或者解決方案。

當BUG解決且上線沒有問題之後，我們再看後續的處理。

追查原因及處理方法：這個BUG出現的原因是什麼。這有分為幾種情況：

1）測試環境無法重現：可能是線上的環境造成的BUG或者是測試環境無法模擬的 情況。

 解決方法：儘量完善測試方法、儘量模擬測試環境、增加線上測試。

2）漏測：

 a.測試用例裁剪過度：錯誤預估優先順序或者時間過於緊迫裁剪了用例
​
 解決方法：在後續版本或者其他專案啟動時重新評估測試時間，要求專家介入對優先順序進行評估，避免此類事件再次發生。
 b.測試用例執行期間遺漏：由於測試人員疏忽造成測試用例執行遺漏。
​
 解決方法：調查該名測試人員的整個測試過程的工作情況，並隨機抽測其他模組，對該名測試人員進行綜合評估，給出結論，是因為偷懶漏測，還是因為負責模組過多漏測，還是有其他原因   ，對該名測試人員發出警告，對相關測試主   管，專案經理，產品經理髮出警告。
​
 c.測試用例覆蓋不全：由於用例評審的不嚴格造成的；中途需求變更造成的；由於某些其他因素造成的。
​
 解決方法：找到原因，並進行記錄，在以後的專案或者下一版本重點關注。

最最重要的：補測試用例！