軟件測試常考面試題-軟件測試面試寶典 ---面試過程當中踩過的坑

 

問：你在測試中發現了一個  bug ，可是開發經理認爲這不是一個  bug ，你應該怎樣解決。
首先，將問題提交到缺陷管理庫裏面進行備案。
而後，要獲取判斷的依據和標準：
根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供
缺陷是否確認的直接依據；
若是沒有文檔依據，能夠根據相似軟件的通常特性來講明是否存在不一致的地方，來確認是
否是缺陷；
根據用戶的通常使用習慣，來確認是不是缺陷；
與設計人員、開發人員和客戶表明等相關人員探討，確認是不是缺陷；
合理的論述，向測試經理說明本身的判斷的理由，注意客觀、嚴謹，不參雜我的情緒。
等待測試經理作出最終決定，若是仍然存在爭議，能夠經過公司政策所提供的渠道，向上級

反映，並有上級作出決定。

 

問：給你一個網站，你如何測試？
首先，查找需求說明、網站設計 m 等相關文檔，分析測試需求。
制定測試計劃，肯定測試範圍和測試策略，通常包括如下幾個部分：
功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
設計測試用例：
功能性測試能夠包括，但不限於如下幾個方面：
連接測試。連接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回
等。
提交功能的測試。
多媒體元素是否能夠正確加載和顯示。
多語言支持是否可以正確顯示選擇的語言等。
界面測試能夠包括但不限於一下幾個方面：
頁面是否風格統一，美觀
頁面佈局是否合理，重點內容和熱點內容是否突出
控件是否正常使用
對於必須但爲安裝的空間，是否提供自動下載並安裝的功能
文字檢查
性能測試通常從如下兩個方面考慮：
壓力測試；負載測試；強度測試
數據庫測試要具體決定是否須要開展。數據庫通常須要考慮連結性，對數據的存取操做，數
據內容的驗證等方面。
安全性測試：
1 基本的登陸功能的檢查 2 是否存在溢出錯誤，致使系統崩潰或者權限泄露 3 相關開發語言
的常見安全性問題檢查，例如 SQL 注入等。4 若是須要高級的安全性測試，肯定得到專業安
全公司的幫助，外包測試，或者獲取支持
兼容性測試，根據需求說明的內容，肯定支持的平臺組合：
瀏覽器的兼容性；操做系統的兼容性；軟件平臺的兼容性；數據庫的兼容性
開展測試，並記錄缺陷。合理的安排調整測試進度，提早獲取測試所需的資源，創建管理體
系（例如，需求變動、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
按期評審，對測試進行評估和總結，調整測試的內容。
在搜索引擎中輸入漢字就能夠解析 到對應的域名，請問如何用 r LoadRunner  進行測試。
創建測試計劃，肯定測試標準和測試範圍

設計典型場景的測試用例，覆蓋經常使用業務流程和不經常使用的業務流程等

 

根據測試用例，開發自動測試腳本和場景：
錄製測試腳本
新建一個腳本（Web/HTML 協議）
點擊錄製按鈕，在彈出的對話框的 URL 中輸入」about:blank」。
在打開的瀏覽器中進行正常操做流程後，結束錄製。
調試腳本並保存。可能要注意到字符集的關聯。
設置測試場景
針對性能設置測試場景，主要判斷在正常狀況下，系統的平均事務響應時間是否達標
針對壓力負載設置測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件
下，系統是否會崩潰。

執行測試，獲取測試結果，分析測試結果

 

問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什麼區別? ?
300 個用戶在一個客戶端上，會佔用客戶機更多的資源，而影響測試的結果。
線程之間可能發生干擾，而產生一些異常。
300 個用戶在一個客戶端上，須要更大的帶寬。
IP 地址的問題，可能須要使用 IP Spoof 來繞過服務器對於單一 IP 地址最大鏈接數的限制。
全部用戶在一個客戶端上，沒必要考慮分佈式管理的問題；而用戶分佈在不一樣的客戶端上，需
要考慮使用控制器來總體調配不一樣客戶機上的用戶。同時，還須要給予相應的權限配置和防
火牆設置。
試述軟件的概念和特色？軟件複用的含義？構件包括哪些？
軟件是計算機系統中與硬件相互依存的另外一部分，它是包括程序、文檔的完整集合。
軟件複用(Software Reuse)是將已有軟件的各類有關知識用於創建新的軟件,以縮減軟件開
發和維護的花費。軟件複用是提升軟件生產力和質量的一種重要技術。早期的軟件複用主要
是代碼級複用，被複用的知識專指程序，後來擴大到包括領域知識、開發經驗、設計決定、
體系結構、需求、設計、代碼和文檔等一切有關方面。

能夠被複用的軟件成分通常稱做可複用構件

 

2 2 、軟件生存週期及其模型是什麼？
軟件生存週期是軟件開發所有過程、活動和任務的結構框架，是從可行性研究到需求分析、
軟件設計、編碼、測試、軟件發佈維護的過程。
在經歷需求、分析、設計、實現、部署後，軟件將被使用並進入維護階段，直到最後因爲缺
少維護費用而逐漸消亡。這樣的一個過程，稱爲"生命週期模型"（Life Cycle Model）。
什麼是軟件測試？軟件測試的目的與原則
使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否知足規定的需
求或弄清預期結果與實際結果之間的差異。
軟件測試的目的：
測試是程序的執行過程，目的在於發現錯誤
一個成功的測試用例在於發現至今未發現的錯誤
一個成功的測試是發現了至今未發現的錯誤的測試
確保產品完成了它所承諾或公佈的功能，而且用戶能夠訪問到的功能都有明確的書面說明。
確保產品知足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟件測試的原則：
教材的說法：

軟件測試應儘早執行，並貫穿於整個軟件生命週期
軟件測試應追溯需求
測試應由第三方來構造
窮舉測試是不可能的,要遵循 Good-enough 原則
必須肯定預期輸出（或結果）
必須完全檢查每一個測試結果
充分注意測試中的羣集現象
缺陷的二八定理
嚴格執行測試計劃，排除測試的隨意性
注意合法合理的輸入，也要注意非法的非預期的輸入
檢查程序是否作了不應作的
測試應從「小規模」開始，逐步轉向「大規模」
反覆使用一樣的測試會使軟件具備抵抗力
關注缺陷的修復
軟件配置管理的做用？軟件配置包括什麼？
軟件配置管理做爲軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命周
期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持做用。一個軟件開發組織真
正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具備可重複性，
大大提升軟件組織的競爭力。
軟件配置包括以下內容：
配置項識別
工做空間管理
版本控制
變動控制
狀態報告
配置審計
什麼是軟件質量？

