軟件測試之捉蟲記-大容量Web應(yīng)用性能測試與LoadRunner實戰(zhàn)_第1頁
軟件測試之捉蟲記-大容量Web應(yīng)用性能測試與LoadRunner實戰(zhàn)_第2頁
軟件測試之捉蟲記-大容量Web應(yīng)用性能測試與LoadRunner實戰(zhàn)_第3頁
免費預(yù)覽已結(jié)束,剩余16頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、第 1章 什么是軟件測試由 安 博 測 試 空 間 技 術(shù) 中 心 :/btestingsky/ 提供在我國宋代,有一位叫宋慈的法醫(yī)學(xué)家寫了一本?洗冤集錄?。在書中,他講述了很 多斷案的經(jīng)驗,其中有一個用銀針驗毒的方法至今仍廣為流傳。比方在很多電視劇中,我 們能經(jīng)常看到皇帝在進膳的時候,由于害怕被人暗害,總要讓可憐的太監(jiān)或者宮女先用銀 筷子嘗上幾口飯菜,沒有出現(xiàn)問題再正式用餐。這種用銀針進行的試驗就可以說是一種測 試的雛形吧,銀針充當了測試工具,而太監(jiān)或者宮女就是古代的測試工程師。時光飛逝。隨著科技的開展,我們生活周圍有了越來越多的產(chǎn)品,它們在出廠銷售前 都要進行測試,不僅要保證功能完好,還要

2、確保對使用者的傷害在允許范圍內(nèi)。因此在工 廠里,逐漸出現(xiàn)了這樣一個部門,由它來負責(zé)檢驗產(chǎn)品,被稱之為質(zhì)量檢驗或者質(zhì)量保 證部。上個世紀中后期,軟件出現(xiàn)了,它作為人們?nèi)粘I钪刑焯於紩褂玫漠a(chǎn)品,同樣也 需要質(zhì)量的保證。有一種誤解:軟件的質(zhì)量問題并不那么重要,比方 Windows 等操作系 統(tǒng),各種桌面的應(yīng)用軟件,像 IE 瀏覽器,如果它出現(xiàn)了問題,程序會失去響應(yīng)甚至嚴重的 系統(tǒng)會藍屏,那么只需要在任務(wù)管理器中將它刪掉就可以了,最多重新啟動電腦,一般都 能夠繼續(xù)使用。這只是一方面,另一方面,有很多非常重要的軟件在我們看不見的地方默 默地運行著,如果它們出現(xiàn)了問題,影響就很大了。為了說明軟件質(zhì)量的

3、重要性,這里舉一個比擬著名的軟件質(zhì)量造成的事故。1962 年,美國的航海家 1 號 Mariner 1 火箭升空,由于控制火箭的軟件出現(xiàn)問題, 直接導(dǎo)致火箭升空后因偏離軌道而被迫引爆, 造成當時 1800 萬美元的損失。 事后查明, 是 程序員在編寫軟件代碼時,誤寫了其中一個公式的上標造成軌道計算失誤的。因此,軟件公司也需要質(zhì)量保證部門。我們把該部門的組成人員稱為QA工程師,QA即Quality Assuranee質(zhì)量保證的簡稱。軟件是否符合質(zhì)量是通過測試來驗證的,因此他們 也被稱為軟件測試工程師。在本書中您即將遇到的各種行為,絕大多數(shù)都將是軟件測試工 程師在工作中所要實現(xiàn)和完成的。1.1軟件

4、開發(fā)的根本知識對于每一位進入軟件測試行業(yè)的新人來講,公司的入職培訓(xùn)是一個很好的學(xué)習(xí)時機。1.1.1 軟件開發(fā)公司技術(shù)部門的根本結(jié)構(gòu)可將軟件測試部門類比于工廠車間的質(zhì)量保證部門,那么顯而易見,如果在工廠中要 做好質(zhì)量控制的工作,必須熟悉本廠生產(chǎn)的產(chǎn)品和流程。換句話來說,作為軟件生產(chǎn)的參 與者,了解被測試的軟件也是非常重要的一件事情。這也正是經(jīng)理要求小白在短期內(nèi)盡快 熟悉的內(nèi)容。【什么是軟件】中國大百科全書中對軟件的定義是:軟件是電腦系統(tǒng)中的程序和相關(guān)文件或文檔的總 稱。軟件是從英文 Software翻譯過來的名詞,與硬件Hardware丨相對應(yīng)。因此,軟件開發(fā)公司就是制造這些程序和相關(guān)文件或文檔

5、的商業(yè)機構(gòu)。一般來說,軟 件開發(fā)公司的技術(shù)部門由幾個子部門或者角色組成:開發(fā)部門、測試部門、部門經(jīng)理或者 工程經(jīng)理,另外有的公司還有技術(shù)支持部門。對應(yīng)于傳統(tǒng)行業(yè),分別相當于生產(chǎn)車間,質(zhì) 量控制部門,部門經(jīng)理和售后效勞部門。如表1-1列出了常見軟件開發(fā)公司技術(shù)部門的不同職責(zé)。表1-1常見軟件開發(fā)公司技術(shù)部門的角色分類部門職責(zé)軟件開發(fā)部門開發(fā)軟件:確定軟件實現(xiàn)方法,編寫軟件程序代碼軟件測試部門測試軟件:確定測試方法,編寫自動測試軟件的代碼,手工測試軟件,記錄并跟蹤軟件Bug技術(shù)總監(jiān)或工程經(jīng)理在所屬或其他部門之間溝通,協(xié)調(diào)工程或者開發(fā)測試進度,為成員提供各種資源技術(shù)支持部門軟件開發(fā)完成后在客戶處部署

