軟件測試面試題和答案

1、一、判斷題1軟件測試的目的是盡可能多的找出軟件的缺陷。（Y ）2Beta 測試是驗收測試的一種。（Y ）3驗收測試是由最終用戶來實施的。（N ）4項目立項前測試人員不需要提交任何工件。（Y ）5單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（Y ）6代碼評審是檢查源代碼是否達到模塊設(shè)計的要求。（N ）7自底向上集成需要測試員編寫驅(qū)動程序。（Y ）8負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。（N ）9測試人員要堅持原則，缺陷未修復(fù)完堅決不予通過。（N ）10代碼評審員一般由測試員擔任。（N ）11我們可以人為的使得軟件不存在配臵問題。（N ）12集成測試計劃在需求分析階段末提交。（N ）二、選折1

2、軟件驗收測試的合格通過準則是：（ABCD ）A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。B 所有測試項沒有殘余一級、二級和三級錯誤。C 立項審批表、需求分析文檔、設(shè)計文檔和編碼實現(xiàn)一致。D 驗收測試工件齊全。2軟件測試計劃評審會需要哪些人員參加？（ABCD ）A 項目經(jīng)理B SQA 負責(zé)人C 配臵負責(zé)人D 測試組3下列關(guān)于alpha 測試的描述中正確的是：（AD ）A alpha 測試需要用戶代表參加B alpha 測試不需要用戶代表參加C alpha 測試是系統(tǒng)測試的一種D alpha 測試是驗收測試的一種4測試設(shè)計員的職責(zé)有：（BC ）A 制定測試計劃B 設(shè)計測

3、試用例C 設(shè)計測試過程、腳本D 評估測試活動5軟件實施活動的進入準則是：（ABC ）A 需求工件已經(jīng)被基線化B 詳細設(shè)計工件已經(jīng)被基線化C 構(gòu)架工件已經(jīng)被基線化D 項目階段成果已經(jīng)被基線化三、添空1. 軟件驗收測試包括：正式驗收測試，alpha 測試，beta 測試。2. 系統(tǒng)測試的策略有：功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配臵測試，安裝測試，卸載測試，文擋測試，故障恢復(fù)測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試，（有的可以合在一起，分開寫只要寫出15就滿分哦）3. 設(shè)計系統(tǒng)測試計劃需要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計

4、劃。4. 對面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。5. （這題出的有問題哦，詳細的5步驟為）通過畫因果圖來寫測試用例的步驟為：（1）分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結(jié)果（即輸出條件），并給每個原因和結(jié)果賦予一個標識符。（2）分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應(yīng)的是什么關(guān)系? 根據(jù)這些關(guān)系，畫出因果圖。（3）由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。（4）把因果圖轉(zhuǎn)換成判定表。（5）把判定表的每一列拿出來作為依據(jù)

5、，設(shè)計測試用例。四、簡答（資料是搜集整理的，感謝前輩的解題）無1. 區(qū)別階段評審的與同行評審?fù)性u審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤, 只要是找錯誤;階段評審目的:評審模塊階段作品的正確性可行性及完整性同行評審人數(shù):3-7人人員必須經(jīng)過同行評審會議的培訓(xùn), 由SQA 指導(dǎo)階段評審人數(shù):5人左右評審人必須是專家具有系統(tǒng)評審資格同行評審內(nèi)容:內(nèi)容小一般文檔< 40頁, 代碼< 500行階段評審內(nèi)容:內(nèi)容多, 主要看重點同行評審時間:一小部分工作產(chǎn)品完成階段評審時間:通常是設(shè)臵在關(guān)鍵路徑的時間點上!2. 什么是軟件測試為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程3簡述集成測試的過程系統(tǒng)集成測試主要

6、包括以下過程：1. 構(gòu)建的確認過程。2. 補丁的確認過程。3. 系統(tǒng)集成測試測試組提交過程。4. 測試用例設(shè)計過程。5. 測試代碼編寫過程。6. Bug 的報告過程。7. 每周/每兩周的構(gòu)建過程。8. 點對點的測試過程。9. 組內(nèi)培訓(xùn)過程。4怎么做好文檔測試仔細閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例。P142檢查文檔的編寫是否滿足文檔編寫的目的內(nèi)容是否齊全，正確內(nèi)容是否完善標記是否正確5白盒測試有幾種方法總體上分為靜態(tài)方法和動態(tài)方法兩大類。靜態(tài)：關(guān)鍵功能是檢查軟件的表示和描述是否一致, 沒有沖突或者沒有歧義動態(tài)：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。6系統(tǒng)

7、測試計劃是否需要同行審批，為什么需要，系統(tǒng)測試計劃屬于項目階段性關(guān)鍵文檔，因此需要評審。7Alpha 測試與beta 的區(qū)別Alpha 測試在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試；測試后仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。Beta 測試當開發(fā)和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。8比較負載測試，容量測試和強度測試的區(qū)別負載測試：在一定的工作負荷下，系統(tǒng)的負荷及響應(yīng)時間。強度測試：在一定的負荷條件下，在較長時間跨度內(nèi)的系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響。容量