軟件質量：軟件產品的特性能夠知足用戶的功能、性能需求的能力。

 

目前主要的測試用例設計方法是什麼？

白盒測試：
邏輯覆蓋
循環覆蓋
基本路徑覆蓋
黑盒測試：
邊界值分析法
等價類劃分
錯誤猜想法
因果圖法
狀態圖法
測試大綱法
隨機測試

場景法

 

軟件的安全性應從哪幾個方面 去測試？
軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不一樣測試策略也不一樣。
用戶認證安全的測試要考慮問題：
明確區分系統中不一樣用戶權限
系統中會不會出現用戶衝突
系統會不會因用戶的權限的改變形成混亂
用戶登錄密碼是不是可見、可複製
是否能夠經過絕對途徑登錄系統（拷貝用戶登錄後的連接直接進入系統）
用戶退出系統後是否刪除了全部鑑權標記，是否能夠使用後退鍵而不經過輸入口令進入系統
系統網絡安全的測試要考慮問題
測試採起的防禦措施是否正確裝配好，有關係統的補丁是否打上
模擬非受權攻擊，看防禦系統是否堅固
採用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，
如今最經常使用的是 NBSI 系列和 IPhacker IP ）
採用各類木馬檢查工具檢查系統木馬狀況
採用各類防外掛工具檢查系統各組程序的外掛漏洞
數據庫安全考慮問題：

系統數據是否機密（好比對銀行系統，這一點就特別重要，通常的網站就沒有過高要求）

系統數據的完整性（我剛剛結束的企業實名覈查服務系統中就曾存在數據的不完整，對於這
個系統的功能實現有了障礙）
系統數據可管理性
系統數據的獨立性

系統數據可備份和恢復能力（數據備份是否完整，能否恢復，恢復是否能夠完整）

什麼是測試用例 什麼是測試腳本 二者的關係是什麼？
爲實施測試而向被測試系統提供的輸入數據、操做或各類環境設置以及指望結果的一個特定
的集合。
測試腳本是爲了進行自動化測試而編寫的腳本。
測試腳本的編寫必須對應相應的測試用例，
簡述什麼是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試
靜態測試是不運行程序自己而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差別，判
定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，並分析系統運行效率
和健壯性等性能。
黑盒測試通常用來確認軟件功能的正確性和可操做性,目的是檢測軟件的各個功能是否能得
以實現,把被測試的程序看成一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間
的關係或程序功能的狀況下,依靠軟件規格說明書來肯定測試用例和推斷測試結果的正確
性。
白盒測試根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員經過閱讀
程序代碼或者經過使用開發工具中的單步調試來判斷軟件的質量，通常黑盒測試由項目經理
在程序員開發中來實現。
α測試是由一個用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環
境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在
測試現場，Beta 測試不能由程序員或測試員完成。
軟件質量保證體系是什麼 國家標準中與質量保證管理相關的幾個標準是什麼? ? 他們的編號
和全稱是什麼? ?
SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA 貫穿整個軟件開發過程，
(它)應包括需求文檔評審、代碼控制、代碼評審、變動管理、配置管理、版本管理和軟件測
試。

軟件產品質量特性是什麼? ?
功能性：適應性、準確性、互操做性、依從性、安全性。

可靠性：成熟性、容錯性、以恢復性。
可以使用性：易理解性、易學習性、易操做性。
效率：時間特性、資源特性。
可維護性：易分析性、易變動性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性。

軟件測試的策略是什麼? ?
軟件測試策略：在必定的軟件測試標準、測試規範的指導下，依據測試項目的特定環境約束
而規定的軟件測試的原則、方式、方法的集合。

軟件測試分爲幾個 階段 各階段的測試策略和要求是什麼? ?
軟件測試按階段劃分能夠分爲單元測試、集成測試、系統測試和<驗收測試>（不必定有）幾
個階段
單元測試測試策略：
自頂向下的單元測試策略
總結：比孤立單元測試的成本高不少，不是單元測試的一個好的選擇。
自底向上的單元測試策略
總結：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略
總結：最好的單元測試策略。
集成測試的測試策略：
大爆炸集成
適應於一個維護型項目或被測試系統較小
自頂向下集成
適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或常常可能被修
改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系統功能
行爲。
自底向上集成
適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基於進度的集成
優勢：具備較高的並行度；可以有效縮短項目的開發進度。
缺點：樁和驅動工做量較大；有些接口測試不充分；有些測試重複和浪費。
系統測試的測試策略
8
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容
量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；
可用性測試；版本驗證測試；文檔測試
在軟件測試各個階段一般完成什麼工做？各個階段的結果文件是什麼？包括什麼內容？
單元測試階段。各獨立單元模塊在與系統地其餘部分相隔離的狀況下進行測試，單元測試針
對每個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成
單元測試報告，提交缺陷報告。
集成測試階段。集成測試是在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規
格說明的要求組裝成模塊、子系統或系統的過程當中各部分工做是否達到或實現相應技術指標
及要求的活動。該階段生成集成測試報告，提交缺陷報告。
系統測試階段。將經過確認測試的軟件，做爲整個給予計算機系統的一個元素，與計算機硬
件、外設、某些支持軟件、數據和人員等其餘系統元素結合在一塊兒，在實際運行環境下，對
計算機系統進行全面的功能覆蓋。該階段須要提交測試總結和缺陷報告。

打賞，就是鼓勵我寫做的動力。 2.88 3.88 6.88 12.88 都是不錯的數字呢~

 以上，謝謝閱讀。

