第一篇：軟件測試失效案例簡介

http://book.51cto.com/art/200909/151890.htm

失效案例簡介

軟件出現(xiàn)的問題有多種形式，會產(chǎn)生各種各樣的后果。下面是一些例子。

受醫(yī)用線性加速器的過度輻射，造成6人嚴重燒傷或死亡。經(jīng)查，管理加速器的軟件包含了一系列程序錯誤，由于軟件結(jié)構(gòu)極差，錯誤再現(xiàn)困難，也使得機器生產(chǎn)者不愿意收回機器。

火星氣候軌道航天器撞到了火星的表面。調(diào)查表明，由于測試不充分，沒有發(fā)現(xiàn)程序中的一個簡單的量綱轉(zhuǎn)換錯誤。

幾架“黑鷹”直升機撞毀，多人罹難。調(diào)查表明，災(zāi)難原因是無線電信號與機載計算機系統(tǒng)相互干擾。

稱做CONFIRM的旅游預(yù)訂系統(tǒng)在經(jīng)過1.25億美元的投資后流產(chǎn)。

F22戰(zhàn)機的一個軟件故障（邊界值測試的漏洞）。2007年2月，美軍F22戰(zhàn)斗機從夏威夷飛往日本，途徑日期變更線（東經(jīng)180度，西經(jīng)0度）時，軟件缺陷爆發(fā)，飛機上的全球定位系統(tǒng)失靈，電腦系統(tǒng)崩潰。飛行員無法確定戰(zhàn)機的位置，返回夏威夷的?？房哲娀?。洛·馬丁公司對軟件進行了維護，48小時后提供了新的軟件版本。

2007年北京機場信息系統(tǒng)癱瘓。2007年10月10日13時28分，設(shè)在北京首都國際機場的中國民航信息網(wǎng)絡(luò)股份公司離港系統(tǒng)突然發(fā)生故障，短短50分鐘內(nèi)，北京、廣州、深圳、長沙機場至少84個離港航班發(fā)生延誤，受其影響的城市包括上海、長春、南京、南寧、溫州、成都、鄭州、太原、呼和浩特、重慶、蘭州、香港、東京等。該系統(tǒng)是由美國某家公司研發(fā)，此事件引發(fā)信息系統(tǒng)安全的擔憂。

2008北京奧運會售票系統(tǒng)于2007年10月30日上午11時癱瘓：北京奧運會的指定獨家票務(wù)供應(yīng)商-北京歌華特瑪捷票務(wù)有限公司成立于2006年9月，由美國特瑪捷公司、中體產(chǎn)業(yè)股份有限公司及北京歌華文化發(fā)展集團三家出資構(gòu)建而成。售票系統(tǒng)癱瘓事件發(fā)生后，公眾普遍質(zhì)疑歌華特瑪捷公司是否具備承擔2008北京奧運會的票務(wù)銷售能力。

用戶常常在軟件開發(fā)初期就發(fā)現(xiàn)軟件不是他們所期待的。在開發(fā)軟件之前，需要進行必要的需求分析。充分的需求分析要求軟件開發(fā)人員與用戶進行良好的溝通，充分理解用戶需求才能開發(fā)出更有用的產(chǎn)品。雖然這些軟件故障的后果程度不一，但可以肯定的是，通過嚴格的軟件工程可以極大地降低故障及因此而引發(fā)的種種惡果。

1.6.2失效原因

軟件失效主要是由于開發(fā)組織沒有采用好的軟件工程方法。盡管軟件開發(fā)人員知道不好的軟件開發(fā)可能造成可怕的后果，但為什么大家還不能廣泛采用軟件工程的方法呢？原因是管理和開發(fā)隊伍對軟件工程早期的重要性的認識嚴重不足，認為代碼的行數(shù)是項目進展的唯一尺度，任何與生成代碼無關(guān)的事情都不是進展，因而也不值得花費時間和資源。

引起軟件失效的原因包括：

1)軟件復(fù)雜度；

2)非線性（多線程）軟件；

3)對意外的輸入或條件估計不足；

4)與外設(shè)接口動作異常；

5)硬件或操作系統(tǒng)與軟件不兼容；

6)管理不善；

7)測試不充分；

8)粗心大意；

9)想走捷徑；

10)不向管理部門通報問題；

11)風險分析不充分；

12)數(shù)據(jù)輸入錯誤；

13)錯誤的輸出解釋；

14)對軟件過于自信；

15)缺乏生產(chǎn)高質(zhì)量軟件的市場或法律壓力。

