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

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

失效案例簡介

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

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

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

幾架“黑鷹”直升機撞毀，多人罹難。調查表明，災難原因是無線電信號與機載計算機系統相互干擾。

稱做CONFIRM的旅游預訂系統在經過1.25億美元的投資后流產。

F22戰機的一個軟件故障（邊界值測試的漏洞）。2007年2月，美軍F22戰斗機從夏威夷飛往日本，途徑日期變更線（東經180度，西經0度）時，軟件缺陷爆發，飛機上的全球定位系統失靈，電腦系統崩潰。飛行員無法確定戰機的位置，返回夏威夷的希卡姆空軍基地。洛·馬丁公司對軟件進行了維護，48小時后提供了新的軟件版本。

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

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

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

1.6.2失效原因

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

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

1)軟件復雜度；

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

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

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

5)硬件或操作系統與軟件不兼容；

6)管理不善；

7)測試不充分；

8)粗心大意；

9)想走捷徑；

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

11)風險分析不充分；

12)數據輸入錯誤；

13)錯誤的輸出解釋；

14)對軟件過于自信；

15)缺乏生產高質量軟件的市場或法律壓力。

以上是引起軟件失效的原因列表，對我們很有幫助，我們應該謹記。考慮的潛在軟件失效原因越多，系統就越不易出現失效。例如，如果完全按照一種軟件工程方法學來開發軟件，假設用戶是未經過充分訓練的，那么就應考慮可能會出現數據完整性錯誤，否則，系統可能是沒什么用的。

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

1.6.3 CONFIRM

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

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

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

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

3)1988年12月30日，AMRIS向聯盟呈報了系統基礎設計，Marriott認為系統的功能規約還不夠充分，用戶需求還不夠細，開發人員還不能據此進行開發。

4)1989年3月，AMRIS呈報一份開發計劃，結果也未被聯盟成員們接受。

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

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

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

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

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

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

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

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

大量的報刊對CONFIRM項目的無能的管理和技術上的幼稚等進行了無情的嘲諷。不過我們關心的是，如何利用適當的軟件工程方法來避免這種災難。雖然這個例子涉及一個重要的職業道德問題，但首先還是讓我們來分析軟件失效的根源。

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

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

1.6.4 電話和通信

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

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

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

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

這種類型的“網絡隱錯”確實很難發現和想到，要在一個測試用的系統上精確模擬和預料真實世界中的網絡通信是十分困難的。事實上，AT&T確實也在它的測試網絡上測試了該軟件，但沒能發現該問題。

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

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

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

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

1.6.5阿麗亞娜5型火箭

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

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

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

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

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

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

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

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

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

蘭州直方科技有限公司

心得體會

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

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

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

很榮幸，在本次項目開發中，我個人承擔項目小組長的角色，在項目進展過程中，非常感謝項目小組成員對我工作的支持，項目經理對我的信任。感謝在項目開發中，各位領導對項目進度的關注！謝謝！

蘭州直方科技有限公司

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

心得體會

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

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

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

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

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

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

第四篇：軟件測試心得

《軟件測試心得體會》

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

下面簡單談談我的幾點體會：

體會一：

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

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

體會二：軟件測試的真正意義在于發現錯誤，而不在于驗證軟件是正確的。

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

體會三：在系統性能測試方面需要重視。

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

下面是我的幾點想法：

想法一：加強系統上線前的性能測試。

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

想法二：適當介入相關項目研發

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

我個人是做開發出身，有此類經驗，當時是在客戶現場，因為了解系統內部結構，能夠在第一時間排查解決客戶所反饋問題。

現在系統完全由廠家開發，很難了解內部結構，或許會造成后期維護困難。所以，是否應該針對某些項目介入廠家研發工作，比如請廠家提供源代碼等相關要素，以增進維護人員對系統的了解。

最后再次感謝公司提供的平臺，感謝領導的信任，讓我有機會得到更深層次的學習以及展示自己能力的機會，我也會盡我所能來完善工作的系統，提高整體工作效率，為南方電網的發展建設提供更堅實，優秀的支撐服務平臺。

