測試工程師工作總結(jié)

測試工程師工作總結(jié)

工作總結(jié)的主要內(nèi)容為你在過去做了什么，現(xiàn)在的你對(duì)此怎么

看，未來打壞怎么樣改進(jìn)。卜面了幾篇關(guān)「測試，程加的J1作總站范

文，歡迎閱讀參考.

軟件測試匚程師工作總結(jié)一

一：20XX年工作【可顧及總結(jié)

回顧220XX年這一年來的工作，我在公司領(lǐng)導(dǎo)及各位同事的支

持和梢助下，嚴(yán)格要求門己，按照公司要求，比較好地完成了本職工

作。通過近一年的學(xué)習(xí)和工作，工作模式上行了新的突破,工作方式

有了較大的改變.現(xiàn)將這一年的工作情況總結(jié)如下：

K總體來說,20XX年我主要完成了“……銀行系統(tǒng)”、“……

渠道管理平臺(tái)”、“……”、”……”、44……””……”的日常測

試以及偵量控制工作;“……”已經(jīng)穩(wěn)定上線運(yùn)行6個(gè)多月,“……”

即將上線。

2、日常我主要負(fù)責(zé)項(xiàng)目測試工作、測試文檔、參與功能需求設(shè)

計(jì)、協(xié)調(diào)開發(fā)進(jìn)度、總結(jié)經(jīng)驗(yàn)分享、完成所需知識(shí)積累、工具學(xué)習(xí)及

研究、兼容性軟件測試。就在銀聯(lián)項(xiàng)目工作來說，主要的工作內(nèi)容右：

a、測試項(xiàng)目案例、測試用例的設(shè)計(jì)與編寫:b、對(duì)測試過程中遇到的

問題進(jìn)行溝通,并提供意見:c、設(shè)計(jì)業(yè)務(wù)功能流程,提供參考意見,

繪制關(guān)鍵業(yè)務(wù)流程;d、進(jìn)行主要功能的界面測試、功能測試:e、按照

測試用例執(zhí)行測試il?劃：r、進(jìn)行需求驗(yàn)證工作

3、知識(shí)的總結(jié)與分享，完成客戶端在安卓4.0/4.Liosa0以

上系統(tǒng)上出現(xiàn)的兼容等問題.完成了兼容性測試案例的編寫以及兼容

性測試的培訓(xùn)J1作.在日常J1作中，發(fā)現(xiàn)旅容上重大問胸，在測試部

門群中發(fā)布分享.

4,完成所需知識(shí)枳累，學(xué)習(xí)所需知識(shí)、工具以及技能.在工作

中學(xué)習(xí)「銀行業(yè)務(wù)流程規(guī)范、學(xué)習(xí)公司研發(fā)規(guī)范.參加了公司組織的

技術(shù)培訓(xùn)、學(xué)習(xí)了各種

測試工具的使用。

二：對(duì)公司的建議與意見

對(duì)公司和部門建設(shè)上，我有以下幾點(diǎn)建議：

1、對(duì)?員工進(jìn)行金融知識(shí)的系統(tǒng)培訓(xùn),讓測試人員了解銀行業(yè)務(wù)

流程?行助于測試人員更加詳細(xì)了解業(yè)務(wù)流程，測試過程會(huì)少走很多

彎路。

2、部門內(nèi)希望多組織技術(shù)交流付論，促進(jìn)測試工作的開展和提

高。一年至少有2次這樣的交流。

3、公司在項(xiàng)目開發(fā)前期，希望盡可能的明確需求，盡可能的詳

盡需求說明書內(nèi)容。在測試過程中發(fā)現(xiàn)很多項(xiàng)目缺少需求說明書，需

求說明書不明確或并需求說明15內(nèi)容錯(cuò)誤，誤導(dǎo)了開發(fā)和測浪我

了時(shí)間，影響了項(xiàng)目進(jìn)度。

4、建議項(xiàng)目需求設(shè)計(jì)可以有測試員參與討論。

5、公司管理有點(diǎn)混亂,個(gè)人感覺公司對(duì)每位員工的市視程度不

夠!節(jié)假日公司應(yīng)該給每位員r?定的福利和關(guān)心.

6、個(gè)人感覺平時(shí)的效率比較低，希望測試部門能夠有所訓(xùn)整.

希里公司能制定質(zhì)量控制標(biāo)準(zhǔn)以及開發(fā)、測試匚作流程.讓開發(fā)更好

的了解測試的流程，增強(qiáng)開發(fā)團(tuán)隊(duì)。測武團(tuán)隊(duì)的配合，提高」一作效率.

7、加強(qiáng)部門測試成果的積累與沉淀,提高團(tuán)隊(duì)測試水準(zhǔn)，希里

我們的團(tuán)隊(duì)能夠做的更好，能翎已團(tuán)隊(duì)的形*參，軟件項(xiàng)目的開發(fā)，

而不僅僅是一個(gè)頂H中也不起眼的小小測試員.

=：一年工作計(jì)劃與學(xué)習(xí)計(jì)劃

xx年工作計(jì)劃就此希望通過自己的努力，讓我們的產(chǎn)品更加完

美，讓自己在軟件測試技能上有所提高，更多的關(guān)注軟件產(chǎn)品的開發(fā)

過程,提高工作效率、做到與用戶的需求一?致,提高公司軟件產(chǎn)品用

戶滿意度。

具體來說xx年工作計(jì)劃有：努力提高自身測試水準(zhǔn),努力學(xué)習(xí)

金融知識(shí)以及業(yè)務(wù)流程，學(xué)會(huì)需求分析，掌握需求分析在測試中的作

用，參與公司更多的開發(fā)項(xiàng)目的測試工作。

********

201*年.月,口

軟件測試工程帥工作總結(jié)二

L、為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？

因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的庾量.

