測試主管試題

1、軟件測試工程師/主管筆試試題01.為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？任何軟件在開發(fā)過程中都會(huì)留下缺陷，帶有缺陷的軟件產(chǎn)品如果提交出去，可能會(huì)給公司帶來不可估量的損失，我們必須在客戶之前發(fā)現(xiàn)盡可能多的問題，從而保障客戶滿意。而發(fā)現(xiàn)問題的這個(gè)過程稱之為測試。請(qǐng)?jiān)囀鲈谶@個(gè)過程中都有哪請(qǐng)?jiān)囀鲆粋€(gè)完整的開發(fā)過程（對(duì)于軟件測試部分，可以簡02.您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解,些工作要做？分別由哪些不同的角色來完成這些工作？03.您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解,需要完成哪些工作？分別由哪些不同的角色來完成這些工作？述）04.您在以往的測試工作中都曾經(jīng)具體從事過哪些

2、工作？其中最擅長哪部分工作？05.您所熟悉的軟件測試類型都有哪些？請(qǐng)?jiān)囍謩e比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試）功能測試就是對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，根據(jù)功能測試用例，逐項(xiàng)測試，檢查產(chǎn)品是否達(dá)到用戶要求的功能性能測試是通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試,確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測試。,基本功能驗(yàn)證。主要是對(duì)發(fā)布的

3、版本進(jìn)行一些最主要功能的測試。英文常見叫法是SmokingTest,BasicVerificationTest或者SanityCheck。功能測試。主要是依據(jù)需求或者需求分析文檔，對(duì)所發(fā)布的版本進(jìn)行測試，看看是否滿足需求，是否出現(xiàn)了不必要的功能。單元測試。是開發(fā)人員進(jìn)行的測試之一，一般是開發(fā)人員對(duì)很小的模塊，比如函數(shù)進(jìn)行測試，一般來說，開發(fā)人員還需要開發(fā)相應(yīng)的測試樁來進(jìn)行此類測試。集成測試。在大型的開發(fā)過程中，軟件是模塊化進(jìn)行開發(fā)的，將不同的模塊揉合在一起的話，需要進(jìn)行的測試就是集成測試。系統(tǒng)測試。當(dāng)軟件提交給測試組后，是對(duì)整個(gè)系統(tǒng)的所有功能進(jìn)行測試，一般來說，功能測試是系統(tǒng)測試的一個(gè)部分。壓

4、力測試。主要是在很大性能的情況下，這個(gè)性能已經(jīng)接近了系統(tǒng)的極限，看看系統(tǒng)運(yùn)轉(zhuǎn)的情況。負(fù)載測試。主要是用各種不同的性能去檢測系統(tǒng)，采集各個(gè)數(shù)據(jù)在這些性能情況下的數(shù)據(jù)。黑盒測試。指系統(tǒng)對(duì)你來說是完全不透明的，只給你留下了輸入和最終輸出，這個(gè)是功能測試的方法之一?；液袦y試。指在了解部分系統(tǒng)內(nèi)部工作機(jī)制的情況下，對(duì)于系統(tǒng)進(jìn)行的覆蓋性測試。白盒測試。主要是在單元測試和集成測試的情況下，開發(fā)人員已知代碼，對(duì)這一段的代碼進(jìn)行全路徑的覆蓋測試。界面測試。主要是看用戶界面的友好性和易用性，是否有文字或者排版錯(cuò)誤，是否有輸入限制等等?；貧w測試。一般是系統(tǒng)發(fā)現(xiàn)BUG開發(fā)人員彳改后，和BUCS：接相關(guān)以及可能相關(guān)的功

5、能進(jìn)行的測試。安裝和卸載的測試?；謴?fù)測試。主要是一個(gè)系統(tǒng)在發(fā)生了災(zāi)難的情況下，從錯(cuò)誤中是否容易恢復(fù)。兼容性測試。一個(gè)系統(tǒng)在不同的語言，操作系統(tǒng)下的系統(tǒng)測試。安全測試。系統(tǒng)在遇到攻擊或者類似情況下的表現(xiàn)。Alpha測試。系統(tǒng)在給最終用戶前，測試人員在實(shí)驗(yàn)室中模擬最終用戶的測試。Beta測試。由部分最終用戶通過使用來進(jìn)行的測試。比較測試。和其他具有相同或者類似功能的系統(tǒng)進(jìn)行對(duì)比的測試。驗(yàn)收測試。一般是最終用戶在接受產(chǎn)品前，依據(jù)自己所提出的要求進(jìn)行的測試，很多情況下，驗(yàn)收測試可能委托第三方機(jī)構(gòu)完成。06.請(qǐng)?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。黑盒測試、

6、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別黑盒測試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對(duì)象看做一個(gè)黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動(dòng)測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤：1、是否有不正確或遺漏的功能？2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果

7、？3、是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息（例如數(shù)據(jù)文件）訪問錯(cuò)誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯(cuò)誤？軟件的白盒測試是對(duì)軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對(duì)象看做一個(gè)打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測試用例，對(duì)程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試。白盒測試主要是想對(duì)程序模塊進(jìn)行如下檢查：1、對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。2、對(duì)所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。3、在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。

8、4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測試是用于判斷某個(gè)特定條件（或者場景）下某個(gè)特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時(shí)也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個(gè)已經(jīng)測試過的單元組合成一個(gè)組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，

9、許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個(gè)完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對(duì)最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。驗(yàn)收測試是部署軟件之前的最后一個(gè)測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗(yàn)收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計(jì)把所

10、有的模塊組裝成一個(gè)完整的軟件系統(tǒng)，接口錯(cuò)誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性，這就是驗(yàn)收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。.單元測試的主要目的是針對(duì)編碼過程中可能存在的各種錯(cuò)誤，例如用戶輸入驗(yàn)證過程中的邊界值的錯(cuò)誤。.集成測試主要目的是針對(duì)詳細(xì)設(shè)計(jì)中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯(cuò)誤。.系統(tǒng)測試主要針對(duì)b概要設(shè)計(jì)/b,檢查了系統(tǒng)作為一個(gè)整體是否有效地得到運(yùn)行，例如在產(chǎn)品設(shè)置中是否達(dá)到了預(yù)期的高性能4.驗(yàn)收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要（需求）。07.測試計(jì)劃工作的目的是什么？測試計(jì)劃

11、工作的內(nèi)容都包括什么？其中哪些是最重要的？軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對(duì)測試過程中的各種變更。測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動(dòng)的范圍、方單元測試完成之后，接下來的工作就是集成測試.軟件集成測試主要依據(jù)軟件結(jié)構(gòu)設(shè)計(jì)（概要設(shè)計(jì)）文檔，測試主要內(nèi)容有功能性、可靠性、易用性、效率、維護(hù)性和可移植性中相

