《軟件測試基礎》課件-第18章

第18章測試行業(yè)

18.1測試行業(yè)概述18.2測試認識誤區(qū)18.3測試員的思維方式18.4著名企業(yè)的測試面試題18.5軟件測試工程師職位簡介

18.1測試行業(yè)概述

軟件測試不僅早已成為軟件開發(fā)的有機組成部分，而且在整個軟件開發(fā)中占據(jù)著相當大的比重，所占比例高達40%以上，同時占整個軟件開發(fā)費用的50%以上。軟件測試人員與開發(fā)人員的人數(shù)比例大于1∶2。例如，微軟作為軟件行業(yè)的龍頭老大，開發(fā)Windows2000操作系統(tǒng)共有1700多個開發(fā)人員，以及3200個測試人員，開發(fā)和測試人員之比約為3∶5。HP公司中測試人員和開發(fā)人員人數(shù)比例為1∶1。

軟件行業(yè)比較發(fā)達的國家，如歐美各國、印度、以色列等，軟件測試行業(yè)的產(chǎn)值幾乎占了軟件行業(yè)總產(chǎn)值的1/4。軟件測試已經(jīng)發(fā)展成為一個獨立的產(chǎn)業(yè)，主要體現(xiàn)在：

(1)軟件測試在軟件公司中占有重要地位，軟件測試在人員配備和資金投入方面占據(jù)相當大的比重；

(2)軟件測試理論研究蓬勃發(fā)展，引領軟件測試理論研究的國際潮流；

(3)軟件測試市場繁榮，如MI、Compuware、Rational等，其出品的測試工具占領了國際市場；

(4)軟件產(chǎn)品的認定往往需要第三方測試的介入。

隨著中國軟件業(yè)的日益壯大和逐步走向成熟，軟件測試也在不斷發(fā)展，從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變?yōu)榘ň幹茰y試計劃、編寫測試用例、準備測試數(shù)據(jù)、編寫測試腳本、實施測試、測試評估等多項內(nèi)容的正規(guī)測試。測試方式則由單純手工測試發(fā)展為手工、自動兼之，并有向第三方專業(yè)測試公司發(fā)展的趨勢。雖然我國軟件產(chǎn)業(yè)以及信息化工作取得了較大成績，但與發(fā)達國家相比，目前仍然停留在開發(fā)人員自行測試階段，軟件開發(fā)人員和測試人員結(jié)構(gòu)明顯失調(diào)，缺乏第三方測試。國內(nèi)軟件測試與國外軟件測試主要存在如下差距：

(1)測試的理解認識。國內(nèi)軟件企業(yè)普遍存在重開發(fā)輕測試，將測試置于從屬地位，沒有認識到軟件項目完成不僅取決于開發(fā)人員，更取決于測試人員。國內(nèi)許多中小型軟件企業(yè)沒有軟件測試部門，有些甚至不設置軟件測試的崗位。

(2)測試過程的管理。國內(nèi)軟件企業(yè)普遍存在測試的隨意化、簡單化的情況，未建立有效、規(guī)范的測試管理體系。

(3)測試工具的使用。國內(nèi)軟件企業(yè)的測試普遍缺乏使用自動化測試工具。

(4)測試人員的培養(yǎng)。軟件測試領域目前十分缺乏人才，首先是測試人員角色定位不合理，其次是缺乏專家級測試人才。

當然，國內(nèi)軟件測試產(chǎn)業(yè)也正在慢慢發(fā)展。第一，軟件測試工具的開發(fā)取得了顯著進展，如西安交通大學開發(fā)的COBOL測試系統(tǒng)、華中科技大學開發(fā)的C編譯程序測試系統(tǒng)、北京航空航天大學與清華大學開發(fā)的C軟件綜合測試系統(tǒng)、中科院開發(fā)的I-test測試工具等。第二，軟件企業(yè)對于軟件測試設置了相應部門，如東軟、神州數(shù)碼等軟件企業(yè)。第三，軟件測試正在成為新的就業(yè)崗位。

18.2測試認識誤區(qū)