6、產(chǎn)品,并解決與反響使用中岀現(xiàn)的問題Web應(yīng)用是一種特殊的軟件。那么開發(fā)Web應(yīng)用的網(wǎng)站與一般的軟件開發(fā)公司有什么不同呢?對于小白所處的商業(yè)網(wǎng)站來說,網(wǎng)站程序和相關(guān)文件或文檔也可以稱之為軟件,其技 術(shù)部門的結(jié)構(gòu)也和軟件開發(fā)公司根本類似,但是各部門日常工作的方式那么有所不同。商業(yè)網(wǎng)站每天都要有很多頁面的更新,每次更新后當時瀏覽網(wǎng)站的人立即可以看 至而軟件開發(fā)公司一般一年或者幾年推出一個產(chǎn)品,在產(chǎn)品沒有上市的時間內(nèi), 用戶只能使用舊的版本。也就是說網(wǎng)站軟件的變化要比軟件開發(fā)公司頻繁,網(wǎng)站 軟件的開發(fā)與用戶使用處于同一時間段內(nèi)。商業(yè)網(wǎng)站以效勞器為核心,網(wǎng)站軟件主要運行在效勞器上;而軟件開發(fā)公司的產(chǎn) 品

7、主要運行在用戶的電腦上?!狙莩獣c專輯】商業(yè)網(wǎng)站與軟件開發(fā)公司的運作模式有點類似于歌手開演唱會和發(fā)專輯的區(qū)別。在演 唱會上,歌手與觀眾的互動性更強,每一個細節(jié)的變化也都能被觀眾捕捉到;而歌手專輯 那么相當于軟件產(chǎn)品的某個版本,是提前制作完成之后再上市銷售的。1.1.2 軟件危機小白在熟悉了技術(shù)部門的大致結(jié)構(gòu),網(wǎng)站與軟件開發(fā)公司的區(qū)別之后,經(jīng)理開始介紹 和軟件測試相關(guān)的背景知識。軟件危機就是產(chǎn)生軟件測試這一職業(yè)的重要推動力之一。從20世紀50年代以來,軟件的規(guī)模越來越大,復(fù)雜性也越來越高,另外,在20世紀80年代,伴隨著電腦的普及和應(yīng)用需求的飛速增長,互聯(lián)網(wǎng)開始蓬勃興起。 現(xiàn)在,現(xiàn)代人的生活已經(jīng)

8、越來越依賴各種各樣的軟件,軟件不再是大學(xué)實驗室里科學(xué)家的工具,而成 為我們生活的一局部。從操作系統(tǒng),比方每一臺個人電腦所安裝的Windows XP或者Vista系統(tǒng),到小小的桌面程序 一個簡單的連連看小游戲,再到Google網(wǎng)站上可以編輯的在線文檔工具,軟件的開發(fā)、管理、維護的復(fù)雜性和高本錢現(xiàn)象也日益突出,在某一段時期,暴露了很多問題。因此在 20世紀,有人提出了 “軟件危機的說法,來說明這種現(xiàn)象?!拒浖?fù)雜性的類比】其實我們中國人是很容易理解軟件復(fù)雜性的。一些在人口少的國家不成為問題的問 題,放在十幾億人口的環(huán)境中,就會產(chǎn)生不大不小的麻煩,比方每年的春運需要火車 票的人是如此之多,而火車的座

9、位是固定數(shù)量的;需要回家的人的分布是如此之廣,而火 車站的位置也是固定的。依此類比,當軟件的代碼量越來越龐大,要滿足的需求越來越廣 泛時,出現(xiàn)局部的危機是很容易理解的。1.1.3 軟件危機的幾個表達隨著軟件越來越復(fù)雜,質(zhì)量越來越難于控制,于是出現(xiàn)了所謂“軟件危機。具體而 言,軟件危機有以下幾個表達。軟件需求的增長無法快速得到滿足。這一點在前文已經(jīng)有所講述。軟件生產(chǎn)本錢變高,價格越來越昂貴。軟件的代碼量增加,所投入的人工本錢, 也就是軟件開發(fā)相關(guān)人員的本錢也會增加,還要增加采用各種新技術(shù)的本錢等。 軟件生產(chǎn)進度難于控制。軟件的用戶需求不容易定義。這一點也很重要:目前絕大多數(shù)的軟件已經(jīng)不止?jié)M 足單

10、一的需求,因此用戶真正所需要的不一定能夠完美地實現(xiàn)。軟件質(zhì)量不容易保證。這一點也是由軟件復(fù)雜度的增加而增加。還是舉春運的例 子,如果火車上人人都有座位,那么每個人的心情都會很好;但如果到處擠滿了 人,每位旅客回家的心情總會受到影響,從而影響對列車效勞的評價。軟件質(zhì)量 和用戶的評價同樣是相關(guān)的:經(jīng)常造成死機、異常退出或者按鈕單擊后沒有反響 的軟件,很難說是質(zhì)量好的軟件。軟件可維護性變差。軟件同樣是需要維護的:一方面是對于用戶使用過程中的維 護,這一功能由客戶效勞或者技術(shù)支持部門來完成;另一方面是對于軟件本身代 碼和文件文檔的維護,這一功能由開發(fā)部門或者測試部門來完成。隨著軟件的日 益龐大,軟件本

11、身經(jīng)歷的修改越來越多,管理維護軟件的各種版本變得日益困難。由于軟件危機有這么多的影響和危害,所以促使人們靜下心來研究軟件開發(fā)過程中的 規(guī)律,這就產(chǎn)生了軟件生命周期的概念。1.1.4 軟件生命周期軟件生命周期,英文為Software Lifecycle,就是軟件開發(fā)、使用和消亡的過程,具體而言,包含軟件需求分析、軟件設(shè)計、軟件實現(xiàn)與測試和軟件發(fā)布、部署與維護這4個過程。在商業(yè)軟件開發(fā)公司內(nèi)部,人們往往遵循一定的軟件生命周期模型,這樣和被開發(fā)軟 件相關(guān)的所有人員都按照這個模型的標準或者步驟開展工作,統(tǒng)一行動,有助于提高生產(chǎn) 效率,從而減少溝通和實施的本錢,獲得更大的商業(yè)利益。而對于軟件生命周期的不