以上是引起軟件失效的原因列表，對我們很有幫助，我們應(yīng)該謹記?？紤]的潛在軟件失效原因越多，系統(tǒng)就越不易出現(xiàn)失效。例如，如果完全按照一種軟件工程方法學(xué)來開發(fā)軟件，假設(shè)用戶是未經(jīng)過充分訓(xùn)練的，那么就應(yīng)考慮可能會出現(xiàn)數(shù)據(jù)完整性錯誤，否則，系統(tǒng)可能是沒什么用的。

下面來看幾個實際的軟件開發(fā)中的災(zāi)難故事，目的是讓你充分理解軟件開發(fā)中和諧工作方式的重要性，不論你是初學(xué)者還是計算機專家，均能獲益。這些故事也可以讓你為爭取在你的工作環(huán)境下采用好的軟件工程方法提供有力證據(jù)。

1.6.3 CONFIRM

CONFIRM是一個雄心勃勃的軟件開發(fā)計劃，它的目標是集成飛機訂票、汽車出租和旅館預(yù)訂以及相關(guān)的決策支持機制為一體。它是由美國航空公司的子公司AMRIS提出的，項目開發(fā)了3年半，耗資1.25億美元，結(jié)果生產(chǎn)了一個無用的系統(tǒng)。

CONFIRM的慘敗雖然沒有危及任何人的生命，但是如此巨大的經(jīng)濟損失最后都轉(zhuǎn)嫁到了消費者身上。通過這種高的消費代價，大眾覺察到如此災(zāi)難性軟件開發(fā)的后果。為了更好地評估避免如此巨大經(jīng)濟損失而應(yīng)采取的各種策略，將有關(guān)的大事列表如下：

1)1987年10月，Marriott,Hilton,Budget Rent-a-Car和AMRIS成立聯(lián)盟，決定開發(fā)和運營CONFIRM，并讓AMRIS管理開發(fā)。項目計劃分兩個階段，計劃于1992年6月完工。

2)1988年5月24日，AMRIS發(fā)布新聞，宣布CONFIRM設(shè)計階段開始。

3)1988年12月30日，AMRIS向聯(lián)盟呈報了系統(tǒng)基礎(chǔ)設(shè)計，Marriott認為系統(tǒng)的功能規(guī)約還不夠充分，用戶需求還不夠細，開發(fā)人員還不能據(jù)此進行開發(fā)。

4)1989年3月，AMRIS呈報一份開發(fā)計劃，結(jié)果也未被聯(lián)盟成員們接受。

5)1989年8月，AMRIS向聯(lián)盟成員提交了項目經(jīng)費預(yù)算。基于這一預(yù)算，其他成員決定繼續(xù)維持該項目。后來的事實表明，這一預(yù)算對人員和操作成本的估計存在嚴重不足。

6)1989年9月，AMRIS終于完成了一個令聯(lián)盟滿意的設(shè)計，同時預(yù)算也增長至7260萬美元。

7)1990年1月，AMRIS未能按第一合同期限完成終端屏幕的設(shè)計。

8)1990年2月，第二個項目里程碑即系統(tǒng)商務(wù)領(lǐng)域分析也未能如期完成。AMRIS承認有13周的滯后，但仍聲明系統(tǒng)可以在原定的期限完成。

9)1991年2月，AMRIS向聯(lián)盟成員提交了一份修改過的開發(fā)計劃，要到1993年3月為Marriott提供完整功能的系統(tǒng)。后來Marriott聲稱其實AMRIS知道它不可能在新的期限內(nèi)完成系統(tǒng)，但還是強迫雇員人為地延長工作時間表，否則會遭到解雇或重新調(diào)遣。AMRIS也在修改的開發(fā)計劃中提高了開發(fā)的價錢，升至9200萬美元。

10)1991年10月，AMRIS總裁以及20余名雇員辭職。

11)1992年5月1日，AMRIS的新總裁認可“系統(tǒng)接口和數(shù)據(jù)庫不足以提供必要的性能和可靠性”，他還將這種狀況歸究于AMRIS對項目狀態(tài)的錯誤認識。

12)最后，于1992年7月，聯(lián)盟在花費了1.25億美元后，不堪重負，終于解散。

大量的報刊對CONFIRM項目的無能的管理和技術(shù)上的幼稚等進行了無情的嘲諷。不過我們關(guān)心的是，如何利用適當?shù)能浖こ谭椒▉肀苊膺@種災(zāi)難。雖然這個例子涉及一個重要的職業(yè)道德問題，但首先還是讓我們來分析軟件失效的根源。