誤區(qū)一：使用了測試工具，就是進行了有效的測試。

誤區(qū)一是軟件測試認識的通病，幾乎是軟件開發(fā)中每個領域CASE工具剛出現(xiàn)時都會產(chǎn)生的問題。比如：使用RationalRose工具進行UML制圖，就聲稱采用面向?qū)ο蠓椒?，而其軟件設計和代碼實現(xiàn)卻是過程化的。同樣，在測試中往往認為使用某種測試工具，就能獲取種種好處，這種想法是錯誤的。

選擇測試工具，應以是否滿足需求為標準。對于大多數(shù)項目，一些開源測試工具的功能就足夠了，比如，Java語言的測試工具JUnit和C++方面的單元測試工具CppUnit等。誤區(qū)二：軟件中存在太多的無法測試的內(nèi)容。

軟件開發(fā)中確實存在一些內(nèi)容很難測試，但并非無法測試。極限編程中，軟件開發(fā)時首先編寫測試代碼，迫使開發(fā)者從易使用性、易測試性等角度考慮需求，專注軟件模塊的抽象，避免模塊之間的耦合過緊，定義出清晰明確反映意圖的模塊接口，設計出良好的軟件系統(tǒng)架構(gòu)。誤區(qū)三：單元測試和驗收測試沒有什么區(qū)別。

以建筑行業(yè)類比軟件開發(fā)過程，單元測試類比于建筑質(zhì)檢人員檢測建筑時，關(guān)注的重點是建筑的內(nèi)部結(jié)構(gòu)、地基、框架以及墻壁是否垂直等，檢測要保證建筑的各個部分符合建筑的質(zhì)量標準。驗收測試類比為建筑使用者對建筑進行的檢測，使用者關(guān)注的重點是建筑的外觀是否美觀、各個房間的大小是否合適、窗戶的位置是否合適、是否能夠滿足家庭的需要等。所以，建筑的使用者執(zhí)行驗收測試，是從用戶的角度出發(fā)；而建筑質(zhì)檢人員執(zhí)行單元測試，是從構(gòu)建者的角度出發(fā)的。

單元測試和驗收測試之間的區(qū)別取決于從不同的測試角度出發(fā)，二者互為補充。單元測試保證把事情做對，而驗收測試則保證做正確的事情。關(guān)于單元測試和驗收測試的劃分，沒有一個通用的標準。誤區(qū)四：軟件開發(fā)完成后進行軟件測試。

一般認為，軟件開發(fā)過程包括需求分析、概要設計、詳細設計、軟件編碼、軟件測試、軟件發(fā)布等。據(jù)此，常常錯誤地認為軟件測試是在軟件編碼之后進行的。

軟件測試貫穿于軟件項目的整個生命過程，在軟件項目的每一個階段都要進行不同目的和不同內(nèi)容的測試活動，以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設計等各類文檔。

軟件開發(fā)與軟件測試是交互進行的。例如，編碼需要單元測試，模塊組合階段需要集成測試。如果等到軟件編碼后才進行測試，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將很差。誤區(qū)五：軟件發(fā)布后發(fā)現(xiàn)質(zhì)量問題，是測試人員的問題。

軟件錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤。從軟件開發(fā)的角度看，高質(zhì)量的軟件不是軟件測試的功勞，而依賴于軟件生命周期的各個過程，特別是需求分析和設計階段。如果軟件質(zhì)量出現(xiàn)問題，不能簡單地歸結(jié)為測試人員的責任，而應該分析軟件過程的各個階段，尋找出錯的原因和改進的措施。誤區(qū)六：軟件測試要求不高，隨便找個人就行。

軟件測試作為一個相對獨立的領域，其技術(shù)不斷更新和完善，新工具、新流程、新方法都在不斷出現(xiàn)。隨著軟件測試行業(yè)的大力發(fā)展，需要更多具備測試技術(shù)和管理經(jīng)驗的測試人員。軟件測試人員不僅需要掌握測試知識，更需要不斷地實踐。誤區(qū)七：項目進度吃緊時少做測試，時間寬裕時多做測試。