12、同理 解和劃分,就形成了不同的軟件生命周期模型。1.1.5 常見的軟件生命周期模型目前來講,主要的軟件生命周期模型有如下幾種。Big-Bang :大爆炸模型。Waterfall :瀑布模型。Spiral :螺旋模型。Code and Fix :邊做邊改模型。由于本書并不是以軟件工程為探討內(nèi)容,因此在這里只通過人們過河的類比來簡單介 紹一下前述這幾種軟件生命周期模型的特點。小學(xué)課本里有個寓言叫做“小馬過河,小馬在過河前遇到了不同的小動物,它們對 于河水深度的理解是不同的,會導(dǎo)致小馬過河時的不同選擇,參見圖1-1。假設(shè)把待開發(fā)的軟件產(chǎn)品比喻為小馬面前橫著的那條小河,那么開發(fā)軟件的過程也就是過河的過

13、程,那 么如何過河就會有不同的結(jié)果。圖1-1小馬過河:對河深度的理解影響過河的方法1.1.6 直接沖過河去的大爆炸模型大爆炸這個名稱來自于天體物理有關(guān)宇宙形成方式的一種理論:宇宙是在億萬年前的 大爆炸中誕生的。與此類似,軟件開發(fā)公司把金錢、辦公場地和人員全部投入到一個產(chǎn)品 的開發(fā)當中,經(jīng)過一段時間,產(chǎn)品出爐,這樣的形式就是大爆炸模型。大爆炸模型的優(yōu)點就是簡單,沒有很多的軟件設(shè)計,對工程的管理也很少,目前不少 小公司由于各方面的限制不得已或者不自覺地采用了這樣的開發(fā)模型。但是它的優(yōu)點也造 成了它的缺點:開發(fā)出來的軟件質(zhì)量不可控制。在這樣的模型中,由于沒有周密的方案,軟件測試往往是在產(chǎn)品即將上市的

14、前夕才開 始,在很多公司中甚至沒有專職的測試工程師,由開發(fā)人員或者其他人員代勞,因此測試 人員面對的產(chǎn)品與客戶、使用者要面對的產(chǎn)品根本一致。從前文所述可以得知,在這樣的 階段發(fā)現(xiàn)Bug,返工修改代碼的代價是非常大的?;氐竭^河的比喻中來,大爆炸模型就相當于小馬先退后幾步,集中精力和能量,然后 快速沖過去。這樣的結(jié)果取決于河的寬度和深度。如果軟件非常復(fù)雜,很可能過河的小馬 半途就淹死了,無法到達對岸。1.1.7 摸著石頭過河的邊做邊改模型邊做邊改模型比起大爆炸模型來說進了一步。在開發(fā)軟件產(chǎn)品的開始階段,先有一個 大概的設(shè)計,然后開始編碼,測試,發(fā)現(xiàn) Bug,修改Bug這樣的循環(huán),直到整個產(chǎn)品的輪

15、廓日漸清晰,最終完成產(chǎn)品。用一句俗話來描述,就是“摸著石頭過河的過程:先以河 里的一些石頭為支點,走入河道,再經(jīng)過不斷的試探和返回得到一條路線,最終到達目 的地。由此可見,邊做邊改模型中測試的參與要比大爆炸模型中要早得多,而且也重要得多。邊做邊改模型的優(yōu)點就是適用于某些中小型工程的快速開發(fā),軟件產(chǎn)品的成果也會在最早 的階段顯現(xiàn)出來:和在岸邊冥思苦想如何過河的人相比,先站在河道里的石頭上,總是讓 人看到更多的希望?!具呑鲞吀哪P捅惠^多采用】這種開發(fā)模型被大多數(shù)公司所采用,是大多數(shù)測試工程師在實際工作中最常遇到的開 發(fā)模型之一。而且,它和最近幾年很流行的敏捷開發(fā)也有一定的關(guān)系。1.1.8 制定周密

16、過河方案的瀑布模型從現(xiàn)在開始,下面的這兩個模型就不適合小馬了,只有人和外星人才有這樣的能力。 如圖1-2介紹了軟件開發(fā)的瀑布模型,由于圖中的箭頭好似瀑布的水流,從上至下,因此 得名。圖1-2瀑布模型示意圖回到過河的例子中來,瀑布模型過河具備如 下特點:過河前,首先花費大局部的時間對河進 行詳細的勘察,選擇適宜的下水點,選 擇適宜的過河工具,制定詳細的分步驟 過河方案。一旦過河方案制定,將不會大更改,開 始過河。在河中完全按照方案進行,無 法返回起點。這也是為什么稱此模型為 瀑布的原因,瀑布是飛流直下三千尺, 想從下面返回瀑布的頂端,何其難。在每步驟即將完成時,都會對這一步驟進行總結(jié),如果進行下

17、一步驟的條件不具 備,將停留在原地,等待條件具備。瀑布模型看起來給人很專業(yè)的感覺,所以,對于軟件開發(fā)人員有比擬高的要求。 要對待開發(fā)的軟件或者要過的河有細致、全面、準確的了解。如果理解錯誤, 將導(dǎo)致方案失敗,沒有返回重來的時機。職業(yè)素質(zhì)、職業(yè)紀律要比擬高。軟件開發(fā)人員要具備堅決執(zhí)行方案的能力。這種要求也就產(chǎn)生了瀑布模型的缺點,那就是無法完美適應(yīng)當今要求快速開發(fā)產(chǎn)品, 從而占領(lǐng)市場的軟件行業(yè)現(xiàn)狀。因為制定詳細的、理解完整的方案很難,聚合很多專業(yè)的 開發(fā)人員有時候也很難,而市場對于軟件更新?lián)Q代的要求期限越來越短。為了適應(yīng)變化, 人們又提出了螺旋模型。1.1.9 方案趕得上變化的螺旋模型前文提到,為

