原文地址:http://blog.csdn.net/hualusiyu/article/details/8132162
61、簡述負載測試與壓力測試的區別。
參考答案：
壓力測試（Stress Testing）
壓力測試的主要任務就是獲取系統正確運行的極限，檢查系統在瞬間峯值負荷下正確執行的能力。例如，對服務器做壓力測試時就可以增加併發操作的用戶數量；或者不停地向服務器發送請求；或一次性向服務器發送特別大的數據等。看看服務器保持正常運行所能達到的最大狀態。人們通常使用測試工具來完成壓力測試，如模擬上萬個用戶從終端同時登錄，這是壓力測試中常常使用的方法。
負載測試（Volume Testing）
用於檢查系統在使用大量數據的時候正確工作的能力，即檢驗系統的能力最高能達到什麼程度。例如，對於信息檢索系統，讓它使用頻率達到最大；對於多個終端的分時系統，讓它所有的終端都開動。在使整個系統的全部資源達到“滿負荷”的情形下，測試系統的承受能力。
62、寫出bug報告流轉的步驟，每步的責任人及主要完成的工作。
參考答案：（要結合自己實際的工作經驗進行回答，不同公司略有區別）
測試人員提交新的Bug入庫，錯誤狀態爲New。
高級測試員/測試經理驗證錯誤，如果確認是錯誤，分配給開發組。設置狀態爲Open。如果不是錯誤，則拒絕，設置爲Declined狀態。
開發經理分配bug至對應的模塊開發人員。
開發人員查詢狀態爲Open的Bug，如果不是錯誤，則置狀態爲Declined；如果是Bug則修復並置狀態爲Fixed。不能解決的Bug，要留下文字說明及保持Bug爲Open狀態。
對於不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可。
測試人員查詢狀態爲Fixed的Bug，然後驗證Bug是否已解決，如解決，置Bug的狀態爲Closed，如沒有解決,置bug狀態爲Reopen。
63、寫出bug報告當中一些必備的內容。
參考答案：
硬件平臺和操作系統
測試應用的硬件平臺（Platform），通常選擇“PC”。
測試應用的操作系統平臺（OS）。
a) 版本
提交缺陷報告時通過該字段標識此缺陷存在於被測試軟件的哪個版本。
b) Bug報告優先級
c) Bug狀態
d) Bug的編號
e) 發現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關係
j) 詳細描述
k) 嚴重程度
l) 所屬模塊
m) 附件
n) 提交日期
64、開發人員老是犯一些低級錯誤怎麼解決？
參考答案：
這種現象在開發流程不規範的團隊裏特別常見，尤其是一些“作坊式”的團隊裏。解決這種問題一般從兩個方面入手：
一方面從開發管理入手，也就是從根源來解決問題。可以制定規範的開發流程，甚至可以制定懲罰制度，還有就是軟件開發前做好規劃設計。
另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題“消滅”在開發階段，這是比較好的做法，讀者可以參考第13章試案例分析的“13.1.2缺陷反覆出現，誰的責任”小節，13.1.2專門討論了這類問題的方法。
此外，還可以通過規範的缺陷管理來對開發人員進行控制，比如測試部門整理出常見的缺陷，讓開發人員自己對照進行檢查，以減少這類低級錯誤的發生。
開發人員犯錯誤是正常的現象，作爲測試人員一定不能抱怨，要認認真真的解決問題纔是上策。
65、畫出軟件測試的V模型圖。
參考答案：
66、爲什麼要在一個團隊中開展軟件測試工作？
參考答案：
因爲沒有經過測試的軟件很難在發佈之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟件的質量情況。
67、您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
參考答案：（根據項目經驗不同，靈活回答即可）
我曾經做過web測試，後臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試
68、您所熟悉的軟件測試類型都有哪些？請試着分別比較這些不同的測試類型的區別與聯繫（如功能測試、性能測試……）
參考答案：
測試類型有：功能測試，性能測試，界面測試。
功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到嚮導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕鬆愉悅的感受和成功的感覺，相反由於界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注於產品整體的多用戶併發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（儘量在前臺避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然後再考慮該功能點的性能測試
69、您認爲做好測試用例設計工作的關鍵是什麼？
參考答案：
白盒測試用例設計的關鍵是以較少的用例覆蓋儘可能多的內部程序邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
70、請試着比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯繫。
參考答案：
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是爲了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
軟件的白盒測試是對軟件的過程性細節做細緻的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱爲結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這麼說，程序員有責任編寫功能代碼，同時也就有責任爲自己的代碼編寫單元測試。執行單元測試，就是爲了證明這段代碼的行爲和我們期望的一致。
集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求並且遵循系統設計。
驗收測試是部署軟件之前的最後一個測試操作。驗收測試的目的是確保軟件準備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
71、測試計劃工作的目的是什麼？測試計劃工作的內容都包括什麼？其中哪些是最重要的？
參考答案：
軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）
72、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
參考答案：
1．等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.併合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理劃分爲若干等價類,在每一個等價類中取一個數據作爲測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作爲測試數據,而不是選取等價類中的典型值或任意值作爲測試數據.
3．錯誤推測法
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據爲0的情況. 輸入表格爲空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作爲測試用例.
4．因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯繫, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程序輸入條件的各種組合情況.
73、請以您以往的實際工作爲例，詳細的描述一次測試用例設計的完整的過程。
參考答案：
就說最近的這次網站功能的測試吧
首先：得到相關文檔（需求文檔和設計文檔），理解需求和設計設計思想後，想好測試策略（測試計劃簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。
第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，然後在進行系統測試（另外個模塊呢有另一個測試人員負責，可以進行聯調測試），網站模塊的測試基本是功能測試和界面測試（用戶併發的可能性很小，所以不考慮）：這次的網站的輸入數據呢是使用數據庫中的某張表記錄，如果表中某一數據記錄中新加進來的（還沒有被處理的，有個標誌位），網站啓動後會立刻去刷那張表，得到多條數據，然後在進行處理。處理過程中，會經歷3個步驟，網站纔算完成了它的任務。有3個步驟呢，就可以分別對 這3個步驟進行測試用例的設計,儘量覆蓋到各種輸入情況（包括數據庫中的數據，用戶的輸入等），得出了差不多50個用例。界面測試，也就是用戶看的到的地方，包括髮送的郵件和用戶填寫資料的頁面展示。
第三步：搭建測試環境（爲什麼這個時候考慮測試環境呢？因爲我對網站環境已經很熟了，只有有機器能空於下來做該功能測試就可以做了），因爲網站本身的環境搭建和其他的系統有點不同，它需要的測試環境比較麻煩，需要web服務器（Apache,tomcat），不過這次需求呢，網站部分只用到了tomcat，所以只要有tomcat即可
第四步：執行測試
74、您以往是否曾經從事過性能測試工作？如果有，請儘可能的詳細描述您以往的性能測試工作的完整過程。
參考答案：（以自己最熟悉的性能測試項目爲例）
是的，曾經做過網站方面的性能測試，雖然做的時間並不久（2個月吧），當時呢，是有位網站性能測試經驗非常豐富的前輩帶着我一起做。
性能測試類型包括負載測試，強度測試，容量測試等
負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否能夠承擔。
強度測試： 強度測試是一種性能測試，他在系統資源特別低的情況下軟件系統運行情況
容量測試：確定系統可處理同時在線的最大用戶數
在網站流量逐漸加大的情況下，開始考慮做性能測試了，首先要寫好性能測試計劃，根據運營數據得出流量最大的頁面（如果是第一次的話，一般是首頁，下載頁，個人帳戶頁流量最大，而且以某種百分比），
Web服務器指標指標：
* Avg Rps: 平均每秒鐘響應次數＝總請求時間 / 秒數；
* Successful Rounds：成功的請求；
* Failed Rounds ：失敗的請求；
* Successful Hits ：成功的點擊次數；
* Failed Hits ：失敗的點擊次數；
* Hits Per Second ：每秒點擊次數；
* Successful Hits Per Second ：每秒成功的點擊次數；
* Failed Hits Per Second ：每秒失敗的點擊次數；
* Attempted Connections ：嘗試鏈接數；
75、你對測試最大的興趣在哪裏？爲什麼？
參考答案：
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分需要後天的努力。但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它。
剛開始進入測試行業時，對測試的認識是從無憂測試網上瞭解到的一些資料，當時是衝着做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因爲我喜歡我的專業），但看到測試比開發更難更有挑戰性，想做好測試的意志就更堅定了。
不到一年半的測試工作中，當時的感動和熱情沒有減退一點（即使環境問題以及自身經驗，技術的不足，做測試的你一定也能理解）。
我覺得做測試整個過程中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設計，因爲測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎麼運作的的，後臺是怎麼響應用戶請求的？測試環境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什麼難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現。
第二是發現BUG的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的bug，還有一部分bug需要測試的過程中更瞭解所測版本的情況獲得更多信息，補充測試用例，測試出bug。還有如何發現bug？這就需要在測試用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程數據流及結果都得看仔細了，bug都在裏面發現的）。如何描述bug也很有講究，bug在什麼情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什麼？如果你夠厲害的話，可以幫開發人員初步定位問題。
76、你以前工作時的測試流程是什麼？
參考答案：（靈活回答）
公司對測試流程沒有規定如何做，但每個測試人員都有自己的一套測試流程。我說下我1年來不斷改正（自己總結，吸取同行的方法）後的流程吧。需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求確定(出一份確定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員的確定（嚴重級別的，或突然發現的在測試用例範圍之外的，難以重現的），有些可以直接錄製進TD）－>開發人員修改（可以在測試過程中快速的修改）－>迴歸測試（可能又會發現新問題，再按流程開始跑）。
77、當開發人員說不是BUG時，你如何應付？
參考答案：
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是BUG的依據是什麼？如果被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最後的確認。
78、軟件的構造號與版本號之間的區別？BVT(BuildVerificationTest)
參考答案：版本控制命名格式: 主版本號.子版本號[.修正版本號[.編譯版本號 ]]
Major.Minor [.Revision[.Build]]
應根據下面的約定使用這些部分：
Major ：具有相同名稱但不同主版本號的程序集不可互換。例如，這適用於對產品的大量重寫，這些重寫使得無法實現向後兼容性。
Minor ：如果兩個程序集的名稱和主版本號相同，而次版本號不同，這指示顯著增強，但照顧到了向後兼容性。例如，這適用於產品的修正版或完全向後兼容的新版本。
Build ：內部版本號的不同表示對相同源所作的重新編譯。這適合於更改處理器、平臺或編譯器的情況。
Revision ：名稱、主版本號和次版本號都相同但修訂號不同的程序集應是完全可互換的。這適用於修復以前發佈的程序集中的安全漏洞。
BVT(BuildVerificationTest)：
作爲Build的一部分，主要是通過對基本功能、特別是關鍵功能的測試，保證新增代碼沒有導致功能失效，保證版本的持續穩定。實現BVT方式是有以下幾種：1、測試人員手工驗證關鍵功能實現的正確性。特點：這是傳統開發方法中，通常採用的方式。無需維護測試腳本的成本，在測試人力資源充足，測試人員熟悉業務、並對系統操作熟練情況下效率很高，比較靈活快速。缺點：人力成本較高；對測試人員能力有一定要求；測試人員面對重複的工作，容易產生疲倦懈怠，從而影響測試質量。2、藉助基於GUI的自動化功能測試工具來完成，將各基本功能操作錄製成測試腳本，每次回放測試腳本驗證功能實現的正確性。特點：能夠模擬用戶操作完成自動的測試，從UI入口到業務實現，每一層的代碼實現都經過驗證；節約人力成本；降低測試人員重複勞動的工作量，機器不會疲倦；缺點：對於UI變動比較頻繁的系統來說，這種方式的維護成本很高，實施起來非常困難。另外，在項目週期較短且後續無延續性或繼承的情況下，也不推薦使用此方式。3、由開發人員通過自動化測試工具完成業務層的BVT測試。特點：通過對業務層關鍵功能的持續集成測試，保證系統功能的持續穩定。可以結合DailyBuild，做爲Build的一部分，自動實現並輸入BVT報告。缺點：僅對業務規則實現的正確性進行了測試，對錶現層無法測試到，對於諸如：前臺頁面控件各種事件響應、頁面元素變化等方面的問題無法保證。
79、您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
參考答案：
80、您以往所從事的軟件測試工作中，是否使用了一些工具來進行軟件缺陷（Bug）的管理？如果有，請結合該工具描述軟件缺陷（Bug）跟蹤管理的流程。
參考答案：
81、您認爲性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
參考答案：
82、單元測試、集成測試、系統測試的側重點是什麼？
參考答案：
83、集成測試通常都有那些策略？
參考答案：
84、一個缺陷測試報告的組成
參考答案：
85、基於WEB信息管理系統測試時應考慮的因素有哪些？
參考答案：
86、軟件測試項目從什麼時候開始，？爲什麼？
參考答案：
87、需求測試注意事項有哪些？
參考答案：
88、簡述一下缺陷的生命週期
參考答案：
89、你在你所在的公司是怎麼開展測試工作的？是如何組織的？
參考答案：
90、你認爲理想的測試流程是什麼樣子？
參考答案：
91、您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，並以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。
參考答案：
92、軟件測試活動的生命週期是什麼？
參考答案：
93、請畫出軟件測試活動的流程圖？
參考答案：
94、針對缺陷採取怎樣管理措施？
參考答案：
95、什麼是測試評估？測試評估的範圍是什麼？
參考答案：
96、如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎？爲什麼？
參考答案：
97、測試結束的標準是什麼？
參考答案：
98、軟件驗收測試除了alpha ,beta測試以外,還有哪一種?
參考答案：
99、做測試多久了？以前做過哪些項目？你們以前測試的流程是怎樣的？用過哪些測試工具？
參考答案：
100、請就如何在開發中進行軟件質量控制說說你的看法
101、一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。
102、軟件測試的類型有那些？分別比較這些不同的測試類型的區別與聯繫。
103、測試用例通常包括那些內容？着重闡述編制測試用例的具體做法
104、在分別測試winform的C/S結構與測試WEB結構的軟件是，應該採取什麼樣的方法分別測試？他們存在什麼樣的區別與聯繫？
105、在測試winform的C/S結構軟件時，發現這個軟件的運行速度很慢，您會認爲是什麼原因？您會採取哪些方法去檢查這個原因？
106、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程
107、你都用什麼測試方法
針對不同的產品或者系統或者模塊，有不同的測試方法。總體而言有白盒測試和黑盒測試。
108、怎麼編寫案例
案例的編寫與測試階段的定義有很大的關係。系統測試和unit測試的案例可能不同。總體而言測試案例根據系統的需求而定。
109、怎麼才能夠全面的測試到每一個點
測試的全面性主要需要在設計測試計劃的時候考慮，從測試策略，產品需求等等多個角度考慮從而定義全部的測試點。
110、談談軟件測試技術，以及如何提高
111、談談軟件測試職業發展，以及個人的打算
112、談談軟件測試在企業的地位，也可以結合軟件生命週期來談
113、一般公司裏實際的軟件測試流程是什麼樣的？你們公司又是怎樣的？
114、軟件工程師要具有那些素質？
115、你會哪些測試工具？怎麼操作？
116、你能不能說下你的3到5年的職業計劃（規劃）
117、你覺得你來應聘有那些優勢？
其他問題：（有可能清晰的思路比確切的答案更重要）
對測試的理解——考查點：基本的測試知識，對測試是否認可
談一談過去自己的工作——考查點：瞭解經歷、提供進一步提問的素材，表達能力、測試技能
測試設計的方法並舉例說明——考查點：測試技術的使用
測試工具——考查點：熟悉程度，能否與當前工作匹配？
如何做計劃？如何跟蹤計劃？——考查點：日常工作能力
如果開發人員提供的版本不滿足測試的條件，如何做？——考查點：與開發人員協作的能力
熟悉unix系統、oracle數據庫嗎？——考查點：是否具備系統知識
做過開發嗎？寫過哪些代碼？——考查點：開發技能
閱讀英語文章，給出理解說明？——考查點：部分英語能力
文檔的意義——考查點：是否善於思考？（最簡單的概念，不同層次的理解）
假如進入我們公司，對我們哪些方面會有幫助？——考查點：講講自己的特長
隨便找一件物品，讓其測試——考查點：測試的實際操作能力
有一個新的軟件，假如你是測試工程師，該如何做——考查點：實際項目經驗、是否有帶領測試團隊的經驗和潛力