就好比ISO質(zhì)量認(rèn)證?樣，測試同樣也需要質(zhì)量的保證,這個(gè)時(shí)候就

需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的

問題，及時(shí)讓開發(fā)人員科知并修改問題，在即將發(fā)布時(shí)，從測試報(bào)告

中將出軟件的質(zhì)量情況.

2.、測試能給你帶來什么樣的快樂？

測試可以給我?guī)砗芏嗫鞓?如果測試出一個(gè)項(xiàng)目缺少東西，我

會(huì)很高興，因?yàn)槲覍?duì)自己的【:作行r新的認(rèn)識(shí),也為公司做r效前；如

果測試出?個(gè)項(xiàng)目沒有問題,我也就高興，因?yàn)橥聜兌荚谂?大家

都布望為公司做貢獻(xiàn)，這就是一個(gè)很強(qiáng)大的團(tuán)隊(duì)，這是一件多么另人

振奮的事情??！

27、文檔測試要注意什么？

文檔的讀者群、文檔的術(shù)語、文檔的正確性、文檔的完整性、

文檔的一致性、文檔的易用性、樣例與示例、文檔的語言

3.、軟件測試的目的？

測試的目的是以最少人力、物力和時(shí)間找出軟件中潛在各種錯(cuò)

識(shí)和缺陷.通過修正種錯(cuò)誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由

于潛在的軟件缺陷和錯(cuò)誤造成的隱患帶來的商業(yè)風(fēng)險(xiǎn)。

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

Alpha測試在系統(tǒng)開發(fā)接近完成時(shí)對(duì)應(yīng)用系統(tǒng)的測試;測試后仍

然會(huì)有少早.的設(shè)計(jì)變更。這種測試一般由程序或測試員完成，不能由

最終用戶或其它人員完成。

Beta測試當(dāng)開發(fā)和測試根本完成時(shí)所做的測試,最終的錯(cuò)誤和

問題需要在最終發(fā)行前找到?這種測試一般由最終用戶或其它人員完

成.不能由程序員或測試員完成。

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

1.構(gòu)建的確認(rèn)過程.2.補(bǔ)丁的確認(rèn)過程。3.Z34.4.測試用例設(shè)

計(jì)過程。5.測試代碼編寫過程.6.Bug的報(bào)告過程.7.每周/每兩周

的構(gòu)建過程。8.點(diǎn)對(duì)點(diǎn)的測試過程。9.組內(nèi)培訓(xùn)過程.

集成溶試過程：集成測試il劃-＞集成測試設(shè)計(jì)-）集成測試實(shí)現(xiàn)

集成測試執(zhí)行。

6.、質(zhì)量的八大特性是什么？各種特性的定義？

D功能性：軟件所實(shí)現(xiàn)的功能達(dá)到它的設(shè)計(jì)規(guī)范和滿足用戶需

求的程度2）性能：在規(guī)定條件下,實(shí)現(xiàn)軟件功能所需的響應(yīng)時(shí)間和計(jì)

兜機(jī)資源（CPI.、內(nèi)存、磁盤空間和數(shù)據(jù)吞葉.量）的使用程度3）可事性：

在滿足?定條件的應(yīng)用環(huán)境中，軟件能夠正常維持其工作的能力，在

出現(xiàn)一些錯(cuò)誤操作時(shí),軟件可以具有容錯(cuò)性，如果軟件意外退出.重

新啟動(dòng)后可以恢復(fù)最近的軟件數(shù)據(jù)，1）安全性：為了防止意外或人為

的破垢，軟件應(yīng)具備的自身保護(hù)能力5）使用性：用戶在理解,學(xué)習(xí)

和操作軟件的過程中的付出的努力的難易程度6）維護(hù)性：軟件在運(yùn)

行維護(hù)過程中，如果出現(xiàn)了運(yùn)行故障或者擴(kuò)展新功能和性能,軟件系

統(tǒng)是否具有可分析性和良好的擴(kuò)展性，重新設(shè)il后的軟件的穩(wěn)定性和

可測試性7）移植性：軟件從現(xiàn)有運(yùn)行平臺(tái)向另一個(gè)運(yùn)行平臺(tái)過度的

適應(yīng)程度和平臺(tái)可替換性8）重用性：挈個(gè)軟件或其中一部分能作為

軟件包而被再利用的程度

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

需要?系統(tǒng)測試計(jì)劃屈于項(xiàng)目階段性關(guān)鍵文檔.因此需要評(píng)審.

8.、軟件質(zhì)量應(yīng)該從哪些方面來評(píng)價(jià)？

可靠性、安全性、性能、易用性、外觀、稔定性

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

L恢圮測試、2.安全測試、3.限度測試、4.性能測試

10.、區(qū)別階段評(píng)審的與同行評(píng)審

同行評(píng)審”的：發(fā)現(xiàn)小規(guī)模工作產(chǎn)晶的錯(cuò)誤，只要是找錯(cuò)誤；

階段評(píng)審目的：評(píng)審模塊階段作品的正確性可行性及完整性

同行評(píng)審人數(shù)：3-7人人員必須經(jīng)過同行評(píng)審會(huì)議的培訓(xùn)，||]

SQA指導(dǎo)

階段評(píng)審人數(shù)：5人左右評(píng)審人必須是專家具有系統(tǒng)評(píng)審資格

同行評(píng)審內(nèi)容：內(nèi)容小段文檔《40頁，代碼＜500行

階段評(píng)審內(nèi)容：內(nèi)容我主要看近點(diǎn)

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

階段評(píng)審時(shí)間:通常是設(shè)置在關(guān)鍵路徑的時(shí)間點(diǎn)上！

11.、淵試結(jié)束的標(biāo)準(zhǔn)是什么?

I.用例全部執(zhí)行。2.凌蓋率達(dá)到標(biāo)準(zhǔn)。3.缺陷率達(dá)到標(biāo)準(zhǔn)。4.