18、了適應(yīng)方案和變化兩方面的因素,螺旋模型被提出。螺旋模型的示意如 圖1-3所示??梢钥吹?,它確實很類似一個螺旋。與邊做邊改模型類似,螺旋模型也具有循序漸進的 特點,對軟件最終實現(xiàn)什么不一定有完全確定的理解, 而是摸著石頭先下水。但是在選擇過河的每一個石頭前 經(jīng)過了周密的方案和考慮,從這一點看,又類似瀑布模 型??梢?,螺旋模型實際上是邊做邊改模型和瀑布模型 的有機結(jié)合。螺旋模型有如下4個步驟。1確定工程目標、可用資源、各種實現(xiàn)的方法, 工程的各個階段。2在某個階段中,確認、解決當前階段工程進展 中出現(xiàn)的風(fēng)險。3評估各種方法,開發(fā)、測試代碼,實現(xiàn)當前階 段的目標。4總結(jié)當前階段,方案下階段的目標和實

19、現(xiàn)方法, 在圖1-3中螺旋線被兩條直線劃分成 4個局部,重復(fù)第2步。分別是上述的 4個步驟。在每一步驟中由于被直線切割會有多段曲線,每一段曲線就代表了在不同階段中所進行的相同某個 步驟?!韭菪P偷膬?yōu)點】由此可見,螺旋模型是屢次方案,邊做邊改,這樣既保證了軟件開發(fā)任務(wù)的清晰,也 降低了開始一次方案,因為理解不完整或者市場變化后導(dǎo)致工程失敗的可能性。1.1.10 4種模型的總結(jié)前文講述了 4種軟件開發(fā)模型,那么在具體工程開發(fā)中采取哪一種最好呢?答案是它 們各有利弊,需要靈活采用。這幾種開發(fā)流程的優(yōu)缺點比擬如表1-2所示。表1-24種軟件開發(fā)流程的優(yōu)缺點開發(fā)流程分類優(yōu)點缺點大爆炸模型簡單,不用學(xué)習(xí)

20、就會拍腦門的想法,產(chǎn)品質(zhì)量無法保證。盡量防止使用邊做邊改模型快速得到可運行的版本方案有些缺乏,導(dǎo)致版本前后變化較大??蛇x擇的模型之一瀑布模型方案周密,專業(yè),按部就班實現(xiàn)相對難于做到快速開發(fā),以搶占市場??蛇x擇的模型之一螺旋模型方案變化同時考慮可選擇的模型之一當然,在幾十年的軟件開發(fā)過程中,人們還提出了很多其他的開發(fā)模型,不過,作為 測試工程師,我們對這幾種主流模型有所了解就可以了。進一步深入的內(nèi)容并不是本書所 講述的范疇,讀者可以參看軟件工程的相關(guān)書籍。1.1.11 軟件幵發(fā)的幾個階段不管采用哪一種開發(fā)模型,按照時間順序,所有的軟件開發(fā)工程都要經(jīng)歷如下4個階段。1工程啟動階段:了解客戶需求、配

21、置相關(guān)資源。2工程設(shè)計階段:明確客戶需求,確立軟件開發(fā)、測試的方法。3工程執(zhí)行階段:開發(fā)與測試階段。4工程竣工階段:軟件的上市、后期維護與技術(shù)支持。這一分類很好理解,下面再結(jié)合小白的工作場景,進行展開介紹。1工程啟動階段。這一階段一般技術(shù)人員參與較少,主要是市場部門,銷售部門, 技術(shù)總監(jiān)、工程經(jīng)理等角色的參與:工程本錢是多大,開發(fā)人員有多少,測試人員有多少,完成時間在什么時候等。2工程設(shè)計階段。這一階段主要參與者就是需求分析人員、開發(fā)人員、工程經(jīng)理和 小白這樣的測試人員了。主要目的是確定軟件該如何做,做什么:開發(fā)人員利用何種技術(shù) 開發(fā),測試工程師該如何測試該軟件,客戶如何使用該軟件等。這些問題

22、都要確定,形成 各自的開發(fā)文檔、測試文檔和需求文檔等。3工程執(zhí)行階段。開發(fā)、測試以及對其的管理就是執(zhí)行,這一階段的參與者是開發(fā) 人員、測試人員和工程經(jīng)理。開發(fā)人員編寫程序代碼,進行單元測試;測試人員編寫測試 代碼、測試用例,進行功能測試等多種測試。工程經(jīng)理控制進度,協(xié)調(diào)各種資源,與設(shè)計 人員溝通等。4工程竣工階段。當工程執(zhí)行完畢的時候,依然要進行部署、軟件光盤生產(chǎn)、客戶 支持、升級補丁包開發(fā)和測試等多項工作。這階段主要的參與者是工程經(jīng)理,少量的開發(fā) 人員和測試人員,售后技術(shù)支持人員、客戶效勞人員等。1.1.12 軟件發(fā)布的方式按照目前的軟件發(fā)布方式,一般有RTM Ready To Market

