這是小編整理的軟件測試常用的技術面試題
請看下面
-
你的測試職業發展是什么?
測試經驗越多，測試能力越高。所以我的職業發展是需要時間積累的，一步步向着高級測試工程師奔去。而且我也有初步的職業規划，前3年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。 -
你認為測試人員需要具備哪些素質
做測試應該要有一定的協調能力，因為測試人員經常要與開發接觸處理一些問題，如果處理不好的話會引起 2、些沖突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。除了耐心，測試人員不能放過每一個可能的錯誤。 -
你為什么能夠做測試這一行
雖然我的測試技術還不是很成熟，但是我覺得我還是可以勝任軟件測試這個工作的，因為做軟件測試不僅是要求技術好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來看我認為我是勝任這個工作的。 -
測試的目的是什么?
測試的目的是找出軟件產品中的錯誤，是軟件盡可能的符合用戶的要求。當然軟件測試是不可能找出全部錯誤的。 -
測試分為哪幾個階段?
一般來說分為5個階段：單元測試、集成測試、確認測試、系統測試、驗收測試 -
單元測試的測試對象、目的、測試依據、測試方法?
測試對象是模塊內部的程序錯誤，目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據是模塊的詳細設計，測試方法是采用白盒測試。 -
怎樣看待加班問題
加班的話我沒有太多意見，但是我還是覺得如果能夠合理安排時間的話，不會有太多時候加班的。 -
結合你以前的學習和工作經驗，你認為如何做好測試。
根據我以前的工作和學習經驗，我認為做好工作首先要有一個良好的溝通，只有溝通無障礙了，才會有好的協作，才會有更好的效率，再一個就是技術一定要過關，做測試要有足夠的耐心，和一個良好的工作習慣，不懂的就要問，實時與同事溝通這樣的話才能做好測試工作。 -
你為什么選擇軟件測試行業
因為之前了解軟件測試這個行業，覺得他的發展前景很好。 -
根據你以前的工作或學習經驗描述一下軟件開發、測試過程，由哪些角色負責，你做什么
要有架構師、開發經理、測試經理、程序員、測試員。我在里面主要是負責所分到的模塊執行測試用例。 -
根據你的經驗說說你對軟件測試/質量保證的理解
軟件質量保證與測試是根據軟件開發階段的規格說明和程序的內部結構而精心設計的一批測試用例(即輸入數據和預期的輸出結果)，並根據這些測試用例去運行程序，以發現錯誤的過程。它是對應用程序的各個方面進行測試以檢查其功能、語言有效性及其外觀排布。 -
軟件測試的流程是什么?
需求調查：全面了解系統概況、應用領域、軟件開發周期、軟件開發環境、開發組織、時間安排、功能需求、性能需求、質量需求及測試要求等。根據系統概況進行項目所需的人員、時間和工作量估計以及項目報價。
制定初步的項目計划。
測試准備：組織測試團隊、培訓、建立測試和管理環境等。
測試設計：按照測試要求進行每個測試項的測試設計，包括測試用例的設計和測試腳本的開發等。
測試實施：按照測試計划實施測試。
測試評估：根據測試的結果，出具測試評估報告。 -
你對SQA的職責和工作活動(如軟件度量)的理解?
SQA就是獨立於軟件開發的項目組，通過對軟件開發過程的監控，來保證軟件的開發流程按照指定的CMM規程(如果有相應的CMM規程),對於不符合項及時提出建議和改進方案，必要時可以向高層經理匯報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少后期軟件的維護成本。SQA主要的工作活動包括制定SQA工作計划，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等;對項目開發過程中產生的數據進行度量等等。 -
說說你對軟件配置管理的理解
項目在開發過程中要用相應的配置管理工具對配置項(包括各個階段的產物)進行變更控制，配置管理的使用取決於項目規模和復雜性及風險的水平。軟件的規模越大，配置管理就越顯得重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標准，隨后的工作便基於此標准，並只有經過授權后才能變更這個標准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用過SVN，對其他的工具不是很熟悉。 -
怎樣寫測試計划和測試用例
簡單點，測試計划里應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至於測試用例，那是依賴於需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。 -
你在測試中發現了一個 bug ，但是開發經理認為這不是一個 bug ，你應該怎樣解決。
首先，將問題提交到缺陷管理庫里面進行備案。然后，要獲取判斷的依據和標准：根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計划有不一致的地方，提供缺陷是否確認的直接依據；如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；根據用戶的一般使用習慣，來確認是否是缺陷；與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並有上級做出決定。 -
給你一個網站，你如何測試？
首先，查找需求說明、網站設計等相關文檔，分析測試需求。制定測試計划，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
設計測試用例,鏈接測試、提交功能的測試和界面測試、性能測試。
數據庫測試：要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
安全性測試：
1 基本的登錄功能的檢查
2 是否存在溢出錯誤，導致系統崩潰或者權限泄露
3 相關開發語言的常見安全性問題檢查，例如 SQL 注入等。
4 如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持兼容性測試，根據需求說明的內容，確定支持的平台組合：瀏覽器的兼容性；操作系統的兼容性；軟件平台的兼容性；數據庫的兼容性開展測試，並記錄缺陷。 -
軟件生存周期及其模型是什么？
軟件生存周期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發布維護的過程。在經歷需求、分析、設計、實現、部署后，軟件將被使用並進入維護階段，直到最后由於缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。 -
什么是軟件測試？軟件測試的目的與原則
使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
軟件測試的目的：
測試是程序的執行過程，目的在於發現錯誤;
軟件測試的原則：
1、軟件測試應盡早執行，並貫穿於整個軟件生命周期
2、軟件測試應追溯需求
3、必須確定預期輸出（或結果）
4、必須徹底檢查每個測試結果
5、嚴格執行測試計划，排除測試的隨意性
6、注意合法合理的輸入，也要注意非法的非預期的輸入
7、檢查程序是否做了不該做的
8、測試應從“小規模”開始，逐步轉向“大規模”
9、反復使用同樣的測試會使軟件具有抵抗力
10、關注缺陷的修復 -
軟件配置管理的作用？軟件配置包括什么？
軟件配置管理作為軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命周期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持作用。一個軟件開發組織真正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具有可重復性，大大提高軟件組織的競爭力。
軟件配置包括如下內容：配置項識別、工作空間管理、版本控制、變更控制、狀態報告和配置審計 -
什么是軟件質量？
軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。 -
目前主要的測試用例設計方法是什么？
1、白盒測試：
邏輯覆蓋、循環覆蓋、基本路徑覆蓋
2、黑盒測試：
邊界值分析法、等價類划分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試和場景法 -
軟件的安全性應從哪幾個方面 去測試？
軟件安全性測試包括程序、數據庫安全性測試。
根據系統安全指標不同測試策略也不同。用戶認證安全的測試要考慮問題：
1、明確區分系統中不同用戶權限，系統中會不會出現用戶沖突，系統會不會因用戶的權限的改變造成混亂；
2、用戶登陸密碼是否是可見、可復制，是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統
3、系統網絡安全的測試要考慮問題，測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上，模擬非授權攻擊，看防護系統是否堅固
4、采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
5、采用各種木馬檢查工具檢查系統木馬情況，采用各種防外掛工具檢查系統各組程序的外掛漏洞
6、數據庫安全考慮問題：
系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）
系統數據的完整性
系統數據可管理性
系統數據的獨立性
系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整） -
什么是測試用例 什么是測試腳本 兩者的關系是什么？
為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。測試腳本是為了進行自動化測試而編寫的腳本。測試腳本的編寫必須對應相應的測試用例 -
簡述什么是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試
靜態測試：不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判
定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，並分析系統運行效率
和健壯性等性能。
黑盒測試：一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得
以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間
的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確
性。
白盒測試：根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員通過閱讀
程序代碼或者通過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理
在程序員開發中來實現。
α測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環
境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。
β測試是：軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在
測試現場，Beta 測試不能由程序員或測試員完成。 -
軟件產品質量特性是什么? ?
功能性：適應性、准確性、互操作性、依從性、安全性。
可靠性：成熟性、容錯性、以恢復性。
可使用性：易理解性、易學習性、易操作性。
效率：時間特性、資源特性。
可維護性：易分析性、易變更性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性。 -
軟件測試的策略是什么? 測試的策略有哪些?
軟件測試策略：在一定的軟件測試標准、測試規范的指導下，依據測試項目的特定環境約束
而規定的軟件測試的原則、方式、方法的集合。
測試策略有黑盒/白盒，靜態/動態，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）。 -
軟件測試分為幾個階段
軟件測試按階段划分可以分為單元測試、集成測試、系統測試和驗收測試4個階段 -
測試人員在軟件開發過程中的任務是什么？
1、尋找 Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關注用戶的需求。
總的目標是：確保軟件的質量。 -
黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點
黑盒測試的優點有：
1、比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關；
2、從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
3、基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
4、在做軟件自動化測試時較為方便。
黑盒測試的缺點有：
1、不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
2、自動化測試的復用性較低。
白盒測試的優點有：
1、幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題
白盒測試的缺點有：
1、程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
2、測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一
些功能需求；
3、系統龐大時，測試開銷會非常大。
-
如何測試一個紙杯？
1、功能度：用水杯裝水看漏不漏；水能不能被喝到；
2、安全性：杯子有沒有毒或細菌；
3、可靠性：杯子從不同高度落下的損壞程度；
4、可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用；
5、兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等；
6、易用性：杯子是否燙手、是否有防滑措施、是否方便飲用；
7、用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述；
8、疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）放 24 小時檢查泄漏時間和情況等
9、壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透 -
測試計划工作的目的是什么？測試計划文檔的內容應該包括什么？其中哪些是最重要的？
答案：軟件測試計划是指導測試過程的綱領性文件。
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試
交流、風險分析等內容。借助軟件測試計划，參與測試的項目成員，尤其是測試管理人員，
可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對
測試過程中的各種變更。
測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划
測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。 -
黑盒測試的測試用例常見設計方法都有哪些？
1） 等價類划分
划分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試因此,可以把全部輸入數據合理划分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類划分可有兩種不同的情況:有效等價類和無效等價類.
2） 邊界值分析法
邊界值分析方法是對等價類划分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.
3）錯誤猜測法
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法
4）因果圖方法
前面介紹的等價類划分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件
之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要
檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件划分成等價類,他們之間的
組合情況也相當多. 因此必須考慮采用一種適合於描述對於多種條件的組合,相應產生多個
動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成
的就是判定表. 它適合於檢查程序輸入條件的各種組合情況.
5）正交表分析法
有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例並
沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表
來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。
6）場景分析方法
指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行
性更好。
7）狀態圖法
通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條
件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。 -
詳細的描述一個測試活動完整的過程。
1、 項目經理通過和客戶的交流，完成需求文檔
2、 開發人員和測試人員共同完成需求文檔的評審，
3、 項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計划。
4、 SQA 進入項目，開始進行統計和跟蹤開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計划文檔，測試計划包括的內容上面有描述。
5、 寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。
6、 測試用例完成后，測試和開發需要進行評審。
7、 測試人員搭建環境,開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現 BUG后提交
8、 開發提交第二個版本,測試人員進行測試。重復上面的工作，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求。如果有客戶反饋的問題，需要測試人員協助重現並重新測試。
9、 -
軟件驗收測試包括 ___ 、 ___ 、 ____ 三種類型。
軟件驗收測試包括正式驗收測試、alpha 測試、beta 測試三種測試。 -
系統測試的策略有 _________等 15 種方法。（該題15 個空）
性能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、分布測試、可用性測試。 -
設計系統測試計划需要參考的項目文檔有 ___ 、 ___ 和 ____ 。
軟件測試計划、軟件需求工件、和迭代計划。 -
軟件測試項目從什么時候開始？為什么？
軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發過程中產生的所有產品都測試,並且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大. -
什么是回歸測試? ?
回歸測試: (regression testing): 回歸測試有兩類：用例回歸和錯誤回歸；
1、 用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。
2、 錯誤回歸，就是在新版本中，對以前版本中出現並修復的缺陷進行再次驗證，並以缺陷為核心，對相關修改的部分進行測試的方法。 -
單元測試、集成測試、系統測試的側重點是什么？
1、單元測試：針對的是軟件設計的最小單元–程序模塊（面向過程中是函數、過程；面向對象中是類）,進行正確性檢驗的測試工作,在於發現每個程序模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
2、集成測試：針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.
3、系統測試：針對的是集成好的軟件系統，作為整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試. -
設計用例的方法有哪些？
1、 白盒測試用例設計有如下方法：邏輯覆蓋、循環覆蓋和基本路徑覆蓋。
2、 黑盒測試用例設計方法：等價類划分、邊界值分析、錯誤猜測、因果圖、狀態圖、測試大綱、場景法、正交策略表。 -
一個測試工程師應具備那些素質？
1、責任心
2、溝通能力
3、團隊合作精神
4、耐心、細心、信心
5、時時保持懷疑態度，並且有缺陷預防的意識
6、具備一定的編程經驗 -
集成測試通常都有那些策略？
基於分解的集成:大爆炸集成\自頂向下集成\自底向上集成\ 三明治集成\基於調用圖的集成\基於路徑的集成\分層集成\基於功能的集成\高頻集成\基於進度的集成\基於風險集成\基於事件集成\基於使用的集成\C/S 集成 -
你所了解的的軟件測試類型都有哪些，簡單介紹一下。
1、 按測試 策略分類：1、靜態與動態測試 2、黑盒與白盒測試 3、手工和自動測試 4、冒煙測試 5、回歸測試；
2、 按測試階段分類：單元測試、集成測試、系統測試；
3、 其他常見測試方法：1、功能測試 2、性能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、界面測試 8、配置測試 9、文檔測試 10、兼容性測試 11、安全性測試 12、恢復測試 -
分別概述創建測試計划與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。 -
您認為做好測試用例設計工作的關鍵是什么？
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題 -
性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？
性能測試的目的主要是發現在並發多用戶和大數據量操作時是否會出現與需求有差異的地方。性能測試工作的關鍵是做好系統分析和功能分析，確定系統瓶頸所在 -
你的測試職業發展目標是什么？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向着高級測試工程師奔去。而且我也有初步的職業規划，前 3 年累積測試經驗，不斷的更新自己改正自己，做好測試任務。 -
測試結束的標准是什么？
從微觀上來說，在測試計划中定義，比如系統在一定性能下平穩運行 72 小時，目前錯誤跟蹤系統中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數量在 3 以下，BUG 修復率 90%以上等等參數，然后由開發經理，測試經理，項目經理共同簽字認同版本 Release。如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結束了。 -
軟件測試分為黑盒和白盒，分別適合什么情況？
1、 白盒測試又稱為結構測試、邏輯驅動測試或基於程序本身的測試，它着重於程序的內部結構及算法，通常不關心功能與性能指標；
2、 黑盒測試又被稱為功能測試、數據驅動測試或基於規格說明的測試，它實際上是站在最終用戶的立場，檢驗輸入輸出信息及系統性能指標是否符合規格說明書中有關功能需求及性能需求的規定。 -
一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試 -
軟件測試用例通常包括那些內容？
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。 -
你的測試職業發展目標是什么？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向着高級測試工程師奔去。而且我也有初步的職業規划，前 3 年累積測試經驗，按如何做好測試工程師的要求自己，不斷的更新自己改正自己，做好測試任務。 -
請試着比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系。
1、 黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
2、 白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
3、 單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。
4、 集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。
5、 系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求並且遵循系統設計。
6、 驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件准備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
55. 當開發人員說不是bug時，你如何應付？
開發人員說不是 bug，有 2 種情況:
一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好后再看要不要改。
二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是 BUG 的依據是什么,如果被用戶發現或出了問題，會有什么不良結果,程序員可能會給你很多理由，你可以對他的解釋進行反駁。
56. 為什么要在一個團隊中開展軟件測試工作？
因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比 ISO 質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告中得出軟件的質量情況。
57. 如果有機會轉成開發人員，你會去做開發工作嗎？
如果公司確實需要我可以從事開發，但我還是喜歡做測試，我認為我更適合做測試。
58. 軟件測試分哪些階段？各階段的含義？
分為單元測試、集成測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試，測試獨立模塊；集成測試主要測試模塊之間的接口是否正常，確認測試類似於冒煙測試通常在大規模系統測試之前驗證版本主要功能是否實現，版本的穩定性是否可以進入系統測試，系統測試是全面測試驗證系統是否滿足用戶需求包括功能、性能、兼容性等等。驗收測試是用戶參與的測試。
59. 一份測試計划應該包括哪些內容？
背景、項目簡介、目的、測試范圍、測試策略、人員分工、資源要求、進度計划、參考文檔、常用術語、提交文檔、風險分析。
60. 針對於軟件的行業背景，你如何理解軟件的業務？
閱讀用戶手冊了解軟件的功能和操作流程；看一些業務的專業書籍補充業務知識；如果有用戶實際的數據，可以拿實際的數據進行參考；參考以前的用例和 BUG 報告；在使用軟件的過程中多思考；多與產品經理交流。
61. 測試用例應包括哪些內容？
編號、模塊名稱、編寫人、日期、操作說明、輸入數據、預期結果等。
62. 什么是兼容性測試？兼容性測試側重哪些方面。
兼容測試主要是檢查軟件在不同的硬件平台、軟件平台上是否可以正常的運行，即是通常說的軟件的可移植性。
兼容的類型，如果細分的話，有平台的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
兼容測試的重點是對兼容環境的分析。通常，是在運行軟件的環境不是很確定的情況下，才需要做兼容。根據軟件運行的需要，或者根據需求文檔，一般都能夠得出用戶會在什么環境下使用該軟件，把這些環境整理成表單，就得出做兼容測試的兼容環境了。
兼容和配置測試的區別在於，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環境下做的。。
63. 對某軟件進行測試，發現在 WIN98 上運行得很慢，怎么判別是該軟件存在問題還是其軟硬件運行環境存在問題？
看軟件的運行環境要求。如果符合要求則是程序存在問題，若不符合要求則是硬件系統存在問題
64. 我現在有個程序，發現在Windows上運行得很慢，怎么判別是程序存在問題還是軟硬件系統存在問題？
1、檢查系統是否有中毒的特征；
2、檢查軟件/硬件的配置是否符合軟件的推薦標准；
3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU資源的服務；
4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況。
65. 正交表測試用例設計方法的特點是什么？
用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；
對於基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
66. 描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程？
就是Bugzilla的狀態轉換圖。
67. 你覺得bugzilla在使用的過程中，有什么問題？
界面不穩定；
根據需要配置它的不同的部分，過程很煩瑣。
流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；
沒有綜合的評分指標，不好確認修復的優先級別。
68. 描述測試用例設計的完整過程？
需求分析 + 需求變更的維護工作；
根據需求 得出測試需求；
設計測試方案，評審測試方案；
方案評審通過后，設計測試用例，再對測試用例進行評審；
69. 單元測試的策略有哪些？
邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
70. LoadRunner分哪三部分？
用戶動作設計；場景設計；測試數據分析；
71. LoadRunner進行測試的流程?
- 測試測試
- 創建虛擬用戶腳本
- 創建運行場景
- 運行測試腳本
- 監視場景
- 分析測試的結果
以上，最好是結合一個案例，根據以上流程來介紹。 - 什么是並發？在LoadRunner中，如何進行並發的測試？集合點失敗了會怎么樣？
在同一時間點，支持多個不同的操作。
LoadRunner中提供IP偽裝，集合點，配合虛擬用戶的設計，以及在多台電腦上設置，可以比較好的模擬真實的並發。
集合點，即是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操作的。集合點失敗，則集合點的才操作就會取消，測試就不能進行。 - 使用QTP做功能測試，錄制腳本的時候，要驗證多個用戶的登錄情況/查詢情況，如何操作？
分析用戶登錄的基本情況，得出一組數據，通過性測試/失敗性測試的都有（根據TC來設計這些數據），然后錄制登錄的腳本，將關鍵的數據參數化，修改腳本，對代碼進行加強，調試腳本。 - QTP中的Action有什么作用？有幾種？
Action的作用
用Action可以對步驟集進行分組
步驟重組，然后被整體調用
擁有自己的sheet
組合有相同需求的步驟，整體操作
具有獨立的對象倉庫
Action的種類
可復用Action
不可復用Action
外部Action - TestDirector有些什么功能，如何對軟件測試過程進行管理？
需求管理
定義測試范圍
定義需求樹
描述需求樹的功能點
測試計划
定義測試目標和測試策略。
分解應用程序，建立測試計划樹。
確定每個功能點的測試方法。
將每個功能點連接到需求上，使測試計划覆蓋全部的測試需求。
描述手工測試的測試步驟
指明需要進行自動測試的功能點
測試執行
定義測試集合。
為每個測試人員制定測試任務和測試日程安排。
運行自動測試。
缺陷跟蹤
記錄缺陷
查看新增缺陷，並確定哪些是需要修正的
相關技術人員修改缺陷
回歸測試
分析缺陷統計圖表，分析應用程序的開發質量。 - 軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
5C標准 - Beta測試與Alpha測試有什么區別？
Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場
Alpha testing (α測試),是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試 - 軟件的評審一般由哪些人參加？其目的是什么？
在正式的會議上將軟件項目的成果（包括各階段的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並采取補救措施，以及找出在性能、安全性和經濟方面的可能的改進。
人員：用戶、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段 - 測試****活動中，如果發現需求文檔不完善或者不准確，怎么處理？
測試需求分析 發現需求文檔不完善或者不准確，應該立即和相關人員進行協調交流。 - 階段評審與項目評審有什么區別？
階段評審 對項目各階段評審：對階段成果和工作
項目評審 對項目總體評審：對工作和產品 - 闡述工作版本的定義？
構造號： BUILD - 什么是樁模塊？什么是驅動模塊？
樁模塊：被測模塊調用模塊
驅動模塊 調用被測模塊 - 什么是扇入？什么是扇出？
扇入：被調次數，扇出：調其它模塊數目 - 你認為做好測試計划工作的關鍵是什么？
軟件測試計划就是在軟件測試工作正式實施之前明確測試的對象，並且通過對資源、時間、風險、測試范圍和預算等方面的綜合分析和規划，保證有效的實施軟件測試；
做好測試計划工作的關鍵 ：目的，管理，規范 - 明確測試的目標，增強測試計划的實用性
編寫軟件測試計划得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計划的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計划中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、准確
2．堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規則創建軟件測試計划，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
3．采用評審和更新機制，保證測試計划滿足實際需求
測試計划寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計划內容的可能不准確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計划的內容沒有及時更新，誤導測試執行人員。 - 分別創建測試計划與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。 - 你認為做好測試用例工作的關鍵是什么？
需求和設計文檔的理解程度，對系統的熟悉程度 - 簡述一下缺陷的生命周期？
提交->確認->分配->修復->驗證->關閉 - 軟件的安全性應從哪幾個方面去測試？
- 用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議
- 加密機制
- 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描
- 數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理
- 防病毒系統
- 軟件配置管理工作開展的情況和認識？
軟件配置管理貫穿於軟件開發、測試活動的始終，覆蓋了開發、測試活動的各個環節，它的重要作用之一就是要全面的管理保存各個配置項，監控各配置項的狀態，並向項目經理及相關的人員報告，從而實現對軟件過程的控制。
軟件測試配置管理包括4個最基本的活動：
配置項標識
配置項控制
配置項狀態報告
配置審計
軟件配置管理通常借助工具來輔助，主要有MS SourceSafe、Rational ClearCase等 - 你覺得軟件測試通過的標准應該是什么樣的？
缺陷密度值達到客戶的要求 - 引入測試管理的含義？
風險分析，進度控制、角色分配、質量控制 - 一套完整的測試應該由哪些階段組成？
測試計划、測試設計與開發、測試實施、測試評審與測試結論 - 單元測試的主要內容？
模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試 - 集成測試也叫組裝測試或者聯合測試，請簡述集成測試的主要內容？
（1）在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；
（2）一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
（3）各個子功能組合起來，能否達到預期要求的父功能；
（4）全局數據結構是否有問題；
（5）單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。 - 簡述集成測試與系統測試關系？
（1）集成測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；
（2）集成測試是系統模塊的測試，系統測試是對整個系統的測試，包括相關的軟硬件平台、網絡以及相關外設的測試。 - 軟件測試的文檔測試應當貫穿於軟件生命周期的全過程，其中用戶文檔是文檔測試的重點。那么軟件系統的用戶文檔包括哪些？
用戶手冊
安裝和設置指導
聯機幫助
指南、向導
樣例、示例和模板
授權/注冊登記表
最終用戶許可協議 - 軟件系統中除用戶文檔之外，文檔測試還應該關注哪些文檔？
開發文檔
軟件需求說明書
數據庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
管理文檔
項目開發計划
測試計划
測試報告
開發進度月報
開發總結報告 - 簡述軟件系統中用戶文檔的測試要點？
（1）讀者群。文檔面向的讀者定位要明確。對於初級用戶、中級用戶以及高級用戶應該有不同的定位
（2）術語。文檔中用到的術語要適用與定位的讀者群，用法一致，標准定義與業界規范相吻合。
（3）正確性。測試中需檢查所有信息是否真實正確，查找由於過期產品說明書和銷售人員誇大事實而導致的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試鏈接是否准確，產品支持電話、地址和郵政編碼是否正確。
（4）完整性。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到。
（5）一致性。按照文檔描述的操作執行后，檢查軟件返回的結果是否與文檔描述的相同。
（6）易用性。對關鍵步驟以粗體或背景色給用戶以提示，合理的頁面布局、適量的圖表都可以給用戶更高的易用性。需要注意的是文檔要有助於用戶排除錯誤。不但描述正確操作，也要描述錯誤處理辦法。文檔對於用戶看到的錯誤信息應當有更詳細的文檔解釋。
（7）圖表與界面截圖。檢查所有圖表與界面截圖是否與發行版本相同。
（8）樣例與示例。像用戶一樣載入和使用樣例。如果是一段程序，就輸入數據並執行它。以每一個模塊制作文件，確認它們的正確性。
（9）語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是屏幕截圖或繪制圖形中的文字。
（10）印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。 - 如何理解強度測試？
強度測試是為了確定系統在最差工作環境的工作能力,也可能是用於驗證在標准工作壓力下的各種資源的最下限指標。
它和壓力測試的目標是不同的,壓力測試是在標准工作環境下,不斷增加系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峰值),而強度測試則是在非標准工作環境下,甚至不斷人為降低系統工作環境所需要的資源,如網絡帶寬,系統內存,數據鎖等等,以測試系統在資源不足的情況下的工作狀態,通過強度測試,可以確定本系統正常工作的最差環境.
強度測試和壓力測試的測試指標相近,大多都是與時間相關的指標,如並發量(吞吐量),延遲(最大\最小\平均)以及順序指標等
強度測試需要對系統的結構熟悉,針對系統的特征設計強度測試的方法 - 如何理解壓力、負載、性能測試測試？
- 性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。
壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。 - 而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那么連續訪問8個小時就可以認為負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。 - 什么是系統瓶頸？
瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。
嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，內存也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求。在用戶極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶工作。
因此我們測試系統瓶頸主要是實現下面兩個目的：
-發現“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測試的基本目標。
-發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化。滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟件生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化。 - 文檔測試主要包含什么內容？
在國內軟件開發管理中，文檔管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文檔測試也就不足為奇了。要想給用戶提供完整的產品，文檔測試是必不可少的。文檔測試一般注重下面幾個方面：
文檔的完整性：主要是測試文檔內容的全面性與完整性，從總體上把握文檔的質量。例如用戶手冊應該包括軟件的所有功能模塊。
描述與軟件實際情況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致。因為文檔往往跟不上軟件版本的更新速度。
易理解性：主要是檢查文檔對關鍵、重要的操作有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了。
文檔中提供操作的實例：這項檢查內容主要針對用戶手冊。對主要功能和關鍵操作提供的應用實例是否豐富，提供的實例描述是否詳細。只有簡單的圖文說明，而無實例的用戶手冊看起來就像是軟件界面的簡單拷貝，對於用戶來說，實際上沒有什么幫助。
印刷與包裝質量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過於粗糙，不易於用戶保存。優秀的文檔例如用戶手冊和技術白皮書，應提供商品化包裝，並且印刷精美。 - 功能測試用例需要詳細到什么程度才是合格的？
這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什么都要寫出來，目的是即使一個不了解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟件外包文檔都是這樣做的。
另外一種觀點就是主張寫的粗些，類似於編寫測試大綱。主張這種觀點的人是因為軟件開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標准來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。
實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：“用戶登陸系統”的測試用例可以不寫出具體的執行數據，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以采用等價划分）。
另一個影響測試用例的就是組織的開發能力和測試對象特點。如果開發力量比較落后，編寫較詳細的測試用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨着團隊的發展而逐漸有所改善。測試對象特點重點是指測試對象在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。
因此，測試用例的編寫要根據測試對象特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最后要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。 - 配置和兼容性測試的區別是什么？
配置測試的目的是保證軟件在其相關的硬件上能夠正常運行，而兼容性測試主要是測試軟件能否與不同的軟件正確協作。
配置測試的核心內容就是使用各種硬件來測試軟件的運行情況，一般包括：
（1）軟件在不同的主機上的運行情況，例如Dell和Apple；
（2）軟件在不同的組件上的運行情況，例如開發的撥號程序要測試在不同廠商生產的Modem上的運行情況；
（3）不同的外設；
（4）不同的接口；
（5）不同的可選項，例如不同的內存大小；
兼容性測試的核心內容：
（1）測試軟件是否能在不同的操作系統平台上兼容；
（2）測試軟件是否能在同一操作系統平台的不同版本上兼容；
（3）軟件本身能否向前或者向后兼容；
（4）測試軟件能否與其它相關的軟件兼容；
（5）數據兼容性測試，主要是指數據能否共享；
配置和兼容性測試通稱對開發系統類軟件比較重要，例如驅動程序、操作系統、數據庫管理系統等。具體進行時仍然按照測試用例來執行。 - 軟件文檔測試主要包含什么？
隨着軟件文檔系統日益龐大，文檔測試已經成為軟件測試的重要內容。文檔測試對象主要如下：
-包裝文字和圖形；
-市場宣傳材料、廣告以及其它插頁；
-授權、注冊登記表；
-最終用戶許可協議；
-安裝和設置向導；
-用戶手冊；
-聯機幫助；
-樣例、示范例子和模板；
-……
文檔測試的目的是提高易用性和可靠性，降低支持費用，因為用戶通過文檔就可以自己解決問題。因文檔測試的檢查內容主要如下：
-讀者對象——主要是文檔的內容是否能讓該級別的讀者理解；
-術語——主要是檢查術語是否適合讀者；
-內容和主題——檢查主題是否合適、是否丟失、格式是否規范等；
-圖標和屏幕抓圖——檢查圖表的准確度和精確度；
-樣例和示例——是否與軟件功能一致；
-拼寫和語法；
-文檔的關聯性——是否與其它相關文檔的內容一致，例如與廣告信息是否一致；
文檔測試是相當重要的一項測試工作，不但要給予充分的重視，更要要認真的完成，象做功能測試一樣來對待文檔測試。 - 沒有產品說明書和需求文檔地情況下能夠進行黑盒測試嗎？
這個問題是國內測試工程師經常遇到的問題，根源就是國內軟件開發文檔管理不規范，對變更的管理方法就更不合理了。實際上沒有任何文檔的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入了解測試對象、理解軟件功能，進而發現缺陷。
在這種做法基本上把軟件當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作項目的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。 - 測試中的“殺蟲劑怪事”是指什么？
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用於描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農葯，害蟲就會有免疫力，農葯發揮不了效力。這種現象的根本原因就是測試人員對測試軟件過於熟悉，形成思維定勢。
為了克服這種現象，測試人員需要不斷編寫新的測試程序或者測試用例，對程序的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟件，剛剛進來的新手往往能發現一些意想不到的問題。 - 在配置測試中，如何判斷發現的缺陷是普通問題還是特定的配置問題？
在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。因此判斷新發現的問題，需要在不同的配置中重新執行發現軟件缺陷的步驟，如果軟件缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷。
需要注意的是，配置問題可以在一大類配置中出現。例如，撥號程序可能在所有的外置Modem中都存在問題，而內置的Modem不會有任何問題。 - 為什么盡量不要讓時間有富裕的員工去做一些測試？
表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮並富有耐心，善於學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。如果他是專職的，那么肯定更有經驗和信心。國內的小伙子好象都喜歡做程序員，兩者工作性質不同，待遇不同，地位不同，對自我實現的價值的認識也不同，這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它工作中都是不行的。 - 完全測試程序是可能的嗎？
軟件測試初學者可能認為拿到軟件后需要進行完全測試，找到全部的軟件缺陷，使軟件“零缺陷”發布。實際上完全測試是不可能的。主要有以下一個原因：
-完全測試比較耗時，時間上不允許；
-完全測試通常意味着較多資源投入，這在現實中往往是行不通的；
-輸入量太大，不能一一進行測試；
-輸出結果太多，只能分類進行驗證；
-軟件實現途徑太多；
-軟件產品說明書沒有客觀標准，從不同的角度看，軟件缺陷的標准不同；
因此測試的程度要根據實際情況確定。 - 軟件測試的風險主要體現在哪里？
我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員為了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發布前這些代碼中的一些沒有被注釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現。
因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小。 - 發現的缺陷越多，說明軟件缺陷越多嗎？
這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：
-代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。
-程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。程序員加班是一種司空見慣的現象，因此體力不只時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。
“缺陷一個連着一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。 - 所有的軟件缺陷都能修復嗎？所有的軟件缺陷都要修復嗎？
從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對於整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：
-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。
-有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以后升級中進行修復。
-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。
最后要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。 - 軟件測試人員就是QA嗎？
軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是創建或者制定標准和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。
軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。 - 如何減少測試人員跳槽帶來的損失？
在IT行業里跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失。測試隊伍也無疑會面臨跳槽的威脅，作為測試經理管理者，只有從日常工作中開始做起，最能最大限度的減少損失。建議我們從以下兩個方面做起：
-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。
-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業。因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規划並付諸實現。不過這項要求做起來比較，要有比較好的企業文化為依托。 - 測試產品與測試項目的區別是什么？
習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產品，也就是可以買“賣拷貝”的軟件，例如Windows2000。而通常把針對一個或者幾個特定的用戶而開發的軟件成為軟件項目，軟件項目是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟件產品來滿足特定的用戶需求。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：
-質量要求不同。通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了。
-測試資源投入多少不同。做軟件產品通常是研發中心來開發，進度壓力要小些。同時由於質量要求高，因此會投入較多的人力、物力資源。
-項目最后要和用戶共同驗收測試，這是產品測試不具有的特點。
此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作。 - 用戶共同測試（UAT測試）的注意點有哪些？
軟件產品在投產前，通常都會進行用戶驗收測試。如果用戶驗收測試沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而后者的影響往往更嚴重。根據作者的經驗，用戶驗收測試一定要讓用戶滿意。
實際上用戶現場測試更趨於是一種演示。在不欺騙用戶的前提下，我們向用戶展示我們軟件的優點，最后讓“上帝”滿意並欣然掏出“銀子”才是我們的目標。因此用戶測試要注意下面的事項：
（1）用戶現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好准備，這些核心功能一定要預先經過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。
（2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。
（3）永遠不能欺騙用戶，蒙混過關。道理很簡單，因為軟件是要給用戶用的，問題早晚會暴露出來，除非你可以馬上修改。
和用戶進行測試還要注意各種交流技巧，爭取不但短期利益得到了滿足，還要為后面得合作打好基礎。 - 如何編寫提交給用戶的測試報告？
隨着測試工作越來越受重視，開發團隊向客戶提供測試文檔是不可避免的事情。很多人會問：“我們可以把工作中的測試報告提供給客戶嗎？”答案是否定的。因為提供內部測試報告，可能會讓客戶失去信心，甚至否定項目。
測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況，這里不過多討論，讀者可以參考相關教材。這里主要討論一下外部測試報告的寫法，一般外部測試報告要滿足下面幾個要求：
-根據內部測試報告進行編寫，一般可以摘錄；
-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；
-報告上面的內容盡量要真實可靠；
-整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。
總之，外部測試報告要小心謹慎的編寫。 - 測試工具在測試工作中是什么地位？
國內的很多測試工程師對測試工具相當迷戀，尤其是一些新手，甚至期望測試工具可以取代手工測試。測試工具在測試工作中起的是輔助作用，一般用來提高測試效率。自動化測試彌補了手工測試的不足，減輕一定的工作量。實際上測試工具是無法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。
對於自動測試技術，應當依據軟件的不同情況來分別對待，一般自動技術會應用在引起大量重復性工作的地方、系統的壓力點、以及任何適合使用程序解決大批量輸入數據的地方。然后再尋找合適的自動測試工具，或者自己開發測試程序。一定不要為了使用測試工具而使用。 - 簡述負載測試與壓力測試的區別。
壓力測試（Stress Testing）
壓力測試的主要任務就是獲取系統正確運行的極限，檢查系統在瞬間峰值負荷下正確執行的能力。例如，對服務器做壓力測試時就可以增加並發操作的用戶數量；或者不停地向服務器發送請求；或一次性向服務器發送特別大的數據等。看看服務器保持正常運行所能達到的最大狀態。人們通常使用測試工具來完成壓力測試，如模擬上萬個用戶從終端同時登錄，這是壓力測試中常常使用的方法。
負載測試（Volume Testing）
用於檢查系統在使用大量數據的時候正確工作的能力，即檢驗系統的能力最高能達到什么程度。例如，對於信息檢索系統，讓它使用頻率達到最大；對於多個終端的分時系統，讓它所有的終端都開動。在使整個系統的全部資源達到“滿負荷”的情形下，測試系統的承受能力。 - 寫出bug報告流轉的步驟，每步的責任人及主要完成的工作。
（要結合自己實際的工作經驗進行回答，不同公司略有區別）
測試人員提交新的Bug入庫，錯誤狀態為New。
高級測試員/測試經理驗證錯誤，如果確認是錯誤，分配給開發組。設置狀態為Open。如果不是錯誤，則拒絕，設置為Declined狀態。
開發經理分配bug至對應的模塊開發人員。
開發人員查詢狀態為Open的Bug，如果不是錯誤，則置狀態為Declined；如果是Bug則修復並置狀態為Fixed。不能解決的Bug，要留下文字說明及保持Bug為Open狀態。
對於不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可。
測試人員查詢狀態為Fixed的Bug，然后驗證Bug是否已解決，如解決，置Bug的狀態為Closed，如沒有解決,置bug狀態為Reopen。 - 寫出bug報告當中一些必備的內容。
硬件平台和操作系統
測試應用的硬件平台（Platform），通常選擇“PC”。
測試應用的操作系統平台（OS）。
a) 版本
提交缺陷報告時通過該字段標識此缺陷存在於被測試軟件的哪個版本。
b) Bug報告優先級
c) Bug狀態
d) Bug的編號
e) 發現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關系
j) 詳細描述
k) 嚴重程度
l) 所屬模塊
m) 附件
n) 提交日期 - 開發人員老是犯一些低級錯誤怎么解決？
這種現象在開發流程不規范的團隊里特別常見，尤其是一些“作坊式”的團隊里。解決這種問題一般從兩個方面入手：
一方面從開發管理入手，也就是從根源來解決問題。可以制定規范的開發流程，甚至可以制定懲罰制度，還有就是軟件開發前做好規划設計。
另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題“消滅”在開發階段，這是比較好的做法，讀者可以參考第13章試案例分析的“13.1.2缺陷反復出現，誰的責任”小節，13.1.2專門討論了這類問題的方法。
此外，還可以通過規范的缺陷管理來對開發人員進行控制，比如測試部門整理出常見的缺陷，讓開發人員自己對照進行檢查，以減少這類低級錯誤的發生。
開發人員犯錯誤是正常的現象，作為測試人員一定不能抱怨，要認認真真的解決問題才是上策。
- 為什么要在一個團隊中開展軟件測試工作？
因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告中得出軟件的質量情況。 - 您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
（根據項目經驗不同，靈活回答即可）
我曾經做過web測試，后台測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試 - 您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
1．等價類划分
划分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理划分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類划分可有兩種不同的情況:有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類划分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.
3．錯誤推測法
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
4．因果圖方法
前面介紹的等價類划分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件划分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程序輸入條件的各種組合情況. - 請以您以往的實際工作為例，詳細的描述一次測試用例設計的完整的過程。
就說最近的這次網站功能的測試吧
首先：得到相關文檔（需求文檔和設計文檔），理解需求和設計設計思想后，想好測試策略（測試計划簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。
第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，然后在進行系統測試（另外個模塊呢有另一個測試人員負責，可以進行聯調測試），網站模塊的測試基本是功能測試和界面測試（用戶並發的可能性很小，所以不考慮）：這次的網站的輸入數據呢是使用數據庫中的某張表記錄，如果表中某一數據記錄中新加進來的（還沒有被處理的，有個標志位），網站啟動后會立刻去刷那張表，得到多條數據，然后在進行處理。處理過程中，會經歷3個步驟，網站才算完成了它的任務。有3個步驟呢，就可以分別對 這3個步驟進行測試用例的設計,盡量覆蓋到各種輸入情況（包括數據庫中的數據，用戶的輸入等），得出了差不多50個用例。界面測試，也就是用戶看的到的地方，包括發送的郵件和用戶填寫資料的頁面展示。
第三步：搭建測試環境（為什么這個時候考慮測試環境呢？因為我對網站環境已經很熟了，只有有機器能空於下來做該功能測試就可以做了），因為網站本身的環境搭建和其他的系統有點不同，它需要的測試環境比較麻煩，需要web服務器（Apache,tomcat），不過這次需求呢，網站部分只用到了tomcat，所以只要有tomcat即可
第四步：執行測試 - 您以往是否曾經從事過性能測試工作？如果有，請盡可能的詳細描述您以往的性能測試工作的完整過程。
（以自己最熟悉的性能測試項目為例）
是的，曾經做過網站方面的性能測試，雖然做的時間並不久（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 ：嘗試鏈接數； - 你對測試最大的興趣在哪里？為什么？
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分需要后天的努力。但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它。 - 你以前工作時的測試流程是什么？
（靈活回答）
公司對測試流程沒有規定如何做，但每個測試人員都有自己的一套測試流程。我說下我1年來不斷改正（自己總結，吸取同行的方法）后的流程吧。需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求確定(出一份確定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員的確定（嚴重級別的，或突然發現的在測試用例范圍之外的，難以重現的），有些可以直接錄制進TD）－>開發人員修改（可以在測試過程中快速的修改）－>回歸測試（可能又會發現新問題，再按流程開始跑）。 - 當開發人員說不是BUG時，你如何應付？
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認。 - 軟件的構造號與版本號之間的區別？BVT(BuildVerificationTest)
版本控制命名格式: 主版本號.子版本號[.修正版本號[.編譯版本號 ]]
Major.Minor [.Revision[.Build]]
應根據下面的約定使用這些部分：
Major ：具有相同名稱但不同主版本號的程序集不可互換。例如，這適用於對產品的大量重寫，這些重寫使得無法實現向后兼容性。
Minor ：如果兩個程序集的名稱和主版本號相同，而次版本號不同，這指示顯著增強，但照顧到了向后兼容性。例如，這適用於產品的修正版或完全向后兼容的新版本。
Build ：內部版本號的不同表示對相同源所作的重新編譯。這適合於更改處理器、平台或編譯器的情況。
Revision ：名稱、主版本號和次版本號都相同但修訂號不同的程序集應是完全可互換的。這適用於修復以前發布的程序集中的安全漏洞。
BVT(BuildVerificationTest)：
作為Build的一部分，主要是通過對基本功能、特別是關鍵功能的測試，保證新增代碼沒有導致功能失效，保證版本的持續穩定。實現BVT方式是有以下幾種：1、測試人員手工驗證關鍵功能實現的正確性。特點：這是傳統開發方法中，通常采用的方式。無需維護測試腳本的成本，在測試人力資源充足，測試人員熟悉業務、並對系統操作熟練情況下效率很高，比較靈活快速。缺點：人力成本較高；對測試人員能力有一定要求；測試人員面對重復的工作，容易產生疲倦懈怠，從而影響測試質量。2、借助基於GUI的自動化功能測試工具來完成，將各基本功能操作錄制成測試腳本，每次回放測試腳本驗證功能實現的正確性。特點：能夠模擬用戶操作完成自動的測試，從UI入口到業務實現，每一層的代碼實現都經過驗證；節約人力成本；降低測試人員重復勞動的工作量，機器不會疲倦；缺點：對於UI變動比較頻繁的系統來說，這種方式的維護成本很高，實施起來非常困難。另外，在項目周期較短且后續無延續性或繼承的情況下，也不推薦使用此方式。3、由開發人員通過自動化測試工具完成業務層的BVT測試。特點：通過對業務層關鍵功能的持續集成測試，保證系統功能的持續穩定。可以結合DailyBuild，做為Build的一部分，自動實現並輸入BVT報告。缺點：僅對業務規則實現的正確性進行了測試，對表現層無法測試到，對於諸如：前台頁面控件各種事件響應、頁面元素變化等方面的問題無法保證。
加粗樣式