8、測試：容量測試目的是通過測試預(yù)先分 析出反映軟件 系統(tǒng)應(yīng)用特征的某項指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運行。容量測試 還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負載或工作量。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。容量測試是面向數(shù)據(jù) 的，并且它的目的是顯示系統(tǒng)可以處理目標內(nèi)確定的數(shù)據(jù)容量。 9測試結(jié)束的標準是什么？用例全部測試。覆蓋率達到標準。缺陷率達到標準。其他指標達到質(zhì)量標準10描述軟件測試活動的生命周期？測試周期分為計劃、設(shè)計、實現(xiàn)、執(zhí)行、總結(jié)。其中：計劃：對整個測試周期中所有活動

9、進行規(guī)劃，估計工作量、風(fēng)險，安排人力物力資源，安排進度等；設(shè)計：完成測試方案，從技術(shù)層面上對測試進行規(guī)劃；實現(xiàn)：進行測試用例和測試規(guī)程設(shè)計；執(zhí)行：根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例?？偨Y(jié)：記錄測試結(jié)果，進行測試分析，完成測試報告。11軟件的缺陷等級應(yīng)如何劃分？A 類嚴重錯誤，包括以下各種錯誤： 1 由于程序所引起的死機, 非法退出 2 死循環(huán) 3 數(shù)據(jù)庫發(fā)生死鎖 4 因錯誤操作導(dǎo)致的程序中斷 5 功能錯誤 6 與數(shù)據(jù)庫連接錯誤 7 數(shù)據(jù)通訊錯誤B 類較嚴重錯誤，包括以下各種錯誤： 1 程序錯誤 2 程序接口錯誤 3 數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件C 類一

10、般性錯誤，包括以下各種錯誤： 1 操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致） 2 打印內(nèi)容、格式錯誤 3 簡單的輸入限制未放在前臺進行控制 4 刪除操作未給出提示 5 數(shù)據(jù)庫表中有過多的空字段D 類較小錯誤，包括以下各種錯誤： 1 界面不規(guī)范 2 輔助說明描述不清楚 3 輸入輸出不規(guī)范 4 長操作未給用戶提示 5 提示窗口文字未采用行業(yè)術(shù)語 6 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志 E 類測試建議01. 為什么要在一個團隊中開展軟件測試工作？因為沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO 質(zhì)量認證一樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團隊中開展軟件測試

11、的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質(zhì)量情況。02. 您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？我曾經(jīng)做過web 測試，后臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試03. 您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試）測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件

12、產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔谩?/p>

13、同時界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個細節(jié)功能，每個可能存在的功能問題。性能測試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關(guān)注于用戶體驗上，用戶使用該產(chǎn)品的時候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的數(shù)據(jù)，當然考慮到體驗性，不能太粗魯?shù)膹棾鼍妫孔瞿硞€性能測試的時候，首先它可能是個功能點，首

14、先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試04您認為做好測試用例設(shè)計工作的關(guān)鍵是什么？白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果黑盒測試用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題05. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別與聯(lián)系。 黑盒測試：已知產(chǎn)品的功能設(shè)計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測試意味著

15、測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：1、是否有不正確或遺漏的功能？2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？3、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？軟件的白盒測試是對軟件的過程性細節(jié)做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測

16、試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進行如下檢查：1、對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。3、在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己

17、?？梢赃@么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進程的所有模塊一起測試。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功

18、能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。 驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。06. 測試計劃工作的目的是什么？測試計劃工作的內(nèi)容都包括什么？其中哪些是最重要的？軟件測試計劃是指導(dǎo)

19、測試過程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配臵、測試周期、測試資源、測試交流、風(fēng)險分析等內(nèi)容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應(yīng)對測試過程中的各種變更。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配臵，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）07. 您認為做好測試計劃工作的關(guān)鍵是什么？1. 明確測試的目標，增強測試計劃的實用性編寫軟件測

20、試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準確2堅持“5W”規(guī)則，明確內(nèi)容與過程“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where （在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why ），明確測試的范圍和內(nèi)容（What ），確定測試的開始和結(jié)束日期（When ），指出測

21、試的方法和工具（How ），給出測試文檔和軟件的存放位臵（Where ）。3采用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容的可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)行人員。4. 分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例應(yīng)把詳細的測試技術(shù)指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源

22、配臵，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。08. 您所熟悉的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。1等價類劃分劃分等價類: 等價類是指某個輸入域的子集合. 在該子集合中, 各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的. 并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試. 因此, 可以把全部輸入數(shù)據(jù)合理劃分為若干等價類, 在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件, 就可以用少量代表性的測試數(shù)據(jù). 取得較好的測試結(jié)果. 等價類劃分可有兩種不同的情況:有效等價類和無效等價類.2邊界值分析法邊界值分析方法是對等價類劃分方法的補