23、,市場發(fā)布、RTW ReadyTo Web,在網(wǎng)絡(luò)上發(fā)布、RTO Ready To Operation,可以運營等多種方式。RTM方式需要在工廠進行光盤的復(fù)制生產(chǎn),用戶購置光盤后安裝。大局部的操作 系統(tǒng)和應(yīng)用軟件采用這種方式的比擬多。RTW方式需要在網(wǎng)絡(luò)上提供下載鏈接,一般的軟件升級包或者游戲軟件采用這種方式的比擬多。RTO方式那么很簡單,在效勞器上部署軟件產(chǎn)品,用戶購置其中的某項或者多項服 務(wù)即可,這是大局部網(wǎng)站或者在線游戲采用的方式。1.1.13 工程管理與甘特圖前面提到軟件工程的流程很重要,那么這種流程的控制一般是由工程經(jīng)理來完成的, 他或者她所從事的這個工作叫做工程管理。小白所在的技術(shù)

24、部門一般一周都要開一個例會,在會上,開發(fā)部門、測試部門和工程 經(jīng)理都要對上一周各自所做的工作進行一番總結(jié),安排下周將要做的工作。在這樣的例會 上,同事們經(jīng)常會查看工程的進度圖來進行講解,他們把這樣的進度圖稱為甘特圖Ga nttChart。如圖1-4顯示的是軟件開發(fā)過程中常用的工程管理工具Microsoft Office Project軟件在這里是2003版本,最新為2007版本運行的界面,在其中我們可以清楚地看到軟件生 命周期中的各個子任務(wù)的時間分配,負責(zé)人員和工程進度的甘特圖。圖1-4 Project 2003中的甘特圖【甘特圖的來歷】甘特圖的名稱由創(chuàng)造者亨利勞倫斯甘特Henry Laure

25、nee Gantt , 1861 1919而來。甘特早年從事的是電氣工程師的職業(yè),后來轉(zhuǎn)而從事管理業(yè)界的咨詢。甘特圖是他在 晚年創(chuàng)造的一種用于顯示工程方案和進度的圖表。在誕生的初期,甘特圖就被譽為 20世紀20年代的最重要創(chuàng)造之一,廣泛應(yīng)用于一系列的大工程之中。比方1931年前后修建的美國胡佛水壩如果你看過2007年的熱門電影?變形金剛?,那么對關(guān)押威震天的那個水壩 應(yīng)該有印象,它就是胡佛水壩。在軟件開發(fā)領(lǐng)域,很多公司也應(yīng)用甘特圖這一工具來進 行工程管理,比方著名的微軟公司。1.2 關(guān)于蟲子的故事在熟悉了公司的結(jié)構(gòu)、開發(fā)流程,參與了部門例會之后,小白要開始從事具體的軟件 測試工作了,對于他來說

26、,這一領(lǐng)域陌生而令人興奮。在剛上班的一周內(nèi),小白不斷地聽到周圍的測試工程師快樂得喊道:“又發(fā)現(xiàn)Bug 了!看著他們那興奮的樣子,小白也有點躍躍欲試,想趕緊在捉蟲的戰(zhàn)場上大展身手。那么, 什么是Bug呢,它為什么這么重要,發(fā)現(xiàn)Bug為什么這樣興奮?1.2.1 蟲子的來世今生在本章的序幕局部,我們已經(jīng)了解了很多由于軟件代碼的問題使得事情失敗的案例 了。它們有的后果真的很嚴重,甚至能夠造成對生命的威脅。這肯定不是軟件設(shè)計者和開 發(fā)者想要到達的目標,因此,出現(xiàn)這樣的情況可以說是軟件的錯誤。細細的分起來,軟件的錯誤有如下幾個詞語來描述:缺陷、偏差、錯誤、問題、事故、異常。在這一堆詞語當中,除了偏差之外,

27、其他的 詞語所造成的后果給人的感覺都相當嚴重。所謂偏差,就是軟件在使用過程中,和軟件設(shè) 計說明product specification丨所不一致的行為。那么為什么將這樣的軟件問題稱為Bug呢?這里面還有一個故事?!臼飞系谝粋€軟件 Bug】該詞的原意是“臭蟲或“蟲子。1947年9月9日,正值電腦剛剛被創(chuàng)造的時候,哈佛大學(xué)的某個電腦實驗室正在做實驗。由于當時的原始電腦由很多龐大且昂貴的真空管 組成,運行時會產(chǎn)生光和熱,在下午15點45分的時候,一個飛蛾英文是Moth鉆入了真空管內(nèi),導(dǎo)致整個電腦無法工作。當把這只小蟲子從真空管中取出后,電腦又恢復(fù)正常。后來,蟲子的泛稱 Bug這個名詞就沿用下來,而

28、那個被拍死的飛蛾也成為了歷史上發(fā)現(xiàn)的 第一個Bug?!綛ug滲透到日常生活中】一般來說,擁有一定知識產(chǎn)權(quán)的產(chǎn)品的錯誤都能稱之為Bug。這方面有一個我們比擬熟悉的例子就是電影。影迷們經(jīng)常議論某熱門電影中出現(xiàn)了所謂的“穿幫鏡頭,比方在 描述古代武俠的影片中天空掠過一架飛機,主角剛剛是右臉有傷痕,過一會變成左臉等。這樣的鏡頭也可以說是Bug,甚至還有專門的網(wǎng)站來記錄這些影迷的細心發(fā)現(xiàn),比方:chin abug .n et。1.2.2 軟件Bug的5個要素前文籠統(tǒng)解釋了軟件Bug是軟件的錯誤或者偏差。那么在具體的工作中,小白如何判斷軟件的行為是Bug呢?說來簡單,根據(jù)軟件設(shè)計階段形成的功能說明書,英文