測試人員在軟件開發過程當中的任務是什麼？
一、尋找 Bug；
二、避免軟件開發過程當中的缺陷；
三、衡量軟件的品質；
四、關注用戶的需求。
總的目標是：確保軟件的質量。
在您以往的工做中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量
的軟件缺陷（Bug）記錄？
一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現
人、修改日期、修改人、修改方法、迴歸結果等等；要有效的發現 Bug 需參考需求以及詳細
設計等前期文檔設計出高效的測試用例，而後嚴格執行測試用例，對發現的問題要充分確認
確定，而後再向外發布如此才能提升提交 Bug 的質量。
黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優勢和缺點！
黑盒測試的優勢有：
比較簡單，不須要了解程序內部的代碼及實現；
與軟件的內部實現無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基於軟件開發文檔，因此也能知道軟件實現了文檔中的哪些功能；
在作軟件自動化測試時較爲方便。
黑盒測試的缺點有：
不可能覆蓋全部的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
自動化測試的複用性較低。

白盒測試的優勢有：
幫助軟件測試人員增大代碼的覆蓋率，提升代碼的質量，發現代碼中隱藏的問題。
白盒測試的缺點有：
程序運行會有不少不一樣的路徑，不可能測試全部的運行路徑；
測試基於代碼，只能測試開發人員作的對不對，而不能知道設計的正確與否，可能會漏掉一
些功能需求；
系統龐大時，測試開銷會很是大。
如何測試一個 紙杯？
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不一樣高度落下的損壞程度
可移植性：杯子在不一樣的地方、溫度等環境下是否均可以正常使用
兼容性：杯子是否可以容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和狀況；盛上汽油（案例二）
放 24 小時檢查泄漏時間和狀況等
壓力測試：用根針並在針上面不斷加劇量，看壓強多大時會穿透

7 7 、測試計劃工做的目的是什麼？測試計劃文檔的內容應該包括什麼？其中哪些是最重要
的？
答案：軟件測試計劃是指導測試過程的綱領性文件。
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試
交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤爲是測試管理人員，
能夠明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對
測試過程當中的各類變動。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃
測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
因此其中最重要的是測試測試策略和測試方法（最好是能先評審）。

8 8 、黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來講明這些方法在測
試用例設計工做中的應用。
等價類劃分
劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序
中的錯誤都是等效的.併合理地假定:測試某等價類的表明值就等於對這一類其它值的測試.

所以,能夠把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試
的輸入條件,就能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不
同的狀況:有效等價類和無效等價類.
2）邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工做經驗告訴我,大量的錯誤是發生在輸
入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測
試用例,能夠查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應肯定邊界狀況.一般輸入和輸出等價類的邊界,就
是應着重測試的邊界狀況.應當選取正好等於,剛剛大於或剛剛小於邊界的值做爲測試數據,
而不是選取等價類中的典型值或任意值做爲測試數據.
3）錯誤猜想法
基於經驗和直覺推測程序中全部可能存在的各類錯誤, 從而有針對性的設計測試用例的方
法.
錯誤推測方法的基本思想: 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況,根
據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 之前產品
測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據爲 0 的狀況.
輸入表格爲空格或輸入表格只有一行. 這些都是容易發生錯誤的狀況. 可選擇這些狀況下
的例子做爲測試用例.

4）因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件
之間的聯繫, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的狀況. 但要
檢查輸入條件的組合不是一件容易的事情, 即便把全部輸入條件劃分紅等價類,他們之間的
組合狀況也至關多. 所以必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個
動做的形式來考慮設計測試用例. 這就須要利用因果圖（邏輯模型）. 因果圖方法最終生成
的就是斷定表. 它適合於檢查程序輸入條件的各類組合狀況.
5）正交表分析法
有時候，可能由於大量的參數的組合而引發測試用例數量上的激增，同時，這些測試用例並
沒有明顯的優先級上的差距，而測試人員又沒法完成這麼多數量的測試，就能夠經過正交表
來進行縮減一些用例，從而達到儘可能少的用例覆蓋儘可能大的範圍的可能性。
6）場景分析方法
指根據用戶場景來模擬用戶的操做步驟，這個比較相似因果圖，可是可能執行的深度和可行
性更好。
7）狀態圖法
經過輸入條件和系統需求說明獲得被測系統的全部狀態，經過輸入條件和狀態得出輸出條
件；經過輸入條件、輸出條件和狀態得出被測系統的測試用例。
8）大綱法
11
大綱法是一種着眼於需求的方法，爲了列出各類測試條件，就將需求轉換爲大綱的形式。大
綱表示爲樹狀結構，在根和每一個葉子結點之間存在惟一的路徑。大綱中的每條路徑定義了一
個特定的輸入條件集合，用於定義測試用例。樹中葉子的數目或大綱中的路徑給出了測試所
有功能所需測試用例的大體數量。
9 9 、詳細的描述一個測試活動完整的過程。
答案：（供參考，本答案主要是瀑布模型的作法）
項目經理經過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評
審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者沒法實現的功能的地方。
項目經理經過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。而後 SQA 進入項目，
開始進行統計和跟蹤
開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有
遺漏或者雙方理解不一樣的地方。測試人員完成測試計劃文檔，測試計劃包括的內容上面有描
述。
測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳
細設計文檔。此兩份文檔成爲測試人員撰寫測試用例的補充材料。
測試用例完成後，測試和開發須要進行評審。
測試人員搭建環境
開發人員提交第一個版本，可能存在未完成功能，須要說明。測試人員進行測試，發現 BUG
後提交給 BugZilla。
開發提交第二個版本，包括 Bug Fix 以及增長了部分功能，測試人員進行測試。
重複上面的工做，通常是 3-4 個版本後 BUG 數量減小，達到出貨的要求。
若是有客戶反饋的問題，須要測試人員協助重現並從新測試。
2、在您以往的工做中，一條軟件缺陷（或者叫  Bug ）記錄都包含了哪些內容？如何提交高
質量的軟件缺陷（ Bug ）記錄？
在傳統的 BugZilla 中，BUG 描述應該包括如下的信息
和 BUG 產生對應的軟件版本和模塊
開發的接口人員
BUG 的優先級
BUG 的嚴重程度
BUG 可能屬於的模塊，若是不能確認，能夠用開發人員來判斷
BUG 標題，須要清晰的描述現象
BUG 描述，須要儘可能給出從新 Bug 的步驟
BUG 附件中能給出相關的日誌和截圖。
高質量的 BUG 記錄就是指很容易理解的 BUG 記錄，因此，對於描述的要求高，能提供的信息
多且準確，很好的幫助開發人員定位，所以提交高質量的軟件缺陷記錄須要注意對 BUG 記錄
的描述質量多且準確。