很明顯，AMRIS關(guān)于項目狀態(tài)的管理是有問題的。項目是如何發(fā)展到管理部門被迫掩蓋真相的呢其實在項目的早期就有一些不好的征兆，AMRIS是不能開發(fā)一個可行的產(chǎn)品的；第二個征兆是，經(jīng)過7個月的努力后，AMRIS提交的設(shè)計文檔技術(shù)上是不能令人滿意的。這樣的一個設(shè)計意味著AMRIS沒有能力正確估計自己設(shè)計的質(zhì)量。另外，AMRIS的行動表明它并不重視交付設(shè)計的質(zhì)量，只重視初始設(shè)計的按期完成。第二次提交的設(shè)計再次遭到拒絕，這也再一次表明AMRIS確實太無能，不可能提出一個充分的開發(fā)計劃。

以上大事記似乎反復(fù)強調(diào)了AMRIS不能提供高質(zhì)量的軟件工程報告，這意味著基礎(chǔ)的軟件開發(fā)階段的有效性值得質(zhì)疑。另外，某種基礎(chǔ)的風險分析應(yīng)能幫助聯(lián)盟成員識別至少兩種高風險目標。這些風險目標應(yīng)能提醒聯(lián)盟成員進行某些測驗項目，以確定這些目標的可行性。CONFIRM系統(tǒng)的一個高風險目標是需要與聯(lián)盟伙伴的現(xiàn)有系統(tǒng)連接，這樣的連接要求CONFIRM同異構(gòu)的軟硬件能互操作；第二個高風險目標是需要將預(yù)訂系統(tǒng)同每種商務(wù)領(lǐng)域的決策支持系統(tǒng)集成。初始時對這些目標的復(fù)雜性作一下分析，就會得到一個更合理的開發(fā)進度計劃。

1.6.4 電話和通信

今天，人們很難找到比遠程電話網(wǎng)應(yīng)用技術(shù)更好的例子。它通過光纖將遍及世界各地的人們可靠地、即時地連在一起，這不能不說是技術(shù)上的奇跡。AT&T擁有多達115個交換站，將遍及世界的當?shù)仉娫捁具B接起來，每天可處理1.15億次美國境內(nèi)的呼叫和150萬次的海外呼叫，每個交換站每小時能處理將近75萬次呼叫。

一個交換站，又名4ESS，其實是一個龐大的專用計算機，它運行一個包含4百萬行代碼的軟件。該軟件需要仔細處理電話兩端的連接、通話費以及其他許多與電話相關(guān)的服務(wù)，為維護該軟件需要雇傭150人以上。有幾次事故曾中斷了電話服務(wù)，原因就是該軟件過于復(fù)雜。

1990年1月15日的下午，AT&T的全球電話網(wǎng)絡(luò)的管理人員發(fā)現(xiàn)顯示網(wǎng)絡(luò)狀態(tài)的視頻監(jiān)視器上不斷出現(xiàn)紅色報警信號。報警信號說明網(wǎng)絡(luò)不能完成呼叫，接下來的9個小時內(nèi)，有近6500萬個電話沒有接通，造成大約6000萬美元的損失。盡管系統(tǒng)的管理人員設(shè)法在9小時內(nèi)解決了問題，但是要查明原因恐怕需要好幾天。

大約在系統(tǒng)癱瘓前一個月，軟件進行了升級，以允許某種類型的消息更快地通過系統(tǒng)。在升級軟件的一小段代碼中發(fā)現(xiàn)了一個錯誤，該錯誤在嚴格的測試和一個月的試用中沒有被發(fā)現(xiàn)，因為那幾行代碼只在網(wǎng)絡(luò)特別忙而發(fā)生了特定的事件序列時才會調(diào)用。各單個交換站工作都正常，但交換站之間的消息傳遞的快速步調(diào)引起系統(tǒng)反復(fù)重啟動。當運行升級軟件的交換站數(shù)減少到80臺左右時，網(wǎng)絡(luò)似乎又恢復(fù)正常。這時，其余的交換站仍然運行舊版軟件，可以處理盡可能多的呼叫。

這種類型的“網(wǎng)絡(luò)隱錯”確實很難發(fā)現(xiàn)和想到，要在一個測試用的系統(tǒng)上精確模擬和預(yù)料真實世界中的網(wǎng)絡(luò)通信是十分困難的。事實上，AT&T確實也在它的測試網(wǎng)絡(luò)上測試了該軟件，但沒能發(fā)現(xiàn)該問題。

