軟件測試工程師工作總結

1、爲什麼要在一個團隊中開展軟件測試工作？
　　因爲沒有經過測試的軟件很難在發佈之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟件的質量情況。
2、測試能給你帶來什麼樣的快樂？
　　測試可以給我帶來很多快樂，如果測試出一個項目缺少東西，我會很高興，因爲我對自己的工作有了新的認識，也爲公司做了效益;如果測試出一個項目沒有問題，我也很高興，因爲同事們都在努力，大家都希望爲公司做貢獻，這就是一個很強大的團隊，這是一件多麼另人振奮的事情啊!
3、軟件測試的目的？
　　測試的目的是以最少人力、物力和時間找出軟件中潛在各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟件質量，迴避軟件發佈後由於潛在的軟件缺陷和錯誤造成的隱患帶來的商業風險。
4、Alpha測試與beta測試的區別
　　Alpha測試 在系統開發接近完成時對應用系統的測試；測試後仍然會有少量的設計變更。這種測試一般由程序或測試員完成，不能由最終用戶或其它人員完成。
　　Beta測試 當開發和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。
5、簡述集成測試的過程
　　1)構建的確認過程。
　　2) 補丁的確認過程。
　　3) Z34 。
　　4) 測試用例設計過程。
　　5) 測試代碼編寫過程。
　　6) Bug的報告過程。
　　7) 每週/每兩週的構建過程。
　　8) 點對點的測試過程。
　　9) 組內培訓過程。
集成測試過程:集成測試計劃->集成測試設計->集成測試實現->集成測試執行。
6、質量的八大特性是什麼？各種特性的定義？
　　1）功能性：軟件所實現的功能達到它的設計規範和滿足用戶需求的程度
　　2）性能：在規定條件下，實現軟件功能所需的響應時間和計算機資源(CPU、內存、磁盤空間和數據吞吐量)的使用程度
　　3）可靠性：在滿足一定條件的應用環境中，軟件能夠正常維持其工作的能力，在出現一些錯誤操作時，軟件可以具有容錯性，如果軟件意外退出，重新啓動後可以恢復最近的軟件數據
　　4）安全性：爲了防止意外或人爲的破壞，軟件應具備的自身保護能力
　　5）使用性：用戶在理解、學習和操作軟件的過程中的付出的努力的難易程度
　　6）維護性：軟件在運行維護過程中，如果出現了運行故障或者擴展新功能和性能，軟件系統是否具有可分析性和良好的擴展性，重新設計後的軟件的穩定性和可測試性
　　7）移植性：軟件從現有運行平臺向另一個運行平臺過度的適應程度和平臺可替換性
　　8）重用性：整個軟件或其中一部分能作爲軟件包而被再利用的程度
7、系統測試計劃是否需要同行審批，爲什麼
　　需要，系統測試計劃屬於項目階段性關鍵文檔，因此需要評審。
8、軟件質量應該從哪些方面來評價？
　　可靠性、安全性、性能、易用性、外觀、穩定性
9、系統測試包含哪些方面？
　　1.恢復測試、2.安全測試、3.強度測試、4.性能測試
10、區別階段評審的與同行評審
　　同行評審目的:發現小規模工作產品的錯誤，只要是找錯誤;
　　階段評審目的:評審模塊 階段作品的正確性 可行性 及完整性
　　同行評審人數:3-7人 人員必須經過同行評審會議的培訓，由SQA指導
　　階段評審人數:5人左右 評審人必須是專家 具有系統評審資格
　　同行評審內容:內容小 一般文檔 < 40頁， 代碼 < 500行
　　階段評審內容: 內容多，主要看重點
　　同行評審時間:一小部分工作產品完成
　　階段評審時間: 通常是設置在關鍵路徑的時間點上!
11、測試結束的標準是什麼？
　　1.用例全部執行。2.覆蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準
12、制定測試計劃之前需要了解什麼問題？
　　1)軟件測試計劃的目的是什麼？是否所有人都知道？他們同意這個測試計劃過程嗎？
　　2)測試的是什麼產品？是新程序還是維護升級的？是獨立程序還是由多個小程序組成的？
　　3)產品的質量目標是什麼？產品的功能需求和性能指標必須得到所有人的一致認可。
13、請詳述設計測試用例的方法？ （只是列出一個測試用例思考的方向，具體設計靠經驗）
　　①黑盒測試用例根據業務需求說明書來設計，分爲：
　　等價劃分法邊界值分析法錯誤推測法因果圖法邏輯覆蓋法
　　②白盒測試用例通過研究代碼與程序結構可以分爲以下兩種方式：
　　靜態測試：通過靜態的檢查程序代碼、界面、文檔中可能存在的錯誤的過程。
　　|-測試代碼編寫的規範性 |-測試界面 |-測試相關需求說明和用戶手冊是否符合實際要求
　　動態測試：通過路徑和分支測試。測試用例主要根據以下六種覆蓋測試方法設計
　　|-語句覆蓋 |-判定覆蓋 |-條件覆蓋 |-判定/條件覆蓋 |-組合覆蓋 |-路徑覆蓋
14、比較負載測試，壓力測試，容量測試和強度測試的區別
　　負載測試：在一定的工作負荷下，系統的負荷及響應時間。通過逐步增加系統負載，最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。
　　強度測試：又稱疲勞強度測試，在系統穩定運行的情況下能夠支持的最大併發用戶數，持續執行一段時間業務，通過綜合分析，確定系統處理最大工作量強度性能的過程。一定負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。
　　容量測試：容量測試目的是通過測試預先分析出反映軟件系統應用特徵的某項指標的極限值（如最大併發用戶數、數據庫記錄數等），系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。容量測試的目的是使系統承受超額的數據容量來發現它是否能夠正確處理。容量測試是面向數據的，並且目的是顯示系統可以處理目標內確定的數據容量。
　　壓力測試：通過逐步增加系統負載，最終確定在什麼負載條件下系統性能將處於崩潰狀態，以此獲得系統能提供的最大服務級別的測試。
15、測試人員需要何時參加需求分析？
　　如果條件允許，原則上來說是越早介入需求分析越好。因爲測試人員對需求理解越深刻，對測試工作的開展越有利，可以儘早的確定測試思路，減少與開發人員的交互，減少對需求理解上的偏差。
16、軟件的缺陷等級應如何劃分？
　　嚴重：1.由於程序所引起的死機，非法退出 2.死循環 3.數據庫發生死鎖 4.因錯誤操作導致的程序中斷 5.功能錯誤 6.與數據庫連接錯誤 7. 數據通訊錯誤。
　　較嚴重：1.程序錯誤 2.程序接口錯誤 3.數據庫的表、業務規則、缺省值未加完整性等約束條件。
　　一般性：1.操作界面錯誤（包括數據窗口內列名定義、含義是否一致） 2.打印內容、格式錯誤 3.簡單的輸入限制未放在前臺進行控制 4.刪除操作未給出提示 5.數據庫表中有過多的空字段。
　　建議：1.界面不規範 2.輔助說明描述不清楚 3.輸入輸出不規範 4.長操作未給用戶提示 5.提示窗口文字未採用行業術語 6.可輸入區域和只讀區域沒有明顯的區分標誌 。
17、你自認爲測試的優勢在哪裏？
　　優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。
18、你在測試中發現了一個bug，但是開發經理認爲這不是一個bug，你應該怎樣解決。
　　1)如果不是錯誤則應該主動承認不是缺陷。
　　2)如果是需求不明確的則應和開發加強溝通補充需求。
　　3)如果和開發爭論不休應該邀請上級判斷。
19、您認爲做好測試計劃工作的關鍵是什麼？
　　1)明確測試的目標，增強測試計劃的實用性
　　2)堅持“5W”規則，明確內容與過程
　　3)採用評審和更新機制，保證測試計劃滿足實際需求
　　4)分別創建測試計劃與測試詳細規格、測試用例
20、風險和問題
　　◆ 市場的壓力
　　◆ 測試時間不夠
　　◆ 測試資源的及時到位
　　◆ 測試人員的技能需求
　　◆ 開發進度的變化，需求的變更
　　◆ 開發部門的版本控制
　　◆ 短時間上線。這個是已經定好的，沒有參考測試人員的意見。時間短往往不能得到充分的測試，測試策略必須根據可用的時間進行調整。儘快指出這樣的問題非常重要，只有這樣才能調整時間表，確定快速開發的風險並制定降低風險的策略。
　　◆ 新的設計過程。引入新的設計過程會增加風險，新的設計過程包括新的工具和設計技術。如果採用新的技術，能否像我們預期的那樣運轉，都存在很大的風險
　　◆ 複雜性。我們應該進行一些分析工作來確定哪個功能最複雜，哪個功能最容易出錯，錯誤會對系統的哪些地方造成重大的影響。
　　◆ 使用頻率。軟件最常用功能中隱藏的問題可能給用戶造成嚴重的損失。
　　◆ 不可測試的需求。不可測試的需求會對系統的成功造成巨大的威脅。如果測試組在需求階段就驗證了需求的可測試性，對需求進行了評審，那麼此類問題會減少多。
21、軟件都有多少種分類?
　　固件、支持軟件、系統軟件、應用軟件
22、你認爲軟件測試過程中較常見的困難是什麼？如何有效克服這些困難？ （根據自己實際測試中遇到的情況來寫的）
　　①Bug的重現問題：有些Bug只是偶爾出現的，根本就不知道具體需要什麼條件才能重現Bug.
　　解決方法：將不能重現的Bug，利用截圖的方式記錄下來。並說明一系列的操作步驟
　　②Bug的更新：舊的Bug修改好之後，很多時候會引發更多Bug的出現。
　　解決方法：對更新的功能模塊重點的測試之後，再重新測試和更新的功能密切的模塊，會不會產生新的Bug.
　　③與開發人員的溝通和對業務流程理解的分歧，經常缺少需求文檔
　　解決方法：根據需求說明書和Bug情況，多多和開發人員進行交流
23、測試計劃工作的目的是什麼？測試計劃工作的內容都包括什麼？其中哪些是最重要的？
　　軟件測試計劃是指導測試過程的綱領性文件，對測試工作的計劃和安排包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
　　測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）
24、怎樣保證你所負責的模塊通過了測試
　　首先是瞭解用戶的需求，設計好的測試用例，嚴格的進行用例的評審，認真的執行測試用例，對自己提交的Bug進行詳細的描述。
　　反覆測試，增強測試的準確性，通過冒煙迴歸隨機測試挖掘缺陷提高測試工作質量，把各個模塊整體運行發現未曾出現的錯誤，完善測試用例
25、您認爲性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
　　性能測試工作的目的是檢查系統是否滿足在需求說明書中規定的性能，性能測試常常需要和強度測試結合起來，並常常要求同時進行軟件和硬件的檢測。性能測試主要的關注對象是響應時間，吞吐量，佔用內存大小（輔助存儲區），處理精度等。
26、怎麼編寫案例
　　案例的編寫與測試階段的定義有很大的關係。系統測試和unit測試的案例可能不同。總體而言測試案例根據系統的需求而定。
27、怎麼才能夠全面的測試到每一個點
　　測試的全面性主要需要在設計測試計劃的時候考慮，從測試策略，產品需求等等多個角度考慮從而定義全部的測試點。
28、常用的測試工具及分類
　　功能測試工具 — QTP；性能測試工具 — PerfermanceRunner/Loadrunner；測試管理工具 — TestCenter；
　　白盒測試工具 — Nunit，Junit，C++Test，JTest，BoundsChecker，Logiscope
29、軟件測試與調試的關係？
　1) 測試條件已知，規程可定義，結果可預知2) 測試可以計劃，過程可控3) 測試是檢驗，調試是推理過程4) 測試表明程序失敗，調試表明正確5) 測試可不瞭解設計細節6) 測試由非設計人員完成7) 測試有理論依據8) 測試可自動化
30、給你一個網站，你如何測試？
　　1.查找需求說明、網站設計等相關文檔，分析測試需求。
　　2.制定測試計劃，確定測試範圍和測試策略，一般包括以下幾個部分：功能性測試、界面測試、性能測試、數據庫測試、安全性測試、兼容性測試。
　　3.設計測試用例：
　　功能性測試：1鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。2提交功能的測試。3多媒體元素是否可以正確加載和顯示。4多語言支持是否能夠正確顯示選擇的語言等。
　　界面測試：1頁面是否風格統一，美觀 2頁面佈局是否合理，重點內容和熱點內容是否突出 3控件是否正常使用 4對於必須但爲安裝的空間，是否提供自動下載並安裝的功能 5文字檢查
　　性能測試：壓力測試、負載測試、強度測試
　　數據庫測試：要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
　　安全性測試：1基本的登錄功能的檢查2是否存在溢出錯誤，導致系統崩潰或者權限泄露3相關開發語言的常見安全性問題檢查，例如SQL注入等。4如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持
兼容性測試：根據需求說明的內容，確定支持的平臺組合。1瀏覽器的兼容性2操作系統的兼容性3軟件平臺的兼容性4數據庫的兼容性
　　4.開展測試，並記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
　　5.定期評審，對測試進行評估和總結，調整測試的內容。
31、您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，並以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。
　　有使用過LoadRunner，該工具能夠錄製測試人員的操作步驟，然後對這個操作步驟模擬出多個用戶來播放出來。1.Visural User Genertor創建腳本，選擇協議，錄製操作，編輯操作。2.中央控制器（Controller）調度虛擬用戶。創建場景，選擇腳本，建立虛擬用戶，設計shedual，設置ip spoofer。3.運行腳本。分析shedual。4.分析測試結果。
32、怎樣做好測試計劃
　　1.理解系統。從整個系統的高度瞭解被測系統必須滿足的功能和非功能性需求。利用涉及整個系統的文檔，形成對系統的整體瞭解。
　　2.及早介入。爲了深入瞭解項目，測試人員應該在系統的開始階段介入，可以增加對客戶需求，客戶問題，潛在風險，以及最重要的功能方面的理解
　　3.測試期望。程序員的期望是什麼？客戶的期望是什麼？銷售對測試的期望又是什麼？測試目標必須是絕對的，以免說不清楚是否達到目標。
　　4.吸取教訓。把以前工作中學習到的經驗教訓運用過來，對確定測試策略很有作用。
　　5.工作量大小。完成測試需要多少工作量？需要多少人員？
　　6.技術選擇。系統會採取什麼技術？系統會採用什麼架構？這些信息有助於確定測試策略和測試工具。
　　7.時間表。系統開發和測試分配的時間有多長？截止日期是什麼時候？
33、您是否瞭解以往所工作的企業的軟件測試過程？如果瞭解，請試述在這個過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？
　　軟件測試部門配合系統分析人員軟件需求分析討論，並根據需求說明書制定《項目測試計劃》，編寫測試用例，建立測試環境。軟件測試人員負責軟件開發部門的新產品測試及原有產品的升級測試，負責軟件問題解決過程跟蹤，負責軟件開發文檔開發工作的規範化及管理開發部門的產品文檔，製作用戶手冊及操作手冊，負責產品的上線測試，監督軟件開發過程的執行，提高產品質量。需求人員連同系統分析人員&測試人員開會討論需求。系統分析人員寫出需求分析說明，並連同系統分析人員&測試人員&需求人員開會討論可行性。系統分析人員寫出詳細設計說明書，程式人員編碼，給出系統流程圖。交與測試人員，測試人員給出Bug統計表。
34、系統測試階段低級缺陷較多怎麼辦？
　　公司有預測試這個流程，會在開展測試活動之前對主要功能點的正常流程做一個測試，以判斷這個版本是不是可測試版本，如果低級缺陷比較多，嚴重阻礙測試執行的話，我們會打回開發部，不執行測試。
35、缺陷流落到客戶那裏怎麼辦？
　　我們公司會儘可能的避免這種情況的出現，讓軟件缺陷在內部得到解決，萬一版本上線了才發現有問題，我們也會及時派技術人員在最短的時間內做出修改，把客戶的損失降到最低。
36、代碼會審是什麼？
　　對代碼的一個評審的過程，發現一些最基本的錯誤，方式是靜態的代碼走讀方式，在一些大型軟件的設計過程中，還是必不可少的。
37、請問功能測試和性能測試的區別是什麼？(只總結了兩個方面，有其他的自己補充)
　　①測試目的：
　　功能測試：檢查實際軟件的功能是否符合用戶的需求，測功能是不是全部實現，某個實現是不是有BUG。主要爲了發現以下幾類錯誤：A、是否有不正確或遺漏的功能？B、功能實現是否滿足用戶需求和系統設計的隱藏需求？ C、能否正確接收輸入？能否正確輸出結果？
　　性能測試：驗證軟件質量的三個質量特性，可靠性，正確性和效率。主要是測試產品的健壯性
　　②測試方式：
　　功能測試：按照系統需求說明書和測試用例，對產品的功能一步步進行測試。找出產品功能是否全部實現
　　性能測試：一般都使用性能工具對產品的健壯性進行評估。通過創建場景和虛擬用戶來模擬真是環境，進行壓力測試和負載測試。
38、狀態爲已修改的缺陷 實際沒有修改怎麼辦？
　　加強項目質量管理，提高項目執行能力。如果測試人員發現了這樣的問題，首先要弄清楚是什麼原因導致這種情況，最終還是要督促開發人員，修改掉這些問題。如果是不能重現的問題或者是老版本中遺留下來的問題不能修改的 要做好標示。
39、性能測試什麼時候開始最合適
　　一般在功能測試最後階段執行 因爲功能走通了 性能纔有意義 總之性能測試要根據用戶實際性能指標來操作 是一個很重要的測試活動 要根據軟件的屬性以及它的實際情況來制定策略
40、迴歸測試中 未解決的缺陷如何處理
　　實際項目中 也會因爲種種原因 出現最後一輪測試結束了 還有一些缺陷沒有解決 那麼對於問題的不同 我們有不同的解決方式：嚴重性問題：必須解決，不允許上線；功能性問題：可以考慮在後續版本中解決；一般性問題：可以不解決或者升級的時候解決。
41、集成測試通常都有那些策略？
1)在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；
　　2)各個子功能組合起來，能否達到預期要求的父功能；
　　3)一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
　　4)全局數據結構是否有問題；
　　5)單個模塊的 誤差積累起來，是否會放大，從而達到不可接受的程度。
42、軟件測試的對象
　　答：軟件測試並不等於程序測試。軟件測試應貫穿於軟件定義與開發的整個期間。
　　需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成爲軟件測試的對象。
43、什麼是UML？
　　答：Unified Modeling Language
　　它是一種用於描述，構造軟件系統以及商業建模的語言。簡單的理解就是它可以以一種直觀的方式表示出一個系統的各項內容。