3、G BUG  管理工具的跟蹤過程
用 BugZilla 爲例子
測試人員發現了 BUG，提交到 Bugzilla 中，狀態爲 new，BUG 的接受者爲開發接口人員
開發接口將 BUG 分配給相關的模塊的開發人員，狀態修改成已分配，開發人員和測試確認
BUG，若是是本人的 BUG，則設置爲接收；若是是別的開發人員的問題，則轉發出去，由下
一個開發人員來進行此行爲；若是認爲不是問題，則須要你們討論並確認後，拒絕這個 BUG，
而後測試人員關閉此問題。
若是開發人員接受了 BUG，並修改好之後，將 BUG 狀態修改成已修復，並告知測試在哪一個版
本中能夠測試。
測試人員在新版本中測試，若是發現問題依然存在，則拒絕驗證；若是已經修復，則關閉
BUG。
4、您認爲在測試人員同開發人員的溝經過程中，如何提升溝通的效率和改善溝通的效果？
維持測試人員同開發團隊中其餘成員 良好的人際關係的關鍵是什麼？
儘可能面對面的溝通，其次是能直接經過電話溝通，若是隻能經過 Email 等非及時溝通工具的
話，強調必須對特性的理解深入以及能表達清楚。
運用一些測試管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在
TestDirector 中對 BUG 有準確的描述。

在團隊中創建測試人員與開發人員良好溝通中注意如下幾點：
一真誠
二是團隊精神
三是在專業上有共同語言
四是要對事不對人，工做至上
固然也能夠經過直接指出一些小問題，而不是進入 BUG Tracking System 來增長對方的好感。
5、你對測試最大的興趣在哪裏？爲何？
回答這個面試題，沒有固定統一的答案，但多是許多企業都會問到的。提供如下答案供考：
最大的興趣，感受這是一個有挑戰性的工做；
測試是一個經驗行業，工做越久越能感受到作好測試的難度和樂趣
經過本身的工做，能使軟件產品愈來愈完善，從中體會到樂趣
回答此類問題注意如下幾個方面：
儘量的切合招聘企業的技術路線來表達你的興趣，例如該企業是數據庫應用的企業，那麼
表示你的興趣在數據庫的測試，而且但願經過測試提高本身的數據庫掌握能力。
代表你作測試的目的是爲了提高能力，也是爲了更好的作好測試；提高能力不是爲了之後轉
開發或其餘的，除非用人企業有這樣的安排。
不要過多的表達你的興趣在招聘企業的範疇這外。好比招聘企業是作財務軟件的，但是你表
現出來的是對遊戲軟件的興趣；或招聘是作 Java 開發的，而你的興趣是在 C 類語言程序的
開發。

6、你自認爲測試的優點在哪裏？
該面試也沒有固定不變的答案，但可參考如下幾點，並結合自身特色：
有韌性
有耐心
作事有條理性
喜歡面對挑戰
有信心作好每一件事情
較強的溝通能力
從之前的經理處都獲得了很好的評價代表我作的很好
7、集成測試一般都有那些策 略？
一、大爆炸集成
二、自頂向下集成
三、自底向上集成
四、三明治集成適應於大部分軟件開發項目
五、基幹集成
六、分層集成
七、基於功能的集成
八、基於消息的集成
九、基於風險的集成
十、基於進度的集成
請你分別畫出 I OSI  的七層網絡結構圖和 P TCP/IP  的四層結構圖。
答：OSI 七層網絡結構圖，由上至下：
應用層 ；表示層 ;會話層 ;傳輸層 ;網絡層 ;數據鏈路層;物理層
TCP/IP 的四層結構圖
應用層;傳輸層;互聯層;鏈路層
一個 e byte  幾個單位。( ( 計算機基礎) )
答：8bit。

經常使用 X UNIX  命令x (Linux  的經常使用命令) ) （至少 0 10  個）； (Unix)
答：ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit，
參見 linux 的教材。
簡述你在之前的工做中作過哪些事情，比較熟悉什麼。
此問題每一個人都不同。參考答案以下。
我過去的主要工做是系統測試和自動化測試。在系統測試中，主要是對 BOSS 系統的業務邏
輯功能，以及軟交換系統的 Class 5 特性進行測試。性能測試中，主要是進行的壓力測試，
在各個不一樣數量請求的狀況下，獲取系統響應時間以及系統資源消耗狀況。自動化測試主要
是經過本身寫腳本以及一些第三方工具的結合來測試軟交換的特性測試。
在測試中，我感受對用戶需求的徹底準確的理解很是重要。另外，就是對 BUG 的管理，要以
需求爲依據，並非全部 BUG 均須要修改。
測試工做須要耐心和細緻，由於在新版本中，雖然多數原來發現的 BUG 獲得了修復，但原來
正確的功能也可能變得不正確。所以要注重迭代測試和迴歸測試。
在  C/C++中 中 c static  有什麼用途？（請至少說明兩種）
1)在函數體，一個被聲明爲靜態的變量在這一函數被調用過程當中維持其值不變。
2) 在模塊內（但在函數體外），一個被聲明爲靜態的變量能夠被模塊內所用函數訪問，但
不能被模塊外其它函數訪問。它是一個本地的全局變量。
3) 在模塊內，一個被聲明爲靜態的函數只可被這一模塊內的其它函數調用。那就是，這個
函數被限制在聲明它的模塊的本地範圍內使用
引用與指針有什麼區別？
1) 引用必須被初始化，指針沒必要。
2) 引用初始化之後不能被改變，指針能夠改變所指的對象。
3) 不存在指向空值的引用，可是存在指向空值的指針。
t Internet  採用哪一種網絡協議？該協議的主要層次結構？t Internet  物理地址和 P IP  地址轉換
採用什麼協議？
TCP/IP 協議
主要層次結構爲： 應用層/傳輸層/網絡層/數鏈路層。
ARP (Address Resolution Protocol)（地據址解析協議）
說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優
缺點和主要適應於哪一種類型測試；
自頂向下集成
優勢：較早地驗證了主要控制和判斷點；按深度優先能夠首先實現和驗證一個完整的軟件功
能；功能較早證明，帶來信心；只需一個驅動，減小驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。

