天津理工大學(xué)-軟件工程總結(jié)考試

1、軟件過程的步驟或基本活動(dòng)：1.軟件描述 2.軟件設(shè)計(jì)和實(shí)現(xiàn) 3.軟件有效性驗(yàn)證 4.軟件進(jìn)化軟件生命周期或軟件需求過程 1.需求分析和定義2.系統(tǒng)和軟件設(shè)計(jì)3.實(shí)現(xiàn)和單元測試4.集成和系統(tǒng)測試5.運(yùn)行和維護(hù)增量式開發(fā)過程的好處是：1客戶無需等到整個(gè)系統(tǒng)的實(shí)現(xiàn)。第一個(gè)增量會(huì)滿足他們大多數(shù)關(guān)鍵的需求，因此，軟件馬上就能使用。2.客戶可以將早期的增量作為原型，從中獲得對后面系統(tǒng)增量的需求經(jīng)驗(yàn)。3.項(xiàng)目總體性失敗的風(fēng)險(xiǎn)比較低。雖然可能在一些增量中遇到問題，但是其他一些增量將會(huì)成功的交付給客戶4.因?yàn)榫哂凶罡邇?yōu)先權(quán)的服務(wù)被首先交付，而后面的增量也不斷被集成進(jìn)來，這就使得最重要的系統(tǒng)服務(wù)肯定接受了最多的測

2、試。這就意味著在系統(tǒng)的最重要的部分，客戶不太可能遇到軟件失敗。第一章軟件工程和計(jì)算機(jī)科學(xué)的區(qū)別： 計(jì)算機(jī)科學(xué)側(cè)重理論和基礎(chǔ)，而軟件工程則側(cè)重于軟件開發(fā)和交付的實(shí)際活動(dòng)軟件工程和系統(tǒng)工程的區(qū)別： 系統(tǒng)工程側(cè)重基于計(jì)算機(jī)系統(tǒng)開發(fā)的所有方面，包括硬件，軟件，和處理工程。軟件工程只是它的一部分1.軟件是計(jì)算機(jī)程序和所有使程序正確運(yùn)行所需要的相關(guān)文檔和配置信息軟件產(chǎn)品分為：Generic通用、Bespoke (custom)定制2、軟件工程是一門工程學(xué)科，涉及軟件生產(chǎn)的各個(gè)方面。軟件工程人員運(yùn)用的是系統(tǒng)的、有組織的工作方法。6、軟件過程模型 從特定角度提出的軟件過程的簡化表示形式Examples of

3、process perspectives are 工作流模型 數(shù)據(jù)流或活動(dòng)模型 角色/動(dòng)作模型軟件開發(fā)模型Waterfall瀑布型開發(fā)方法 Iterative development迭代式開發(fā)方法 Component-based software engineering（CBSE）基于組件的軟件工程7、the costs of software engineering軟件工程的成本軟件開發(fā)成本約占60%，測試成本占40%。對于定制軟件而言，進(jìn)化成本常常高于開發(fā)成本。8、software engineering methods軟件工程方法：.軟件開發(fā)的結(jié)構(gòu)化研究方法，包括：系統(tǒng)模型、標(biāo)記法、規(guī)劃

4、、設(shè)計(jì)忠告和過程指南9、CASE (Computer-Aided Software Engineering)計(jì)算機(jī)輔助軟件工程： 旨在使軟件過程活動(dòng)自動(dòng)化的軟件系統(tǒng)。CASE常用作方法支持10、the attributes of good software優(yōu)良軟件的特點(diǎn)：軟件應(yīng)具有用戶所需的功能與性能，而且應(yīng)該可維護(hù)、可靠、可用11、key challenges facing software engineering軟件工程面臨的主要挑戰(zhàn)：Legacy遺留 Heterogeneity多樣性挑戰(zhàn) delivery交付上的挑戰(zhàn) trust信任的挑戰(zhàn)2Software engineering cos