29、為Specification Document,一般簡稱 Spec。對于具體的判斷標準,經(jīng)理介紹了如下 5個要素:軟件沒有實現(xiàn)說明書中所列出的功能。軟件出現(xiàn)了說明書中提到不應(yīng)出現(xiàn)的事情。軟件實現(xiàn)了說明書中沒有提到的功能。軟件沒有實現(xiàn)說明書中沒有提到但應(yīng)該實現(xiàn)的功能。軟件非常難于學(xué)習(xí)、使用,運轉(zhuǎn)速度很慢,用戶認為無法到達預(yù)期。為了充分理解上述 5個要素,小白自己翻開了Windows系統(tǒng)中最簡單的一款軟件Notepad,也就是我們平時“不屑于用到的記事本程序,開始了自己的思考。1 軟件沒有實現(xiàn)說明書中所列出的功能對于“軟件沒有實現(xiàn)說明書中所列出的功能是Bug 這一點是比擬好理解的。如果打 開記事本

30、軟件,卻無法在其中輸入漢字,或者輸入了文本,無法保存成文件,那么肯定是 一個很重要的Bug。2 軟件出現(xiàn)了說明書中提到不應(yīng)出現(xiàn)的事情對于第2點,“軟件出現(xiàn)了說明書中提到不應(yīng)出現(xiàn)的事情也是Bug,這一點和小白的性能測試工作有相對更緊密的關(guān)系。小白要測試的是公司的網(wǎng)站,它要求用戶在瀏覽網(wǎng) 站時顯示頁面盡可能地快,如果超出5秒鐘那么認為是不可接受的。這個“超出5秒鐘就是說明書中提到不應(yīng)該出現(xiàn)的事情,實際出現(xiàn)后肯定是一個Bug,需要開發(fā)人員找出哪里消耗了頁面顯示時間。在記事本程序中,如果程序保存文件時出現(xiàn)了程序崩潰Crash現(xiàn)象,即屬于此類。3 軟件實現(xiàn)了說明書中沒有提到的功能軟件實現(xiàn)了說明書中沒有提

31、到的功能也是Bug這一點可能有點難于理解。一個軟件,功能難道不是越多越強大嗎?其實不盡然,實現(xiàn)額外的功能有如下幾個缺點,如表1-3所示。表1-3軟件實現(xiàn)說明書中未提到功能所帶來的問題缺點說明代碼量增大由于代碼可能相互影響,因此這局部額外的功能可能對其他 功能的實現(xiàn)造成影響,帶入新的Bug增加額外的開發(fā)、測試時間在軟件工程時間固定的情況下,導(dǎo)致投入到其他必備功能的 開發(fā)測試時間減少,可能影響它們的完成質(zhì)量增加了本錢,與軟件的宣傳不完全符合雖然用戶對于增加功能一般不會有意見,但可能影響了公司 的銷售策略和市場定位4 軟件沒有實現(xiàn)說明書中沒有提到但應(yīng)該實現(xiàn)的功能小白一般是將網(wǎng)上找到的有用文檔保存在隨

32、身攜帶的U盤中。這一次,他在測試記事本程序的時候,同樣打算將文件保存在U盤上,可是由于連日來的文檔太多了,優(yōu)盤已經(jīng)沒有空間,記事本提示無法保存,同時系統(tǒng)托盤有提示說磁盤空間已滿。在這種情況下記 事本的行為,就屬于實現(xiàn)了說明書中沒有提到卻應(yīng)該實現(xiàn)的功能在磁盤滿的情況下,給 用戶以提示。如果沒有提示,不符合絕大局部用戶的使用習(xí)慣,也是一個Bug。5.軟件難于使用、性能差軟件是拿來用的,再好的界面使用不方便也不會產(chǎn)生多大效果。一個網(wǎng)站如果半天都 打不開,很難想象還會有多少用戶會訪問它。因此這樣的問題也是Bug,而且對于性能測試來說,這一個規(guī)那么很重要。1.2.3 發(fā)現(xiàn)蟲子的危害既然軟件Bug對產(chǎn)品造

33、成了這么多的影響,那么發(fā)現(xiàn)它就顯得非常重要了。業(yè)內(nèi)人士都認為,在軟件生命周期內(nèi)的不同階段發(fā)現(xiàn)Bug,所節(jié)省的本錢是不同的,如圖1-5所示。圖1-5軟件生命周期內(nèi)各階段發(fā)現(xiàn)與改正Bug所需本錢示意圖從圖中可以看出,在產(chǎn)品設(shè)計階段發(fā)現(xiàn)Bug要比在產(chǎn)品維護階段發(fā)現(xiàn)好得多,這是很好理解的。在需求分析階段,對于用戶需求的理解停留在需求文檔中,對其中理解不正確的 局部只需要修改文檔即可以,根本不會產(chǎn)生什么本錢。在軟件設(shè)計階段,發(fā)現(xiàn)的Bug很多都是設(shè)計思想的缺陷。由于尚未開始編碼,這樣的Bug 一般需要進行深入的討論最終獲得一種正確的結(jié)論,因此改正本錢也 不咼。在軟件編碼階段和測試階段,代碼通過開發(fā)人員和測

34、試人員的努力在進行不斷的 完善,有關(guān)Bug的本錢主要花費在工程內(nèi)部的溝通與時間本錢方面。但是一旦產(chǎn)品發(fā)布,在軟件維護階段發(fā)現(xiàn)的Bug,其修改本錢會非常高昂:一是因為軟件成為了系統(tǒng),與開發(fā)階段重點檢查各模塊功能相比更為復(fù)雜,尋找代碼 上的產(chǎn)生Bug根源更加困難。特別是,如果前期工作沒有做好的話,甚至軟件產(chǎn) 品的結(jié)構(gòu)都需要進行大修改;二是因為牽扯的部門明顯增加,比方客戶效勞部門、 產(chǎn)品部署部門、銷售部門等都要參與,導(dǎo)致公司內(nèi)部、公司與客戶之間的溝通成 本急劇增加;第三點那么是影響產(chǎn)品質(zhì)量與公司的信譽、未來產(chǎn)品的銷售?!厩晗x的問題】在前幾年,有一個著名的蟲子把業(yè)內(nèi)攪得不可開交,那就是千年蟲問題,也