23、充。測試工作經(jīng)驗告訴我, 大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上, 而不是發(fā)生在輸入輸出范圍的內(nèi)部. 因此針對各種邊界情況設(shè)計測試用例, 可以查出更多的錯誤.使用邊界值分析方法設(shè)計測試用例, 首先應(yīng)確定邊界情況. 通常輸入和輸出等價類的邊界, 就是應(yīng)著重測試的邊界情況. 應(yīng)當選取正好等于, 剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù), 而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).3錯誤推測法基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法.錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況, 根據(jù)他們選擇測試用例. 例如, 在單元

24、測試時曾列出的許多在模塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例.4因果圖方法前面介紹的等價類劃分方法和邊界值分析方法, 都是著重考慮輸入條件, 但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合, 可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類, 他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合, 相應(yīng)產(chǎn)生多個動作的形式

25、來考慮設(shè)計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.09. 請以您以往的實際工作為例, 詳細的描述一次測試用例設(shè)計的完整的過程。就說最近的這次網(wǎng)站功能的測試吧首先：得到相關(guān)文檔（需求文檔和設(shè)計文檔），理解需求和設(shè)計設(shè)計思想后，想好測試策略（測試計劃簡單點就OK 了），考慮到測試環(huán)境，測試用例，測試時間等問題。第二步：設(shè)計測試用例，測試策略是：把網(wǎng)站部分的功能點測試完，然后在進行系統(tǒng)測試（另外個模塊呢有另一個測試人員負責(zé)，可以進行聯(lián)調(diào)測試），網(wǎng)站模塊的測試基本是功能測試和界面測試（用戶并發(fā)的可能性很小，所以不考慮）：這

26、次的網(wǎng)站的輸入數(shù)據(jù)呢是使用數(shù)據(jù)庫中的某張表記錄，如果表中某一數(shù)據(jù)記錄中新加進來的（還沒有被處理的，有個標志位），網(wǎng)站啟動后會立刻去刷那張表，得到多條數(shù)據(jù)，然后在進行處理。處理過程中，會經(jīng)歷3個步驟，網(wǎng)站才算完成了它的任務(wù)。有3個步驟呢，就可以分別對 這3個步驟進行測試用例的設(shè)計, 盡量覆蓋到各種輸入情況（包括數(shù)據(jù)庫中的數(shù)據(jù)，用戶的輸入等），得出了差不多50個用例。界面測試，也就是用戶看的到的地方，包括發(fā)送的郵件和用戶填寫資料的頁面展示。第三步：搭建測試環(huán)境（為什么這個時候考慮測試環(huán)境呢？因為我對網(wǎng)站環(huán)境已經(jīng)很熟了，只有有機器能空于下來做該功能測試就可以做了），因為網(wǎng)站本身的環(huán)境搭建和其他的系統(tǒng)

27、有點不同，它需要的測試環(huán)境比較麻煩，需要web 服務(wù)器（Apache,tomcat ），不過這次需求呢，網(wǎng)站部分只用到了tomcat ，所以只要有tomcat 即可 第四步：執(zhí)行測試11. 您以往是否曾經(jīng)從事過性能測試工作？如果有，請盡可能的詳細描述您以往的性能測試工作的完整過程。 是的，曾經(jīng)做過網(wǎng)站方面的性能測試，雖然做的時間并不久（2個月吧），當時呢，是有位網(wǎng)站性能測試經(jīng)驗非常豐富的前輩帶著我一起做。性能測試類型包括負載測試，強度測試，容量測試等負載測試：負載測試是一種性能測試指數(shù)據(jù)在超負荷環(huán)境中運行，程序是否能夠承擔。強度測試： 強度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)

28、運行情況容量測試：確定系統(tǒng)可處理同時在線的最大用戶數(shù)在網(wǎng)站流量逐漸加大的情況下，開始考慮做性能測試了，首先要寫好性能測試計劃，根據(jù)運營數(shù)據(jù)得出流量最大的頁面（如果是第一次的話，一般是首頁，下載頁，個人帳戶頁流量最大，而且以某種百分比），Web 服務(wù)器指標指標：* Avg Rps: 平均每秒鐘響應(yīng)次數(shù)總請求時間 / 秒數(shù)；* Successful Rounds：成功的請求；* Failed Rounds ：失敗的請求；* Successful Hits ：成功的點擊次數(shù)；* Failed Hits ：失敗的點擊次數(shù)；* Hits Per Second ：每秒點擊次數(shù)；* Successful H

29、its Per Second ：每秒成功的點擊次數(shù)；* Failed Hits Per Second ：每秒失敗的點擊次數(shù)；* Attempted Connections ：嘗試鏈接數(shù)；13. 您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應(yīng)用的。14. 您認為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？15. 在您以往的工作中，一條軟件缺陷（或者叫Bug ）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug ）記錄？16. 您以往所從事的軟件測試工作中，是否使用了一些工具來進行軟件缺陷（B

