軟件測試工程師試題

1、軟件測試工程師筆試試題01. 為什么要在一個團隊中開展軟件測試工作？ 因為沒有經過測試的軟件很難在發(fā)布之前知道該軟件的質量，就好比 ISO 質量認證一樣，測試同樣也需要 質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)現軟件中存在的問題，及時 讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質量情況。02. 您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請試述在這個過程中都有哪 些工作要做？分別由哪些不同的角色來完成這些工作？ 我沒有工作過，但是對企業(yè)的軟件測試過程有所了解，一個完整的軟件測試過程包括測試計劃的制定、人 員的確定與分工、測試用例的編寫、測

2、試的實施、測試結果分析等03. 您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請試述一個完整的開發(fā)過程 需要完成哪些工作？分別由哪些不同的角色來完成這些工作？ （對于軟件測試部分， 可以簡 述）一個完整的開發(fā)過程包括需求分析、規(guī)劃、編碼、測試等04. 您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？ 我曾經做過 web 測試，后臺測試，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試05. 您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試）測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比

3、例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用 黑盒測試法進行動態(tài)測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。采用 黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進 行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載 下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個 系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。界面測試，界

4、面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計 良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用。同時界面如同人的面孔，具有吸引用戶 的直接優(yōu)勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓 用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。區(qū)別在于，功能測試關注產品的所有功能上，要考慮到每個細節(jié)功能，每個可能存在的功能問題。性 能測試主要關注于產品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關注于用戶體驗上，用戶使用 該產品的時候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的） ，是否美觀（能否吸引用戶的

5、注意力） ，是 否安全（盡量在前臺避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告）？做某 個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性 能測試06. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū) 別與聯(lián)系。黑盒測試：已知產品的功能設計規(guī)格，可以進行測試證明每個實現了的功能是否符合要求。白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規(guī)格要求，所有 內部成分是否以經過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人 員完全不考

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

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

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

9、對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設 計。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最 終用戶將其用于執(zhí)行軟件的既定功能和任務。 驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊 組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是 驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。07. 測試計劃工作的目的是什么？測試計劃工作的內容都包括什么？其中哪些是最重要 的？ 軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述

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

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

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

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

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

15、他們選擇 測試用例 . 例如 , 在單元測試時曾列出的許多在模塊中常見的錯誤 . 以前產品測試中曾經發(fā)現的錯誤等 , 這 些就是經驗的總結 . 還有 , 輸入數據和輸出數據為 0 的情況 . 輸入表格為空格或輸入表格只有一行 . 這些都 是容易發(fā)生錯誤的情況 . 可選擇這些情況下的例子作為測試用例 .4因果圖方法前面介紹的等價類劃分方法和邊界值分析方法 ,都是著重考慮輸入條件 ,但未考慮輸入條件之間的聯(lián)系 , 相互組合等 . 考慮輸入條件之間的相互組合 ,可能會產生一些新的情況 . 但要檢查輸入條件的組合不是一件 容易的事情 , 即使把所有輸入條件劃分成等價類 ,他們之間的組合情況也相當多 .

16、 因此必須考慮采用一種適 合于描述對于多種條件的組合 ,相應產生多個動作的形式來考慮設計測試用例 . 這就需要利用因果圖（邏輯 模型）. 因果圖方法最終生成的就是判定表 . 它適合于檢查程序輸入條件的各種組合情況 .10. 您認為做好測試用例設計工作的關鍵是什么？ 白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果 黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的 用例在合理的時間內發(fā)現最多的問題11. 請以您以往的實際工作為例，詳細的描述一次測試用例設計的完整的過程。就說我做過的網站功能的測試吧首先：得到相關文檔（需求文檔和設計文檔