適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或常常可能被修
改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系統功能
行爲。
二、自底向上集成
優勢：對底層組件行爲較早驗證；工做最初能夠並行集成，比自頂向下效率高；減小了樁的
工做量；支持故障隔離。
缺點：驅動的開發工做量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
軟件驗收測試包括 ___ 、 ___ 、 ____ 三種類型。
軟件驗收測試包括正式驗收測試、alpha 測試、beta 測試三種測試。
2 2 ．系統測試的策略有 ____________________________等 等  15  種方法。（該題
5 15  個空）
系統測試的策略有不少種的，有性能測試、負載測試、強度測試、易用性測試、安全測試、
配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、分佈測試、可
用性測試。
3 3 ．設計系統測試計劃須要參考的項目文檔有 ___ 、 ___ 和 ____ 。
設計系統測試計劃須要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。
4 4 ．經過畫因果圖來寫測試用例的步驟爲 ___ 、 ___ 、 ___ 、 ___ 及把因果圖轉換爲狀態圖共五
個步驟。 利用因果圖生成測試用例的基本步驟是：
§ 分析軟件規格說明描述中，哪些是緣由（即輸入條件或輸入條件的等價類），哪些是結
果（即輸出條件），並給每一個緣由和結果賦予一個標識符。
§ 分析軟件規格說明描述中的語義，找出緣由與結果之間，緣由與緣由之間對應的是什麼
關係? 根據這些關係，畫出因果圖。
§ 因爲語法或環境限制，有些緣由與緣由之間，緣由與結果之間的組合狀況不可能出現。
爲代表這些特殊狀況，在因果圖上用一些記號標明約束或限制條件。 § 把因果圖轉換成判
定表。
§ 把斷定表的每一列拿出來做爲依據，設計測試用例。
1、 測試的種類不少，好比：
代碼、函數級測試
模塊、組件級測試
系統測試
請說出這些測試最好由那些人員完成，測試的是什麼？
代碼、函數級測試通常由白盒測試人員完成，他們針對每段代碼或函數進行正確性檢驗，檢
查其是否正確的實現了規定的功能。

模塊、組件級測試主要依據是程序結構設計測試模塊間的集成和調用關係，通常由測試人員
完成。
系統測試在於模塊測試與單元測試的基礎上進行測試。瞭解系統功能與性能，根據測試用例
進行全面的測試。
2、 設計測試用例時應該考慮哪些方面，即不一樣的測試用例針對那些方面進行測試？
設計測試用例時須要注意的是，除了對總體流程及功能注意外，還要注意強度測試、性能測
試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。（測試用例須要考慮的四
個基本要素是輸入、輸出、操做和測試環境；另外，測試用例須要考慮的是測試類型（功能、
性能、安全„„），這部分能夠參照 TP 作答。此外，還須要考慮用例的重要性和優先級）
4、 在 在 s windows  下保存一個文本文件時會彈出保存對話框，若是爲文件名創建測試用例，
等價類應該怎樣劃分？
單字節，如 A；
雙字節， AA、我我；
特殊字符 /‘。‘；、=-等；
保留字，如 com；
文件格式爲 8.3 格式的；
文件名格式爲非 8.3 格式的；
/,\,*等九個特殊字符。
假設有一個文本框要求輸入 0 10  個字符的郵政編碼，對於該文本框應該怎 樣劃分等價類？
特殊字符，如 10 個*或￥；
英文字母，如 ABCDefghik；
小於十個字符，如 123；
大於十個字符，如 11111111111；
數字和其餘混合，如 123AAAAAAA；
空字符；
保留字符
7、 答：
用命令行: use 數據庫名稱

在工具欄直接選擇要鏈接數據庫
5. 軟件測試項目從何時開始，？爲何？
軟件測試應該在需求分析階段就介入,由於測試的對象不只僅是程序編碼,應該對軟件開發
過程當中產生的全部產品都測試,而且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費
的成本就越大.
表一 AA
種類 T 庫存總量 S
A 997 B 1234
表二 BB
種類 T 出庫數量 S
A 105 B 116 B 303
A 213 B 211
select distinct AA.T kind ,AA.S-(select sum(BB.S) sumnum from BB group
by T having AA.T=BB.T) stock from AA,BB where AA.T=BB.T
什麼是白盒測試？什麼是黑盒測試? ? 什麼是迴歸測試? ?
答：白盒測試是測試人員要了解程序結構和處理過程,按照程序內部邏輯測試程序,檢查程序
中的每條通路是否按照預約要求正確工做.它主要的針對被測程序的源代碼,測試着能夠完
全不考慮程序的功能.
白盒測試流程:詳細設計-->源程序-->分析程序內部邏輯結構-->流程圖-->制定測試用例
-->被測程序-->執行路徑-->覆蓋狀況分析 .
黑盒測試:（Black-box Testing，又稱爲功能測試或數據驅動測試）是把測試對象看做一
個黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品
的內部結構和處理過程。
迴歸測試: (regression testing): 迴歸測試有兩類：用例迴歸和錯誤迴歸；用例回
歸是過一段時間之後再回頭對之前使用過的用例在從新進行測試，看看會從新發現問題。錯
誤迴歸，就是在新版本中，對之前版本中出現並修復的缺陷進行再次驗證，並以缺陷爲核心，
對相關修改的部分進行測試的方法。
2. 單元測試、集成測試、系統測試的側重點是什麼？
單元測試針對的是軟件設計的最小單元--程序模塊（面向過程當中是函數、過程；面向對象
中是類。）,進行正確性檢驗的測試工做,在於發現每一個程序模塊內部可能存在的差錯.通常
有兩個步驟:人工靜態檢查\動態執行跟蹤
集成測試針對的是經過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是
各個單元模塊之間的接口,以及各個模塊集成後所實現的功能.
系統測試針對的是集成好的軟件系統，做爲整個計算機系統的一個元素,與計算機硬件\
外設\某些支持軟件\數據和人員等其餘系統元素結合在一塊兒,要在實際的運行環境中,對計
算機系統進行一系列的集成測試和確認測試.
3. 設計用例的方法：
在測試的不一樣階段運用不用的測試方法設計用例的方法依據不一樣:
白盒測試用例設計有以下方法：邏輯覆蓋、循環覆蓋和基本路徑覆蓋