12、關(guān)的部分，根據(jù)軟件需求和設(shè)計(jì)的要求而選定。驗(yàn)證各軟件單元集成后形成的模塊能否達(dá)到概要設(shè)計(jì)規(guī)格說明中各模塊的設(shè)計(jì)目標(biāo)；這里，模塊可能是指某個(gè)軟件部件，也可能是指某個(gè)或某幾個(gè)子系統(tǒng)。通常在做集成測試時(shí)先是從子系統(tǒng)內(nèi)部的集成測試開始做起，做完以后再測試各子系統(tǒng)是否能集成為最終要實(shí)現(xiàn)的整體系統(tǒng)。也有其他做法（如自頂向下集成測試方法、核心系統(tǒng)先做集成測試或每日集成測試等等）。總之，萬變不離其宗,集成測試要保證模塊的內(nèi)部正確性以及保證模塊能最終集成為完整的系統(tǒng)。集成測試有時(shí)也被稱為組裝測試或灰盒測試（有觀點(diǎn)認(rèn)為集成測試介于白盒與黑盒之間）。軟件集成測試具體內(nèi)容包括：功能性測試（1）程序的功能測試。檢查各個(gè)

13、子功能組合起來能否滿足設(shè)計(jì)所要求的功能。（2）一個(gè)程序單元或模塊的功能是否會(huì)對(duì)另一個(gè)程序單元或模塊的功能產(chǎn)生不利影響。（3）根據(jù)計(jì)算精度的要求，單個(gè)程序模塊的誤差積累起來，是否仍能夠達(dá)到要求的技術(shù)指標(biāo)。（4）程序單元或模塊之間的接口測試。把各個(gè)程序單元或模塊連接起來時(shí)，數(shù)據(jù)在通過其接口時(shí)是否會(huì)出現(xiàn)不一致情況,是否會(huì)出現(xiàn)數(shù)據(jù)丟失。（5）全局?jǐn)?shù)據(jù)結(jié)構(gòu)的測試。檢查各個(gè)程序單元或模塊所用到的全局變量是否一致、合理。（6）對(duì)程序中可能有的特殊安全性要求進(jìn)行測試。可靠性測試根據(jù)軟件需求和設(shè)計(jì)中提出的要求，對(duì)軟件的容錯(cuò)性、易恢復(fù)性、錯(cuò)誤處理能力進(jìn)行測試。易用性測試根據(jù)軟件設(shè)計(jì)中提出的要求，對(duì)軟件的易理解性、

14、易學(xué)性和易操作性進(jìn)行檢查和測試。性能測試根據(jù)軟件需求和設(shè)計(jì)中提出的要求，進(jìn)行軟件的時(shí)間特性、資源特性測試。維護(hù)性測試根據(jù)軟件需求和設(shè)計(jì)中提出的要求，對(duì)軟件的易修改性進(jìn)行測試?？梢浦残詼y試根據(jù)軟件需求和設(shè)計(jì)中提出的要求，對(duì)軟件在不同操作系統(tǒng)環(huán)境下被使用的正確性進(jìn)行測試以其中最重要的是測試測試策略和測試方法（最好是能先評(píng)審）。08.您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性編寫軟件測試計(jì)劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計(jì)劃的價(jià)值取決于它對(duì)幫助管理測試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測試計(jì)劃中的測試范圍必須高度覆蓋功能需求，測試方法

15、必須切實(shí)可行，測試工具并且具有較高的實(shí)用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確堅(jiān)持“5W規(guī)則，明確內(nèi)容與過程“5W規(guī)則指的是“What（做什么）、“Why（為什么做）、“When（何時(shí)做）”、“Where（在哪里）、“How（如何做）”。利用“5W規(guī)則創(chuàng)建軟件測試計(jì)劃，可以幫助測試團(tuán)隊(duì)理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。采用評(píng)審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求測試計(jì)劃寫作完成后，如果沒有經(jīng)過評(píng)審，直接發(fā)送給測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容

16、，或者軟件需求變更引起測試范圍的增減，而測試計(jì)劃的內(nèi)容沒有及時(shí)更新，誤導(dǎo)測試執(zhí)行人員。分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨(dú)立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動(dòng)的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)09.您所熟悉的測試用例設(shè)計(jì)方法都有哪些？請(qǐng)分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。.等價(jià)類劃分劃分等價(jià)類:等價(jià)類是指某個(gè)輸入域的子集合.在該子集合中

17、,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測試某等價(jià)類的代表值就等于對(duì)這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù)取得較好的測試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類.邊界值分析法邊界值分析方法是對(duì)等價(jià)類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對(duì)各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯(cuò)誤.使用邊界值分析方法設(shè)計(jì)測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界,就是應(yīng)著重測試的邊

18、界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù).錯(cuò)誤推測法基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤,從而有針對(duì)性的設(shè)計(jì)測試用例的方法.錯(cuò)誤推測方法的基本思想:列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況,根據(jù)他們選擇測試用例.例如,在單元測試時(shí)曾列出的許多在模塊中常見的錯(cuò)誤.以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等，這些就是經(jīng)驗(yàn)的總結(jié).還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況.輸入表格為空格或輸入表格只有一行.這些都是容易發(fā)生錯(cuò)誤的情況.可選擇這些情況下的例子作為測試用例.因果圖方法前面介紹的等價(jià)類劃分方法和邊界值分析方法，都是著

19、重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系，相互組合等.考慮輸入條件之間的相互組合，可能會(huì)產(chǎn)生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價(jià)類，他們之間的組合情況也相當(dāng)多.因此必須考慮采用一種適合于描述對(duì)于多種條件的組合，相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來考慮設(shè)計(jì)測試用例這就需要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表.它適合于檢查程序輸入條件的各種組合情況.正交表分析法有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測試用例數(shù)量上的激增，同時(shí)，這些測試用例并沒有明顯的優(yōu)先級(jí)上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而

20、達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。.場景分析方法指根據(jù)用戶場景來模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。.您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？關(guān)鍵是對(duì)系統(tǒng)的熟悉程度，需求的理解，設(shè)計(jì)文檔的了解情況，對(duì)要測試對(duì)象的深度了解，業(yè)務(wù)的了解，還有經(jīng)驗(yàn)的積累白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題.請(qǐng)以您以往的實(shí)際工作為例，詳細(xì)的描述一次測試用例設(shè)計(jì)的完整的過程。軟件測試用例的基本要素包括測試用例編號(hào)、測試標(biāo)題、

21、重要級(jí)別、測試輸入、操作步驟、預(yù)期結(jié)果，下面逐一介紹。用例編號(hào)測試用例的編號(hào)有一定的規(guī)則，比如系統(tǒng)測試用例的編號(hào)這樣定義規(guī)則：PROJECT1-ST-001,命名規(guī)則是項(xiàng)目名稱+測試階段類型（系統(tǒng)測試階段）+編號(hào)。定義測試用例編號(hào)，便于查找測試用例，便于測試用例的跟蹤。測試標(biāo)題對(duì)測試用例的描述，測試用例標(biāo)題應(yīng)該清楚表達(dá)測試用例的用途。比如“測試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況”。重要級(jí)別定義測試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為“高”和“低”兩個(gè)級(jí)別。一般來說，如果軟件需求的優(yōu)先級(jí)為“高”，那么針對(duì)該需求的測試用例優(yōu)先級(jí)也為“高”；反之亦然.您以往的工作中是否曾開展過測試用例的評(píng)審工作？如