與首次癱瘓相隔6個月，又遇到了另一個控制交換站的軟件失效。在1991年6月到7月間的三個星期內(nèi)，8次電話不通事故影響了大約2000萬電話客戶。不通的原因難以捉摸，而且，本地電話公司之間似乎也不愿意彼此透露如何修復(fù)問題的有關(guān)信息。最終，由BellCore貝爾通信研究公司經(jīng)過6個月的調(diào)查，認定引起這一問題的原因仍然是這個交換機軟件。

這些事故的原因是制造交換機的軟硬件公司DSC通信公司對軟件的一次修改不當造成的。1991年4月，DSC通信公司發(fā)布了交換機的新版本。很快，華盛頓、賓夕法尼亞和北卡羅來納州的用戶碰到了這一問題。每次癱瘓首先由一個交換機的一個小問題引起，該問題與信號傳輸點（Signal Transfer Point，STP）有關(guān)。然后這一問題會觸發(fā)大量的錯誤消息，結(jié)果導(dǎo)致STP被關(guān)閉，進而導(dǎo)致鄰近系統(tǒng)的癱瘓。

最后，BellCore發(fā)現(xiàn)問題出在新版軟件中的一個三位錯：一個應(yīng)是二進制數(shù)D（1101）的數(shù)誤為二進制數(shù)60110）。在交換算法中，這三位錯導(dǎo)致交換機允許錯誤消息飽和。通過網(wǎng)絡(luò)，一個系統(tǒng)出錯導(dǎo)致其他系統(tǒng)崩潰。正常情況下，飽和的交換機只簡單地通告其他系統(tǒng)出現(xiàn)了擁塞情況。DSC通信公司很快發(fā)布了該軟件的補丁，專門處理這一問題。對源程序作了廣泛的測試之后發(fā)現(xiàn)，一個程序員對源程序中的三行代碼作了修改，其中一行包含低級的打字錯誤，軟件發(fā)布前，該段代碼沒有經(jīng)過測試。

你也許會慶幸通信問題似乎已成歷史，因為以上兩個例子均發(fā)生在20世紀90代初。然而，事實上近年來也發(fā)生了大量的這類失效。例如，一位美國西部技師為科羅拉多州安裝一個新的區(qū)域碼軟件時，不經(jīng)意地關(guān)閉了該區(qū)域的911系統(tǒng)，結(jié)果一位在Longmont的名叫Thomas Carlock的男士死于心臟病，發(fā)病時他的妻子不能撥通911急救服務(wù)。當時，她至少試過3次，結(jié)果每次都沒有回答，沒有振鈴，也沒有線路忙信號。最后，她查了號碼本，直接呼叫了一個急救室的電話，然后救護車才發(fā)往她的住地。在事故追查的過程中，技師一直不清楚911會有問題，Longmont急救人員也是直到事故發(fā)生后一個小時才知道911有問題的。按照美國西部的一份報告的說法，公司“已承諾采取措施確保軟件安裝不會影響到911服務(wù)”。

1.6.5阿麗亞娜5型火箭

1996年6月4日，阿麗亞娜（Ariane）5型火箭在法屬圭亞那庫魯航天中心首次發(fā)射。當火箭離開發(fā)射臺升空30秒時，距地面約4000米，天空中傳來兩聲巨大的爆炸聲并出現(xiàn)一

團桔黃色的巨大火球，火箭碎塊帶著火星撒落在直徑約兩公里的地面上。與阿麗亞娜5型火箭一同化為灰燼的還有4顆太陽風觀察衛(wèi)星。這是世界航天史上又一大悲劇。

阿麗亞娜5型火箭由歐洲航天局研制，火箭高52.7米，重740噸，研制費用為70億美元，研制時間1985－1996年，參研人員約萬人。事故原因報道：阿麗亞娜5型火箭采用阿麗亞娜4型火箭初始定位軟件。軟件不適應(yīng)物理環(huán)境的變化。阿麗亞娜5型火箭起飛推力15900KN，重量740噸，阿麗亞娜4型火箭起飛推力5400KN，重量474噸。阿5型火箭加速度=21.5g，阿4型火箭加速度=11.4g。阿麗亞娜5型火箭加速度值輸入到計算機系統(tǒng)的整型加速度值產(chǎn)生上溢出，以加速度為參數(shù)的速度、位置計算錯誤，導(dǎo)致慣性導(dǎo)航系統(tǒng)對火箭控制失效，程序只得進入異常處理模塊，引爆自毀。箭載兩套計算機系統(tǒng)由于硬件、軟件完全相同，沒有達到軟件容錯的目的。