30、ug ）的管理？如果有，請結(jié)合該工具描述軟件缺陷（Bug ）跟蹤管理的流程。17. 您認為在測試人員同開發(fā)人員的溝通過程中, 如何提高溝通的效率和改善溝通的效果？維持測試人員同開發(fā)團隊中其他成員良好的人際關(guān)系的關(guān)鍵是什么？18. 在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對待這些事情的？19. 在即將完成這次筆試前，您是否愿意談一些自己在以往的學(xué)習(xí)和工作中獲得的工作經(jīng)驗和心得體會？（可以包括軟件測試、過程改進、軟件開發(fā)或者與此無關(guān)的其他方面）20. 你對測試最大的興趣在哪里？為什么？最大的興趣就是測試有難度，有挑戰(zhàn)性！做測試越久越能感覺到做好測試有多難。曾經(jīng)在無

31、憂測試網(wǎng)上看到一篇文章，是關(guān)于如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關(guān)，有部分需要后天的努力。但除了性格有關(guān)的1，2點我沒有把握，其他點我都很有信心做好它。剛開始進入測試行業(yè)時，對測試的認識是從無憂測試網(wǎng)上了解到的一些資料，當時是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發(fā)更難，雖然當時我很想做開發(fā)（學(xué)校專業(yè)課我基本上不缺席，因為我喜歡我的專業(yè)），但看到測試比開發(fā)更難更有挑戰(zhàn)性，想做好測試的意志就更堅定了。不到一年半的測試工作中，當時的感動和熱情沒有減退一點（即使環(huán)境問題以及自身經(jīng)驗，技術(shù)的不足，做測試的你一定也能理解）。我覺得做測試整個過程

32、中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設(shè)計，因為測試的精華就在測試用例的設(shè)計上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務(wù)時，你得花一定的時間去消化業(yè)務(wù)需求和技術(shù)基礎(chǔ)，業(yè)務(wù)需求很好理解（多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能達到目的），而技術(shù)基礎(chǔ)可就沒那么簡單了，這需要你自覺的學(xué)習(xí)能力，比如說網(wǎng)站吧，最基本的技術(shù)知識你要知道網(wǎng)站內(nèi)部是怎么運作的的，后臺是怎么響應(yīng)用戶請求的？測試環(huán)境如何搭建？這些都需要最早的學(xué)好。至少在開始測試之前能做好基本的準備，可能會遇到什么難題？需求細節(jié)是不是沒有確定好？這些問

33、題都能在設(shè)計用例的時候發(fā)現(xiàn)。第二是發(fā)現(xiàn)BUG 的時候了，這應(yīng)該是測試人員最基本的任務(wù)了，一般按測試用例開始測試就能發(fā)現(xiàn)大部分的bug ，還有一部分bug 需要測試的過程中更了解所測版本的情況獲得更多信息，補充測試用例，測試出bug 。還有如何發(fā)現(xiàn)bug ？這就需要在測試用例有效的情況下，通過細心和耐心去發(fā)現(xiàn)bug 了，每個用例都有可能發(fā)現(xiàn)bug ，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程數(shù)據(jù)流及結(jié)果都得看仔細了，bug 都在里面發(fā)現(xiàn)的）。如何描述bug 也很有講究，bug 在什么情況下會產(chǎn)生，如果條件變化一點點，就不會有這個bug ，以哪些最少的操作步驟就能重現(xiàn)這個bug ，這

34、個bug 產(chǎn)生的規(guī)律是什么？如果你夠厲害的話，可以幫開發(fā)人員初步定位問題。34. 你的測試職業(yè)發(fā)展是什么？測試經(jīng)驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時間累積的，一步步向著高級測試工程師奔去。而且我也有初步的職業(yè)規(guī)劃，前3年累積測試經(jīng)驗，按如何做好測試工程師的11，12點要求自己，不斷的更新自己改正自己，做好測試任務(wù)。35. 你自認為測試的優(yōu)勢在哪里？優(yōu)勢在于我對測試堅定不移的信心和熱情，雖然經(jīng)驗還不夠，但測試需要的基本技能我有信心在工作中得以發(fā)揮。36. 你以前工作時的測試流程是什么？公司對測試流程沒有規(guī)定如何做，但每個測試人員都有自己的一套測試流程。我說下我1年來不斷改正（自己總結(jié)，