其他指標(biāo)達(dá)到質(zhì)量標(biāo)準(zhǔn)

12.,制定測試計(jì)劃之前需要了解什么問題？

1.軟件測試計(jì)劃的目的是什么？是否所仃人都知道?他們同意這

個(gè)測試計(jì)劃過程嗎？

2.測試的是什么產(chǎn)品？是新程序還是維護(hù)升級(jí)的?是獨(dú)立程序還

是由多個(gè)小程序組成的?

3.產(chǎn)品的質(zhì)量目標(biāo)是什么？產(chǎn)品的功能需求和性能指標(biāo)必須得

到所有人的一致認(rèn)可.

13.、請(qǐng)?jiān)斒鲈O(shè)計(jì)泅試用例的方法？（只是列出?個(gè)測試用例思考

的方向，具體設(shè)計(jì)靠經(jīng)驗(yàn)）

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

等價(jià)劃分法邊界值分析法錯(cuò)誤推測法因果圖法邏輯明蓋法

②向盒測試用例通過研究代碼與程序結(jié)構(gòu)可以分為以下兩種方

式：

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

的借誤的過程.

I-測試代碼編寫的規(guī)范性i-測試界面-測成相關(guān)需求說明和用

戶手冊(cè)是否符合實(shí)際要求

動(dòng)態(tài)測試：通過路役和分支測試。測試用例主要根據(jù)以F六種

覆蓋測試方法設(shè)計(jì)

I-語句履蓋.1-判定覆蓋條件覆蓋I-判定/條件覆蓋-組合網(wǎng)

蓋I-路徑覆蓋

14,、比較負(fù)載測試，壓力測試,容量測試和強(qiáng)度測試的區(qū)別

負(fù)載測試：在一定的工作負(fù)荷下.系統(tǒng)的負(fù)荷及響應(yīng)時(shí)間。通

過逐步增加系統(tǒng)負(fù)載，最終硼定在滿足性能指標(biāo)的情況卜，系統(tǒng)能承

受的最大負(fù)敦量的測試。

強(qiáng)度測試：乂稱疲勞強(qiáng)度測試.在系統(tǒng)穩(wěn)定運(yùn)行的情況下能夠

支持的最大并發(fā)用戶數(shù),持續(xù)執(zhí)行一段時(shí)間業(yè)務(wù).通過綜合分析,確

定系統(tǒng)處理最大工作量強(qiáng)度性能的過程e?定負(fù)荷條件下，在較K時(shí)

間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能所造成的影響.

容吊測試：容量測試目的是通過測試預(yù)先分析出反映軟件系統(tǒng)

應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等）,

系統(tǒng)在裁極限化L狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能

正常運(yùn)行。容策測武還將確定測試對(duì)象在給定時(shí)間內(nèi)能帔持續(xù)處理的

最大負(fù)載或工作屬。容量測試的H的是使系統(tǒng)承受超題的數(shù)據(jù)容量來

發(fā)現(xiàn)它是否能夠正確處理。容量測試是面向數(shù)據(jù)的，并且目的是顯示

系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量。

壓力測試：通過逐步增加系統(tǒng)負(fù)我,最終確定在什么負(fù)載條件

下系統(tǒng)性能將處丁?崩潰狀態(tài)，以此獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的

測試。

15.、測試人員需要何時(shí)參加需求分析？

如果條件允許，原則上來說是越早介入需求分析越好。因?yàn)闇y

試人員對(duì)需求理解越深刻，對(duì)測試工作的開展越有利，可以盡早的確

定測試思路，成少與開發(fā)人員的交互，減少對(duì)?需求理解上的偏度。

16.、軟件的缺陷等級(jí)應(yīng)如何劃分？

嚴(yán)重：1.由于程序所引起的死機(jī).非法退出2.死循環(huán)3.數(shù)據(jù)庫

發(fā)生死鎖4.因錯(cuò)i吳操作導(dǎo)致的程序中斷5.功能錯(cuò)誤6.與數(shù)據(jù)庫連接

錯(cuò)誤7.數(shù)據(jù)通訊錯(cuò)誤。較嚴(yán)重：1.程序錯(cuò)誤2.程序接口錯(cuò)誤3.數(shù)據(jù)

庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件,一般性：1.操作

界面借誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義足否-,致）2.打印內(nèi)容、格

式錯(cuò)誤3.藺單的輸入限制未放在前臺(tái)進(jìn)行控制4.刪除操作未給出提

示5.數(shù)據(jù)庫農(nóng)中有過多的空字段.也議?1.界而不規(guī)范2?輔助說明

描述不清楚3.輸入輸出不規(guī)范1.長操作未給用戶提示工提示窗口文

字未采用行業(yè)術(shù)語6,可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志。

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

優(yōu)勢在于我對(duì)測武堅(jiān)定不移的信心和熱情，雖然經(jīng)齡還不桀，

但測試需要的基本技能我行信心在工作中得以發(fā)揮。

18.、你在測試中發(fā)現(xiàn)了一個(gè)bug,但是開發(fā)經(jīng)理認(rèn)為這不是一

個(gè)bug,你應(yīng)該怎樣解決。

1.如果不足錯(cuò)誤則應(yīng)該主動(dòng)承認(rèn)不是缺陷.

2.如果是需求不明確的則應(yīng)和開發(fā)加強(qiáng)溝通補(bǔ)充需求。

3.如果和開發(fā)爭論不休應(yīng)該邈請(qǐng)上級(jí)判斷。

19.、您認(rèn)為做好測試計(jì)劃工作的關(guān)處是什么？

1.明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性

2,堅(jiān)持“5W”規(guī)則,明確內(nèi)容與過程

3,采用評(píng)審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求

4,分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例

20.,風(fēng)險(xiǎn)和問題

