【文章內(nèi)容簡介】 左、右設(shè)計(jì)測試用例，很有可能發(fā)現(xiàn)新的錯(cuò)誤。邊界條件測試是一項(xiàng)基礎(chǔ)測試，也是后面系統(tǒng)測試中的功能測試的重點(diǎn)，邊界測試執(zhí)行的較好，可以大大提高程序健壯性。
（4）模塊中所有獨(dú)立路徑測試：在模塊中應(yīng)對每一條獨(dú)立執(zhí)行路徑進(jìn)行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。測試目的主要是為了發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤。具體做法就是程序員逐條調(diào)試語句。常見的錯(cuò)誤包括： 誤解或用錯(cuò)了算符優(yōu)先級； 混合類型運(yùn)算； 變量初值錯(cuò)； 精度不夠； 表達(dá)式符號錯(cuò)。
比較判斷與控制流常常緊密相關(guān)，測試時(shí)注意下列錯(cuò)誤： 不同數(shù)據(jù)類型的對象之間進(jìn)行比較； 錯(cuò)誤地使用邏輯運(yùn)算符或優(yōu)先級； 因計(jì)算機(jī)表示的局限性，期望理論上相等而實(shí)際上不相等的兩個(gè)量相等； 比較運(yùn)算或變量出錯(cuò)； 循環(huán)終止條件或不可能出現(xiàn)； 迭代發(fā)散時(shí)不能退出； 錯(cuò)誤地修改了循環(huán)變量。
模塊的各條錯(cuò)誤處理通路測試：程序在遇到異常情況時(shí)不應(yīng)該退出，好的程序應(yīng)能預(yù)見各種出錯(cuò)條件，并預(yù)設(shè)各種出錯(cuò)處理通路。如果用戶不按照正常操作，程序就退出或者停止工作，實(shí)際上也是一種缺陷，因此單元測試要測試各種錯(cuò)誤處理路徑。一般這種測試著重檢查下列問題： 輸出的出錯(cuò)信息難以理解； 記錄的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不相符； 在程序自定義的出錯(cuò)處理段運(yùn)行之前，系統(tǒng)已介入； 異常處理不當(dāng)； 錯(cuò)誤陳述中未能提供足夠的定位出錯(cuò)信息。
3如何理解強(qiáng)度測試？ 參考答案： 強(qiáng)度測試是為了確定系統(tǒng)在最差工作環(huán)境的工作能力,也可能是用于驗(yàn)證在標(biāo)準(zhǔn)工作壓力下的各種資源的最下限指標(biāo)。
它和壓力測試的目標(biāo)是不同的,壓力測試是在標(biāo)準(zhǔn)工作環(huán)境下,不斷增加系統(tǒng)負(fù)荷,最終測試出該系統(tǒng)能力達(dá)到的最大負(fù)荷(穩(wěn)定和峰值),而強(qiáng)度測試則是在非標(biāo)準(zhǔn)工作環(huán)境下,甚至不斷人為降低系統(tǒng)工作環(huán)境所需要的資源,如網(wǎng)絡(luò)帶寬,系統(tǒng)內(nèi)存,數(shù)據(jù)鎖等等,以測試系統(tǒng)在資源不足的情況下的工作狀態(tài),通過強(qiáng)度測試,可以確定本系統(tǒng)正常工作的最差環(huán)境. 強(qiáng)度測試和壓力測試的測試指標(biāo)相近,大多都是與時(shí)間相關(guān)的指標(biāo),如并發(fā)量(吞吐量),延遲(最大＼最?。芷骄?以及順序指標(biāo)等 強(qiáng)度測試需要對系統(tǒng)的結(jié)構(gòu)熟悉,針對系統(tǒng)的特征設(shè)計(jì)強(qiáng)度測試的方法 如何理解壓力、負(fù)載、性能測試測試？ 參考答案： 性能測試是一個(gè)較大的范圍，實(shí)際上性能測試本身包含了性能、強(qiáng)度、壓力、負(fù)載等多方面的測試內(nèi)容。
壓力測試是對服務(wù)器的穩(wěn)定性以及負(fù)載能力等方面的測試，是一種很平常的測試。增大訪問系統(tǒng)的用戶數(shù)量、或者幾個(gè)用戶進(jìn)行大數(shù)據(jù)量操作都是壓力測試。而負(fù)載測試是壓力相對較大的測試，主要是測試系統(tǒng)在一種或者集中極限條件下的相應(yīng)能力，是性能測試的重要部分。100個(gè)用戶對系統(tǒng)進(jìn)行連續(xù)半個(gè)小時(shí)的訪問可以看作壓力測試，那么連續(xù)訪問8個(gè)小時(shí)就可以認(rèn)為負(fù)載測試，1000個(gè)用戶連續(xù)訪問系統(tǒng)1個(gè)小時(shí)也可以看作是負(fù)載測試。
實(shí)際上壓力測試和負(fù)載測試沒有明顯的區(qū)分。測試人員應(yīng)該站在關(guān)注整體性能的高度上來對系統(tǒng)進(jìn)行測試。
4什么是系統(tǒng)瓶頸？ 參考答案： 瓶頸主要是指整個(gè)軟硬件構(gòu)成的軟件系統(tǒng)某一方面或者幾個(gè)方面能力不能滿足用戶的特定業(yè)務(wù)要求，“特定”是指瓶頸會在某些條件下會出現(xiàn)，因?yàn)楫吘勾蠖鄶?shù)系統(tǒng)在投入前。
嚴(yán)格的從技術(shù)角度講，所有的系統(tǒng)都會有瓶頸，因?yàn)榇蠖鄶?shù)系統(tǒng)的資源配置不是協(xié)調(diào)的，例如CPU使用率剛好達(dá)到100％時(shí)，內(nèi)存也正好耗盡的系統(tǒng)不是很多見。因此我們討論系統(tǒng)瓶頸要從應(yīng)用的角度討論：關(guān)鍵是看系統(tǒng)能否滿足用戶需求。在用戶極限使用系統(tǒng)的情況下，系統(tǒng)的響應(yīng)仍然正常，我們可以認(rèn)為改系統(tǒng)沒有瓶頸或者瓶頸不會影響用戶工作。
因此我們測試系統(tǒng)瓶頸主要是實(shí)現(xiàn)下面兩個(gè)目的： 發(fā)現(xiàn)“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統(tǒng)時(shí)的瓶頸，然后解決瓶頸，這是性能測試的基本目標(biāo)。
發(fā)現(xiàn)潛在的瓶頸并解決，保證系統(tǒng)的長期穩(wěn)定性。主要是考慮用戶在將來擴(kuò)展系統(tǒng)或者業(yè)務(wù)發(fā)生變化時(shí)，系統(tǒng)能夠適應(yīng)變化。滿足用戶目前需求的系統(tǒng)不是最好的，我們設(shè)計(jì)系統(tǒng)的目標(biāo)是在保證系統(tǒng)整個(gè)軟件生命周期能夠不斷適應(yīng)用戶的變化，或者通過簡單擴(kuò)展系統(tǒng)就可以適應(yīng)新的變化。
4文檔測試主要包含什么內(nèi)容？ 參考答案： 在國內(nèi)軟件開發(fā)管理中，文檔管理幾乎是最弱的一項(xiàng)，因而在測試工作中特別容易忽略文檔測試也就不足為奇了。要想給用戶提供完整的產(chǎn)品，文檔測試是必不可少的。文檔測試一般注重下面幾個(gè)方面： 文檔的完整性：主要是測試文檔內(nèi)容的全面性與完整性，從總體上把握文檔的質(zhì)量。例如用戶手冊應(yīng)該包括軟件的所有功能模塊。
描述與軟件實(shí)際情況的一致性：主要測試軟件文檔與軟件實(shí)際的一致程度。例如用戶手冊基本完整后，我們還要注意用戶手冊與實(shí)際功能描述是否一致。因?yàn)槲臋n往往跟不上軟件版本的更新速度。
易理解性：主要是檢查文檔對關(guān)鍵、重要的操作有無圖文說明，文字、圖表是否易于理解。對于關(guān)鍵、重要的操作僅僅只有文字說明肯定是不夠的，應(yīng)該附有圖表使說明更為直觀和明了。
文檔中提供操作的實(shí)例：這項(xiàng)檢查內(nèi)容主要針對用戶手冊。對主要功能和關(guān)鍵操作提供的應(yīng)用實(shí)例是否豐富，提供的實(shí)例描述是否詳細(xì)。只有簡單的圖文說明，而無實(shí)例的用戶手冊看起來就像是軟件界面的簡單拷貝，對于用戶來說，實(shí)際上沒有什么幫助。
印刷與包裝質(zhì)量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過于粗糙，不易于用戶保存。優(yōu)秀的文檔例如用戶手冊和技術(shù)白皮書，應(yīng)提供商品化包裝，并且印刷精美。
4功能測試用例需要詳細(xì)到什么程度才是合格的？ 參考答案： 這個(gè)問題也是測試工程師經(jīng)常問的問題。有人主張測試用例詳細(xì)到每個(gè)步驟執(zhí)行什么都要寫出來，目的是即使一個(gè)不了解系統(tǒng)的新手都可以按照測試用例來執(zhí)行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟件外包文檔都是這樣做的。
另外一種觀點(diǎn)就是主張寫的粗些，類似于編寫測試大綱。主張這種觀點(diǎn)的人是因?yàn)檐浖_發(fā)需求管理不規(guī)范，變動(dòng)十分頻繁，因而不能按照歐美的高標(biāo)準(zhǔn)來編寫測試用例。這樣的測試用例容易維護(hù)，可以讓測試執(zhí)行人員有更大的發(fā)揮空間。
實(shí)際上，軟件測試用例的詳細(xì)程度首先要以覆蓋到測試點(diǎn)為基本要求。舉個(gè)例子：“用戶登陸系統(tǒng)”的測試用例可以不寫出具體的執(zhí)行數(shù)據(jù)，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個(gè)功能是不合格的測試用例。覆蓋功能點(diǎn)不是指列出功能點(diǎn)，而是要寫出功能點(diǎn)的各個(gè)方面（如果組合情況較多時(shí)可以采用等價(jià)劃分）。
另一個(gè)影響測試用例的就是組織的開發(fā)能力和測試對象特點(diǎn)。如果開發(fā)力量比較落后，編寫較詳細(xì)的測試用例是不現(xiàn)實(shí)的，因?yàn)楦緵]有那么大的資源投入，當(dāng)然這種情況很隨著團(tuán)隊(duì)的發(fā)展而逐漸有所改善。測試對象特點(diǎn)重點(diǎn)是指測試對象在進(jìn)度、成本等方面的要求，如果進(jìn)度較緊張的情況下，是根本沒有時(shí)間寫出高質(zhì)量的測試用例的，甚至有些時(shí)候測試工作只是一種輔助工作，因而不編寫測試用例。
因此，測試用例的編寫要根據(jù)測試對象特點(diǎn)、團(tuán)隊(duì)的執(zhí)行能力等各個(gè)方面綜合起來決定編寫策略。最后要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時(shí)，不斷地提高自身能力。
4配置和兼容性測試的區(qū)別是什么？ 參考答案： 配置測試的目的是保證軟件在其相關(guān)的硬件上能夠正常運(yùn)行，而兼容性測試主要是測試軟件能否與不同的軟件正確協(xié)作。
配置測試的核心內(nèi)容就是使用各種硬件來測試軟件的運(yùn)行情況，一般包括： （1）軟件在不同的主機(jī)上的運(yùn)行情況，例如Dell和Apple； （2）軟件在不同的組件上的運(yùn)行情況，例如開發(fā)的撥號程序要測試在不同廠商生產(chǎn)的Modem上的運(yùn)行情況； （3）不同的外設(shè)； （4）不同的接口； （5）不同的可選項(xiàng)，例如不同的內(nèi)存大??； 兼容性測試的核心內(nèi)容： （1）測試軟件是否能在不同的操作系統(tǒng)平臺上兼容； （2）測試軟件是否能在同一操作系統(tǒng)平臺的不同版本上兼容； （3）軟件本身能否向前或者向后兼容； （4）測試軟件能否與其它相關(guān)的軟件兼容； （5）數(shù)據(jù)兼容性測試，主要是指數(shù)據(jù)能否共享； 配置和兼容性測試通稱對開發(fā)系統(tǒng)類軟件比較重要，例如驅(qū)動(dòng)程序、操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)等。具體進(jìn)行時(shí)仍然按照測試用例來執(zhí)行。
4軟件文檔測試主要包含什么？ 參考答案： 隨著軟件文檔系統(tǒng)日益龐大，文檔測試已經(jīng)成為軟件測試的重要內(nèi)容。文檔測試對象主要如下： 包裝文字和圖形； 市場宣傳材料、廣告以及其它插頁； 授權(quán)、注冊登記表； 最終用戶許可協(xié)議； 安裝和設(shè)置向?qū)В?用戶手冊； 聯(lián)機(jī)幫助； 樣例、示范例子和模板； …… 文檔測試的目的是提高易用性和可靠性，降低支持費(fèi)用，因?yàn)橛脩敉ㄟ^文檔就可以自己解決問題。因文檔測試的檢查內(nèi)容主要如下： 讀者對象——主要是文檔的內(nèi)容是否能讓該級別的讀者理解； 術(shù)語——主要是檢查術(shù)語是否適合讀者； 內(nèi)容和主題——檢查主題是否合適、是否丟失、格式是否規(guī)范等； 圖標(biāo)和屏幕抓圖——檢查圖表的準(zhǔn)確度和精確度； 樣例和示例——是否與軟件功能一致； 拼寫和語法； 文檔的關(guān)聯(lián)性——是否與其它相關(guān)文檔的內(nèi)容一致，例如與廣告信息是否一致； 文檔測試是相當(dāng)重要的一項(xiàng)測試工作，不但要給予充分的重視，更要要認(rèn)真的完成，象做功能測試一樣來對待文檔測試。
4沒有產(chǎn)品說明書和需求文檔地情況下能夠進(jìn)行黑盒測試嗎？ 參考答案： 這個(gè)問題是國內(nèi)測試工程師經(jīng)常遇到的問題，根源就是國內(nèi)軟件開發(fā)文檔管理不規(guī)范，對變更的管理方法就更不合理了。實(shí)際上沒有任何文檔的時(shí)候，測試人員是能夠進(jìn)行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據(jù)自己的專業(yè)技能、領(lǐng)域知識等不斷的深入了解測試對象、理解軟件功能，進(jìn)而發(fā)現(xiàn)缺陷。
在這種做法基本上把軟件當(dāng)成了產(chǎn)品說明書，測試過程中要和開發(fā)人員不斷的進(jìn)行交流。尤其在作項(xiàng)目的時(shí)候，進(jìn)度壓力比較大，可以作為加急測試方案。最大的風(fēng)險(xiǎn)是不知道有些特性是否被遺漏。
4測試中的“殺蟲劑怪事”是指什么？ 參考答案： “殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件測試技術(shù)》第二版中提出。用于描述測試人員對同一測試對象進(jìn)行的測試次數(shù)越多，發(fā)現(xiàn)的缺陷就會越來越少的現(xiàn)象。就像老用一種農(nóng)藥，害蟲就會有免疫力，農(nóng)藥發(fā)揮不了效力。這種現(xiàn)象的根本原因就是測試人員對測試軟件過于熟悉，形成思維定勢。
為了克服這種現(xiàn)象，測試人員需要不斷編寫新的測試程序或者測試用例，對程序的不同部分進(jìn)行測試，以發(fā)現(xiàn)更多的缺陷。也可以引用新人來測試軟件，剛剛進(jìn)來的新手往往能發(fā)現(xiàn)一些意想不到的問題。
4在配置測試中，如何判斷發(fā)現(xiàn)的缺陷是普通問題還是特定的配置問題？ 參考答案： 在進(jìn)行配置測試時(shí)，測試工程師仍然會發(fā)現(xiàn)一些普通的缺陷，也就是與配置環(huán)境無關(guān)的缺陷。因此判斷新發(fā)現(xiàn)的問題，需要在不同的配置中重新執(zhí)行發(fā)現(xiàn)軟件缺陷的步驟，如果軟件缺陷不出現(xiàn)了，就可能是配置缺陷；如果在所有的配置中都出現(xiàn)，就可能是普通缺陷。
需要注意的是，配置問題可以在一大類配置中出現(xiàn)。例如，撥號程序可能在所有的外置Modem中都存在問題，而內(nèi)置的Modem不會有任何問題。
4為什么盡量不要讓時(shí)間有富裕的員工去做一些測試？ 參考答案： 表面上看這體現(xiàn)了管理的效率和靈活性，但實(shí)際上也體現(xiàn)了管理者對測試的輕視。測試和測試的人有很大關(guān)系。測試工作人員應(yīng)該是勤奮并富有耐心，善于學(xué)習(xí)、思考和發(fā)現(xiàn)問題，細(xì)心有條理，總結(jié)問題，如果具備這樣的優(yōu)點(diǎn)，做其它工作同樣也會很出色，因此這里還有一個(gè)要求，就是要喜歡測試這項(xiàng)工作。如果他是專職的，那么肯定更有經(jīng)驗(yàn)和信心。國內(nèi)的小伙子好象都喜歡做程序員，兩者工作性質(zhì)不同，待遇不同，地位不同，對自我實(shí)現(xiàn)的價(jià)值的認(rèn)識也不同，這是行業(yè)的一個(gè)需要改善的問題。如果只是為了完成任務(wù)而完成任務(wù)，或者發(fā)現(xiàn)了幾個(gè)問題就覺得滿意了，這在任何其它工作中都是不行的。
50、完全測試程序是可能的嗎？ 參考答案： 軟件測試初學(xué)者可能認(rèn)為拿到軟件后需要進(jìn)行完全測試，找到全部的軟件缺陷，使軟件“零缺陷”發(fā)布。實(shí)際上完全測試是不可能的。主要有以下一個(gè)原因： 完全測試比較耗時(shí)，時(shí)間上不允許； 完全測試通常意味著較多資源投入，這在現(xiàn)實(shí)中往往是行不通的； 輸入量太大，不能一一進(jìn)行測試； 輸出結(jié)果太多，只能分類進(jìn)行驗(yàn)證； 軟件實(shí)現(xiàn)途徑太多； 軟件產(chǎn)品說明書沒有客觀標(biāo)準(zhǔn)，從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同； 因此測試的程度要根據(jù)實(shí)際情況確定。
5軟件測試的風(fēng)險(xiǎn)主要體現(xiàn)在哪里？ 參考答案： 我們沒有對軟件進(jìn)行完全測試，實(shí)際就是選擇了風(fēng)險(xiǎn)，因?yàn)槿毕輼O有可能存在沒有進(jìn)行測試的部分。舉個(gè)例子，程序員為了方便，在調(diào)試程序時(shí)會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發(fā)布前這些代碼中的一些沒有被注釋掉。在測試時(shí)測試工程師又沒有對其進(jìn)行測試。如果客戶碰到它，這將是代價(jià)昂貴的缺陷，因?yàn)榻桓逗蟛疟豢蛻舭l(fā)現(xiàn)。
因此，我們要盡可能的選擇最合適的測試量，把風(fēng)險(xiǎn)降低到最小。
5發(fā)現(xiàn)的缺陷越多，說明軟件缺陷越多嗎？ 參考答案： 這是一個(gè)比較常見的現(xiàn)象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個(gè)后，會接二連三的發(fā)現(xiàn)很多缺陷，頗有個(gè)人成就感。其中的原因主要如下： 代碼復(fù)用、拷貝代碼導(dǎo)致程序員容易犯相同的錯(cuò)誤。類的繼承導(dǎo)致所有的子類會包含基類的錯(cuò)誤，反復(fù)拷貝同一代碼意味可能也復(fù)制了缺陷。
程序員比較勞累是可以導(dǎo)致某些連續(xù)編寫的功能缺陷較多。程序員加班是一種司空見慣的現(xiàn)象，因此體力不只時(shí)容易編寫一些缺陷較多的程序。而這些連續(xù)潛伏缺陷恰恰時(shí)測試工程師大顯身手的地方。
“缺陷一個(gè)連著一個(gè)”不是一個(gè)客觀規(guī)律，只是一個(gè)常見的現(xiàn)象。如果軟件編寫的比較好，這種現(xiàn)象就不常見了。測試人員只要嚴(yán)肅認(rèn)真的測試程序就可以了。
5所有的軟件缺陷都能修復(fù)嗎？所有的軟件缺陷都要修復(fù)嗎？ 參考答案： 從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒有必要修復(fù)所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時(shí)候不能追求軟件的完美。對于整個(gè)項(xiàng)目團(tuán)隊(duì)，要做的是對每一個(gè)軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險(xiǎn)決定那些缺陷要修復(fù)。發(fā)生這種現(xiàn)象的主要原因如下： 沒有足夠的時(shí)間資源。在任何一個(gè)項(xiàng)目中，通常情況下開發(fā)人員和測試人員都是不夠用的，而且在項(xiàng)目中沒有預(yù)算足夠的回歸測試時(shí)間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強(qiáng)大壓力下，必須放棄某些缺陷的修改。
有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商