17、） ，理解需求和設計設計思想后，想好測試策略（測試計劃 簡單點就 OK 了），考慮到測試環(huán)境，測試用例，測試時間等問題。第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，然后在進行系統(tǒng)測試（另外個模 塊呢有另一個測試人員負責， 可以進行聯(lián)調測試） ，網站模塊的測試基本是功能測試和界面測試（用戶并發(fā) 的可能性很小， 所以不考慮） ：這次的網站的輸入數據呢是使用數據庫中的某張表記錄，如果表中某一數據 記錄中新加進來的（還沒有被處理的，有個標志位） ，網站啟動后會立刻去刷那張表，得到多條數據，然后 在進行處理。處理過程中，會經歷 3個步驟，網站才算完成了它的任務。 有 3個步驟呢，就可以分

18、別對 這 3 個步驟進行測試用例的設計 ,盡量覆蓋到各種輸入情況 （包括數據庫中的數據， 用戶的輸入等） ，得出了差 不多 50 個用例。界面測試，也就是用戶看的到的地方，包括發(fā)送的郵件和用戶填寫資料的頁面展示。第三步：搭建測試環(huán)境（為什么這個時候考慮測試環(huán)境呢？因為我對網站環(huán)境已經很熟了，只有有機 器能空于下來做該功能測試就可以做了） ，因為網站本身的環(huán)境搭建和其他的系統(tǒng)有點不同， 它需要的測試 環(huán)境比較麻煩，需要 web服務器（Apache,tomcat）,不過這次需求呢，網站部分只用到了 tomcat，所以只 要有 tomcat 即可第四步：執(zhí)行測試12. 您以往的工作中是否曾開展過測試

19、用例的評審工作？如果有，請描述測試用例評審的過 程和評審的內容。13. 您以往是否曾經從事過性能測試工作？如果有，請盡可能的詳細描述您以往的性能測試 工作的完整過程。是的，曾經做過網站方面的性能測試，雖然做的時間并不久，也是基于興趣自己嘗試著做。 性能測試類型包括負載測試，強度測試，容量測試等負載測試：負載測試是一種性能測試指數據在超負荷環(huán)境中運行，程序是否能夠承擔。強度測試： 強度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運行情況 容量測試：確定系統(tǒng)可處理同時在線的最大用戶數 在網站流量逐漸加大的情況下，開始考慮做性能測試了，首先要寫好性能測試計劃，根據運營數據得 出流量最大的頁

20、面 （如果是第一次的話， 一般是首頁， 下載頁， 個人帳戶頁流量最大， 而且以某種百分比）Web 服務器指標指標：* Avg Rps:平均每秒鐘響應次數=總請求時間 /秒數；* Successful Rounds:成功的請求；* Failed Rounds ：失敗的請求；* Successful Hits :成功的點擊次數；* Failed Hits :失敗的點擊次數；* Hits Per Second :每秒點擊次數；* Successful Hits Per Second :每秒成功的點擊次數；* Failed Hits Per Second :每秒失敗的點擊次數；* Attempted

21、Connections :嘗試鏈接數；14. 您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原 理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。有，loadrunner,原理圖如下：工作原理:代理（Proxy）是客戶端和服務器端之間的中介人，LoadRunner就是通過代理方式截獲客戶端和服務器之間交互的數據流。1、 虛擬用戶腳本生成器通過代理方式接收客戶端發(fā)送的數據包，記錄并將其轉發(fā)給服務器端； 接收到從服 務器端返回的數據流，記錄并返回給客戶端。這樣服務器端和客戶端都以為在一個真實運行環(huán)境中，虛擬腳本生成器能通過這種方式截獲數據流； 虛擬用戶腳

22、本生成器在截獲數據流后對其進行了協(xié)議層上的處理，最終用腳本函數將數據流交互過程體現 為我們容易看懂的腳本語句。2、壓力生成器則是根據腳本內容，產生實際的負載，扮演產生負載的角色。3、 用戶代理是運行在負載機上的進程，該進程與產生負載壓力的進程或是線程協(xié)作， 接受調度系統(tǒng)的命令， 調度產生負載壓力的進程或線程。4、壓力調度是根據用戶的場景要求，設置各種不同腳本的虛擬用戶數量，設置同步點等。5、監(jiān)控系統(tǒng)則可以對數據庫、應用服務器、服務器的主要性能計數器進行監(jiān)控。6、壓力結果分析工具是輔助測試結果分析。15. 您認為性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？ 目的是驗證軟件系統(tǒng)是否能夠

