軟件測試工程師年終總結

第第頁軟件測試工程師年終總結

由于沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)覺軟件中存在的問題，實時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質量狀況。

2.、測試能給你帶來什么樣的歡樂?

測試可以給我?guī)碓S多歡樂,假如測試出一個項目缺少東西,我會很興奮,由于我對自己的工作有了新的認識,也為公司做了效益;假如測試出一個項目沒有問題,我也很興奮,由于同事們都在努力,大家都盼望為公司做貢獻,這就是一個很強大的團隊，這是一件多么另人興奮的事情啊!

27、文檔測試要留意什么?

文檔的讀者群、文檔的術語、文檔的正確性、文檔的完整性、文檔的全都性、文檔的易用性、樣例與例如、文檔的語言

3.、軟件測試的目的?

測試的目的是以最少人力、物力和時間找出軟件中潛在各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟件質量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患帶來的商業(yè)風險。

4.、Alpha測試與beta測試的區(qū)分

Alpha測試在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試;測試后仍舊會有少量的設計變更。這種測試一般由程序或測試員完成，不能由最終用戶或其它人員完成。

Beta測試當開發(fā)和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。

5.、簡述集成測試的過程

1.構建的確認過程。

2.補丁的確認過程。

3.Z34。

4.測試用例設計過程。

5.測試代碼編寫過程。

6.Bug的報告過程。

7.每周/每兩周的.構建過程。

8.點對點的測試過程。

9.組內培訓過程。

集成測試過程:集成測試計劃-集成測試設計-集成測試實現(xiàn)-集成測試執(zhí)行。

6.、質量的八大特性是什么?各種特性的定義?

1)功能性：軟件所實現(xiàn)的功能達到它的設計規(guī)范和滿意用戶需求的程度2)性能：在規(guī)定條件下,實現(xiàn)軟件功能所需的響應時間和計算機資源(CPU、內存、磁盤空間和數(shù)據(jù)吞吐量)的運用程度3)牢靠性：在滿意肯定條件的應用環(huán)境中，軟件能夠正常維持其工作的技能，在涌現(xiàn)一些錯誤操作時，軟件可以具有容錯性，假如軟件意外退出，重新啟動后可以復原最近的軟件數(shù)據(jù)4)安全性：為了防止意外或人為的破壞，軟件應具備的自身愛護技能5)運用性：用戶在理解、學習和操作軟件的過程中的付出的努力的難易程度6)維護性：軟件在運行維護過程中，假如涌現(xiàn)了運行故障或者擴展新功能和性能，軟件系統(tǒng)是否具有可分析性和良好的擴展性，重新設計后的軟件的穩(wěn)定性和可測試性7)移植性：軟件從現(xiàn)有運行平臺向另一個運行平臺過度的適應程度和平臺可替換性8)重用性：整個軟件或其中一部分能作為軟件包而被再利用的程度

7.、系統(tǒng)測試計劃是否需要同行審批，為什么

需要，系統(tǒng)測試計劃屬于項目階段性關鍵文檔，因此需要評審。

8.、軟件質量應當從哪些方面來評價?

牢靠性、安全性、性能、易用性、外觀、穩(wěn)定性

9.、系統(tǒng)測試包含哪些方面?

1.復原測試、2.安全測試、3.強度測試、4.性能測試

10.、區(qū)分階段評審的與同行評審

同行評審目的:發(fā)覺小規(guī)模工作產(chǎn)品的錯誤,只要是找錯誤;

階段評審目的:評審模塊階段作品的正確性可行性及完整性

同行評審人數(shù):3-7人人員需要經(jīng)過同行評審會議的培訓,由SQA指導

階段評審人數(shù):5人左右評審人需要是專家具有系統(tǒng)評審資格

同行評審內容:內容小一般文檔40頁,代碼500行

階段評審內容:內容多,主要看重點

同行評審時間:一小部分工作產(chǎn)品完成

階段評審時間:通常是設置在關鍵路徑的時間點上!

11.、測試結束的標準是什么?

1.用例全部執(zhí)行。2.掩蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準

12.、制定測試計劃之前需要了解什么問題?

1.軟件測試計劃的目的是什么?是否全部人都知道?他們同意這個測試計劃過程嗎?

2.測試的是什么產(chǎn)品?是新程序還是維護升級的?是獨立程序還是由多個小程序組成的?

3.產(chǎn)品的質量目標是什么?產(chǎn)品的功能需求和性能指標需要得到全部人的全都認可。

13.、請詳述設計測試用例的方法?(只是列出一個測試用例思索的方向，詳細設計靠閱歷)

①黑盒測試用例依據(jù)業(yè)務需求說明書來設計，分為：

等價劃分法邊界值分析法錯誤推想法因果圖法規(guī)律掩蓋法

②白盒測試用例通過討論代碼與程序結構可以分為以下兩種方式：

靜態(tài)測試：通過靜態(tài)的檢查程序代碼、界面、文檔中可能存在的錯誤的過程。