35、吸取同行的方法）后的流程吧。需求評審（有開發(fā)人員，產(chǎn)品經(jīng)理，測試人員，項目經(jīng)理）>需求確定(出一份確定的需求文檔 >開發(fā)設(shè)計文檔（開發(fā)人員在開始寫代碼前就能輸出設(shè)計文檔）>想好測試策略，寫出測試用例>發(fā)給開發(fā)人員和測試經(jīng)理看看（非正式的評審用例）>接到測試版本>執(zhí)行測試用例（中間可能會補充用例）>提交bug （有些bug 需要開發(fā)人員的確定（嚴重級別的，或突然發(fā)現(xiàn)的在測試用例范圍之外的，難以重現(xiàn)的），有些可以直接錄制進TD ）>開發(fā)人員修改（可以在測試過程中快速的修改）>回歸測試（可能又會發(fā)現(xiàn)新問題，再按流程開始跑）。37. 當開發(fā)人員說不

36、是BUG 時，你如何應(yīng)付？開發(fā)人員說不是bug ，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產(chǎn)品經(jīng)理進行確認，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發(fā)生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG 的依據(jù)是什么？如果被用戶發(fā)現(xiàn)或出了問題，會有什么不良結(jié)果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來, 跟開發(fā)經(jīng)理和測試經(jīng)理進行確認, 如果要修改就改, 如果不要修改就不改。其實有些真的不是bug ，我也只是建議的方式寫進TD 中，如果開發(fā)人員不修改也沒有大問題。如果確定是bug 的話，一定要堅

37、持自己的立場，讓問題得到最后的確認。23你為什么想離開目前的職務(wù)？因為公司運作情況并不理想，公司需要調(diào)整部門體系，公司考慮到縮減部門人員，所以大批量的裁員（有6，7個），這是我的第一份工作，對公司也有較深的感情，因為在這里我找到了職業(yè)理想（就是測試），所以公司需要精簡人員，我自愿退出。雖然很舍不得，但我將會有新的發(fā)揮能力的舞臺。24：你對我們公司了解有多少？25：你找工作時，最重要的考慮因素為何？工作的性質(zhì)和內(nèi)容是否能讓我發(fā)揮所長，并不斷成長。26：為什么我們應(yīng)該錄取你？您可以由我過去的工作表現(xiàn)所呈現(xiàn)的客觀數(shù)據(jù)，明顯地看出我全力以赴的工作態(tài)度。27：請談?wù)勀銈€人的最大特色。我的堅持度很高，事情

38、沒有做到一個令人滿意的結(jié)果，絕不罷手。28. 白箱測試和黑箱測試是什么? 什么是回歸測試?29。單元測試、集成測試、系統(tǒng)測試的側(cè)重點是什么？30。設(shè)計用例的方法、依據(jù)有那些？31。一個測試工程師應(yīng)具備那些素質(zhì)和技能？32. 集成測試通常都有那些策略？33. 你用過的測試工具的主要功能、性能及其他？34. 一個缺陷測試報告的組成35. 基于WEB 信息管理系統(tǒng)測試時應(yīng)考慮的因素有哪些？36. 軟件測試項目從什么時候開始，？為什么？37. 需求測試注意事項有哪些？38. 簡述一下缺陷的生命周期39. 測試分析測試用例注意（事項）？你在你所在的公司是怎么開展測試工作的？是如何組織的？你認為理想的測試

39、流程是什么樣子？你是怎樣工作的？軟件測試活動的生命周期是什么？請畫出軟件測試活動的流程圖？針對缺陷采取怎樣管理措施？什么是測試評估？測試評估的范圍是什么？如果能夠執(zhí)行完美的黑盒測試，還需要進行白盒測試嗎？為什么？測試結(jié)束的標準是什么？軟件驗收測試除了alpha,beta 測試以外, 還有哪一種?做測試多久了？以前做過哪些項目？你們以前測試的流程是怎樣的？<答：測試計劃測試用例設(shè)計測試執(zhí)行測試分析報告>用過哪些測試工具？為什么選擇測試這行？<答：它是一個新興的行業(yè)，有發(fā)展?jié)摿?，而且很鍛煉人，需要掌握更多的技能，比做開發(fā)要更難>為什么值得他們公司雇用？ 如果我雇用你，你能給

40、部門帶來什么貢獻？如何從工作中看出你是個自動自覺的人你的工作通常能在時限內(nèi)完成嗎. （我想問一下就是她問這個問題的動機是什么）通常你對于別人批評你會有什么樣的反應(yīng)如果明知這樣做不對，你還會依主管的指過去做嗎如果你接到一個客戶抱怨的電話，你確知無法解決他的問題，你會怎么處理你覺得什么樣的人最難相處為什么值得他們公司雇用？幫助公司提高軟件質(zhì)量和測試部門的技術(shù)水平如果我雇用你，你能給部門帶來什么貢獻？分享我的測試經(jīng)驗和測試技能，提高測試部門技術(shù)水平如何從工作中看出你是個自動自覺的人自動自覺范圍太廣1. 工作成果2. 工作質(zhì)量你的工作通常能在時限內(nèi)完成嗎. （我想問一下就是她問這個問題的動機是什么）在

41、有足夠的資源和合理的工作量的情況下，完全可以按時完成，并能比一般人做的更好通常你對于別人批評你會有什么樣的反應(yīng)有錯即改，無措勉之如果明知這樣做不對，你還會依主管的指過去做嗎在公司內(nèi)部下級是否有申訴渠道？如果你接到一個客戶抱怨的電話，你確知無法解決他的問題，你會怎么處理為什么抱怨？是怎么樣的問題？如果是客服問題，提交客服部門解決如果是質(zhì)量問題，分析原因，下一版本改進你覺得什么樣的人最難相處自以為是的人什么叫單元測試？請就軟件測試人員應(yīng)該具備什么樣的基本素質(zhì)說說你的看法。請就如何在開發(fā)中進行軟件質(zhì)量控制說說你的看法簡述軟件測試的意義，以及軟件測試的分類1、功能測試，性能測試，界面測試，安全測試（可