23、達到用戶提出的性能指標， 同時發(fā)現軟件系統(tǒng)中存在的性能瓶頸， 優(yōu)化軟件， 最后起到優(yōu)化系統(tǒng)的目的。包括以下幾個方面 一評估系統(tǒng)的能力，測試中得到的負荷和響應時間數據可以被用于驗證所計劃的模型的能力，并幫助作 出決策。二識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄 弱的地方。三系統(tǒng)調優(yōu)：重復運行測試，驗證調整系統(tǒng)的活動得到了預期的結果，從而改進性能。 檢測軟件中的問題：長時間的測試執(zhí)行可導致程序發(fā)生由于內存泄露引起的失敗，揭示程序中的隱含的問 題或沖突。四驗證穩(wěn)定性( resilience )可靠性( reliability )：在一個生產負荷下執(zhí)行測

24、試一定的時間是評估系統(tǒng)穩(wěn)定 性和可靠性是否滿足要求的唯一方法。關鍵點：1、整體工作計劃 一個提綱攜領的工作執(zhí)行詳細說明，必須是實施層面的。大至階段劃分，小到重裝機器，是為性能測試工 作的指導書2、性能測試需求調研 一項工作，總有目的，需求調研即是解決這個問題。要在了解系統(tǒng)架構的前提下，確定測試目標。如：高峰期并發(fā)1000,交易平均響應時間不超過 10S。但這種目標存在問題，因為并發(fā)1000是絕對并發(fā)還是按照 業(yè)務人員操作習慣的并發(fā)不確定，所以，最好的測試目標是直接確定到系統(tǒng)TPS，而這種需求，是必須來源于實際生產中的數據，其它的，都屬于拍腦袋的范疇。確定TPS有一定的策略，如八二原則等等。3、

25、測試數據 測試數據包括基礎數據和腳本數據，都有可能成為測試任務的風險點。性能測試中，基礎數據可以大部分 為垃圾數據。腳本數據可以通過直接撰寫 SQL 語句來挑選。4、腳本編寫 也是我的一個弱項，技術層面上的問題比較多，有一些特殊的系統(tǒng)，做起來腳本中的關聯(lián)相當的困難5、系統(tǒng)調優(yōu) 這個我認為是性能測試中最重要的事情。性能測試包括兩個層面，性能驗證和性能調優(yōu)。性能調優(yōu)需要調 優(yōu)者具備多方面的能力，包括操作系統(tǒng)、中間件、數據庫、網絡、存儲等等，目前我還沒有碰到過一個對 如此多方面均有所涉獵的人，所以說，一個全面的系統(tǒng)調優(yōu)專家不存在，存在的只有領域專家，如何把相 關領域專家更好的結合到性能測試中，是一個

26、測試經理需要做的事情6、測試報告撰寫 測試報告，是反映本次測試成果的最直接和直觀的輸出物。一個好的測試報告，必須能夠反映出測試過程 中所有的問題和解決措施，必須能夠結合所有的測試數據，體現出系統(tǒng)的性能瓶頸和調優(yōu)建議。它應該包 括：背景、過程 review 、結果分析、調優(yōu)建議，甚至包括容量規(guī)劃。16. 在您以往的工作中，一條軟件缺陷(或者叫Bug)記錄都包含了哪些內容？如何提交高質量的軟件缺陷(Bug)記錄？記錄的內容為：發(fā)現了哪些 bug、解決了哪些bug、遺留的bug對軟件的影響answer2: 缺陷名詞/描述/缺陷等級 /嚴重程度 /發(fā)現模塊/發(fā)現步驟和過程 /是否可以重現 提交高質量的