5、t analysis 軟件工程成本分析定制軟件：對于瀑布模型，系統(tǒng)描述、設(shè)計(jì)、實(shí)現(xiàn)和集成的成本獨(dú)立測算，其中系統(tǒng)集成和測試活動(dòng)所需的費(fèi)用最高，約占40%。對于迭代式開發(fā)，系統(tǒng)描述、設(shè)計(jì)和開發(fā)之間沒有嚴(yán)格的劃分界限，但系統(tǒng)描述的成本降低。在軟件開發(fā)活動(dòng)中，系統(tǒng)描述、實(shí)際、實(shí)現(xiàn)、集成和測試是并行的。基于組件的軟件開發(fā)，描述部分約20%，開發(fā)成本約30%，集成和測試約50%除系統(tǒng)開發(fā)成本之外，在軟件投入使用后軟件的變更也需要成本。進(jìn)化成本對許多使用期限長的軟件系統(tǒng)而言，有可能超過開發(fā)成本的34倍。相對于小的業(yè)務(wù)系統(tǒng)就降低許多了。為個(gè)人計(jì)算機(jī)配置的軟件產(chǎn)品這類產(chǎn)品通常基于一個(gè)概要描述，用進(jìn)化式開發(fā)方法

6、開發(fā)。描述成本相對較低，但由于要用在不同的配置中，所以測試成本比較多。通用軟件產(chǎn)品進(jìn)化成本很難估算。多數(shù)情況下，產(chǎn)品的進(jìn)化過程并不大。通用軟件的進(jìn)化成本不能像定制軟件一樣獨(dú)立評(píng)估，而是作為該系統(tǒng)的下一個(gè)版本的開發(fā)成本。第二章1System engineering process 系統(tǒng)工程過程系統(tǒng)退役系統(tǒng)進(jìn)化系統(tǒng)安裝系統(tǒng)集成子系統(tǒng)開發(fā)系統(tǒng)設(shè)計(jì)需求定義2System modeling 系統(tǒng)建模在系統(tǒng)需求和設(shè)計(jì)活動(dòng)中，系統(tǒng)被建模成一系列組件和組件間的關(guān)系。通常是以圖的形式描述在系統(tǒng)體系結(jié)構(gòu)模型中。系統(tǒng)體系結(jié)構(gòu)模型通常以方塊圖來描述，展現(xiàn)一些主要的子系統(tǒng)以及這些子系統(tǒng)之間的關(guān)聯(lián)。3System evo

7、lution 系統(tǒng)進(jìn)化大型和復(fù)雜的系統(tǒng)都會(huì)有一個(gè)非常長的生存期。在整個(gè)生存期內(nèi)，必須改進(jìn)原有的系統(tǒng)需求中的錯(cuò)誤進(jìn)而滿足出現(xiàn)的新需求。使用系統(tǒng)的機(jī)構(gòu)可能重新改組并且因此一種不同的方式使用系統(tǒng)4System procurement process 系統(tǒng)采購過程系統(tǒng)的采購過程主要是對機(jī)構(gòu)以最佳方式獲得系統(tǒng)做出決策并決定系統(tǒng)的最佳提供商簽訂開發(fā)合同合同談判選擇投標(biāo)人發(fā)出招標(biāo)請求選擇供應(yīng)商發(fā)出招標(biāo)請求選擇系統(tǒng)調(diào)整需求對現(xiàn)有系統(tǒng)做市場調(diào)查第四章進(jìn)化式開發(fā)有兩個(gè)基本類型; 探索式開發(fā) 其目標(biāo)是與用戶一起工作，共同探索系統(tǒng)需求，知道最后交付系統(tǒng)。這類開發(fā)是從需求較清楚的部分開始，根據(jù)用戶的建議逐漸向系統(tǒng)中添加