22、果有，請(qǐng)描述測試用例評(píng)審的過程和評(píng)審的內(nèi)容。1:評(píng)審的過程A：開始前做好如下準(zhǔn)備1、確定需要評(píng)審的原因2、確定進(jìn)行評(píng)審的時(shí)機(jī)3、確定參與評(píng)審人員4、明確評(píng)審的內(nèi)容5、確定評(píng)審結(jié)束標(biāo)準(zhǔn)6、提前至少一天將需要評(píng)審的內(nèi)容以郵件的形式發(fā)送給評(píng)審會(huì)議相關(guān)人員。并注明詳審時(shí)間、地點(diǎn)及償參與人員等。7、在郵件中提醒評(píng)審會(huì)議相關(guān)人員至少簡讀一遍評(píng)審內(nèi)容，并記錄相關(guān)的疑問，以便在評(píng)審會(huì)議上提出。8、會(huì)議主持者（一般為用例編寫人員）應(yīng)在會(huì)議前整理相關(guān)疑問，以便在會(huì)議上提出。B:開始評(píng)審1、召開評(píng)審會(huì)議。與會(huì)者在設(shè)計(jì)人員講解之后給出意見和建議，同時(shí)進(jìn)行詳細(xì)的評(píng)審記錄。2、通用郵件與相關(guān)人員溝通3、通用IM工具直接與

23、相關(guān)人員交流4、根據(jù)評(píng)審內(nèi)容進(jìn)行評(píng)審2:評(píng)審內(nèi)容1、用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理，是否利于高效對(duì)需求進(jìn)行覆蓋。2、優(yōu)先極安排是否合理。3、是否覆蓋測試需求上的所有功能點(diǎn)。4、用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確；期待結(jié)果是否有明顯的驗(yàn)證方法。5、是否已經(jīng)刪除了冗余的用例。6、是否包含充分的負(fù)面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個(gè)健壯的軟件，其中80%的代碼都是在保護(hù)”20%勺功能實(shí)現(xiàn)。7、是否從用戶層面來設(shè)計(jì)用戶使用場景和使用流程的測試用例。8、是否簡潔，復(fù)用性強(qiáng)。例如，可將重復(fù)度高的步驟或

24、過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。3:參與評(píng)審人員（這里會(huì)分為多個(gè)級(jí)別進(jìn)行評(píng)審）1、部門評(píng)審，測試部門全體成員參與的評(píng)審。2、公司評(píng)審，這里包括了項(xiàng)目經(jīng)理、需求分析人員、架構(gòu)設(shè)計(jì)人員、開發(fā)人員和測試人員。3、客戶評(píng)審，包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見.您以往是否曾經(jīng)從事過性能測試工作？如果有，請(qǐng)盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。.您在從事性能測試工作時(shí)，是否使用過一些測試工具？如果有，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟?，并以一個(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。.您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？一般來講，性能測

25、試目的覆蓋.發(fā)現(xiàn)系統(tǒng)性能瓶頸.容量規(guī)劃.benchmark評(píng)估.系統(tǒng)選型基準(zhǔn).系統(tǒng)調(diào)優(yōu)關(guān)鍵：.規(guī)劃和策略.關(guān)鍵性性能指標(biāo)定義.環(huán)境模擬.回歸測試中的調(diào)優(yōu).在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？.您以往所從事的軟件測試工作中，是否使用了一些工具來進(jìn)行軟件缺陷（Bug）的管理?如果有，請(qǐng)結(jié)合該工具描述軟件缺陷（Bug）跟蹤管理的流程。.您以往是否曾經(jīng)從事過單元測試和集成測試？如果有，請(qǐng)談一下這些工作的實(shí)際開展情況。.您如何看待軟件過程改進(jìn)？在您曾經(jīng)工作過的企業(yè)中，是否有一些需要改進(jìn)的東西呢？您期望的理想的測試人員的工作環(huán)境是怎樣

26、的？改進(jìn)用戶需求過程進(jìn)用戶需求的獲取方式1）研究用戶特點(diǎn)2）成立需求調(diào)查小組進(jìn)獲取用戶需求的態(tài)度1）正式的外部文檔方式2）正式的提交過程進(jìn)用戶需求內(nèi)容準(zhǔn)備工作1）專業(yè)的用戶需求調(diào)查表單，力求取得用戶的配合，由用戶或需求調(diào)？1）用戶需求的分析、總結(jié)，須及時(shí)反饋到用戶方，以取得及時(shí)而有效、滿意但不多余的需求2改進(jìn)需求分析方式1）改進(jìn)需求分析的前提條件一一正確的獲取用戶的需求2）針對(duì)不同堯也系統(tǒng)采用不同的需求方式和模型，更有助于界定需求的范疇3）及時(shí)總結(jié)、改進(jìn)需求分析方式和模型，形成需求分析模式庫4）復(fù)用和改進(jìn)需求分析模式庫5）加載有效的、適用的、先進(jìn)的需求分析理論于經(jīng)驗(yàn)分析基礎(chǔ)之上6）改進(jìn)項(xiàng)目組內(nèi)

27、需求分析的溝通和流通7）在需求分析初始，盡早分析需求的可行性，并作備案8）對(duì)不適當(dāng)需求，與用戶溝通，以取得理解和信任9）對(duì)不合理需求，協(xié)調(diào)用戶，以降低成本10）需求一旦獲得認(rèn)定，盡快進(jìn)行系統(tǒng)分析和設(shè)計(jì)11）及時(shí)有效的控制需求的變化，防止對(duì)需求隨意的更改和增刪3改進(jìn)系統(tǒng)分析和設(shè)計(jì)原則1）以最小的代價(jià)實(shí)現(xiàn)系統(tǒng)2）以開發(fā)人員最熟悉的方法、技術(shù)和工具實(shí)現(xiàn)系統(tǒng)3）盡量采用先進(jìn)的方法和理論，以適應(yīng)發(fā)展的需求4）在系統(tǒng)的相關(guān)處，與具體的實(shí)施人員進(jìn)行及時(shí)有效的溝通，尋求實(shí)現(xiàn)的最佳途徑5）以簡單、易懂的方式進(jìn)行分析和設(shè)計(jì)6）以簡單、易懂的方式表現(xiàn)系統(tǒng)7）系統(tǒng)分析的方式要易于復(fù)用，并及時(shí)進(jìn)行調(diào)整、改進(jìn)，系統(tǒng)系統(tǒng)分

28、析庫8）對(duì)系統(tǒng)的分析、設(shè)計(jì)加以控制、遵守，防止系統(tǒng)結(jié)構(gòu)的隨意更改4改進(jìn)系統(tǒng)的實(shí)施和驗(yàn)證1）確保在取得共同的理解后才進(jìn)行系統(tǒng)的實(shí)施和驗(yàn)證2）系統(tǒng)的實(shí)施和驗(yàn)證遵循一定的流程，以約定的方式進(jìn)行溝通3）系統(tǒng)的變化能夠以多種不同方式進(jìn)行溝通，以確保變化被告知、并被認(rèn)可4）確保在系統(tǒng)的實(shí)施和驗(yàn)證過程中，所采用的方式和方法是易于理解的，且不易發(fā)生變化5）系統(tǒng)的實(shí)施和驗(yàn)證完成標(biāo)識(shí)明顯，易于被相關(guān)人員識(shí)別5改進(jìn)用戶驗(yàn)收被動(dòng)局面1）理解和支持用戶的行為2）取得用戶的理解和支持3）對(duì)系統(tǒng)進(jìn)行充分的驗(yàn)證4）提高系統(tǒng)安裝的成功率和速度5）改進(jìn)系統(tǒng)界面，使系統(tǒng)直觀、有效6）保證進(jìn)度，提高誠信度6改進(jìn)系統(tǒng)維護(hù)過程1）對(duì)用戶

29、進(jìn)行有效的培訓(xùn)2）快捷、有效、合理的處理用戶的問題3）跟蹤問題，形成問題庫.您以往工作過的企業(yè)中，是否開展了軟件配置管理工作？您能否描述一下這項(xiàng)工作的開展情況和您對(duì)這項(xiàng)工作的認(rèn)識(shí)？軟件配置管理（SoftwareConfigurationManagement,SCM）是一種標(biāo)識(shí)、組織和控制修改的技術(shù)。軟件配置管理應(yīng)用于整個(gè)軟件工程過程。我們知道，在軟件建立時(shí)變更是不可避免的，而變更加劇了項(xiàng)目中軟件開發(fā)者之間的混亂。SCM活動(dòng)的目標(biāo)就是為了標(biāo)識(shí)變更、控制變更、確保變更正確實(shí)現(xiàn)并向其他有關(guān)人員報(bào)告變更。從某種角度講，SCM是一種標(biāo)識(shí)、組織和控制修改的技術(shù)，目的是使錯(cuò)誤降為最小并最有效地提高生產(chǎn)效率軟

30、件配置管理，貫穿于整個(gè)軟件生命周期，它為軟件研發(fā)提供了一套管理辦法和活動(dòng)原則。軟件配置管理無論是對(duì)于軟件企業(yè)管理人員還是研發(fā)人員都著重要的意義。軟件配置管理可以提煉為三個(gè)方面的內(nèi)容VersionControl-版本控制版本控制是全面實(shí)行軟件配置管理的基礎(chǔ)，可以保證軟件技術(shù)狀態(tài)的一致性。我們?cè)谄綍r(shí)的日常工作中都在或多或少地進(jìn)行版本管理的工作。比如有時(shí)我們?yōu)榱朔乐刮募G失，而拷貝一個(gè)后綴為bak或日期的備份文件。當(dāng)文件丟失或被修改后可以通過該備份文件恢復(fù)。版本控制是對(duì)系統(tǒng)不同版本進(jìn)行標(biāo)識(shí)和跟蹤的過程。版本標(biāo)識(shí)的目的是便于對(duì)版本加以區(qū)分、檢索和跟蹤，以表明各個(gè)版本之間的關(guān)系。一個(gè)版本是軟件系統(tǒng)的一個(gè)