?市場的壓力?測試時(shí)間不夠?測試資源的及時(shí)到位?測試人

員的技能需求?開發(fā)進(jìn)度的變化,需求的變更?開發(fā)部門的版本控制

?短時(shí)間上線.這個(gè)是已經(jīng)定好的,沒有參考測試人員的意見。時(shí)間

短往往不能得到充分的測試，測試策略必須根據(jù)可用的時(shí)間進(jìn)行調(diào)整。

盡快指出這樣的問題II:常近要，只有這樣才能消整時(shí)間表，確定快速

開發(fā)的風(fēng)險(xiǎn)并制定降低風(fēng)險(xiǎn)的策略。?新的設(shè)計(jì)過程。引入新的設(shè)計(jì)

過程會(huì)增加風(fēng)險(xiǎn)，新的設(shè)il過程包括新的工具和設(shè)計(jì)技術(shù)。如果采用

新的技術(shù),能否像我們預(yù)期的那樣運(yùn)轉(zhuǎn)，都存在很大的風(fēng)險(xiǎn)?兔雜性.

我們應(yīng)該進(jìn)行一些分析口乍來確定哪個(gè)功能最復(fù)雜，哪個(gè)功能最容易

出借，錯(cuò)誤會(huì)對(duì)系統(tǒng)的嫌些地方造成重大的影響。?使用頻率。軟件

最常用功能中隱藏的問題可能給用戶造成嚴(yán)肅的損失。?不可測試的

需求。不可測試的需求會(huì)對(duì)系統(tǒng)的成功造成巨大的威脅。如果測試組

在需求階段就驗(yàn)證了需求的可測試性,對(duì)鬣求進(jìn)行了評(píng)審，那么此類

問題會(huì)減少很多.

21.、軟件都付多少種分類？

固件、支持軟件、系統(tǒng)軟件、應(yīng)用軟件

22.、你認(rèn)為軟件測試過程中較常見的困難是什么？如何有效克

服這優(yōu)困雄？（根據(jù)門已實(shí)際測試中遇到的情況來寫的）

①?Bug的市現(xiàn)問題：有些BUR只是偶爾出現(xiàn)的，根本就不知道

具體需要什么條件才能重現(xiàn)Bug.

?解決方法:將不能重現(xiàn)的Bug.利用截圖的方式記錄下來。并

說明一系列的操作步驟

②?Rug的更新：舊的Bug修改好之后，很多時(shí)候會(huì)引發(fā)更多Bug

的出現(xiàn)。

?解決方法：對(duì)更新的功能模塊用點(diǎn)的測試之后.再市新測試和

更新的功能密切的模塊，會(huì)不會(huì)產(chǎn)生新的Bug.

③?與開發(fā)人員的溝通和對(duì)業(yè)務(wù)流程理解的分岐，妊常缺少需求

文檔

?解決方法：根據(jù)需求說明書和Bug情況，多多和開發(fā)人員進(jìn)行

交流

23.、測試計(jì)劃工作的目的是什么?測試計(jì)劃「作的內(nèi)容都包括

什么？其中哪些是最重要的？

軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，對(duì)測試工作的計(jì)

劃和安排包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配

置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容.借助軟件測

試計(jì)劃,參與測試的項(xiàng)目成員,尤其是測試管理人員，可以明確測試

任務(wù)和測試方法,保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)

度，應(yīng)對(duì)測試過程中的各種變更。

測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是故略和戰(zhàn)術(shù)的關(guān)系,

測試計(jì)劃主要從宏觀上規(guī)劃測試活動(dòng)的范圍、方法和資源配置，而測

試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù).所以其中最垂要

的是測試測試策略和測試方法（最好是能先評(píng)審）

24.、怎樣保證你所負(fù)責(zé)的模塊通過了測試

首先是了解用戶的需求，設(shè)計(jì)好的測試用例，嚴(yán)格的進(jìn)行用例

的評(píng)審.認(rèn)真的執(zhí)行測試用例,對(duì)自己提交的Bug進(jìn)行詳細(xì)的描述.

反復(fù)測試,增強(qiáng)測試的準(zhǔn)確性,通過官煙回歸隨機(jī)測試挖掘缺廉

提高測試工作放比,把各個(gè)模塊整體運(yùn)行發(fā)現(xiàn)未曾出現(xiàn)的錯(cuò)誤，完善

測試用例

25.、您認(rèn)為性能測試工作的目的是什么？做好性燙測試工作的

關(guān)鍵是什么?

性能測試，作的目的是檢儀系統(tǒng)是否滿足在需求說明書中規(guī)定

的性能，性能測試常常需要和強(qiáng)度測試結(jié)合起來，并幡常要求同時(shí)進(jìn)

行軟件和假件的愴測“性能漓試主要的關(guān)注對(duì)象是響應(yīng)時(shí)間，件吐眼，

占用內(nèi)存大?。ㄝo助存儲(chǔ)區(qū)）,處理精度等。

26.、怎么編寫案例

案例的編寫與測限階段的定義有很大的關(guān)系。系統(tǒng)測試和unit

測試的案例可能不同.總體而言測試案例根據(jù)系統(tǒng)的需求而定0

27.、怎么才能夠全面的測試到每一個(gè)點(diǎn)

測試的全面性主要需要在設(shè)計(jì)測試計(jì)劃的時(shí)候考慮，從測試策

略，產(chǎn)品轉(zhuǎn)求等等多個(gè)角度考慮從而定義全部的測試點(diǎn).

28.、常用的測試工具及分類

功能測試工具一QTP;性能溶試工具一LoadRunner;測試管理工

具一Test?rector;

白盒正試工具一Nunit,Junit.C++Test.JTest.BoundsChecker.

Logiscope

291,軟件測試與調(diào)試的關(guān)系？

D測試條件已知,規(guī)程可定義,結(jié)果可預(yù)知2）測試可以計(jì)劃，