8、功能。 拋棄式原型 這種開發(fā)方法的目標(biāo)是理解用戶需求，然后在給系統(tǒng)需求有更深刻理解時(shí)，能夠很快在軟件過程的好處是描述可以不斷地補(bǔ)充完整?；谶M(jìn)化式方法的軟件過程的好處是描述可以不斷地補(bǔ)充完善 存在兩個(gè)問題 1.過程不可見 管理者需要經(jīng)常性得交付來把握進(jìn)度，如果系統(tǒng)開發(fā)速度很快，要產(chǎn)生每個(gè)版本的文檔來反應(yīng)變更就很不劃算了一、軟件工程模型software process model二、（1）waterfall model瀑布模型：直到上一階段完成，下一階段才能啟動(dòng)（2）Evolutionary development進(jìn)化式開發(fā)：優(yōu)勢：描述可以不斷補(bǔ)充完善劣勢：過程不可見;系統(tǒng)結(jié)構(gòu)通常較差進(jìn)化式開發(fā)

9、的兩種基本類型：Exploratory development 探索式開發(fā)、Throw-away prototyping拋棄式原型（3）Component-based software engineering基于組件的軟件工程（Reuse-oriented development面向復(fù)用的軟件開發(fā)方法）其過程模型如下圖：三、Spiral development螺旋式開發(fā)它不是將軟件過程用一系列活動(dòng)和活動(dòng)間的回溯來表示，而是將過程用螺旋線表示。每個(gè)回路表示軟件過程的一個(gè)階段。2、四部分：目標(biāo)設(shè)置 風(fēng)險(xiǎn)評(píng)估和規(guī)避、開發(fā)和有效性驗(yàn)證、規(guī)劃.四、Software validation軟件有效性驗(yàn)證：是

10、要看系統(tǒng)是否符合它的描述以及系統(tǒng)是否符合客觀的預(yù)測目標(biāo)。5、 測試過程的階段：組件測試、系統(tǒng)、接收測試五、Activities in CASE (Computer-aided software engineering) 六、CASE classification分類：從功能角度看；從過程角度看；從集成角度看Fuggetta提出的分類：工具，工作平臺(tái),環(huán)境第五章一、 Management activities管理活動(dòng).提出書面建議 .項(xiàng)目規(guī)劃和調(diào)度 .項(xiàng)目成本 項(xiàng)目監(jiān)督和審評(píng) .人員選擇和評(píng)價(jià) .寫作并稱述工作報(bào)告二、 Types of planning計(jì)劃的類型質(zhì)量計(jì)劃、有效性驗(yàn)證計(jì)劃、配置管

11、理計(jì)劃、維護(hù)計(jì)劃、人員開發(fā)計(jì)劃三、 Milestones in the requirements process需求過程里程碑：四、 Project scheduling process項(xiàng)目調(diào)度五、 three main project management： 項(xiàng)目風(fēng)險(xiǎn) 產(chǎn)品風(fēng)險(xiǎn) 業(yè)務(wù)風(fēng)險(xiǎn)types of risk in project management：技術(shù)風(fēng)險(xiǎn)、人員風(fēng)險(xiǎn)、機(jī)構(gòu)風(fēng)險(xiǎn)、需求、估算.第六章1Functional requirement and examples 功能需求和舉例 功能需求描述系統(tǒng)所預(yù)期提供的功能或服務(wù)。取決于開發(fā)的軟件類型，軟件未來的用戶以及開發(fā)的系統(tǒng)類型。LI

12、BSYS-大學(xué)圖書館系統(tǒng)幾種功能需求：用戶能從總的數(shù)據(jù)庫中查詢或者是選擇其中的一個(gè)子集系統(tǒng)能提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)每次借閱能對應(yīng)一個(gè)獨(dú)特的識(shí)別符(order_id)，可拷貝到用戶賬戶的常備儲(chǔ)存區(qū)內(nèi)2Non-functional requirement and examples 非功能需求和舉例對系統(tǒng)提供的服務(wù)或功能給出的約束，與系統(tǒng)的總體特性相關(guān)。圖書館系統(tǒng)的LIBSYS的產(chǎn)品需求，機(jī)構(gòu)需求和外部需求的實(shí)例：產(chǎn)品需求：它應(yīng)該能將所有APSE和用戶之間的必須的通信用標(biāo)準(zhǔn)的Ada字符集表達(dá)機(jī)構(gòu)需求：系統(tǒng)開發(fā)過程和可交付的文檔將遵照XYZCo-SP-STAN-95中的相關(guān)定義外部需求：系