導(dǎo)航系統(tǒng)負責參照基于慣性參考系統(tǒng)輸入的特定軌道來計算航線矯正。一個慣性參考系統(tǒng)讓一個移動體（例如火箭）僅根據(jù)來自加速儀和回轉(zhuǎn)儀的傳感器數(shù)據(jù)來計算其位置，也就是說，其計算不參考外部世界的數(shù)據(jù)。該慣性系統(tǒng)首先必須初始化起始坐標，用火箭的初始瞄準來校準其軸。導(dǎo)航系統(tǒng)在發(fā)射前，進行校對計算。為了把地球自轉(zhuǎn)產(chǎn)生的影響計算在內(nèi)，校對計算的結(jié)果需要不斷更新。校準計算很復(fù)雜，大約需要45分鐘才能完成。一旦火箭發(fā)射后，校準數(shù)據(jù)將傳給飛行導(dǎo)航系統(tǒng)。根據(jù)設(shè)計，校準計算在數(shù)據(jù)傳給導(dǎo)航系統(tǒng)后，還將繼續(xù)50秒。這一決定使導(dǎo)彈發(fā)射前的倒計數(shù)得以在對準數(shù)據(jù)傳出后、在發(fā)動機被點火之前終止，而不必重新啟動校準計算（即，不必重新啟動45分鐘的計算周期）。當發(fā)射成功時，校準輪在起飛后為下一個40秒產(chǎn)生待處理的數(shù)據(jù)。

Ariane5的計算機系統(tǒng)與Ariane4不同，電子儀器多了一倍。有兩個慣性參考系統(tǒng)來計算火箭的位置，兩臺計算機將計劃中的軌道和實際軌道進行比較，并用兩套控制儀器來控制火箭。如果某個構(gòu)件出了問題，后備系統(tǒng)將隨時接替現(xiàn)行系統(tǒng)。

專為地面設(shè)計的校準系統(tǒng)，使用16位字來存儲水平速度(對由于風和地球運行產(chǎn)生的位移計算而言，16位是綽綽有余的)。飛行30秒后，Ariane5的水平速度計算產(chǎn)生了溢出，由此引出了一種意外，通過關(guān)掉機載計算機來處理這一問題，并把控制權(quán)交給后備系統(tǒng)。

討論：由于校準系統(tǒng)沒有得到充分測試，盡管它經(jīng)過成千上萬次測試，但沒有一次測試包括了實際軌道上的測試。導(dǎo)航系統(tǒng)被單獨地進行了測試。系統(tǒng)項目組制定測試計劃，導(dǎo)航系統(tǒng)的構(gòu)造者執(zhí)行測試。系統(tǒng)項目組沒有意識到在飛行中的校準會引起主處理機的關(guān)閉。這一實例充分說明了構(gòu)件組與系統(tǒng)組缺乏溝通。

教訓(xùn)：軍用軟件的運行依賴于支撐環(huán)境，武器平臺的變化可能影響軍用軟件采集數(shù)據(jù)的精度、范圍和對系統(tǒng)的控制。軍用軟件重用必須重新進行系統(tǒng)論證和系統(tǒng)測試／試驗，決不能想當然。

第二篇：軟件測試 心得體會

蘭州直方科技有限公司

心得體會

如果要進步，那么就要嘗試新的技術(shù)，新的思維，大膽的使用，在用的過程中肯定會學(xué)到新的東西。

加強團隊內(nèi)部的溝通，是解決團隊內(nèi)部分散的最好辦法，如果一個團隊沒有很好溝通，那么這個團隊就像是沒有肥力的沙漠就沒有競爭力，它的存在價值值得懷疑。但是加強團隊建設(shè)是一件很不容易做到的事情，加入團隊中有某一個成員技術(shù)很牛，就是搞獨立，不按照游戲的規(guī)則，那么，作為項目小組的負責人，該如何去解決這個問題。我想在肯定他技術(shù)很牛的同時也應(yīng)該讓他明白如果只是將自己所做的模塊做好，整個項目卻是一般般，那么自己做好的那個模塊就起不到任何的作用了。溝通，再溝通，直到他能很好的配合團隊的工作，這樣我相信我們的團隊是一個有凝聚力、競爭力的團隊，我們才能按時高質(zhì)量的完成項目。

在這次的項目中，我們學(xué)到了很多。尤為深刻的體會是一個團隊如果不能團結(jié)在一起，那么它就沒有競爭。項目組之間要多交流一邊更好的理解別人的思維、項目的進程來及時解決存在的問題以及計劃的改進。要對自己準確定位知道自己能勝任什庅樣的工作以及在那一方面最擅長可以做得很好。