過程可控3）測試是檢驗(yàn),調(diào)試是推理過程4）測試表明程序失敗,調(diào)

試表明正確5）測試可不了解設(shè)計(jì)細(xì)節(jié)6）測試由非設(shè)計(jì)人員完成7）測

試有理論依據(jù)8）測試可H動(dòng)化

30.、給你?個(gè)網(wǎng)站，你如何測試？

1.查找需求說明、網(wǎng)站設(shè)計(jì)等相關(guān)文檔,分析測試需求.

2.制定測試讓劃，確定測試范圍和測試策略，一般包括以卜兒

個(gè)部分：功能性測試、界面測試、性能測試、數(shù)據(jù)庫測試、安仝性測

試、兼容性測試.

3.設(shè)計(jì)測成用例：

功能性測試：1性接測試.鞋接是否正確跳轉(zhuǎn)，是否存在空頁

面和無效頁面，是否有不正確的出錯(cuò)信息返回等02提交功能的測試.

3多媒體元案是否可以正確加載和顯示。4多泌言支持是否能夠止確

顯示選擇的語行等.

界面測試：1頁面是否風(fēng)格統(tǒng)一，美觀2頁面布局是否合理.

重點(diǎn)內(nèi)容和熱點(diǎn)內(nèi)容是否突出3控件是否正常使用4對(duì)于必須但為安

裝的空間，是否提供自動(dòng)卜.我并安裝的功能5文字檢杳

性能測試：壓力測成、負(fù)載測試、強(qiáng)度測試

數(shù)據(jù)庫測試：要具體決定是否需要開展.數(shù)據(jù)庫一股需要考慮

連結(jié)性，對(duì)數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗(yàn)證等方面.

安全性測試：1幕本的登錄功能的檢/2是否存在溢出錯(cuò)俁，

導(dǎo)致系統(tǒng)崩漬或者權(quán)限泄露3相關(guān)開發(fā)語言的常見安全性問題檢杳,

例如SQL注入等。4如果需要高級(jí)的安全性測試,確定獲得專業(yè)安全

公司的幫助,外包測試,或者獲取支持

兼容性測試:根據(jù)需求說明的內(nèi)容，確定支持的平臺(tái)組合e.I

瀏覽器的兼容性2操作系統(tǒng)的兼咨性3軟件平臺(tái)的兼容性4數(shù)據(jù)庫的

兼容性

4.開展測試，并記錄缺陷。合理的安拄調(diào)整測試進(jìn)度,提前獲

取測試所需的資源，建立管理體系(例如，需求變更、風(fēng)險(xiǎn)，配置、

測試文檔、缺陷報(bào)告、人力貸源等內(nèi)容)。

5.定期評(píng)巾，對(duì)測試進(jìn)行評(píng)估和總結(jié),調(diào)整測試的內(nèi)容。

31.、您在從事性能測試工作時(shí),是否使用過一些測試工具？如

果行，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟?并以一個(gè)具體的工作中的例子描述

該工具是如何在實(shí)際工作中應(yīng)用的.

行使用過I-oadRunner,該工具能夠錄制測試人員的操作步驟.

然后對(duì)這個(gè)操作步驟模擬出多個(gè)用戶來播放出來.

I.VisundlserGenertor創(chuàng)建腳本，選擇協(xié)議，錄制操作，操作。2.

中央控制器(Controller)調(diào)度虛擬用戶.創(chuàng)建場景，選擇腳本,建立

虛擬用戶，設(shè)計(jì)shedual,設(shè)置ipspoofer(>3,運(yùn)行腳本。分析shedual.

I.分析泅試結(jié)果。

32.,怎樣做好測試計(jì)劃

1.理解系統(tǒng)。從整個(gè)系統(tǒng)的高度了解被測系統(tǒng)必須滿足的功能

和十功能性需求。利用涉及整個(gè)系統(tǒng)的文檔，形成對(duì)系統(tǒng)的整體了解.

2.及陸介入.為j深入/解項(xiàng)目,測試人員應(yīng)該在系統(tǒng)的開始

階段介入.可以增加對(duì)客戶需求,客戶問題,潛在風(fēng)酸，以及最重?要

的功能方面的理解

3.測試期曳.程序員的期里是什么？客戶的期望是什么？銷華對(duì)

測試的期望又站什么？測試目標(biāo)必須是絕對(duì)的,以免說不清楚是否達(dá)

到目標(biāo)。

4.吸取教訓(xùn).把以前工作中學(xué)習(xí)到的經(jīng)聆教訓(xùn)運(yùn)用過來，對(duì)確

定測試策略很有作用。

5.工作量大小。完成泅試需要多少工作用?需要多少人員？

6.技術(shù)選擇。系統(tǒng)會(huì)采取什么技術(shù)？系統(tǒng)會(huì)采用什么架構(gòu)?這些

信息有助于確定測試策略和測試工具。

7.時(shí)間表。系統(tǒng)開發(fā)和測試分配的時(shí)間仃多長？被止日期是什么

時(shí)候？

33.、您是否了於以往所工作的企業(yè)的軟件測試過程?如果了解,

請(qǐng)?jiān)囀鲈谶@個(gè)過程中都右哪些工作要做?分別由哪些不同的角色來完

成這些工作？

軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需

求說明書制定《項(xiàng)目測試計(jì)劃》，編寫泅試用例，建立測試環(huán)境。軟

件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級(jí)測試,

負(fù)資軟件問題解決過程跟蹤，負(fù)荷■軟件開發(fā)文檔開發(fā)工作的規(guī)范化及

管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊(cè)及操作手冊(cè),負(fù)責(zé)產(chǎn)品的上

線測試,監(jiān)旨軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。需求人員連同系

統(tǒng)分析人員&測試人員開會(huì)討論需求。系統(tǒng)分析人員寫出需求分析說