13、統(tǒng)不應(yīng)該對系統(tǒng)的操作人員公開客戶出名字和索引代碼之外的任何個(gè)人的信息三、types of Non-functional requirement四、metrics in Non-functional requirement Requirements measures非功能需求度量性質(zhì)度量方法速度每秒處理的事務(wù)用戶/事件響應(yīng)時(shí)間屏幕刷新時(shí)間規(guī)模K字節(jié)RAM芯片數(shù)易用性培訓(xùn)時(shí)間幫助畫面數(shù)可靠性失敗平均時(shí)間無效的概率失敗發(fā)生率有效性魯棒性失敗之后的重啟次數(shù)事件引起失敗的百分比失敗中數(shù)據(jù)崩潰的可能性可移植性依賴于目標(biāo)的語句百分比目標(biāo)系統(tǒng)數(shù)5Documents used in software requi

14、rements 軟件需求文檔軟件需求文檔是對系統(tǒng)開發(fā)者應(yīng)當(dāng)實(shí)現(xiàn)的內(nèi)容的正式陳述。包括系統(tǒng)的用戶需求和一個(gè)詳細(xì)的系統(tǒng)需求描述。需求文檔中內(nèi)容的詳細(xì)程度，取決于所要開發(fā)的系統(tǒng)的類型，以及所使用的開發(fā)過程。第七章1The process of requirement engineering 需求工程的過程系統(tǒng)可行性研究；需求導(dǎo)出和分析；需求描述；需求有效性驗(yàn)證需求有效性驗(yàn)證可行性研究需求描述用戶需求和系統(tǒng)需求可行性報(bào)告需求文檔需求導(dǎo)出和分析系統(tǒng)模型2The main content of feasibility studies 可行性研究的主要內(nèi)容進(jìn)行一項(xiàng)可行性研究包括信息評(píng)估，信息匯總和報(bào)告生成3

15、Process activities in requirement elicitation and analysis 需求導(dǎo)出和分析的過程活動(dòng)需求發(fā)現(xiàn)；需求分類和組織；優(yōu)先排序和沖突解決；需求文檔編制4Requirement validation techniques(three) 需求有效性驗(yàn)證技術(shù)需求評(píng)審；原型建立；測試用例生成5Requirement change management 需求變更管理三個(gè)基本階段：問題分析和變更描述過程：始于一個(gè)被識(shí)別的需求問題或是一份明確的變更提議變更分析和成本計(jì)算：使用可追溯性信息和系統(tǒng)需求的一般知識(shí)對被提議的變更產(chǎn)生的影響進(jìn)行評(píng)估變更實(shí)現(xiàn)：必要的話，

16、需求文檔，系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)都要做修改第八章* 1Principle system model 上下文模型context model 行為模型 Behavioural models數(shù)據(jù)模型 data model 對象模型 object model 結(jié)構(gòu)化方法 structured methods2Examples of system models(5) 系統(tǒng)模型實(shí)例數(shù)據(jù)流模型(data processing model)；組成模型(composition model)；體系結(jié)構(gòu)模型(architectural model)；分類模型(classfication model)；激勵(lì)-響應(yīng)模型(sti

17、mulate/response model)3Definition of data-flow models 數(shù)據(jù)流模型的定義（自上而下的模型）數(shù)據(jù)流模型是從功能角度來看待系統(tǒng)而得到的模型表示，對數(shù)據(jù)的每一個(gè)變換用一個(gè)函數(shù)或過程來描述，描述了所發(fā)生的完整的行動(dòng)序列，從對輸入的處理到系統(tǒng)的響應(yīng)。第十一章1 Content of architectural models 體系結(jié)構(gòu)模型的內(nèi)容靜態(tài)結(jié)構(gòu)模型；動(dòng)態(tài)結(jié)構(gòu)模型；接口模型；關(guān)系模型；分布模型2 Major components of Client-sever model 客戶機(jī)/服務(wù)器模型的主要組成部分一組給其他子系統(tǒng)提供服務(wù)的單機(jī)服務(wù)器；一組向