31、實(shí)例，在功能上和性能上與其他版本有所不同，或是修正、補(bǔ)充了前一版本的某些不足。實(shí)際上，對(duì)版本的控制就是對(duì)版本的各種操作控制，包括檢入檢出控制、版本的分支和合并、版本的歷史記錄和版本的發(fā)行。ChangeControl-變更控制進(jìn)行變更控制是至關(guān)重要的。但是要實(shí)行變更控制也是一件令人頭疼的事情。我們擔(dān)憂變更的發(fā)生是因?yàn)閷?duì)代碼的一點(diǎn)小小的干擾都有可能導(dǎo)致一個(gè)巨大的錯(cuò)誤，但是它也許能夠修補(bǔ)一個(gè)巨大的漏洞或者增加一些很有用的功能。我們擔(dān)憂變更也因?yàn)橛行┝髅コ绦騿T可能會(huì)破壞整個(gè)項(xiàng)目，雖然智慧思想有不少來自于這些流氓程序員的頭腦。過于嚴(yán)格的控制也有可能挫傷他們進(jìn)行創(chuàng)造性工作的積極性。但是，如果你不控制他，他

32、就控制了你！ProcessSupport-過程支持一般來說，人們已漸漸意識(shí)到了軟件工程過程概念的重要性,而且人們也逐漸了解了這些概念和軟件工程支持技術(shù)的結(jié)合，尤其是軟件過程概念與CM有著密切的聯(lián)系，因?yàn)镃M理所當(dāng)然地可以作為一個(gè)管理變更的規(guī)則（或過程）。如IEEE軟件配置管理計(jì)劃的標(biāo)準(zhǔn)就列舉了建立一個(gè)有效的CM規(guī)則所必需的許多關(guān)鍵過程概念。但是，傳統(tǒng)意義上的軟件配置管理主要著重于軟件的版本管理，缺乏軟件過程支持的概念。在大多數(shù)有關(guān)軟件配置管理的定義中，也并沒有明確提出配置管理需要對(duì)過程進(jìn)行支持的概念。因此，不管軟件的版本管理得多好，組織之間沒有連接關(guān)系，組織所擁有的是相互獨(dú)立的信息資源，從而形

33、成了信息的孤島。在CM提供了過程支持后，CM與CASE環(huán)境進(jìn)行了集成，組織之間通過過程驅(qū)動(dòng)建立一種單向或雙向的連接。對(duì)于開發(fā)員或測試員則不必去熟悉整個(gè)過程，也不必知道整個(gè)團(tuán)隊(duì)的開發(fā)模式。他只需集中精力關(guān)心自己所需要進(jìn)行的工作。在這種情況下，可以延續(xù)其一貫的工作程序和處理辦法。.您是否熟悉一些主流的軟件工程方法論和思想，如RUP、CMM、CMMI、XP、PSPTSR如果熟悉，您是否可以談一下對(duì)這些方法論和思想的認(rèn)識(shí)？RUP（RationalUnifiedProcess,統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程）是一個(gè)面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。極限編程（ExtremeProgramming,XP）

34、是一門針對(duì)業(yè)務(wù)和軟件開發(fā)的規(guī)則，它的作用在于將兩者的力量集中在共同的、可以達(dá)到的目標(biāo)上。它是以符合客戶需要的軟件為目標(biāo)而產(chǎn)生的一種方法論，XP使開發(fā)者能夠更有效XP的響應(yīng)客戶的需求變化，哪怕是在軟件生命周期的后期。它強(qiáng)調(diào)，軟件開發(fā)是人與人合作進(jìn)行的過程，因此成功的軟件開發(fā)過程應(yīng)該充分利用人的優(yōu)勢，而弱化人的缺點(diǎn)，突出了人在軟件開發(fā)過程中的作用。極端編程屬于輕量級(jí)的方法，認(rèn)為文檔、架構(gòu)不如直接編程來的直接XP的核心思想從長遠(yuǎn)看，早期發(fā)現(xiàn)錯(cuò)誤以及降低復(fù)雜度可以節(jié)約成本。極限編程強(qiáng)調(diào)我們將任務(wù)/系統(tǒng)細(xì)分為可以在較短周期解決的一個(gè)個(gè)子任務(wù)/模塊，并且強(qiáng)調(diào)測試、代碼質(zhì)量和及早發(fā)現(xiàn)問題。通常，通過一個(gè)個(gè)短