第五篇：軟件測試總結

面向對象程序的軟件測試方法

在軟件生命周期過程中，軟件測試是保證軟件質量的關鍵環節之一。面向對象方法學在軟件工程中的引入極大地方便了軟件的設計、開發和維護，為創建高可靠性的軟件系統提供了重要保證。但面向對象程序的封裝、繼承、多態和異常處理機制等新特性卻給測試帶來新的挑戰。一方面需要調整、改進傳統的測試策略和方法；另一方面探索出適應面向對象程序特征的測試理論與技術也尤為必要。

面向對象(Object Oriented,OO)是當前計算機界關心的重點，它是90年代軟件開發方法的主流。面向對象的概念和應用已超越了程序設計和軟件開發，擴展到很寬的范圍。如數據庫系統、交互式界面、應用結構、應用平臺、分布式系統、網絡管理結構、CAD技術、人工智能等領域。

面向對象的定義或說明對象的定義的非常少。其初，“面向對象”是專指在程序設計中采用封裝、繼承、抽象等設計方法。可是，這個定義顯然不能再適合現在情況。面向對象的思想已經涉及到軟件開發的各個方面。如，面向對象的分析（OOA，Object Oriented Analysis），面向對象的設計（OOD，Object Oriented Design）、以及我們經常說的面向對象的編程實現（OOP，Object Oriented Programming）。許多有關面向對象的文章都只是講述在面向對象的開發中所需要注意的問題或所采用的比較好的設計方法。看這些文章只有真正懂得什么是對象，什么是面向對象，才能最大程度地對自己有所裨益。這一點，恐怕對初學者甚至是從事相關工作多年的人員也會對它們的概念模糊不清。

1、面向對象的基本概念

(1)對象。

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

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

對象具有狀態，一個對象用數據值來描述它的狀態。

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

對象實現了數據和操作的結合，使數據和操作封裝于對象的統一體中

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

類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。

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

(4)類的結構。

在客觀世界中有若干類，這些類之間有一定的結構關系。通常有兩種主要的結構關系，即一般--具體結構關系，整體--部分結構關系。

①一般——具體結構稱為分類結構，也可以說是“或”關系，或者是“is a”關系。

②整體——部分結構稱為組裝結構，它們之間的關系是一種“與”關系，或者是“has a”關系。

(5)消息和方法。

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

類中操作的實現過程叫做方法，一個方法有方法名、參數、方法體。消

2、面向對象的特征

(1)對象唯一性。

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

(2)分類性。

分類性是指將具有一致的數據結構(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。

(3)繼承性。

繼承性是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。在定義和實現一個類的時候，可以在一個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，并加入若干新的內容。繼承性是面向對象程序設計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數據結構和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數據結構和方法，則稱為多重繼承。

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

采用繼承性，提供了類的規范的等級結構。通過類的繼承關系，使公共的特性能夠共享，提高了軟件的重用性。

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

多態性允許每個對象以適合自身的方式去響應共同的消息。

多態性增強了軟件的靈活性和重用性。

面向對象方法的基本思想是一：面向對象方法是一種運用對象、類、封裝、繼承、多態和消息等概念來構造、測試、重構軟件的方法。

二： 面向對象方法是以認識論為基礎，用對象來理解和分析問題空間，并設計和開發出由對象構成的軟件系統（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結構上的不一致帶來的問題。簡言之，面向對象就是面向事情本身，面向對象的分析過程就是認識客觀世界的過程。

面向對象方法從對象出發，發展出對象，類，消息，繼承等概念。

面向對象方法的主要優點是：符合人們通常的思維方式；從分析到設計再到編碼采用一致的模型表示具有高度連續性；軟件重用性好。

面向對象軟件測試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術； 2.掌握白盒測試和黑盒測試的測試用例的設計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向對象軟件和WEB應用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標準和文檔；

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