35、叫做2000年問題。它是指在某些使用了電腦程序的智能系統(tǒng)比方一般的電腦系統(tǒng)以及自動控制芯 片等中,由于其中的年份沿用早期的設(shè)計,只使用2位十進制數(shù)來表示, 比方用80代表1980年,因此當系統(tǒng)進行或者涉及到跨世紀的日期處理運算 比方計算1980年到2080 年之間的日期時,就會出現(xiàn)錯誤的結(jié)果,從而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至系統(tǒng)崩 潰。從千年蟲的實際例子中也可以看出,不考慮硬件上的限制,如果當初在設(shè)計日期表示 格式的時候能夠想得更長遠一些,就完全可以防止這個蟲子的發(fā)作,從而節(jié)省一大筆修改 更新軟件等的費用據(jù)未經(jīng)證實的來自美國國際資料公司調(diào)查報告說明,光是1995年到1998年,全球捉“千年蟲

36、的開銷就已經(jīng)到達驚人的1840億美元。1.3軟件測試的定義與分類前文花費了不少文字來講述Bug的定義、危害和判斷原那么,本節(jié)將在更廣的范圍內(nèi)介紹軟件測試的定義與分類。1.3.1 軟件測試的定義軟件測試就是利用一定的方法對軟件的質(zhì)量或者使用性進行判斷和評估的過程。這一 定義獲得了較廣泛的認同。1.3.2 軟件測試工程師的工作內(nèi)容軟件測試是由軟件測試工程師來完成的,他們的主要工作內(nèi)容那么是: 尋找軟件中的Bug,并且是越早發(fā)現(xiàn)越好原因見節(jié)。 確認Bug的可重復(fù)性Repro以及Bug產(chǎn)生的步驟。 確認Bug是否被解決Fixed。測試方法、測試方案、測試平臺、測試代碼、測試用例、測試文檔、測試報告確

37、實定、編寫和執(zhí)行。對于小白這樣剛?cè)肼毜男氯藖碚f,主要工作就是前3項以及測試用例的編寫了。在節(jié)將講述測試用例的知識。1.3.3 軟件測試的分類軟件測試可以有很多種分類,常見的有如下一些:黑盒測試Black box testing;白盒測試White box testing;功能性測試Functional testing 丨;兼容性測試Compatibility testing 丨;性能測試Performanee testing 丨;平安測試Security testing;壓力測試Stress testing。雖然看起來很多很復(fù)雜,但是目前,小白所要做的工作就是先熟悉這些名詞,這樣在 閱讀眾多的

38、技術(shù)文檔時,了解這些名詞屬于軟件測試的范疇就可以了。對于軟件測試的兩個核心,那么有必要在第1章詳細的介紹。這兩個核心分別是測試用例和測試工程師,分別代表了軟件測試的兩個方面:工具和人。1.4軟件測試的核心I :測試用例前文提到,測試用例代表了軟件測試的工具方面,是它的核心之一。那么什么是測試 用例,它又有哪些要點需要我們?nèi)フ莆眨?.4.1 什么是測試用例軟件測試的核心行為就是針對要測試的軟件設(shè)置測試用例。所謂測試用例,英文名為Test Case,是一個與程序局部行為以及輸入、輸出相關(guān)的描述或者標識。 【測試用例的IEEE定義】美國電氣與電子工程 師協(xié)會IEEE, The In stitute

39、of Electrical and Electro nicsEngineers,它出臺了一個標準的測試用例定義,即“測試用例是描述輸入實際值和預(yù)期 輸出行為或者結(jié)果的文檔,它同時也標識了測試過程結(jié)果與約束。 在實際工作中,花費測試工程師大局部時間的,都是與測試用例相關(guān)的。1.4.2 測試用例的幾大要素一般來說,測試用例應(yīng)該清楚地描述出對被測試軟件發(fā)出什么數(shù)據(jù)或者條件,以及該 輸入所期望的結(jié)果。在小白這樣的商業(yè)網(wǎng)站,測試部門規(guī)定測試用例應(yīng)該具備如下幾個 要素。1 標識符這一點雖然和測試用例的內(nèi)容沒有關(guān)系,但卻是測試過程中不可缺少的。比方,小白 所在的部門每周都要開一次例會,向經(jīng)理或者開發(fā)部門的同

40、事說明當前整個產(chǎn)品的測試狀 態(tài),有時候需要特別指出某個測試用例的內(nèi)容,那么用一個簡單的代號來代表這一測試用 例是非常適合的,這個代號一般情況下都是一個正整數(shù),比方1、88、437等這樣。在小白所在的公司,測試用例是存放在一個數(shù)據(jù)庫中的,代號也就自然地采用了數(shù)據(jù)庫系統(tǒng)中的 標識符字段類型。如果采用其他的方式存儲測試用例,可以人工指定,只要保證標識符不 重復(fù)就可以了。如圖1-6顯示了應(yīng)用于真實測試場景的某測試用例文檔,它實際上是一個 Office Word文件,測試工程師即編寫者在文件內(nèi)容中手工指定了各個測試用例的標識符。圖1-6 測試用例的標識符2 .測試的內(nèi)容測試內(nèi)容可以說是測試用例最重要的局