很榮幸，在本次項目開發(fā)中，我個人承擔項目小組長的角色，在項目進展過程中，非常感謝項目小組成員對我工作的支持，項目經(jīng)理對我的信任。感謝在項目開發(fā)中，各位領(lǐng)導(dǎo)對項目進度的關(guān)注！謝謝！

蘭州直方科技有限公司

第三篇：軟件測試心得體會

心得體會

六天的培訓(xùn)結(jié)束了，感覺過得好快啊。雖然是因為參加“模擬招聘”獲得這次機會的，不像其他同學(xué)一樣是交錢的，但是我也是抱著要學(xué)東西的心態(tài)參加的。

第一天老師就給了個下馬威——教材全是全是英文版的。對于雖然大三的我來說，英語四級剛過，六級成績還沒出來的情況下，想看懂全文是不太現(xiàn)實的。在老師講解過程中利用在線翻譯才勉強能看懂句子。不過培訓(xùn)過程中最難忘的不是來自教材，而是來自老師的那雙犀利的眼神。無論何時，只要你打開了與課堂無關(guān)的網(wǎng)頁，她總會第一時間或叫號碼，或叫名字，或站到你旁邊。說實話，大學(xué)上課已經(jīng)很久沒有這種高中被管的感覺了。雖然不爽，但是卻有種回到高中的快感（說的是實話）。

頭幾天還蠻不錯的，食堂開門的，超市沒關(guān)?？珊髱滋欤斝ｉT口已無人煙，就剩我們這幾個的時候就真覺得寢室樓好靜啊，還不如在機房呆著。對于老師我想說的是，前幾天笑容總是掛在臉上，可兩天后明顯笑的少了，不知道是不是因為和大家熟了，沒有剛見面的客氣了（我喜歡看人笑，本身也喜歡笑，老師的這種變化，我很敏銳的察覺了）。

這次培訓(xùn)雖然感覺學(xué)到的沒有很多，但是我了解了一個企業(yè)，起碼是軟件測試這一行業(yè)大致的運作模式，讓我對我將來要不要從事這個行業(yè)有了認識。貌似軟件測試女生為主，男生比較適合從開發(fā)做起，這是我這幾天得到的最大體會。還有對于課堂結(jié)束的演講，是個鍛煉

自己的好機會，我并不否認這點，不過貌似每個人都只有一次機會，我是個表現(xiàn)欲很強的人，讓我講了一次有點不過癮。

開始我是因為不想浪費免費來上課的就會，來到后我覺得確實很多時候是需要多接觸下這些社會上的公司、企業(yè)等，畢竟還有一年就畢業(yè)了，到底何去何從自己是真的要好好做個打算了。期待下一期的網(wǎng)新的培訓(xùn)??

第四篇：軟件測試心得

《軟件測試心得體會》

軟件測試在整個軟件周期中的重要性。它存在于整個項目周期，在項目開始

下面簡單談?wù)勎业膸c體會：

體會一：

體會一：軟件測試在整個軟件周期中的重要性。

它存在于整個項目周期，在項目開始之初需求調(diào)研的時候就開始了，在形成需求規(guī)格說明書的時候就需要針對文檔進行測試。這個環(huán)節(jié)在后續(xù)整個項目中占了很大的比重，能主導(dǎo)整個項目的走向，成敗與否全在于開始階段的決策。

體會二：軟件測試的真正意義在于發(fā)現(xiàn)錯誤，而不在于驗證軟件是正確的。

再嚴密的測試也不能完全發(fā)現(xiàn)軟件當中所有的錯誤，但是測試還是能發(fā)現(xiàn)大部分的錯誤，能確保軟件基本是可用的，所以在后續(xù)使用的過程中還需要加強快速響應(yīng)的環(huán)節(jié)。結(jié)合軟件測試的理論，故障暴露在最終客戶端之前及時主動的去發(fā)現(xiàn)并解決。這一點就需要加強研發(fā)隊伍的建設(shè)。

體會三：在系統(tǒng)性能測試方面需要重視。

經(jīng)過這次培訓(xùn)中多個案例的講解，讓我了解到系統(tǒng)在上線之后會有很多不能預(yù)知的性能問題，需要在上線之前實現(xiàn)進行模擬，以規(guī)避風險，包括大數(shù)據(jù)量訪問，高并發(fā)數(shù)等等。當然也有很多應(yīng)對手段，沒有哪種手段可稱為最完美，只有最合適的，需要靈活掌握，綜合運用以達到最優(yōu)程度，這是個很值得研究的領(lǐng)域。

下面是我的幾點想法：