42、以簡單點，比如只涉及到COOKIES 里的內(nèi)容），壓力測試（商業(yè)性質(zhì)的網(wǎng)站） 等等，B/S軟件也要根據(jù)其具體功能采用不同的測試策略。2、態(tài)度、責(zé)任心、自信、敏銳的觀察力、良好的發(fā)散思維3、先設(shè)計后開發(fā)模式，加強單元測試，加強代碼走查，有一套完整的白盒測試方法。關(guān)鍵是加強開發(fā)人員的質(zhì)量意識，增進程序員向工程師水平發(fā)展。4、意義嘛，就自己想吧。軟件測試的分類，這個很多人都按各種方法去分。無明確答案給你。對測試的理解-基本的測試知識，對測試是否認可？ 75。3、談一談過去自己的工作-了解經(jīng)歷、提供進一步提問的素材，表達能力測試技能測試設(shè)計的方法并舉例說明-測試技術(shù)的使用測試工具-熟悉程度，能否與當前

43、工作匹配？如何做計劃？如何跟蹤計劃？-日常工作能力如果開發(fā)人員提供的版本不滿足測試的條件，如何做？-與開發(fā)人員協(xié)作的能力熟悉unix 系統(tǒng)、oracle 數(shù)據(jù)庫嗎？-是否具備系統(tǒng)知識做過開發(fā)嗎？寫過哪些代碼？-開發(fā)技能閱讀英語文章，給出理解說明？-部分英語能力文檔的意義-是否善于思考？（最簡單的概念，不同層次的理解）假如進入我們公司，對我們哪些方面會有幫助？-講講自己的特長隨便找一件物品，讓其測試-測試的實際操作能力軟件測試的方法有？軟件測試的過程？有一個新的軟件，假如你是測試工程師，該如何做？軟件測試分哪兩種方法？分別適合什么情況？2。一套完整的測試應(yīng)該由哪些階段組成？分別闡述一下各個階段。

44、3。軟件測試的類型有那些？分別比較這些不同的測試類型的區(qū)別與聯(lián)系。4。測試用例通常包括那些內(nèi)容？著重闡述編制測試用例的具體做法5。在分別測試winform 的C/S結(jié)構(gòu)與測試WEB 結(jié)構(gòu)的軟件是，應(yīng)該采取什么樣的方法分別測試？他們存在什么樣的區(qū)別與聯(lián)系？6。在測試winform 的C/S結(jié)構(gòu)軟件時，發(fā)現(xiàn)這個軟件的運行速度很慢，您會認為是什么原因？您會采取哪些方法去檢查這個原因？7。描述使用bugzilla 缺陷管理工具對軟件缺陷（BUG ）跟蹤的管理的流程你在五年內(nèi)的個人目標和職業(yè)目標分別是什么？分析這個問題是用來了解你的計劃能力的，通過這個問題，面試人同時還可以知道你的目標是否符合企業(yè)對你的

45、安排。錯誤回答我想在將來的某個時候考慮這個問題。如今企業(yè)的領(lǐng)導(dǎo)者更換頻繁，我認為做太多的個人計劃是荒謬可笑的，不是嗎？評論這種回答屬于令人反感的一類。首先，當有人想了解你的目標時，" 將來的某個時候" 這種通俗說法并不奏效。其次，認為企業(yè)很脆弱，領(lǐng)導(dǎo)者更換頻繁，這種說法毫無疑問會令人反感，而且也是不合理的。最后，認為做計劃可笑，看不起這個問題，而且反問面試人，這些都注定了這樣的求職者最終會失敗。正確回答從現(xiàn)在起的五年之內(nèi)，我希望能夠在一個很好的職位上待幾年，而且最好有一次晉升，然后就期待著下一步。不管是向上提升，還是在企業(yè)內(nèi)橫向調(diào)動，對我個人來說，我希望找到一家企業(yè)-一家愿

46、意做相互投入的企業(yè)-待上一段時間。評論這個問題沒有回答得過分具體（那樣可能會產(chǎn)生漏洞），而且它表明你有雄心，并且思考過在企業(yè)中的成長方式。通過表達橫向調(diào)動和向上提升的愿望，表明你是一個有靈活性的人。問題23 你怎樣做出自己的職業(yè)選擇？分析 面試人提出這個問題是為了了解求職者的動機，看看他（她）應(yīng)聘這份工作是否有什么歷史淵源，是否有職業(yè)規(guī)劃，是不是僅僅在漫無目的地申請很多工作。錯誤回答 我一直都想在企業(yè)界工作。自孩提時代起，我就夢想自己至少也要成為大企業(yè)的副總裁。評論 除了難以令人相信之外，這種回答還存在一個問題：它表明求職者會對副總裁以下的職位不感興趣。 正確回答 在上大學(xué)四年級前的那個夏天，