明，并連同系統(tǒng)分析人員&測試人員&需求人員開會(huì)討論可行性.系統(tǒng)

分析人員寫出詳細(xì)設(shè)il?說明回程式人員編螞,給出系統(tǒng)流程圖。交

V測試人員,測試人員給出Bug統(tǒng)計(jì)表.

34.,系統(tǒng)測試階段低級(jí)缺陷較多怎么辦？

公司有位泅試這個(gè)流程，分在開展測試活動(dòng)之前對(duì)主要功能點(diǎn)

的正常流程做一個(gè)測試，以判斷這個(gè)版本是不是可測試版本，如果低

級(jí)缺陷比較多，嚴(yán)重阻礙測試執(zhí)行的話，我們會(huì)打網(wǎng)開發(fā)部，不執(zhí)行

測試。

35.、缺陷流落到客戶那里怎么辦？

我們公司會(huì)盡可能的瞪免這種情況的出現(xiàn)，讓軟件跳陷在內(nèi)部

得到解決.萬?版本上線了才發(fā)現(xiàn)有問胭，我們也會(huì)及時(shí)派技術(shù)人員

在最短的時(shí)間內(nèi)做出修改，把客戶的損失降到最低，

36.、代碼會(huì)審是什么？

對(duì)代碼的一個(gè)評(píng)審的過程，發(fā)現(xiàn)一些最基本的錯(cuò)誤，方式是靜

態(tài)的代碼走讀方式，在一些大型軟件的設(shè)計(jì)過程中,還是必不可少的.

37.、請(qǐng)問功能測試和性能測試的區(qū)別是什么？（只總結(jié)了兩個(gè)方

面，有其他的自己補(bǔ)充）

①測試目的：

?功能測試：檢杳實(shí)際軟件的功能是否符合用戶的需求,測功能

是不是全部實(shí)現(xiàn)，某個(gè)實(shí)現(xiàn)是不是仃RUG。主要為了發(fā)現(xiàn)以下幾類錯(cuò)

誤：力、是否有不正確或遺漏的功能?B、功能實(shí)現(xiàn)是否滿足用戶需求

和系統(tǒng)設(shè)計(jì)的隱藏需求?C、能否正確接收輸入?能否正確輸出結(jié)果？

?性能測試：驗(yàn)證軟件質(zhì)量的三個(gè)質(zhì)量特性，可轅性，正確性和

效率。主要是測試產(chǎn)品的健壯性

②測試方式：

?功能測試：按照系統(tǒng)需求說明“和測試用例，對(duì)產(chǎn)品的功能一

步步進(jìn)行測試0找出產(chǎn)品功能是否全部實(shí)現(xiàn)

?性能測試：一般都使用性能工具對(duì)產(chǎn)品的健壯性進(jìn)行評(píng)估。通

過創(chuàng)建場景和虛擬用戶來模擬真是環(huán)境，進(jìn)行壓力測試和負(fù)載測試。

38.、狀態(tài)為已修改的缺陷實(shí)際沒有修改怎么辦？

加強(qiáng)項(xiàng)目質(zhì)量管理，提高項(xiàng)目執(zhí)行能力。如果測試人員發(fā)現(xiàn)了

這樣的問題,首先要弄清楚是什么原因?qū)е逻@種情況.最終還是要督

促開發(fā)人員,修改掉這些問題.如果是不能肅現(xiàn)的問題或者是老版本

中遺留下來的問題不能修改的要做好標(biāo)示.

39.、性能測試什么時(shí)候開始最合適

?股在功能測試最后階段執(zhí)行因?yàn)楣δ茏咄ā感阅懿庞幸饬x總

之性能測試要根據(jù)用戶實(shí)際性能指標(biāo)來操作是一個(gè)很求要的測試活

動(dòng)要根據(jù)軟件的屬性以及它的‘實(shí)際情況來制定策略

40.、回婦測試中未解決的缺陷如何處理

實(shí)際項(xiàng)目中也會(huì)閃為種種原因出現(xiàn)最后一輪測試結(jié)束了還有一

些缺陷沒仃解決那么對(duì)于問題的不同我們仃不同的解決方大：嚴(yán)重性

問題：必須解決,不允許上線;功能性問題：可以考慮在后續(xù)版本中

解決；一股性問梗：可以不解決或者升級(jí)的時(shí)帔解決.

41.,集成測試通常都有那些策略？

1）在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接11的數(shù)據(jù)是否會(huì)

丟失；

2）各個(gè)了?功能組合起來，能否達(dá)到預(yù)期要求的父功能；

3）一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影

響；

力全后數(shù)據(jù)結(jié)構(gòu)是否有同題；

5）單個(gè)模塊的誤差積累起來，是否會(huì)放大，從而達(dá)到不可接受

的程度。

42.軟件測試的對(duì)象

答：軟件測試并不等于程序測試.軟件測試應(yīng)貫穿于軟件定義

與開發(fā)的整個(gè)期間，

需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到

的文檔，包括需求規(guī)格說明、概要設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明

以及源程序，都應(yīng)成為軟件測試的對(duì)以。

43.什么是UML?

答：InifiedModelingl^ingUcige

它是一種用于描述，構(gòu)造軟件系統(tǒng)以及商業(yè)建模的語言。衙單

的理解就是它可以以一種宜觀的方式表示出一個(gè)系統(tǒng)的各項(xiàng)內(nèi)容。

44.,什么是測試策略

測試策略描述測試工程的總體方法和目標(biāo)主要包括以F三個(gè)方

I畫定的測試技術(shù)和工具

2制定測試啟動(dòng)停止完成標(biāo)準(zhǔn)

3風(fēng)險(xiǎn)分析和應(yīng)對(duì)方案

我目的是為我們更好的寫出高質(zhì)量的用例提供支撐