想法一：加強系統(tǒng)上線前的性能測試。

目前我們在項目建設(shè)過程中對性能壓力測試的重視程度還不太高，廠家也很少有雇傭第三方的測試機構(gòu)。而是在現(xiàn)網(wǎng)進行試用，遇到問題再解決，可能會產(chǎn)生滯后問題，影響客戶使用。希望以后能在性能測試方面提高重視程度，加大人力投入，以保證系統(tǒng)上線后能夠穩(wěn)定運行。

想法二：適當介入相關(guān)項目研發(fā)

對于快速響應(yīng)這塊，我們不能一味依賴廠家，而希望自己就能快速響應(yīng)，及時將問題解決。這也是一個比較長遠的問題，需要加強研發(fā)力量的投入。

我個人是做開發(fā)出身，有此類經(jīng)驗，當時是在客戶現(xiàn)場，因為了解系統(tǒng)內(nèi)部結(jié)構(gòu)，能夠在第一時間排查解決客戶所反饋問題。

現(xiàn)在系統(tǒng)完全由廠家開發(fā)，很難了解內(nèi)部結(jié)構(gòu)，或許會造成后期維護困難。所以，是否應(yīng)該針對某些項目介入廠家研發(fā)工作，比如請廠家提供源代碼等相關(guān)要素，以增進維護人員對系統(tǒng)的了解。

最后再次感謝公司提供的平臺，感謝領(lǐng)導(dǎo)的信任，讓我有機會得到更深層次的學(xué)習(xí)以及展示自己能力的機會，我也會盡我所能來完善工作的系統(tǒng)，提高整體工作效率，為南方電網(wǎng)的發(fā)展建設(shè)提供更堅實，優(yōu)秀的支撐服務(wù)平臺。

第五篇：軟件測試總結(jié)

面向?qū)ο蟪绦虻能浖y試方法

在軟件生命周期過程中，軟件測試是保證軟件質(zhì)量的關(guān)鍵環(huán)節(jié)之一。面向?qū)ο蠓椒▽W(xué)在軟件工程中的引入極大地方便了軟件的設(shè)計、開發(fā)和維護，為創(chuàng)建高可靠性的軟件系統(tǒng)提供了重要保證。但面向?qū)ο蟪绦虻姆庋b、繼承、多態(tài)和異常處理機制等新特性卻給測試帶來新的挑戰(zhàn)。一方面需要調(diào)整、改進傳統(tǒng)的測試策略和方法；另一方面探索出適應(yīng)面向?qū)ο蟪绦蛱卣鞯臏y試理論與技術(shù)也尤為必要。

面向?qū)ο?Object Oriented,OO)是當前計算機界關(guān)心的重點，它是90年代軟件開發(fā)方法的主流。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計和軟件開發(fā)，擴展到很寬的范圍。如數(shù)據(jù)庫系統(tǒng)、交互式界面、應(yīng)用結(jié)構(gòu)、應(yīng)用平臺、分布式系統(tǒng)、網(wǎng)絡(luò)管理結(jié)構(gòu)、CAD技術(shù)、人工智能等領(lǐng)域。

面向?qū)ο蟮亩x或說明對象的定義的非常少。其初，“面向?qū)ο蟆笔菍Ｖ冈诔绦蛟O(shè)計中采用封裝、繼承、抽象等設(shè)計方法?？墒?，這個定義顯然不能再適合現(xiàn)在情況。面向?qū)ο蟮乃枷胍呀?jīng)涉及到軟件開發(fā)的各個方面。如，面向?qū)ο蟮姆治觯∣OA，Object Oriented Analysis），面向?qū)ο蟮脑O(shè)計（OOD，Object Oriented Design）、以及我們經(jīng)常說的面向?qū)ο蟮木幊虒崿F(xiàn)（OOP，Object Oriented Programming）。許多有關(guān)面向?qū)ο蟮奈恼露贾皇侵v述在面向?qū)ο蟮拈_發(fā)中所需要注意的問題或所采用的比較好的設(shè)計方法?？催@些文章只有真正懂得什么是對象，什么是面向?qū)ο?，才能最大程度地對自己有所裨益。這一點，恐怕對初學(xué)者甚至是從事相關(guān)工作多年的人員也會對它們的概念模糊不清。

1、面向?qū)ο蟮幕靖拍?/p>

(1)對象。

對象是人們要進行研究的任何事物，從最簡單的整數(shù)到復(fù)雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計劃或事件。

(2)對象的狀態(tài)和行為。

對象具有狀態(tài)，一個對象用數(shù)據(jù)值來描述它的狀態(tài)。