18、服務(wù)器請求服務(wù)的客戶機(jī)；一個(gè)連接客戶機(jī)和服務(wù)器的網(wǎng)站第十七章1 Describe incremental development and prototyping by figure 用圖形描述增量式開發(fā)和原型構(gòu)造可執(zhí)行原型+系統(tǒng)描述交付的系統(tǒng)概要需求拋棄式原型構(gòu)造進(jìn)化式開發(fā)2 Tools included in a Rapid Application Development 快速應(yīng)用開發(fā)的工具數(shù)據(jù)庫編程語言；界面生成器；與辦公應(yīng)用的連接；報(bào)告生成器第二十三章1Model of the software testing process 軟件測試過程的模型系統(tǒng)測試；組件測試；測試用例設(shè)計(jì)；測試自動(dòng)

19、化設(shè)計(jì)測試用例將結(jié)果與測試用例進(jìn)行比較用測試數(shù)據(jù)運(yùn)行程序準(zhǔn)備測試數(shù)據(jù)測試報(bào)告測試結(jié)果測試數(shù)據(jù)測試用例2Structural testing 結(jié)構(gòu)化測試結(jié)構(gòu)化測試是根據(jù)軟件的結(jié)構(gòu)知識(shí)和實(shí)現(xiàn)知識(shí)導(dǎo)出測試的測試用例設(shè)計(jì)方法，又稱為“白盒測試”一、軟件需求分析1、需求分析的任務(wù)就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的 “做什么” 的問題。2、結(jié)構(gòu)化分析方法l 面向數(shù)據(jù)流進(jìn)行需求分析的方法l 結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析l 具體來說，結(jié)構(gòu)化分析方法就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，直到找到滿足功能要求的所有可實(shí)現(xiàn)的軟件為

20、止描述銀行取款過程的數(shù)據(jù)流圖：4、結(jié)構(gòu)花英語：是一種介于自然語言和形式化語言之間的語言，語言的正文用基本控制結(jié)構(gòu)進(jìn)行分割，加工中的操作用自然語言短語來表示其基本控制結(jié)構(gòu)有三種：簡單陳述句結(jié)構(gòu)：避免復(fù)合語句；重復(fù)結(jié)構(gòu)：while_do 或repeat_until 結(jié)構(gòu)。判定結(jié)構(gòu)：if_then_else 或case_of 結(jié)構(gòu)；例子：商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”：if 發(fā)貨單金額超過$500 then if 欠款超過了60天 then 在償還欠款前不予批準(zhǔn) else （欠款未超期） 發(fā)批準(zhǔn)書，發(fā)貨單 else （發(fā)貨單金額未超過$500） if 欠款超過60天 then 發(fā)批準(zhǔn)書，發(fā)貨單及賒

21、欠報(bào)告 else （欠款未超期） 發(fā)批準(zhǔn)書，發(fā)貨單 5、判定表（大題）：如果數(shù)據(jù)流圖的加工需要依賴于多個(gè)邏輯條件的取值，使用判定表來描述比較合適。 例子：以“檢查發(fā)貨單”為例 二、軟件設(shè)計(jì)方法1、 軟件設(shè)計(jì)的目標(biāo)和方法根據(jù)用信息域表示的軟件需求，以及功能和性能需求，進(jìn)行數(shù)據(jù)設(shè)計(jì)、系統(tǒng)結(jié)構(gòu)設(shè)計(jì)、過程設(shè)計(jì)。軟件設(shè)計(jì)任務(wù)：從工程管理角度來看，軟件設(shè)計(jì)分兩步完成l 概要設(shè)計(jì)，將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。l 詳細(xì)設(shè)計(jì)，即過程設(shè)計(jì)。通過對結(jié)構(gòu)表示進(jìn)行細(xì)化，得到軟件的詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法2、 軟件設(shè)計(jì)過程制定規(guī)范 軟件系統(tǒng)結(jié)構(gòu)的總體設(shè)計(jì) 處理方式設(shè)計(jì) 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì) 可靠性設(shè)計(jì) 編寫概要設(shè)計(jì)階段