黑盒測試用例設計方法：等價類劃分、邊界值分析、錯誤猜想、因果圖、狀態圖、測試大綱、
場景法、正交策略表。
4. 一個測試工程師應具有那些素質？
一、責任心
二、溝通能力
三、團隊合做精神
四、耐心、細心、信心
五、時時保持懷疑態度，而且有缺陷預防的意識
六、具有必定的編程經驗
5. 集成測試一般都有那些策略？
基於分解的集成:大爆炸集成\自頂向下集成\自底向上集成\ 三明治集成\基於調用圖的
集成\基於路徑的集成\分層集成\基於功能的集成\高頻集成\基於進度的集成\基於風險集
成\基於事件集成\基於使用的集成\C/S 集成
問題二：你所瞭解的的軟件測試類型都有哪些，簡單介紹一下。
按測試 策略分類：一、靜態與動態測試 二、黑盒與白盒測試 三、手工和自動測試 四、冒煙測
試 五、迴歸測試；
按測試階段分類：單元測試、集成測試、系統測試；
其餘常見測試方法：一、功能測試 二、性能測試 三、壓力測試 四、負載測試 五、易用性測試 六、
安裝測試 七、界面測試 八、配置測試 九、文檔測試 十、兼容性測試 十一、安全性測試 十二、
恢復測試
問題三：你認爲作好測試計劃工做的關鍵是什麼？
明確測試的目標，加強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程可以發現更多的軟件缺陷，所以軟件測試計劃
的價值取決於它對幫助管理測試項目，而且找出軟件潛在的缺陷。所以，軟件測試計劃中的
測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具而且具備較高的實用性，
便於使用，生成的測試結果直觀、準確
堅持「5W」規則，明確內容與過程
「5W」規則指的是「What（作什麼）」、「Why（爲何作）」、「When（什麼時候作）」、「Where
（在哪裏）」、「How（如何作）」。利用「5W」規則建立軟件測試計劃，能夠幫助測試團
隊理解測試的目的（Why），明確測試的範圍和內容（What），肯定測試的開始和結束日期
（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
採用評審和更新機制，保證測試計劃知足實際需求
測試計劃寫做完成後，若是沒有通過評審，直接發送給測試團隊，測試計劃內容的可能不許
確或遺漏測試內容，或者軟件需求變動引發測試範圍的增減，而測試計劃的內容沒有及時更
新，誤導測試執行人員。

分別建立測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文檔，把用於指導測試小組執行測
試過程的測試用例放到獨立建立的測試用例文檔或測試用例管理數據庫中。測試計劃和測試
詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、
方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
問題四：您認爲作好測試用例設計工做的關鍵是什麼？
白盒測試用例設計的關鍵是以較少的用例覆蓋儘量多的內部程序邏輯結果
黑盒法用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能作到徹底測
試，以最少的用例在合理的時間內發現最多的問題
問題六：您認爲性能測試工做的目的是什麼？作好性能測試工做的關鍵是什麼？
性能測試的目的主要是發如今併發多用戶和大數據量操做時是否會出現與需求有差別的地
方。性能測試工做的關鍵是作好系統分析和功能分析，肯定系統瓶頸所在（這裏參看 ATT
第十章 LoadRunner 的 PPT）。
問題七：在您以往的測試工做中，最讓您感到不滿意或者不堪回首的事情是什麼？您是如
何來對待這些事情的？
問題八：你的測試職業發展目標是什麼？
測試經驗越多，測試能力越高。因此個人職業發展是須要時間累積的，一步步向着高級測試
工程師奔去。並且我也有初步的職業規劃，前 3 年累積測試經驗，不斷的更新本身改正本身，
作好測試任務。
問題九：你對咱們公司瞭解有多少？
建議從招聘廣告上多瞭解信息，同時到應聘公司的網站上去儘量多的瞭解這個公司的情
況，以便回答好這類問題。
問題十：測試結束的標準是什麼？
從微觀上來講，在測試計劃中定義，好比系統在必定性能下平穩運行 72 小時，目前 Bug
Tracking System 中，本版本中沒有通常嚴重的 BUG，普通 BUG 的數量在 3 如下，BUG 修復
率 90%以上等等參數，而後由開發經理，測試經理，項目經理共同簽字認同版本 Release。
若是說宏觀的，則是當這個軟件完全的消失之後，測試就結束了。
1 1 、 軟件測試分爲黑盒和白盒，分別適合什麼狀況？ ？
軟件測試方法通常分爲兩種：白盒測試與黑盒測試。白盒測試又稱爲結構測試、邏輯
驅動測試或基於程序自己的測試，它着重於程序的內部結構及算法，一般不關心功能與性能
指標；黑盒測試又被稱爲功能測試、數據驅動測試或基於規格說明的測試，它其實是站在
最終用戶的立場，檢驗輸入輸出信息及系統性能指標是否符合規格說明書中有關功能需求及
性能需求的規定。
二、一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗
收測試