對象還有操作，用于改變對象的狀態(tài)，對象及其操作就是對象的行為。

對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作封裝于對象的統(tǒng)一體中

(3)類。具有相同或相似性質(zhì)的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。

類具有屬性，它是對象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。

類具有操作，它是對象的行為的抽象，用操作名和實現(xiàn)該操作的方法來描述。

(4)類的結(jié)構(gòu)。

在客觀世界中有若干類，這些類之間有一定的結(jié)構(gòu)關(guān)系。通常有兩種主要的結(jié)構(gòu)關(guān)系，即一般--具體結(jié)構(gòu)關(guān)系，整體--部分結(jié)構(gòu)關(guān)系。

①一般——具體結(jié)構(gòu)稱為分類結(jié)構(gòu)，也可以說是“或”關(guān)系，或者是“is a”關(guān)系。

②整體——部分結(jié)構(gòu)稱為組裝結(jié)構(gòu)，它們之間的關(guān)系是一種“與”關(guān)系，或者是“has a”關(guān)系。

(5)消息和方法。

對象之間進行通信的結(jié)構(gòu)叫做消息。在對象的操作中，當一個消息發(fā)送給某個對象時，消息包含接收對象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對象名、發(fā)送給該對象的消息名（即對象名、方法名）。一般還要對參數(shù)加以說明，參數(shù)可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

類中操作的實現(xiàn)過程叫做方法，一個方法有方法名、參數(shù)、方法體。消

2、面向?qū)ο蟮奶卣?/p>

(1)對象唯一性。

每個對象都有自身唯一的標識，通過這種標識，可找到相應(yīng)的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。

(2)分類性。

分類性是指將具有一致的數(shù)據(jù)結(jié)構(gòu)(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應(yīng)用有關(guān)的重要性質(zhì)，而忽略其他一些無關(guān)內(nèi)容。任何類的劃分都是主觀的，但必須與具體的應(yīng)用有關(guān)。

(3)繼承性。

繼承性是子類自動共享父類數(shù)據(jù)結(jié)構(gòu)和方法的機制，這是類之間的一種關(guān)系。在定義和實現(xiàn)一個類的時候，可以在一個已經(jīng)存在的類的基礎(chǔ)之上來進行，把這個已經(jīng)存在的類所定義的內(nèi)容作為自己的內(nèi)容，并加入若干新的內(nèi)容。繼承性是面向?qū)ο蟪绦蛟O(shè)計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為多重繼承。

在軟件開發(fā)中，類的繼承性使所建立的軟件具有開放性、可擴充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創(chuàng)建工作量，增加了代碼的可重性。

采用繼承性，提供了類的規(guī)范的等級結(jié)構(gòu)。通過類的繼承關(guān)系，使公共的特性能夠共享，提高了軟件的重用性。

(4)多態(tài)性(多形性)多態(tài)性使指相同的操作或函數(shù)、過程可作用于多種類型的對象上并獲得不同的結(jié)果。不同的對象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象稱為多態(tài)性。

多態(tài)性允許每個對象以適合自身的方式去響應(yīng)共同的消息。

多態(tài)性增強了軟件的靈活性和重用性。

面向?qū)ο蠓椒ǖ幕舅枷胧且唬好嫦驅(qū)ο蠓椒ㄊ且环N運用對象、類、封裝、繼承、多態(tài)和消息等概念來構(gòu)造、測試、重構(gòu)軟件的方法。

二： 面向?qū)ο蠓椒ㄊ且哉J識論為基礎(chǔ)，用對象來理解和分析問題空間，并設(shè)計和開發(fā)出由對象構(gòu)成的軟件系統(tǒng)（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結(jié)構(gòu)上的不一致帶來的問題。簡言之，面向?qū)ο缶褪敲嫦蚴虑楸旧恚嫦驅(qū)ο蟮姆治鲞^程就是認識客觀世界的過程。

面向?qū)ο蠓椒◤膶ο蟪霭l(fā)，發(fā)展出對象，類，消息，繼承等概念。

面向?qū)ο蠓椒ǖ闹饕獌?yōu)點是：符合人們通常的思維方式；從分析到設(shè)計再到編碼采用一致的模型表示具有高度連續(xù)性；軟件重用性好。

面向?qū)ο筌浖y試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術(shù)； 2.掌握白盒測試和黑盒測試的測試用例的設(shè)計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統(tǒng)測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向?qū)ο筌浖蚖EB應(yīng)用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標準和文檔；

8.掌握QESuite軟件測試過程管理平臺和QESat/C++軟件分析和工具的使用方法。