35、小的迭代周期，我們就可以獲得一個(gè)個(gè)階段性的進(jìn)展，并且可以及時(shí)形成一個(gè)版本供用戶參考，以便及時(shí)對(duì)用戶可能的需求變更作出響應(yīng)極限編程中有四個(gè)核心價(jià)值是我們?cè)陂_發(fā)中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和勇氣（Courage）。.您認(rèn)為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發(fā)團(tuán)隊(duì)中其他成員良好的人際關(guān)系的關(guān)鍵是什么？一，有共同的目標(biāo)，共同的利益。二，默契。三，大度，謙讓，素質(zhì)。.選擇正確的溝通途徑選擇正確的溝通途徑對(duì)于確保完成溝通目標(biāo)起到非常重要的作用。在軟件項(xiàng)目管理中，存在各種各樣的溝通

36、。可能因?yàn)闇贤ǖ膶?duì)象不同，也可能因?yàn)闇贤ǖ膬?nèi)容不同，我們可能需要選擇不同溝通途經(jīng)。最有效的是facetoface的溝通，特別是在需求評(píng)審階段。有些比較復(fù)雜的用文字容易出現(xiàn)歧義的問題，面對(duì)面以及電話溝通往往是最直接最有效最清晰的。.使表述的內(nèi)容易于理解溝通的困難往往在于無法把想要講述的內(nèi)容以一種對(duì)方容易理解的方式呈現(xiàn)給對(duì)方。作為測試人員，bug的描述一定要清晰，主題要簡明扼要，場景步驟要描述清楚比如測試帳號(hào)，數(shù)據(jù)，以及重現(xiàn)的步驟。因?yàn)?，有些比較淺的bug開發(fā)可能通過看主題就已經(jīng)可以定位了，不需要在看繁瑣的步驟。那場景步驟描述的是否清晰直接影響到測試人員和開發(fā)之間的溝通成本。.溝通技巧先禮后兵”，

37、測試和開發(fā)的溝通在整個(gè)項(xiàng)目過程中都是很重要的一個(gè)環(huán)節(jié)。作為測試人員一定要在明確自己的立場（保障項(xiàng)目質(zhì)量和用戶需求）的同時(shí)，注意和開發(fā)同學(xué)溝通的方式方法。先禮后兵”和重要，有問題先要很好的溝通，必要的時(shí)候可以從他們的立場出發(fā)去尋求突破，不要輕易破壞和開發(fā)之間的友好關(guān)系，但是在問題得不到解決，或者會(huì)直接影響到項(xiàng)目的進(jìn)度及質(zhì)量的時(shí)候，也要果斷的向上一級(jí)尋求幫助，讓更有發(fā)言權(quán)的人來作出溝通23.在您以往的測試工作中, 待這些事情的？和確定。最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對(duì)24.在即將完成這次筆試前，您是否愿意談一些自己在以往的學(xué)習(xí)和工作中獲得的工作經(jīng)驗(yàn)和心得體會(huì)？（可以包括軟件測

38、試、過程改進(jìn)、軟件開發(fā)或者與此無關(guān)的其他方面）判斷題（每題1分，12分，正確的M錯(cuò)誤的X）.軟件測試的目的是盡可能多的找出軟件的缺陷。（）V.Beta測試是驗(yàn)收測試的一種。（）.驗(yàn)收測試是由最終用戶來實(shí)施的。（）.項(xiàng)目立項(xiàng)前測試人員不需要提交任何工件。（）5單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（）6代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（）7自底向上集成需要測試員編寫驅(qū)動(dòng)程序。（）8負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（）9測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（）10代碼評(píng)審員一般由測試員擔(dān)任。（）11我們可以人為的使得軟件不存在配置問題。（）12集成測試計(jì)劃在需

39、求分析階段末提交。（）二、不定項(xiàng)選擇題（每題2分，10分）1軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（）A軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。B所有測試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤。C立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。D驗(yàn)收測試工件齊全。2軟件測試計(jì)劃評(píng)審會(huì)需要哪些人員參加？（）A項(xiàng)目經(jīng)理BSQA負(fù)責(zé)人C.配置負(fù)責(zé)人D測試組3下列關(guān)于alpha測試的描述中正確的是：（）A.alpha測試需要用戶代表參加Balpha測試不需要用戶代表參加Calpha測試是系統(tǒng)測試的一種D.alpha測試是驗(yàn)收測試的一種4測試設(shè)計(jì)員的職責(zé)有：（）A制定測試計(jì)劃B設(shè)計(jì)測試用例

40、C.設(shè)計(jì)測試過程、腳本D評(píng)估測試活動(dòng)5軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是：（）A需求工件已經(jīng)被基線化B詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化C.構(gòu)架工件已經(jīng)被基線化D項(xiàng)目階段成果已經(jīng)被基線化三、填空題（每空1分，24分）1軟件驗(yàn)收測試包括、三種類型。2系統(tǒng)測試的策略有功能測試、易用性測試、等15種方法。3設(shè)計(jì)系統(tǒng)測試計(jì)劃需要參考的項(xiàng)目文檔有、和迭代計(jì)劃。4對(duì)面向過程的系統(tǒng)采用的集成策略有、兩種。5通過畫因果圖來寫測試用例的步驟為、及把因果圖轉(zhuǎn)換為狀態(tài)圖共五個(gè)步驟。 TOC o 1-5 h z 四、簡答題（共37分）階段評(píng)審與同行評(píng)審的區(qū)別。（4分）什么是軟件測試。（3分）簡述集成測試的過程。（5分）怎樣做好文檔測試？

41、（4分）白盒測試有那幾種方法？（6分）系統(tǒng)測試計(jì)劃是否需要同行評(píng)審，為什么？（4分）Alpha測試與beta測試的區(qū)別。（4分）比較負(fù)載測試、容量測試和強(qiáng)度測試的區(qū)別。（6分）測試結(jié)束的標(biāo)準(zhǔn)是什么？（3分）五、設(shè)計(jì)題（共15分）對(duì)下面給出的程序控制圖，分別以各種不同的測試方法寫出最少的測試用例。測試人員_考試試卷（考試時(shí)間100分鐘，滿分100分）姓名：部門：員工號(hào)：一、填空題：（每一空格2分，共60分）軟件實(shí)施活動(dòng)的輸出工件有、。代碼評(píng)審主要做工作。軟件實(shí)施活動(dòng)中集成員的職責(zé)是。驗(yàn)證與確認(rèn)軟件實(shí)施活動(dòng)主要有、代碼評(píng)審、SQA驗(yàn)證。表明測試已經(jīng)結(jié)束。軟件測試的目的是。軟件測試主要分為、四類測試