27、Bug記錄的方法：1 用統(tǒng)一的 Bug 管理系統(tǒng)2在執(zhí)行完一個測試用例并且通過時，應向Bug 管理系統(tǒng)提交一個 Bug 報告3. Bug報告必須清晰描述 Bug產生的環(huán)境，產生 Bug的用例、Bug產生的條件、具體詳細的 BUG現象，當 前被測的軟件版本，測試員人的建義等內容，以便 BUG處理人員能重視現象 BUG能有效的找出現象 BUG 的原因BUG并進行修正。4. BUG提交以“輪”為單位，也就是每個具體的BUG必須屬于具體的被測軟件產品版本。5. 每個提交的BUG經過處理或修正后放在下一個被測版本中進行回歸測試，測試通過后，此BUG才會轉換 為CLOSE犬態(tài)，結束此BUG的生命周期，否則

28、，此 BUG會處于相應的生存狀態(tài)，直到最終處理完成后轉為 CLOSE犬態(tài)。6. BUG生命周期中各BUG處理過程必須有詳細準確的處理記錄，在BUG管理系統(tǒng)中能詳細的看到此 BUG勺 生命歷程。17. 您以往所從事的軟件測試工作中，是否使用了一些工具來進行軟件缺陷（Bug）的管理？如果有，請結合該工具描述軟件缺陷（Bug ）跟蹤管理的流程。使用過 BugFree 等免費工具18. 您以往是否曾經從事過單元測試和集成測試？如果有，請談一下這些工作的實際開展情 況。19. 您如何看待軟件過程改進？在您曾經工作過的企業(yè)中，是否有一些需要改進的東西呢？ 您期望的理想的測試人員的工作環(huán)境是怎樣的？ 將先進

29、的經驗或思想固化到過程中，通過過程改進和能力提高來改進軟件質量。20. 您以往工作過的企業(yè)中，是否開展了軟件配置管理工作？您能否描述一下這項工作的開 展情況和您對這項工作的認識？21. 您是否熟悉一些主流的軟件工程方法論和思想， 如 RUP、CMM 、CMMI 、XP、PSP、TSP。 如果熟悉，您是否可以談一下對這些方法論和思想的認識？22. 您認為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？ 維持測試人員同開發(fā)團隊中其他成員良好的人際關系的關鍵是什么？ 對事不對人，一切以公司利益、客戶為重23. 在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什么？您是

30、如何來對 待這些事情的？24. 在即將完成這次筆試前，您是否愿意談一些自己在以往的學習和工作中獲得的工作經驗 和心得體會？（可以包括軟件測試、過程改進、軟件開發(fā)或者與此無關的其他方面）軟件測試工程師筆試試題 2判斷題（每題1分，12分，正確的V，錯誤的X）1. 軟件測試的目的是盡可能多的找出軟件的缺陷。（ 錯） 軟件測試的目的就是為了發(fā)現軟件中的缺陷，從這個意義上面說上面的這個論斷是正確的。不少人會認為 軟件測試可以保證軟件的質量，其實這個觀點是錯誤，測試只是軟件質量控制中的一個角色，其活動并不 能達成軟件質量保證的效果。 所以不要認為一個公司里面如果有了軟件測試人員， 產品的質量就會好起來。

31、2. Beta 測試是驗收測試的一種。 （ 錯）Beat 測試和驗收測試是兩種不同的測試。驗收測試的目的是為了以發(fā)現 ”未實現的需求 ”為目的，以評估 適合使用 ”為目標，該類測試的不是以發(fā)現缺陷為主要目的。 beta 測試是一模擬真實的使用環(huán)境從而發(fā)現缺 陷的一種測試。所以兩者之間的是非包容關系。3驗收測試是由最終用戶來實施的。 （錯 ） 驗收測試也可由軟件生產的企業(yè)內部人員來實施，例如產品經理。當軟件以項目的形式出現，那么驗收測 試由最終用戶來實施的情況是比較常見的。但是對于產品形式的軟件，生產企業(yè)內部的驗收測試會更多。 4項目立項前測試人員不需要提交任何工件。 （對 ?） 應該說這道題目