誤區(qū)七是在軟件開發(fā)過程中不重視軟件測試的常見表現(xiàn)，也是軟件項目過程管理混亂的表現(xiàn)。軟件項目開發(fā)需要各種計劃，對項目實施過程中的任何問題，都要有風險分析和相應的對策，不要因為開發(fā)進度的延期而簡單地縮短測試時間、人力和資源?？s短測試時間帶來測試的不完整，對項目質(zhì)量的下降引入風險，會造成更大的軟件缺陷?？朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制，包括軟件測試計劃、測試設計、測試執(zhí)行、測試度量和測試控制。誤區(qū)八：軟件測試是低級工作，開發(fā)人員才是軟件高手。

開發(fā)和測試是相輔相成的過程，測試人員需要和程序員保持密切的聯(lián)系，加強交流和協(xié)調(diào)。因此，軟件測試不僅僅是測試人員的事情，也與程序員密切相關(guān)。軟件測試人員和開發(fā)人員并沒有技術(shù)的高低之分。軟件開發(fā)人員往往只對自己開發(fā)的模塊比較了解，對算法掌握的程度較高。而軟件測試人員不僅要懂得如何測試，還要懂得被測軟件的業(yè)務知識和專業(yè)知識。因此，軟件測試和開發(fā)人員只是工作側(cè)重點有所不同，并不存在水平差異的問題。

18.3測試員的思維方式

1．逆向思維方式

逆向思維是相對的，就是按照與常規(guī)思路相反的方向進行思考，比如根據(jù)結(jié)果逆推條件，從而得出輸入條件的等價類劃分。其實逆向思維在調(diào)試當中用到的也比較多，當發(fā)現(xiàn)缺陷時，進一步定位問題的所在，往往采用逆流而上進行分析。逆向思維往往能夠發(fā)現(xiàn)開發(fā)人員思維的漏洞。

2．組合思維方式

很多東西單一的思考都沒有問題，當將相關(guān)的事物組合在一起卻能發(fā)現(xiàn)很多問題，如多進程并發(fā)，不但使得程序的復雜度提高，也讓程序的缺陷率隨之增長。針對不同的應用，可以酌情考慮使用“排列”或者“組合”，將相關(guān)的因素劃分到不同的維度上，然后再考慮其相關(guān)性。

3．全局思維方式

全局思維方式就是從多角度分析待測的系統(tǒng)，以不同角色去看系統(tǒng)，分析其是否能夠滿足需求。在軟件開發(fā)過程中進行的各種評審，應讓更多的人參與思考，盡可能地實現(xiàn)全方位審查某個解決方案的正確性以及其它特性。

4．兩極思維方式

兩極思維方式，是在極端的情況下，看是否存在缺陷。邊界值分析方法就是兩極思維方式的典范。

5．簡單思維方式

通過舍去一些非關(guān)鍵特征，針對事物本質(zhì)進行測試，這樣不至于偏離方向。

6．比較思維方式

人們認識事物時，往往都是和已有的某些概念進行比較，找出相同、相異之處，或者歸類。應用模式是“比較思維”很常見的例子，有設計模式、體系結(jié)構(gòu)模式、測試模式等。由于經(jīng)驗在測試中很重要，因此比較思維是較為常用的方式。

18.4著名企業(yè)的測試面試題

1.軟件測試分哪兩種方法？分別適合什么情況？

【解析】

軟件測試方法一般分為白盒測試與黑盒測試。白盒測試又稱為結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序本身的測試，它著重于程序的內(nèi)部結(jié)構(gòu)及算法，通常不關(guān)心功能與性能指標；黑盒測試又稱為功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試，它實際上是站在最終用戶的立場，檢驗輸入輸出信息及系統(tǒng)性能指標是否符合規(guī)格說明書中有關(guān)功能需求及性能需求的規(guī)定。

2.一套完整的測試應該由哪些階段組成？分別闡述各個階段。

【解析】

完整的測試由計劃階段、設計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)測試、回歸測試、驗收測試等一套完整的測試組成，一般包括五個階段：

