mave工程中的一个类调用另一个聚合工程的一个类_信息系统管理工程师备考分享(材料重点精炼)——第一章信息化和信息系统(4)...
本章分享的1.4節(jié)的重要考點(diǎn)內(nèi)容相對(duì)來(lái)說(shuō)還是比較多的,里面包括需求、設(shè)計(jì)、測(cè)試等軟件工程的內(nèi)容,同學(xué)們學(xué)完前幾篇文章的分享會(huì)發(fā)現(xiàn),第一章與計(jì)算機(jī)領(lǐng)域的知識(shí)的銜接程度還是非常緊密的。我經(jīng)常會(huì)聽(tīng)到很多面授課學(xué)員在學(xué)習(xí)第一章的時(shí)候跟我說(shuō)“第一章記不住,太難了,想放棄”,其實(shí)我可以這么說(shuō)第一章是比較難,就以1.4節(jié)為例,大部分同學(xué)應(yīng)該都是計(jì)算機(jī)相關(guān)專(zhuān)業(yè)畢業(yè)的學(xué)員,大家在大學(xué)的時(shí)候一定知道軟件工程這個(gè)專(zhuān)業(yè),試想一下,軟件工程專(zhuān)業(yè)的同學(xué)用三到四年的時(shí)間學(xué)習(xí)軟件工程的相關(guān)知識(shí),我們的教材只是用一個(gè)小節(jié)進(jìn)行講解,所有的知識(shí)點(diǎn)只要背下來(lái)考試就會(huì)沒(méi)問(wèn)題。而且你幸運(yùn)的看到了這篇文章,你會(huì)發(fā)現(xiàn)本篇文章對(duì)書(shū)中不考的知識(shí)點(diǎn)進(jìn)行篩選精化,將原先要背的幾十頁(yè)甚至幾百頁(yè)的內(nèi)容最終形成幾千字的文字,大家就更不應(yīng)該退縮了,更應(yīng)該好好學(xué)習(xí)了。下面我們繼續(xù)分享
1.4軟件工程
1.4.1需求分析
1、需求是多層次的, 包括業(yè)務(wù)需求、用戶(hù)需求和系統(tǒng)需求。
(1) 業(yè)務(wù)需求。業(yè)務(wù)需求是指反映企業(yè)或客戶(hù)對(duì)系統(tǒng)高層次的目標(biāo)要求,通常來(lái)自項(xiàng)目投資人、購(gòu)買(mǎi)產(chǎn)品的客戶(hù)、客戶(hù)單位的管理人員、市場(chǎng)營(yíng)銷(xiāo)部門(mén)或產(chǎn)品策劃部門(mén)等。
(2) 用戶(hù)需求。用戶(hù)需求描述的是用戶(hù)的具體目標(biāo),或用戶(hù)要求系統(tǒng)必須能完成的任務(wù)。也就是說(shuō),用戶(hù)需求描述了用戶(hù)能使用系統(tǒng)來(lái)做些什么。通常采取用戶(hù)訪(fǎng)談和問(wèn)卷調(diào)查等方式,對(duì)用戶(hù)使用的場(chǎng)景進(jìn)行整理,從而建立用戶(hù)需求。
(3) 系統(tǒng)需求。系統(tǒng)需求是從系統(tǒng)的角度來(lái)說(shuō)明軟件的需求,包括功能需求、非功能需求和設(shè)計(jì)約束等。
2、質(zhì)量功能部署(QFD)是一種將用戶(hù)要求轉(zhuǎn)化成軟件需求的技術(shù),其目的是最大限度地提升軟件工程過(guò)程中用戶(hù)的滿(mǎn)意度。QFD將軟件需求分為三類(lèi),分別是常規(guī)需求、期望需求和意外需求。
(1) 常規(guī)需求。用戶(hù)認(rèn)為系統(tǒng)應(yīng)該做到的功能或性能,實(shí)現(xiàn)越多用戶(hù)會(huì)越滿(mǎn)意。
(2) 期望需求。用戶(hù)想當(dāng)然認(rèn)為系統(tǒng)應(yīng)具備的功能或性能,但并不能正確描述自己想要得到的這些功能或性能需求。如果期望需求沒(méi)有得到實(shí)現(xiàn),會(huì)讓用戶(hù)感到不滿(mǎn)意。
(3) 意外需求。意外需求也稱(chēng)為興奮需求,是用戶(hù)要求范圍外的功能或性能(但通常是軟件開(kāi)發(fā)人員很樂(lè)意賦予系統(tǒng)的技術(shù)特性實(shí)現(xiàn)這些需求用戶(hù)會(huì)更高興,但不實(shí)現(xiàn)也不影響其購(gòu)買(mǎi)的決策。意外需求是控制在開(kāi)發(fā)人員手中的,開(kāi)發(fā)人員可以選擇實(shí)現(xiàn)更多的意外需求,以便得到高滿(mǎn)意、高忠誠(chéng)度的用戶(hù),也可以(出于成本或項(xiàng)目周期的考慮)選擇不實(shí)現(xiàn)任何意外需求。
3、常見(jiàn)的需求獲取方法包括用戶(hù)訪(fǎng)談、問(wèn)卷調(diào)查、采樣、情節(jié)串聯(lián)板、聯(lián)合需求計(jì)劃等
4、一個(gè)好的需求應(yīng)該具有無(wú)二義性、完整性、一致性、可測(cè)試性、確定性、可跟蹤性、正確性、必要性等特性,因此,需要分析人員把雜亂無(wú)章的用戶(hù)要求和期望轉(zhuǎn)化為用戶(hù)需求,這就是需求分析的工作。
使用SA方法進(jìn)行需求分析,其建立的模型的核心是數(shù)據(jù)字典。在實(shí)際工作中,一般使用實(shí)體聯(lián)系圖(E-R圖) 表示數(shù)據(jù)模型,用數(shù)據(jù)流圖(DFD) 表示功能模型,用狀態(tài)轉(zhuǎn)換圖(STD) 表示行為模型。E-R圖主要描述實(shí)體、屬性,以及實(shí)體之間的關(guān)系;DFD從數(shù)據(jù)傳遞和加工的角度,利用圖形符號(hào)通過(guò)逐層細(xì)分描述系統(tǒng)內(nèi)各個(gè)部件的功能和數(shù)據(jù)在它們之間傳遞的情況,來(lái)說(shuō)明系統(tǒng)所完成的功能; STD通過(guò)描述系統(tǒng)的狀態(tài)和引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件,來(lái)表示系統(tǒng)的行為,指出作為特定事件的結(jié)果將執(zhí)行哪些動(dòng)作(例如,處理數(shù)據(jù)等)。
5、軟件需求規(guī)格說(shuō)明書(shū)(SRS)是需求開(kāi)發(fā)活動(dòng)的產(chǎn)物,其中規(guī)定SRS應(yīng)該包括以下內(nèi)容。
(1)范圍(2)引用文件(3)需求(4)合格性規(guī)定(5)需求可追蹤性(6)尚未解決的問(wèn)題(7) 注解(8)附錄
6、需求驗(yàn)證也稱(chēng)為需求確認(rèn),其活動(dòng)是為了確定以下幾個(gè)方面的內(nèi)容。
(1) SRS正確地描述了預(yù)期的、滿(mǎn)足項(xiàng)目干系人需求的系統(tǒng)行為和特征。
(2) SRS中的軟件需求是從系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來(lái)源中正確推導(dǎo)而來(lái)的。
(3) 需求是完整的和高質(zhì)量的。
(4)需求的表示在所有地方都是一致的。
(5)需求為繼續(xù)進(jìn)行系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試提供了足夠的基礎(chǔ)。
在實(shí)際工作中,一般通過(guò)需求評(píng)審和需求測(cè)試工作來(lái)對(duì)需求進(jìn)行驗(yàn)證。需求評(píng)審就是對(duì)SRS進(jìn)行技術(shù)評(píng)審。
7、從總體上來(lái)看,UML的結(jié)構(gòu)包括構(gòu)造塊、規(guī)則和公共機(jī)制三個(gè)部分。
8、UML用關(guān)系把事物結(jié)合在一起,主要有下列四種關(guān)系:
(1) 依賴(lài): :依賴(lài)是兩個(gè)事物之間的語(yǔ)義關(guān)系,其中一個(gè)事物發(fā)生變化會(huì)影響另一個(gè)事物的語(yǔ)義。
(2) 關(guān)聯(lián):關(guān)聯(lián)描述一組對(duì)象之間連接的結(jié)構(gòu)關(guān)系。
(3) 泛化:泛化是一般化和特殊化的關(guān)系,描述特殊元素的對(duì)象可替換一般元素的對(duì)象。
(4) 實(shí)現(xiàn):實(shí)現(xiàn)是類(lèi)之間的語(yǔ)義關(guān)系,其中的一個(gè)類(lèi)指定了由另一個(gè)類(lèi)保證執(zhí)行的契約。
9、UML 2. 0包括14種圖,分別列舉如下:
(1)類(lèi)圖:類(lèi)圖描述一組類(lèi)、接口、協(xié)作和它們之間的關(guān)系。類(lèi)圖給出了系統(tǒng)的靜態(tài)設(shè)計(jì)視圖,活動(dòng)類(lèi)的類(lèi)圖給出了系統(tǒng)的靜態(tài)進(jìn)程視圖。
(2)對(duì)象圖:對(duì)象圖描述一組對(duì)象及它們之間的關(guān)系。
(3) 泛化:泛化是一般化和特殊化的關(guān)系,描述特殊元素的對(duì)象可替換一般元素的對(duì)象。
(4) 實(shí)現(xiàn):實(shí)現(xiàn)是類(lèi)之間的語(yǔ)義關(guān)系,其中的一個(gè)類(lèi)指定了由另一個(gè)類(lèi)保證執(zhí)行的契約。
9、UML 2. 0包括14種圖,分別列舉如下:
(1)類(lèi)圖:類(lèi)圖描述一組類(lèi)、接口、協(xié)作和它們之間的關(guān)系。類(lèi)圖給出了系統(tǒng)的靜態(tài)設(shè)計(jì)視圖,活動(dòng)類(lèi)的類(lèi)圖給出了系統(tǒng)的靜態(tài)進(jìn)程視圖。
(2)對(duì)象圖:對(duì)象圖描述一組對(duì)象及它們之間的關(guān)系。
(3) 構(gòu)件圖:構(gòu)件圖描述一個(gè)封裝的類(lèi)和它的接口、端口, 以及由內(nèi)嵌的構(gòu)件和連接件構(gòu)成的內(nèi)部結(jié)構(gòu)。
(4) 組合結(jié)構(gòu)圖:組合結(jié)構(gòu)圖描述結(jié)構(gòu)化類(lèi)(例如,構(gòu)件或類(lèi))的內(nèi)部結(jié)構(gòu),包括結(jié)構(gòu)化類(lèi)與系統(tǒng)其余部分的交互點(diǎn)。
(5)用例圖:用例圖描述一組用例、參與者及它們之間的關(guān)系。
(6)順序圖(也稱(chēng)序列圖) :順序圖是一一種交互圖,交互圖展現(xiàn)了一種交互,它由一組對(duì)象或參與者以及它們之間可能發(fā)送的消息構(gòu)成。交互圖專(zhuān)注于系統(tǒng)的動(dòng)態(tài)視圖。順序圖是強(qiáng)調(diào)消息的時(shí)間次序的交互圖。
(7) 通信圖:通信圖也是一種交互圖,它強(qiáng)調(diào)收發(fā)消息的對(duì)象或參與者的結(jié)構(gòu)組織。順序圖強(qiáng)調(diào)的是時(shí)序,通信圖強(qiáng)調(diào)的是對(duì)象之間的組織結(jié)構(gòu)(關(guān)系)。
(8) 定時(shí)圖(也稱(chēng)計(jì)時(shí)圖) :定時(shí)圖也是一種交互圖,它強(qiáng)調(diào)消息跨越不同對(duì)象或參與者的實(shí)際時(shí)間,而不僅僅只是關(guān)心消息的相對(duì)順序。
(9) 狀態(tài)圖:狀態(tài)圖描述一個(gè)狀態(tài)機(jī),它由狀態(tài)、轉(zhuǎn)移、事件和活動(dòng)組成。狀態(tài)圖給出了對(duì)象的動(dòng)態(tài)視圖。
(10) 活動(dòng)圖:活動(dòng)圖將進(jìn)程或其他計(jì)算結(jié)構(gòu)展示為計(jì)算內(nèi)部一步步的控制流和數(shù)據(jù)流。活動(dòng)圖專(zhuān)注于系統(tǒng)的動(dòng)態(tài)視圖。它強(qiáng)調(diào)對(duì)象間的控制流程。
(11) 部署圖:部署圖描述對(duì)運(yùn)行時(shí)的處理節(jié)點(diǎn)及在其中生存的構(gòu)件的配置。部署圖給出了架構(gòu)的靜態(tài)部署視圖,通常一個(gè)節(jié)點(diǎn)包含一個(gè)或多個(gè)部署圖。
(12)制品圖:制品圖描述計(jì)算機(jī)中一個(gè)系統(tǒng)的物理結(jié)構(gòu)。制品包括文件、數(shù)據(jù)庫(kù)和類(lèi)似的物理比特集合。制品圖通常與部署圖一起使用。制品也給出了它們實(shí)現(xiàn)的類(lèi)和構(gòu)件。
(13) 包圖:包圖描述由模型本身分解而成的組織單元,以及它們之間的依賴(lài)關(guān)系。
(14)交互概覽圖:交互概覽圖是活動(dòng)圖和順序圖的混合物。
10、UML視圖: 5個(gè)系統(tǒng)視圖:
(1) 邏輯視圖:邏輯視圖也稱(chēng)為設(shè)計(jì)視圖,它表示了設(shè)計(jì)模型中在架構(gòu)方面具有重要意義的部分,即類(lèi)、子系統(tǒng)、包和用例實(shí)現(xiàn)的子集。
(2) 進(jìn)程視圖:進(jìn)程視圖是可執(zhí)行線(xiàn)程和進(jìn)程作為活動(dòng)類(lèi)的建模,它是邏輯視圖的一-次執(zhí)行實(shí)例,描述了并發(fā)與同步結(jié)構(gòu)。
(3)實(shí)現(xiàn)視圖:實(shí)現(xiàn)視圖對(duì)組成基于系統(tǒng)的物理代碼的文件和構(gòu)件進(jìn)行建模。
(4)部署視圖:部署視圖把構(gòu)件部署到一組物理節(jié)點(diǎn)上,表示軟件到硬件的映射和分布結(jié)構(gòu)。
(5) 用例視圖:用例視圖是最基本的需求分析模型。
11、00A模型獨(dú)立于具體實(shí)現(xiàn),即不考慮與系統(tǒng)具體實(shí)現(xiàn)有關(guān)的因素,這也是00A和00D的區(qū)別之所在。00A的任務(wù)是“做什么00D的任務(wù)是“怎么做”。面向?qū)ο蠓治鲭A段的核心工作是建立系統(tǒng)的用例模型與分析模型。
12、SA (結(jié)構(gòu)化分析)方法采用功能分解的方式來(lái)描述系統(tǒng)功能,在這種表達(dá)方式中,系統(tǒng)功能被分解到各個(gè)功能模塊中,通過(guò)描述細(xì)分的系統(tǒng)模塊的功能來(lái)達(dá)到描述整個(gè)系統(tǒng)功能的目的。
13、類(lèi)之間的主要關(guān)系有關(guān)聯(lián)、依賴(lài)、泛化、聚合、組合和實(shí)現(xiàn)等
(1) 關(guān)聯(lián)關(guān)系。關(guān)聯(lián)提供了不同類(lèi)的對(duì)象之間的結(jié)構(gòu)關(guān)系,它在一段時(shí)間內(nèi)將多個(gè)類(lèi)的實(shí)例連接在一起。關(guān)聯(lián)體現(xiàn)的是對(duì)象實(shí)例之間的關(guān)系,而不表示兩個(gè)類(lèi)之間的關(guān)系。
(2) 依賴(lài)關(guān)系。兩個(gè)類(lèi)A和B,如果B的變化可能會(huì)引起A的變化,則稱(chēng)類(lèi)A依賴(lài)于類(lèi)B。
(3) 泛化關(guān)系。泛化關(guān)系描述了一- 般事物與該事物中的特殊種類(lèi)之間的關(guān)系,也就是父類(lèi)與子類(lèi)之間的關(guān)系。繼承關(guān)系是泛化關(guān)系的反關(guān)系,也就是說(shuō),子類(lèi)繼承了父類(lèi),而父類(lèi)則是子類(lèi)的泛化。
(4)共享聚集。共享聚集關(guān)系通常簡(jiǎn)稱(chēng)為聚合關(guān)系,它表示類(lèi)之間的整體與部分的關(guān)系,其含義是“部分”可能同時(shí)屬于多個(gè)“整體”,“部分”與“整體”的生命周期可以不相同。
(5)組合聚集。組合聚集關(guān)系通常簡(jiǎn)稱(chēng)為組合關(guān)系,它也是表示類(lèi)之間的整體與部分的關(guān)系。與聚合關(guān)系的區(qū)別在于,組合關(guān)系中的“部分”只能屬于一個(gè)“整體”,“部分”與“整體”的生命周期相同,“部分” 隨著“整體M的創(chuàng)建而創(chuàng)建,也隨著“整體”的消亡 而消亡。
(6) 實(shí)現(xiàn)關(guān)系。實(shí)現(xiàn)關(guān)系將說(shuō)明和實(shí)現(xiàn)聯(lián)系起來(lái)。接口是對(duì)行為而非實(shí)現(xiàn)的說(shuō)明, 而類(lèi)中則包含了實(shí)現(xiàn)的結(jié)構(gòu)。一個(gè)或多個(gè)類(lèi)可以實(shí)現(xiàn)一個(gè)接口,而每個(gè)類(lèi)分別實(shí)現(xiàn)接口中的操作。
1.4.2軟件架構(gòu)設(shè)計(jì)
1、解決好軟件的復(fù)用、質(zhì)量和維護(hù)問(wèn)題,是研究軟件架構(gòu)的根本目的。軟件架構(gòu)設(shè)計(jì)的一個(gè)核心問(wèn)題是能否達(dá)到架構(gòu)級(jí)的軟件復(fù)用。
2、軟件架構(gòu)分為數(shù)據(jù)流風(fēng)格、調(diào)用/返回風(fēng)格、獨(dú)立構(gòu)件風(fēng)格、虛擬機(jī)風(fēng)格和倉(cāng)庫(kù)風(fēng)格。
(1) 數(shù)據(jù)流風(fēng)格:數(shù)據(jù)流風(fēng)格包括批處理序列和管道/過(guò)濾器兩種風(fēng)格。
(2) 調(diào)用/返回風(fēng)格:調(diào)用/返回風(fēng)格包括主程序/子程序、數(shù)據(jù)抽象和面向?qū)ο?#xff0c;以及層次結(jié)構(gòu)。
(3) 獨(dú)立構(gòu)件風(fēng)格:獨(dú)立構(gòu)件風(fēng)格包括進(jìn)程通信和事件驅(qū)動(dòng)的系統(tǒng)。
(4)虛擬機(jī)風(fēng)格:虛擬機(jī)風(fēng)格包括解釋器和基于規(guī)則的系統(tǒng)。
(5) 倉(cāng)庫(kù)風(fēng)格:倉(cāng)庫(kù)風(fēng)格包括數(shù)據(jù)庫(kù)系統(tǒng)、黑板系統(tǒng)和超文本系統(tǒng)。
3、軟件架構(gòu)評(píng)估可以只針對(duì)一個(gè)架構(gòu),也可以針對(duì)一組架構(gòu)。在架構(gòu)評(píng)估過(guò)程中,評(píng)估人員所關(guān)注的是系統(tǒng)的質(zhì)量屬性。
4、敏感點(diǎn)是一個(gè)或多個(gè)構(gòu)件(和/或構(gòu)件之間的關(guān)系)的特性,權(quán)衡點(diǎn)是影響多個(gè)質(zhì)量屬性的特性,是多個(gè)質(zhì)量屬性的敏感點(diǎn)。
5、從目前已有的軟件架構(gòu)評(píng)估技術(shù)來(lái)看,可以歸納為三類(lèi)主要的評(píng)估方式,分別是基于調(diào)查問(wèn)卷(或檢查表)的方式、基于場(chǎng)景的方式和基于度量的方式。這三種評(píng)估方式中,基于場(chǎng)景的評(píng)估方式最為常用。
6、基于場(chǎng)景的方式主要包括:架構(gòu)權(quán)衡分析法(ATAM)、 軟件架構(gòu)分析法(SAAM)和成本效益分析法(CBAM)中。 在架構(gòu)評(píng)估中,一般采用刺激、環(huán)境和響應(yīng)三方面來(lái)對(duì)場(chǎng)景進(jìn)行描述。刺激是場(chǎng)景中解釋或描述項(xiàng)目干系人怎樣引發(fā)與系統(tǒng)的交互部分,環(huán)境描述的是刺激發(fā)生時(shí)的情況,響應(yīng)是指系統(tǒng)是如何通過(guò)架構(gòu)對(duì)刺激作出反應(yīng)的。
7、基于場(chǎng)景的方式分析軟件架構(gòu)對(duì)場(chǎng)景的支持程度,從而判斷該架構(gòu)對(duì)這一場(chǎng)景所代表的質(zhì)量需求的滿(mǎn)足程度。這一評(píng)估方式考慮到了所有與系統(tǒng)相關(guān)的人員對(duì)質(zhì)量的要求,涉及的基本活動(dòng)包括確定應(yīng)用領(lǐng)域的功能和軟件架構(gòu)之間的映射,設(shè)計(jì)用于體現(xiàn)待評(píng)估質(zhì)量屬性的場(chǎng)景,以及分析軟件架構(gòu)對(duì)場(chǎng)景的支持程度。
1.4.3軟件設(shè)計(jì)
1、軟件設(shè)計(jì)分為結(jié)構(gòu)化設(shè)計(jì)與面向?qū)ο笤O(shè)計(jì)。
2、結(jié)構(gòu)化設(shè)計(jì)SD是--種面向數(shù)據(jù)流的方法,它以SRS和SA階段所產(chǎn)生的DFD和數(shù)據(jù)字典等文檔為基礎(chǔ),是一個(gè)自頂向下、逐步求精和模塊化的過(guò)程。SD分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個(gè)階段
3、在SD中,需要遵循一個(gè)基本的原則:高內(nèi)聚,低耦合
4、面向?qū)ο笤O(shè)計(jì)00D是00A方法的延續(xù),其基本思想包括抽象、封裝和可擴(kuò)展性,其中可擴(kuò)展性主要通過(guò)繼承和多態(tài)來(lái)實(shí)現(xiàn)。
5、設(shè)計(jì)模式是前人經(jīng)驗(yàn)的總結(jié),它使人們可以方便地復(fù)用成功的軟件設(shè)計(jì)。根據(jù)處理范圍不同,設(shè)計(jì)模式可分為類(lèi)模式和對(duì)象模式。根據(jù)目的和用途不同,設(shè)計(jì)模式可分為創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式三種。創(chuàng)建型模式主要用于創(chuàng)建對(duì)象;結(jié)構(gòu)型模式主要用于處理類(lèi)或?qū)ο蟮慕M合;行為型模式主要用于描述類(lèi)或?qū)ο蟮慕换ヒ约奥氊?zé)的分配。
1.4. 4軟件工程的過(guò)程管理
1、階段式模型
2、連續(xù)式模型
1.4.5軟件測(cè)試及其管理
1、每個(gè)測(cè)試用例應(yīng)包括名稱(chēng)和標(biāo)識(shí)、測(cè)試追蹤、用例說(shuō)明、測(cè)試的初始化要求、測(cè)試的輸入、期望的測(cè)試結(jié)果、評(píng)價(jià)測(cè)試結(jié)果的準(zhǔn)則、操作過(guò)程、前提和約束、測(cè)試終止條件。期望的測(cè)試結(jié)果、評(píng)價(jià)測(cè)試結(jié)果的準(zhǔn)則、操作過(guò)程、前提和約束、測(cè)試終止條件。
2、軟件測(cè)試方法可分為靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試。靜態(tài)測(cè)試是指被測(cè)試程序不在機(jī)器上運(yùn)行,而采用人工檢測(cè)和計(jì)算機(jī)輔助靜態(tài)分析的手段對(duì)程序進(jìn)行檢測(cè)。靜態(tài)測(cè)試包括對(duì)文檔的靜態(tài)測(cè)試和對(duì)代碼的靜態(tài)測(cè)試。對(duì)文檔的靜態(tài)測(cè)試主要以檢查單的形式進(jìn)行,而對(duì)代碼的靜態(tài)測(cè)試一般采用桌前檢查、代碼走查和代碼審查。
3、動(dòng)態(tài)測(cè)試是指在計(jì)算機(jī)上實(shí)際運(yùn)行程序進(jìn)行軟件測(cè)試,一般采用白盒測(cè)試和黑盒測(cè)試方法。白盒測(cè)試也稱(chēng)為結(jié)構(gòu)測(cè)試,主要用于軟件單元測(cè)試中。它的主要思想是,將程序看作是一個(gè)透明的白盒,測(cè)試人員完全清楚程序的結(jié)構(gòu)和處理算法,按照程序內(nèi)部邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試用例。白盒測(cè)試方法主要有控制流測(cè)試、數(shù)據(jù)流測(cè)試和程序變異測(cè)試等。另外,使用靜態(tài)測(cè)試的方法也可以實(shí)現(xiàn)白盒測(cè)試。例如,使用人工檢查代碼的方法來(lái)檢查代碼的邏輯問(wèn)題,也屬于白盒測(cè)試的范疇。白盒測(cè)試方法中,最常用的技術(shù)是邏輯覆蓋,即使用測(cè)試數(shù)據(jù)運(yùn)行被測(cè)程序,考察對(duì)程序邏輯的覆蓋程度。主要的覆蓋標(biāo)準(zhǔn)有語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、條件/判定覆蓋、條件組合覆蓋、修正的條件/判定覆蓋和路徑覆蓋等。
4、黑盒測(cè)試也稱(chēng)為功能測(cè)試,主要用于集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試中。黑盒測(cè)試將程序看作是一個(gè)不透明的黑盒,完全不考慮(或不了解)程序的內(nèi)部結(jié)構(gòu)和處理算法。一般包括等價(jià)類(lèi)劃分、邊界值分析、判定表、因果圖、狀態(tài)圖、隨機(jī)測(cè)試、猜錯(cuò)法和正交試驗(yàn)法等。
5、軟件測(cè)試可分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、配置項(xiàng)測(cè)試和回歸測(cè)試等類(lèi)別。
(1)單元測(cè)試。單元測(cè)試也稱(chēng)為模塊測(cè)試。
(2) 集成測(cè)試。集成測(cè)試的目的是檢查模塊之間,以及模塊和已集成的軟件之間的接口關(guān)系。
(3)確認(rèn)測(cè)試。確認(rèn)測(cè)試主要用于驗(yàn)證軟件的功能、性能和其他特性是否與用戶(hù)需求一致。根據(jù)用戶(hù)的參與程度,通常包括以下類(lèi)型。
內(nèi)部確認(rèn)測(cè)試。內(nèi)部確認(rèn)測(cè)試主要由軟件開(kāi)發(fā)組織內(nèi)部按照SRS進(jìn)行測(cè)試。
Alpha測(cè)試和Beta測(cè)試。對(duì)于通用產(chǎn)品型的軟件開(kāi)發(fā)而言,Alpha測(cè)試是指由用戶(hù)在開(kāi)發(fā)環(huán)境下進(jìn)行測(cè)試,通過(guò)Alpha測(cè)試以后的產(chǎn)品通常稱(chēng)為Alpha版;Beta測(cè)試是指由用戶(hù)在實(shí)際使用環(huán)境下進(jìn)行測(cè)試,通過(guò)Beta測(cè)試的產(chǎn)品通常稱(chēng)為Beta版。一般在通過(guò)Beta測(cè)試后,才能把產(chǎn)品發(fā)布或交付給用戶(hù)。
驗(yàn)收測(cè)試。驗(yàn)收測(cè)試是指針對(duì)SRS,在交付前以用戶(hù)為主進(jìn)行的測(cè)試。其測(cè)試對(duì)象為完整的、集成的計(jì)算機(jī)系統(tǒng)。
(4)系統(tǒng)測(cè)試。系統(tǒng)測(cè)試的對(duì)象是完整的、集成的計(jì)算機(jī)系統(tǒng),系統(tǒng)測(cè)試的目的是在真實(shí)系統(tǒng)工作環(huán)境下,驗(yàn)證完整的軟件配置項(xiàng)能否和系統(tǒng)正確連接,并滿(mǎn)足系統(tǒng)/子系統(tǒng)設(shè)計(jì)文檔和軟件開(kāi)發(fā)合同規(guī)定的要求。
(5)配置項(xiàng)測(cè)試。配置項(xiàng)測(cè)試的對(duì)象是軟件配置項(xiàng),配置項(xiàng)測(cè)試的目的是檢驗(yàn)軟件配置項(xiàng)與SRS的一致性。
(6) 回歸測(cè)試。回歸測(cè)試的目的是測(cè)試軟件變更之后,變更部分的正確性和對(duì)變更需求的符合性,以及軟件原有的、正確的功能、性能和其他規(guī)定的要求的不損害性。回歸測(cè)試的對(duì)象主要包括以下四個(gè)方面。
未通過(guò)軟件單元測(cè)試的軟件,在變更之后,應(yīng)對(duì)其進(jìn)行單元測(cè)試。
未通過(guò)配置項(xiàng)測(cè)試的軟件,在變更之后,首先應(yīng)對(duì)變更的軟件單元進(jìn)行測(cè)試,然后再進(jìn)行相關(guān)的集成測(cè)試和配置項(xiàng)測(cè)試。
未通過(guò)系統(tǒng)測(cè)試的軟件,在變更之后,首先應(yīng)對(duì)變更的軟件單元進(jìn)行測(cè)試,然后再進(jìn)行相關(guān)的集成測(cè)試、配置項(xiàng)測(cè)試和系統(tǒng)測(cè)試。
因其他原因進(jìn)行變更之后的軟件單元,也首先應(yīng)對(duì)變更的軟件單元進(jìn)行測(cè)試,然后再進(jìn)行相關(guān)的軟件測(cè)試。
6、與傳統(tǒng)的結(jié)構(gòu)化系統(tǒng)相比,00系統(tǒng)具有三個(gè)明顯特征,即封裝性、繼承性與多態(tài)性。正是由于這三個(gè)特征,給00系 統(tǒng)的測(cè)試帶來(lái)了一系列的困難。
7、常用的軟件調(diào)試策略可以分為蠻力法、回溯法和原因排除法三類(lèi)。軟件調(diào)試與測(cè)試的區(qū)別主要體現(xiàn)在以下幾個(gè)方面。
(1) 測(cè)試的目的是找出存在的錯(cuò)誤,而調(diào)試的目的是定位錯(cuò)誤并修改程序以修正錯(cuò)誤。
(2) 調(diào)試是測(cè)試之后的活動(dòng),測(cè)試和調(diào)試在目標(biāo)、方法和思路.上都有所不同。
(3)測(cè)試從一個(gè)已知的條件開(kāi)始,使用預(yù)先定義的過(guò)程,有預(yù)知的結(jié)果;調(diào)試從一-個(gè)未知的條件開(kāi)始,結(jié)束的過(guò)程不可預(yù)計(jì)。
(4)測(cè)試過(guò)程可以事先設(shè)計(jì),進(jìn)度可以事先確定;調(diào)試不能描述過(guò)程或持續(xù)時(shí)間。
8、軟件測(cè)試的管理包括過(guò)程管理、配置管理和評(píng)審工作。
(1)過(guò)程管理。過(guò)程管理包括測(cè)試活動(dòng)管理和測(cè)試資源管理。軟件測(cè)試應(yīng)由相對(duì)獨(dú)立的人員進(jìn)行。軟件測(cè)試人員應(yīng)包括測(cè)試項(xiàng)目負(fù)責(zé)人、測(cè)試分析員、測(cè)試設(shè)計(jì)員、測(cè)試程序員、測(cè)試員、測(cè)試系統(tǒng)管理員和配置管理員等。
(2)配置管理。應(yīng)按照軟件配置管理的要求,將測(cè)試過(guò)程中產(chǎn)生的各種工作產(chǎn)品納入配置管理。由開(kāi)發(fā)組織實(shí)施的軟件測(cè)試,應(yīng)將測(cè)試工作產(chǎn)品納入軟件項(xiàng)目的配置管理;由獨(dú)立測(cè)試組織實(shí)施的軟件測(cè)試,應(yīng)建立配置管理庫(kù),將被測(cè)試對(duì)象和測(cè)試工作產(chǎn)品納入配置管理。
(3)評(píng)審。測(cè)試過(guò)程中的評(píng)審包括測(cè)試就緒評(píng)審和測(cè)試評(píng)審。測(cè)試就緒評(píng)審是指在測(cè)試執(zhí)行前對(duì)測(cè)試計(jì)劃和測(cè)試說(shuō)明等進(jìn)行評(píng)審,評(píng)審測(cè)試計(jì)劃的合理性和測(cè)試用例的正確性、完整性和覆蓋充分性,以及測(cè)試組織、測(cè)試環(huán)境和設(shè)備、工具是否齊全并符合技術(shù)要求等;測(cè)試評(píng)審是指在測(cè)試完成后,評(píng)審測(cè)試過(guò)程和測(cè)試結(jié)果的有效性,確定是否達(dá)到測(cè)試目的,主要對(duì)測(cè)試記錄和測(cè)試報(bào)告進(jìn)行評(píng)審。
1.4.6軟件集成技術(shù)
1、企業(yè)應(yīng)用集成EAI包括表示集成、數(shù)據(jù)集成、控制集成和業(yè)務(wù)流程集成等多個(gè)層次和方面。當(dāng)
然,也可以在多個(gè)企業(yè)之間進(jìn)行應(yīng)用集成。
(1)表示集成也稱(chēng)為界面集成,是黑盒集成,無(wú)須了解程序與數(shù)據(jù)庫(kù)的內(nèi)部構(gòu)造。常用的集成
技術(shù)主要有屏幕截取和輸入模擬技術(shù)。
(2) 數(shù)據(jù)集成是白盒集成
(3)控制集成也稱(chēng)為功能集成或應(yīng)用集成,是在業(yè)務(wù)邏輯層上對(duì)應(yīng)用系統(tǒng)進(jìn)行集成的。集成處可能只需簡(jiǎn)單使用公開(kāi)的API (應(yīng) 用程序編程接口)就可以訪(fǎng)問(wèn),當(dāng)然也可能需要添加附加的代碼來(lái)實(shí)現(xiàn)。控制集成是黑盒集成。控制集成與表示集成、數(shù)據(jù)集成相比,靈活性更高。表示集成和數(shù)據(jù)集成適用的環(huán)境下,都適用于控制集成。但是,由于控制集成是在業(yè)務(wù)邏輯層進(jìn)行的,其復(fù)雜度更高一些。
(4) 業(yè)務(wù)流程集成
業(yè)務(wù)流程集成也稱(chēng)為過(guò)程集成,這種集成超越了數(shù)據(jù)和系統(tǒng),它由一系列基于標(biāo)準(zhǔn)的、統(tǒng)一數(shù)據(jù)格式的工作流組成。當(dāng)進(jìn)行業(yè)務(wù)流程集成時(shí),企業(yè)必須對(duì)各種業(yè)務(wù)信息的交換進(jìn)行定義、授權(quán)和管理,以便改進(jìn)操作、減少成本、提高響應(yīng)速度。
(5) 企業(yè)之間的應(yīng)用集成
EAI技術(shù)可以適用于大多數(shù)要實(shí)施電子商務(wù)的企業(yè),以及企業(yè)之間的應(yīng)用集成。EAI使得應(yīng)用集成架構(gòu)里的客戶(hù)和業(yè)務(wù)伙伴都可以通過(guò)集成供應(yīng)鏈內(nèi)的所有應(yīng)用和數(shù)據(jù)庫(kù)實(shí)現(xiàn)信息共享。也就是說(shuō),能夠使企業(yè)充分利用外部資源。
請(qǐng)大家認(rèn)真學(xué)習(xí)1.4節(jié)的,為了能夠快速準(zhǔn)確的找到我的文章大家可以關(guān)注我,我會(huì)每天進(jìn)行更新。
總結(jié)
以上是生活随笔為你收集整理的mave工程中的一个类调用另一个聚合工程的一个类_信息系统管理工程师备考分享(材料重点精炼)——第一章信息化和信息系统(4)...的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: carbon 验证时间格式_接口测试:用
- 下一篇: httpinvoker远程调用超时_RP