32、沒有明確的答案，在項目立項前測試人員是不是要把一些準備工作以工件的形式給記錄下 來是完全取決于該企業(yè)的軟件開發(fā)過程的要求。同時不同企業(yè)，立項前要達成的一些必要條件也是大相徑 庭的。應該說這一題目出的不是很好。5單元測試能發(fā)現約 80%的軟件缺陷。 （對？） 同樣這一題目也沒有標準答案。因為該數據的來源和其統(tǒng)計的方法，樣本都沒有一個工業(yè)標準。這樣出來 的數據同樣不具有權威性。這里我可以說一個簡單的例子，在用 ASP,php 這類腳本語言開發(fā)網頁的時候是 根本沒有復雜的單元測試。那么這樣的數字應用在網站開發(fā)上面是否有意義，還是值得商榷的。6代碼評審是檢查源代碼是否達到模塊設計的要求。（對）代碼審查

33、是一種靜態(tài)技術，從這個意義上說代碼復查是需要和其他的一些動態(tài)測試技術配合才能檢查代碼 是否符合設計的要求7自底向上集成需要測試員編寫驅動程序。 （？）樁程序與驅動程序的概念問題8負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。（錯）9測試人員要堅持原則，缺陷未修復完堅決不予通過。（錯）缺陷是否修復是需要聽取測試人員的意見，但測試人員的意見非決定性。所以還是要看一個企業(yè)賦予測試 人員有多大的權力。 （視具體情況而定，如果缺陷對系統(tǒng)的使用功能、性能不夠成不利影響，在時間等因素 的條件下，可以考慮予以通過）10代碼評審員一般由測試員擔任。 （錯） 如果測試員有這個水平，那么當然是可以參加的。不過

34、大多數的企業(yè)不會讓普通的測試人員參與代碼的評 審。11我們可以人為的使得軟件不存在配置問題。 （錯） 12集成測試計劃在需求分析階段末提交。 （錯） 集成測試計劃在開發(fā)人員完成軟件集成計劃之后就可以開始進行了。所以在需求分析階段之后提交是不現 實的事情，應該在軟件的設計階段后，編碼前。二、不定項選擇題（每題 2 分，10 分） 1軟件驗收測試的合格通過準則是： （ABCD ） A 軟件需求分析說明書中定義的所有功能已全部實現，性能指標全部達到要求。B 所有測試項沒有殘余一級、二級和三級錯誤。C 立項審批表、需求分析文檔、設計文檔和編碼實現一致。D 驗收測試工件齊全。 2軟件測試計劃評審會需要哪

35、些人員參加？（ABCD ）A 項目經理B. SQA負責人C.配置負責人 D 測試組 3下列關于 alpha 測試的描述中正確的是： （AD） A alpha 測試需要用戶代表參加 B alpha 測試不需要用戶代表參加 C alpha 測試是系統(tǒng)測試的一種 D alpha 測試是驗收測試的一種 名詞解釋： Alpha 和 Beta 測試簡介1、大型通用軟件，在正式發(fā)布前，通常需要執(zhí)行 Alpha和Beta測試，目的是從實際終端用戶的使用 角度，對軟件的功能和性能進行測試，以發(fā)現可能只有最終用戶才能發(fā)現的錯誤。2、Alpha測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際

