測試面試題
B/S 只需要作業系統和瀏覽器就行，可實現跨平臺，客戶端零維護，個性化能力低，響應速度慢。 C/S 響應速度快，安全性高，一般用於區域網，因為要針對不同的作業系統需要針對性的開發，並且維護成本高
2、HTTP協議
1、https協議需要申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
4、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。
3，POST與GET區別
1，get是不安全的，因為在傳輸過程中資料被放在請求的URL中；post所有操作對使用者來說都是不可見的。 2，get傳輸量小，這主要是因為受URL長度限制；post傳送的資料量較大，一般被預設為不受限制。 3，get限制form表單資料集的值必須為ASCII字元；而post支撐整個IS010646字符集。 4，get執行效率卻比post方法好。Get是form提交預設方法。
4，Cookie和Session的區別與聯絡
1、Cookie和Session都是會話技術，Cookie是執行在客戶端，Session是執行在伺服器端。 2、Cookie有大小限制以及瀏覽器在存cookie的個數也有限制，Session是沒有大小限制和伺服器的記憶體大小有關。 3、Cookie有安全隱患，通過攔截或本地檔案找得到你的cookie後可以進行攻擊。 4、Session是儲存在伺服器端上會存在一段時間才會消失，如果session過多會增加伺服器的壓力
5，測試的目的
軟體測試的目的是為了保證軟體產品的最終質量，在軟體開發的過程中，對軟體產品進行質量控制。一般來說軟體測試應由獨立的產品評測中心負責，嚴格按照軟體測試流程，制定測試計劃、測試方案、測試規範，實施測試，對測試記錄進行分析，並根據迴歸測試情況撰寫測試報告。測試是為了證明程式有錯，而不能保證程式沒有錯誤
6，軟體測試原則
1，測試顯示軟體是否存在缺陷 2，窮盡測試時不可能的 3，測試儘早介入 4，缺陷叢集性 5，殺蟲劑悖論 6，測試活動依賴於測試內容 7，沒有錯誤是好是謬論
7，軟體測試分為哪幾個階段？
單元測試：比如說對Java中的類和方法的測試，一般由軟體開發人員實施（儘可能保證測試用例相對獨立，測試過程中不要呼叫其他類的方法，而是在測試用例中重寫模擬方法）
整合測試：（測試各個單元模組的介面）在單元測試的基礎上，把軟體單元按照*概要規格說明書*要求，組裝模組，測試看是否模組達到了規格技術指標。
系統測試：（黑盒測試）在經過整合測試的單元模組，按照整體*需求規格說明書*，進行一套有效嚴格的測試，保證軟體的正常執行。（整合測試偏重於技術角度，系統測試偏重於業務角度）
迴歸測試：（迴歸測試在測試生命週期中是很重要的一部分，會進行多次迴歸測試），是指在發生修改之後，再重新回去測試一下，避免修改的內容導致了其他的錯誤。驗證之前出現過但已修復好的缺陷不再重新出現。
冒煙測試：（是自由測試的一種）是指開發者功能完成後的完整性功能測試，發現問題後反饋給開發者進行修改，然後看這次修改是否真的修復解決了這bug，或者對其他模組造成了影響，這個時候就需要冒煙測試來進行驗證，缺點就是覆蓋率低。
驗收測試：也叫交付測試，是針對使用者需求、業務流程進行的整體測試，確認是否滿足驗收標準，由使用者、客戶看是否接受系統，可以部署上線。
Alpha測試：使用者在開發者的場所進行測試，是一個可控的環境中測試的。
Beta測試：是使用者在對軟體產品進行測試，開發者不在現場，使用者對測試過程中遇到的bug進行記錄，開發並對它進行修改，再測試，直到使用者覺得可以了，就部署上線。
8，單元測試與整合測試的側重點
單元測試
是在軟體開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試，測試重點是系統的模組，包括子程式的正確性驗證等。
整合測試
也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出來，影響功能的實現。測試重點是模組間的銜接以及引數的傳遞等。
9，系統測試範圍
指的是將整個軟體系統看做一個1個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。 系統測試由黑盒測試人員在整個系統整合完畢後進行測試，前期主要測試系統的功能是否滿足需求，後期主要測試系統執行的效能是否滿足需求，以及系統在不同的軟硬體環境的相容性等
10，a測試與ß測試的區別
它們都是驗收測試！
α測試是指把使用者請到開發方的場所來測試 β測試是指在一個或多個使用者的場所進行的測試。
α測試的環境是受開發方控制的,使用者的數量相對比較少,時間比較集中。 β測試的環境是不受開發方控制的, 使用者數量相對比較多,時間不集中。
α測試先於β測試執行。通用的軟體產品需要較大規模的β測試,測試周期比較
11，驗收測試怎麼做？
-
制定測試計劃，測試項，測試策略及驗收通過準則，並經過客戶參與的計劃評審。
-
建立測試環境，設計測試用例，並經過評審。
-
準備測試資料，執行測試用例，記錄測試結果。
-
分析測試結果，根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。 測試專案通過； 測試專案沒有通過，並且不存在變通方法，需要很大的修改； 測試專案沒有通過，但存在變通方法，在維護後期或下一個版本改進； 測試專案無法評估或者無法給出完整的評估。此時必須給出原因。如果是因為該測試專案沒有說明清楚，應該修改測試計劃。
-
提交測試報告。
12，白盒、黑盒和灰盒測試區別
白箱測試或白盒測試(White-box testing 或glass-box testing)是通過程式的原始碼進行測試而不使用使用者介面。這種型別的測試需要從程式碼句法發現內部程式碼在演算法，溢位，路徑，條件等等中的缺點或者錯誤，進而加以修正。
黑箱測試或黑盒測試(Black-box testing)是通過使用整個軟體或某種軟體功能來嚴格地測試, 而並沒有通過檢查程式的原始碼或者很清楚地瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。測試人員通過輸入他們的資料然後看輸出的結果從而瞭解軟體怎樣工作。通常測試人員在進行測試時不僅使用肯定出正確結果的輸入資料，而且還會使用有挑戰性的輸入資料以及可能結果會出錯的輸入資料以便了解軟體怎樣處理各種型別的資料。
灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過使用者介面測試，但是測試人員已經有所瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。甚至於還讀過部分原始碼。 因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。這樣做的意義在於:如果你知道產品內部的設計和對產品有透過使用者介面的深入瞭解，你就能夠更有效和深入地從使用者介面來測試它的各項效能。
13，冒煙測試的目的
為正式測試前，驗證是否產品或系統的主要需求或預置條件是否存在bug。
14，迴歸測試怎麼做？
1、在測試策略制定階段，制定迴歸測試策略 2、確定需要回歸測試的版本 3、迴歸測試版本釋出,按照迴歸測試策略執行迴歸測試 4、迴歸測試通過，關閉缺陷跟蹤單（問題單） 5、迴歸測試不通過，缺陷跟蹤單返回開發人員，開發人員重新修改問題，再次提交測試人員迴歸測試
15，全部迴歸與部分迴歸的區別？
對軟體的新版本測試時，重複執行上一個版本測試時使用的測試用例，防止出現“以前應用沒有的問題現在出問題了”，這是全部迴歸；當在測試過程中，發現某個模組存在缺陷，開發修復後，測試人員重新驗證該缺陷是否被修復，以及驗證相關聯的模組是否受影響，這叫部分迴歸。
16，需求分析的目的
第一、把使用者需求轉化為功能需求：1）對測試範圍進度量 2）對處理分支進行度量 3）對需求業務的場景進行度量 4）明確其功能對應的輸入、處理和輸出 5）把隱式需求轉變為明確。
第二、明確測試活動的五個要素：測試需求是什麼、決定怎麼測試、明確測試時間、確定測試人員、確定測試環境：測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到儘可能的詳細明確，以避免測試遺漏和誤解。
17，測試計劃的目的
1.儘早地明確測試工作內容（範圍）、測試工作的方法以及測試工作所需要的各種資源 2.所有涉及到測試工作的人員，儘快將下一步測試工作需要考慮的問題和準備的條件落實。 3.測試計劃工作的重點在於：對當前工作任務的準備和規劃以及資訊的交流。
18，什麼時候開始寫測試計劃
開立項會之後由測試人員開始寫測試計劃
19，由誰來編寫測試計劃
測試人員
20，測試計劃的內容
1.簡介
2.參考文件和提交檔案
3.進度安排
4.測試資源
5.嚴重程度和優先順序
6.風險分析
7.測試策略
21，結束條件(專案上線的條件)
1) 軟體系統在進行系統測試過程中，發現一、二級缺陷數目達到專案質量管理目標要求，測試暫停返回開發； 2) 軟體專案在其開發生命週期內出現重大估算和進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點資料； 3) 如有新的需求變更過大，測試活動應暫停，待原測試計劃和測試用例修改後，再重新執行測試； 4) 若開發暫停，則相應測試也應暫停，並備份暫停點資料； 5) 所有功能和效能測試用例100％執行完成； 此外，測試是有成本的，當你2周發現2個bug有類似此種情況時，在產品質量要求不是十分嚴格的情況下，即可以停止測試了。
22，常見的測試風險
需求風險
測試用例風險
缺陷風險
程式碼質量風險
測試環境風險
測試技術風險
迴歸測試風險
溝通協調風險
研發流程風險
其他不可預計風險
23，測試用例的要素
1、*用例編號*：測試用例的編號有一定的規則，比如系統測試用例的編號定義規則：MS-ST-001，命名規則是專案名稱+測試階段型別(系統測試階段)+編號。編號是為了查詢測試用例，便於測試用例的跟蹤。
2、*測試專案*：要測試專案的名稱，可以是測試用例所屬的大類，被測需求，被測模組或者是被測的單元。
3、*測試標題*：對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如”測試使用者登入時輸入錯誤密碼時，軟體的響應情況“。
4、*重要級別*：定義測試用例的優先級別，可以分為”高“、”中“、”低“三個級別。
高：保證系統基本功能、重要特性、實際使用頻率比較高的用例；
中：重要程度介於高和低之間的測試用例；
低：實際使用頻率不高，對系統業務功能影響不大的模組或功能的測試用例。
一般如果軟體需求的優先順序是”高“，那麼針對該需求的測試用例優先順序也是”高“；反過來也是一樣。
5、*預置條件*：就是執行當前測試用例的前提描述，如果不滿足這些條件，則無法進行測試。
6、*測試輸入*：測試用例執行時，需要輸入的外部資訊。
7、*操作步驟*：執行當前測試用例所要經過的操作步驟，需要給出每一步操作的詳細描述，測試人員根據測試用例操作步驟，完成測試用例的執行。
8、*預期結果*：當前測試用例的預期輸出結果，用來與實際結果比較，如果相同則該測試用例通過，否則該測試用例失敗。
以上八個要素是最重要的，下面這些選寫：
9、*作者*：誰寫的
10、*建立時間*：寫用例的日期
11、*修改日期*：最後一個修改用例的日期
12、*測試結果*：執行用例後的結果：pass、fail、block
24，測試用例級別的劃分
優先順序一般都是和缺陷的嚴重程度對應的。
一般可以把優先順序分為三種：
高（Highs）：保證功能性是穩定的，是按照需求的正常使用和實現點進行用例設計的，重要的錯誤和邊界測試的測試用例的集合。
中（Mediums）：更全面的驗證功能的各方面，包括流程中的各個節點出錯情況、異常情況測試、中斷、UI展示、使用者體驗等方面的測試用例設計
低（Lows）：不常被執行的測試用例。比如壓力和效能測試用例設計，介面測試用例設計隨著時間的推移已經從低級別變化到了中級別。
我們將測試用例分成：高，中和低。
25，怎樣保證覆蓋使用者需求？
使用者需求：描述了使用者使用產品必須要完成的任務，在軟體開發活動中，屬於基本的需求。
系統需求：描述了軟體設計人員、程式設計人員必須要完成的任務。系統分析員通過分析使用者需求，把使用者的需求轉變成開發設計人員看得懂的系統需求。
測試需求：描述了軟體測試人員必須要完成的任務。測試工程師通過分析系統需求，產生測試需求，作為測試活動的指導。
26，寫好測試用例的關鍵 /寫好用例要關注的維度
編寫測試用例主要有以下6個主要作用： 1.便於理清測試思路，確保需覆蓋測試的功能點無遺漏 2.便於測試工作量的評估 3.便於提前準備測試資料 4.便於把控測試工作進度 5.便於迴歸測試 6.便於測試工作的組織，提高測試效率，降低測試交接成本
1、UI 測試
2、功能
3、易用性
4、容錯性：特殊字元測試
5、效能
6、相容性測試：IE8/9/10/11 谷歌瀏覽器 火狐瀏覽拿起
7、安全
27，測試用例的狀態
*排隊：*測試用例已經指定給某個測試人，不準備在這一個測試階段執行。
進行中：該測試正在進行，並且會持續一段時間。
阻塞：一些因素會導致測試不能進行到底，我通常會在測試用例總結工作表的意見欄記錄下阻塞的狀態。
跳過：你決定在當前測試階段跳過某個測試，可能是因為它的優先權相對較低。
通過：測試執行結束，測試人得到了預料中的測試結果狀態和測試行為。
失敗：在很多情況下，測試人得到預料之外的測試結果，狀態或行為，這些結果與測試目標相差甚遠。這就引發了關於系統質量的疑問。一個或多個測試錯誤需要記錄下來。
警告：在很多情況下，測試人得到預料之外的測試結果，狀態或行為，但是這些結果與測試目標差別不是很大，只和延期的或不是一定要改的錯誤相關的測試可以標記為警告，而不是失敗。
關閉：一個測試在第一個迴圈中被標為失敗或警告，第二個測試釋出中將第一個測試迴圈出現的錯誤修改了。重新運行了整個測試用例後，沒有錯誤出現。將這類測試標記為關閉而不是通過，
28，常見的測試用例設計方法
等價類劃分，邊界值，錯誤推測，因果圖，場景法，正交表 應用的場景 等價類劃分 多用於輸入框：註冊/登入 邊界值（掌握上點和離點的取值） 多和等價類劃分結合使用，有邊界限制的:註冊的密碼長度，， 場景法 從基本流開始，再將基本流和備選流結合起來，可以確定用例場景 銀行取錢 正交表 用於多個下拉框之間的組合，可以通過正交助手生成測試用例 錯誤推測 錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。 一般這種方法是基於經驗和直覺推測程式中可能傳送的各種錯誤，有針對性地設計。只能作為一種補充 因果圖 因果圖法比較適合輸條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結果就是輸出 自動販賣機
29，判定表用在哪些時候/哪些功能
判定表bai方法是黑盒測試方法的一種du，主要zhi用於輸入和輸dao出比較多，功能zhuan邏輯比較複雜的情況，通過畫shu出判定表縷清需求中的功能邏輯，還能確保找到輸入的所有組合情況獲得更多關於測試的知識，
30，什麼時候用到場景法
場景法：通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的一種方法。
30，什麼時候用到場景法
1、現在在的軟體幾乎都是用事件觸發來控制流程的,事件觸發時的情景便形成了場景，而同一事件不同的出發順序和處理結果就形成事件流。這種在軟體設計方面的思想也可以引入到軟體測試中，可以比較生動的描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使用測試用例更容易理解和執行。
31，測試環境怎麼搭建的？
1、搭建測試環境，確定測試目的
測試環境儘可能的模擬真實環境
確保環境無毒
營造獨立的測試環境
構建可複用的測試環境
2、安裝依賴軟體
拿python專案舉例
安裝python3、pymysql、redis等需要的工具。
匯入Django、pymysql、redis等需要的第三方模組
拿Java專案舉例
安裝JDK、tomcat、資料庫等需要的工具。
3、拉取程式碼
需要知道SVN地址或者Git地址
4、修改配置檔案
修改資料庫、redis等配置檔案的配置資訊，修改成測試環境的配置資訊
5、編譯、打包（python不需要編譯直接可以執行，如果是Java、c、 c++需要編譯）
6、匯入基礎資料
建表、匯入管理員賬號之類的資訊，即把sql在測試資料庫執行一次
7、啟動程式。
32，偶然性問題的處理
一、一定要提交
1、記得有這麼個缺陷，以後再遇到的時候可能就會了解發生的原因。
2、盡力取查找出錯誤的原因，比如有什麼特別的操作，或者一些操作環境等。
3、程式設計師對程式比測試人員熟悉的多，也許你提交了，即使無法重現，程式設計師也會了解問題所在
4、無法重現的問題再次出現後可以直接叫程式設計師來檢視問題。
5、對於測試人員來說，沒有操作錯誤這條既然遇到了就是問題。即使真的操作錯了，也要推到程式設計師哪裡，既然程式設計師員犯錯誤，使用者可能會犯同樣的錯誤。錯誤發生的時候，Tester最大。
33，當我們認為某個地方是bug，但開發認為不是bug，怎麼處理？
1 首先，將問題指派給開發人員。
2 然後，要獲取判斷的依據和標準：
3 根據需求說明書、產品說明、設計文件等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
4 如果沒有文件依據，可以根據類似軟體的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
5 根據使用者的一般使用習慣，來確認是否是缺陷；
6 與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
7 合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
8 等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並有上級做出決定。
9仍不確定為BUG在上線前的測試總結中寫入這個BUG
34，產品在上線後用戶發現bug，這時測試人員應做哪些工作？
評估BUG的嚴重程度當程度高的時候應立即提示使用者下線止損。
測試復現後提交缺陷管理軟體，考慮bug的優先級別，再考慮修復的影響範圍和難易度，然後出對應得補丁包。 在分析bug的原因，判斷是什麼因素導致的問題，再前往bug內容對相近的模組和類似的介面處進行復查。出現問題進行風險預防。
當BUG的程度不高為中等時提示使用者維護或在下次版本迭代時進行修復進行迴歸測試
35，二八定理
二八定律是一種社會準則，符合大多數社會現象的規律。同樣也適用於網際網路領域。
比如一個網站有成千上萬的使用者，但是80%的使用者請求是發生在20%的時間內，比如大家去網上購物，基本也都集中在中午休息或晚上下班後。二八定律的核心原則是關注重要部分，忽略次要部分。系統性能如果能支撐發生在20%時間內的高併發請求，必然也能支援非高峰期的訪問。
36，如何跟蹤缺陷
發現缺陷-->提交缺陷-->將缺陷指派給開發-->開發確認缺陷-->研發去修復缺陷-->迴歸測試缺陷-->是否通過驗證-->關閉缺陷
37. 缺陷的狀態
-
New（新的）：bug提交到缺陷庫中會自動的被設定成New狀態
-
Assigned（已指派）：當一個bug被認為New之後，將其分配開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為“Assigned”
-
Open（已開啟）：開發人員開始處理bug時，他將這個bug的狀態設定為“Open”，表示開發人員正在處理這個“bug”
-
Fixed（已修復）：當開發人員進行處理（並認為已經解決）之後，他（她）就可以將這個bug的狀態設定為“Fixed”並將其提交給開發組的負責人，然後開發組的負責人將這個bug返還給測試組
-
Rejected(被拒絕)：測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之後認為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設定為“Rejected”
-
Postponed（延期）：有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試資料，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設定為“Postponed”
-
Closed（已關閉）：測試人員經過再次測試後確認bug已經被解決，將bug的狀態設定為“Closed”
-
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. 概述：一般會在概述中新增專案背景、需求描述等資訊。
-
測試過程主要包含評審記錄、測試範圍、測試用例
-
羅列出是否已按本次測試計劃實現功能
-
包括資源統計、執行情況、問題統計、問題列表、遺留問題
-
主要總結本次測試測了哪些內容、用例覆蓋程度、bug解決程度等，以及最終是否決定通過本次測試。
-
測試風險沒有放在測試總結裡，而是單獨劃分為一個模組，可見其重要性。
41，如何定位bug：
1、發現bug，首先要檢視bug的詳細資訊，根據描述初步分析是哪個模組哪段程式碼的問題
2、檢查引發bug的測試環境、測試程式碼段和測試資料，排除測試人員的誤操作導致的程式異常
3、確認測試程式碼、測試環境和資料都正確後，再進一步分析bug根源。這裡就需要看具體的測試業務了，可藉助相關的工具進行分析，比如firebug外掛等
4、如果產品或業務有相關的日誌記錄，可通過分析日誌來確認bug
5、當測試人員經過一系列的分析，可以基本確認bug產生的原因後，就可以直接找開發提bug了（注意溝通技巧）
6、如果各方面都分析完還不能確認bug的原因，可以找開發一起定位（注意保留bug現場或者可以復現bug場景）
7、確認bug後，提單給開發進行bug跟蹤。
問題單上要描述清楚以下資訊：
具體的測試時間、測試環境、測試場景、測試的具體業務和功能、使用的測試程式碼和測試資料、測試執行步驟、測試結果、bug現象（最好截圖）、日誌記錄、預期結果、bug確認相關人員等
8、跟蹤bug，等開發人員修復bug後進行迴歸測試。（關注bug是否完全修復、有沒有對其他功能造成影響、有沒有引入新的問題）
42，開發沒時間修復，如何推進bug的修復：
在測試過程中，不免會遇到開發人員因為一些原因不想修改個別bug的情況。那一般遇到這種問題時，我們該如何去推進開發修改bug呢？
我們先來分析下到底會有哪些原因會導致開發不修改bug
1、 開發與測試對bug的定義理解不一致產生的問題，例如暴力操作、非常規操作出現的問題、問題路徑深、伺服器返回的資料不規範、競品同樣有的問題、個別機型問題等情況，開發可能會不願意修改。
2、 工作流程方面的原因，例如開發有更高優先順序的任務沒有時間修改、上線時間緊急，來不及修改、開發不關注名下的bug、開發認為目前的實現比產品需求好等情況
3、 當然還有個人能力原因，例如找不到好的解決方案、影響範圍大、找不到bug原因，沒有解決方案、技術實現難，不知道怎麼修改等等原因
4、 另外還有一些不可抗力的客觀因素，例如系統問題，第三方應用問題等等
我的觀點
開發不修改bug有這麼多原因，但我們測試推動開發修改bug卻只有一個原因~那就是責任。關子少賣，對策拿來~通過一個案例幫你分析解決方案~
小明來也~
小明測試輸入法時發現，更換面板後，在某鵝應用中調起鍵盤並轉屏，鍵盤會顯示異常，無法正常使用。
提交bug後，開發調研原因，發現輸入法並有沒有針對轉屏做特殊處理，猜測可能是某鵝應用的問題，如果我們做適配改動會比較大。並且這個操作使用者不易遇到，並且軟體上線在即，所以不太想修改。測試認為轉屏屬於常用操作，使用者一但觸發此bug，輸入法則無法正常使用，非常影響使用者的體驗。在測試的堅持下，開發人員為輸入法做了些保護，並將問題反饋給該應用，應用負責人答應在下個版本修復。問題很快得到了解決。
分析上述案例，開發不修改bug的原因有四：bug路徑較深、上線時間緊急、改動影響範圍大、第三方應用問題。我們逐條分析解決方案
1、 針對路徑較深的bug，測試在推動開發修復bug時，需要注意以下幾點
a) 從使用者的角度分析問題的嚴重性，分析使用者的遇到此問題的概率，引導開發站在使用者角度去思考，從而使開發意識到問題的嚴重性
b) 可以和開發人員列舉一個之前的類似問題，為開發提供參考
c) 產品是負責這個軟體的人員，當測試與開發意見無法達成一致時，不要因為無法推動開發修改而放棄，一定要找產品確認，最終的決定權交給產品人員。
2、 上線時間緊張，開發來不及修改了，這個時候測試應該分析問題的嚴重性，和產品人員商議是否需要修改
3、 修改bug改動較大，影響範圍廣，沒有最優的解決方案等情況在專案即將上線的節點比較忌諱這種事情的發生。面對這種情況，建議開發人員做調研工作，請教其他的同事，或者組織一個臨時會議，集眾人之力研究好的修改方案
4、 第三方應用問題，開發無法修改。確認原因之後需要找相關的工作人員，例如產品，聯絡第三方輸入法的工作人員，反饋問題，儘量推動應用解決問題
小結
總之，bug修不修，測試應該有一個自己的原則，同時也要權衡利弊。不能因為推不動開發，就放棄，由著bug上線，也不能揪著一個小bug不放，影響上線時間。推動開發人員修復bug需要技巧，你get了嗎？
43，軟體測試流程
立項(確定專案)--編寫需求(需求人員)--需求評審(編寫需求人員發起)--開發編寫概要和詳細設計(編碼並自測[開發環境]) 測試:測試用例-測試用例評審(測試人員發起)--部署環境--冒煙測試(通過)--提交bug--迴歸測試(測試報告)--驗收測試--上線
44，專案介紹
我們一般在專案進行開立項會【產品經理 專案經理 開發人員 測試人員】的時候進行參與， 討論需求並提出建議，在立項會中制定需求文件，由ui設計原型圖，開發根據需求文件進行編碼， 我們測試會根據需求文件進行編寫 測試計劃，根據模組的（顆粒度）劃分並編寫測試用例以及對用例的評審， 開發結束侯測試對主要功能進行冒煙測試，執行測試用例，提交bug 開發進行修改，修改成功後關閉bug， 進行迴歸測試，在上線前進行測試總結。
45，對一支圓珠筆進行測試，要從哪些方面進行測試？
1.功能測試： 圓珠筆按下是否能正常書寫。
2.效能測試： 筆芯彈出彈回的快慢。
3.負載測試： 連續按，看彈簧能經受多少次伸縮。
4.相容性測試： 看是否可以使用其他筆芯。
5.強度測試： 用力過度會有什麼影響
6.可恢復性測試： 長時間按住彈簧，鬆開後看彈簧是否可以恢復
7.介面測試： 筆的外觀，舒適度
8.安全性測試： 是否會對使用者造成傷害
三角形測試用例設計
在三角形計算中，要求三角形的三個邊長：A B C 。
1、 當三邊不可能構成三角形時提示錯誤，可構成三角形時計算三角形周長。
2、若是等腰三角形列印“等腰三角形”， 若兩個等腰的平方和等於第三邊平方和，則列印“等腰直角三角形”。
3、若是等邊三角形，則列印：“等邊三角形”。
4、畫出程式流程圖並設計一個測試用例。
分析一下：
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？什麼原因導致的？
1.支付後，狀態沒有同步。
2.金額是不足1元，會顯示為小數點前面的0不見了
3.查詢功能第二頁的內容與第1頁的內容完全相同
4.匯出為excel檔案，內容亂碼（後臺管理員端會涉及匯出）
5.匯入：商品上架可以支援匯入，匯入上千個商品曾發生卡死。（線上Bug）
6.查詢訂單時，系統提示訂單不存在。
7.按鈕不起作用，比較容易發生在返回按鈕，上一步按鈕
8.付款賬號和收款賬號相同，會導致交易失敗
9.存在頁面某個資料顯示為Null，這個資料沒有同步過來。響應中沒有這個資料
10.錯誤資訊顯示為錯誤程式碼，在測試環境比較容易出現。
11.同一個賬號顯示為不同格式，比較容易出現在手機號的顯示。13800138001 138 0013 8001
12.時間的顯示格式不正確，沒有做出適合中國人的顯示格式
13.資料的狀態不正確，有一筆訂單是已經支付，但在某些地方顯示為未支付。
14.偶爾可能出現亂碼，只有中文亂碼
15.輸入框輸入過長的內容，也能夠提交。
47，一個專案完成時，有多個重要的缺陷沒有被修復，但是專案負責人說可以不修改，你認為測試是不通過的，請簡述你的理由。
48，在需求文件不太詳細的情況下，如何開展測試？
-
解決使用者問題或達到使用者目標需要具備的條件或能力
-
遵守合同、協議、規範或其他要求
49，如何儘快找到軟體中的bug?
1.儘快熟悉軟體的需求和業務，只有熟悉了產品的業務流程、你才能迅速找出軟體中存在的一些重要的缺陷 2.把自己當成使用者，把自己當成是使用者去使用該系統，比如在使用該系統過程中是這樣操作的嗎？ 3.善於懷疑，不要開發人員的能力 4.不要讓程式開發人員的觀點：“使用者不會進行這樣的操作”而說服自己 5.使用完整的流程去測試軟體系統，有些子流程在單獨測試時沒有問題，但按流程走的時候問題就可能出來了。
50，什麼是bug？
產品說明書中規定要做的事情，而軟體沒有實現。 產品說明書中規定不要做的事情，而軟體確實現了。 產品說明書中沒有提到過的事情，而軟體確實現了。 產品說明書中沒有提到但是必須要做的事情，軟體確沒有實現。 軟體很難理解，很難使用，速度超慢，測試人員站在終端使用者的角度看到的問題是平常的但不是正確的。
注：產品說明書中沒有提到但是必須要做的事情，軟體確沒有實現。軟體實現了產品的功能，但是沒有考慮軟體在弱網路、低電量的情況下也能正常使用，而做出來的產品在弱網路或低電量的情況下報錯，那麼這也是一個bug。
或者
1.不符合客戶確認過的需求 2.已超越客戶確認過的需求 3.和使用者的互動習慣不一致 4.與使用者的介面審美不一致
51，ATM機吞卡的吞卡現象是不是BUG?
不是
是特意設定的安全措施 防止有人馬虎，操作後忘記取走銀行卡而被人冒領卡中的錢款 所以特意設定了倒計時，限時內沒有取走銀行卡就會吞卡
52，如何減少非問題單的提交？
53，有個程式，在windows上執行很慢，怎麼判斷是程式存在問題，還是軟硬體系統存在問題？
1、檢查系統是否有中度的特徵，如：瀏覽器視窗連續開啟，系統中檔案圖示改成統一圖示，CPU使用率儲存90%以上等 2、檢查軟體/硬體的配置是否符合軟體的推薦標準 3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務，如：虛擬機器執行 4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的； 5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對CPU/記憶體的訪問情況，
效能監視器開啟方法：
一、【開始》執行】輸入perfmon，回車 二、右鍵【計算機》管理】