-15.軟件溜試按過程分為三個(gè)步驟

單元測試：單元測試乂稱模塊惻試，是針對(duì)軟件設(shè)計(jì)的最小單

位一程序模塊，進(jìn)行正確性檢噲的測試工作。其II的在于發(fā)現(xiàn)各模塊

內(nèi)部可能存在的各種差錯(cuò)。

單元泅試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測試用例.多個(gè)模塊

可以平?行地獨(dú)立進(jìn)行單元測試。

集成測試：在運(yùn)行（可能是不完整）的應(yīng)用中保證軟件單元被結(jié)

合后能正常操作的測試執(zhí)行的階段

系統(tǒng)測試：當(dāng)應(yīng)用作為整體運(yùn)行時(shí)的測試執(zhí)行階段

46.軟件測試員和組長的職費(fèi)分工

普通測試員：

?創(chuàng)作相關(guān)的測試汁劃和測試案例

?識(shí)別可自動(dòng)測試的區(qū)域

?參與組內(nèi)的測試計(jì)劃和測試案例以及測試腳本分析工作

?手動(dòng)或Ei動(dòng)測試

?按照需求規(guī)格說明點(diǎn)證并驗(yàn)證各項(xiàng)功能

?發(fā)現(xiàn)并報(bào)告bug,跟蹤其狀態(tài)

?初步評(píng)估bug對(duì)產(chǎn)品其他部分的影響

測試組長：

?確定測試的策略

?參與對(duì)整個(gè)產(chǎn)品的完整測試計(jì)劃的制定

?參。并管理測試

?評(píng)估如8對(duì)用戶的影響

?跟蹤關(guān)鉞bug狀態(tài)

?管理用試工作和對(duì)象的資源

?參與面試新人

?交流狀態(tài)和存在問題，并驅(qū)動(dòng)問題的解決

?促進(jìn)組內(nèi)的交流

47.什么是bug?

軟件的Bug指的是軟件中（包括程序和文檔）不符合用戶需求的

問題.

常見的軟件Bug分為以下三類：

?沒有攻現(xiàn)的功能

?完成r用戶需求的功能，但是運(yùn)行時(shí)會(huì)出現(xiàn)一些功能或性能上

的問題

?實(shí)現(xiàn)了用戶不需要的多余的功能

48.什么是QN?

CMM：CapabilityMaturityModel.即“能力成熟度模型”。

它是一個(gè)分5級(jí)的、可以描述結(jié)構(gòu)完善程度的模型，用它來說

明所交付的軟件的效能.

49.您認(rèn)為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通

的效率和改善溝通的效果?維持測試人員同開發(fā)團(tuán)隊(duì)中犬他成員良好

的人際關(guān)系的關(guān)欖是什么？

盡就能有面對(duì)面的溝通，如果做小到，那么盡后能直接通過電

話溝通，如果只能通過同HiI等『.及時(shí)溝通I：具的話，強(qiáng)調(diào)必須對(duì)特

性的理解深刻以及能表達(dá)清楚。

一是真誠?二是團(tuán)隊(duì)精神.三是在專業(yè)上有共同語言，當(dāng)然也

可以通過口接指出-一些小問題，而不是進(jìn)入BUGTrackingSystem來增

加對(duì)方的好感。

50.你們以前的測試流程是怎樣的？

明確需求一一測試計(jì)劃——制定測試策略和測試用例——搭建

測試環(huán)境、執(zhí)行測試用例、提交缺陷報(bào)告——對(duì)測試過程和版本質(zhì)量

評(píng)估得出測試總結(jié)報(bào)告——最后驗(yàn)收測試

51.請(qǐng)?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、

系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系:

黑盒正試：把測成對(duì)象當(dāng)成?個(gè)黑盒子，測試人員完全不考慮

邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢杳程式的功便是

否滿足它的功能說明。

單元測試：白盆測試的一種,對(duì)軟件設(shè)計(jì)中的單兀模塊進(jìn)行測

試.

集成測試：在單元測試的基礎(chǔ)匕對(duì)單元模塊之間的連接和組

裝進(jìn)行測試。

系統(tǒng)測試：在所行都考慮的情況下，對(duì)系統(tǒng)進(jìn)行測試。

臉收測試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測試.

52.您以往的工作中是否曾開展過測試用例的評(píng)審_L作？如果行,

請(qǐng)描述測試用例評(píng)審的過程和評(píng)審的內(nèi)容。

53.軟件本地化測試和功能測試都行那些方面要注意？

本地化就是將軟件版本語*進(jìn)行更改，比如將英文的windows

改成中文的windows就是本地化。

本地化測試過程中的測試工作集中在：

?受本地化影響的方面，如W和內(nèi)容

?區(qū)域件或區(qū)域設(shè)置特定的、語方特定的和地區(qū)特定的方面

?基本功能測試

?在本地化環(huán)境中運(yùn)行的安裝和升級(jí)測試

?根據(jù)產(chǎn)品的目標(biāo)地M：計(jì)劃應(yīng)用程序和硬件煎容性測試。

54.什么是軟件質(zhì)量？

高質(zhì)量的軟件是適當(dāng)?shù)?無錯(cuò)誤的，能在預(yù)算內(nèi)按時(shí)交貨，滿

足需求/或期望，并且是可維護(hù)的。所以，質(zhì)量是?個(gè)主觀的術(shù)語。

它取決于譙是客戶以及客戶對(duì)項(xiàng)II計(jì)劃的影響。對(duì)?個(gè)軟件開發(fā)項(xiàng)目

來說，“客戶”的范用很廣,包括最終用戶、客戶所接受的測忒者、

9客戶合同有關(guān)的官員'客戶管理'開發(fā)機(jī)構(gòu)的管理者/會(huì)計(jì)/測試人

員/銷售人員、未來的軟件維護(hù)工程師、股票持有者、雜志專欄記者.

