軟體測試工程師筆試題帶答案
軟體測試工程師筆試題帶答案
軟體測試題目
一、 判斷題 (每題2分，20)
1、軟體測試就是為了驗證軟體功能實現的是否正確，是否完成既定目標的活動，所以軟體測試在軟體工程的後期才開始具體的工作。 （初級） （ × ）
2、發現錯誤多的模組，殘留在模組中的錯誤也多。( √ ) （初級）
3、測試人員在測試過程中發現一處問題，如果問題影響不大，而自己又可以修改，應立即將此問題正確修改，以加快、提高開發的程序。（ × ）（初級）
4、單元測試通常應該先進行“人工走查”，再以白盒法為主，輔以黑盒法進行動態測試。
（ √ ）（中級）
5、功能測試是系統測試的主要內容，檢查系統的功能、效能是否與需求規格說明相同。（ √ ）（中級）
6、軟體質量管理即QM由QA和QC構成，軟體測試屬於QC的核心工作內容。（√）（高階）
7、軟體測試只能發現錯誤，但不能保證測試後的軟體沒有錯誤。(√)
8、軟體就是程式。(X)
9、測試只要做到語句覆蓋和分支覆蓋，就可以發現程式中的所有錯誤。(X)
10、I18N測試是指對產品做出具有國際性的規劃，而L10N測試則是指對軟體做出符合本地需求更改工作。（√）【高階】
二、 選擇題 (每題2分 20 )
1、 進行軟體質量管理的重要性有：（ABCD）【中級】
A、維護降低成本 B、法律上的要求 C、市場競爭的需要
D、質量標準化的趨勢 E、軟體工程的需要 F、CMM過程的一部分
G、方便與客戶進一步溝通為後期的實施打好基礎
2、以測試的形態分測試可以分為：（ABC）【中級】
A、建構性測試 B、系統測試 C、專項測試
D、單元測試 E、元件測試 F、整合測試
3、選出屬於黑盒測試方法的選項（ABC）【初級】
A、測試用例覆蓋 B、輸入覆蓋 C、輸出覆蓋
D、分支覆蓋 E、語句覆蓋 F、條件覆蓋
4、編寫測試計劃的目的是：（ABC）【中級】
A、使測試工作順利進行 B、使專案參與人員溝通更舒暢 C、使測試工作更加系統化
D、軟體工程以及軟體過程的需要 E、軟體過程規範化的要求 F、控制軟體質量
5、依存關係有4種分別是：（ABCD）【高階】
A、開始－結束 B、開始－開始 C、結束－開始
D、結束－結束 E、開始－實施－結束 F、結束－稽核－開始
6、軟體質量管理（QM）應有質量保證（QA）和質量控制（QC）組成，下面的選項屬於QC得是：（ABC）【高階】
A、測試 B、跟蹤 C、監督
D、制定計劃 E、需求審查 F、程式程式碼審查
7、實施缺陷跟蹤的目的是：（ABCD）【中級】
A、軟體質量無法控制 B、問題無法量化 C、重複問題接連產生
D、解決問題的知識無法保留 E、確保缺陷得到解決 F、使問題形成完整的閉環處理
8、使用軟體測試工具的目的：（ABC）【中級】
A、幫助測試尋找問題 B、協助問題的診斷 C、節省測試時間
D、提高Bug的發現率 E、更好的控制缺陷提高軟體質量 F、更好的協助開發人員
9、典型的瀑布模型的四個階段是：（ABCD）【高階】
A、分析 B、設計 C、編碼
D、測試 E、需求調研 F、實施
10、PSP是指個人軟體過程 ，是一種可用於（ A ）、（ B ）和（ C ）個人軟體工作方式的自我改善過程。【高階】
A、控制 B、管理 C、改進
D、高效 E、充分 F、適宜
三、 問答題
1、 測試人員在軟體開發過程中的任務是什麼？（初級）(5分)
答：1、尋找Bug；
2、避免軟體開發過程中的缺陷；
3、衡量軟體的品質；
4、關注使用者的需求。
總的目標是：確保軟體的質量。
2、 在您以往的工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？（初級）(6分)
答：一條Bug記錄最基本應包含：編號、Bug所屬模組、Bug描述、Bug級別、發現日期、發現人、修改日期、修改人、修改方法、迴歸結果等等；要有效的發現Bug需參考需求以及詳細設計等前期文件設計出高效的測試用例，然後嚴格執行測試用例，對發現的問題要充分確認肯定，然後再向外發布如此才能提高提交Bug的質量。
3、 介面測試題及設計題。請找出下面介面中所存在的問題並分別列出；用黑盒測試的任何一種方法設計出此登陸窗體的測試用例。（中級）(6分)
答：1、窗體的標題欄中為空，沒有給出標題。
2、使用者名稱和密碼控制元件的字型不一致並且沒有對齊。
3、文字框的大小不一致沒有對其。
4、確定和取消按鈕控制元件的大小不一致。
4、 黑盒測試和白盒測試是軟體測試的兩種基本方法，請分別說明各自的優點和缺點！（中級）(5分)
答：黑盒測試的優點有：
1）比較簡單，不需要了解程式內部的程式碼及實現；
2）與軟體的內部實現無關；
3）從使用者角度出發，能很容易的知道使用者會用到哪些功能，會遇到哪些問題；
4）基於軟體開發文件，所以也能知道軟體實現了文件中的哪些功能；
5）在做軟體自動化測試時較為方便。
黑盒測試的缺點有：
1）不可能覆蓋所有的程式碼，覆蓋率較低，大概只能達到總程式碼量的30%；
2）自動化測試的複用性較低。
白盒測試的優點有：
幫助軟體測試人員增大程式碼的覆蓋率，提高程式碼的質量，發現程式碼中隱藏的問題。
白盒測試的缺點有：
1）程式執行會有很多不同的路徑，不可能測試所有的執行路徑；
2）測試基於程式碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
3）系統龐大時，測試開銷會非常大。
5、 根據自己的理解回答什麼是軟體測試，軟體測試分為哪幾個階段。（初級）(5分)
答：軟體測試是一個為了尋找軟體中的錯誤而執行軟體的過程，一個成功的測試是指找到了迄今為止尚未發現的錯誤的測試。
軟體測試一般分為單元測試、整合測試和系統測試。
6、 根據自己的理解什麼是測試用例和測試規程，設計一個測試用例應當從哪幾方面考慮？（中級）(10分)
答：狹義的講，一個測試用例就是測試人員用以測試被測軟體的某個特性或特性組合的一組資料。這組資料可能是從使用者處得來的實際的一組資料，也可能是測試人員專門設計出來的測試軟體某些功能的一組資料。
測試規程就是詳細的對測試用例設計方法、測試方法、測試工具、測試環境和測試資料進行描述的文件，還可以包括能把某個或某一組測試用例應用到被測軟體上完成某項測試的一系列的操作步驟。
設計測試用例應當從以下幾方面考慮：邊界值，等價類劃分，有效/無效值等。
7、 什麼是軟體質量保證？軟體質量保證人員與開發人員的關係如何？（高階） (10分)
答：軟體質量保證就是通過確保軟體過程的質量，來保證軟體產品的質量。
軟體質量保證人員和開發人員之間具有管理上的嚴格的獨立性，兩個小組的管理員都不能越權管理另一組，但都可以向更高層的管理者彙報軟體開發中的問題
軟體測試筆試題
一、選擇題
1、對計算機軟體和硬體資源進行管理和控制的軟體是（D）
A.檔案管理程式
B.輸入輸出管理程式
C.命令出來程式
D.作業系統
2、在沒有需求文件和產品說明書的情況下只有哪一種測試方法可以進行的（A）
A.錯誤推測法測試
B.路勁分析測試
C.語句覆蓋測試
D.條件覆蓋測試
3、某測試人員通過執行測試軟體測試的方法對當前功能進行了測試，該測試人員使用的測試方法為（C）
A.靜態測試
B.單元測試
C.黑盒測試
4、編寫測試計劃的目的是（ABC）多選題
A.使測試工作順利進行
B.使專案參與人員溝通更舒暢
C.使測試工作更加系統化
D.軟體工程以及軟體過程的需要
E.軟體過程規範化的要求
F.控制軟體質量
5、關於軟體測試與軟體開發的認識，不正確的是（B）
A.軟體生命週期各個階段都可能產生測試
B.軟體測試是獨立於軟體開發的一個工作
C.軟體開發的需求分析和設計階段就應開始測試工作
D.測試越早進行，越有助於提高被測軟體的質量
6、當一個應用程式視窗被最小化後該應用的程式將會出現一下哪種情況（D）
A.被終止執行
B.繼續在前臺執行
C.被暫停執行
D.被轉入後臺執行
7、下列方法中，不屬於黑盒測試的是？（A）
A.基本路勁測試法
B.等價類測試法
C.邊界值分析法
D.基於場景的測試方法
8、對於維護軟體的人員來說，使用質量是【】的結果（C）
A.功能性
B.可靠性
C.可維護性
D.效率
9、下列軟體屬性中，軟體產品首要滿足的應該是（A）
A.功能需求
B.效能需求
C.可擴充套件性和靈活性
D.容錯、糾錯能力
10、單元測試中設計測試用例的依據是（D）
A.概要設計規格說明書
B.使用者需求規格說明書
C.專案計劃說明書
D.詳細設計規格說明書
二、判斷題
1、單元測試通常應該先進行“人工走查”，再以白盒法為主，輔以黑盒法進行動態測試。（√）
2、軟體測試就是為了驗證軟體功能實現的是否正確，是否完成既定目標的活動，所以軟體測試在軟體工程的後期才開始具體的工作（ × ）
3、發現錯誤多的模組，殘留在模組中的錯誤也多。( √ )
4、測試人員在測試過程中發現一處問題，如果問題影響不大，而自己又可以修改，應立即將此問題正確修改，以加快、提高開發的程序。（ × ）
5、單元測試通常應該先進行“人工走查”，再以白盒法為主，輔以黑盒法進行動態測試。（ √ ）
6、功能測試是系統測試的主要內容，檢查系統的功能、效能是否與需求規格說明相同。（ √ ）
7、軟體質量管理即QM由QA和QC構成，軟體測試屬於QC的核心工作內容。（√）
8、軟體測試只能發現錯誤，但不能保證測試後的軟體沒有錯誤。(√)
9、軟體就是程式。(X)
10、測試只要做到語句覆蓋和分支覆蓋，就可以發現程式中的所有錯誤。(X)
三、問答題
1、在您以往的工作中，一條軟體缺陷（或者叫BUG）記錄都包含了哪些內容？如果提交高質量的軟體缺陷（bug）記錄？
答：一條BUG記錄最基本應包含：編號、BU所屬模組、BUG描述、BUG級別、發現日期、發現人、修改日期、修改人、修改方法、迴歸結果等等；要有效的發現bUG需要參加需求以及詳細的設計等前期文件設計出高效的測試用例，然後嚴格執行測試用例，對發現的問題要充分確認肯定，然後再向外發布，這樣才能提高提交BUG的質量。
2、測試分為那幾個階段？
答：按照開發階段劃分，軟體測試可分為單元測試、整合測試、系統測試和驗收測試
整合測試：針對每個單元的測試，以確保每個模組能正常工作為目標
整合測試：對已經測試過的模組進行組裝，進行整合測試。目的就是在於檢驗與軟體設計相關的程式結構問題。
系統測試：檢驗軟體產品能夠與系統的其他部分（比如：硬體、資料庫及操作人員）協調工作。
驗收測試：檢驗軟體產品質量的最後一道工序，主要突出使用者的作用，同時軟體開發人員也有一定程度的參與。
3、瞭解哪些測試工具？你是用過和知道的測試工具有哪些？各有什麼用途？
答：Jmeter：介面測試、壓力測試
soapui：介面測試
xshell、xftp：管理linux系統
禪道：管理BUG
navictt：管理資料庫
4、先有一個程式，頁面提供3個輸入框a、b、c，一個輸出框d，根據a、b、c的輸入判斷資料層是否只能組成一個三角形（三角形兩邊之和大於第三邊），在d中輸出：是，否
答：等價類劃分法：
有效等價類：a、b、c的值都大於0
a+b>c且b+c>a且a+c>b
無效等價類：
a/b/c為0或負數
a/b/c為空
a/b/c為非數字
a+b<=c b+c<=a a+b<=b
5、你認為一個測試工程師應具備哪些素質和技能
答：技能：計算機專業技能，測試專業技能，軟體程式設計技能
素質：.溝通能力，要有嚴謹、敢於承擔責任、穩重的做事風格，具有懷疑與破壞的精神，善於自我總結、自我督促。
6、問題單都有哪些屬性？
答：我所知道的有：產品模組、所屬專案、所屬版本、bug標題、步驟及測試資料、bug及日誌截圖、型別及嚴重程度、系統/瀏覽器
7、一個完整的測試方案包含哪些要素？
答：測試計劃、人員分配、時間安排、測試方法的確定、測試工具的確定、測試報告
8、檢視介面的工具有哪些？說出一個工具的操作
答：jmeter與soapui都支援
jmeter的用法：新建一個執行緒組，天劍http型別的請求→填上介面地址和資料→新增檢視結果樹→進行執行→檢視結果、進行分析
9、如何定位BUG，是前端還是後端的問題，用什麼工具，還是利用別的？
答：如果是功能性的問題，那麼就是後端問題，如果是介面的效果或者是按鈕問題，那麼也許是前端問題，分析問題，有的時候需要開發的協作，大師這些也是經驗的問題，多工作就可以總結出來
軟體測試筆試題
1、HTTP協議有什麼特點？有哪幾類狀態碼，分別表示什麼意思？
1.特點:
無連線：限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。
媒體獨立：只要客戶端和伺服器知道如何處理的資料內容，任何型別的資料都可以通過HTTP傳送。
無狀態：無狀態是指協議對於事務處理沒有記憶能力。
各個狀態碼的含義：1xx：請求成功繼續處理 2xx：請求傳送成功 3xx：重定向 4xx:客戶端錯誤，請求有誤無法實現 5xx:服務端錯誤：未能實現合法請求
2.簡述cookies和session是怎麼工作的？
cookis：傳送HTTP請求時請求頭加上特殊的指示提示瀏覽器生成指示對應的cookis
session：是一種服務端的機制，類似於用散列表的形式儲存資訊
4.用你熟悉的一種程式語言，寫出計算以下結果的程式碼。1+2+3+…+100=？
j=0 for i int range(1,101) j = j+i print("計算的結果為 d%" j%)
5.建立一個UC表，欄位如下：FID(INT)/NAME(VARCHAR)姓名/EMAIL(VARCHAR)郵件/FBAL(decimal(20,2))/金額
CREATE TABLE UC(
FID INT PRIMARY KEY AUTO_INCREMENT NOT NULL COMMENT '主鍵ID',
NAME VARCHAR(10) NOT NULL COMMENT'使用者名稱稱',
EMAIL VARCHAR(10) NOT NULL COMMENT'使用者郵箱',
FBAL DECIMAL(20,2) NOT NULL COMMENT '使用者金額'
)
a.增加資料
INSERT INTO UC(NAME,EMAIL,FBAL) VALUES('黃斌','[email protected]','550')
INSERT INTO UC(NAME,EMAIL,FBAL) VALUES('李毅','[email protected]','250')
INSERT INTO UC(NAME,EMAIL,FBAL) VALUES('張梭','[email protected]','250')
INSERT INTO UC(NAME,EMAIL,FBAL) VALUES('李冰','[email protected]','450')
B.查詢使用者金額不小於300的使用者名稱稱?
SELECT NAME FROM UC WHERE FBAL <= 300
一、什麼是靜態測試？動態測試？
二、什麼是迴歸測試？
三、如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎（黑盒和白盒的區別？）
四、軟體測試分幾個階段？各階段重點測試什麼？各個階段的含義？
五、針對缺陷採取怎樣的管理措施？
六、軟體測試的V模型和W模型
七、測試方法可以分為哪幾種？
八、白盒測試之六種覆蓋
九、其他問題記錄
一、什麼是靜態測試？動態測試？
通過執行程式測試軟體：動態測試(有白盒和黑盒，從不同角度設計測試用例)
通過評審文件、閱讀程式碼：靜態測試
靜態測試方法是指不執行被測程式本身，僅通過分析或檢查原始碼的語法、結構、介面等來檢查程式的正確性。對照需求規格說明書，軟體設計說明書，源程式做結構分析，流程圖分析。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，如不匹配的引數，不合適的巢狀迴圈和分支巢狀，不允許的遞迴，未使用過的變數、空指標的引用和可疑的計算。用於進一步的差錯，併為測試用例選取提供指導。
二、什麼是迴歸測試？
目的是程式有修改的情況下，保證原有功能正常的一種測試策略和方法。
測試人員在程式進行測試時發現bug，然後返回程式設計師修改，程式設計師修改後釋出新的軟體包或軟體補丁包給測試人員，重新測試，保證程式修正了以前bug的情況下，正常執行且不會帶來新的錯誤的過程，一般不需要全面測試，根據修改情況進行有效的測試。
三、如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎（黑盒和白盒的區別？）
任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或資料驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能?
2、在介面上，輸入是否能正確的接受?能否輸出正確的結果?
3、是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤?
4、效能上是否能夠滿足要求?
5、是否有初始化或終止性錯誤?
軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如下檢查：
1、對程式模組的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在迴圈的邊界和執行的界限內執行迴圈體。
4、測試內部資料結構的有效性，等等。
以上事實說明，軟體測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程式只能進行少量(相對於窮舉的巨大數量而言)的有限的測試，在未發現錯誤時，不能說明程式中沒有錯誤。
就算執行了完美的黑盒測試也是無法測試程式內部特定部位，另外當規格說明本身有誤，也不能發現問題。而白盒測試能對程式的內部特定部位進行覆蓋測試，所以黑盒和白盒測試互為互補關係，結合起來進行測試用例的設計更為合理。
經驗表明，通常在進行單元測試時採用白盒測試方法，整合測試使用灰盒測試，系統測試使用黑盒測試。
四、軟體測試分幾個階段？各階段重點測試什麼？各個階段的含義？
開發的5個階段：單元測試、整合測試、確認測試、系統測試、驗收測試。(迴歸測試)（軟體釋出後）。
每階段都有5個步驟：==測試計劃、測試設計、用例設計、執行結果、測試報告 ==
1.單元測試是對軟體中的基本組成單元進行測試，如一個模組、一個過程等等，它是軟體動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟體最基本組成單元的正確性。
2.整合測試在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。其主要目的是檢驗軟體各單位之間的介面是否正確。實踐表明，一些模組雖然可以單獨工作，但並不能保證連線起來也能正常工作。程式在某些區域性反映不出來的問題，在全域性上可能暴露。測試重點是模組間的銜接以及引數的傳遞等。
3.確認測試確認測試的目標是驗證軟體的功能和效能以及其他特性是否與使用者的要求一致。確認測試一般包括有效性測試和軟體配置複查。一般由第三方測試機構進行。
3.系統測試是對已經整合好的軟體系統進行徹底的測試，已驗證軟體系統的正確性和效能等滿足其規約所指定的要求，檢查軟體的行為和輸出是否正確。重點：整個系統的執行以及與其他軟體的相容性。
4.驗收測試旨在向軟體的購買者展示該軟體滿足其使用者的需求。它的測試資料通常是系統測試的測試資料的子集。
5.迴歸測試是在軟體的維護階段，對軟體進行修改之後進行的測試，其目的是檢驗對軟體的修改是否正確。
五、針對缺陷採取怎樣的管理措施？
1.要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的。
2.根據缺陷的生命週期，考慮缺陷提交的管理，缺陷狀態的管理和缺陷分析的管理。
3.所有發現的缺陷必須全部即時的，準確的提交到缺陷管理工具中，這就是缺陷提交的管理。
4.缺陷提交後，需要即時的指派給相應的開發人員，提交缺陷的人需要密切注意缺陷的狀態，幫助缺陷的儘快解決，缺陷解決後需要即時對缺陷的修復進行驗證。目的有2個：1.讓缺陷儘快解決2.方便後面缺陷的分析
5.為了更好的改進開發計劃和測試過程，需要對缺陷進行分析，總結如缺陷的型別，缺陷的齡期分佈等資訊。
六、軟體測試的V模型和W模型
七、測試方法可以分為哪幾種？
軟體測試可以是人工測試：如個人複查，抽查和會審等
也可以是機器自動測試，又有不同的分類：
按照否關軟體內部結構具體實現角度劃
==A.白盒測試B.黑盒測試 C.灰盒測試 ==
按照軟體發程按階段劃
A.單元測試 B.集測試 C.確認測試 D.系統測試 E.驗收測試
八、白盒測試之六種覆蓋
1.語句覆蓋：可執行語句至少被執行一次；
2.判斷覆蓋：每個判斷的取真分支和取假分支至少經歷一次；
3.條件覆蓋：每個條件的取值至少滿足一次；
4.判斷條件覆蓋：判斷和條件都滿足；
5.條件組合覆蓋：每個條件的所有可能都至少出現一次，並且判定結果至少出現一次 ；
他與條件覆蓋的區別：他不是簡單要求每個條件出現“真”和“假”兩種結果，而是要求這些結果所有可能至少出現一次；
6.路徑測試：執行所有可能的執行路徑；
7.基本路徑測試：
路徑測試執行了每個路徑，每個判定的結果肯定經歷過一次
6種覆蓋標準，強度由弱到強依次是：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋
常用的黑盒測試方法：等價類劃分法、邊界值分析法、正交實驗設計法、因果圖法、決策表法。
等值分析測試=等價類劃分+邊界值分析測試
邊界值法既是白盒又是黑盒測試方法
因果圖法：等價類劃分法和邊界值分析方法都是著重考慮輸入條件，如果程式輸入之間沒有什麼聯絡，採用等價類劃分和邊界值分析是一種比較有效的方法。如果輸入之間有關係，例如，約束關係、組合關係，這種關係用等價類劃分和邊界值分析是很難描述的，測試效果難以保障，因此必須考慮使用一種適合於描述對於多種條件的組合，產生多個相應動作的測試方法，因果圖正是在此背景下提出的。因果圖法著重測試規格說明中的輸入與輸出間的依賴關係。
因果圖法測試用例的設計步驟：
（1）確定軟體規格(需求)中的原因和結果
（2）確定原因和結果之間的邏輯關係
（3）確定因果圖中的各個約束(constraints)
（4）畫出因果圖並轉換為決策表
（5）根據決策表設計測試用例
軟體測試面試題100道整理
1.什麼是軟體測試？
答：軟體測試是為了發現錯誤而執行程式的過程。
2.軟體測試的目的?
答;測試的目的是想以最少的人力、物力和時間找出軟體中潛在的各種錯誤和缺陷，通過修正錯誤和缺陷提高軟體質量，迴避軟體釋出後由於潛在的軟體缺陷和錯誤造成的隱患帶來的商業風險。
3.什麼是需求文件測試？
答：主要測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現;
4.什麼是設計文件測試?
答:測試設計是否符合全部需求以及設計是否合理。
5.什麼是α測試?
答:Alpha測試(α測試)是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由程式設計師或測試員完成。Alpha測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評價軟體產品的功能、可使用性、可靠性、效能和支援。尤其注重產品的介面和特色。Alpha測試可以從軟體產品編碼結束之後開始，或在模組(子系統)測試完成後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。有關的手冊(草稿)等應該在Alpha測試前準備好。
6.什麼是β測試?
答：Beta測試(β測試)是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。因而，Beta測試是在開發者無法控制的環境下進行的軟體現場應用。在Beta測試中，由使用者記下遇到的所有問題，包括真實的以及主管認定的，定期向開發者報告，開發者在綜合使用者的報告後，做出修改，最後將軟體產品交付給全體使用者使用。Beta測試著重於產品的支援性，包括文件、客戶培訓和支援產品的生產能力。只有當Alpha測試達到一定的可靠程度後，才能開始Beta測試。由於Beta測試的主要目標是測試可支援性，所以Beta測試應該儘可能由主持產品發行的人員來管理。
7.什麼是驅動模組？
答:驅動模組在大多數場合稱為"主程式"，它接收測試資料並將這些資料傳遞到被測試模組.單元測試一個函式單元時，被測單元本身是不能獨立執行的，需要為其傳送資料，為此寫驅動
驅動模組主要完成以下事情：
1、接受測試輸入;
2、對輸入進行判斷;
3、將輸入傳給被測單元，驅動被測單元執行;
4、接受被測單元執行結果，並對結果進行判斷;
5、將判斷結果作為用例執行結果輸出測試報告。
8.什麼是樁模組?
答:比如對函式A做單元測試時，被測的函式單元下還包括了一個函式B，為了更好的錯誤，定位錯誤，就要為函式B寫樁，來模擬函式B的功能，保證其正確。
9.什麼是白盒測試?
答:白盒測試(White-box Testing，又稱邏輯驅動測試,結構測試),它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。
對開發語言的支援：白盒測試工具是對原始碼進行的測試，測試的主要內容包括詞法分析與語法分析、靜態錯誤分析、動態檢測等。目前測試工具主要支援的開發語言包括：標準C、C++、Visual C++、Java、Visual J++等。
10.什麼是靜態測試?
答:通過執行程式測試軟體稱為動態測試.通過評審文件、閱讀程式碼等方式測試軟體稱為靜態測試,在動態測試中,通常使用白盒測試和黑盒測試從不同的角度設計測試用例,查詢軟體程式碼中的錯誤.
靜態測試方法是指不執行被測程式本身，僅通過分析或檢查源程式的語法、結構、過程、介面等來檢查程式的正確性。對需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，例如不匹配的引數、不適當的迴圈巢狀和分支巢狀、不允許的遞迴、未使用過的變數、空指標的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，併為測試用例選取提供指導。
11.什麼是迴歸測試?
答:迴歸測試的目的是在程式有修改的情況下，保證原有功能正常的一種測試策略和方法。
說白了就是，我們測試人員在對程式進行測試時發現bug，然後返還程式設計師修改，程式設計師修改後釋出新的軟體包或新的軟體補丁包給我們測試人員，我們就要重新對這個程式測試，已保證程式在修正了以前bug的情況下，正常執行，且不會帶來新的錯誤的這樣一個過程。 一般情況下是不需要全面測試的，而是根據修改的情況進行有效的測試。
12.白盒測試有哪幾種方法?
答:白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。“白盒”法全面瞭解程式內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。
13.軟體的缺陷等級應如何劃分?
軟體缺陷的等級可以用嚴重性和優先順序來描述；
嚴重性：衡量缺陷對客戶滿意度影響的滿意程度，分為
1,致命錯誤，可能導致本模組以及其他相關的模組異常，宕機等問題；
2.嚴重錯誤，問題侷限在本模組，導致模組功能失常或異常退出；
3.一般錯誤，模組功能部分失效；
4.建議模組，有問題提出人對測試模組的改進建議；
優先順序：缺陷被修復的緊急程度；
1.立即解決（P1級）：缺陷導致系統功能幾乎不能使用或者測試不能繼續，需立即修復；
2.高優先順序（P2級）：缺陷嚴重，影響測試，需優先考慮；
3.正常排隊（P3級）：缺陷需要正常排隊等待修復；
4.低優先順序（P4級）：缺陷可以在有時間的時候被糾正；
14.如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎?(白盒與黑盒的區別)
答:任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求.
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或資料驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能?
2、在介面上，輸入是否能正確的接受?能否輸出正確的結果?
3、是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤?
4、效能上是否能夠滿足要求?
5、是否有初始化或終止性錯誤?
軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子，它允許測試人員利用程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如下檢查：
1、對程式模組的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在迴圈的邊界和執行的界限內執行迴圈體。
4、測試內部資料結構的有效性，等等。
以上事實說明，軟體測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程式只能進行少量(相對於窮舉的巨大數量而言)的有限的測試，在未發現錯誤時，不能說明程式中沒有錯誤。
15.軟體測試應該劃分幾個階段?簡述各個階段應重點測試的點?各個階段的含義?
答:大體上來說可分為單元測試,整合測試,系統測試,驗收測試,每個階段又分為以下五個步驟: 測試計劃，測試設計，用例設計，執行結果，測試報告
初始測試集中在每個模組上，保證原始碼的正確性，該階段成為單元測試，主要用白盒測試方法。 接下來是模組整合和整合以便組成完整的軟體包。整合測試集中在證實和程式構成問題上。主要採用黑盒測試方法，輔之以白盒測試方法。
軟體整合後，需要完成確認和系統測試。確認測試提供軟體滿足所有功能、效能需求的最後保證。確認測試僅僅應用黑盒測試方法。
16.什麼是單元測試？
答:單元測試是對軟體中的基本組成單位進行的測試，如一個模組、一個過程等等。它是軟體動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟體基本組成單位的正確性。
17.什麼是整合測試
答:整合測試是在軟體系統整合過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。
18.系統測試？
答:系統測試是對已經整合好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和效能等滿足其規約所指定的要求，檢查軟體的行為和輸出是否正確並非一項簡單的任務，它被稱為測試的“先知者問題”。
19.驗收測試
答:驗收測試旨在向軟體的購買者展示該軟體系統滿足其使用者的需求。它的測試資料通常是系統測試的測試資料的子集.
20.迴歸測試
答:迴歸測試是在軟體維護階段，對軟體進行修改之後進行的測試。其目的是檢驗對軟體進行的修改是否正確。
21.針對缺陷採取怎樣的管理措施?
答:1. 要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的都可。
\2. 根據缺陷的生命週期，考慮缺陷提交的管理、缺陷狀態的管理和缺陷分析的管理。
\3. 所有發現的缺陷(不管是測試發現的還是走讀程式碼發現的)都必須全部即時的、準確的提交到缺陷管理工具中，這是缺陷提交的管理。
\4. 缺陷提交後，需要即時的指派給相應的開發人員，提交缺陷的人需要密切注意缺陷的狀態， 幫助缺陷的儘快解決。缺陷解決後需要即時對缺陷的修復進行驗證。這樣的目的有兩個：一個是讓缺陷儘快解決;二是方便後面缺陷的分析(保證缺陷相關的資訊準確，如齡期等)，這是缺陷狀態的管理。
\5. 為了更好的改進開發過程和測試過程，需要對缺陷進行分析，總結如缺陷的類別、缺陷的齡期分佈等資訊，這是缺陷分析的管理。
22.單元測試、整合測試、系統測試的側重點是什麼?
答:單元測試是在軟體開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試，測試重點是系統的模組，包括子程式的正確性驗證等。
整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出來，影響功能的實現。測試重點是模組間的銜接以及引數的傳遞等。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。測試重點是整個系統的執行以及與其他軟體的相容性。
23.設計用例的方法、依據有那些?
答:白盒測試用例設計有如下方法:
基本路徑測試\邊界值分析\覆蓋測試\迴圈測試\資料流測試\程式插樁測試\變異測試.
這時候依據就是詳細設計說明書及其程式碼結構
黑盒測試用例設計方法:
基於使用者需求的測試\功能圖分析方法\等價類劃分方法\邊界值分析方法\錯誤推測方法\因果圖方法\判定表驅動分析方法\正交實驗設計方法.
依據是使用者需求規格說明書,詳細設計說明書。
24.描述使用bugzilla缺陷管理工具對軟體缺陷(BUG)跟蹤的管理的流程
答:1) 測試人員或開發人員發現bug後，判斷屬於哪個模組的問題，填寫bug報告後，系統會自動通過Email通知專案組長或直接通知開發者。
2) 經驗證無誤後，修改狀態為VERIFIED.待整個產品釋出後，修改為CLOSED.
3) 還有問題，REOPENED，狀態重新變為“New"，併發郵件通知。
4) 專案組長根據具體情況，重新reassigned分配給bug所屬的開發者。
5) 若是，進行處理，resolved並給出解決方法。(可建立補丁附件及補充說明)
6) 開發者收到Email資訊後，判斷是否為自己的修改範圍。
7) 若不是，重新reassigned分配給專案組長或應該分配的開發者。
8) 測試人員查詢開發者已修改的bug，進行重新測試。
25.請你分別介紹一下單元測試、整合測試、系統測試、驗收測試、迴歸測試
答;1、單元測試：完成最小的軟體設計單元（模組）的驗證工作，目標是確保模組被正確的編碼，使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模組內的錯誤，通常情況下是白盒的，對程式碼風格和規則、程式設計和結構、業務邏輯等進行靜態測試，及早的發現和解決不易顯現的錯誤。
2、整合測試：通過測試發現與模組介面有關的問題。目標是把通過了單元測試的模組拿來，構造一個在設計中所描述的程式結構，應當避免一次性的整合（除非軟體規模很小），而採用增量整合。
自頂向下整合：模組整合的順序是首先整合主模組，然後按照控制層次結構向下進行整合，隸屬於主模組的模組按照深度優先或廣度優先的方式整合到整個結構中去。
自底向上整合：從原子模組開始來進行構造和測試，因為模組是自底向上整合的，進行時要求所有隸屬於某個給頂層次的模組總是存在的，也不再有使用穩定測試樁的必要。
3、系統測試：是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。系統測試的物件不僅僅包括需要測試的產品系統的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等。因此，必須將系統中的軟體與各種依賴的資源結合起來，在系統實際執行環境下來進行測試。
4、迴歸測試：迴歸測試是指在發生修改之後重新測試先前的測試用例以保證修改的正確性。理論上，軟體產生新版本，都需要進行迴歸測試，驗證以前發現和修復的錯誤是否在新軟體版本上再次出現。根據修復好了的缺陷再重新進行測試。迴歸測試的目的在於驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。
5、驗收測試：驗收測試是指系統開發生命週期方法論的一個階段，這時相關的使用者或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統使用者決定是否接收系統。它是一項確定產品是否能夠滿足合同或使用者所規定需求的測試。驗收測試包括Alpha測試和Beta測試。
Alpha測試：是由使用者在開發者的場所來進行的，在一個受控的環境中進行。
Beta測試：由軟體的終端使用者在一個或多個使用者場所來進行的，開發者通常不在現場，使用者記錄測試中遇到的問題並報告給開發者，開發者對系統進行最後的修改，並開始準備釋出最終的軟體。
26.請你回答一下單元測試、整合測試、系統測試、驗收測試、迴歸測試這幾步中最重要的是哪一步
答：這些測試步驟分別在軟體開發的不同階段對軟體進行測試，我認為對軟體完整功能進行測試的系統測試很重要，因為此時單元測試和整合測試已完成，能夠對軟體所有功能進行功能測試，能夠覆蓋系統所有聯合的部件，是針對整個產品系統進行的測試，能夠驗證系統是否滿足了需求規格的定義，因此我認為系統測試很重要。
27.請回答整合測試和系統測試的區別，以及它們的應用場景主要是什麼？
參考回答：
區別：
1、計劃和用例編制的先後順序：從V模型來講，在需求階段就要制定系統測試計劃和用例，HLD的時候做整合測試計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統測試計劃用例，再做整合。
2、用例的粒度：系統測試用例相對很接近使用者接受測試用例，整合測試用例比系統測試用例更詳細，而且對於介面部分要重點寫，畢竟要整合各個模組或者子系統。
3、執行測試的順序：先執行整合測試，待整合測試出的問題修復之後，再做系統測試。
應用場景：
整合測試：完成單元測試後，各模組聯調測試；集中在各模組的介面是否一致、各模組間的資料流和控制流是否按照設計實現其功能、以及結果的正確性驗證等等；可以是整個產品的整合測試，也可以是大模組的整合測試；整合測試主要是針對程式內部結構進行測試，特別是對程式之間的介面進行測試。整合測試對測試人員的編寫指令碼能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結合。
系統測試：針對整個產品的全面測試，既包含各模組的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個使用者的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各種效能引數的測試。系統測試測試軟體《需求規格說明書》中提到的功能是否有遺漏，是否正確的實現。做系統測試要嚴格按照《需求規格說明書》，以它為標準。測試方法一般都使用黑盒測試法。
28.請問測試開發需要哪些知識？需要具備什麼能力？
需要的知識：
軟體測試基礎理論知識，如黑盒測試、白盒測試等；
考程式語言基礎，如C/C++、java、python等；
自動化測試工具，如Selenium、Appium、Robotium等；
計算機基礎知識，如資料庫、Linux、計算機網路等；
測試框架，如JUnit等。
需要具備的能力：
業務分析能力，分析整體業務流程、分析被測業務資料、分析被測系統架構、分析被測業務模組、分析測試所需資源、分析測試完成目標；
缺陷洞察能力，一般缺陷的發現能力、隱性問題的發現能力、發現連帶問題的能力、發現問題隱患的能力、儘早發現問題的能力、發現問題根源的能力；
團隊協作能力，合理進行人員分工、協助組員解決問題、配合完成測試任務、配合開發重現缺陷、督促專案整體進度、出現問題勇於承擔；
專業技術能力，掌握測試基礎知識、掌握計算機知識、熟練運用測試工具；
邏輯思考能力，判斷邏輯的正確性、對可行性邏輯分析、站在客觀角度思考；
問題解決能力，技術上的問題、工作中的問題、溝通問題；
溝通表達能力，和技術人員、產品人員、上下級的溝通；
巨集觀把控能力，有效控制測試時間、有效控制測試成本、有效制定測試計劃、有效進行風險評估、有效控制測試方向。
29.請說一說黑盒與白盒的測試方法
參考回答：
黑盒測試：
黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作一個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，並且保持外部資訊（如資料庫或檔案）的完整性。
“黑盒”法著眼於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
白盒測試：
白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程式的控制結構設計測試用例，主要用於軟體或程式驗證。白盒測試法檢查程式內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程式本身是否違反了設計規範，即程式是否是一個錯誤的程式；窮舉路徑測試不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與資料相關的錯誤。
白盒測試需要遵循的原則有：1. 保證一個模組中的所有獨立路徑至少被測試一次；2. 所有邏輯值均需要測試真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作範圍內執行所有迴圈。
常用白盒測試方法：
靜態測試：不用執行程式的測試，包括程式碼檢查、靜態結構分析、程式碼質量度量、文件測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具（Fxcop）自動進行。
動態測試：需要執行程式碼，通過執行程式找到問題，包括功能確認與介面測試、覆蓋率分析、效能分析、記憶體分析等。
白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。
30.請說一下手動測試與自動化測試的優缺點
手工測試缺點：
1、重複的手工迴歸測試，代價昂貴、容易出錯。
2、依賴於軟體測試人員的能力。
手工測試優點：
1、測試人員具有經驗和對錯誤的猜測能力。
2、測試人員具有審美能力和心理體驗。
3、測試人員具有是非判斷和邏輯推理能力。
自動化測試的優點：
1、對程式的迴歸測試更方便。這可能是自動化測試最主要的任務，特別是在程式修改比較頻繁時，效果是非常明顯的。由於迴歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動執行，可以極大提高測試效率，縮短迴歸測試時間。
2、可以執行更多更繁瑣的測試。自動化的一個明顯的好處是可以在較少的時間內執行更多的測試。
3、可以執行一些手工測試困難或不可能進行的測試。比如，對於大量使用者的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多使用者，從而達到測試的目的。
4、更好地利用資源。將繁瑣的任務自動化，可以提高準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合於自動測試，僅適合於手工測試，將可自動測試的測試自動化後，可以讓測試人員專注於手工測試部分，提高手工測試的效率。
5、測試具有一致性和可重複性。由於測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，從而達到測試的可重複的效果。
6、測試的複用性。由於自動測試通常採用指令碼技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。
7、增加軟體信任度。由於測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決於測試的設計質量。一旦軟體通過了強有力的自動測試後，軟體的信任度自然會增加。
自動化測試的缺點：
1、不能取代手工測試
2、手工測試比自動測試發現的缺陷更多
3、對測試質量的依賴性極大
4、測試自動化不能提高有效性
5、測試自動化可能會制約軟體開發。由於自動測試比手動測試更脆弱，所以維護會受到限制，從而制約軟體的開發。
6、工具本身並無想像力
31.請問你怎麼看待軟體測試的潛力和挑戰
軟體測試是正在快速發展，充滿挑戰的領域。儘管現在許多自動化測試軟體的出現使得傳統手工測試的方式被代替，但自動化測試工具的開發、安全測試、測試建模、精準測試、效能測試、可靠性測試等專項測試中仍然需要大量具有專業技能與專業素養的測試人員，並且隨著雲端計算、物聯網、大資料的發展，傳統的測試技術可能不再適用，測試人員也因此面臨著挑戰，需要深入瞭解新場景並針對不同場景嘗試新的測試方法，同時敏捷測試、Devops的出現也顯示了軟體測試的潛力。
32.你覺得軟體測試的核心競爭力是什麼
測試人員的核心競爭力在於提早發現問題，並能夠發現別人無法發現的問題。
1、早發現問題：問題發現的越早，解決的成本越低。如果一個需求在還未實現的時候就能發現需求的漏洞，那麼這種問題的價值是最高的。
2、發現別人無法發現的問題：所有人都能發現的問題，你發現了，那就證明你是可以被替代的。別人發現不了，而你可以發現，那麼你就是無法被替代。
33.你覺得測試和開發需要怎麼結合才能使軟體的質量得到更好的保障
參考回答：
測試和開發應該按照W模型的方式進行結合，測試和開發同步進行，能夠儘早發現軟體缺陷，降低軟體開發的成本。
在V模型中，測試過程被加在開發過程的後半部分，單元測試所檢測程式碼的開發是否符合詳細設計的要求。整合測試所檢測此前測試過的各組成部分是否能完好地結合到一起。系統測試所檢測已整合在一起的產品是否符合系統規格說明書的要求。而驗收測試則檢測產品是否符合終端使用者的需求。V模型的缺陷在於僅僅把測試過程作為在需求分析、系統設計及編碼之後的一個階段，忽視了測試對需求分析、系統設計的驗證，因此需求階段的缺陷很可能一直到後期的驗收測試才被發現，此時進行彌補將耗費大量人力物力資源。
相對於V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動。W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。
W模型強調：測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時瞭解專案難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快專案進度。
W模型中測試的活動與軟體開發同步進行，測試的物件不僅僅是程式，還包括需求和設計，因此能夠儘早發現軟體缺陷，降低軟體開發的成本。
34.你覺得單元測試可行嗎
參考回答：
可行，單元測試可以有效地測試某個程式模組的行為，是未來重構程式碼的信心保證。事前可以保證質量，事後可以快速復現問題，並在修改程式碼後做迴歸自測。可行性考慮的是要用一些可行的方法做到關鍵的程式碼可測試，如通過邊界條件、等價類劃分、錯誤、因果，設計測試用例要覆蓋常用的輸入組合、邊界條件和異常。
35.你覺得自動化測試有什麼意義，都需要做些什麼
自動化測試的意義在於
1、可以對程式的新版本自動執行迴歸測試
2、可以執行手工測試困難或者不可能實現的測試，如壓力測試，併發測試，
3、能夠更好的利用資源，節省時間和人力
執行自動化測試之前首先判斷這個專案是不是和推廣自動化測試，然後對專案做需求分析，指定測試計劃，搭建自動化測試框架，設計測試用例，執行測試，評估
36.請你回答一下測試的相關流程是什麼？
測試最規範的過程如下
需求測試->概要設計測試->詳細設計測試->單元測試->整合測試->系統測試->驗收測試
來自W模型
37.請你說一下如何寫測試用例？
1、測試人員儘早介入，徹底理解清楚需求，這個是寫好測試用例的基礎
2、如果以前有類似的需求，可以參考類似需求的測試用例，然後還需要看類似需求的bug情況
3、清楚輸入、輸出的各種可能性，以及各種輸入的之間的關聯關係，理解清楚需求的執行邏輯，通過等價類、邊界值、判定表等方法找出大部分用例
4、找到需求相關的一些特性，補充測試用例
5、根據自己的經驗分析遺漏的測試場景
6、多總結類似功能點的測試點，才能夠寫出質量越來越高的測試用例
7、書寫格式一定要清晰
38.請問你覺得測試專案具體工作是什麼？
答;搭建測試環境
撰寫測試用例
執行測試用例
寫測試計劃，測試報告
測試，並提交BUG表單
跟蹤bug修改情況
執行自動化測試，編寫指令碼，執行，分析，報告
進行效能測試，壓力測試等其他測試，執行，分析，調優，報告
39.請問如果想進行bug的測評，怎麼去評測bug？
Bug的priority（）和severity（）是兩個重要屬性，通常人員在提交bug的時候，只定義severity，而將priority交給leader定義，通常bug管理中，severity分為四個等級blocker、critical、major、minor/trivial，而priority分為五個等級immediate、urgent、high、normal、low。
Severity：
1、blocker：即系統無法執行，崩潰，或嚴重資源不足，應用模組無法啟動或異常退出，無法測試，造成系統不穩定。常見的有嚴重花屏、記憶體洩漏、使用者資料丟失或破壞、系統崩潰/宕機/凍結、模組無法啟動或異常退出、嚴重的數值計算錯誤、功能設計與需求嚴重不符、其它導致無法測試的錯誤， 如伺服器500錯誤。
2、critical：即映像系統功能或操作，主要功能存在嚴重缺陷，但不會映像到系統穩定性。常見的有：功能未實現，功能錯誤、系統重新整理錯誤、資料通訊錯誤、輕微的數值計算錯誤、影響功能及介面的錯誤字或拼寫錯誤。
3、major：即介面、效能缺陷、相容性，常見的有：操作介面錯誤，邊界條件錯誤，提示資訊錯誤，長時間操作無進度提示，系統未優化，相容性問題。
4、minor/trivial：即易用性及建議性問題。
Priority
1、immediate：即馬上解決，
2、urgent：急需解決
3、high：高度重視，有時間要馬上解決
4、low：在系統釋出前解決，或確認可以不用解決。
40.請你說一說測試用例的邊界?
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。
常見的邊界值
1)對16-bit 的整數而言 32767 和 -32768 是邊界
2)螢幕上游標在最左上、最右下位置
3)報表的第一行和最後一行
4)陣列元素的第一個和最後一個
5)迴圈的第 0 次、第 1 次和倒數第 2 次、最後一次
41.請你說一下軟體質量的六個特徵?
按照軟體質量國家標準GB-T8566–2001G，軟體質量可以用下列特徵來評價：
a.功能特徵：與一組功能及其指定性質有關的一組屬性，這裡的功能是滿足明確或隱含的需求的那些功能。
b.可靠特徵：在規定的一段時間和條件下，與軟體維持其效能水平的能力有關的一組屬性。
c.易用特徵：由一組規定或潛在的使用者為使用軟體所需作的努力和所作的評價有關的一組屬性。
d.效率特徵：與在規定條件下軟體的效能水平與所使用資源量之間關係有關的一組屬性。
e.可維護特徵：與進行指定的修改所需的努力有關的一組屬性。
f.可移植特徵：與軟體從一個環境轉移到另一個環境的能力有關的一組屬性。
42.請你說一下設計測試用例的方法
黑盒測試：
1.等價類劃分
等價類劃分是將系統的輸入域劃分為若干部分，然後從每個部分選取少量代表性資料進行測試。等價類可以劃分為有效等價類和無效等價類，設計測試用例的時候要考慮這兩種等價類。
2.邊界值分析法
邊界值分析法是對等價類劃分的一種補充，因為大多數錯誤都在輸入輸出的邊界上。邊界值分析就是假定大多數錯誤出現在輸入條件的邊界上，如果邊界附件取值不會導致程式出錯，那麼其他取值出錯的可能性也就很小。
邊界值分析法是通過優先選擇不同等價類間的邊界值覆蓋有效等價類和無效等價類來更有效的進行測試，因此該方法要和等價類劃分法結合使用。
3.正交試驗法
正交是從大量的試驗點中挑選出適量的、有代表性的點。正交試驗設計是研究多因素多水平的一種設計方法，他是一種基於正交表的高效率、快速、經濟的試驗設計方法。
4.狀態遷移法
狀態遷移法是對一個狀態在給定的條件內能夠產生需要的狀態變化，有沒有出現不可達的狀態和非法的狀態，狀態遷移法是設計足夠的用例達到對系統狀態的覆蓋、狀態、條件組合、狀態遷移路徑的覆蓋。
5.流程分析法
流程分析法主要針對測試場景型別屬於流程測試場景的測試項下的測試子項進行設計，這是從白盒測試中路徑覆蓋分析法借鑑過來的一種很重要的方法。
6.輸入域測試法
輸入域測試法是針對輸入會有各種各樣的輸入值的一個測試，他主要考慮 極端測試、中間範圍測試，特殊值測試 。
7.輸出域分析法
輸出域分析法是對輸出域進行等價類和邊界值分析，確定是要覆蓋的輸出域樣點，反推得到應該輸入的輸入值，從而構造出測試用例，他的目的是為了達到輸出域的等價類和邊界值覆蓋。
8.判定表分析法
判定表是分析和表達多種輸入條件下系統執行不同動作的工具，他可以把複雜的邏輯關係和多種條件組合的情況表達的即具體又明確；
9.因果圖法
因果圖是用於描述系統輸入輸出之間的因果關係、約束關係。因果圖的繪製過程是對被測系統的外部特徵的建模過程，根據輸入輸出間的因果圖可以得到判定表，從而規劃出測試用例。
10.錯誤猜測法
錯誤猜測法主要是針對系統對於錯誤操作時對於操作的處理法的猜測法，從而設計測試用例
11.異常分析法
異常分析法是針對系統有可能存在的異常操作，軟硬體缺陷引起的故障進行分析，分析發生錯誤時系統對於錯誤的處理能力和恢復能力依此設計測試用例。
白盒測試：
白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程式的控制結構設計測試用例，主要用於軟體或程式驗證。白盒測試法檢查程式內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程式本身是否違反了設計規範，即程式是否是一個錯誤的程式；窮舉路徑測試不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與資料相關的錯誤。
白盒測試需要遵循的原則有：1. 保證一個模組中的所有獨立路徑至少被測試一次；2. 所有邏輯值均需要測試真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作範圍內執行所有迴圈。
常用白盒測試方法：
靜態測試：不用執行程式的測試，包括程式碼檢查、靜態結構分析、程式碼質量度量、文件測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具（Fxcop）自動進行。
動態測試：需要執行程式碼，通過執行程式找到問題，包括功能確認與介面測試、覆蓋率分析、效能分析、記憶體分析等。
白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。
43.請你說一說測試工程師的必備技能
需要的知識：
• 軟體測試基礎理論知識，如黑盒測試、白盒測試等；
• 程式語言基礎，如C/C++、java、python等；
• 自動化測試工具，如Selenium、Appium、Robotium等；
• 計算機基礎知識，如資料庫、Linux、計算機網路等；
• 測試框架，如JUnit等。
需要具備的能力：
• 業務分析能力，分析整體業務流程、分析被測業務資料、分析被測系統架構、分析被測業務模組、分析測試所需資源、分析測試完成目標；
• 缺陷洞察能力，一般缺陷的發現能力、隱性問題的發現能力、發現連帶問題的能力、發現問題隱患的能力、儘早發現問題的能力、發現問題根源的能力；
• 團隊協作能力，合理進行人員分工、協助組員解決問題、配合完成測試任務、配合開發重現缺陷、督促專案整體進度、出現問題勇於承擔；
• 專業技術能力，掌握測試基礎知識、掌握計算機知識、熟練運用測試工具；
• 邏輯思考能力，判斷邏輯的正確性、對可行性邏輯分析、站在客觀角度思考；
• 問題解決能力，技術上的問題、工作中的問題、溝通問題；
• 溝通表達能力，和技術人員、產品人員、上下級的溝通；
• 巨集觀把控能力，有效控制測試時間、有效控制測試成本、有效制定測試計劃、有效進行風險評估、有效控制測試方向。
44.請你說一下app效能測試的指標
1、記憶體：記憶體消耗測試節點的設計目標是為了讓應用不佔用過多的系統資源，且及時釋放記憶體，保障整個系統的穩定性。當然關於記憶體測試，在這裡我們需要引入幾個概念：空閒狀態、中等規格、滿規格。
空閒狀態指開啟應用後，點選home鍵讓應用後臺執行，此時應用處於的狀態叫做空閒；中等規格和滿規格指的是對應用的操作時間的間隔長短不一，中等規格時間較長，滿規格時間較短。
記憶體測試中存在很多測試子項，清單如下：
●空閒狀態下的應用記憶體消耗；
●中等規格狀態下的應用記憶體消耗；
●滿規格狀態下的應用記憶體消耗；
●應用記憶體峰值；
●應用記憶體洩露；
●應用是否常駐記憶體；
●壓力測試後的記憶體使用。
2、CPU：
使用Android提供的view plaincopy在CODE上檢視程式碼片派生到我的程式碼片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt來獲取；
使用top命令view plaincopy在CODE上檢視程式碼片派生到我的程式碼片
adbshell top |grep packagename>/address/CPU.txt來獲取。
3、流量：
網路流量測試是針對大部分應用而言的，可能還有部分應用會關注網速、弱網之類的測試。
流量測試包括以下測試項：
應用首次啟動流量提示；
應用後臺連續執行2小時的流量值；
應用高負荷執行的流量峰值。
4、電量：
●測試手機安裝目標APK前後待機功耗無明顯差異；
●常見使用場景中能夠正常進入待機，待機電流在正常範圍內；
●長時間連續使用應用無異常耗電現象。
5、啟動速度：
第一類：首次啟動–應用首次啟動所花費的時間；
第二類：非首次啟動–應用非首次啟動所花費的時間；
第三類：應用介面切換–應用介面內切換所花費的時間。
6、滑動速度、介面切換速度
7、與伺服器互動的網路速度
45.請你說一說app測試的工具
參考回答：
功能測試自動化
a) 輕量介面自動化測試
jmeter，
b) APP UI層面的自動化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator，
iOS:基於Instrument的iOS UI自動化，
效能測試
a) Web前端效能測試
網路抓包工具：Wireshark
網頁檔案大小
webpagetest
pagespeed insight
chrome adb
b) APP端效能測試
Android記憶體佔用分析：MAT
iOS記憶體問題分析：ARC模式
Android WebView效能分析：
iOS WebView效能分析
c) 後臺服務效能測試
負載，壓力，耐久性
可拓展性，基準
工具：apacheAB，Jmeter，LoadRunner，
專項測試
a) 相容性測試
手工測試：作業系統，解析度，rom，網路型別
雲平臺：testin，指令碼編寫，Android。
b) 流量測試
Android自帶的流量管理，
iOS自帶的Network
tcpdump抓包
WiFi代理抓包：Fiddler
流量節省方法：壓縮資料，json優於xml；WebP優於傳統的JPG，PNG；控制訪問的頻次；只獲取必要的資料；快取；
c) 電量測試
基於測試裝置的方法，購買電量表進行測試。
GSam Battery Monitoe Pro
iOS基於Instrument Energy工具
d) 弱網路測試
手機自帶的網路狀況模擬工具
基於代理的弱網路的模擬:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner
46.請你說一說bug的週期，以及描述一下不同類別的bug
參考回答：
1、New:（新的）
當某個“bug”被第一次發現的時候，測試人員需要與專案負責人溝通以確認發現的的確是一個bug，如果被確認是一個bug，就將其記錄下來，並將bug的狀態設為New
2、Assigned（已指派的）
當一個bug被指認為New之後，將其反饋給開發人員，開發人員將確認這是否是一個bug，如果是，開發組的負責人就將這個bug指定給某位開發人員處理，並將bug的狀態設定為“Assigned”
3、Open（開啟的）
一旦開發人員開始處理bug的時候，他（她）就將這個bug的狀態設定為“Open”，這表示開發人員正在處理這個“bug”
4、Fixed（已修復的）
當開發人員進行處理（並認為已經解決）之後，他就可以將這個bug的狀態設定為“Fixed”並將其提交給開發組的負責人，然後開發組的負責人將這個bug返還給測試組
5、Pending Reset（待在測試的）
當bug被返還到測試組後，我們將bug的狀態設定為Pending Reset”
6、Reset(再測試)
測試組的負責人將bug指定給某位測試人員進行再測試，並將bug的狀態設定為“Reset”
7、Closed（已關閉的）
如果測試人員經過再次測試之後確認bug 已經被解決之後，就將bug的狀態設定為“Closed”
8、Reopen（再次開啟的）
如果經過再次測試發現bug（指bug本身而不是包括因修復而引發的新bug）仍然存在的話，測試人員將bug再次傳遞給開發組，並將bug的狀態設定為“Reopen”
9、Pending Reject（拒絕中）
如果測試人員傳遞到開發組的bug被開發人員認為是正常行為而不是bug時，這種情況下開發人員可以拒絕，並將bug的狀態設定為“Pending Reject”
10、Rejected(被拒絕的)
測試組的負責人接到上述bug的時候，如果他（她）發現這是產品說明書中定義的正常行為或者經過與開發人員的討論之後認為這並不能算作bug的時候，開發組負責人就將這個bug的狀態設定為“Rejected”
11、Postponed（延期）
有些時候，對於一些特殊的bug的測試需要擱置一段時間，事實上有很多原因可能導致這種情況的發生，比如無效的測試資料，一些特殊的無效的功能等等，在這種情況下，bug的狀態就被設定為“Postponed“
不同類別的bug：
Bug型別
• 程式碼錯誤
• 介面優化
• 設計缺陷
• 配置相關
• 安裝部署
• 安全相關
• 效能問題
• 標準規範
• 測試指令碼
• 其他
47.請你說一說PC網路故障，以及如何排除障礙
(1)首先是排除接觸故障，即確保你的網線是可以正常使用的。然後禁用網絡卡後再啟用，排除偶然故障。開啟網路和共享中心視窗，單擊視窗左上側“更改介面卡設定”右擊其中的“本地連線“或”無線網路連線”，單擊快捷選單中的“禁用”命令，即可禁用所選網路。接下來重啟網路，只需右擊後單擊啟用即可。
(2)使用ipconfig檢視計算機的上網引數
1、單擊“開始|所有程式|附件|命令提示符“，開啟命令提示符視窗
2、輸入ipconfig，按Enter確認，可以看到機器的配置資訊，輸入ipconfig/all,可以看到IP地址和網絡卡實體地址等相關網路詳細資訊。
(3)使用ping命令測試網路的連通性，定位故障範圍
在命令提示符視窗中輸入”ping 127.0.0.1“，資料顯示本機分別傳送和接受了4個數據包，丟包率為零，可以判斷本機網路協議工作正常，如顯示”請求超時“，則表明本機網絡卡的安裝或TCP/IP協議有問題，接下來就應該檢查網絡卡和TCP/IP協議，解除安裝後重裝即可。
(4)ping本機IP
在確認127.0.0.1地址能被ping通的情況下，繼續使用ping命令測試本機的IP地址能否被ping通，如不能，說明本機的網絡卡驅動程式不正確，或者網絡卡與網線之間連線有故障，也有可能是本地的路由表面收到了破壞，此時應檢查本機網絡卡的狀態是否為已連線，網路引數是否設定正確，如果正確可是不能ping通，就應該重新安裝網絡卡驅動程式。丟失率為零，可以判斷網絡卡安裝配置沒有問題，工作正常。
(5)ping閘道器
閘道器地址能被ping通的話，表明本機網路連線以及正常，如果命令不成功，可能是閘道器裝置自身存在問題，也可能是本機上網引數設定有誤，檢查網路引數。
48.請你說一說測試的常用方法
黑盒測試：
黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作一個不能開啟的黑盆子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，並且保持外部資訊（如資料庫或檔案）的完整性。
“黑盒”法著眼於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
白盒測試：
白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程式的控制結構設計測試用例，主要用於軟體或程式驗證。白盒測試法檢查程式內部邏輯結構，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程式本身是否違反了設計規範，即程式是否是一個錯誤的程式；窮舉路徑測試不可能檢查出程式因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與資料相關的錯誤。
白盒測試需要遵循的原則有：1. 保證一個模組中的所有獨立路徑至少被測試一次；2. 所有邏輯值均需要測試真（true）和假（false）；兩種情況；3. 檢查程式的內部資料結構，保證其結構的有效性；4. 在上下邊界及可操作範圍內執行所有迴圈。
常用白盒測試方法：
靜態測試：不用執行程式的測試，包括程式碼檢查、靜態結構分析、程式碼質量度量、文件測試等等，它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具（Fxcop）自動進行。
動態測試：需要執行程式碼，通過執行程式找到問題，包括功能確認與介面測試、覆蓋率分析、效能分析、記憶體分析等。
白盒測試中的邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標準發現錯誤的能力呈由弱到強的變化：
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。
49.請你說一說你知道的自動化測試框架
參考回答：
1、模組化測試框架
模組化測試指令碼框架（TEST MODulARITY FRAMEWORK）需要建立小而獨立的可以描述的模組、片斷以及待測應用程式的指令碼。這些樹狀結構的小指令碼組合起來，就能組成能用於特定的測試用例的指令碼。在五種框架中，模組化框架是最容易掌握和使用的。在一個元件上方建立一個抽象層使其在餘下的應用中隱藏起來，這是眾所周知的程式設計技巧。這樣應用同組件中的修改隔離開來，提供了程式設計的模組化特性。模組化測試指令碼框架使用這一抽象或者封裝的原理來提高自動測試組合的可維護性和可升級性。
2、測試庫框架
測試庫框架（Test Library Architecture）與模組化測試指令碼框架很類似，並且具有同樣的優點。不同的是測試庫框架把待測應用程式分解為過程和函式而不是指令碼。這個框架需要建立描述模組、片斷以及待測應用程式的功能庫檔案。
3、關鍵字驅動或表驅動的測試框架
對於一個獨立於應用的自動化框架，關鍵字驅動（KEYWORD DRIVEN）I9LJJ試和表驅動（TABLE DRIVEN）測試是可以互換的術語。這個框架需要開發資料表和關鍵字。這些資料表和關鍵字獨立於執行它們的測試自動化工具，並可以用來“驅動＂待測應用程式和資料的測試指令碼程式碼，關鍵宇驅動測試看上去與手工測試用例很類似。在一個關鍵字驅動測試中，把待測應用程式的功能和每個測試的執行步驟一起寫到一個表中。這個測試框架可以通過很少的程式碼來產生大量的測試用例。同樣的程式碼在用資料表來產生各個測試用例的同時被複用。
4、資料驅動測試框架
資料驅動（DATA DRIVEN），LJ試是一個框架。在這裡測試的輸入和輸出資料是從資料檔案中讀取（資料池，ODBC源，CSV檔案，EXCEL檔案，ADO物件等）並且通過捕獲工具生成或者手工生成的程式碼指令碼被載入到變數中。在這個框架中，變數不僅被用來存放輸入值還被用來存放輸出的驗證值。整個程式中，測試指令碼來讀取數值檔案，記載測試狀態和資訊。這類似於表驅動測試，在表驅動測 試中，它的測試用例是包含在資料檔案而不是在指令碼中，對於資料而言，指令碼僅僅是一個“驅動器”，或者是一個傳送機構。然而，資料驅動測試不同於表驅動測試，儘管導航資料並不包含在表結構中。在資料驅動測試中，資料檔案中只包含測試資料。這個框架意圖減少需要執行所有測試用例所需要的總的測試指令碼數。資料驅動需要很少的程式碼來產生大量的測試用例，這與表驅動極其類似。
5、混合測試自動化（Hybrid Test Automation）框架
最普遍的執行框架是上面介紹的所有技術的一個結合，取其長處，彌補其不足。這個混合測試框架是由大部分框架隨著時間並經過若干專案演化而來的
50.請你說一說web測試和app測試的不同點
系統架構方面：
web專案，一般都是b/s架構，基於瀏覽器的
app專案，則是c/s的，必須要有客戶端，使用者需要安裝客戶端。
web測試只要更新了伺服器端，客戶端就會同步會更新。App專案則需要客戶端和伺服器都更新。
效能方面:
web頁面主要會關注響應時間
而app則還需要關心流量、電量、CPU、GPU、Memory這些。
它們服務端的效能沒區別，都是一臺伺服器。
相容方面：
web是基於瀏覽器的，所以更傾向於瀏覽器和電腦硬體，電腦系統的方向的相容
app測試則要看解析度，螢幕尺寸，還要看裝置系統。
web測試是基於瀏覽器的所以不必考慮安裝解除安裝。
而app是客戶端的，則必須測試安裝、更新、解除安裝。除了常規的安裝、更新、解除安裝還要考慮到異常場景。包括安裝時的中斷、弱網、安裝後刪除安裝檔案 。
此外APP還有一些專項測試：如網路、適配性。
51.請問你瞭解什麼測試方法
參考回答：
等價類劃分，邊界值分析，錯誤推測，因果圖法，邏輯覆蓋法，程式插樁技術，基本路徑法，符號測試，錯誤驅動測試
52.請問黑盒測試和白盒測試有哪些方法
黑盒測試方法有等價類劃分，邊界值分析，錯誤推測，因果圖法
白盒測試方法有邏輯覆蓋法，程式插樁技術，基本路徑法，符號測試，錯誤驅動測試
53.請問你怎麼看待測試，知道哪些測試的型別，有用過哪些測試方法？
測試是軟體開發中不可或缺的一環，測試通過經濟，高效的方法，捕捉軟體中的錯誤，從而達到保重軟體內在質量的目的。
測試分為功能測試和非功能測試，非功能測試又可以分為效能測試、壓力測試、容量測試、健壯性測試、安全性測試、可靠性測試、恢復性測試、備份測試、協議測試、相容性測試、可用性測試、配置測試、GUI測試。
測試方法用過等價劃分法、邊值分析法、錯誤推測法、因果圖法。
54.請問你怎麼測試網路協議?
協議測試包括四種類型的測試
1、一致性測試：檢測協議實現本身與協議規範的符合程度
2、互操作性測試：基於某一協議檢測不同協議實現間互操作互通訊的能力
3、效能測試：檢測協議實現的效能指標，比如資料傳輸速度，連線時間，執行速度，吞吐量，併發度，
4、健壯性測試：檢測協議是現在各種惡劣環境下執行的能力，比如注入干擾報文，通訊故障，通道被切斷
軟體測試筆試面試題目完全彙總
軟體缺陷：
1）軟體未實現產品說明書要求的功能
2）軟體出現了產品說明書指明不應該出現的錯誤
3）軟體實現了產品說明書未提到的功能
4）軟體未實現產品說明書雖未明確提及但應該實現的目標
5）軟體難以理解、不易使用、執行緩慢或者從測試員的角度看終端使用者會認為不好。
軟體測試：為了發現軟體產品中的各種缺陷，而對軟體產品進行驗證和確認的活動過程，此過程貫穿整個軟體開發生命週期。 簡單的說，軟體測試是以發現錯誤為目的而執行的一個程式或系統的過程。
軟體測試的目的：
1.驗證軟體需求和功能是否得到完整實現
2.驗證軟體是否可以釋出
3.儘可能多的發現軟體中的bug
4.儘可能早的發現軟體中的bug
5.對軟體質量做出合理評估
6.預防下個版本可能出現的問題
7.預防使用者使用可能出現的問題
8.發現開發過程中的問題和風險
軟體測試的原則：
1、所有測試的標準都是建立在使用者需求之上 。
2、合理控制測試深度與廣度，完全測試不可能，測試的投入與產出要均衡。
3、80-20原則，軟體中80%的bug可以在分析、設計與評審階段就能被發現與修正，16%的缺陷在系統的軟體測試中發現，最後剩下的4%是使用者長期使用的過程中才能暴露出來。
4、儘可能早的開展測試，越早發現錯誤，修改的代價越小。
5、發現錯誤較多的程式段，應進行更深入的測試。
6、軟體專案一啟動，軟體測試也就是開始，而不是等程式寫完，才開始進行測試 。
7、軟體開發人員即程式設計師應當避免測試自己的程式
8、嚴格執行測試計劃，排除測試的隨意性，以避免發生疏漏或者重複無效的工作
軟體測試的流程
web測試和APP測試的區別
僅僅從功能測試的層面上來講的話，在流程和功能測試上是沒有區別的。那麼區別在哪裡呢？
由於載體不一樣，所以系統測試和一些細節可能會不一樣。
那麼我們就要先來了解，web和app的區別。
web專案，一般都是b/s架構，基於瀏覽器的，而app則是c/s的，必須要有客戶端。那麼在系統測試測試的時候就會產生區別了。
首先從系統架構來看的話，web測試只要更新了伺服器端，客戶端就會同步會更新。而且客戶端是可以保證每一個使用者的客戶端完全一致的。但是app端是不能夠保證完全一致的，除非使用者更新客戶端。如果是app下修改了服務端，意味著客戶端使用者所使用的核心版本都需要進行迴歸測試一遍。
接著是效能方面，web頁面可能只會關注響應時間，而app則還需要關心流量、電量、CPU、GPU、Memory這些了。至於服務端的效能是沒區別，這裡就不談。
相比較web測試，app更是多了一些專項測試：
健壯性測試：
一些異常場景的考慮以及弱網路測試。這裡的異常場景就是中斷，來電，簡訊，關機，重啟等。
而弱網測試是app測試中必須執行的一項測試。包含弱網和網路切換測試。需要測試弱網所造成的使用者體驗，重點要考慮回退和重新整理是否會造成二次提交。需要測試丟包，延時的處理機制。避免使用者的流失。這些在前面的弱網測試那篇已經講過，這裡不再講了。
安裝、解除安裝、更新：
web測試是基於瀏覽器的所以不必考慮這些。而app是客戶端的，則必須測試安裝、更新、解除安裝。除了常規的安裝、更新、解除安裝還要考慮到異常場景。包括安裝時的中斷、弱網、安裝後刪除安裝檔案，更新的強制更新與非強制更新、增量包更新、斷點續傳、弱網，解除安裝後刪除app相關的檔案等等。
就自動化來講，web大多用的selenium、webdriver，而app則是appium。
效能使用的工具web則是LR，app使用Jmeter要多一點
如何提交高質量的缺陷報告單
1、 缺陷的概要描述要清晰準確，要使相關開發負責人員能夠一目瞭然問題是什麼。
2、 一個完整的缺陷報告單，必須包含其必要的元素資訊，例如：概要描述，缺陷發現人，測試環境，瀏覽器，缺陷重現步驟，嚴重等級，指派人，所屬功能模組等等，必要元素資訊必須描述全面清楚。
3、 缺陷的重現步驟必須描寫清晰明瞭，使相關開發負責人能夠根據重現步驟準確的重現所提交的缺陷，使其定位缺陷的原因所在。
4、測試資料，測試的資料作為重現缺陷的一個重要元素資訊，一定要將測試時所使用的資訊給描寫清楚準確。讓開發人員根據測試所提供的測試資料準確重現缺陷。
5、附件截圖資訊，附件或截圖資訊能讓開發人員能夠一目瞭然的清楚問題的所在。
如何對web系統進行全面測試？
原文地址：http://www.51testing.com/html/04/n-3727304.html
一、 功能測試
1、連結測試
連結是Web應用系統的一個主要特徵，它是在頁面之間切換和指導使用者去一些不知道地址的頁面的主要手段。連結測試可分為三個方面。首先，測試所有連結是否按指示的那樣確實連結到了該連結的頁面;其次，測試所連結的頁面是否存在;最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連結指向該頁面，只有知道正確的URL地址才能訪問。 連結測試可以自動進行，現在已經有許多工具可以採用。連結測試必須在整合測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行連結測試。
2、表單測試
當用戶給Web應用系統管理員提交資訊時，就需要使用表單操作，例如使用者註冊、登陸、資訊提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給伺服器的資訊的正確性。例如：使用者填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了預設值，還要檢驗預設值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
3、Cookies測試
Cookies通常用來儲存使用者資訊和使用者在某應用系統的操作，當一個使用者使用Cookies訪問了某一個應用系統時，Web伺服器將傳送關於使用者的資訊，把該資訊以Cookies的形式儲存在客戶端計算機上，這可用來建立動態和自定義頁面或者儲存登陸等資訊。 如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行儲存，重新整理對Cookies有什麼影響等。
4、設計語言測試
Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分散式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的指令碼語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
5、資料庫測試
在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、執行、查詢和實現使用者對資料儲存的請求等提供空間。在Web應用中，最常用的資料庫型別是關係型資料庫，可以使用SQL對資訊進行處理。 在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是資料一致性錯誤和輸出錯誤。資料一致性錯誤主要是由於使用者提交的表單資訊不正確而造成的，而輸出錯誤主要是由於網路速度或程式設計問題等引起的，針對這兩種情況，可分別進行測試。
二、 效能測試
1、連線速度測試
使用者連線到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長(例如超過5秒鐘)，使用者就會因沒有耐心等待而離開。 另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。
2、負載測試
負載測試是為了測量Web系統在某一負載級別上的效能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的使用者數量，也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上?如果超過了這個數量，會出現什麼現象?Web應用系統能否處理大量使用者對同一個頁面的請求?
3、壓力測試
負載測試應該安排在Web系統釋出以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。 進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。 壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。
三、 可用性測試
1、導航測試
導航描述了使用者在一個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等;或在不同的連線頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀?Web系統的主要部分是否可通過主頁存取?Web系統是否需要站點地圖、搜尋引擎或其他的導航幫助? 在一個頁面上放太多的資訊往往起到與預期相反的效果。Web應用系統的使用者趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的資訊，如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。 導航的另一個重要方面是Web應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。 Web應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。
2、圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。
圖形測試的內容有：
(1)要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都連結到某個具體的頁面。
(2)驗證所有頁面字型的風格是否一致。
(3)背景顏色應該與字型顏色和前景顏色相搭配。
(4)圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮。
3、內容測試
內容測試用來檢驗Web應用系統提供資訊的正確性、準確性和相關性。 資訊的正確性是指資訊是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛;資訊的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文書處理軟體來進行，例如使用Microsoft Word的拼音與語法檢查功能;資訊的相關性是指是否在當前頁面可以找到與當前瀏覽資訊相關的資訊列表或入口，也就是一般Web站點中的所謂相關文章列表。
4、整體介面測試
整體介面是指整個Web應用系統的頁面結構設計，是給使用者的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的資訊在什麼地方?整個Web應用系統的設計風格是否一致? 對整體介面的測試過程，其實是一個對終端使用者進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到終端使用者的反饋資訊。 對所有的可用性測試來說，都需要有外部人員(與Web應用系統開發沒有聯絡或聯絡很少的人員)的參與，最好是終端使用者的參與。
四、 客戶端相容性測試
1、平臺測試
市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的終端使用者究竟使用哪一種作業系統，取決於使用者系統的配置。這樣，就可能會發生相容性問題，同一個應用可能在某些作業系統下能正常執行，但在另外的作業系統下可能會執行失敗。 因此，在Web系統釋出之前，需要在各種作業系統下對Web系統進行相容性測試。
2、瀏覽器測試
瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規格有不同的支援。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設定也不一樣。 測試瀏覽器相容性的一個方法是建立一個相容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設定的適應性。
五、 安全性測試
Web應用系統的安全性測試區域主要有：
(1)現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的使用者名稱和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
(2)Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內(例如15分鐘)沒有點選任何頁面，是否需要重新登陸才能正常使用。
(3)為了保證Web應用系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。
(4)當使用了安全套接字時，還要測試加密是否正確，檢查資訊的完整性。
(5)伺服器端的指令碼常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。
測試用例設計經典面試題——電梯，杯子，筆，桌子，洗衣機
原文地址：https://blog.csdn.net/slforeverlove/article/details/47080279
優秀測試人員應具備的素質：
1）溝通能力與表達能力
2）好奇心與懷疑精神
3）責任感與抗壓能力
4）自信心，堅持自己的觀點
5）耐心與細心
6）逆向思維的能力
7）善於學習與總結
8）團隊協作精神
9）文件編寫能力
優秀測試人員應具備的技能：
1）精通業務知識
2）具備軟體程式設計能力，比如C,C++,JAVA等。
3）可以用指令碼語言編寫小測試工具
4）主流作業系統應用與網路知識，可以搭建測試環境
5）熟練掌握各種資料庫知識
6）精通軟體測試理論與方法
7）掌握常用測試與開發工具的使用
8）優秀的文件編寫能力
軟體測試的分類：
1）按照是否執行被測試軟體來分：
靜態測試：是指不執行軟體，測試包括程式碼檢查、靜態結構分析、程式碼質量度量等，主要對軟體需求說明書、設計說明書、軟體原始碼進行檢查與分析。
動態測試：指通過執行被測程式，檢查執行結果與預期結果的差異，分析差異原因，並分析軟體執行效率、健壯性等效能。 動態測試是目前公司主要的測試方式
2）按照測試技術分為黑盒測試和白盒測試：
黑盒測試：黑盒測試又叫功能測試或資料驅動測試，在完全不考慮程式內部結構和內部特性的情況下，通過軟體的外部表現來發現其缺陷和錯誤。
白盒測試：白盒測試也稱結構測試或邏輯驅動測試，它是按照程式內部的結構進行測試程式，通過測試來檢測產品內部邏輯是否按照設計規格說明書的規定正常進行，檢驗程式中的每條通路是否都能按預定要求正確工作。
3）按照測試手段來分，可以分為手工測試和自動化測試
4）按照過程階段來分，可以分為單元測試、整合測試、系統測試和驗收測試
單元測試：通過模組(類/方法/函式)測試，使程式碼達到設計要求 主要目的是針對編碼過程中可能存在的各種錯誤，例如使用者輸入驗證過程中的邊界值的錯誤。
整合測試：將經過單元測試的模組逐步組裝成完整的程式。 主要目的是檢查各單元與其它程式部分之間的介面是否存在問題，各模組功能之間是否有影響。
系統測試：是將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起進行測試。 系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方 ，進行改正。
驗收測試：驗收測試是在軟體產品完成了單元測試、整合測試和系統測試之後，產品釋出之前所進行的最後一次軟體測試活動，也稱為交付測試。 通常由業務專家或使用者進行，以確認產品能真正符合使用者業務上的需要。
軟體開發流程（軟體生命週期）：
計劃-》需求分析-》設計-》程式編寫-》測試-》執行/維護
軟體測試流程：
測試計劃-》需求分析-》測試用例-》測試用例執行-》提交bug-》迴歸測試
軟體開發模型：
軟體測試模型：
V模型：反映了測試與開發階段之間一一對應的特點，測試在開發之後，出錯後迴歸測試量大。
W模型：測試伴隨整個開發週期，測試與開發同步進行，有利於儘早發現問題
H模型：軟體測試活動完全獨立，與其他流程並行。
白盒測試方法
白盒測試方法有 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。
設計用例的方法、依據有那些?
測試分為白盒測試和黑盒測試，回答時，要注意分開說。白盒測試用例設計有如下方法：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。依據就是程式碼結構。
黑盒測試用例設計方法：基於使用者需求的測試、等價類劃分方法、邊界值分析方法、錯誤推測方法、因果圖方法、判定表驅動分析方法、正交實驗法、場景法。依據是使用者需求規格說明書，詳細設計說明書。
一個測試工程師應具備那些素質和技能?
一個好的測試工程師，不僅要基礎紮實，對自身的性格、責任心都有非常高的要求。具體如下：(1)掌握基本的測試基礎理論(2)本著找出軟體存在的問題的態度進行測試,即客觀吧,不要以挑刺形象出現(3)可熟練閱讀需求規格說明書等文件(4)以使用者的觀點看待問題(5)有著強烈的質量意識(6)細心和責任心(7)良好的有效的溝通方式(與開發人員及客戶)(8)具有以往的測試經驗(9)能夠及時準確地判斷出高危險區在何處.
整合測試通常都有哪些策略?
大致說四點即可，當然說全更好。整合測試有十種策略:(1)大爆炸整合(2)自頂向下整合(3)自底向上整合(4)三明治整合(5)分層整合(6)基幹整合(7)基於功能的整合(8)基於訊息的整合(9)基於風險的整合(10)基於進度的整合.
什麼是相容性測試？相容性測試側重哪些方面？
相容測試主要是檢查軟體在不同的硬體平臺、軟體平臺上是否可以正常的執行，即是通常說的軟體的可移植性。
相容的型別，如果細分的話，有平臺的相容，網路相容，資料庫相容，以及資料格式的相容。
相容測試的重點是，對相容環境的分析。通常，是在執行軟體的環境不是很確定的情況下，才需要做相容。根據軟體執行的需要，或者根據需求文件，一般都能夠得出使用者會在什麼環境下使用該軟體，把這些環境整理成表單，就得出做相容測試的相容環境了。
我現在有個程式，發現在Windows上執行得很慢，怎麼判別是程式存在問題還是軟硬體系統存在問題？
1、檢查系統是否有中毒的特徵；
2、檢查軟體/硬體的配置是否符合軟體的推薦標準；
3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務；
4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對CPU/記憶體的訪問情況。
測試的策略有哪些？
黑盒/白盒，靜態/動態，手工/自動，冒煙測試，迴歸測試，公測（Beta測試的策略）
正交表測試用例設計方法的特點是什麼？
用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很複雜；
對於基本的驗證功能，以及二次整合引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
描述使用bugzilla缺陷管理工具對軟體缺陷（BUG）跟蹤的管理的流程？
在Bugzilla中，Bug報告狀態分為以下幾種狀態，
待確認的 unconfirmed
新提交的 new
已分配的 assigned
問題未解決的 reopened
待返測的 resolved
待歸檔的 verified
已歸檔的 closed
12345678910111213
Bug處理意見（Resolution）
已修改的 fixed
不是問題 nvalid
無法修改 wontfix
以後版本解決 later
保留 remind
重複 duplicate
無法重現 workforme
12345678910111213
你覺得bugzilla在使用的過程中，有什麼問題？
介面不穩定；
根據需要配置它的不同的部分，過程很煩瑣。
流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；
沒有綜合的評分指標，不好確認修復的優先級別。
描述測試用例設計的完整過程？
需求分析 + 需求變更的維護工作；
根據需求 得出測試需求；
設計測試方案，評審測試方案；
方案評審通過後，設計測試用例，再對測試用例進行評審；
單元測試的策略有哪些？
單元的常見錯誤一般出現在以下五個方面，因此這五個方面是單元測試應該關注的重點。
1、單元介面。
2、區域性資料結構。
3、獨立路徑。
4、出錯處理。
5、邊界條件
在單元測試時，由於單元本身不是一個獨立的程式，一個完整的可執行的軟體系統並沒有構成，所以需要設定一些輔助測試單元，輔助測試單元有兩種，一種是驅動單元，另外一種是樁單元。
1、驅動單元（Driver）:用來模擬被測單元的上層單元，相當於被測函式的主函式，如main函式。所以驅動單元主要完成以下4個步驟：
（1）接受測試資料，包含測試用例輸入和預期輸出；
（2）把測試用例輸入傳送給被測單元，驅動被測單元測試；
（3）將被測單元的實際輸出和預期輸出進行比較，得到測試結果；
（4）將測試結果輸出到指定位置。
2、樁單元（Stub）：用來代替被測單元工作過程中呼叫的子單元。
樁單元模擬的單元可能是自定義函式：這些自定義函式可能尚未編寫完成，為了測試被測單元，需要構造樁單元來代替它們，可能存在錯誤，會影響測試結果，所以需要構造正確無誤的樁單元來達到隔離的目的。
驅動單元和樁單元都是額外的開銷，雖然在單元測試的時候必須寫，但是並不需要作為最終的產品提供給客戶。
單元測試策略
一般的單元執行策略有三種：孤立的單元測試策略（Isolation Unit Testing），自頂向下的單元測試策略（Top Down Unit Testing）和自底向上的單元測試策略（Bottom Up Unit Testing）。需要注意的是：在整合測試中也有自頂向下和自底向上的測試策略，但是測試物件不同。
1、孤立的單元測試策略（Isolation Unit Testing）
方法：不考慮每個模組與其它模組之間的關係，為每個模組設計樁模組和驅動模組，每個模組進行獨立的單元測試。
優點：這個方法比較簡單，最容易操作，可以達到很高的結構覆蓋率，可以並行開展，該方法是純粹的單元測試。
缺點：樁函式和驅動函式工作量很大，效率低。
2、自頂向下的單元測試策略（Top Down Unit Testing）
方法：先對最頂層的單元進行測試，把頂層所呼叫的單元做成樁模組，其次對第二層進行測試，使用上面已經測試過的單元做驅動模組，以此類推，直到測試完所有模組。
優點：可以節省驅動函式的開發工作，效率高。
缺點：隨著被測單元一個一個被加入，測試過程將變得越來越複雜，並且開發和維護的成本將增加。
3、自底向上的單元測試策略（Bottom Up Unit Testing）
方法：先對最底層的模組進行單元測試，將模擬呼叫該模組的模組設定為驅動模組，然後再對上面一層做單元測試，用下面已經測試好的模組做樁模組，以此類推，直到測試完所有模組。
優點：可以節省樁函式的開發工作量，測試效率較高。
缺點：不是純粹的單元測試，底層函式的測試質量對上層函式的測試將產生很大影響。
LoadRunner分哪三部分？
指令碼生成器；
場景控制器；
結果分析器。
LoadRunner進行測試的流程?
1、 測試設計
2、 建立虛擬使用者指令碼
3、 建立執行場景
4、 執行場景
5、 監視場景
6、 分析測試的結果
以上，最好是結合一個案例，根據以上流程來介紹。
什麼是併發？在lordrunner中，如何進行併發的測試？集合點失敗了會怎麼樣？
在同一時間點，支援多個不同的操作。
LoadRunner中提供IP偽裝，集合點，配合虛擬使用者的設計，以及在多臺電腦上設定，可以比較好的模擬真實的併發。
集合點，即是多個使用者在某個時刻，某個特定的環境下同時進行虛擬使用者的操作的。集合點失敗，則集合點的操作就會取消，測試就不能進行。
TestDirector有些什麼功能，如何對軟體測試過程進行管理？
需求管理
n 定義測試範圍
n 定義需求樹
n 描述需求樹的功能點
測試計劃
n 定義測試目標和測試策略。
n 分解應用程式，建立測試計劃樹。
n 確定每個功能點的測試方法。
n 將每個功能點連線到需求上，使測試計劃覆蓋全部的測試需求。
n 描述手工測試的測試步驟
n 指明需要進行自動測試的功能點
測試執行
n 定義測試集合。
n 為每個測試人員制定測試任務和測試日程安排。
n 執行自動測試。
缺陷跟蹤
n 記錄缺陷
n 檢視新增缺陷，並確定哪些是需要修正的
n 相關技術人員修改缺陷
n 迴歸測試
n 分析缺陷統計圖表，分析應用程式的開發質量。
你所熟悉的軟體測試型別都有哪些？請試著分別比較這些不同的測試型別的區別與聯絡（如功能測試、效能測試……）？
Compatibility Testing（相容性測試），也稱“Configuration testing（配置測試）”，測試軟體是否和系統的其它與之互動的元素之間相容，如：瀏覽器、作業系統、硬體等。驗證測試物件在不同的軟體和硬體配置中的執行情況。
Functional testing (功能測試)，也稱為behavioral testing（行為測試），根據產品特徵、操作描述和使用者方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。本地化軟體的功能測試，用於驗證應用程式或網站對目標使用者能正確工作。使用適當的平臺、瀏覽器和測試指令碼，以保證目標使用者的體驗將足夠好，就像應用程式是專門為該市場開發的一樣。
Performance testing（效能測試），評價一個產品或元件與效能需求是否符合的測試。包括負載測試、強度測試、資料庫容量測試、基準測試等型別。
一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？
1.和BUG對應的軟體版本
2.開發的介面人員，測試人員
3.BUG的優先順序
4.BUG的嚴重程度
5.BUG可能屬於的模組
6.BUG的標題
7.BUG的描述
8.BUG的截圖
9.BUG的狀態
10.BUG的錯誤型別（資料，介面。。。。）
Beta測試與Alpha測試有什麼區別？
Beta testing(β測試),測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場
Alpha testing (α測試),是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試
軟體的評審一般由哪些人蔘加？其目的是什麼？
在正式的會議上將軟體專案的成果（包括各階段的文件、產生的程式碼等）提交給使用者、客戶或有關部門人員對軟體產品進行評審和批准。其目的是找出可能影響軟體產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並採取補救措施，以及找出在效能、安全性和經濟方面的可能的改進。
人員：使用者、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段
階段評審與專案評審有什麼區別？
階段評審對專案各階段評審：對階段成果和工作
專案評審對專案總體評審：對工作和產品
什麼是扇入？什麼是扇出？
參考答案：
扇入：被調次數，扇出：調其它模組數目
什麼是樁模組？什麼是驅動模組？
樁模組：被測模組呼叫模組
驅動模組：呼叫被測模組
你認為做好測試計劃工作的關鍵是什麼？
軟體測試計劃就是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源、時間、風險、測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測試；
做好測試計劃工作的關鍵：目的，管理，規範
1、 明確測試的目標，增強測試計劃的實用性
編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
2．堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裡）”、“How（如何做）”。利用“5W”規則建立軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文件和軟體的存放位置（Where）。
3．採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
4、分別建立測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
簡述一下缺陷的生命週期？
提交->確認->分配->修復->驗證->關閉
軟體的安全性應從哪幾個方面去測試？
(1)使用者認證機制：如資料證書、智慧卡、雙重認證、安全電子交易協議
(2)加密機制
(3)安全防護策略：如安全日誌、入侵檢測、隔離防護、漏洞掃描
(4)資料備份與恢復手段：儲存裝置、儲存優化、儲存保護、儲存管理
(5)防病毒系統
軟體配置管理工作開展的情況和認識？
軟體配置管理貫穿於軟體開發、測試活動的始終，覆蓋了開發、測試活動的各個環節，它的重要作用之一就是要全面的管理儲存各個配置項，監控各配置項的狀態，並向專案經理及相關的人員報告，從而實現對軟體過程的控制。
軟體測試配置管理包括4個最基本的活動：
配置項標識
配置項控制
配置項狀態報告
配置審計
軟體配置管理通常藉助工具來輔助，主要有MS SourceSafe、Rational ClearCase等
1
你覺得軟體測試通過的標準應該是什麼樣的？
缺陷密度值達到客戶的要求
1
引入測試管理的含義？
風險分析，進度控制、角色分配、質量控制
一套完整的測試應該由哪些階段組成？
參考答案：測試計劃、測試設計與開發、測試實施、測試評審與測試結論
單元測試的主要內容？
模組介面測試、區域性資料結構測試、路徑測試、錯誤處理測試、邊界測試
整合測試也叫組裝測試或者聯合測試，請簡述整合測試的主要內容？
（1）在把各個模組連線起來的時候，穿越模組介面的資料是否會丟失；
（2）一個模組的功能是否會對另一個模組的功能產生不利的影響；
（3）各個子功能組合起來，能否達到預期要求的父功能；
（4）全域性資料結構是否有問題；
（5）單個模組的誤差累積起來，是否會放大，從而達到不能接受的程度。
簡述整合測試與系統測試關係？
（1）整合測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；
（2）整合測試是系統模組的測試，系統測試是對整個系統的測試，包括相關的軟硬體平臺、網路以及相關外設的測試。
軟體測試的文件測試應當貫穿於軟體生命週期的全過程，其中使用者文件是文件測試的重點。那麼軟體系統的使用者文件包括哪些？
使用者手冊
安裝和設定指導
聯機幫助
指南、嚮導
樣例、示例和模板
授權/註冊登記表
終端使用者許可協議
軟體系統中除使用者文件之外，文件測試還應該關注哪些文件？
開發文件
軟體需求說明書
資料庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
1234567
管理文件
專案開發計劃
測試計劃
測試報告
開發進度月報
開發總結報告
123456789
簡述軟體系統中使用者文件的測試要點？
（1）讀者群。文件面向的讀者定位要明確。對於初級使用者、中級使用者以及高階使用者應該有不同的定位
（2）術語。文件中用到的術語要適用與定位的讀者群，用法一致，標準定義與業界規範相吻合。
（3）正確性。測試中需檢查所有資訊是否真實正確，查詢由於過期產品說明書和銷售人員誇大事實而導致的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試連結是否準確，產品支援電話、地址和郵政編碼是否正確。
（4）完整性。對照軟體介面檢查是否有重要的分支沒有描述到，甚至是否有整個大模組沒有描述到。
（5）一致性。按照文件描述的操作執行後，檢查軟體返回的結果是否與文件描述的相同。
（6）易用性。對關鍵步驟以粗體或背景色給使用者以提示，合理的頁面佈局、適量的圖表都可以給使用者更高的易用性。需要注意的是文件要有助於使用者排除錯誤。不但描述正確操作，也要描述錯誤處理辦法。文件對於使用者看到的錯誤資訊應當有更詳細的文件解釋。
（7）圖表與介面截圖。檢查所有圖表與介面截圖是否與發行版本相同。
（8）樣例與示例。像使用者一樣載入和使用樣例。如果是一段程式，就輸入資料並執行它。以每一個模組製作檔案，確認它們的正確性。
（9）語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是螢幕截圖或繪製圖形中的文字。
（10）印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。
單元測試主要內容是什麼？
單元測試大多數由開發人員來完成，測試人員技術背景較好或者開發系統軟體時可能會安排測試人員進行單元測試，大多數進行的單元測試都是開發人員除錯程式或者開發組系統聯合除錯的過程。討論這個問題主要是擴充一下讀者的視野。
單元測試一般包括五個方面的測試：
（1）模組介面測試：模組介面測試是單元測試的基礎。只有在資料能正確流入、流出模組的前提下，其他測試才有意義。模組介面測試也是整合測試的重點，這裡進行的測試主要是為後面打好基礎。測試介面正確與否應該考慮下列因素：
-輸入的實際引數與形式引數的個數是否相同；
-輸入的實際引數與形式引數的屬性是否匹配；
-輸入的實際引數與形式引數的量綱是否一致；
-呼叫其他模組時所給實際引數的個數是否與被調模組的形參個數相同；
-呼叫其他模組時所給實際引數的屬性是否與被調模組的形參屬性匹配；
-呼叫其他模組時所給實際引數的量綱是否與被調模組的形參量綱一致；
-呼叫預定義函式時所用引數的個數、屬性和次序是否正確；
-是否存在與當前入口點無關的引數引用；
-是否修改了只讀型引數；
-對全程變數的定義各模組是否一致；
-是否把某些約束作為引數傳遞。
如果模組功能包括外部輸入輸出，還應該考慮下列因素：
-檔案屬性是否正確；
-OPEN/CLOSE語句是否正確；
-格式說明與輸入輸出語句是否匹配；
-緩衝區大小與記錄長度是否匹配；
-檔案使用前是否已經開啟；
-是否處理了檔案尾；
-是否處理了輸入/輸出錯誤；
-輸出資訊中是否有文字性錯誤。
-區域性資料結構測試；
-邊界條件測試；
-模組中所有獨立執行通路測試；
（2）區域性資料結構測試：檢查區域性資料結構是為了保證臨時儲存在模組內的資料在程式執行過程中完整、正確，區域性功能是整個功能執行的基礎。重點是一些函式是否正確執行，內部是否執行正確。區域性資料結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
-不合適或不相容的型別說明；
-變數無初值；
-變數初始化或省缺值有錯；
-不正確的變數名（拼錯或不正確地截斷）；
-出現上溢、下溢和地址異常。
（3）邊界條件測試：邊界條件測試是單元測試中最重要的一項任務。眾所周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。邊界條件測試是一項基礎測試，也是後面系統測試中的功能測試的重點，邊界測試執行的較好，可以大大提高程式健壯性。
（4）模組中所有獨立路徑測試：在模組中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模組中每條語句至少執行一次。測試目的主要是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。具體做法就是程式設計師逐條除錯語句。常見的錯誤包括：
-誤解或用錯了算符優先順序；
-混合型別運算；
-變數初值錯；
-精度不夠；
-表示式符號錯。
比較判斷與控制流常常緊密相關，測試時注意下列錯誤：
-不同資料型別的物件之間進行比較；
-錯誤地使用邏輯運算子或優先順序；
-因計算機表示的侷限性，期望理論上相等而實際上不相等的兩個量相等；
-比較運算或變量出錯；
-迴圈終止條件或不可能出現；
-迭代發散時不能退出；
-錯誤地修改了迴圈變數。
模組的各條錯誤處理通路測試：程式在遇到異常情況時不應該退出，好的程式應能預見各種出錯條件，並預設各種出錯處理通路。如果使用者不按照正常操作，程式就退出或者停止工作，實際上也是一種缺陷，因此單元測試要測試各種錯誤處理路徑。一般這種測試著重檢查下列問題：
-輸出的出錯資訊難以理解；
-記錄的錯誤與實際遇到的錯誤不相符；
-在程式自定義的出錯處理段執行之前，系統已介入；
-異常處理不當；
-錯誤陳述中未能提供足夠的定位出錯資訊。
如何理解強度測試？
強度測試是為了確定系統在最差工作環境的工作能力,也可能是用於驗證在標準工作壓力下的各種資源的最下限指標。
它和壓力測試的目標是不同的,壓力測試是在標準工作環境下,不斷增加系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峰值),而強度測試則是在非標準工作環境下,甚至不斷人為降低系統工作環境所需要的資源,如網路頻寬,系統記憶體,資料鎖等等,以測試系統在資源不足的情況下的工作狀態,通過強度測試,可以確定本系統正常工作的最差環境.
強度測試和壓力測試的測試指標相近,大多都是與時間相關的指標,如併發量(吞吐量),延遲(最大\最小\平均)以及順序指標等
強度測試需要對系統的結構熟悉,針對系統的特徵設計強度測試的方法
如何理解壓力、負載、效能測試測試？
效能測試是一個較大的範圍，實際上效能測試本身包含了效能、強度、壓力、負載等多方面的測試內容。
壓力測試是對伺服器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的使用者數量、或者幾個使用者進行大資料量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是效能測試的重要部分。100個使用者對系統進行連續半個小時的訪問可以看作壓力測試，那麼連續訪問8個小時就可以認為負載測試，1000個使用者連續訪問系統1個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體效能的高度上來對系統進行測試。
什麼是系統瓶頸？
瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足使用者的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。
嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足使用者需求。在使用者極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響使用者工作。
因此我們測試系統瓶頸主要是實現下面兩個目的：
-發現“表面”的瓶頸。主要是模擬使用者的操作，找出使用者極限使用系統時的瓶頸，然後解決瓶頸，這是效能測試的基本目標。
-發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮使用者在將來擴充套件系統或者業務發生變化時，系統能夠適應變化。滿足使用者目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體生命週期能夠不斷適應使用者的變化，或者通過簡單擴充套件系統就可以適應新的變化。
文件測試主要包含什麼內容？
在國內軟體開發管理中，文件管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文件測試也就不足為奇了。要想給使用者提供完整的產品，文件測試是必不可少的。文件測試一般注重下面幾個方面：
文件的完整性：主要是測試文件內容的全面性與完整性，從總體上把握文件的質量。例如使用者手冊應該包括軟體的所有功能模組。
描述與軟體實際情況的一致性：主要測試軟體文件與軟體實際的一致程度。例如使用者手冊基本完整後，我們還要注意使用者手冊與實際功能描述是否一致。因為文件往往跟不上軟體版本的更新速度。
易理解性：主要是檢查文件對關鍵、重要的操作有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明瞭。
文件中提供操作的例項：這項檢查內容主要針對使用者手冊。對主要功能和關鍵操作提供的應用例項是否豐富，提供的例項描述是否詳細。只有簡單的圖文說明，而無例項的使用者手冊看起來就像是軟體介面的簡單拷貝，對於使用者來說，實際上沒有什麼幫助。
印刷與包裝質量：主要是檢查軟體文件的商品化程度。有些使用者手冊是簡單列印、裝訂而成，過於粗糙，不易於使用者儲存。優秀的文件例如使用者手冊和技術白皮書，應提供商品化包裝，並且印刷精美。
配置和相容性測試的區別是什麼？
配置測試的目的是保證軟體在其相關的硬體上能夠正常執行，而相容性測試主要是測試軟體能否與不同的軟體正確協作。
配置測試的核心內容就是使用各種硬體來測試軟體的執行情況，一般包括：
（1）軟體在不同的主機上的執行情況，例如Dell和Apple；
（2）軟體在不同的元件上的執行情況，例如開發的撥號程式要測試在不同廠商生產的Modem上的執行情況；
（3）不同的外設；
（4）不同的介面；
（5）不同的可選項，例如不同的記憶體大小；
相容性測試的核心內容：
（1）測試軟體是否能在不同的作業系統平臺上相容；
（2）測試軟體是否能在同一作業系統平臺的不同版本上相容；
（3）軟體本身能否向前或者向後相容；
（4）測試軟體能否與其它相關的軟體相容；
（5）資料相容性測試，主要是指資料能否共享；
配置和相容性測試通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等。具體進行時仍然按照測試用例來執行。
軟體文件測試主要包含什麼？
隨著軟體文件系統日益龐大，文件測試已經成為軟體測試的重要內容。文件測試物件主要如下：
-包裝文字和圖形；
-市場宣傳材料、廣告以及其它插頁；
-授權、註冊登記表；
-終端使用者許可協議；
-安裝和設定嚮導；
-使用者手冊；
-聯機幫助；
-樣例、示範例子和模板；
-……
文件測試的目的是提高易用性和可靠性，降低支援費用，因為使用者通過文件就可以自己解決問題。因文件測試的檢查內容主要如下：
-讀者物件——主要是文件的內容是否能讓該級別的讀者理解；
-術語——主要是檢查術語是否適合讀者；
-內容和主題——檢查主題是否合適、是否丟失、格式是否規範等；
-圖示和螢幕抓圖——檢查圖表的準確度和精確度；
-樣例和示例——是否與軟體功能一致；
-拼寫和語法；
-文件的關聯性——是否與其它相關文件的內容一致，例如與廣告資訊是否一致；
文件測試是相當重要的一項測試工作，不但要給予充分的重視，更要要認真的完成，象做功能測試一樣來對待文件測試。
沒有產品說明書和需求文件地情況下能夠進行黑盒測試嗎？
這個問題是國內測試工程師經常遇到的問題，根源就是國內軟體開發文件管理不規範，對變更的管理方法就更不合理了。實際上沒有任何文件的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入瞭解測試物件、理解軟體功能，進而發現缺陷。
在這種做法基本上把軟體當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作專案的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。
##3 測試中的“殺蟲劑怪事”是指什麼？
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測試技術》第二版中提出。用於描述測試人員對同一測試物件進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本原因就是測試人員對測試軟體過於熟悉，形成思維定勢。
為了克服這種現象，測試人員需要不斷編寫新的測試程式或者測試用例，對程式的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟體，剛剛進來的新手往往能發現一些意想不到的問題。
在配置測試中，如何判斷髮現的缺陷是普通問題還是特定的配置問題？
在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。因此判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷。
需要注意的是，配置問題可以在一大類配置中出現。例如，撥號程式可能在所有的外接Modem中都存在問題，而內建的Modem不會有任何問題。
完全測試程式是可能的嗎？
軟體測試初學者可能認為拿到軟體後需要進行完全測試，找到全部的軟體缺陷，使軟體“零缺陷”釋出。實際上完全測試是不可能的。主要有以下一個原因：
-完全測試比較耗時，時間上不允許；
-完全測試通常意味著較多資源投入，這在現實中往往是行不通的；
-輸入量太大，不能一一進行測試；
-輸出結果太多，只能分類進行驗證；
-軟體實現途徑太多；
-軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同；
因此測試的程度要根據實際情況確定。
軟體測試的風險主要體現在哪裡？
我們沒有對軟體進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程式設計師為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式釋出前這些程式碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因為交付後才被客戶發現。
因此，我們要儘可能的選擇最合適的測試量，把風險降低到最小。
發現的缺陷越多，說明軟體缺陷越多嗎？
這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個後，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：
-程式碼複用、拷貝程式碼導致程式設計師容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反覆拷貝同一程式碼意味可能也複製了缺陷。
-程式設計師比較勞累是可以導致某些連續編寫的功能缺陷較多。程式設計師加班是一種司空見慣的現象，因此體力不只時容易編寫一些缺陷較多的程式。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。
“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟體編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程式就可以了。
所有的軟體缺陷都能修復嗎？所有的軟體缺陷都要修復嗎？
從技術上講，所有的軟體缺陷都是能夠修復的，但是沒有必要修復所有的軟體缺陷。測試人員要做的是能夠正確判斷什麼時候不能追求軟體的完美。對於整個專案團隊，要做的是對每一個軟體缺陷進行取捨，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：
-沒有足夠的時間資源。在任何一個專案中，通常情況下開發人員和測試人員都是不夠用的，而且在專案中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。
-有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以後升級中進行修復。
-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以後有時間時考慮再處理。
最後要說的是，缺陷是否修改要由軟體測試人員、專案經理、程式設計師共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。
軟體測試人員就是QA嗎？
軟體測試人員的職責是儘可能早的找出軟體缺陷，確保得以修復。而質量保證人員（QA）主要職責是建立或者制定標準和方法，提高促進軟體開發能力和減少軟體缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作物件。
軟體測試和質量是相輔相成的關係，都是為了提高軟體質量而工作。
如何減少測試人員跳槽帶來的損失？
在IT行業裡跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失。測試隊伍也無疑會面臨跳槽的威脅，作為測試經理管理者，只有從日常工作中開始做起，最能最大限度的減少損失。建議我們從以下兩個方面做起：
-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。
-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業。因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯絡起來，為員工設定合理發展規劃並付諸實現。不過這項要求做起來比較，要有比較好的企業文化為依託.
以windows對檔案的複製粘帖功能為例，儘可能多地寫出測試思路
1、 基本功能測試： 檔案的複製貼上功能，首先關鍵字“檔案”，檔案有不同的分類（圖片、視訊、音訊、文件等），每個分類又有不同的型別（文件型別：txt doc execl pdf等），每個檔案又有不同的大小，而且檔案還有很多許可權，是不是隱藏，是不是隻是管理員可執行。選擇不同分類的不同型別，不同大小的檔案做測試資源。比如：文件型別裡面txt檔案可以分為 1.KB的txt檔案、1MB的txt檔案、1GB的txt檔案。。。。
下一個關鍵字 複製貼上 複製有多種方式 右擊選擇、Ctrl+C、 拖動複製，對應貼上也有各種方式。然後從哪複製，貼上到哪，比如 可以有本機硬碟、行動硬碟、優盤、記憶體卡、軟盤、光碟、連線手機儲存，複製到網路地址等等。複製粘貼後檔案是不是可用，檔案許可權是不是有變化。複製過去容量不夠怎麼處理？複製過後有重名檔案怎麼處理？複製過程中取消、關機、拔優盤怎麼處理？複製過程能不能執行檔案？
2.效能測試：複製貼上功能效能怎麼樣？複製檔案的速度可不可以接受？同時複製多個檔案是不是可以完成?複製檔案過程中佔用CPU資源大不大，耗電量大不大？
3.相容性測試 Windows XP, Windows 7, Windows 8 , Windows 8.1, Windows 10等各種windos版本是不是都支援這個功能。
4.互動測試; 複製貼上檔案時，使用windows儲存的其他功能是否有影響？比如播放本地的音訊、視訊、等同時複製檔案是不是有影響。一邊複製，一邊貼上是不是有影響。
貼上的穩定性：貼上完了大小會不會變化，內容格式會不會變化，貼上不上，誤操作以後還能不能找到複製的內容等
貼上的安全性：貼上的內容貼上好了以後會不會存在別處洩露等
2.效能測試：（1）時間：複製貼上的響應時間？頁面的顯示時間？（2）負載：多次重複進行復制貼上是否有異常？複製貼上容量很大的一個或多個檔案是否能承受？（3）強度：保證容量足夠的條件下，分別複製貼上50GB，100GB，500GB，…大小的檔案，看什麼時候出現失敗，失敗後的表現，能否重新正常複製貼上50G？（4）容量：在不同CPU資源條件下，持續複製貼上5分鐘，最多能複製貼上多少容量的檔案？
5.介面測試：複製貼上時進度條的顯示介面是否與系統的設計風格一致？顯示介面是否有文字性錯誤？顯示介面的布是否合理？介面上的按鈕是否可用（如：是否可以選擇中止？是否可用最小化？）
6.本地化測試：不同語言環境下的顯示正常
7.輔助性測試：高對比度下能否顯示正常
連結：https://www.nowcoder.com/questionTerminal/ad274cafadf64222bb8805df45828741?orderByHotValue=1&pos=3
來源：牛客網
1 、複製貼上方法
快捷鍵測試：測試 Ctrl+C ，是否正確執行復制、 Ctrl+v 是否支援貼上功能
右鍵測試：檢視複製貼上功能是否正確執行；
在 cmd 命令列中使用複製貼上命令；
2 、檔案大小測試
原始檔為空， 0 位元組；
原始檔正常大小；
原始檔為超大檔案： **G/ 等；
3 、檔案格式
測試各種檔案格式下是否正常複製貼上：如：圖片、聲音、視訊、壓縮檔案、辦公檔案： word\excel\ppt 等、二進位制檔案；
測試共享檔案、隱藏檔案
4 、複製和貼上檔案路徑
在系統不同檔案路徑下複製貼上，
測試相對路徑和絕對路徑下檔案複製貼上；
測試資料夾下和另一個不同資料夾複製貼上；
測試不同 C\D\E 盤之間；
測試複製貼上至：行動硬碟、 U 盤、讀卡器以及其它外部儲存裝置；
5 、異常測試
測試被損壞檔案、不完整檔名稱、禁止複製和貼上的檔案、超出規定大小檔案等；
同名稱檔案測試是否提醒替換或覆蓋；
6 、相容性
測試不同作業系統之間、不同應用程式（如： QQ ）；
7 、效能測試：
測試複製貼上可支援最大檔案大小；複製貼上操作的相應速度、執行完畢時間；
一次支援不同格式的檔案同時操作；
支援大量檔案同時複製貼上；
登入介面測試用例設計
一、介面測試點：
1、介面的設計風格是否與UI的設計風格統一；
2、介面中的文字簡潔易懂；
3、介面中沒有錯別字；
二、使用者名稱與密碼在輸入時，要考慮：
1、正確的使用者名稱與正確的密碼；
2、正確的使用者名稱與錯誤的密碼；
3、錯誤的使用者名稱與正確的密碼；
4、錯誤的使用者名稱與錯誤的密碼；
5、空的使用者名稱和空的密碼；
6、正確的使用者名稱和空的密碼；
7、空的使用者名稱和正確的密碼；
8、使用者名稱的前/中/後含有空格；
9、密碼的前/中/後含有空格；
10、使用者名稱與密碼使用的字元範圍及位數限制的測試（等價類及邊界值，會用到強制的複製與貼上來實現不允許輸入的字元，以及一些保留字的測試）；
11、牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），重新整理或換一個按鈕是否好用；
三、安全性測試：
1、密碼是否隱蔽顯示；
3、不能直接輸入，就copy，是否資料檢驗出錯；
還要準確定位每一個輸入框的功能，每一種錯誤情況下，出現的錯誤提示要準確或者合適。
四、相容性測試：
1.不同瀏覽器測試
2.瀏覽器不同版本測試
12
五、其他測試點：
1、輸入框之間考慮tab鍵是否支援；
2、登入按鈕要考慮回車鍵是否支援；
3、取消後的預設位置（一般為空白的使用者名稱輸入框）；
4、登入後的跳轉頁面是否正確（一般為首頁）；
5、要考慮多次點選登入和取消按鈕的介面反應；
6、考慮是否支援多使用者在同一機器上登入；
7、考慮一使用者在多臺機器上登入；
8、登入頁面中的註冊等連結是否正確
軟體測試筆試題
選擇題
一、數量關係
1、甲乙2人比賽爬樓梯，已知每層樓梯相同，速度不變，當甲到3層時，乙到2層，照這樣計算，當甲到9層時，乙到( D )層
A.5 B.6 C.7 D.8
2、有一份選擇題試卷共6個小題，其得分標準是：一道小題答對得8分，答錯得0分，不答得2分，某位同學得了20分，則他( D )
A.至多答對一道題 B.至少有三個小題沒答 C.至少答對三個小題 D.答錯兩小題
3、有隻蝸牛要從一口井底爬出來。井深20尺。蝸牛每天白天向上爬3尺，晚上向下滑2尺。請問該蝸牛幾天才能爬出井口? （A）
A.20 B.19 C.18 D.15
4、下列哪一個計算結果最接近1.25×8的值?A
A.3.3×3 B. 1.7×6 C. 1.6×6 D. 2.1×5
軟體測試工程師筆試題目
一．選擇題
1、 系統測試使用（ C ）技術, 主要測試被測應用的高階互操作性需求, 而無需考慮被測試應用的內部結構。
A、 單元測試 B、 整合測試 C、 黑盒測試 D、白盒測試
2、單元測試主要的測試技術不包括（B ）。
A、 白盒測試 B、 功能測試
C、 靜態測試 D、 以上都不是
3、（A ）的目的是對最終軟體系統進行全面的測試，確保最終軟體系統滿足產品需求並且遵循系統設計。
A、 系統測試 B、 整合測試
C、 單元測試 D、 功能測試
4、如果一個產品中次嚴重的缺陷基本完成修正並通過複測，這個階段的成品是（ A ）。
A、 Alpha版 B、Beta版
C、正版 D、以上都不是
5、自底向上法需要寫（A ）。
A、 驅動程式 B、 樁程式 C、驅動程式和樁程式 D、 .以上都不是
6、測試ATM取款功能，已知取款數只能輸入正整數，每次取款數要求是100的倍數且不能大於500，下面哪個是正確的無效等價類（C）
A、（0，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+∞）;
B、（500，+∞）
C、（500，+∞）、任意大於0小於500的非100倍數的整數；
D、（-∞，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+∞）;
7、因果圖/判定表工程方法在以下那種情況下不適用（C）
A、輸入輸出明確，或輸入輸出因果關係明確的情況下
B、被分析的特性或功能點複雜，輸入專案很多的情況下
C、系統輸入之間相互約束多，需要做大範圍的組合測試情況下
D、系統輸入之間基本沒有相互聯絡
8、以下說法不正確的是（D）
A、測試原始需要明確了產品將要實現了什麼
B、產品測試規格明確了測試設計內容
C、測試用例明確了測試實現內容
D、以上說法均不正確
9、可測試性中，有關係統可觀察性的理解，下面說法那個是錯誤的（ B）
A、系統所有的輸出結果可觀察，錯誤輸出易於識別；
B、系統執行狀態和內部處理的過程資訊可觀察；
C、系統內部變數名及其取值可觀察；
D、系統內部重要物件的狀態和屬性可觀察；
E、系統內部重要的操作的處理時間可觀察；
F、系統內部重要的資源的佔用情況及單個資源的建立、保持、釋放過程可觀察
10、測試指令碼的編寫規範強調：（ABCD ）
A、可讀行 B、可重用性 C、可維護性 D、可移植性
11、當繼承某個特性是，通常會從哪些角度對該特性進行測試分析？（AC ）
A、失效影響度 B、成熟度 C、繼承方式 D、使用者原始需求
12、從下列關於軟體測試的敘述中，選出正確的敘述（CD）
A、用黑盒法測試時，測試用例是根據程式內部邏輯設計的
B、測試的目的是驗證該軟體已正確的實現了使用者的要求
C、發現錯誤多的程式塊，殘留在模組中的錯誤也多
D、測試設計時，應充分考慮異常的輸入情況
13、軟體驗收測試的合格通過準則是：（ABCD）
A． 軟體需求分析說明書中定義的所有功能已全部實現，效能指標全部達到要求。
B． 所有測試項沒有殘餘一級、二級和三級錯誤。
C． 立項審批表、需求分析文件、設計文件和編碼實現一致。
D． 驗收測試工件齊全。
14、軟體測試計劃評審會需要哪些人員參加？（ABCD）
A．專案經理
B．SQA 負責人
C．配置負責人
D．測試組
15．測試設計員的職責有：（BC ）
A．制定測試計劃
B．設計測試用例
C．設計測試過程、指令碼
D．評估測試活動
16．軟體實施活動的進入準則是：（ABC）
A．需求工件已經被基線化
B．詳細設計工件已經被基線化
C．構架工件已經被基線化
D．專案階段成果已經被基線化
二、 判斷題
1.軟體測試的目的是儘可能多的找出軟體的缺陷。（ Y）
2.負載測試是驗證要檢驗的系統的能力最高能達到什麼程度。（N ）
3.測試人員要堅持原則，缺陷未修復完堅決不予通過。（N）
4.自動化測試能比手工測試發現更多的缺陷（N）
-
錯誤猜測法基於這樣一種假設，以前犯過的錯誤，以後同樣會犯，我犯過的錯誤別人同樣會犯，前人犯過的錯誤，後人同樣會犯（N）
-
軟體測試中的二八原則暗示著測試發現的錯誤中的80%很可能起源於程式模組的20%（Y）
-
某WEB系統設計中，使用者點選“退出”按鈕從系統中退出，介面回到初始登陸介面。此時不關閉視窗，使用瀏覽器的回退功能，可以回到之前的使用者介面，繼續進行使用者操作。這種合適的人性化設計，恩那個避免使用者誤點選退出按鈕後重新登入的繁瑣操作；這種說法是否正確（N）
8.在確定性能測試指標值時，參考的國際標準、國標、運營商規範中對此要求並不一樣，可以視情況選擇有利於我們的指標值，但必須要比競爭對手高，這樣才有利於市場競爭力（N）
9.測試執行時，應該對每一個測試結果做全面的檢查，包括日誌，這種說法是否正確（ N）
筆試題有三份，分別考python、SQL、java和計算機網路Linux命令等基礎知識。
python部分
1、選擇題
第1題，下列選項中，python不支援的資料型別有（B）
python中沒有字元型別，只有字串型別string
A、int B、char C 、float D、dictionary
第2題，下列Python語句正確的是（*D*）
考簡單的python語句是否有錯。按照語法就可以了
A. min = x if x < y else y B. max = x > y ? x : y
C. if(x > y) print x D. while True :pass （while後面加分號，pass語句空語句，不做任何事情）
2、簡答題
一、a = 1，b = 2 。不用中間變數交換a和b的值（同理，交換列表也一樣）
a,b = b,a
二、s ="ajldjlajfdljfddd"，去重並從小到大排序輸出 "adfjl"
方法1
# 由於資料型別set本身具有無序，唯一值的特性，可以用內建函式set對字串和列表進行去重
s ="ajldjlajfdljfddd"
s1 = set(s) #去重
s2 = list(s1) #轉為列表
s2.sort() #排序，注意沒有返回值
s3 = ''.join(s2) #列表轉字串
print(s3) #輸出
方法2
s ="ajldjlajfdljfddd"
s1 = set(s) #去重
s2 = list(s1) #轉為列表
s3 = sorted(s2) #排序
s4 = ''.join(s3) #列表轉字串
print(s4) #輸出
方法3，一行程式碼搞掂，熟悉的話應該很容易寫。
s ="ajldjlajfdljfddd"
s1 =''.join(sorted(list(set(s))))
print(s1)
三、用至少三種方法從字串"hello boy<[www.doiido.com]>byebye"中提取字串'www.doiido.com'
①使用切片法擷取字串。切片語法：[起始：結束：步長]，****步長預設為1，可為負數，切片區間左閉右開
str = "hello boy<[www.doiido.com]>byebye"
print(str[11:25:1]) #第一個w第11位，最後m第24位，注意切片區間左閉右開
輸出：
www.doiido.com
②使用split函式。
語法：str.split(str="", num=string.count(str))[n]
引數：str預設為空格
num為分割次數
[n]表示取第n個分片，可不寫則不取，下標同樣從零開始
返回值：分割後的字串列表（列表元素=分割次數num+1）
思路：
1. 網址在[]裡面，用第一個 [ 將字串分隔成列表 str.split("[")
['hello boy<', 'www.doiido.com]>byebye']
2. 再取列表裡的索引為1的元素 str.split("[")[1]
www.doiido.com]>byebye
3. 再用分隔符]將列表分隔開 str.split("[")[1].split("]")
['www.doiido.com', '>byebye']
4. 再取第一個元素 str.split("[")[1].split("]")[0]
www.doiido.com
程式碼：
str = "hello boy<[www.doiido.com]>byebye"
print(str.split("[")[1].split("]")[0])#是先輸出[後的內容 以及]前的內容，下標從0開始
輸出：
www.doiido.com
③使用replace函式
*語法：str.replace(old, new[, max])
引數
1.old -- 這是要進行更換的舊子串。
2.new -- 這是新的子串，將取代舊的子字串。
3.max -- 如果這個可選引數max值給出，就只替代max個，除max個外若還有old值，也不替代。
返回值：把新的子串取代舊的子串後，形成的新的字串。
注意：並不返回原字串裡，請賦給一個新的string。*
思路：
1. 網址在w之前的字串用空格替換掉 str.replace('hello boy<[','')
www.doiido.com]>byebye
2. 網址在m後面的字串用空格替換掉 str1.replace(']>byebye','')
www.doiido.com
程式碼：
str = "hello boy<[www.doiido.com]>byebye"
str1 = str.replace('hello boy<[','')#刪除網址之前的字串
print(str1.replace(']>byebye',''))#刪除網址之後的字串
輸出：
www.doiido.com
④目前到這裡。。。可能還有其他的函式樓主還沒想到
四、讀取testA.txt的內容，去掉檔案中的空格，寫入到testB.txt中。
語法：
1、開啟檔案或者新建一個檔案（不指定訪問方式，預設只讀方式開啟檔案）
2、讀/寫資料
3、關閉檔案
程式碼：
f1 = open('testA.txt','w') #新建testA.txt
f1.write('I am Quality Testing Engineer')#往testA.txt寫資料
f1.close()#關閉檔案
f2 = open('testA.txt','r')#讀模式
content = f2.read()#讀testA.txt資料
str = content.replace(" ","")#把資料中的空格全部去掉
f3 = open('testB.txt','w')#新建testB.txt
f3.write(str)#往testB.txt寫資料
f2.close()#關閉檔案
f3.close()#關閉檔案
看看執行後py檔案目錄下的結果：
成功。注意讀之前一定要關閉檔案，否則讀取會失敗。可以刪除f1.close()這一行程式碼試一試（執行後testB.txt內容為空）。
五、閱讀下面的程式碼，寫出A0，A1至An的值。
A0 = dict(zip(('a','b','c','d','e'),(1,2,3,4,5))) #先zip返回物件，再dict轉字典
A1 = range(10) #即range(0,10,1)
A2 = [i for i in A1 if i in A0] #即[i for i in range(10) if i in A0]，A0與A1交集
A3 = [A0[s] for s in A0] #即[A0[s] for s in A0.keys()]，A0[s]字典知道鍵通過下標取值
A4 = [i for i in A1 if i in A3] #即 既滿足A1，又滿足A3，A1和A3交集
A5 = {i:i*i for i in A1} #即{i:i*i for i in range(10)}，字典鍵值對
A6 = [[i,i*i] for i in A1] #即[[i:i*i] for i in range(10)]，列表元素又是列表
print('A0:',A0)
print('A1:',A1)
print('A2:',A2)
print('A3:',A3)
print('A4:',A4)
print('A5:',A5)
print('A6:',A6)
話不多說，馬上看看結果
A0: {'a': 1, 'b': 2, 'c': 3, 'd': 4, 'e': 5}
A1: range(0, 10)
A2: []
A3: [1, 2, 3, 4, 5]
A4: [1, 2, 3, 4, 5]
A5: {0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25, 6: 36, 7: 49, 8: 64, 9: 81}
A6: [[0, 0], [1, 1], [2, 4], [3, 9], [4, 16], [5, 25], [6, 36], [7, 49], [8, 64], [9, 81]]
分析：考察列表推導式，詳情見Python 列表推導式
A0：zip函式作用，dict函式作用。#先zip返回物件，再dict轉字典
A1：range函式作用。#即range(0,10,1)
A2：for if 用法。#即[i for i in range(10) if i in A0]，A0與A1交集
A3：取字典元素，for 用法。#即[A0[s] for s in A0.keys()]，A0[s]字典知道鍵通過下標取值
A4：同A2。#即 既滿足A1，又滿足A3，A1和A3交集
A5：for 輸出字典元素。#即{i:i*i for i in range(10)}，字典鍵值對
A6：for 輸出列表元素。#即[[i:i*i] for i in range(10)]，列表元素又是列表
後面對這些函式單獨研究。
SQL部分
筆試的時候是看一張成績表，包括姓名，課程，成績，學號。三個問題，第一，查詢某科成績大於80分的學生。二，學生成績統計並排名。三，展示一個表格，增加一列，展示每一個學生低於60分就算不及格的，高於60算及格。
具體題目忘記了，從網上找了個相似的練習下。工作上用的比較多的是查詢，其它的畢竟好幾年沒複習了，早就忘了。
成績表資料如下：
一、查詢每個人的總成績並按從高到低排名(要求顯示欄位：姓名，總成績，學號)
考察聚合函式sum()，用於返回數值列的總數（總額）。。group by 分組（配合聚合函式使用），排序用order by，預設從小到大，加個desc，從大到小。沒有where子句查詢所有記錄
select name,SUM(score),stid from dbo.stuscore
group by name,stid
order by SUM(score) desc;
執行結果（一塊複製進來了）（Navicat命令列介面，輸入sql語句按回車enter鍵）
mysql> select name,SUM(score),stid from dbo.stuscore
group by name,stid
order by SUM(score) desc;
+------+------------+------+
| name | SUM(score) | stid |
+------+------------+------+
| 張三 | 218 | 1 |
| 李四 | 200 | 2 |
| 王五 | 191 | 3 |
+------+------------+------+
3 rows in set (0.03 sec)
二、查詢每個人單科最高成績(要求顯示欄位: 學號，姓名，課程，最高成績)
考察派生表（需要別名），max()函式，用於返回一列中的最大值，NULL 值不包括在計算中。先查學號與最高成績，再把學號，姓名，課程，最高成績查出來
select table1.stid,table1.name,table1.subject,table1.score from stuscore table1,
(select stid,max(score) as maxscore from stuscore group by stid) table2
where table1.stid=table2.stid and table1.score=table2.maxscore;
先查括號裡面的
mysql> select stid,max(score) as maxscore from stuscore group by stid;
+------+----------+
| stid | maxscore |
+------+----------+
| 1 | 89 |
| 2 | 80 |
| 3 | 91 |
+------+----------+
3 rows in set (0.03 sec)
結果，再把相關資訊列出來
mysql> select table1.stid,table1.name,table1.subject,table1.score from stuscore table1,
(select stid,max(score) as maxscore from stuscore group by stid) table2
where table1.stid=table2.stid and table1.score=table2.maxscore;
+------+------+---------+-------+
| stid | name | subject | score |
+------+------+---------+-------+
| 1 | 張三 | 數學 | 89 |
| 2 | 李四 | 英語 | 80 |
| 3 | 王五 | 數學 | 91 |
+------+------+---------+-------+
3 rows in set (0.04 sec)
三、查詢每個人的平均成績（要求顯示欄位: 學號，姓名，平均成績）
考察avg()函式，用於返回數值列的平均值，NULL 值不包括在計算中。和分組group by用法
select name,stid,avg(score) from dbo.stuscore
group by name,stid;
執行結果
mysql> select name,stid,avg(score) from dbo.stuscore
group by name,stid;
+------+------+------------+
| name | stid | avg(score) |
+------+------+------------+
| 張三 | 1 | 72.6667 |
| 李四 | 2 | 66.6667 |
| 王五 | 3 | 63.6667 |
+------+------+------------+
3 rows in set (0.04 sec)
四、查詢各門課程成績最好的學生(要求顯示欄位: 學號，姓名，科目，成績)
類似第二題。第一步查詢把學號 換成科目
select table1.stid,table1.name,table1.subject,table1.score from stuscore table1,
(select subject,max(score) as maxscore from stuscore group by subject) table2
where table1.subject=table2.subject and table1.score=table2.maxscore;
執行結果
mysql> select table1.stid,table1.name,table1.subject,table1.score from stuscore table1,
(select subject,max(score) as maxscore from stuscore group by subject) table2
where table1.subject=table2.subject and table1.score=table2.maxscore;
+------+------+---------+-------+
| stid | name | subject | score |
+------+------+---------+-------+
| 2 | 李四 | 語文 | 70 |
| 2 | 李四 | 英語 | 80 |
| 3 | 王五 | 數學 | 91 |
+------+------+---------+-------+
3 rows in set (0.04 sec)
五、查詢各門課程成績最好的兩位學生(要求顯示欄位: 學號，姓名，科目，成績)
服了，還沒找到更好的方法，將就下。按照最快的思路還沒除錯好，用top應該更快（找到科目相同的，成績的，前兩列）
SELECT t1.name,t1.SUBJECT,t1.score FROM stuscore t1 WHERE(SELECT COUNT(*) FROM stuscore t2
WHERE t1.SUBJECT=t2.SUBJECT AND t2.score>=t1.score)<=2
order by subject desc;
執行結果
mysql> SELECT t1.name,t1.SUBJECT,t1.score FROM stuscore t1 WHERE
(
SELECT COUNT(*) FROM stuscore t2 WHERE
t1.SUBJECT=t2.SUBJECT AND t2.score>=t1.score
)<=2 order by subject desc;
+------+---------+-------+
| name | SUBJECT | score |
+------+---------+-------+
| 李四 | 語文 | 70 |
| 王五 | 語文 | 60 |
| 張三 | 英語 | 70 |
| 李四 | 英語 | 80 |
| 張三 | 數學 | 89 |
| 王五 | 數學 | 91 |
+------+---------+-------+
6 rows in set (0.06 sec)
六、查詢結果統計如下
| 學號 | 姓名 | 語文 | 數學 | 英語 | 總分 | 平均分 |
|---|---|---|---|---|---|---|
考察case when函式。sum(case ...then... else 0 end)固定用法
select stid 學號,name 姓名,sum(case when subject='語文' then score else 0 end )as 語文,
sum(case when subject='數學' then score else 0 end )as 數學,
sum(case when subject='英語' then score else 0 end )as 英語,
SUM(score)總分,avg(score)平均分 from stuscore
group by stid,name order by 總分;
執行結果
mysql> select stid 學號,name 姓名,sum(case when subject='語文' then score else 0 end )as 語文,
sum(case when subject='數學' then score else 0 end )as 數學,
sum(case when subject='英語' then score else 0 end )as 英語,
SUM(score)總分,avg(score)平均分 from stuscore
group by stid,name order by 總分;
+------+------+------+------+------+------+---------+
| 學號 | 姓名 | 語文 | 數學 | 英語 | 總分 | 平均分 |
+------+------+------+------+------+------+---------+
| 3 | 王五 | 60 | 91 | 40 | 191 | 63.6667 |
| 2 | 李四 | 70 | 50 | 80 | 200 | 66.6667 |
| 1 | 張三 | 59 | 89 | 70 | 218 | 72.6667 |
+------+------+------+------+------+------+---------+
3 rows in set (0.05 sec)
七、查詢各門課程的平均成績（要求顯示欄位：課程，平均成績）
考察avg函式，group by 分組
select subject,avg(score) from stuscore
group by subject;
執行結果
mysql> select subject,avg(score) from stuscore
group by subject;
+---------+------------+
| subject | avg(score) |
+---------+------------+
| 數學 | 76.6667 |
| 英語 | 63.3333 |
| 語文 | 63.0000 |
+---------+------------+
3 rows in set (0.03 sec)
八、查詢數學成績的排名（要求顯示欄位：學號，姓名，成績，排名）
考察count用法，order by排序，注意：比較的次數+1 = 排名
select stid,name,score,
(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次 from stuscore t2
where subject='數學' order by score desc;
--註釋：排序，比較大小，比較的次數+1 = 排名。
執行結果
mysql> select stid,name,score,
(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次 from stuscore t2
where subject='數學' order by score desc;
+------+------+-------+------+
| stid | name | score | 名次 |
+------+------+-------+------+
| 3 | 王五 | 91 | 1 |
| 1 | 張三 | 89 | 2 |
| 2 | 李四 | 50 | 3 |
+------+------+-------+------+
3 rows in set (0.13 sec)
九、查詢數學成績在2-3名的學生（要求顯示欄位：學號，姓名，科目，成績）
有很多種方法，下面只是其中的一種，順著第八題做下來
select t3.* from (
select stid,name,subject,score,
(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次 from
stuscore t2 where subject='數學') t3
where t3.名次 between 2 and 3 order by t3.score desc;
執行結果
mysql> select t3.* from (
select stid,name,subject,score,
(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次 from
stuscore t2 where subject='數學') t3
where t3.名次 between 2 and 3 order by t3.score desc;
+------+------+---------+-------+------+
| stid | name | subject | score | 名次 |
+------+------+---------+-------+------+
| 1 | 張三 | 數學 | 89 | 2 |
| 2 | 李四 | 數學 | 50 | 3 |
+------+------+---------+-------+------+
2 rows in set (0.49 sec)
十、查詢李四的數學成績的排名
方法很多，下面列出其中的一種，順著第八題做
select stid,name,subject,score,(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次
from stuscore t2 where subject='數學' and name = '李四' order by score desc;
執行結果
mysql> select stid,name,subject,score,(select count(*) from stuscore t1 where subject ='數學' and t1.score > t2.score)+1 as 名次
from stuscore t2 where subject='數學' and name = '李四' order by score desc;
+------+------+---------+-------+------+
| stid | name | subject | score | 名次 |
+------+------+---------+-------+------+
| 2 | 李四 | 數學 | 50 | 3 |
+------+------+---------+-------+------+
1 row in set (0.05 sec)
十一、查詢統計如下
| 課程 | 不及格（0-59）個 | 良（60-80）個 | 優（81-100）個 |
|---|---|---|---|
考察case when
select subject 科目,sum(case when score between 0 and 59 then 1 else 0 end) as 不及格,
sum(case when score between 60 and 80 then 1 else 0 end) as 良,
sum(case when score between 81 and 100 then 1 else 0 end) as 優秀 from stuscore
group by subject;
執行結果
mysql> select subject 科目,sum(case when score between 0 and 59 then 1 else 0 end) as 不及格,
sum(case when score between 60 and 80 then 1 else 0 end) as 良,
sum(case when score between 81 and 100 then 1 else 0 end) as 優秀 from stuscore
group by subject;
+------+--------+----+------+
| 科目 | 不及格 | 良 | 優秀 |
+------+--------+----+------+
| 數學 | 1 | 0 | 2 |
| 英語 | 1 | 2 | 0 |
| 語文 | 1 | 2 | 0 |
+------+--------+----+------+
3 rows in set (0.06 sec)
十二、查詢統計如下
數學: 張三(50分),李四(90分),王五(90分),趙六(76分)
查了下答案，先貼上
declare @s nvarchar(1000)
set @s=''
select @s =@s+','+name+'('+convert(nvarchar(10),score)+'分)' from
stuscore where subject='數學'
set @s=stuff(@s,1,1,' ')print '數學:'+@s
Mysql增刪改查語句
增加：INSERT INTO 表名(欄位名1，欄位名2) VALUE(欄位值1，欄位值2)
例：INSERT INTO a(id,name) VALUE(2,'李四');
刪除：DELETE FROM 表名 WHERE 條件
例：DELETE FROM a WHERE id=1;
修改：UPDATE 表名 SET 欄位名=欄位值 WHERE 條件
例：UPDATE a SET id=1,name='張三' WHERE id=2;
查詢：SELECT （欄位名，*代表全部） FROM 表名 WHERE 條件
例：SELECT id,name FROM a WHERE id=1;
常見軟體測試筆試題
1、測試用例的設計方法有哪些？請闡述判定表設計測試用例的步驟。
答：等價類劃分，邊界值分析，錯誤推斷法，因果圖法，正交表分析法，場景分析法。
判定表設計測試用例的步驟：確定規則的個數；列出所有的條件樁和動作樁；填入條件項，得到初始判定表；簡化合並相似規則。
2、自動化測試框架有哪幾種？
答：模組化框架，
函式庫框架；
關鍵字驅動測試框架；
資料驅動框架。
3、測試覆蓋率分為哪幾種統計方式？分別是什麼？
答：程式碼覆蓋率；功能模組覆蓋率；資料庫覆蓋率；需求覆蓋率。
4、什麼是FMEA？
答：失效模式與影響分析，它是可靠性設計的重要方法，對各種風險進行評價，分析，以便在現有技術的基礎上消除這些風險或將風險減少到可以接受的水平。
5、列舉出你所瞭解的EMC測試和環境測試專案。
答：EMC測試是對電子產品在電磁場方面干擾大小和抗干擾能力的綜合評定，是產品質量重要的指標之一，電磁相容的測量有測試場地和測試儀器組成。EMC包括兩部分，分別是EMI（干擾）和EMS（敏感度，抗干擾）。
6、如何制定測試計劃？
答：產品基本情況，測試需求情況，測試策略和記錄，計劃表，問題跟蹤報告，測試計劃的評定和結果。
7、什麼叫做有效等價有效類，無效等價類？
答：有效等價類值對於程式規格來說是合理的，有意義的輸入資料構成的集合。利用有效等價類可以檢驗程式是否實現了規格說明書的預先設定的功能和特性。無效等價類是指對於軟體規格來說是沒有意義和不合理的輸入的資料集合。
8、請描述TCP/IP建立連線的過程
答：採用三次握手，建立一個連線。
第一次握手，客戶端傳送syn包（syn=j）到服務端，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手，服務端收到syn包，必須確認客戶的SYN（ack=j+1），同時也傳送一個syn包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手，客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認包ACK（ack=k+1），此包傳送完畢，客戶端和伺服器進入EATABLISHED狀態，完成三次握手。
9、呼叫一個DLL（動態連結庫）有哪幾種方式？
答：一種是程式設計的時候，直接呼叫include庫檔案。編好的程式使用時為作業系統直接呼叫。
第二種為程式設計的時候使用LoadLibrary,FreeLibrary,GetProcAddress來動態裝載程式。則編好的程式使用庫檔案時，是程式自己主動載入。
10、白盒測試有哪些覆蓋方法？
答：語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，組合覆蓋，路徑覆蓋。
11、程序與執行緒的區別？
答：執行緒是程序的一個執行單元，也是程序的可排程實體。
與程序的區別：
（1）、地址空間：程序內的一個執行單元；程序至少有一個執行緒，它們共享程序的地址空間，而程序有自己獨立的地址空間；
（2）、資源擁有：程序是資源分配和擁有的單位，同一個程序內的執行緒共享程序的資源；
（3）、執行緒是處理器排程的基本單位，程序不是；
（4）、二者均可併發執行。