22、的文檔 概要設(shè)計(jì)評(píng)審3、 信息隱藏：是指每個(gè)模塊的實(shí)現(xiàn)細(xì)節(jié)對于其它模塊來說是隱蔽的。也就是說，模塊中所包含的信息（包括數(shù)據(jù)和過程）不允許其它不需要這些信息的模塊使用。4、 模塊獨(dú)立性：是指軟件系統(tǒng)中每個(gè)模塊只涉及軟件要求的具體的子功能, 而和軟件系統(tǒng)中其它的模塊的接口是簡單的 例如, 若一個(gè)模塊只具有單一的功能且與其它模塊沒有太多的聯(lián)系, 則稱此模塊具有模塊獨(dú)立性一般采用兩個(gè)準(zhǔn)則度量模塊獨(dú)立性。即模塊間耦合和模塊內(nèi)聚耦合是模塊之間的互相連接的緊密程度的度量。 內(nèi)聚是模塊功能強(qiáng)度(一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度)的度量。 模塊獨(dú)立性比較強(qiáng)的模塊應(yīng)是高內(nèi)聚低耦合的模塊。5、 變換型系統(tǒng)結(jié)構(gòu)

23、：變換型數(shù)據(jù)處理問題的工作過程大致分為三步，即取得數(shù)據(jù)，變換數(shù)據(jù)和給出數(shù)據(jù)。相應(yīng)于取得數(shù)據(jù)、變換數(shù)據(jù)、給出數(shù)據(jù)，變換型系統(tǒng)結(jié)構(gòu)圖由輸入、中心變換和輸出等三部分組成。6、 事務(wù)性系統(tǒng)結(jié)構(gòu)：它接受一項(xiàng)事務(wù)，根據(jù)事務(wù)處理的特點(diǎn)和性質(zhì)，選擇分派一個(gè)適當(dāng)?shù)奶幚韱卧?，然后給出結(jié)果。在事務(wù)型系統(tǒng)結(jié)構(gòu)圖中，事務(wù)中心模塊按所接受的事務(wù)的類型，選擇某一事務(wù)處理模塊執(zhí)行。各事務(wù)處理模塊并列。每個(gè)事務(wù)處理模塊可能要調(diào)用若干個(gè)操作模塊，而操作模塊又可能調(diào)用若干個(gè)細(xì)節(jié)模塊。7、 變換分析方法由以下四步組成：l 重畫數(shù)據(jù)流圖；l 區(qū)分有效(邏輯)輸入、有效(邏輯)輸出和中心變換部分；l 進(jìn)行一級(jí)分解，設(shè)計(jì)上層模塊；l 進(jìn)行

24、二級(jí)分解，設(shè)計(jì)輸入、輸出和中心變換部分的中、下層模塊。8、 文件設(shè)計(jì)文件設(shè)計(jì)過程主要分為兩個(gè)階段。第一個(gè)階段是文件的邏輯設(shè)計(jì)，主要在概要設(shè)計(jì)階段實(shí)施。一般要根據(jù)文件的特性，來確定文件的組織方式。順序文件：連續(xù)文件、串聯(lián)文件。 直接存取文件：無關(guān)鍵字直接存取文件、帶關(guān)鍵字直接存取文件、桶式直接存取文件。索引順序文件：其基本數(shù)據(jù)記錄按順序文件組織，記錄排列順序必須按關(guān)鍵字值升序或降序安排，且具有索引部分，也按同一關(guān)鍵字進(jìn)行索引。 分區(qū)文件：這類文件主要用于存放程序。它由若干稱為成員的順序組織的記錄組和索引組成。二、 程序編碼1、 結(jié)構(gòu)化程序設(shè)計(jì)結(jié)構(gòu)化程序設(shè)計(jì)主要包括兩方面：l 在編寫程序時(shí)，強(qiáng)調(diào)使