(1)測試計劃。首先，根據(jù)用戶需求報告中關(guān)于功能要求和性能指標的規(guī)格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準。以后所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程序即是合格的，反之即是不合格的；同時，還要適當選擇測試內(nèi)容，合理安排測試人員、測試時間及測試資源等。

(2)測試設計將測試計劃階段制訂的測試需求分解、細化為若干個可執(zhí)行的測試過程，并為每個測試過程選擇適當?shù)臏y試用例(測試用例選擇的好壞將直接影響測試結(jié)果的有效性)。

(3)測試開發(fā)建立可重復使用的自動測試過程。

(4)執(zhí)行測試開發(fā)階段建立的自動測試過程，并對所發(fā)現(xiàn)的缺陷進行跟蹤管理。測試執(zhí)行一般由單元測試、組合測試、集成測試、系統(tǒng)聯(lián)調(diào)及回歸測試等步驟組成，測試人員應本著科學負責的態(tài)度，一步一個腳印地進行測試。

(5)測試評估，結(jié)合量化的測試覆蓋域及缺陷跟蹤報告，對于應用軟件的質(zhì)量和開發(fā)團隊的工作進度及工作效率進行綜合評價。

3.您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請試述在這個過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？

【解析】

軟件測試部門配合系統(tǒng)分析人員對軟件需求進行分析討論，并根據(jù)需求說明書制定項目測試計劃，編寫測試用例，建立測試環(huán)境。

軟件測試人員負責軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級測試，負責軟件問題解決過程跟蹤，負責軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊及操作手冊，負責產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。

4.解釋驗證測試、基于用戶實際應用場景的測試、冒煙測試、兼容性測試及適用性測試的區(qū)別與聯(lián)系。

【解析】驗證測試的主要目的是驗證最新生成的軟件版本在功能上是否完整，主要的軟件特性是否正確；基于用戶實際應用場景的測試優(yōu)點是關(guān)注了用戶的需求，缺點是有時候難以真正模仿用戶真實的使用情況；冒煙測試指修復Bug后，針對此次修復是否會對其它模塊造成影響而進行的專門測試，其優(yōu)點是節(jié)省測試時間，防止建構(gòu)失敗，缺點是覆蓋率還是比較低；兼容性測試，主要目的是為了兼容第三方軟件，確保第三方軟件能正常運行，用戶不受影響；適用性測試，是確保軟件對于某些有殘疾的人士也能正常地使用，但優(yōu)先級比較低。其它的測試還有功能測試、安全性測試、壓力測試、性能測試、回歸測試、安裝升級測試等。

5.測試用例通常包括哪些內(nèi)容？著重闡述編制測試用例的具體做法的不同結(jié)構(gòu)(版本、編號、項目、設計人員、設計日期、輸入、預期輸出等)。

【解析】

軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結(jié)果。

用例編號：測試用例的編號有一定的規(guī)則，比如系統(tǒng)測試用例的編號這樣定義規(guī)則：PROJECT1-ST-001，命名規(guī)則是項目名稱+測試階段類型(系統(tǒng)測試階段)+編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。

測試標題：對測試用例的描述。測試用例標題應該清楚表達測試用例的用途。比如“測試用戶登錄時輸入錯誤密碼時，軟件的響應情況”。重要級別：定義測試用例的優(yōu)先級別，可以籠統(tǒng)地分為“高”和“低”兩個級別。一般來說，如果軟件需求的優(yōu)先級為“高”，那么針對該需求的測試用例優(yōu)先級也為“高”；反之亦然。

測試輸入：提供測試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好地定義需求的輸入，那么測試用例設計中會遇到很大的障礙。操作步驟：提供測試執(zhí)行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分幾個步驟完成，這部分內(nèi)容在操作步驟中詳細列出。

預期結(jié)果：提供測試執(zhí)行的預期結(jié)果，預期結(jié)果應該根據(jù)軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結(jié)果與預期結(jié)果不符，那么測試不通過；反之則測試通過。