47、我決定集中精力在某一領(lǐng)域謀求發(fā)展。盡管我是學(xué)商業(yè)的，但是我不知道自己最終會從事哪一行業(yè)的工作。我花了一定的時間考慮自己的目標，想清楚了自己擅長做的事情以及想從工作中得到的東西，最后我得出了一個堅定的結(jié)論，那就是這個行業(yè)是最適合我的。評論 這種回答表明，求職者認真地做過一些計劃，縮小了自己的關(guān)注點，而且也認準了前進的方向。這種回答還表明，求職者理解個人職業(yè)規(guī)劃的重要性，并且有能力做出認真的個人決策。1. 你都用什么測試方法2. 怎么編寫案例3. 怎么才能夠全面的測試到每一個點1. 你都用什么測試方法針對不同的產(chǎn)品或者系統(tǒng)或者模塊，有不同的測試方法。總體而言有白盒測試和黑盒測試。2. 怎么編寫案例

48、案例的編寫與測試階段的定義有很大的關(guān)系。系統(tǒng)測試和unit 測試的案例可能不同?？傮w而言測試案例根據(jù)系統(tǒng)的需求而定。3. 怎么才能夠全面的測試到每一個點測試的全面性主要需要在設(shè)計測試計劃的時候考慮，從測試策略，產(chǎn)品需求等等多個角度考慮從而定義全部的測試點。1、談?wù)勡浖y試技術(shù)，以及如何提高2、談?wù)勡浖y試職業(yè)發(fā)展，以及個人的打算3、談?wù)勡浖y試在企業(yè)的地位，也可以結(jié)合軟件生命周期來談有可能清晰的思路比確切的答案更重要在這里，主要說下筆試和面試的問題，希望大家共同參考。1，一般公司里實際的軟件測試流程是什么樣的？你們公司又是怎樣的？2，軟件工程師要具有那些素質(zhì)？3，你會哪些測試工具？怎么操作？4

49、，你能不能說下你的3到5年的職業(yè)計劃（規(guī)劃）5，你覺得你來應(yīng)聘有那些優(yōu)勢？其余的還好說，但就第4個問題，我感到不好說哦！希望大家給個意見第一關(guān)：首先要自我介紹，自己的性格怎么樣，目前的工作經(jīng)歷積累了一些什么經(jīng)驗取得了些什么值得一說的成果。然后要說說對軟件測試怎么看？還有對于軟件測試有什么自己的想法。為什么會想到要做這行（因為我的簡歷上的工作經(jīng)歷沒有關(guān)于測試方面的）。哦，還有期望薪資。第二關(guān)：認為軟件測試人員所要具備的基本素質(zhì)，如果遇到問題會怎樣處理，如果得不到研發(fā)人員的配合（就是研發(fā)說這個不是問題）你又會怎么處理？然后就是一些基本概念，比如軟件測試的流程有哪些？如果我上任了，首先會怎么開始自己

50、的工作計劃。（前兩關(guān)通過了后面這個就好過多了）第三關(guān)：像我介紹了一下公司的情況，告訴我主要針對什么內(nèi)容的測試，會不會使用數(shù)據(jù)庫。告訴我大概要做哪些內(nèi)容，詳細的可以上崗以后慢慢熟悉。大概就這么多了，這對沒有經(jīng)過這一關(guān)的不知道有沒有幫助，僅供參考吧我覺得就像李波說的，關(guān)鍵是要給對方留下好印象:面試官最后會問你有什么問題要問嗎。作為應(yīng)聘者的你一般不要說沒問題問，這會給面試官留下你不太重視這份工作的壞印象。所以如果你想得到這份工作的話應(yīng)該抓住這最后的表現(xiàn)自己的機會：你可以問：1. 貴公司近期和遠期的發(fā)展目標是什么？2. 貴公司的主要競爭對手有哪些？3. 貴公司有多少開發(fā)人員有多少測試人員？4. 貴公司