36、操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或測試員完成。Alpha測試發(fā)現的錯誤，可以在測試現場立刻反饋給開發(fā)人員，由開發(fā)人員及時分析和處理。目的是評價軟件產品的功能、可使用性、可靠性、性能和支持。尤其注重產品的界面和特色。Alpha測試可以從軟件產品編碼結束之后開始，或在模塊（子系統(tǒng)）測試完成后開始，也可以在確認測試過程中產品達到一定的穩(wěn)定和可靠程度之后再開始。有關的手冊（草 稿）等應該在Alpha測試前準備好。3、 Beta測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測試現場，Beta測試不能由程序員或測試員完成。因而，Beta測試是在開發(fā)者無法

37、控制的環(huán)境下進行的軟件現場應用。在Beta測試中，由用戶記下遇到的所有問題，包括真實的以及主管認定的，定期向開發(fā)者報告， 開發(fā)者在綜合用戶的報告后，做出修改，最后將軟件產品交付給全體用戶使用。Beta測試著重于產品的支持性，包括文檔、客戶培訓和支持產品的生產能力。只有當Alpha測試達到一定的可靠程度后，才能開始Beta測試。由于Beta測試的主要目標是測試可支持性，所以Beta測試應該盡可能由主持產品發(fā)行的人員來管理。從游戲角度上看，alpha可以理解為內測，beta是公測和全面的公開測試。4 .測試設計員的職責有：（BC）A 制定測試計劃 B 設計測試用例 C 設計測試過程、腳本D 評估測

38、試活動5 .軟件實施活動的進入準則是：（ABC ）A .需求工件已經被基線化B .詳細設計工件已經被基線化C.構架工件已經被基線化D .項目階段成果已經被基線化三、填空題（每空1分，24分） 1軟件驗收測試包括哪三種類型？ 正式驗收測試，alpha測試，beta測試。2 .系統(tǒng)測試的策略（15種）功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試， 卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試 3設計系統(tǒng)測試計劃需要參考的項目文檔有？ 軟件測試計劃，軟件需求工件和迭代計劃4. 對面向過程的系統(tǒng)采用的集成策略有哪

39、兩種？自頂向下，自底向上兩種5通過畫因果圖來寫測試用例的步驟為、及把因果圖轉換為狀態(tài)圖共五個步驟。（1） 分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸岀條 件），并給每個原因和結果賦予一個標識符。（2） 分析軟件規(guī)格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系？根據這 些關系，畫出因果圖。（3）由于語法或環(huán)境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特 殊情況，在因果圖上用一些記號標明約束或限制條件。（4）把因果圖轉換成判定表。（5）把判定表的每一列拿岀來作為依據，設計測試用例。四、簡答題（共 37

40、分）1 階段評審與同行評審的區(qū)別。 （4 分） 同行評審目的 :發(fā)現小規(guī)模工作產品的錯誤 , 只要是找錯誤 ;階段評審目的 :評審模塊 階段作品的正確性 可行性 及完整性同行評審人數 :3-7 人 人員必須經過同行評審會議的培訓 ,由 SQA 指導階段評審人數 :5 人左右 評審人必須是專家 具有系統(tǒng)評審資格同行評審內容 :內容小 一般文檔 < 40 頁 , 代碼 < 500 行階段評審內容 : 內容多 ,主要看重點同行評審時間 :一小部分工作產品完成階段評審時間 : 通常是設置在關鍵路徑的時間點上 !2 什么是軟件測試。 （3 分）為了發(fā)現程序中的錯誤而執(zhí)行程序的過程3 簡述集成

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

42、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。6 系統(tǒng)測試計劃是否需要同行評審，為什么？（4 分）需要，系統(tǒng)測試計劃屬于項目階段性關鍵文檔，因此需要評審。7 Alpha 測試與 beta 測試的區(qū)別。 （4 分）Alpha 測試 在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試；測試后仍然會有少量的設計變更。這種測試一般由 最終用戶或其它人員完成，不能由程序或測試員完成。Beta 測試 當開發(fā)和測試根本完成時所做的測試， 最終的錯誤和問題需要在最終發(fā)行前找到。 這種測試一般 由最終用戶或其它人員完成，不能由程序員或測試員完成。8 比較負載測試、容量測試和強度測試的區(qū)別。（6 分）負載測試：在一