41、部,它一般指明了當前測試用例的運行目的, 比方測試網(wǎng)頁是否可以翻開、單擊按鈕后是否能夠顯示正確的計算結(jié)果等。在很多情況下,測試內(nèi)容與下個要點:輸入的條件區(qū)別并不是很清楚。3 .輸入的條件輸入條件可以是操作步驟,也可以是輸入的數(shù)據(jù),還可以是系統(tǒng)運行環(huán)境的需求比 方處于某種特別的操作系統(tǒng)環(huán)境內(nèi)這一條件。圖1-6中的各個測試用例,都詳細地寫明了每一步驟的具體操作。【復(fù)現(xiàn)步驟】對于被測試軟件而言,不同的輸入條件會導(dǎo)致不同的輸出預(yù)期,因而可能出現(xiàn)的Bug表現(xiàn)并不一定相同。如果重復(fù)某些輸入條件,總會導(dǎo)致某個Bug的出現(xiàn),那么就把這些輸入條件稱為Bug的復(fù)現(xiàn)步驟Repro Step。4 輸出的預(yù)期該項信息描

42、述了在當前的輸入條件下,預(yù)期的輸出。比方計算器程序中十進制數(shù)字的2+3的輸出應(yīng)該等于 5。假設(shè)輸出預(yù)期與實際結(jié)果不同,那么應(yīng)該考慮為Bug的可能性有的時候,輸出預(yù)期也會隨工程的進度而變化,因此預(yù)期與實際不同并不意味著100%是Bug ,此時需要與工程經(jīng)理等相關(guān)人員進行協(xié)商。5.測試環(huán)境信息這一局部的內(nèi)容描述了該測試用例所適用的環(huán)境,比方操作系統(tǒng)的版本,所依賴硬件 軟件的版本、語言等。測試環(huán)境信息有時候也可以成為輸入條件或者復(fù)現(xiàn)步驟的一局部, 比方某個按鈕只有在IE瀏覽器中才會出現(xiàn)、 某個Bug只在IE瀏覽器中才會產(chǎn)生,那么IE既是測試環(huán)境信息,也是輸入條件和復(fù)現(xiàn)步驟。6與其他測試用例的依賴關(guān)系

43、在測試某些軟件的時候,比方MSN,如果登錄這個測試用例都無法通過,那么剩下的發(fā)消息,發(fā)文件等測試用例也肯定繼續(xù)進行除去直接調(diào)用接口的那些測試之外,這就 是一種測試用例之間的依賴關(guān)系。合理地應(yīng)用測試用例之間的依賴關(guān)系,能夠提高測試效 率,減少無謂的測試時間浪費。7 測試用例需要被開發(fā)、審閱、使用、維護和保存這也是測試工作很重要的一局部。軟件的說明書Spec可能會變化,因此測試用例需要變化,這就要求對測試用例進行增加、修改和刪除。測試用例是文檔,需要有固定的場所 進行保存,一般是數(shù)據(jù)庫或者文件。測試用例需要審閱,以到達預(yù)期的效果和更高的工作 效率重復(fù)的測試用例肯定會浪費測試工程師的時間。1.5軟件

44、測試的核心II :測試工程師除了測試用例之外,軟件測試的另一個核心,同時也更為關(guān)鍵,就是測試工程師了。 這是因為,測試用例也是由測試工程師來編寫的,受人的因素影響很大??梢哉f,人是決 定軟件成敗的主要因素。本節(jié)將介紹測試工程師所必備的一些素質(zhì)。1.5.1測試工程師與軟件質(zhì)量保障有的時候我們在招聘廣告上能夠發(fā)現(xiàn)有些公司招聘測試人員的時候,列出的職位名稱 是軟件質(zhì)量保障工程師QA,quality assuranee,那么這兩種稱呼是否是代表同一種工作 內(nèi)容呢?答復(fù)是根本一樣,但有細微不同。軟件測試工程師的主要職責(zé)在于發(fā)現(xiàn)并確認Bug的解決與否,而軟件質(zhì)量保障工程師那么更進一步,在測試工程師的職責(zé)之

45、外,還包括創(chuàng)立、 維護為保障軟件質(zhì)量而確立的標準、規(guī)那么與流程,比方軟件配置管理Software Con figurationManagement,又稱SCM工程師等。【字面意義的理解】從字面意義上來看,測試工程師主要針對軟件的已有Bug,類似體檢部門;而軟件質(zhì)量保障工程師那么不光針對已有Bug,還對預(yù)防Bug的產(chǎn)生提出建議,類似健康參謀。當然,在實際工作中,兩者的區(qū)別并不是那么清晰的,在很多公司內(nèi)部,他們所從事的工作內(nèi)容 是完全一致的。1.5.2 測試工程師應(yīng)該具備的素質(zhì)一個合格的測試工程師,應(yīng)該具備如下專業(yè)素質(zhì):具備根本的數(shù)據(jù)結(jié)構(gòu),操作系統(tǒng)等專業(yè)知識。這一點對于從事性能測試的人員來說更為重

46、要。具備一定的程序開發(fā)經(jīng)驗。掌握一到兩門語言對于進行自動測試是大有益處的, 另外,具有程序開發(fā)經(jīng)驗,也更容易理解軟件Bug的來龍去脈。這一到兩門語言可以是某些高級語言,比方C#和VB.net,以及一種腳本語言,比方JavaScript、VBScript或者Python等的組合。軟件使用經(jīng)驗豐富,對于軟件的不正常行為敏感。這一點對于發(fā)現(xiàn)Bug是很有幫助的。同時,測試工程師還應(yīng)該具備如下的性格特征。有好奇心,樂于探索軟件功能,樂于嘗試新的軟件產(chǎn)品。樂于探索謎題,追根溯源。對于一個Bug,必須有追根溯源的精神,才能夠發(fā)現(xiàn)它的特點,這個性格特征在判斷Bug的產(chǎn)生原因,以及是否與其他Bug重復(fù)等日常的工作內(nèi)容中都會展現(xiàn)。有耐心,不輕言放棄。測試工程師在工作中經(jīng)常會試圖復(fù)現(xiàn)一個軟件中的Bug,這需要細心、耐心和堅持。必須具

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論