51、又進一步擴充測試人員的計劃嗎?5. 如果我有幸能進入貴公司的話，我有怎么樣的發(fā)展？6. 測試人員的溝通能力很重要，貴公司有規(guī)范的溝通渠道嗎？7. 請介紹一下貴公司的福利情況。8. 請問我什么時候能知道結(jié)果問題一：什么是“軟件測試”？1。出自(IEEE, 1986; IEEE, 1990.Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs and to evalua

52、te the features ofthe software item就是一個通過分析軟件和需求之間的差異，發(fā)現(xiàn)bug, 對軟件的功能進行評價的過程。2。軟件測試就是在受控制的條件下對系統(tǒng)或應(yīng)用程序進行操作并評價操作的結(jié)果。3。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。這一種也是大多數(shù)文檔和書籍進行的定義，其實和第一個定義沒有什么區(qū)別。問題二：什么是“測試案例”?測試案例是一份文檔，它描述了一個輸入、反應(yīng)、或者是與其相應(yīng)的預(yù)期的響應(yīng)，以便來判斷應(yīng)用軟件的工作是否正常。測試案例應(yīng)當包括測試標識、測試案例的名稱、目標、測試條件/設(shè)臵、輸入數(shù)據(jù)要求、步驟、以及預(yù)期的結(jié)果。問題三：如果時間不夠，無法進行

53、充分的測試怎么辦?使用風(fēng)險分析，確定測試的重點。由于很少有機會對一個應(yīng)用軟件進行所有可能的測試 (包括所有可能的事件組合、所有的相關(guān)性、或者一切可能出錯的東西 ，對大多數(shù)軟件開發(fā)項目來說，利用風(fēng)險分析是適當?shù)?。這需要判斷技能、常識、感覺和經(jīng)驗。如果有正當理由，也可采用正式的方法。需要考慮下列因素：ü 對于該項目的用途而言，哪種功能最重要?ü 哪種功能對用戶最明顯?ü 哪種功能對安全影響最大?ü 哪種功能對用戶最有用?ü 對客戶來說，該應(yīng)用軟件的哪個部分最重要?ü 在開發(fā)過程中，該應(yīng)用軟件的哪個部分可以最先測試?ü 哪一部分代

54、碼最復(fù)雜，容易導(dǎo)致出現(xiàn)錯誤?ü 哪一部分的應(yīng)用程序是在急迫或在驚恐的情況下開發(fā)出來的?ü 哪一部分程序與過去項目中引起問題的部分相類似/有關(guān)?ü 哪一部分程序與過去項目中需要大量維護的部分相類似/有關(guān)?ü 需求和設(shè)計的那些部分不清楚或不容易讀?ü 開發(fā)人員認為在應(yīng)用軟件中哪些部分是高風(fēng)險的?ü 哪些問題能造成最差的發(fā)行?ü 哪些問題最能引起用戶抱怨?ü 哪些測試可以容易地覆蓋多種功能?ü 哪些測試在覆蓋高風(fēng)險部分的測試時使用時間最少?問題四：如果需求一直在變化怎么辦?這是一個常見的令人頭疼的問題。

55、2;如果可能，盡早與承擔該項目風(fēng)險的人接觸，以便了解需求會怎樣改變，從而可以盡早地改變測試計劃和策略。 ü 如果在對應(yīng)用程序進行初始設(shè)計時多考慮一些適應(yīng)性，那么以后在發(fā)生需求的改變時，就不需要再為改變做很多事情了。ü 好的代碼注釋和好的文檔有助于開發(fā)人員作出相應(yīng)的改變。ü只要有可能，就應(yīng)使用快速原型 (rapid prototyping，以幫助用戶確認他們的需求，從而減少變更。 ü在項目的時間表中應(yīng)當留出余量，以應(yīng)付可能出現(xiàn)的變更。ü盡量把新的需求納入應(yīng)用軟件的“下一版”，而把原始需求作為“第一版”。ü通過談判，把易于實現(xiàn)的新的變更列

56、入項目，而把難于實現(xiàn)的新需求列入該應(yīng)用軟件的以后的版本。ü要確保讓客戶和管理人員了解變更對進度表的影響、所帶來的風(fēng)險、以及因變更所引起的大量資金消耗。 ü在應(yīng)付改變時，應(yīng)在為建立自動測試而作的努力和重新進行測試所做的努力之間取得平衡。ü在設(shè)計自動測試劇本時，試圖使其有一些靈活性。ü在對應(yīng)用軟件進行自動測試時，要把注意力集中在看來不大會改變的部分。ü對變更進行適當?shù)娘L(fēng)險分析，以減少回歸測試的要求。ü在設(shè)計測試案例時要有一定的靈活性。做到這一點并不容易，所以要降低測試案例的詳細程度，或者只建立高級的通用型的測試計劃。ü 少注意詳

57、細的測試計劃和測試案例，要把重點放在專門的測試 (ad hoc testing 上。測試的幾個原則1. 應(yīng)當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。2. 測試用例應(yīng)由測試輸入數(shù)據(jù)和對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。3. 程序員應(yīng)避免檢查自己的程序。4. 在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件。5. 充分注意測試中的群集現(xiàn)象。經(jīng)驗表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。6. 嚴格執(zhí)行測試計劃，排除測試的隨意性。7. 應(yīng)當對每一個測試結(jié)果做全面檢查。8. 妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。關(guān)于bug測試的原則-Good Enough對于相對復(fù)雜的產(chǎn)品或系統(tǒng)來說，zero-bug 是一種理想，good-enough 是我們的原則。Good-enough 原則就是一種權(quán)衡投入/產(chǎn)出比的原則：不充分的測試是不負責(zé)任的；過分的測試是一種資源的浪費，同樣也是一種不負責(zé)任的表現(xiàn)。我們的操作困難在于：如何界定什么樣的測試是不充分的，什么樣的測試是過分的。目前狀況唯一可用的答案是：制定