|-測試代碼編寫的規(guī)范性|-測試界面|-測試相關需求說明和用戶手冊是否符合實際要求

動態(tài)測試：通過路徑和分支測試。測試用例主要依據(jù)以下六種掩蓋測試方法設計

|-語句掩蓋|-判定掩蓋|-條件掩蓋|-判定/條件掩蓋|-組合掩蓋|-路徑掩蓋

14.、比較負載測試，壓力測試，容量測試和強度測試的區(qū)分

負載測試：在肯定的工作負荷下，系統(tǒng)的負荷及響應時間。通過逐步增加系統(tǒng)負載，最終確定在滿意性能指標的狀況下，系統(tǒng)能承受的最大負載量的測試。

強度測試：又稱疲憊強度測試，在系統(tǒng)穩(wěn)定運行的狀況下能夠支持的最大并發(fā)用戶數(shù)，持續(xù)執(zhí)行一段時間業(yè)務，通過綜合分析，確定系統(tǒng)處理最大工作量強度性能的過程?？隙ㄘ摵蓷l件下，在較長時間跨度內的系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響。

容量測試：容量測試目的是通過測試預先分析出反映軟件系統(tǒng)應用特征的某項指標的極限值(如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等)，系統(tǒng)在其極限值狀態(tài)下沒有涌現(xiàn)任何軟件故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續(xù)處理的最大負載或工作量。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)覺它是否能夠正確處理。容量測試是面對數(shù)據(jù)的，并且目的是顯示系統(tǒng)可以處理目標內確定的數(shù)據(jù)容量。

壓力測試：通過逐步增加系統(tǒng)負載，最終確定在什么負載條件下系統(tǒng)性能將處于崩潰狀態(tài)，以此獲得系統(tǒng)能提供的最大服務級別的測試。

15.、測試人員需要何時參與需求分析?

假如條件允許，原那么上來說是越早介入需求分析越好。由于測試人員對需求理解越深刻，對測試工作的開展越有利，可以盡早的確定測試思路，減削與開發(fā)人員的交互，減削對需求理解上的偏差。

16.、軟件的缺陷等級應如何劃分?

嚴峻：1.由于程序所引起的死機,非法退出2.死循環(huán)3.數(shù)據(jù)庫發(fā)生死鎖4.因錯誤操作導致的程序中斷5.功能錯誤6.與數(shù)據(jù)庫連接錯誤7.數(shù)據(jù)通訊錯誤。較嚴峻：1.程序錯誤2.程序接口錯誤3.數(shù)據(jù)庫的表、業(yè)務規(guī)章、缺省值未加完整性等約束條件。一般性：1.操作界面錯誤(包括數(shù)據(jù)窗口內列名定義、含義是否全都)2.打印內容、格式錯誤3.簡約的輸入限制未放在前臺進行掌握4.刪除操作未給出提示5.數(shù)據(jù)庫表中有過多的空字段。建議：1.界面不規(guī)范2.幫助說明描述不清晰3.輸入輸出不規(guī)范4.長操作未給用戶提示5.提示窗口文字未采納行業(yè)術語6.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標識。

17.、你自認為測試的優(yōu)勢在哪里?

優(yōu)勢在于我對測試堅決不移的信心和熱忱，雖然閱歷還不夠，但測試需要的基本技能我有信心在工作中得以發(fā)揮。

18.、你在測試中發(fā)覺了一個bug，但是開發(fā)經(jīng)理認為這不是一個bug，你應當怎樣解決。

1.假如不是錯誤那么應當主動承認不是缺陷。

2.假如是需求不明確的那么應和開發(fā)加強溝通補充需求。

3.假如和開發(fā)爭辯不休應當邀請上級判斷。

19.、您認為做好測試計劃工作的關鍵是什么?

1.明確測試的目標，加強測試計劃的有用性

2.堅持“5W”規(guī)章，明確內容與過程

3.采納評審和更新機制，保證測試計劃滿意實際需求

4.分別創(chuàng)建測試計劃與測試具體規(guī)格、測試用例

20.、風險和問題

◆市場的壓力

◆測試時間不夠

◆測試資源的實時到位

◆測試人員的技能需求

◆開發(fā)進度的改變，需求的變更

◆開發(fā)部門的版本掌握

◆短時間上線。這個是已經(jīng)定好的，沒有參考測試人員的看法。時間短往往不能得到充分的測試，測試策略需要依據(jù)可用的時間進行調整。盡快指出這樣的問題特別重要，只有這樣才能調整進度表，確定快速開發(fā)的風險并制定降低風險的策略。

◆新的設計過程。引入新的設計過程會增加風險，新的設計過程包括新的工具和設計技術。假如采納新的技術，能否像我們預期的那樣運轉，都存在很大的風險

◆繁復性。我們應當進行一些分析工作來確定哪個功能最繁復，哪個功能最簡單出錯，錯誤會對系統(tǒng)的哪些地方造成重大的影響。

◆運用頻率。軟件最常用功能中隱蔽的問題可能給用戶造成