1.B/S架構和C/S架構區別 c是客戶端 b是瀏覽器
CS響應速度快，安全性強，使用者體驗好，一般應用於區域網中，但是開發維護成本高，；BS可以實現跨平臺，客戶端零維護，但是個性化能力低，響應速度較慢。所以有些單位日常辦公應用BS，在實際生產中使用CS結構
2.HTTP協議
HTTP協議定義Web客戶端如何從Web伺服器請求Web頁面，以及伺服器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向伺服器傳送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求資料。伺服器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤程式碼、伺服器資訊、響應頭部和響應資料
3.POST與GET區別
1、GET使用URL或Cookie傳參。而POST將資料放在BODY中。
2、GET的URL會有長度上的限制，2kb，則POST的資料則可以非常大。
3、POST比GET安全，因為資料在位址列上不可見。
4、一般get請求用來獲取資料，post請求用來傳送資料
4.Cookie和Session的區別與聯絡
Session和Cookie的主要區別在於：
Cookie是把資料儲存在瀏覽器端的記憶體中
Session把資料儲存在伺服器端的記憶體中
cookie與session的聯絡：
當伺服器端生成一個session時就會向客戶端傳送一個cookie儲存在客戶端，這個cookie儲存的是session的sessionId。。這樣才能保證客戶端發起請求後客戶端已經登入的使用者能夠與伺服器端成千上萬的session中準確匹配到已經儲存了該使用者資訊的session，同時也能夠確保不同頁面之間傳值時的正確匹配。
5.測試的目的
1.軟體測試的目的是為了保證軟體產品的最終質量，在軟體開發的過程中，對軟體產品進行質量控制。一般來說軟體測試應由獨立的產品評測中心負責，嚴格按照軟體測試流程，制定測試計劃、測試方案、測試規範，實施測試，對測試記錄進行分析，並根據迴歸測試情況撰寫測試報告。測試是為了證明程式有錯，而不能保證程式沒有錯誤。
6.軟體測試原則
所有測試bai的標準du都是建立在使用者需求之上zhi的，測試的目的在於dao發現系統是否滿足規定的需zhuan求；
“儘早地和不斷地測試”，越早進行測試，缺陷的修復成本就會越低；
程式設計師應避免檢查自己的程式，由第三方進行測試更客觀有效；
窮舉測試是不可能的；
充分注意測試中的群集現象，一段程式中一發現的錯誤數越多，其中存在的錯誤概率越大，因此對發現錯誤較多的程式段，應進行更深入的測試；
設計測試用例時應包括合理輸入和不合理輸入，以及各種邊界條件、特殊情況下要製造極端狀態和意外狀態；
注意迴歸測試的關聯性，往往修改一個錯誤會引起更多錯誤；
測試應從“小規模”開始，逐步轉向“大規模”；
測試用例式設計出來，不是寫出來的，應根據測試的目的，採用相應的方法設計測試用例，從而提高測試的效率，更多的發現錯誤，提高程式的可靠性；
重視並妥善儲存一切測試過程文件（測試計劃，測試用例，測試報告等）；
對測試錯誤結果一定要有一個確認的過程
7.軟體測試分為哪幾個階段？
單元測試、整合測試、系統測試、驗收測試、迴歸測試
8.單元測試與整合測試的側重點
單元測試是在軟體bai開發過程du中要進行的最低階別的zhi測試活動，在單元dao測試活動中，軟體zhuan的獨立單元將在與shu程式的其他部分相隔離的情況下進行測試，測試重點是系統的模組，包括子程式的正確性驗證等。
整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出來，影響功能的實現。測試重點是模組間的銜接以及引數的傳遞等。
9.系統測試範圍
黑盒測試。不接觸程式碼，只對整個系統做功能的測試和效能的測試。
10.a測試與ß測試的區別
11.驗收測試怎麼做？
使用者驗收測試是軟體開發結束後，使用者對軟體產品投入實際應用以前進行的最後一次質量檢驗活動。它要回答開發的軟體產品是否符合預期的各項要求，以及使用者能否接受的問題。
使用者驗收測試可以分為兩個大的部分：軟體配置稽核和可執行程式測試，其大致順序可分為：文件稽核、原始碼稽核、配置指令碼稽核、測試程式或指令碼稽核、可執行程式測試。
由於驗收測試不只是檢驗軟體某個方面的質量，而是要進行全面的質量檢驗，並且要決定軟體是否合格，因此驗收測試是一項嚴格的正式測試活動。需要根據事先制訂的計劃，進行軟體配置評審、功能測試、效能測試等多方面檢測
12.白盒、黑盒和灰盒測試區別
白箱測試或白盒測試(White-box testing 或glass-box testing)是通過程式的原始碼進行測試而不使用使用者介面。這種型別的測試需要從程式碼句法發現內部程式碼在演算法，溢位，路徑，條件等等中的缺點或者錯誤，進而加以修正。
黑箱測試或黑盒測試(Black-box testing)是通過使用整個軟體或某種軟體功能來嚴格地測試, 而並沒有通過檢查程式的原始碼或者很清楚地瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。測試人員通過輸入他們的資料然後看輸出的結果從而瞭解軟體怎樣工作。通常測試人員在進行測試時不僅使用肯定出正確結果的輸入資料，而且還會使用有挑戰性的輸入資料以及可能結果會出錯的輸入資料以便了解軟體怎樣處理各種型別的資料。
灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過使用者介面測試，但是測試人員已經有所瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。甚至於還讀過部分原始碼。 因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。這樣做的意義在於:如果你知道產品內部的設計和對產品有透過使用者介面的深入瞭解，你就能夠更有效和深入地從使用者介面來測試它的各項效能。
13.冒煙測試的目的
冒煙測試是為了在執行效能測試或壓力測試之前，確保一切都已正確配置並可按預期執行
14.迴歸測試怎麼做？
1、在測試策略制定階段，制定迴歸測試策略
2、確定需要回歸測試的版本
3、迴歸測試版本釋出,按照迴歸測試策略執行迴歸測試
4、迴歸測試通過，關閉缺陷跟蹤單（問題單）
5、迴歸測試不通過，缺陷跟蹤單返回開發人員，開發人員重新修改問題，再次提交測試人員迴歸測試
15.全部迴歸與部分迴歸的區別？
16.需求分析的目的
第一、把使用者需求轉化為功能需求：
1）對測試範圍進度量
2）對處理分支進行度量
3）對需求業務的場景進行度量
4）明確其功能對應的輸入、處理和輸出
5）把隱式需求轉變為明確。
第二、明確測試活動的五個要素：測試需求是什麼、決定怎麼測試、明確測試時間、確定測試人員、確定測試環境：測試中需要的技能，工具以及相應的背景知識，測試過程中可能遇到的風險等等。測試需求需要做到儘可能的詳細明確，以避免測試遺漏和誤解。
17.測試計劃的目的
1、測試的目的是為bai了發現儘可能多的缺陷，不是du為了說明軟體中沒有缺陷。
2、成功的測試在於發現了迄今尚未發現的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟體裡的缺陷。
18.什麼時候開始寫測試計劃
有了詳細的產品需求說明書後，在系統設計階段就應該寫系統測試方案，系統測試計劃並開始詳細設計測試用例了。
19.由誰來編寫測試計劃
1.專案經理
專案經理當然是從整個專案角度出發，編寫整體專案計劃，那麼其中就包括測試的計劃了，他依賴於對應的開發計劃，也就是首先要有開發計劃、提測計劃，再評估測試計劃，最終得出上線時間
2.測試經理
測試經理主要是從測試組角度出發，編寫專案的測試計劃，重點就是專案的任務拆分、合理的安排人力資源、預估時間和風險等
3.測試人員
測試同學本人收到測試經理同步過來的具體分工後，也需要編寫自己的測試計劃，重點就是詳細的說明自己的時間規劃、每一個測試任務的前期準備以及開始和結束測試的時間等
20.測試計劃的內容
測試背景
測試目的
確定測試範圍
制定測試策略（功能測試/業務測試..）
測試資源安排
測試時間安排
測試人員分配
風險評估
21.結束條件(專案上線的條件)
22.常見的測試風險
1、需求風險
產品需求的不明確，對產品需求理解不準確，導致測試範圍存在誤差，遺漏部分需求或者執行了錯誤的測試方式；另外需求變更導致測試用例變更，測試用例維護成本增加，實時更新時存在誤差。
2、測試用例風險
測試用例設計不完整，忽視了邊界條件、異常輸入等情況，用例覆蓋率沒有做到足夠覆蓋，測試用例沒有得到全部執行，有些用例被有意或者無意的漏測，需求變更導致的測試時間被壓縮等情況。
3、缺陷風險
某些缺陷偶發，難以重現，容易被遺漏；缺陷跟蹤不夠積極主動，沒做好缺陷記錄和及時更新，同樣的缺陷，導致的原因可能不同，對這點沒意識到導致的線上生產問題等。
4、程式碼質量風險
程式碼質量差，可讀性差，重構性差，沒做好註釋等原因導致缺陷較多，修改難度增大；另外還有系統架構設計的不足，導致的擴充套件性不足，效能相容差等問題。
5、測試環境風險
測試環境和生產環境配置不同，測試環境交叉影響較大，測試環境資料量不足導致的測試結果誤差等問題。
6、測試技術風險
某些專案存在技術難度，測試能力和經驗所限，技術水平相對較差導致測試進展緩慢，測試結果準確性不夠，專案釋出日期延期等問題。
7、迴歸測試風險
迴歸測試，一般時間相對來說較少，且大多隻迴歸主要的功能點用例，可能造成漏測；另外還有迴歸驗證缺陷時業務流走不通導致的打回修復再驗證造成的時間延後問題。
8、溝通協調風險
專案進行過程中需要多方溝通協調，不同部門，崗位之間的溝通、協作，難免存在誤解、溝通不暢的情況，比如需求變更沒有及時溝通，開發程式碼提交沒有及時告知，測試結果的反饋不及時等問題。
9、研發流程風險
其中包括從產品需求評審、研發設計、程式碼提交、測試釋出等一些列流程，流程的不規範不協調很可能導致很多問題；比如開發在不告知其他成員的情況下提交程式碼，釋出沒有預生產環境，生產出現
問題無法及時回滾等很多說爛了的情況。流程沒必要一板一眼的執行，但沒有流程是萬萬不行的。
10、其它不可預計風險
一些突發狀況、不可抗力等也構成風險因素，且難以預估和避免。對於這種情況，往往一時無法解決，建議做好備份方案和容災機制，或者採用灰度釋出等措施。
PS:以上是測試過程中可能發生的風險及原因，其中有的風險是難以避免的，如缺陷風險；有的風險從理論上可以避免，如需求風險，溝通風險等；還有些風險在實際操作過程中出於時間和成本的考慮，
也難以完全迴避，如迴歸測試風險等。
對於這些風險的存在，要儘量避免，也要做好備份方案和容災機制，規範流程，明確職責，儘可能將風險降到可接受範圍內。。。
23.測試用例的要素
用例編號，所屬模組，用例描述，前置條件，優先順序，輸入資料，操作步驟，預期結果，實際結果，測試人員，測試時間
24.測試用例級別的劃分
高（Highs）：保證功能性是穩定的，是按照需求的正常使用和實現點進行用例設計的，重要的錯誤和邊界測試的測試用例的集合。
中（Mediums）：更全面的驗證功能的各方面，包括流程中的各個節點出錯情況、異常情況測試、中斷、UI展示、使用者體驗等方面的測試用例設計
低（Lows）：不常被執行的測試用例。比如壓力和效能測試用例設計，介面測試用例設計隨著時間的推移已經從低階別變化到了中級別。
25.怎樣保證覆蓋使用者需求？
首先，確認需求
面試官簡單描述這道題後，你是否真的已經瞭解了他的需求呢，如上描述，需求範圍過於籠統，也就是要明確使用者故事。請問這個需求是怎樣的專案背景或基於什麼前提下而做的；會涉及到哪些支撐平臺；具體需要怎樣的許可權可以上傳操作；該功能的迭代會影響到哪些其他的存量功能等，是否有明確的效能需求等
第二，梳理需求，確認測試範圍
是否需要考慮歷史資料，資料來源，使用者角色，支援哪些作業系統，相容性要求（考慮平臺相容性、瀏覽器相容性、手機型號 版本等），是否提供介面文件，DB設計文件等等
第三，制訂測試計劃
通過測試需求與測試範圍，制訂測試計劃，我需要運用到的測試方法，工作量預估，測試資源，每個節點的測試型別，以及結束測試標準等等（可以針對此面試題來描述）
測試計劃需要經過專案組干係人評審通過後才可以進行下一步
第四，根據測試計劃設計測試用例
當然，此步會根據個人習慣和經驗來適當增減，如先使用思維導圖理出測試想法， 然後再擴充套件。可以按可接受性測試用例、系統測試用例（介面、功能、效能、安全、UI、DB...）來開始設計用例。這樣就可以按照所學的N+測試方法來充分設計Case了，而有了測試計劃中的相關策略來指導 ，也不會疏漏其他的需求點了。
第五，後續的執行測試步驟（可以依情況來作描述）我們暫且就此面試題展開分析 ，故不作深入探討 。
26.寫好測試用例的關鍵 /寫好用例要關注的維度
做好測試用例工作的關du鍵是要充分考慮測試計劃zhi的實用性，堅持5W1H的原則，dao採用評審和更新機制以及測試策略。要充分考慮測試計劃的實用性，即測試計劃與實際之間的接近程度和可操作性。要堅持“5W1H”的原則，明確測試內容與過程。採用評審和更新機制，確保測試計劃滿足實際需求。因為軟體專案是一個漸進的過程，中間不可避免地會發生需求變化，為滿足需求變化，測試計劃也需要及時地進行變更。測試策略要作為測試的重點進行描述。測試策略是測試計劃中的重要組成部分，測試計劃是從巨集觀上說明一個專案的測試需求、測試方法、測試人員安排等因素
27.測試用例的狀態
通過，失敗，未執行，無效，阻塞，不適用
28.常見的測試用例設計方法
等價類劃分，邊界值，錯誤推測，因果圖，場景法，正交表
應用的場景
等價類劃分
多用於輸入框：註冊/登入
邊界值（掌握上點和離點的取值）
多和等價類劃分結合使用，有邊界限制的:註冊的密碼長度，，
場景法
從基本流開始，再將基本流和備選流結合起來，可以確定用例場景 銀行取錢
正交表
用於多個下拉框之間的組合，可以通過正交助手生成測試用例
錯誤推測
錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。
一般這種方法是基於經驗和直覺推測程式中可能傳送的各種錯誤，有針對性地設計。只能作為一種補充
因果圖
因果圖法比較適合輸條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結果就是輸出
自動販賣機
29.判定表用在哪些時候/哪些功能
判定表方法是黑盒測試方法的一種，主要用於輸入和輸出比較多，功能邏輯比zhuan較複雜的情況，通過畫出判定表縷清需求中的功能邏輯，
30.什麼時候用到場景法
案例1：ATM取款
步驟1：熟悉需求，整理業務過程，列出基本流和備選流。
基本流：成功取款的流程
識別卡-->輸入正確密碼-->選“取款”功能-->選擇正確的取款金額-->點選“確定”，給出提示，出鈔，更新賬戶和ATM餘額
備選流：取款失敗的各個場景
1）識別卡失敗
2）輸入錯誤密碼：
3次以內--給出提示，重新輸入
3次--鎖卡併吞卡
3）賬戶餘額不足
4）每次取款上限5000元
5）每天取款上限20000元
6）ATM機餘額不足
步驟2：生成場景，填寫《場景表》
步驟3：根據場景，設計測試用例。
說明：場景和用例不一定是1:1的比例
有可能1個場景需要多條用例
也有可能1條用例能測試多個場景
31.測試環境怎麼搭建的？
測試環境=軟體+硬體+網路+資料準備+測試工具
32.偶然性問題的處理
一、一定要提交!!
1. 記得有這麼個缺陷，以後再遇到的時候可能就會了解發生的原因。
2. 盡力去查詢出錯的原因，比如有什麼特別的操作，或者一些操作環境等。
3. 程式設計師對程式比測試人員熟悉的多，也許你提交了，即使無法重新，程式設計師也會了解問題所在。
4. 無法重現的問題再次出現後，可以直接叫程式設計師來看看問題。
5. 對於測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程式設計師那裡，既然測試人員犯錯誤，使用者也可能會犯同樣的錯誤。錯誤發生的時候，Tester最大。
二、程式不是測試人員寫的，出問題也不是測試人員的原因。
至於無法重現，可能的原因很多，因為測試人員看到的只是程式的外部，無法深入程式內部，所以把責任推給測試人員是不對的。
測試人員的任務只是盡力重現問題，而不是必須重現!!
三、下次再遇到的時候，拉他們來看就可以了。
因為問題如果無論如何無法重現，程式設計師確實也沒有什麼好的解決方法。
而且此類問題即使程式設計師說修改了，測試員也沒有好的方法去驗證是不是。 : )
四、你可以告訴程式設計師，測試過程是沒有錯誤的。
測試人員只是檢查程式中可能存在的問題，雖然測試人員使用一定的手段方法努力去覆蓋所有的情況，但這些都是理論的推測。在實際中，可能因為人員、環境、配置等種種原因出現各種各樣的問題，在測試人員這裡發現問題是公司內部的事情，程式發到外面可就是公司的形象問題了。
需要讓程式設計師理解，測試人員是幫助他們的，不是害他們的。
客戶那裡發現問題比測試員發現問題結果要嚴重的多。
五、測試部門是獨立與開發部門的呀，真的打交道，也是經理對經理。
在我們這裡，工作上面的事情，和程式設計師相互只能商議解決，並沒有誰高誰低。
問題無法重現，也要提出，程式設計師那裡可以回覆無法再現。問題放在那裡，等到再次出現的時候，就立刻叫程式設計師過來檢視。
實在沒有再次出現，最後可以寫到報告中，說出現了什麼現象，但無法再現(比較嚴重的問題才如此處理，小問題經理之間商量商量可能就算了)。
至於測試人員必須重現bug，你殺了我好了，我每次測試專案都有無法重現的問題，很多我能找到大概的原因，有些根本無法重現(僅僅出現一次)。
這種事情是無法避免的，並不能說測試人員無法重現問題，就是工作不到位(哼，程式有bug，是否可以說程式設計師工作不到位的呀)。
六、測試部門要獨立，最好不受開發的制約。其實真正要重視，就應該有否決的權利。
我們公司就是專案承包，要拿最後的專案尾款，就要測試部簽字通過，這樣就避免了很多的問題。
其實只要自己盡到心就可以了，管別人怎麼說呢。
七、我們使用的狀態有：
程式設計師處理的狀態(由測試員提交的Action)：等待處理的，再次出現的。
測試員處理的狀態(由程式設計師提交的Action)：已經修改的，暫不修改的，系統限制的，使用錯誤的，無法再現的。測試員可以修改記錄。
經理處理的狀態(由測試員提交Action)：管理員處理的。經理還可以刪除記錄。
按照比較標準的說法，其實對於缺陷還應該有“等待確認的”、“已經確認的”和“重複提交的”的狀態，我們為了省事，統一使用了“等待處理的”。
最後結項的時候，缺陷的狀態對我們來說有兩種，“已經關閉的”(由測試員或經理確認)和“暫不修改的”(比如下一個版本處理等)。
呵呵，狀態多，有些煩瑣，特別是程式設計師很多的時候都不清楚應該回復什麼狀態，但我個人覺得對測試人員來說，這些狀態比較清晰明瞭，容易處理。
八、一個叫doer_ljy(可戰)的網友回覆了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰)的內容：
關於“無法重現”我看是有這麼個問題存在。
33.當我們認為某個地方是bug，但開發認為不是bug，怎麼處理？
1.首先我會從自身去經過多次的測試發現BUG出現的次數和頻率 記錄復現BUG的方式 然後傳送給開發人員
2.再根據需求文件來確認是否為BUG
3.如果開發不認為是BUG的將復現BUG的記錄和需求文件找產品經理和專案經理來確定是否BUG
4.如果專案經理和產品經理都不認為是BUG 我會將BUG記錄在測試文件中 方便在下次評審會上將問題再次丟擲
34.產品在上線後使用者發現bug，這時測試人員應做哪些工作？
首先要做的是重現這個問題並反饋給研發人員，儘快出patch或者解決方案。
當BUG解決且上線沒有問題之後，我們再看後續的處理。
追查原因及處理方法：這個BUG出現的原因是什麼。這有分為幾種情況：
1）測試環境無法重現：可能是線上的環境造成的BUG或者是測試環境無法模擬的情況。
解決方法：儘量完善測試方法、儘量模擬測試環境、增加線上測試。
2）漏測：
a.測試用例裁剪過度：錯誤預估優先順序或者時間過於緊迫裁剪了用例
解決方法：在後續版本或者其他專案啟動時重新評估測試時間，要求專家介入對優先順序進行評估，避免此類事件再次發生。
b.測試用例執行期間遺漏：由於測試人員疏忽造成測試用例執行遺漏。
解決方法：調查該名測試人員的整個測試過程的工作情況，並隨機抽測其他模組，對該名測試人員進行綜合評估，給出結論，是因為偷懶漏測，還是因為負責模組過多漏測，還是有其他原因，對該名測試人員發出警告，對相關測試主管，專案經理，產品經理髮出警告。
c.測試用例覆蓋不全：由於用例評審的不嚴格造成的；中途需求變更造成的；由於某些其他因素造成的。
35.二八定理
80%的缺陷出現在20%的程式碼中；80%的BUG發現在20%的時間中；80%的花費在20%的錯誤程式碼上。
36.如何跟蹤缺陷
1.過程描述
測試人員按照測試用例依次進行，並針對缺陷整個生命週期進行跟蹤
2.角色的定義
測試人員:負責具體測試執行及跟蹤人員
測試組長:負責測試執行機跟蹤包括bug單的一次審閱
專案經理:對測試人員的bug進行稽核及分配
開發人員:對分配到個人的bug進行解決
3.狀態的定義
新建，確認，解決，重新驗證，關閉，重新開啟
37.缺陷的狀態
一個Bug由測試人員發現並提交,我們將狀態標註為新建;開發人員接收了該
Bug,將Bug的狀態修改為已分配(Assigned),表示已經認可;開發人員解決了該
Bug後,就將Bug的狀態修改為解決,併發給測試人員迴歸測試;測試人員對Bug
進行迴歸測試，如果確實已經解決,就將Bug的狀態修改為關閉,否則的話則發給
開發人員重新修改。還要說明的是,Bug是可以“死而復生”的,以前版本已經關閉
的Bug,如果新版本中重新出現,我們就需要將其狀態修改為重新開啟。
38.缺陷的等級
1.輕微缺陷
輕微缺陷是指對產品外觀和下道工序可能會有輕微影響的缺陷
2.一般缺陷
一般缺陷是指不影響產品的運轉和執行、不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷
3.嚴重缺陷
嚴重缺陷是指可以引起易於糾正的異常情況、可能引起易於修復的故障或對產品外觀造成難以接受的缺陷。
4.致命缺陷
致命缺陷是指會造成安全問題的各類缺陷
39.缺陷單應該包含這些要素
所屬產品，所屬模組，當前指派（重要），bug型別，作業系統，重現步驟(重要)，驗證程度(重要),優先順序(重要)，附件等
40.測試報告的主要內容
測試目標，測試的範圍，測試環境，測試結果分析(多少輪測試，測試多少，失敗多少，成功佔比)，遺留缺陷，測試結論（本次測試涉及xxx個功能點，發現xx個缺陷，其中，xx個已修復，xx個遺留。）測試過程完整有效，系統測試通過
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的修復：
1、 開發與測試對bug的定義理解不一致產生的問題，例如暴力操作、非常規操作出現的問題、問題路徑深、伺服器返回的資料不規範、競品同樣有的問題、個別機型問題等情況，開發可能會不願意修改。
2、 工作流程方面的原因，例如開發有更高優先順序的任務沒有時間修改、上線時間緊急，來不及修改、開發不關注名下的bug、開發認為目前的實現比產品需求好等情況
3、 當然還有個人能力原因，例如找不到好的解決方案、影響範圍大、找不到bug原因，沒有解決方案、技術實現難，不知道怎麼修改等等原因
4、 另外還有一些不可抗力的客觀因素，例如系統問題，第三方應用問題等等
43.軟體測試流程
1.需求分析
2.制訂測試用例
3.評審測試用例
4.執行測試
5.提交Bug並推動Bug解決
6.迴歸測試
7.編寫並提交測試報告
44.專案介紹
45.對一支圓珠筆進行測試，要從哪些方面進行測試？三角形測試用例設計
1.功能測試：
圓珠筆按下是否能正常書寫。
2.效能測試：
筆芯彈出彈回的快慢。
3.負載測試：
連續按，看彈簧能經受多少次伸縮。
4.相容性測試：
看是否可以使用其他筆芯。
5.強度測試：
用力過度會有什麼影響
6.可恢復性測試：
長時間按住彈簧，鬆開後看彈簧是否可以恢復
7.介面測試：
筆的外觀，舒適度
8.安全性測試：
是否會對使用者造成傷害
三角形
46.在專案中發現哪些經典bug？什麼原因導致的？
47.一個專案完成時，有多個重要的缺陷沒有被修復，但是專案負責人說可以不修改，你認為測試是不通過的，請簡述你的理由。
48.在需求文件不太詳細的情況下，如何開展測試？
1. 解決使用者問題或達到使用者目標需要具備的條件或能力
2. 遵守合同、協議、規範或其他要求
49.如何儘快找到軟體中的bug?
1.儘快熟悉軟體的需求和業務，只有熟悉了產品的業務流程、你才能迅速找出軟體中存在的一些重要的缺陷
2.把自己當成使用者，把自己當成是使用者去使用該系統，比如在使用該系統過程中是這樣操作的嗎？
3.善於懷疑，不要開發人員的能力
4.不要讓程式開發人員的觀點：“使用者不會進行這樣的操作”而說服自己
5.使用完整的流程去測試軟體系統，有些子流程在單獨測試時沒有問題，但按流程走的時候問題就可能出來了。
50.什麼是bug？
和預期不一致的軟體行為。
一個軟體行為既可能是bug也可能不是bug，那是因為預期的主體千姿百態。
和測試員預期不一致的軟體行為。
和程式設計師預期不一致的軟體行為。
和文件預期不一致的軟體行為。
和管理者預期不一致的軟體行為。
和客戶預期不一致的軟體行為
51.ATM機吞卡的吞卡現象是不是BUG?
不是
是特意設定的安全措施
防止有人馬虎，操作後忘記取走銀行卡而被人冒領卡中的錢款
所以特意設定了倒數計時，限時內沒有取走銀行卡就會吞卡
52.如何減少非問題單的提交？
53.有個程式，在windows上執行很慢，怎麼判斷是程式存在問題，還是軟硬體系統存在問題？
1、檢查系統是否有中度的特徵，如：瀏覽器視窗連續開啟，系統中檔案圖示改成統一圖示，CPU使用率儲存90%以上等
2、檢查軟體/硬體的配置是否符合軟體的推薦標準
3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務，如：虛擬機器執行
4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對CPU/記憶體的訪問情況，
54.你們發現bug會怎麼處理。