等等。每一類客戶對(duì)“質(zhì)量”都有自己的傾向性-會(huì)計(jì)部門判斷質(zhì)量

會(huì)從其收益來考慮，而最終用戶則面視友好的用戶界面和沒有錯(cuò)誤.

55.為什么軟件會(huì)有毛病？

1.交流錯(cuò)誤或者沒行進(jìn)行交流.需求不明確

2.軟件的復(fù)雜性編程錯(cuò)誤

3.需求變更客戶恐怕不明白改變需求的影響，也許是知道但依

然需要變更——會(huì)導(dǎo)致重新設(shè)il、重訂工程進(jìn)度表、對(duì)其他項(xiàng)目的影

響、已完成的工作需要求做或存放充、對(duì)硬件需求的彩響等等。如果

在頊H中出現(xiàn)許多小的改變或一個(gè)大的改變,在項(xiàng)目各部分中出現(xiàn)已

知或的相關(guān)的問翹，可能會(huì)相互影響并導(dǎo)致出現(xiàn)問而且，不斷地

變更也會(huì)增加軟件的曳雜性，可能會(huì)導(dǎo)致錯(cuò)誤的出現(xiàn)。這樣就會(huì)影響

技術(shù)人員的積極性.在?些快速變化的商業(yè)環(huán)境里，持續(xù)變更需求的

場響是致命的.在這種情況下，管理者必須知道它的危險(xiǎn)性.質(zhì)量保

障和測試工程師必須與此相適應(yīng).并安排持續(xù)的廣泛的測試,以克服

不可避免產(chǎn)生的問題。

4.時(shí)間壓力

因?yàn)樾性S多猜測成分，軟件開發(fā)項(xiàng)目的進(jìn)度很難安排得理杷0

當(dāng)最后期限快到的時(shí)候，壓力逐漸增大，錯(cuò)誤隨之產(chǎn)生

5.自負(fù)心理、代碼文檔質(zhì)量差、軟件開發(fā)工具

56.什么是驗(yàn)證、評(píng)價(jià)、預(yù)排.檢查？

(1驗(yàn)證(Yerification)涉及了回顧和會(huì)議,以評(píng)估文檔、計(jì)劃、

代碼、需求和說明書?？梢酝ㄟ^檢查表、調(diào)查表、排練、和檢查會(huì)來

進(jìn)行。

U評(píng)價(jià)(vedidalinn)則指在檢察完成之后的實(shí)際測試.術(shù)語“11

和“V”分別代表臉證和評(píng)價(jià).

U“預(yù)排”是一個(gè)II：正式的會(huì)議，用來進(jìn)行評(píng)估和信息交流。通

常不需要或許只需很少一點(diǎn)準(zhǔn)備3

U檢M匕預(yù)排更正式一點(diǎn)，通常有3-8個(gè)人參加會(huì)議，包括一個(gè)

仲裁者(moderator)、讀者(可以是作者或者任何評(píng)論者)、一個(gè)記錄

員作記錄。典甥的槍直對(duì)象是一個(gè)文件，例如需求說明或者測試訂劃，

目的在于發(fā)現(xiàn)問題和查找遺漏，而不是去對(duì)任何東西進(jìn)行實(shí)際的修改。

會(huì)議的參加者應(yīng)當(dāng)行準(zhǔn)備，應(yīng)當(dāng)通讀文件，大多數(shù)的問題會(huì)在準(zhǔn)備的

過程中被發(fā)現(xiàn).檢查會(huì)的結(jié)果應(yīng)寫成廿面報(bào)告.對(duì)檢查會(huì)進(jìn)行全面準(zhǔn)

備是困難而艱苫的工作，但它是保證質(zhì)量最有用的方法。在檢杳過程

中，最有經(jīng)臉的雇員的作用就向‘大哥哥’一樣，他們的技能也許不

大顯眼，但對(duì)任何軟件開發(fā)機(jī)構(gòu)是玨ifV要的，這是因?yàn)檩夥厘e(cuò)誤要比

發(fā)現(xiàn)錯(cuò)誤在費(fèi)用方面更加有效。

57.介紹一下整體項(xiàng)目流程。

我們公司的測試流程是闈繞著測試的五個(gè)階段展開的，測試計(jì)

劃、設(shè)計(jì)測試、執(zhí)行測試、評(píng)估測試、驗(yàn)收測試。只是在不同的階段

有自己的一套做法，在接到項(xiàng)II帆后，我們會(huì)召開一個(gè)項(xiàng)目開工會(huì)，

要求各部門的相關(guān)人員都參與，會(huì)議我們主要是了解一下項(xiàng)目的背景、

目的和資料。確定開始時(shí)間和結(jié)束時(shí)間和項(xiàng)目參與人員,測試部和開

發(fā)商量好開發(fā)轉(zhuǎn)系統(tǒng)測試時(shí)間，然后就進(jìn)入計(jì)劃階段.開發(fā)和測試都

仃自己的計(jì)劃，我們測試計(jì)劃由測試經(jīng)理編寫，測試計(jì)劃中主要是制

定可采用的測試策略和范1%怦估項(xiàng)目風(fēng)險(xiǎn)和規(guī)避措施.制定時(shí)間進(jìn)

度表,合理的分配人力、物力資源.之后進(jìn)入設(shè)計(jì)階段，設(shè)計(jì)階段我

們會(huì)參考開發(fā)的需求說明書，詳細(xì)設(shè)計(jì)、概要設(shè)計(jì)去設(shè)計(jì)測試用例。

接到開發(fā)的新版本就進(jìn)入r測試執(zhí)行階段，首先是搭建建1試環(huán)境，對(duì)

軟件實(shí)施偵測試主要是驗(yàn)證系統(tǒng)的正笈功能是否可用，然后就是系統(tǒng)