42、。軟件測試活動(dòng)有制定測試計(jì)劃、測試評(píng)估、測試結(jié)束八個(gè)步驟。軟件測試活動(dòng)的輸出工件有_、。10、軟件測試角色有、。二、不定項(xiàng)選擇題：（每題3分，共15分）1、軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是（）A、需求工件已經(jīng)被基線化B、詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化C、構(gòu)架工件已經(jīng)被基線化D、項(xiàng)目階段成果已經(jīng)被基線化2、下面角色不屬于集成計(jì)劃評(píng)審的是（）A、配置經(jīng)理B、項(xiàng)目經(jīng)理C、測試員D、編碼員3、軟件測試設(shè)計(jì)活動(dòng)主要有（）A、工作量分析B、確定并說明測試用例C、確立并結(jié)構(gòu)化測試過程D、復(fù)審并評(píng)估測試覆蓋4、不屬于集成測試步驟的是（）A、制定集成計(jì)劃B、執(zhí)行集成測試C、記錄集成測試結(jié)果D、回歸測試5、屬于軟件測試活動(dòng)的輸

43、入工件的是（）A、軟件工作版本B、可測試性報(bào)告C、軟件需求工件D、軟件項(xiàng)目計(jì)劃三、問答題：（共25分）、項(xiàng)目的集中管理在軟件公司的哪一個(gè)層面？（2分）請(qǐng)描述軟件測試活動(dòng)的生命周期。（8分）什么是測試評(píng)估，測試評(píng)估的范圍是什么？（5分）闡述工作版本的定義。（2分）、請(qǐng)畫出軟件測試活動(dòng)的流程圖。（8分）測試人員考試試卷（考試時(shí)間90分鐘，滿分100分）姓名：部門：員工號(hào)：一、判斷題（每題2分,正確的J錯(cuò)誤的XJ TOC o 1-5 h z 、好的測試員不懈追求完美。（）測試程序僅僅按預(yù)期方式運(yùn)行就行了。（）不存在質(zhì)量很高但可靠性很差的產(chǎn)品。（）軟件測試員可以對(duì)產(chǎn)品說明書進(jìn)行白盒測試。（）靜態(tài)白盒測

44、試可以找出遺漏之處和問題。（）總是首先設(shè)計(jì)白盒測試用例。（）可以發(fā)布具有配置缺陷的軟件產(chǎn)品。（）所有軟件必須進(jìn)行某種程度的兼容性測試。（）所有軟件都有一個(gè)用戶界面，因此必須測試易用性。（）、測試組負(fù)責(zé)軟件質(zhì)量。（）二、簡答題、軟件的缺陷等級(jí)應(yīng)如何劃分？（3分）如果能夠執(zhí)行完美的黑盒測試，還需要進(jìn)行白盒測試嗎？為什么？（5分）你認(rèn)為一個(gè)優(yōu)秀的測試工程師應(yīng)該具備哪些素質(zhì)？（3分）產(chǎn)品測試到什么時(shí)候就算是足夠了？（2分）測試計(jì)劃的目的是什么？（2分）為什么要進(jìn)行軟件測試?軟件測試的目的是什么?（5分）、軟件測試應(yīng)該劃分幾個(gè)階段?簡述各個(gè)階段應(yīng)重點(diǎn)測試的點(diǎn)?各個(gè)階段的含義？（5分）如何做一名合格的測試

45、人員？（3分）針對(duì)缺陷采取怎樣的管理措施？（5分）專業(yè)詞語解釋（每題2分）a測試：3測試：驅(qū)動(dòng)模塊:樁模塊:白盒測試：靜態(tài)測試：選擇題（每題2分）.下面哪些屬于動(dòng)態(tài)分析（）A代碼覆蓋率B模塊功能檢查C系統(tǒng)壓力測試D程序數(shù)據(jù)流分析.下面哪些屬于靜態(tài)分析（）A、代碼規(guī)則檢查B、序結(jié)構(gòu)分析C、序復(fù)雜度分析D、內(nèi)存泄漏設(shè)計(jì)題（10分）A、B和Co當(dāng)三邊不可能構(gòu)成三角形時(shí)“等腰三角形 ”， 若是等邊三角形，則提示 “等, 對(duì)此設(shè)計(jì)一個(gè)測試用例。10 分）在三角形計(jì)算中，要求三角型的三個(gè)邊長：提示錯(cuò)誤，可構(gòu)成三角形時(shí)計(jì)算三角形周長。若是等腰三角形打印邊三角形?！碑嫵龀绦蛄鞒虉D、控制流程圖、找出基本測試路徑

46、論述題、試敘述對(duì)一個(gè)軟件項(xiàng)目測試的全過程。（、簡述你對(duì)測試工作的認(rèn)識(shí)過程、在以后的工作的一些建議。（6分）、述靜態(tài)測試和動(dòng)態(tài)測試的區(qū)別？（5分）測試人員_考試試卷（考試時(shí)間100分鐘，每題10分，滿分100分）姓名：部門：員工號(hào)：什么是軟件測試，以及軟件測試的意義？什么是軟件測試靜態(tài)分析，軟件測試動(dòng)態(tài)分析，下面那些屬于靜態(tài)分析（）A、編碼規(guī)則檢查B、程序結(jié)構(gòu)分析C、程序復(fù)雜度分析D、內(nèi)存泄漏下面那些屬于動(dòng)態(tài)分析（）A、代碼覆蓋率B、模塊功能檢查C、系統(tǒng)壓力測試D、程序數(shù)據(jù)流分析從測試技術(shù)角度，正確的選擇是（），給出各自的含義？A、靜態(tài)測試B、黑盒測試C、動(dòng)態(tài)測試D、白盒測試從測試階段角度，測試

47、正確的順序是（），同時(shí)給出所選擇的正確策略含義和被測對(duì)象是什么？A、單元測試B、集成測試C、系統(tǒng)測試D、確認(rèn)測試針對(duì)缺陷采取怎樣的管理措施？在測試生命周期，測試過程分為幾個(gè)階段，以及各個(gè)階段的含義？簡要寫出自己在理解的基礎(chǔ)質(zhì)上所認(rèn)為引入測試管理的意義在三角形計(jì)算中，要求三角型的三個(gè)邊長：A、B和Co當(dāng)三邊不可能構(gòu)成三角形時(shí)提示錯(cuò)誤，可構(gòu)成三角形時(shí)計(jì)算三角形周長。若是等腰三角形打印“等腰三角形，”若是等邊三角形，則提示“等邊三角形。”畫出程序流程圖、控制流程圖、計(jì)算圈復(fù)雜度V（g），找出基本測試路徑。、根據(jù)你的經(jīng)驗(yàn)說說你對(duì)軟件測試/質(zhì)量保證的理解？軟件質(zhì)量保證與測試是根據(jù)軟件開發(fā)階段的規(guī)格說明和