43、定的工作負荷下，系統(tǒng)的負荷及響應時間。強度測試：在一定的負荷條件下，在較長時間跨度內的系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響。 容量測試：容量測試目的是通過測試預先分析出反映軟件系統(tǒng)應用特征的某項指標的極限值（如最大并發(fā) 用戶數、數據庫記錄數等），系統(tǒng)在其極限值狀態(tài)下沒有岀現任何軟件故障或還能保持主要功能正常運行。 容量測試還將確定測試對象在給定時間內能夠持續(xù)處理的最大負載或工作量。容量測試的目的是使系統(tǒng)承 受超額的數據容量來發(fā)現它是否能夠正確處理。容量測試是面向數據的，并且它的目的是顯示系統(tǒng)可以處 理目標內確定的數據容量。9 .測試結束的標準是什么？ （3分）簡單答法：1所有測試用例執(zhí)行2所有缺

44、陷均關閉或者在商定的范圍內（要依據組織的能力以及測試的要求來）測試退岀標準（復雜版）產品的最終發(fā)布日期為 2007年*月*日。測試退出標準為完成測試需求中列出的所有功能及測試過程中發(fā) 現缺陷的回歸測試。下面分類闡述：一：單元測試退出標準1）單元測試用例設計已經通過評審2）核心代碼100%經過Code Review3）單元測試功能覆蓋率達到 100%4）單元測試代碼行覆蓋率不低于80 %5）所有發(fā)現缺陷至少60%都納入缺陷追蹤系統(tǒng)且各級缺陷修復率達到標準6）不存在A、B類缺陷7）C、D、E類缺陷允許存在8）按照單元測試用例完成了所有規(guī)定單元的測試9）軟件單元功能與設計一致 二：集成測試退岀標準1

45、）集成測試用例設計已經通過評審2）所有源代碼和可執(zhí)行代碼已經建立受控基線，納入配置管理受控庫，不經過審批不能隨意更改3）按照集成構件計劃及增量集成策略完成了整個系統(tǒng)的集成測試4）達到了測試計劃中關于集成測試所規(guī)定的覆蓋率的要求5）集成工作版本滿足設計定義的各項功能、性能要求6）在集成測試中發(fā)現的錯誤已經得到修改，各級缺陷修復率達到標準7）A、B類BUG不能存在8）C、D類BUG允許存在，但不能超過單元測試總 BUG的50%。9）E類BUG允許存在 三：系統(tǒng)測試退岀標準1）系統(tǒng)測試用例設計已經通過評審2）按照系統(tǒng)測試計劃完成了系統(tǒng)測試3）系統(tǒng)測試的功能覆蓋率達 100%4）系統(tǒng)的功能和性能滿足產

46、品需求規(guī)格說明書的要求5）在系統(tǒng)測試中發(fā)現的錯誤已經得到修改并且各級缺陷修復率達到標準6）系統(tǒng)測試后不存在 A、B、C類缺陷7）D類缺陷允許存在，不超過總缺陷的5 %8）E類缺陷允許存在，不超過總缺陷的10%三、問答題：（共25分）1、 項目的集中管理在軟件公司的哪一個層面？（2分）2、 請描述軟件測試活動的生命周期。（8分）開始-進行-迭代-結束3、什么是測試評估，測試評估的范圍是什么？ （5分）目的評估測試結果并記錄變更請求。 計算并交付測試的主要評測方法。生成測試評估摘要。步驟分析測試結果并提交變更請求評估基于需求的測試覆蓋評估基于代碼的測試覆蓋分析缺陷確定是否達到了測試的完成標準和成功