四、測試用例一般包括那些內容？
不一樣結構的用例包括的不同。（版本、編號、項目、設計人員、設計日期、輸入、
預期輸出„„）
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操
做步驟、預期結果。
用例編號： 測試用例的編號有必定的規則，好比系統測試用例的編號這樣定義規則：
PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測
試用例編號，便於查找測試用例，便於測試用例的跟蹤。
測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。好比 「 測
試用戶登陸時輸入錯誤密碼時，軟件的響應狀況 」 。
重要級別： 定義測試用例的優先級別，能夠籠統的分爲 「 高 」 和 「 低 」 兩個級別。
通常來講，若是軟件需求的優先級爲 「 高 」 ，那麼針對該需求的測試用例優先級也爲
「 高 」 ；反之亦然，通常而言，是 5 級劃分。
測試輸入： 提供測試執行中的各類輸入條件。根據需求中的輸入條件，肯定測試用例的輸
入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，若是軟件需求中沒有很好的定
義需求的輸入，那麼測試用例設計中會遇到很大的障礙。
操做步驟： 提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入須要分爲幾
個步驟完成，這部份內容在操做步驟中詳細列出。
預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。若是在
實際測試過程當中，獲得的實際測試結果與預期結果不符，那麼測試不經過；反之則測試經過。
您是否瞭解以往所工做的企業的軟件開發過程？若是瞭解，請試述一個完整的開發過程須要
完成哪些工做？分別由哪些不一樣的角色來完成這些工做？您在以往的測試工做中都曾經具
體從事過哪些工做？其中最擅長哪部分工做？
開發過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳
細設計(設計人員)、編碼（開發人員）
測試過程---需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單
元測試設計、測試執行
測試工做的整個過程都作過，擅長作測試設計
過程決定質量，軟件的過程改進正是爲了提升軟件的質量，將過往的種種經驗和教訓積累起
來。
在您所經歷的測試活動中，參與人員有哪些？您所擔任的角色是什麼？
有項目管理員、開發管理員、系統分析員、設計員、開發員、質量管理員、測試管理員、測
試設計員、測試員
擔任過測試管理員、測試設計員、測試員
測試用例設計的原則是什麼？目前主要的測試用例設計方法有哪些？
表明性：可以表明並覆蓋各類合理的和不合理、合法的和非法的、邊界的和越界的、以及極
限的輸入數據、操做和環境設置等.
可斷定性：即測試執行結果的正確性是可斷定的，每個測試用例都應有相應的指望結果.
可再現性：即對一樣的測試用例，系統的執行結果應當是相同的。
方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法
面向對象的測試用例設計有幾種方法？如何實現？
給類中的每一個構造函數設計一組測試用例
組合類中的類變量、實例變量
組合類中的各類方法
根據前置條件和後置條件設計測試用例
根據代碼設計測試用例
LoadRunner 分爲哪三個模塊？請簡述各模塊的主要功能。
Virtual User Generator：用於錄製腳步
Mercury LoadRunner Controller：用於建立、運行和監控場景
Mercury LoadRunner Analysis：用於分析測試結果
你對測試最大的興趣在哪裏？爲何？
最大的興趣就是測試有難度，有挑戰性！作測試越久越能感受到作好測試有多難。曾經在無
憂測試網上看到一篇文章，是關於如何作好一名測試工程師。一共羅列了 11，12 點，有部
分是和人的性格有關，有部分須要後天的努力。但除了性格有關的 1，2 點我沒有把握，其
他點我都頗有信心作好它。
剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝着作
測試須要不少技能才能作的好，雖然入門容易，但作好很難，比開發更難，雖然當時我很想
作開發（學校專業課我基本上不缺席，由於我喜歡個人專業），但看到測試比開發更難更有
挑戰性，想作好測試的意志就更堅決了。
我以爲作測試整個過程當中有 2 點讓我以爲頗有難度（對我來講，有難度的東西我就很是感興
趣），第一是測試用例的設計，由於測試的精華就在測試用例的設計上了，要在版本出來之
前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），若是你剛測試一個
新任務時，你得花必定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經
理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這須要你自覺的學習能
力，好比說網站吧，最基本的技術知識你要知道網站內部是怎麼運做的的，後臺是怎麼響應
用戶請求的？測試環境如何搭建？這些都須要最先的學好。至少在開始測試以前能作好基本
的準備，可能會遇到什麼難題？需求細節是否是沒有肯定好？這些問題都能在設計用例的時
候發現。
第二是發現 BUG 的時候了，這應該是測試人員最基本的任務了，通常按測試用例開始測試就
能發現大部分的 bug，還有一部分 bug 須要測試的過程當中更瞭解所測版本的狀況得到更多信
息，補充測試用例，測試出 bug。還有如何發現 bug？這就須要在測試用例有效的狀況下，
經過細心和耐心去發現 bug 了，每一個用例都有可能發現 bug，每一個地方都有可能出錯，因此
測試過程當中思惟要清晰（測試過程數據流及結果都得看仔細了，bug 都在裏面發現的）。如
何描述 bug 也頗有講究，bug 在什麼狀況下會產生，若是條件變化一點點，就不會有這個 bug，

