軟體測試工程師年終總結
1.、為什麼要在一個團隊中開展軟體測試工作?
因為沒有經過測試的軟體很難在釋出之前知道該軟體的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將釋出時，從測試報告中得出軟體的質量情況。
2.、測試能給你帶來什麼樣的快樂?
測試可以給我帶來很多快樂,如果測試出一個專案缺少東西,我會很高興,因為我對自己的工作有了新的認識,也為公司做了效益;如果測試出一個專案沒有問題,我也很高興,因為同事們都在努力,大家都希望為公司做貢獻,這就是一個很強大的團隊，這是一件多麼另人振奮的事情啊!
27、文件測試要注意什麼?
文件的讀者群、文件的術語、文件的正確性、文件的完整性、文件的一致性、文件的易用性、樣例與示例、文件的語言
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的重現問題：有些Bu