47、標準生成測試評估摘要輸入工件生成工件：測試計劃測試用例測試結果測試評估摘要4、闡述工作版本的定義。（2分）工作版本由一個或多個構件（通常為可執(zhí)行構件）構成，一般都是通過編譯和鏈接源代碼的處理過程從其 他構件中構建的。（UML表示：實施模型（頂級包或實施子系統(tǒng)）中的包，構造型為？build? o ）軟件測試工程師筆試試題 3測試人員考試試卷（考試時間 90 分鐘，滿分 100 分）姓名： 部門： 員工號： 一、判斷題（每題2分,正確的“V”，錯誤的“X”）1 、 好的測試員不懈追求完美。 （ 對 ）2、測試程序僅僅按預期方式運行就行了。 （ 錯 ）3、不存在質量很高但可靠性很差的產品。 （ 錯

48、）4、軟件測試員可以對產品說明書進行白盒測試。 （ 錯 ）5、靜態(tài)白盒測試可以找出遺漏之處和問題。 （ 對 ）6、總是首先設計白盒測試用例。 （ 錯）7、可以發(fā)布具有配置缺陷的軟件產品。 （對 ）8、 所有軟件必須進行某種程度的兼容性測試。（ 對 ）9、所有軟件都有一個用戶界面，因此必須測試易用性。 （ 錯 ）10、測試組負責軟件質量。 （ 錯）二、簡答題1、軟件的缺陷等級應如何劃分？（ 3 分） 答：影響進度的問題、死機、功能問題、界面問題、建議2、如果能夠執(zhí)行完美的黑盒測試，還需要進行白盒測試嗎？為什么？（5 分）答：需要，黑盒測試，測試人員完全不考慮程序內部的邏輯結構和內部特征，只依據程

49、序的需求分析規(guī)格 說明，檢查程序的功能是否符合它的功能說明。3、你認為一個優(yōu)秀的測試工程師應該具備哪些素質？（ 3 分）答：1、具有良好的計算機編程基礎 2、具有創(chuàng)新精神和超前意識 3、不懈努力，追求完美4、具有整體觀 念，對細節(jié)敏感 5、團隊合作精神6、責任心、耐心、細心、信心7、溝通能力8、時時保持懷疑態(tài)度，并且有缺陷預防的意識4、產品測試到什么時候就算是足夠了？（2分）測試一直貫穿軟件的整個生命周期，從需求、設計到編碼、實現一直到軟件的最終交付用戶。并不等于軟 件的調試。5、測試計劃的目的是什么？ （2分）答：用來識別任務、分析風險、規(guī)劃資源和確定進度。6、為什么要進行軟件測試 ？軟件測

50、試的目的是什么 ？（ 5分）7、軟件測試應該劃分幾個階段 ？簡述各個階段應重點測試的點 ？各個階段的含義？（5分）答：單元測試（測最小模塊）、集成測試（將模塊逐漸遞增）、系統(tǒng)測試（）、驗收測試。8、如何做一名合格的測試人員？（3分）想要成為一名合格的軟件測試人員，不僅需要理解和掌握測試理論、標準和規(guī)范，根據不同企業(yè)的產品特 點，要求了解相應的開發(fā)軟件測試方法，而且還要熟練操作一種甚至多種測試工具。9、針對缺陷采取怎樣的管理措施？ （5分）答：提交缺陷報告、分配缺陷報告、處理缺陷報告、返測報告、關閉缺陷報告三、專業(yè)詞語解釋（每題 2分）a測試：Alpha是用戶在開發(fā)結束時的測試。針對測試的結果可能還會進行一些小的設計更改。B測試：Beta測試是用戶在開發(fā)和測試全部結束后，并且在最終版本發(fā)布之前進行的測試。驅動模塊：驅動模塊在大多數場合稱為"主程序”，它接收測試數據并將這些數據傳遞到被測試模塊 樁模塊：集成測試前要為被測模塊編制一些模擬其下級模塊功能的“替身”模塊，以代替被測模塊的接口，接受或 傳遞被測模塊的數據，這些專供測試用的“假”模塊稱為被測模塊的樁模塊。白盒測試：也稱為結構