以哪些最少的操做步驟就能重現這個bug，這個bug產生的規律是什麼？若是你夠厲害的話，
能夠幫開發人員初步定位問題。
問題十五：你的測試職業發展目標是什麼？
測試經驗越多，測試能力越高。因此個人職業發展是須要時間累積的，一步步向着高級測試
工程師奔去。並且我也有初步的職業規劃，前 3 年累積測試經驗，按如何作好測試工程師的
11，12 點要求本身，不斷的更新本身改正本身，作好測試任務。
2、您所熟悉的軟件測試類型都有哪些？請試着分別比較這些不一樣的測試類型的區別與聯
系（如功能測試、性能測試„„）
測試類型有：功能測試，性能測試，界面測試。
功能測試在測試工做中佔的比例最大，功能測試也叫黑盒測試。是把測試對象看做一個
黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品的
內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯
誤推測、因果圖和綜合策略。
性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各
項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載
測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指
標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能
提供的最大服務級別的測試。
界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印
象。並且設計良好的界面可以引導用戶本身完成相應的操做，起到嚮導的做用。同時界面如
同人的面孔，具備吸引用戶的直接優點。設計合理的界面能給用戶帶來輕鬆愉悅的感覺和成
功的感受，相反因爲界面設計的失敗，讓用戶有挫敗感，再實用強大的功能均可能在用戶的
畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的全部功能上，要考慮到每一個細節功能，每一個可能存在的
功能問題。性能測試主要關注於產品總體的多用戶併發下的穩定性和健壯性。界面測試更關
注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），
是否美觀（可否吸引用戶的注意力），是否安全（儘可能在前臺避免用戶無心輸入無效的數據，
固然考慮到體驗性，不能太粗魯的彈出警告）？作某個性能測試的時候，首先它多是個功
能點，首先要保證它的功能是沒問題的，而後再考慮該功能點的性能測試
3、請試着比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收 測試的
區別與聯繫。
黑盒測試：已知產品的功能設計規格，能夠進行測試證實每一個實現了的功能是否符合要
求。
白盒測試：已知產品的內部工做過程，能夠經過測試證實每種內部操做是否符合設計規
格要求，全部內部成分是否以通過檢查。
軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看作一個黑
盒子，測試人員徹底不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，
檢查程序的功能是否符合它的功能說明。所以黑盒測試又叫功能測試或數據驅動測試。黑盒
測試主要是爲了發現如下幾類錯誤：
一、是否有不正確或遺漏的功能？
二、在接口上，輸入是否能正確的接受？可否輸出正確的結果？
三、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？四、性能上是否可以知足要求？五、是否有初始化或終止性錯誤？ 軟件的白盒測試是對軟件的過程性細節作細緻的檢查。這種方法是把測試對象看作一個 打開的盒子，它容許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例， 對程序全部邏輯路徑進行測試。經過在不一樣點檢查程序狀態，肯定實際狀態是否與預期的狀 態一致。所以白盒測試又稱爲結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行 以下檢查：一、對程序模塊的全部獨立的執行路徑至少測試一遍。二、對全部的邏輯斷定，取「真」與取「假」的兩種狀況都能至少測一遍。三、在循環的邊界和運行的界限內執行循環體。四、測試內部數據結構的有效性，等等。 單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、 很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下 某個特定函數的行爲。 單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有 責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了 證實這段代碼的行爲和咱們指望的一致。 集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是： 兩個已經測試過的單元組合成一個組件，而且測試它們之間的接口。從這一層意義上講，組 件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程 序的更大部分。方法是測試片斷的組合，並最終擴展進程，將您的模塊與其餘組的模塊一塊兒 測試。最後，將構成進程的全部模塊一塊兒測試。 系統測試是將通過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能 提供系統方案說明書中指定功能的有效方法。（常見的聯調測試） 系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統知足產品需求並 且遵循系統設計。 驗收測試是部署軟件以前的最後一個測試操做。驗收測試的目的是確保軟件準備就緒， 而且可讓最終用戶將其用於執行軟件的既定功能和任務。 驗收測試是向將來的用戶代表系統可以像預約要求那樣工做。經集成測試後，已經按照設計 把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步 驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那 樣。 4、當開發人員說不是 G BUG  時，你如何應付？ 開發人員說不是 bug，有 2 種狀況，一是需求沒有肯定，因此我能夠這麼作，這個時候 能夠找來產品經理進行確認，需不須要改動，3 方商量肯定好後再看要不要改。二是這種情 況不可能發生，因此不須要修改，這個時候，我能夠先儘量的說出是 BUG 的依據是什麼？ 若是被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你不少理由，你能夠對他 的解釋進行反駁。若是仍是不行，那我能夠給這個問題提出來,跟開發經理和測試經理進行 確認,若是要修改就改,若是不要修改就不改。其實有些真的不是 bug，我也只是建議的方式 寫進 TD 中，若是開發人員不修改也沒有大問題。若是肯定是 bug 的話，必定要堅持本身的 立場，讓問題獲得最後的確認。 5、爲何要在一個團隊中開展軟件測試工做？24由於沒有通過測試的軟件很難在發佈以前知道該軟件的質量，就比如 ISO 質量認證同樣，測 試一樣也須要質量的保證，這個時候就須要在團隊中開展軟件測試的工做。在測試的過程發 現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出 軟件的質量狀況。 6、若是有機會轉成開發人員，你會去作開發工做嗎？ 若是公司確實須要我能夠從事開發，但我仍是喜歡作測試，我認爲我更適合作測試。 7、軟件測試分哪些階段？各階段的含義？ 分爲單元測試、集成測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試， 測試獨立模塊；集成測試主要測試模塊之間的接口是否正常，確認測試相似於冒煙測試一般 在大規模系統測試以前驗證版本主要功能是否實現，版本的穩定性是否能夠進入系統測試， 系統測試是全面測試驗證系統是否知足用戶需求包括功能、性能、兼容性等等。驗收測試是 用戶參與的測試。 八 、一份測試計劃應該包括哪些內容？ 背景、項目簡介、目的、測試範圍、測試策略、人員分工、資源要求、進度計劃、參考文檔、 經常使用術語、提交文檔、風險分析。 9、針對於軟件的行業背景，你如何理解軟件的業務？ 閱讀用戶手冊瞭解軟件的功能和操做流程； 看一些業務的專業書籍補充業務知識； 若是有用戶實際的數據，能夠拿實際的數據進行參考； 參考之前的用例和 BUG 報告； 在使用軟件的過程當中多思考； 多與產品經理交流。 10、測試用例應包括哪些內容？ 編號、模塊名稱、編寫人、日期、操做說明、輸入數據、預期結果等。 如何定位測試用例 的做用？ 組織性：編寫、組織性、功能覆蓋、重複性、跟蹤、測試確認 測試過程當中什麼是最重要的？ 需求、計劃。 什麼是兼容性測試？請舉例說明如何利用兼容性測試列表進行測試。 主要驗證軟件產品在不一樣版本之間的兼容性。包括向下兼容和交錯兼容，向下兼容是測試軟 件新版本保留它早期版本功能的狀況，交錯兼容是驗證共同存在的兩個相關但不相同的產品 之間的兼容性。 對某軟件進行測試，發如今 8 WIN98  上運行得很慢，怎麼判別是該軟件存在問題仍是其軟硬 件運行環境存在問題？ 看軟件的運行環境要求。若是符合要求則是程序存在問題，若不符合要求則是硬件系統存在 問題 什麼是等價類劃分法和邊界值分析法？ 需求測試的注意事項有哪些？ 是否使用了公司的模板 文檔內容是否符合規範 全部的需求是分級是否清析適當？ 全部的需求是否具備一致性 需求是否可行（即，該需求組合有解決方案） 需求能否用己知的約束來實現 需求是否足夠（即，能夠把它送到一個規範的開發組織，並有一個生產出所須要產品的合理 的可能性） 全部的其它需求是交叉引用是否正確 用戶描述是否清楚 是否用客戶的語言來描述需求 每一個需求描述是否清楚沒有岐義，能夠移交給一個獨立的組去實現時也能理解 是否全部的需求都是可驗證的 是否每條需求都具備獨立性，即便發生了變化也不會影響其它需求 性能指標是否明確 非功能性需求是否獲得充分表現 是否完整列出適用的標準或協議 標準和協議之間是否存在衝突 請簡述一下缺陷的生命週期。 提交分配處理返測關閉（返測和處理爲循環