48、程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)的一批測試用例（即輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)錯(cuò)誤的過程。它是對(duì)應(yīng)用程序的各個(gè)方面進(jìn)行測試以檢查其功能、語言有效性及外觀排布.軟件測試的流程是什么？需求調(diào)查:全面了解您的系統(tǒng)概況、應(yīng)用領(lǐng)域、軟件開發(fā)周期、軟件開發(fā)環(huán)境、開發(fā)組織、時(shí)間安排、功能需求、性能需求、質(zhì)量需求及測試要求等根據(jù)系統(tǒng)概況進(jìn)行項(xiàng)目所需的人員、時(shí)間和工作量估計(jì)及項(xiàng)目報(bào)價(jià)。制定初步的項(xiàng)目計(jì)劃:在與您充分共同和協(xié)商的基礎(chǔ)上制定我們的測試計(jì)劃。測試準(zhǔn)備:組織測試團(tuán)隊(duì)、培訓(xùn)、建立測試和管理環(huán)境等。測試設(shè)計(jì):按照測試要求進(jìn)行每個(gè)測試項(xiàng)的測試設(shè)計(jì)，包括測試用例的設(shè)計(jì)及測試腳本的開發(fā)

49、等。測試實(shí)施:按照測試計(jì)劃進(jìn)行實(shí)施測試。測試評(píng)估:根據(jù)測試的結(jié)果，出具測試評(píng)估報(bào)告。（1）你對(duì)SQA的職責(zé)和工作活動(dòng)（如軟件度量）的理解：SQA就是獨(dú)立于軟件開發(fā)的項(xiàng)目組，通過對(duì)軟件開發(fā)過程的監(jiān)控，來保證軟件的開發(fā)流程按照指定的CMM規(guī)程（如果有相應(yīng)的CMM規(guī)程），對(duì)于不符合項(xiàng)及時(shí)提出建議和改進(jìn)方案，必要是可以要高層經(jīng)理匯報(bào)以求問題的解決。通過這樣的途徑來預(yù)防缺陷的引入，從而減少后期軟件的維護(hù)成本。SQA主要的工作活動(dòng)包括制定SQA工作計(jì)劃，參與階段產(chǎn)物的評(píng)審，進(jìn)行過程質(zhì)量、功能配置及物理配置的審計(jì)等;對(duì)項(xiàng)目開發(fā)過程中產(chǎn)生的數(shù)據(jù)進(jìn)行度量等等；說說你對(duì)軟件配置管理的理解：項(xiàng)目在開發(fā)的過程中要用相

50、應(yīng)的配置管理工具對(duì)配置項(xiàng)（包括各個(gè)階段的產(chǎn)物）進(jìn)行變更控制，配置管理的使用取決于項(xiàng)目規(guī)模和復(fù)雜性能及風(fēng)險(xiǎn)的水平。軟件的規(guī)模越大，配置管理就顯得越重要。還有在配置管理中，有一個(gè)很重要的概念，那就是基線，是在一定階段各個(gè)配置項(xiàng)的組合，一個(gè)基線就提供了一個(gè)正式的標(biāo)準(zhǔn)，隨后的工作便基于此標(biāo)準(zhǔn)，并且只有經(jīng)過授權(quán)后才能變更這個(gè)標(biāo)準(zhǔn)。配置管理工具主要有CC,VSS,CVS等，偶只用過CVS,對(duì)其它的不熟悉怎樣寫測試計(jì)劃和測試用例：簡單點(diǎn)，測試計(jì)劃里應(yīng)有詳細(xì)的測試策略（測試方法等），合理詳盡的資源安排等，至于測試用例，那是依賴于需求（包括功能與非功能需求）是否細(xì)化到功能點(diǎn)，是否可測試等。說說主流的軟件工程思想

51、（如CMM，CMMI，RUP，XP，PSP，TSP等）的大致情況以及對(duì)它們的理解：CMM:SWCapabilityMaturityModel軟件能力成熟度模型,其作用是用于軟件過程的改進(jìn)、評(píng)估及軟件能力的評(píng)鑒CMMI:CapabilityMaturityModelIntegration能力成熟度模型集成CMMI融入了大部分最新的軟件管理實(shí)踐，同時(shí)彌補(bǔ)了SW-CMM模型中的缺陷RUP:rationalunifiedprocess是軟件工程化過程。XP：extremeprogram,即極限編程的意思，適用于小型團(tuán)隊(duì)的軟件開發(fā)，想上面第三個(gè)問題就可以結(jié)合原型法采用這樣的開發(fā)流程。要明白測試對(duì)于xp開

52、發(fā)的重要性，強(qiáng)調(diào)測試（重點(diǎn)是單元測試）先行的理念。編程可以明顯提高代碼的質(zhì)量，持續(xù)集成對(duì)于快速定位問題很有好處。PSP,TSP分別是個(gè)體軟件過程（PersonalSoftwareProcess）,群組軟件過程（TeamSoftwareProcess）大家都知道，CMM只是告訴你怎么做但并沒有告訴你如何做，所以PSP/TSP就是告訴你企業(yè)在實(shí)施CMM的過程中如何做，PSP強(qiáng)調(diào)建立個(gè)人技能（如何制定計(jì)劃、控制質(zhì)量及如何與其他人相互協(xié)作等等）而TSP著重于生產(chǎn)并交付高質(zhì)量的軟件產(chǎn)品（如何有效地規(guī)劃和管理所面臨的項(xiàng)目開發(fā)任務(wù)等等）。總之，單純實(shí)施CMM，永遠(yuǎn)不能真正做到能力成熟度的升級(jí)，只有將實(shí)施CM

53、M與實(shí)施PSP和TSP有機(jī)地結(jié)合起來，才能發(fā)揮最大的效力。因此，軟件過程框架應(yīng)該是CMM/PSP/TSP的有機(jī)集成。4、還有問一下你是怎樣保證軟件質(zhì)量的，也就是說你覺得怎樣才能最大限度地保證軟件質(zhì)量？測試并不能夠最大限度的保證軟件的質(zhì)量，軟件的高質(zhì)量是開發(fā)和設(shè)計(jì)出來的，而不是測試出來的，它不僅要通過對(duì)軟件開發(fā)流程的監(jiān)控，使得軟件開發(fā)的各個(gè)階段都要按照指定的規(guī)程進(jìn)行，通過對(duì)各個(gè)階段產(chǎn)物的評(píng)審，QA對(duì)流程的監(jiān)控，對(duì)功能及配置的審計(jì)來達(dá)到開發(fā)的最優(yōu)化。當(dāng)然測試也是保證軟件質(zhì)量的一個(gè)重要方式，是軟件質(zhì)量保證工程的一個(gè)重要組成部分。5、然后緊接著就基于目前中國的國情，大多數(shù)公司的軟件項(xiàng)目進(jìn)度緊張、人員較