6.描述使用Bugzilla缺陷管理工具對軟件缺陷(Bug)跟蹤管理的流程。

【解析】

測試人員或開發(fā)人員發(fā)現(xiàn)Bug后，首先判斷屬于哪個模塊的問題，填寫B(tài)ug報告后，系統(tǒng)會自動通過E-mail通知項目組長或直接通知開發(fā)者。

(1)經(jīng)驗證無誤后，修改狀態(tài)為“核實”。待整個產(chǎn)品發(fā)布后，修改為關(guān)閉，如果還有問題，重新打開，狀態(tài)重新變?yōu)椤癗ew”，并發(fā)郵件通知。

(2)項目組長根據(jù)具體情況，重新再次分配給Bug所屬的開發(fā)者。

(3)開發(fā)者收到E-mail信息后，判斷是否為自己的修改范圍。

(4)若是，進行處理并給出解決方法；若不是，重新再次分配給項目組長或應該分配的開發(fā)者。

(5)測試人員查詢開發(fā)者已修改的Bug，進行重新測試。

7.您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

【解析】

常用的測試用例設計方法分為黑盒和白盒兩種測試。黑盒測試有等價類劃分法、邊界分析法、因果圖法和錯誤猜測法；白盒測試有邏輯覆蓋法、循環(huán)測試路徑選擇、基本路徑測試。例子：在一次輸入多個條件的完整性查詢中，利用等價類劃分法則和邊界分析法則。首先利用等價類劃分法，可以劃分出一個或多個結(jié)果是“OK”的測試用例，多個結(jié)果是“NG”的測試用例，然后利用邊界值分析法，對結(jié)果分別是“OK”和“NG”的測試用例進行擴展和補充。

8.您認為做好測試用例設計工作的關(guān)鍵是什么？

【解析】測試用例設計工作的關(guān)鍵是對可行的和不可行的情況都要予以考慮。具體包括：①輸入；②詳細的操作步驟；③預期輸出；④實際輸出。

9.您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。

【解析】使用LoadRunner測試工具。該工具能夠錄制測試人員的操作步驟，然后對這個操作步驟模擬出多個用戶。具體步驟如下：

(1)?VirtualUserGenerator創(chuàng)建腳本，選擇協(xié)議，錄制操作，編輯操作。

(2)中央控制器(Controller)調(diào)度虛擬用戶，創(chuàng)建場景，選擇腳本，建立虛擬用戶，設計shedual，設置ipspoofer。

(3)運行腳本，分析shedual。

(4)分析測試結(jié)果。

10.您認為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？

【解析】性能測試工作的目的是檢查系統(tǒng)是否滿足需求說明書中規(guī)定的性能，性能測試常常需要和強度測試結(jié)合起來，要求同時進行軟件和硬件的檢測。性能測試主要的關(guān)注對象是響應時間、吞吐量、占用內(nèi)存大小(輔助存儲區(qū))、處理精度等。

11.在您以往的工作中，一條軟件缺陷(Bug)記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷記錄？

【解析】一條軟件缺陷記錄所包括的內(nèi)容有：檢測時間、系統(tǒng)環(huán)境、硬體環(huán)境、嚴重程度、程式版本、確認人、功能模塊、問題描述、詳細操作步驟及是否會重現(xiàn)等。問題描述和詳細操作步驟要盡可能的詳細。Bug應該盡量用書面語，對于嚴重程度比較高的缺陷要在相同環(huán)境下測試。在C/S模式下，如果條件滿足可以使用替換法來確認是Client端的問題還是Server端的問題。

12．你在測試中發(fā)現(xiàn)了一個Bug，但是開發(fā)經(jīng)理認為這不是一個Bug，你應該怎樣解決？

【解析】具體解決步驟如下：

(1)將問題提交到缺陷管理庫進行備案。

(2)獲取Bug判斷的依據(jù)和標準：

①根據(jù)需求說明書、產(chǎn)品說明、設計文檔等，確認實際結(jié)果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據(jù)；

②如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，以確認是否是缺陷；

③根據(jù)用戶的一般使用習慣，確認是否