25、用幾種基本控制結(jié)構(gòu)，通過組合嵌套，形成程序的控制結(jié)構(gòu)。盡可能避免使用GOTO語句。l 在程序設(shè)計(jì)過程中，盡量采用自頂向下和逐步細(xì)化的原則，由粗到細(xì)，一步步展開。2、程序設(shè)計(jì)風(fēng)格：程序?qū)嶋H上也是一種供人閱讀的文章，有一個(gè)文章的風(fēng)格問題。應(yīng)該使程序具有良好的風(fēng)格。 源程序文檔化、 數(shù)據(jù)說明、 語句結(jié)構(gòu)、 輸入輸出方法3、程序復(fù)雜性度量程序復(fù)雜性主要指模塊內(nèi)程序的復(fù)雜性。它直接關(guān)聯(lián)到軟件開發(fā)費(fèi)用的多少，開發(fā)周期的長短和軟件內(nèi)部潛伏錯(cuò)誤的多少。減少程序復(fù)雜性，可提高軟件的簡單性和可理解性，并使軟件開發(fā)費(fèi)用減少，開發(fā)周期縮短，軟件內(nèi)部潛藏錯(cuò)誤減少。三、 軟件測試1、 軟件測試目的：基于不同的立場，存在著

26、兩種完全不同的測試目的：從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。測試的目的是l 想以最少的時(shí)間和人力，系統(tǒng)地找出軟件中潛在的各種錯(cuò)誤和缺陷。如果我們成功地實(shí)施了測試，我們就能夠發(fā)現(xiàn)軟件中的錯(cuò)誤。l 測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符合。l 實(shí)施測試收集到的測試結(jié)果數(shù)據(jù)為可靠性分析提供了依據(jù)。l 測試不能表明軟件中不存在錯(cuò)誤，它只能說明軟件中存在錯(cuò)誤2、 測試與軟件工程各階段的關(guān)系n 軟件開發(fā)

27、過程是一個(gè)自頂向下，逐步細(xì)化的過程n 軟件計(jì)劃階段定義軟件作用域n 軟件需求分析建立軟件信息域、功能和性能需求、約束等n 軟件設(shè)計(jì)n 把設(shè)計(jì)用某種程序設(shè)計(jì)語言轉(zhuǎn)換成程序代碼3、 黑盒測試這種方法是把測試對象看作個(gè)黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數(shù)據(jù)驅(qū)動(dòng)測試。n 黑盒測試方法是在程序接口上進(jìn)行測試，主要是為了發(fā)現(xiàn)以下錯(cuò)誤:u 是否有不正確或遺漏了的功能?u 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果?u 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤?u 性能上是否能夠滿

28、足要求?u 是否有初始化或終止性錯(cuò)誤?n 用黑盒測試發(fā)現(xiàn)程序中的錯(cuò)誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。4、 白盒測試：此方法把測試對象看做一個(gè)透明的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序的狀態(tài)，確定實(shí)際的狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試。軟件人員使用白盒測試方法，主要想對程序模塊進(jìn)行如下的檢查：u 對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一次；u 對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；u 在循環(huán)的邊界和運(yùn)

29、行界限內(nèi)執(zhí)行循環(huán)體；u 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等。5、 邏輯覆蓋：邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計(jì)測試用例的技術(shù)。它屬白盒測試。語句覆蓋、 判定覆蓋、條件覆蓋判定條件覆蓋、 條件組合覆蓋、 路徑覆蓋。L1 ( a à c à e )= (A>1) and (B=0) and (A=2) or (X/A>1)= (A>1) and (B=0) and (A=2) or (A>1) and (B=0) and (X/A>1)= (A=2) and (B=0) or (A>1) and (B=0) and (X/A>1) L2 ( aà b à d )= not(A&