54、少、需求文檔根本沒有或者很不規(guī)范，你認(rèn)為在這種情況下怎樣保證軟件的質(zhì)量？（大多數(shù)公司最想知道的就是在這種困難面前你該怎么保證軟件的質(zhì)量，因?yàn)檫@些公司一般就是這種情況既不想投入過多又想保證質(zhì)量，faint）出現(xiàn)以上的情況，如果僅僅想通過測試來提高軟件質(zhì)量，那幾乎是不可能，原因是沒有足夠的時(shí)間讓你去測試，少而不規(guī)范的文檔導(dǎo)致測試需求無法細(xì)化何談足夠且有針對(duì)性進(jìn)行測試。所以，作為公司質(zhì)量保證的你應(yīng)該先和項(xiàng)目經(jīng)理確定符合項(xiàng)目本身最適合的軟件生命周期模型（比如RUP的剪裁，原型法）,明確項(xiàng)目的開發(fā)流程并督促項(xiàng)目組按照此流程開展工作，所有項(xiàng)目組成員（項(xiàng)目經(jīng)理更加重要）都要制定出合理的工作計(jì)劃，加強(qiáng)代碼的單

55、元測試，在客戶既定的產(chǎn)品交付日期范圍之內(nèi)，進(jìn)行產(chǎn)品的持續(xù)集成等等，如果時(shí)間允許可以再配合客戶進(jìn)行必要的系統(tǒng)功能測試。6、一個(gè)測試工程師應(yīng)具備那些素質(zhì)和技能？ TOC o 1-5 h z 1、掌握基本的測試基礎(chǔ)理論；2、本著找出軟件存在的問題的態(tài)度進(jìn)行測試,即客觀吧,不要以挑刺形象出現(xiàn)3、可熟練閱讀需求規(guī)格說明書等文檔；4、以用戶的觀點(diǎn)看待問題5、有著強(qiáng)烈的質(zhì)量意識(shí)；6、細(xì)心和責(zé)任心；7、良好的有效的溝通方式（與開發(fā)人員及客戶）8、具有以往的測試經(jīng)驗(yàn)；能夠及時(shí)準(zhǔn)確地判斷出高危險(xiǎn)區(qū)在何處.7、做好軟件測試的一些關(guān)鍵點(diǎn).測試人員必須經(jīng)過測試基礎(chǔ)知識(shí)和理論的相關(guān)培訓(xùn)。.測試人員必須熟悉系統(tǒng)功能和業(yè)務(wù)。

56、.測試必須事先要有計(jì)劃，而且測試方案要和整個(gè)項(xiàng)目計(jì)劃協(xié)調(diào)好.必須事先編寫測試用例，測試執(zhí)行階段必須根據(jù)測試用例進(jìn)行.易用性，功能，分支，邊界，性能等功能性和非功能性需要都要進(jìn)行測試.對(duì)于復(fù)雜的流程一定要進(jìn)行流程分支，組合條件分析，再進(jìn)行等價(jià)類劃分準(zhǔn)備相關(guān)測試數(shù)據(jù).測試設(shè)計(jì)的一個(gè)重要內(nèi)容是要準(zhǔn)備好具體的測試數(shù)據(jù)，清楚這個(gè)測試數(shù)據(jù)是測哪個(gè)場景或分支的.個(gè)人任務(wù)平均每三個(gè)測試用例至少應(yīng)該發(fā)現(xiàn)一個(gè)BUG，否則只能說明測試用例質(zhì)量不好其它暫時(shí)都不要考慮去自動(dòng)化。.除了每日構(gòu)建的冒煙測試可以考慮測試自動(dòng)化外，8、軟件測試員自身素質(zhì)培養(yǎng)首先，應(yīng)對(duì)軟件測試感興趣和對(duì)自己有自信，如果具備了這兩點(diǎn)，那么在開發(fā)過程

57、中不管遇到什么樣的困難，我相信你一定能克服。善于懷疑，世界上沒有絕對(duì)正確的，總有錯(cuò)誤的地方，具有叛逆心理，別人認(rèn)為不可能發(fā)生的事，我卻認(rèn)為可能發(fā)生。別人認(rèn)為是對(duì)的，我卻認(rèn)為不是對(duì)的。（3）打破砂鍋問到底的精神，對(duì)于只出現(xiàn)過一次的bug,一定找出原因，不解決誓不罷休。保持一個(gè)良好的心情，否則可能無法把測試作好。不要把生活中的不愉快的情緒帶到工作中來。做測試時(shí)要細(xì)心，不是所有的bug都能很容易的找出，一定要細(xì)心才能找出這些bug。靈活一些，聰明一點(diǎn)，多制造一些容易產(chǎn)生bug的例子。在有條件的情況下，多和客戶溝通，他們身上有你所需要的。設(shè)身處地為客戶著想，從他們的角度去測試系統(tǒng)。不要讓程序員，以“這

58、種情況不可能發(fā)生”這句話說服你，相反，你應(yīng)該去說服他，告訴他在客戶心里，并不是這樣的?？紤]問題要全面，結(jié)合客戶的需求、業(yè)務(wù)的流程、和系統(tǒng)的構(gòu)架，等多方面考慮問題。提出問題不要復(fù)雜化，這一點(diǎn)和前面的有點(diǎn)矛盾，如果你是一新手，暫時(shí)不要管這一點(diǎn)，因?yàn)樽罱K將有你的小組成員討論解決。追求完美，對(duì)于新測試員來說，努力的追求完美，這對(duì)你很好，盡管有些事無法做到，但你應(yīng)該去嘗試。幽默感，能和開發(fā)小組很好的溝通是關(guān)鍵，試著給你的開發(fā)小組找一個(gè)“BUG殺手”，或?qū)λ麄冋f“我簡直不敢相信，你寫的程序居然到現(xiàn)在沒有找到BUG”。）到此是不是對(duì)測試很有興趣呢？不過我要告訴你，測試過程中有酸甜苦辣，其中的滋味只有你知道，

59、也許你會(huì)感到枯燥，要學(xué)會(huì)放松自己，去溜冰或做你喜歡做的事，不過，別放棄，因?yàn)槟愕淖孕鸥嬖V過你“你會(huì)是很優(yōu)秀的測試員”不是嗎？9、為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO質(zhì)量認(rèn)證一樣，測試同樣也需要質(zhì)量的保證，這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時(shí)讓開發(fā)人員得知并修改問題，在即將發(fā)布時(shí)，從測試報(bào)告中得出軟件的質(zhì)量情況。、您所熟悉的軟件測試類型都有哪些？測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。性能測試是通過自動(dòng)化的測試工具模擬多種正常、

60、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對(duì)軟件的第一印象。區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個(gè)細(xì)節(jié)功能，每個(gè)可能存在的功能問題。性能測試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關(guān)注于用戶體驗(yàn)上，用戶使用該產(chǎn)品的時(shí)候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺(tái)避免用戶無意輸入無效的數(shù)據(jù)，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍妫?？做某個(gè)性能測試的時(shí)候，首先它可能是個(gè)功能點(diǎn)，首先要保證