第1章軟件測試基礎(chǔ)本章內(nèi)容2軟件質(zhì)量軟件測試軟件缺陷二三一本章內(nèi)容3軟件質(zhì)量軟件測試軟件缺陷二三一軟件的復(fù)雜性軟件復(fù)雜性的主要三個方面：軟件規(guī)模無限膨脹軟件失效行為的復(fù)雜軟件工程過程的復(fù)雜4軟件的復(fù)雜性軟件規(guī)模無限膨脹5大致時間軟件名稱代碼規(guī)模/行20世紀(jì)90年代天基紅外系統(tǒng)衛(wèi)星軟件2.5萬2009年波音787飛機航空電控系統(tǒng)650萬2010年通用公司的福特汽車車載計算軟件1000萬2015年F-35機載軟件1200萬2020年Linux內(nèi)核代碼2700萬最著名的8大嚴(yán)重軟件錯誤事件-1豐田（Toyota）的意外加速問題早在1992年，駕駛員就報告他們的豐田汽車出現(xiàn)意外的加速（UA）問題。從那時起，由于導(dǎo)致UA的硬件和軟件問題的結(jié)合，最終有52人在豐田車禍中喪生。MichaelBarr和PhilipKoopman教授在2013年Bookout與Toyota的訴訟中擔(dān)任專家證人。他們發(fā)現(xiàn)的軟件問題包括緩沖區(qū)溢出、無效指針、競爭條件和堆棧溢出。6最著名的8大嚴(yán)重軟件錯誤事件-2蘋果的“gotofail”漏洞2014年2月，Apple發(fā)布了有關(guān)SSL/TLS的安全更新。罪魁禍?zhǔn)资恰癵otofail;”導(dǎo)致后面的語句無法訪問的語句7最著名的8大嚴(yán)重軟件錯誤事件-3火星氣候軌道器（MarsClimateOrbiter）早在1999年，由美國國家航空航天局噴氣推進實驗室建造的耗資3.276億美元的火星氣候軌道器項目以錯誤的角度接近了紅色星球，導(dǎo)致了航天器的滅亡。8什么地方出了錯？發(fā)現(xiàn)工程團隊的不同部分正在使用不同的度量單位。一組研究推進器的單位是英制磅秒；另一個使用公制牛頓秒。最著名的8大嚴(yán)重軟件錯誤事件-4約克城號航空母艦（USSYorktown）1997年9月21日，Yorktown號上的“遠程數(shù)據(jù)庫管理器”中的除零錯誤使網(wǎng)絡(luò)上的所有計算機癱瘓，導(dǎo)致船舶的推進系統(tǒng)出現(xiàn)故障。9一名乘務(wù)員在數(shù)據(jù)庫中輸入一個空白字段?？瞻妆灰暈榱悖?dǎo)致數(shù)據(jù)庫程序無法處理的“除以零”異常。它中止了MicrosoftWindowsNT4.0操作系統(tǒng)，該系統(tǒng)崩潰了，所有艦船的LAN控制臺和遠程終端都崩潰了。最著名的8大嚴(yán)重軟件錯誤事件-5阿麗亞娜5火箭，航班501（Ariane5Rocket,Flight501）1996年6月，阿麗亞娜5號火箭進行了首次飛行，稱為501航班?；鸺l(fā)射后37秒自毀，導(dǎo)致任務(wù)失敗，損失約3.7億美元。失敗是由于數(shù)據(jù)從64位浮點值轉(zhuǎn)換為16位帶符號整數(shù)值而導(dǎo)致整數(shù)溢出。10最著名的8大嚴(yán)重軟件錯誤事件-6愛國者導(dǎo)彈系統(tǒng)（PatriotMissileSystem）愛國者導(dǎo)彈系統(tǒng)是旨在擊落敵機的地對空導(dǎo)彈系統(tǒng)。1991年2月，一枚敵方導(dǎo)彈襲擊了沙特阿拉伯的美國部隊兵營，當(dāng)時一連串愛國者導(dǎo)彈未能攔截進來的飛毛腿導(dǎo)彈。結(jié)果是有28名死亡士兵和100多名其他人員傷亡。11確定的原因是系統(tǒng)時鐘中的軟件錯誤——累積的時鐘漂移使系統(tǒng)運行的時間越長，惡化的情況就越多。最著名的8大嚴(yán)重軟件錯誤事件-7莫里斯蠕蟲（TheMorrisWorm）1988年，小羅伯特·莫里斯（RobertMorris，Jr.）發(fā)布了Internet蠕蟲，它雄辯地指出了Internet的脆弱性以及對更高安全性的需求。他使用gets()函數(shù)導(dǎo)致BerkeleyUnixfinger守護程序中的緩沖區(qū)溢出導(dǎo)致了數(shù)千臺計算機的癱瘓。12最著名的8大嚴(yán)重軟件錯誤事件-8放療事故（Therac-25）在1985年6月至1987年1月之間，有六名患者因計算機控制的放射治療機Therac25的大量過量輻射而嚴(yán)重受傷或喪生。檢測到的軟件問題包括競爭條件和算術(shù)溢出。13軟件質(zhì)量的內(nèi)涵14軟件質(zhì)量是客戶滿意度的體現(xiàn)客戶+質(zhì)量?軟件質(zhì)量IEEE定義，軟件質(zhì)量是： 1.系統(tǒng)、部件或者過程滿足規(guī)定需求的程度。 2.系統(tǒng)、部件或者過程滿足顧客或者用戶需要或期望的程度。另外的關(guān)于軟件質(zhì)量的定義:符合明確陳述的功能和性能需求,明確文檔化了的開發(fā)標(biāo)準(zhǔn)和所有專業(yè)開發(fā)軟件預(yù)期的隱含特征。15軟件質(zhì)量特征(ISO／IEC25010:2023)16質(zhì)量特性子特性定義與示例功能適用性功能完整性、正確性、適當(dāng)性確保功能覆蓋用戶需求性能效率時間特性、資源利用率、容量高并發(fā)系統(tǒng)的響應(yīng)速度兼容性共存性、互操作性多系統(tǒng)共享資源互不干擾交互能力包容性、可學(xué)習(xí)性、用戶粘性、容錯性支持無障礙設(shè)計可靠性成熟性、容錯性、易恢復(fù)性、可用性系統(tǒng)故障后快速恢復(fù)安全性保密性、完整性、不可抵賴性、真實性、可核查性數(shù)據(jù)加密與權(quán)限控制可維護性模塊化、易分析性、可復(fù)用性代碼低耦合設(shè)計靈活性適應(yīng)性、易安裝性、可擴展性跨平臺兼容無害性風(fēng)險識別、故障安全、安全集成高風(fēng)險系統(tǒng)自動停機保護軟件質(zhì)量特征(ISO／IEC25010:2023)功能適應(yīng)性：軟件產(chǎn)品在規(guī)定條件下滿足指定的或隱含的需求的程度17功能完備性functionalcompleteness與軟件功能覆蓋所指定任務(wù)和用戶目標(biāo)有關(guān)的屬性功能正確性functionalcorrectness與軟件按照所要求精度的提供正確結(jié)果有關(guān)的屬性功能適合性appropriateness與軟件提供的功能有助于完成指定的任務(wù)和目標(biāo)有關(guān)的屬性新增重點：強調(diào)功能需符合新興技術(shù)場景（如人工智能）的需求適應(yīng)性。軟件質(zhì)量特征(ISO／IEC25010:2023)性能效率：在規(guī)定條件下使用資源數(shù)量的程度18時間特性timebehaviour與軟件執(zhí)行其功能時響應(yīng)和處理時間以及吞吐量有關(guān)的屬性資源利用率resourceutilization與在軟件執(zhí)行其功能時所使用的資源數(shù)量及其使用時間有關(guān)的屬性容量capacity與軟件參數(shù)最大限度滿足需求有關(guān)的屬性更新：新增對能源消耗的關(guān)注（如綠色計算場景）。軟件質(zhì)量特征(ISO／IEC25010:2023)兼容性：軟件在執(zhí)行所需功能時，與其它軟件、系統(tǒng)或組件共享相同硬件或軟件環(huán)境，可以交互信息相關(guān)的屬性19共存性co-existence軟件在與其它軟件共享相同的環(huán)境與資源時執(zhí)行所需的功能，而未對其它軟件產(chǎn)生不利影響的屬性互操作性interoperability表示兩個或多個軟件或組件間交換信息與使用已交換信息相關(guān)的屬性新增：支持跨平臺技術(shù)（如容器化部署）的兼容性評估。軟件質(zhì)量特征(ISO／IEC25010:2023)交互能力：用戶與軟件之間交換信息的能力可辨識性用戶能否快速識別功能適用性可學(xué)習(xí)性用戶學(xué)習(xí)成本可操作性與用戶為操作和運行控制所花努力有關(guān)的軟件屬性用戶錯誤防止與軟件保護用戶不犯錯誤相關(guān)的屬性用戶粘性（用戶界面美觀度）界面設(shè)計對用戶體驗的持續(xù)吸引力包容性支持殘障人士的無障礙訪問軟件質(zhì)量特征(ISO／IEC25010:2023)可靠性：與在規(guī)定的一段時間和條件下，軟件維持其性能水平的能力有關(guān)的一組屬性21成熟性maturity與由軟件故障引起失效的頻度有關(guān)的軟件屬性可用性availability與軟件在使用時可操作和可訪問有關(guān)的屬性容錯性fault

tolerance與在軟件故障或違反指定接口情況下，維持規(guī)定的性能水平的能力有關(guān)的軟件屬性易恢復(fù)性recoverability與在失效發(fā)生后，重建其性能水平并恢復(fù)直接受影響數(shù)據(jù)的能力以及為達此目的所需的時間和努力有關(guān)的軟件屬性軟件質(zhì)量特征(ISO／IEC25010:2023)安全性：用戶或其它軟件在訪問一個軟件的信息和數(shù)據(jù)時，該軟件是否按照他們的類型與授權(quán)級別對信息與數(shù)據(jù)保護的相關(guān)的一組屬性保密性與軟件確保數(shù)據(jù)只對具有訪問權(quán)限用戶訪問有關(guān)的屬性完整性與軟件防止未授權(quán)訪問或修改計算機程序或數(shù)據(jù)有關(guān)的屬性不可否認性與當(dāng)某種行為或事件發(fā)生后，能夠確保該行為或事件不能否認有關(guān)的屬性可核查性與一個實體的行為可以追溯到該實體有關(guān)的軟件屬性真實性與一個主體或資源可以被證明是所生成的身份有關(guān)的軟件屬性進不來

拿不走看不懂

改不了跑不掉新增：針對AI系統(tǒng)的數(shù)據(jù)隱私保護要求。軟件質(zhì)量特征(ISO／IEC25010:2023)維護性：與進行指定的修改所需的努力有關(guān)的一組屬性模塊性指程序由若干獨立的組件構(gòu)成，當(dāng)修改一個模塊時對其它模塊的影響降到最低易修改性與進行修改、排除錯誤或適應(yīng)環(huán)境變化所需努力有關(guān)的屬性易測試性與確認已修改軟件所需的努力有關(guān)的屬性易重用性與軟件的資產(chǎn)可被其它軟件復(fù)用有關(guān)的屬性易分析性與為診斷缺陷或失效原因及為判定待修改的部分所需努力有關(guān)的屬性軟件質(zhì)量特征(ISO／IEC25010:2023)靈活性：與軟件可從某一環(huán)境轉(zhuǎn)移到另一環(huán)境的能力有關(guān)的一組屬性24適應(yīng)性adaptability與軟件無需采用有別于為該軟件準(zhǔn)備的活動或手段就可能適應(yīng)不同的規(guī)定環(huán)境有關(guān)的屬性易安裝性installability與應(yīng)指定環(huán)境下安裝軟件所需努力的軟件屬性易替換性replaceability與軟件在該軟件環(huán)境中用來替代指定的其他軟件的機會和努力有關(guān)的屬性可擴展性scalability支持橫向或縱向擴展，如云原生架構(gòu)軟件質(zhì)量特征(ISO／IEC25010:2023)無害性：確保軟件產(chǎn)品在特定環(huán)境中不會導(dǎo)致不可接受的風(fēng)險25操作限制設(shè)置安全邊界，如工業(yè)機器人動作范圍限制風(fēng)險識別實時監(jiān)控潛在危險（如自動駕駛的障礙物檢測）故障安全失效時自動進入安全模式（如核電站緊急停機）危險警告異常狀態(tài)預(yù)警（如醫(yī)療設(shè)備報警機制）。安全集成與外部安全系統(tǒng)聯(lián)動（如消防系統(tǒng)與建筑管理平臺集成）。軟件質(zhì)量模型——McCall模型26軟件質(zhì)量模型——Boehm軟件質(zhì)量模型27闡述性互用性數(shù)據(jù)公開性正確性可靠性效率完整性可用性可維護性可測試性靈活性可移植性重復(fù)性連貫性容錯性執(zhí)行效率/儲存效率存取控制/存取檢查可訓(xùn)練溝通良好簡單性易操作的工具自我操作性擴展性一般性模塊性軟件系統(tǒng)獨立性機器獨立性通訊公開性正確性可操作性軟件產(chǎn)品評價質(zhì)量通過對質(zhì)量特性和子特性的定義，軟件質(zhì)量體系構(gòu)架了一個完整的軟件質(zhì)量描述框架，在整個軟件項目的各個階段都具有指導(dǎo)意義。測試實踐中需要根據(jù)軟件質(zhì)量體系，在測試計劃中確定項目質(zhì)量標(biāo)準(zhǔn)、設(shè)計測試用例、制定測試策略；在測試執(zhí)行中確定執(zhí)行策略；在測試報告中全面總結(jié)評價軟件的最終特性。28標(biāo)準(zhǔn)模型質(zhì)量特性質(zhì)量子特性關(guān)鍵進展ISO91266個21個奠定基礎(chǔ)→

ISO25010:20239個40個更全面、更精準(zhǔn)軟件測試與質(zhì)量29實踐證明：對軟件進行充分的測試 才能夠有效的保證軟件質(zhì)量對軟件產(chǎn)品進行充分測試，找出其中的缺陷(defect/bug),并進行修復(fù)(repair)。本章內(nèi)容30軟件質(zhì)量軟件測試軟件缺陷二三一軟件缺陷相關(guān)術(shù)語錯誤（error）通俗地說，錯誤是指某件做錯的事。它是一種人類的失誤行為。和錯誤有關(guān)的行為——忘記、疏忽、隨意、臆測、誤判、錯想、誤會、含混、輕信、無知…。（軟件）缺陷（defect）缺陷是錯誤在軟件中體現(xiàn)出來的結(jié)果。錯誤是潛伏在軟件中的問題，如果永遠不執(zhí)行它們就不會出現(xiàn)缺陷。但是，如果沒有條件引發(fā)這個缺陷，我們就可以認為沒有缺陷嗎？31軟件缺陷相關(guān)術(shù)語故障（fault）當(dāng)缺陷被引發(fā)時，它可能造成故障（失效）。故障是缺陷的表現(xiàn)形式，是軟件的運行結(jié)果相對于軟件預(yù)期行為的一種偏離。Bug是一種通俗的說法，通常用作缺陷的同義詞。Bug的英文含義是“蟲”，用在軟件中，可以理解為人腦子里的“蟲”，變成了系統(tǒng)中潛在的缺陷。失效（Failure）32測試與調(diào)試33錯誤缺陷缺陷缺陷軟硬件環(huán)境與操作條件故障沿著故障返回的路徑，對缺陷分析、定位和修正——調(diào)試發(fā)現(xiàn)系統(tǒng)失效，以證明缺陷的存在——測試發(fā)現(xiàn)系統(tǒng)失效，以證明缺陷的存在——測試軟件缺陷產(chǎn)生的原因軟件缺陷的不可避免性。1、軟件本身：需求不清晰、結(jié)構(gòu)復(fù)雜、運行環(huán)境復(fù)雜、采用新技術(shù)、系統(tǒng)擴展或兼容問題2、團隊工作：需求理解、相互溝通、技術(shù)水平3、技術(shù)問題：算法錯誤、語法錯誤等4、項目管理：不重視質(zhì)量、缺乏評審機制、風(fēng)險估計不足等。34問題：軟件缺陷可能存在于什么地方？僅出現(xiàn)在代碼中？不是。它無處不在！其中，需求說明書是軟件缺陷出現(xiàn)最多的地方。因此，我們必須提前測試，預(yù)防缺陷在后期大爆發(fā)35軟件缺陷在開發(fā)周期的不同階段的分布36修復(fù)軟件缺陷的代價“老生常談”，但仍未得到足夠的重視！人們總是因追求進度和實現(xiàn)而忽略了對軟件缺陷的及時排除。37軟件缺陷的嚴(yán)重性38嚴(yán)重程度說明現(xiàn)象描述（部分例子）處理優(yōu)先級緊急致命錯誤，會導(dǎo)致整個系統(tǒng)失效由于程序所引起的死機、非法退出死循環(huán)數(shù)據(jù)庫發(fā)生死鎖因錯誤操作導(dǎo)致的程序中斷與數(shù)據(jù)庫連接錯誤數(shù)據(jù)通信錯誤，從而導(dǎo)致測試無法繼續(xù)執(zhí)行可能影響其他模塊功能立即處理或解決致命很嚴(yán)重錯誤，會造成系統(tǒng)的部分功能失效程序錯誤程序接口錯誤數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件關(guān)鍵功能完全不能實現(xiàn)程序運行不穩(wěn)定，如出現(xiàn)不可繼續(xù)進行操作的錯誤程序運行出現(xiàn)難以捕捉和不可再現(xiàn)的錯誤響應(yīng)其他業(yè)務(wù)流程的錯誤在發(fā)現(xiàn)的幾天內(nèi)完成嚴(yán)重一般嚴(yán)重錯誤，影響用戶的操作操作界面錯誤打印內(nèi)容、格式錯誤簡單的輸入限制未放在前臺進行控制刪除/退出操作未給出提示數(shù)據(jù)庫表中有過多的空字段功能不完整，如菜單、按鈕不響應(yīng)對錯誤沒有處理信息系統(tǒng)上線前必須修復(fù)完成一般一般性錯誤，可能會影響用戶操作界面不規(guī)范輔助說明描述不清楚輸入輸出不規(guī)范提示窗口文字未采用行業(yè)術(shù)語可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志正常排隊等待修復(fù)或方便時修復(fù)建議較小錯誤，不影響用戶的正常使用Tab鍵跳轉(zhuǎn)不正常窗口控件的Z-Order不正確窗口中的按鈕或者控件缺少快捷字母，或快捷字母沖突文字表述中有錯別字或歧義測試人員所提出的建設(shè)性意見方便時再修復(fù)軟件缺陷構(gòu)成39缺陷分類表40序號類別主要表現(xiàn)1需求缺陷（1）需求有誤；

（2）需求邏輯錯誤；（3）需求不完備；（4）需求文檔描述有問題；

（5）需求更改2設(shè)計缺陷功能的使用對用戶帶來不便及不符合行業(yè)標(biāo)準(zhǔn)，表現(xiàn)：（1）設(shè)計不合理；

（2）設(shè)計文檔描述有問題；（3）設(shè)計變更帶來的問題3功能和性能缺陷功能沒有達到要求或功能存在嚴(yán)重缺陷，系統(tǒng)在運行過程中存在性能瓶頸或存在對系統(tǒng)性能有影響的功能，表現(xiàn)：（1）功能或性能有誤；

（2）性能不完全；（3）功能不完全；

（4）適應(yīng)范圍有問題；（5）用戶信息和診斷信息有誤；（6）異常情況處理有誤；（7）其他功能錯誤4界面缺陷系統(tǒng)的圖片、文字、按鈕、翻頁明顯有錯誤5數(shù)據(jù)錯誤訪問數(shù)據(jù)庫時出錯，得出的數(shù)據(jù)錯誤，表現(xiàn)：（1）數(shù)據(jù)定義、數(shù)據(jù)結(jié)構(gòu)錯誤；（2）數(shù)據(jù)存取及數(shù)據(jù)操作錯誤；（3）其它數(shù)據(jù)問題6結(jié)構(gòu)缺陷（1）控制流和控制順序錯誤；（2）處理錯誤7實現(xiàn)與編碼缺陷（1）編碼錯誤；（2）違背編碼風(fēng)格或標(biāo)準(zhǔn)；（3）文檔有誤；（4）其它實現(xiàn)方面的問題8軟件集成缺陷（1）內(nèi)部接口錯誤（2）外部接口錯誤，時間、吞吐問題；（3）其他集成錯誤9系統(tǒng)結(jié)構(gòu)缺陷（1）操作系統(tǒng)引用或使用錯誤；

（2）軟件結(jié)構(gòu)錯誤；（3）恢復(fù)錯誤；

（4）執(zhí)行錯誤；

（5）診斷錯誤；（6）分割覆蓋錯誤；（7）引用環(huán)境錯誤10測試設(shè)計與測試執(zhí)行錯誤（1）測試設(shè)計錯誤；（2）測試執(zhí)行錯誤；（3）測試文檔錯誤；（4）測試用例不充分；

（5）其他測試錯誤11其它缺陷（1）數(shù)學(xué)結(jié)算錯誤；（2）測試者誤操作卻認為發(fā)現(xiàn)了問題；（3）所產(chǎn)生的問題與硬件設(shè)備直接有關(guān)本章內(nèi)容41軟件質(zhì)量軟件測試軟件缺陷二三一軟件測試IEEE對軟件測試的定義：

正面測試：依據(jù)需求（功能）列表逐個驗證，為了證明軟件是工作的，如：正常值測試。該方法必須用，而且常用，但發(fā)現(xiàn)錯誤的效率較低。42使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的的需求，或是弄清預(yù)期結(jié)果與實際結(jié)果之間的差別軟件測試G.J.Myers在《軟件測試之藝術(shù)》書中描述：

反面測試：想方設(shè)法找出軟件缺陷，為了證明軟件是不工作的，發(fā)現(xiàn)Bug的效率較高，如：異常值測試。實際應(yīng)用中，兩種思維方式都要有。43程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程軟件測試定義通俗地說：軟件測試是一個找錯的過程。軟件測試的過程亦是程序運行的過程。程序運行需要數(shù)據(jù)，為測試設(shè)計的數(shù)據(jù)稱為測試用例（TestCase）。測試用例的設(shè)計原則是盡可能暴露程序中的錯誤。一個成功的測試用例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。軟件測試的目的測試的目的就是發(fā)現(xiàn)軟件中的各種缺陷測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅以較少的測試用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質(zhì)量測試的目標(biāo)最終目的是確保軟件的功能符合用戶的需求，把盡可能多的問題在發(fā)布或交付前發(fā)現(xiàn)并改正：確保軟件完成了它所承諾或公布的功能確保軟件滿足性能的要求確保軟件是健壯的和適應(yīng)用戶環(huán)境的為軟件的質(zhì)量評估提供依據(jù)為軟件質(zhì)量改進和管理提供幫助軟件測試度量測試覆蓋率有多少需求、代碼已經(jīng)被測試了軟件測試度量缺陷發(fā)現(xiàn)率缺陷是何時被發(fā)現(xiàn)，并且有多少缺陷已經(jīng)被發(fā)現(xiàn)。缺陷可以根據(jù)嚴(yán)重性來分類。需記錄以下值：缺陷數(shù)目缺陷的嚴(yán)重性48軟件測試度量測試成功率：有多少測試已經(jīng)通過了，并且有多少是運行正常的？需記錄以下值：已通過的測試用例的數(shù)目可利用的測試用例的數(shù)目軟件的可測試性可測試性（Testability）是否容易測試影響軟件質(zhì)量的關(guān)鍵S.O.C.K原則50軟件的可測試性Simplicity設(shè)計簡潔功能模塊化越簡單，越容易測試51軟件的可測試性52軟件的可測試性O(shè)bservability可觀察性任何一項操作或輸入都應(yīng)該有預(yù)期的、明確的響應(yīng)或輸出運行時狀態(tài)當(dāng)前、過去的系統(tǒng)狀態(tài)和變量應(yīng)可見或可查詢正確地驗證更容易驗證增加輸出參數(shù)、增加斷言等53軟件的可測試性Control控制軟件的運行提供適當(dāng)?shù)氖侄危谕饨缰苯踊蜷g接的控制系統(tǒng)的狀態(tài)及變量業(yè)務(wù)流程和場景易于分解，可以針對單獨業(yè)務(wù)流程進行測試不同分支出錯處理異常處理54軟件的可測試性Knowledge了解模塊的各個狀態(tài)每個狀態(tài)有清晰的定義驗證狀態(tài)排序的輸出和隨機的輸出55軟件測試的原則基本原則站在用戶的角度，對產(chǎn)品進行全面測試。盡早、盡可能多地發(fā)現(xiàn)缺陷（bug），并負責(zé)跟蹤和分析產(chǎn)品中的問題。對不足之處提出質(zhì)疑和改進意見。爭取零缺陷（zero-bug），做到足夠好（good－enough）。進一步研究：在軟件測試過程中，應(yīng)注意和遵循的原則可以概括為10項。56值得學(xué)習(xí)的10項原則所有測試的標(biāo)準(zhǔn)都是建立在用戶需求之上。軟件測試必須基于“質(zhì)量第一”的思想去開展各項工作。事先定義好產(chǎn)品的質(zhì)量標(biāo)準(zhǔn)。軟件項目一啟動，軟件測試也就開始，而不是等程序?qū)懲?，才開始進行測試。窮舉測試是不可能的。第三方進行測試會更客觀，更有效。軟件測試計劃是做好軟件測試工作的前提。測試用例是設(shè)計出來的，不是寫出來的。對發(fā)現(xiàn)錯誤較多的程序段，應(yīng)進行更深入的測試。重視文檔，要善于保存一切測試過程文檔。57軟件測試的分類我們將概述軟件測試類型，如：功能測試、性能測試、單元測試、集成測試、系統(tǒng)測試、驗收測試；以及軟件測試常用的方法，如：手工測試、自動化測試、靜態(tài)測試、動態(tài)測試、白盒測試、黑盒測試、回歸測試、冒煙測試、隨機測試等。在某一類型的測試中，多種測試方法一般會被綜合運用，以達到全面測試的目的。58軟件測試的類型59軟件測試類型按測試階段劃分功能測試單元測試驗收測試系統(tǒng)測試集成測試按測試目的劃分性能測試壓力測試穩(wěn)定性測試兼容性測試健壯性測試可維護性測試可用性測試軟件測試方法60軟件測試方法白盒測試靜態(tài)測試其他動態(tài)測試按是否運行系統(tǒng)劃分按是否查看源代碼劃分隨機測試黑盒測試冒煙測試回歸測試等價類劃分法錯誤推測法因果圖法邊界值分析法組合分析法手工測試自動化測試按是否使用自動化工具劃分邏輯覆蓋法基本路徑測試法測試階段--單元測試單元模塊集成后構(gòu)成軟件系統(tǒng)61系統(tǒng)程序的最小單元是什么？測試階段--單元測試單元測試是對軟件基本組成單元進行的測試。測試的對象是軟件設(shè)計最小單位——模塊。一個類、一個組件、一個菜單、一個顯示界面或者能夠獨立完成的具體功能都可以是一個單元。單元測試把軟件的獨立單元與程序的其他部分隔離開來進行的測試。常使用的方法是白盒測試（主要）與黑盒測試。62單元測試測試階段--單元測試單元測試作為針對于編碼工作的第一級測試，首次對編碼實現(xiàn)的軟件單元進行系統(tǒng)地測試。單元測試的結(jié)果是程序員階段性成功的標(biāo)志。完成單元測試的標(biāo)志是：在單元測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，并且通過了再測試。達到了相關(guān)的覆蓋率的要求。完成軟件單元測試報告。63誰負責(zé)單元測試比較好？測試階段—集成測試集成是把組件組合成更大部件的過程。集成測試不是單純的測試，還是驗證集成后的系統(tǒng)是否達到了既定的設(shè)計目標(biāo)。集成測試是將已分別通過測試的單元（組件），按設(shè)計要求組合起來再進行的測試。集成測試的目的，是揭示接口以及模塊間交互的缺陷。集成測試一般包括：邏輯關(guān)系檢查、數(shù)據(jù)關(guān)系檢查、業(yè)務(wù)關(guān)系檢查、模塊間接口檢查等。64測試階段-系統(tǒng)測試系統(tǒng)測試是用于驗證經(jīng)測試的集成系統(tǒng)是否滿足指定需求而進行的測試，是系統(tǒng)級別的測試。系統(tǒng)測試的被測對象是軟件的特性——包括功能和非功能（主要）的特性。系統(tǒng)測試要檢驗軟件的各種功能操作是否正常，并檢驗它的效率、強度、兼容性、可靠性、故障修復(fù)等一系列的性能指標(biāo)。因此，系統(tǒng)測試是一個龐大的工程。系統(tǒng)測試是“整機”測試，故測試環(huán)境十分重要。要考慮軟硬件設(shè)備和真正的使用環(huán)境。65測試階段-驗收測試驗收測試是在系統(tǒng)測試通過，以及發(fā)現(xiàn)錯誤在修正之后才開始的測試，是整個確認測試的最后一個階段。由用戶在使用環(huán)境下測試。如同我們購買汽車時的“試車”一樣，我們要驗證預(yù)期的產(chǎn)品品質(zhì)。如果是客戶定制的軟件，客戶將根據(jù)合同執(zhí)行驗收測試；對于通用軟件，會在一個公共的測試環(huán)境中進行驗收測試。驗收測試分為兩個階段：α測試：在模擬用戶的環(huán)境中測試，由用戶、測試人員、開發(fā)人員等參與的內(nèi)部測試；β測試：在實際用戶的環(huán)境中測試，完全交給最終用戶。66單元測試、集成測試、系統(tǒng)測試的關(guān)系67系統(tǒng)子系統(tǒng)1子系統(tǒng)n模塊1…模塊n模塊1模塊m單元1單元n單元1單元m…………UTSTITIT系統(tǒng)分析設(shè)計過程系統(tǒng)測試過程測試目的--功能測試功能測試的目的驗證和確認產(chǎn)品規(guī)格說明書規(guī)定的要求是否都得到了滿足檢查實際軟件的功能是否符合用戶需求功能測試包括驗證系統(tǒng)輸入輸出行為的各種測試。經(jīng)常以黑盒測試方法為主，并輔以白盒測試、回歸測試等。功能測試的基礎(chǔ)是功能需求，因此SRS是功能測試的重要依據(jù)。68測試目的--性能測試性能需求（非功能需求）：不描述功能，描述系統(tǒng)執(zhí)行它的功能有“多好”或者性能如何,

分為時間性能(響應(yīng)時間)和空間性能(系統(tǒng)資源)

性能測試一般包括：壓力測試、容量測試、效率性測試、穩(wěn)定性測試、健壯性測試、容錯性測試、數(shù)據(jù)轉(zhuǎn)換測試、易用性測試、可維護性檢查、文檔檢查等。69是否使用工具—手工測試顧名思義，手工測試即測試人員在不借助工具的情況下，“親力親為”地進行測試。優(yōu)勢測試人員具有創(chuàng)造性，靈活性高，可以考慮到一些特殊用例和邊界情況。對于復(fù)雜的邏輯判斷、界面是否友好等方面的測試，手工測試有明顯優(yōu)勢。發(fā)現(xiàn)缺陷的的比例較高，可達85%左右。局限性覆蓋率較低、不具有可重復(fù)性；測試效率較低；不能進行如系統(tǒng)負載、可靠性等性能測試。70是否使用工具--自動化測試軟件自動化測試是相對于手工測試而存在的，主要是利用自動化軟件測試工具，通過編測寫試腳本和輸入測試數(shù)據(jù)，自動運行測試程序。軟件測試工具主要包括功能測試工具、性能測試工具、測試管理工具。優(yōu)點：可重復(fù)性、效率高、準(zhǔn)確、可靠、覆蓋率高等。缺點：靈活性差，發(fā)現(xiàn)缺陷的比例較低，只能達到15%。通常，手工測試和自動化測試結(jié)合使用，以互補的方式完成測試任務(wù)71是否運行系統(tǒng)--靜態(tài)測試軟件的功能在不被執(zhí)行的時候，處于相對靜止的狀態(tài)——靜態(tài)測試方法。靜態(tài)測試的對象包括文檔、代碼、界面等。主要是根據(jù)用戶的要求、及相關(guān)標(biāo)準(zhǔn)規(guī)范進行分析與檢查。常用的手段是人工檢測，依靠人工審查或評審軟件，偏重于編碼風(fēng)格、質(zhì)量的檢驗，除了審查編碼還要對各階段的軟件文檔進行檢驗。計算機輔助靜態(tài)分析，是很有效的靜態(tài)測試。72是否運行系統(tǒng)--動態(tài)測試當(dāng)軟件功能被執(zhí)行的時候，軟件的對應(yīng)部分處于活動之中——動態(tài)測試方法。通過觀察代碼運行時的動作，來獲取執(zhí)行結(jié)果，并得到時間效率、系統(tǒng)可靠性等方面的信息。動態(tài)測試通過真正運行程序發(fā)現(xiàn)錯誤。通過有效的測試用例，對應(yīng)的輸入/輸出關(guān)系來分析被測程序的運行情況。73是否查看源代碼--白盒測試白盒測試：把被測軟件看作一個盒子，在測試時，不僅要關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果，還要把盒子打開，研究里面的源代碼和程序結(jié)構(gòu)。白盒測試常用的方法邏輯覆蓋法基本路徑測試法74Y=2*xX=2Y=4是否查看源代碼--黑盒測試黑盒測試，指的是把被測軟件看作一個盒子，我們不去關(guān)心盒子里面是什么樣子，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。黑盒測試常用的方法等價類劃分法邊界值分析法因果圖法錯誤推測法功能圖法75X=2Y=4其它測試--回歸測試為什么要進行回歸測試？背景：系統(tǒng)功能繁多，產(chǎn)品的種類不斷演變，產(chǎn)品升級比較頻繁，將要發(fā)布的版本都會包括新增功能，經(jīng)過測試的功能也可能在新版本中出現(xiàn)。需求：即使是已經(jīng)測過的功能模塊，在新的版本下依然需要測試，以確保該模塊在新的環(huán)境中仍能正常運行——這就叫“回歸測試”?；貧w測試的定義重復(fù)測試先前測試過的或修改過的程序，確認發(fā)生的更改是否給軟件其他未改變的部分帶來新的缺陷。76其它測試--冒煙測試冒煙測試，是指對一個新版本系統(tǒng)進行大規(guī)模的測試之前，先驗證一下軟件的基本功能能否實現(xiàn)，是否具備可測性。冒煙測試的由來：冒煙測試名字的由來與電路板的測試有關(guān)。人們在測試電路板質(zhì)量時，先給它接上電，如果板子冒煙的話，說明板子的質(zhì)量存在嚴(yán)重問題，就不用測試其它功能了，必須重新研制或生產(chǎn)。一般，先進行冒煙測試，再進行回歸測試。77其它測試--隨機測試隨機測試，是指測試中所有的輸入數(shù)據(jù)都是隨機生成的，其目的是模擬用戶的真實操作，并發(fā)現(xiàn)一些邊緣性的錯誤。隨機測試又叫猴子測試。當(dāng)軟件發(fā)布后，就會有成千上萬的人像猴子一樣對軟件亂點亂敲。這種方法盡量模擬軟件在實際的使用環(huán)境中的隨機操作，發(fā)現(xiàn)一些隱蔽的錯誤。隨機測試的缺點：測試不規(guī)律、不系統(tǒng)，無法統(tǒng)計代碼覆蓋率和需求覆蓋率，很難再進行回歸測試。因此該方法一般用作輔助測試手段。78軟件測試的生命周期79在軟件測試生命周期的每個階段都要完成一些確定的任務(wù)：在執(zhí)行每個階段的任務(wù)時，可以采用行之有效的結(jié)構(gòu)分析設(shè)計技術(shù)和適當(dāng)?shù)妮o助工具；2.在結(jié)束每個階段的任務(wù)時，都進行嚴(yán)格的技術(shù)審查和管理復(fù)審。3.最后提交最終軟件配置的一個或幾個成分（文檔或程序）。軟件測試與開發(fā)的關(guān)系軟件測試與開發(fā)的順序關(guān)系80軟件測試模型V模型在V模型中，描述了一些不同的測試級別，并說明了這些級別所對應(yīng)的生命周期中不同的階段，清楚地描述了這些測試階段和開發(fā)過程期間的對應(yīng)關(guān)系。81V模型示意圖

用戶需求獲取需求定義需求分析需求分析書概要設(shè)計概要設(shè)計書詳細設(shè)計詳細設(shè)計書編碼程序軟件產(chǎn)品可交付軟件驗收測試已確認軟件系統(tǒng)測試已集成軟件集成測試已測試模塊單元測試需求分析評審評審評審評審評審評審評審評審必需在編碼工作結(jié)束后才能進行測試！軟件測試模型W模型由于各種原因，開發(fā)的每一個環(huán)節(jié)都可能產(chǎn)生錯誤，如果堅持各個階段的技術(shù)評審,就能夠盡早發(fā)現(xiàn)和預(yù)防錯誤。83每個開發(fā)活動后都可以執(zhí)行相應(yīng)的測試！W模型示意圖W模型特點優(yōu)點：測試貫穿于整個軟件開發(fā)生命周期；測試對象不僅僅是程序，還包括需求和設(shè)計規(guī)格說明等；測試與開發(fā)同步；可以盡早、全面發(fā)現(xiàn)問題。缺點：為串行結(jié)構(gòu)，需等上一階段活動結(jié)束后才能開展下一活動。85H模型示意圖86H模型RUP87軟件測試模型H模型軟件測試不僅僅指測試的執(zhí)行,還包括很多其他的活動。軟件測試是一個獨立的流程,貫穿產(chǎn)品的整個開發(fā)周期,與其它流程并發(fā)進行。軟件測試要盡早準(zhǔn)備,盡早執(zhí)行。軟件測試根據(jù)被測物的不同是分層次的。不同層次的測試活動可以是按照某個次序先后進行的,但也可能是反復(fù)的。88測試模型的使用X模型提出：針對單獨的程序片段進行相互分離的編碼和測試，然后經(jīng)過頻繁的交接，通過集成最終合成為可執(zhí)行的程序。前置測試模型體現(xiàn)了開發(fā)與測試的結(jié)合，要求對每個交付的內(nèi)容進行測試。這些模型都針對其他模型的缺點進行了一些修正，但本身仍然存在一些不足的地方，所以在軟件測試過程中正確選取模型是一個很關(guān)鍵的問題。89測試模型的使用在這些模型中，V模型強調(diào)了在整個軟件項目開發(fā)中需要經(jīng)歷的若干個測試級別，而且每一個測試級別都與一個開發(fā)級別相對應(yīng)，但它忽略了測試的對象不應(yīng)該僅僅包括程序，或者說它沒有明確地指出應(yīng)該針對軟件的需求和設(shè)計進行測試，而這一點在W模型中得到了補充。W模型強調(diào)測試計劃等工作的先行和對系統(tǒng)需求和設(shè)計的測試，但W模型和V模型一樣，沒有專門對軟件測試流程予以說明。因為事實上，隨著軟件質(zhì)量要求越來越為大家所重視，軟件測試也逐步發(fā)展成為一個獨立于軟件開發(fā)的一系列活動，就每個軟件測試的細節(jié)而言，都有一個獨立的操作流程。比如，現(xiàn)在的第三方測試就包含了從測試計劃和測試用例編寫，到測試實施以及測試報告編寫的全過程，這個過程在H模型中得到了相應(yīng)的體現(xiàn)，表現(xiàn)為測試是獨立的。也就是說，只要測試前提具備了，就可以開始測試。因此，在實際的工作中，要靈活地運用各種模型的優(yōu)點，在W模型的框架下，運用H模型的思想進行獨立測試，同時將測試與開發(fā)緊密結(jié)合，尋找恰當(dāng)?shù)木途w點開始測試并反復(fù)迭代測試，最終保證按期完成預(yù)定目標(biāo)。90軟件測試的完整模型91項目規(guī)劃項目需求分析項目概要分析項目詳細分析代碼編寫測試代碼編寫測試需求分析系統(tǒng)測試計劃集成測試計劃單元測試計劃產(chǎn)品發(fā)布系統(tǒng)測試集成測試單元測試軟件測試與開發(fā)的關(guān)系軟件測試與開發(fā)的并行關(guān)系92需求分析需求評審概要設(shè)計詳細設(shè)計概要設(shè)計評審單元測試編碼設(shè)計走查編碼走查各子模塊有效性測試集成測試測試計劃測試過程測試評審…………**項目階段任務(wù)的里程碑********測試在開發(fā)階段的作用：項目規(guī)劃階段：負責(zé)從單元測試到系統(tǒng)測試的整個測試階段的監(jiān)控。需求分析階段：確定測試需求分析、系統(tǒng)測試計劃的制定，評審后成為管理項目。詳細設(shè)計和概要設(shè)計階段：確保集成測試計劃和單元測試計劃完成。編碼階段：由開發(fā)人員進行自己負責(zé)部分的測試代碼。在項目較大時，由專人進行編碼階段的測試任務(wù)。測試階段（單元、集成、系統(tǒng)測試）：依據(jù)測試代碼進行測試，并提交相應(yīng)的測試狀態(tài)報告和測試結(jié)束報告。93第2章軟件質(zhì)量標(biāo)準(zhǔn)本章內(nèi)容95軟件質(zhì)量標(biāo)準(zhǔn)概述ISO/IEC軟件質(zhì)量標(biāo)準(zhǔn)CMM與CMMI標(biāo)準(zhǔn)二三一IEEE軟件質(zhì)量標(biāo)準(zhǔn)四標(biāo)準(zhǔn)優(yōu)勢對比五本章內(nèi)容96軟件質(zhì)量標(biāo)準(zhǔn)概述ISO/IEC軟件質(zhì)量標(biāo)準(zhǔn)CMM與CMMI標(biāo)準(zhǔn)二三一IEEE軟件質(zhì)量標(biāo)準(zhǔn)四軟件質(zhì)量標(biāo)準(zhǔn)軟件質(zhì)量標(biāo)準(zhǔn)定義確保軟件產(chǎn)品滿足用戶需求和期望的重要參考，它們分為多個層級，包括國際標(biāo)準(zhǔn)、國家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)、企業(yè)標(biāo)準(zhǔn)、項目規(guī)范。97軟件質(zhì)量標(biāo)準(zhǔn)作用：提供系統(tǒng)性指導(dǎo)規(guī)范開發(fā)流程，確保高質(zhì)量、穩(wěn)定性和安全性98國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）99國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）功能適用性：軟件在一定條件下須滿足的明確及隱含的需求。100功能完備性functionalcompleteness軟件提供的一套功能能夠覆蓋所有特定任務(wù)和預(yù)期用戶目標(biāo)的能力。功能正確性functionalcorrectness當(dāng)預(yù)期用戶使用該產(chǎn)品時，軟件能夠提供正確結(jié)果的能力。功能適當(dāng)性functionalappropriateness軟件能夠提供功能以促進特定任務(wù)和目標(biāo)完成的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）性能效率：在特定條件下能夠在規(guī)定的時間和吞吐量參數(shù)內(nèi)執(zhí)行其功能，且能夠高效利用資源的能力。101時間特性timebehaviour軟件在特定條件下執(zhí)行其指定功能并滿足響應(yīng)時間和吞吐率要求的能力。資源利用率resourceutilization軟件在特定條件下執(zhí)行其功能時不使用超過指定數(shù)量資源的能力。容量capacity軟件滿足產(chǎn)品參數(shù)不超過最大限制的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）交互性：軟件通過用戶接口與指定用戶交互，來實現(xiàn)用戶和系統(tǒng)之間的信息交換，并完成預(yù)期任務(wù)的能力。用戶錯誤防止軟件阻止操作錯誤發(fā)生的能力。可識別性被用戶認識到符合他們需求的能力。易學(xué)習(xí)性讓特定用戶不用花費太多時間就能學(xué)會使用特定產(chǎn)品功能的能力。易操作性軟件擁有的功能和屬性讓其操作和控制起來很輕松的能力。用戶參與度軟件以吸引人和激勵人的方式展現(xiàn)自己的功能和信息，鼓勵用戶持續(xù)進行交互的能力。包容性軟件被各種背景的人使用的能力。用戶幫助在特定的使用場景下，讓有各種各樣特征和能力的人使用，以達成指定目標(biāo)的能力。自描述性在用戶需要的地方展示適當(dāng)?shù)男畔?，令軟件功能和使用方法對用戶顯而易見，而不需要用戶過度地與產(chǎn)品交互或依賴其他資源的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）可靠性：是指軟件在一定條件下連續(xù)一段時間執(zhí)行特定功能而不發(fā)生中斷和故障的能力。103無錯性Faultlessness軟件在正常操作下執(zhí)行特定功能不產(chǎn)生故障的能力。可用性availability軟件在使用時可操作和可訪問的能力。容錯性fault

tolerance軟件在有故障或未使用指定接口的情況下，依然按預(yù)期運行的能力。易恢復(fù)性recoverability在發(fā)生一次中斷或故障后，恢復(fù)被直接影響的數(shù)據(jù)，并重新建立期望的系統(tǒng)狀態(tài)的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）安全性：軟件保護信息和數(shù)據(jù)，讓個人或其他軟件擁有的數(shù)據(jù)的訪問程度符合其授權(quán)的類型和等級，同時抵御來自惡意攻擊者的入侵的能力。104保密性保證數(shù)據(jù)只被有訪問授權(quán)的請求獲取的能力。完整性確保其系統(tǒng)狀態(tài)和數(shù)據(jù)免受未經(jīng)授權(quán)的修改或刪除的能力，無論是由于惡意行為還是計算機錯誤。不可否認性在某種行為或事件發(fā)生后，確保該行為或事件不被否認的能力?？勺粉櫺允挂粋€實體的行為被唯一追溯到該實體的能力。真實性證明一個主體或資源的身份與其所聲稱的身份一致的能力。防御性當(dāng)軟件遭受惡意攻擊時保證軟件正常運行的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）可維護性：軟件被高效地修改的能力。105105易分析性軟件高效地評定自身的一個或多個部分發(fā)生預(yù)期變更所產(chǎn)生的影響，以診斷故障的成因，進而識別出需要進行修改的部分的能力?？勺兏攒浖桓咝У匦薷?，且不引入新的缺陷或降低現(xiàn)有產(chǎn)品質(zhì)量的能力。可復(fù)用性軟件的資產(chǎn)被其他軟件復(fù)用的能力。模塊性軟件由若干獨立的組件構(gòu)成，修改一個模塊對其他模塊的影響被降到最低。易測試性軟件允許客觀可行的測試被設(shè)計和執(zhí)行，以確定需求是否達到要求的能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）靈活性：軟件適應(yīng)其必要條件、使用環(huán)境、系統(tǒng)環(huán)境發(fā)生變化的能力。106適應(yīng)性adaptability軟件無須采用其他活動或手段就可適應(yīng)不同環(huán)境的能力。易安裝性installability軟件在特定環(huán)境下高效安裝或卸載的能力。易替換性replaceability軟件在相同的目標(biāo)和環(huán)境下替代其他特定產(chǎn)品的能力。可擴展性scalability軟件處理增長或縮減的工作負載，或調(diào)整容量應(yīng)對變化能力。國際標(biāo)準(zhǔn)（ISO/IEC25010:2023）保護性：軟件在規(guī)定條件下避免人身安全、健康、財產(chǎn)或環(huán)境遭受危害的能力。107操作約束當(dāng)遇到操作風(fēng)險時，軟件將其操作約束在安全的參數(shù)或狀態(tài)范圍內(nèi)的能力。風(fēng)險識別軟件識別出可能導(dǎo)致人身安全、財產(chǎn)、環(huán)境暴露在不可接受風(fēng)險下的一系列事件或操作的能力。故障安全發(fā)生故障時，軟件自動將自身調(diào)整到安全運行模式，或恢復(fù)到安全狀態(tài)的能力。危險警告軟件向操作者或內(nèi)部控制部門提供風(fēng)險警告，使他們有足夠的時間采取行動以維持軟件正常運行的能力。安全集成軟件在整合一個或多個組件期間或之后保持其保護性的能力。國家標(biāo)準(zhǔn)108中國軟件工程國家標(biāo)準(zhǔn)：由各國政府或指定的標(biāo)準(zhǔn)化機構(gòu)制定的標(biāo)準(zhǔn)，確保軟件產(chǎn)品的質(zhì)量和安全。標(biāo)準(zhǔn)分類：基礎(chǔ)標(biāo)準(zhǔn)、開發(fā)標(biāo)準(zhǔn)、文檔標(biāo)準(zhǔn)、管理標(biāo)準(zhǔn)。行業(yè)標(biāo)準(zhǔn)行業(yè)標(biāo)準(zhǔn)定義：為了滿足特定行業(yè)需求而制定的技術(shù)要求，不同部門發(fā)布的標(biāo)準(zhǔn)適用于不同的行業(yè)。例如，針對代碼質(zhì)量與缺陷管理的行業(yè)標(biāo)準(zhǔn):工業(yè)和信息化部SJ/T11681-2017《C#語言源代碼缺陷控制與測試指南》、SJ/T11682-2017《C/C++語言源代碼缺陷控制與測試規(guī)范》、SJ/T11683-2017《Java語言源代碼缺陷控制與測試指南》。國防科學(xué)技術(shù)工業(yè)委員會國家軍用標(biāo)準(zhǔn)GJB5369-2005《航天型號軟件C語言安全子集》、GJB8114-2013《C/C++語言可靠性編程規(guī)范》。109企業(yè)標(biāo)準(zhǔn)企業(yè)標(biāo)準(zhǔn)定義：由單個公司或企業(yè)內(nèi)部制定的規(guī)范和標(biāo)準(zhǔn)，確保其產(chǎn)品和服務(wù)的質(zhì)量、安全性、效率和一致性。示例:華為軟件開發(fā)標(biāo)準(zhǔn)：

包括編碼規(guī)范、代碼審查、開發(fā)流程等。項目管理標(biāo)準(zhǔn)：

華為使用敏捷開發(fā)與DevOps實踐來提高項目管理效率。產(chǎn)品交付標(biāo)準(zhǔn)：

包括SLA和服務(wù)交付的具體要求。110本章內(nèi)容111軟件質(zhì)量標(biāo)準(zhǔn)概述ISO/IEC軟件質(zhì)量標(biāo)準(zhǔn)CMM與CMMI標(biāo)準(zhǔn)二三一IEEE軟件質(zhì)量標(biāo)準(zhǔn)四CMM標(biāo)準(zhǔn)112CMM定義一種旨在改進軟件開發(fā)過程的方法，它由美國國防部聯(lián)合卡內(nèi)基梅隆大學(xué)的軟件工程研究所（SEI）在1980年代末期共同開發(fā)。它是對于軟件組織在定義，實現(xiàn)，度量，控制和改善其軟件過程的進程中各個發(fā)展階段的描述CMM的五個成熟度級別初始級可重復(fù)級定義級管理級優(yōu)化級CMM標(biāo)準(zhǔn)113等級(Level)中文名稱關(guān)鍵特征1初始級過程不可預(yù)測；成功依賴個人能力；項目管理混亂、以反應(yīng)為主2可重復(fù)級建立關(guān)鍵過程（項目計劃、需求管理等）；可管理類似項目，形成可重復(fù)經(jīng)驗3定義級組織層面標(biāo)準(zhǔn)化過程與方法；所有項目遵循統(tǒng)一標(biāo)準(zhǔn)流程4管理級以數(shù)據(jù)與統(tǒng)計方法度量/控制過程性能，確保項目按預(yù)期進行5優(yōu)化級持續(xù)改進與優(yōu)化流程；應(yīng)用先進方法（如六西格瑪）；快速響應(yīng)變化CMM標(biāo)準(zhǔn)114

CMM初始級CMM標(biāo)準(zhǔn)115

CMM可重復(fù)級CMM標(biāo)準(zhǔn)116

CMM可重復(fù)級從CMM3級開始，將軟件生命周期的各個階段嚴(yán)格地劃分出來，以保持軟件工程活動和軟件工作產(chǎn)品的一致性。CMM模型的已定義級的KPA：組織過程焦點(OPF，OrganizationProcessFocus)組織過程定義(OPD，OrganizationProcessDefinition)培訓(xùn)程序(TP，TrainingProgram)集成軟件管理(ISM，IntergratedSoftwareManagement)軟件產(chǎn)品工程(SPE，SoftwareProductEngineering)組間協(xié)調(diào)(IC，IntergroupCoordination)同級評審(PR，PeerReviews)CMM標(biāo)準(zhǔn)117CMM已管理級已管理是CMM的第4級。是建立在可重復(fù)級和已定義級的基礎(chǔ)上的。4級組織的過程能力是定量的，已知的，可預(yù)測的過程。4級時要分析和使用所采集的數(shù)據(jù)，理解過去，控制現(xiàn)在，預(yù)測未來。CMM優(yōu)化級缺陷預(yù)防：目的是鑒別缺陷的原因并防止它們再次出現(xiàn)。技術(shù)變更管理：識別出那些建立在最好的軟件工程實踐基礎(chǔ)上的技術(shù)創(chuàng)新，并把它們推廣到整個組織。過程變更管理：改進軟件質(zhì)量、提高生產(chǎn)率和縮短產(chǎn)品開發(fā)周期為目的持續(xù)不斷地改進組織中所采用的軟件過程。CMMI標(biāo)準(zhǔn)118CMMI定義CMMI在CMM的基礎(chǔ)上，集成了多個領(lǐng)域的標(biāo)準(zhǔn)，不僅適用于軟件開發(fā)，還包括產(chǎn)品、服務(wù)開發(fā)等。實施路徑階段式(Staged):組織成熟度分為五個級別，每個級別有特定的要求。連續(xù)式(Continuous):允許獨立評估各個過程領(lǐng)域的成熟度。CMMI模型優(yōu)勢提升過程效率和可預(yù)測性降低成本與開發(fā)時間提高產(chǎn)品質(zhì)量增強客戶滿意度提升競爭力本章內(nèi)容119軟件質(zhì)量標(biāo)準(zhǔn)概述ISO/IEC軟件質(zhì)量標(biāo)準(zhǔn)CMM與CMMI標(biāo)準(zhǔn)二三一IEEE軟件質(zhì)量標(biāo)準(zhǔn)四ISO/IEC軟件產(chǎn)品質(zhì)量標(biāo)準(zhǔn)120定義ISO/IEC軟件產(chǎn)品質(zhì)量標(biāo)準(zhǔn)提供了一套用于評估和確保軟件產(chǎn)品質(zhì)量的框架，幫助組織評估與改進軟件產(chǎn)品質(zhì)量和性能。示例ISO/IEC9126為軟件產(chǎn)品的質(zhì)量提供了一個評估框架，幫助組織確保軟件產(chǎn)品滿足用戶的需求和期望它定義了軟件質(zhì)量的六個特性，包括功能性、可靠性、可用性、效率、可維護性和可移植性。ISO/IEC軟件產(chǎn)品質(zhì)量標(biāo)準(zhǔn)121質(zhì)量特性描述功能性軟件產(chǎn)品在指定條件下使用時，提供滿足明確和隱含要求的功能的能力?？煽啃栽谔囟l件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別能力?？捎眯杂脩粼谥付l件下使用軟件產(chǎn)品時，產(chǎn)品被用戶理解、學(xué)習(xí)、使用和吸引用戶的能力。效率在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)?shù)男阅艿哪芰ΑＭǔ?，效率就是我們常說的產(chǎn)品性能?？删S護性產(chǎn)品可被修改的能力。這里的修改是指糾正、改進軟件產(chǎn)品和軟件產(chǎn)品對環(huán)境、功能規(guī)格變化的適應(yīng)性。可移植性軟件產(chǎn)品從一種環(huán)境遷移到另外一種環(huán)境的能力。這里的環(huán)境，可以理解為硬件、軟件或組織等不同的環(huán)境。ISO/IEC軟件產(chǎn)品質(zhì)量標(biāo)準(zhǔn)122演變歷史ISO/IEC9126(1991年)：最早的軟件質(zhì)量評估標(biāo)準(zhǔn)，定義了6個質(zhì)量特性。ISO/IEC25010：繼承并擴展ISO/IEC9126，提供更詳細的質(zhì)量指導(dǎo)。標(biāo)準(zhǔn)編號改進內(nèi)容ISO/IEC9126到ISO/IEC25010ISO/IEC25010（SQuaRE）系列標(biāo)準(zhǔn)繼承并擴展了ISO/IEC9126，提供了更詳細的指導(dǎo)，包括軟件質(zhì)量模型、質(zhì)量測量、質(zhì)量要求和評價方法。ISO/IEC29119定義了軟件測試過程中的關(guān)鍵概念和活動，涵蓋了從測試策略到測試執(zhí)行的各個方面，旨在幫助組織有效地規(guī)劃、設(shè)計、執(zhí)行和評估軟件測試。ISO/IEC/IEEE122072017版本與之前的版本相比，增加了軟件系統(tǒng)架構(gòu)建模和敏捷開發(fā)技術(shù)應(yīng)用，并且結(jié)構(gòu)和內(nèi)容繼續(xù)與ISO/IEC/IEEE15288:2015保持一致。ISO/IEC/IEEE29119ISO/IEC/IEEE29119-2（2021年第2版）取消了經(jīng)過技術(shù)修訂的第一版（ISO/IEC/IEEE29119-2:2013），并用"測試模型"取代了"測試條件"，簡化了測試設(shè)計流程。ISO/IEC15504提供了一個軟件過程評估的框架，用于軟件的設(shè)計、管理、監(jiān)督、控制，以及提高軟件過程的能力。本章內(nèi)容123軟件質(zhì)量標(biāo)準(zhǔn)概述ISO/IEC軟件質(zhì)量標(biāo)準(zhǔn)CMM與CMMI標(biāo)準(zhǔn)二三一IEEE軟件質(zhì)量標(biāo)準(zhǔn)四IEEE軟件質(zhì)量標(biāo)準(zhǔn)124定義：電氣和電子工程師協(xié)會（InstituteofElectricalandElectronicsEngineers，IEEE）提供有關(guān)軟件開發(fā)、測試、驗證和維護活動的全面指導(dǎo)。常用IEEE軟件質(zhì)量標(biāo)準(zhǔn)：IEEE730?-2014：

質(zhì)量保證過程標(biāo)準(zhǔn)，幫助組織進行軟件開發(fā)的質(zhì)量控制。IEEE/ISO/IEC12207-2017：

軟件生命周期過程框架，定義了從獲取到交付全過程中的各個活動。IEEEStd730系列：

質(zhì)量保證計劃，確保軟件產(chǎn)品滿足質(zhì)量要求并通過適當(dāng)?shù)膶彶?。?biāo)準(zhǔn)優(yōu)勢對比125標(biāo)準(zhǔn)/模型優(yōu)勢CMM提供清晰的改進路徑，提升開發(fā)成熟度；提高質(zhì)量和效率CMMI集成多個領(lǐng)域，強調(diào)持續(xù)改進；降低成本，提升質(zhì)量ISO/IEC國際認證，提升競爭力；提供全面的軟件質(zhì)量評估框架IEEE強調(diào)質(zhì)量控制，支持生命周期管理；確保軟件質(zhì)量與可靠性第3章軟件質(zhì)量保證本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證組織軟件質(zhì)量保證活動軟件質(zhì)量保證過程127本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證組織軟件質(zhì)量保證活動軟件質(zhì)量保證過程128軟件質(zhì)量保證概述為什么軟件質(zhì)量保證如此重要？1292003年美國大停電因電力公司報警系統(tǒng)失效致5000萬人受影響印尼獅航610航班因錯誤傳感器觸發(fā)自動下壓機頭，墜毀致189人遇難軟件系統(tǒng)一旦失效，影響會成倍擴散，最后不只是“一個小bug”，而是公共安全事件、社會穩(wěn)定事件。軟件質(zhì)量保證概述定義軟件質(zhì)量保證（SQA）是一個確保軟件產(chǎn)品在其整個生命周期中滿足或超越預(yù)定標(biāo)準(zhǔn)的活動。SQA目的對軟件項目正在運行的過程和工作產(chǎn)品進行審查保證軟件開發(fā)、驗證過程符合批準(zhǔn)的計劃和標(biāo)準(zhǔn)對階段工作產(chǎn)品進行了符合性評審，提出的問題得到解決將審查的結(jié)果通知到相關(guān)人員項目組內(nèi)無法解決的問題可向高層反映130軟件質(zhì)量保證概述SQA意義縮小缺陷引入與發(fā)現(xiàn)之間的時間間隔，盡量在剛剛引入缺陷時即將其捕獲，而不是讓缺陷擴散到后續(xù)活動作用于過程而不是最終產(chǎn)品，因此它有可能會帶來廣泛的影響與巨大的收益貫穿于所有的活動之中，而不是只集中于一點131本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證組織軟件質(zhì)量保證活動軟件質(zhì)量保證過程132軟件質(zhì)量保證任務(wù)質(zhì)量保證定義：軟件質(zhì)量保證任務(wù)是由質(zhì)量保證的計劃、審計、評審、記錄、分析、報告等多項任務(wù)組成，這些任務(wù)統(tǒng)一交給獨立的SQA小組執(zhí)行。質(zhì)量保證任務(wù)：SQA計劃：質(zhì)量活動、評審/審計要求、標(biāo)準(zhǔn)、缺陷報告流程審計與評審：產(chǎn)品/過程/工具合規(guī)性檢查，文檔/設(shè)計/代碼核查記錄與報告：問題、偏差、建議；面向項目團隊與管理層跟蹤與分析：不符合項閉環(huán)、度量數(shù)據(jù)收集與改進建議133本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證組織軟件質(zhì)量保證活動軟件質(zhì)量保證過程134軟件質(zhì)量保證組織概述目的：確保開發(fā)過程與結(jié)果達到質(zhì)量標(biāo)準(zhǔn)并滿足用戶需求方式：制定/執(zhí)行質(zhì)量計劃、過程監(jiān)控、質(zhì)量評審與測試、最終交付把關(guān)135軟件質(zhì)量保證組織結(jié)構(gòu)軟件質(zhì)量保證組織結(jié)構(gòu)通常根據(jù)企業(yè)的規(guī)模、項目復(fù)雜度和質(zhì)量管理需求而有所不同。SQA組織結(jié)構(gòu)涉及不同的角色和職能部門，負責(zé)不同層次的質(zhì)量保證任務(wù)。目前常用的SQA組織結(jié)構(gòu)有三種：獨立的SQA部門獨立的SQA小組獨立的SQA工程師136軟件質(zhì)量保證組織結(jié)構(gòu)定義：企業(yè)內(nèi)部專職的質(zhì)量保證部門組織形態(tài)：完整部門，配備專職SQA人員匯報關(guān)系：直接向高層管理層匯報核心職責(zé)：制定企業(yè)級質(zhì)量策略與標(biāo)準(zhǔn)；監(jiān)督各項目質(zhì)量執(zhí)行適用場景：大型企業(yè)、復(fù)雜/多項目環(huán)境137獨立的SQA部門軟件質(zhì)量保證組織結(jié)構(gòu)定義：項目中專職負責(zé)質(zhì)量保證的個人工作方式：與開發(fā)團隊同頻協(xié)作，并行介入開發(fā)過程核心職責(zé)：制定項目級質(zhì)量計劃；組織/執(zhí)行測試；開展代碼評審；監(jiān)督流程符合標(biāo)準(zhǔn)適用場景：小型項目或資源有限的企業(yè)/團隊138獨立的SQA工程師軟件質(zhì)量保證組織結(jié)構(gòu)定義：項目團隊內(nèi)相對獨立的質(zhì)量保證小組，專責(zé)項目層面的SQA定位與獨立性：與開發(fā)團隊緊密協(xié)作但保持獨立判斷，避免受研發(fā)進度干擾核心職責(zé)：制定并維護項目質(zhì)量計劃（QAP）組織/執(zhí)行測試與缺陷跟蹤開展質(zhì)量審核/過程評審與風(fēng)險控制建立度量與報告（缺陷密度、修復(fù)時效、覆蓋率等）協(xié)作關(guān)系：對接產(chǎn)品/開發(fā)/測試/運維，推動問題閉環(huán)與持續(xù)改進適用場景：中型項目/企業(yè)，跨模塊協(xié)作多、對過程一致性與交付質(zhì)量要求高139獨立的SQA小組軟件質(zhì)量保證組織結(jié)構(gòu)模型類型特點適用場景獨立SQA部門系統(tǒng)化、專業(yè)度高；面向企業(yè)級策略、標(biāo)準(zhǔn)與監(jiān)督；直達高層大型企業(yè)、復(fù)雜/多項目環(huán)境獨立SQA小組項目內(nèi)獨立、貼近交付；質(zhì)量計劃/審核/缺陷跟蹤主導(dǎo)中型企業(yè)、中等復(fù)雜度項目獨立SQA工程師個人負責(zé)項目質(zhì)量；靈活高效、成本低小型企業(yè)、簡單項目/質(zhì)量要求較低場景140SQA組織結(jié)構(gòu)對比角色分類和職能141高層管理：制定質(zhì)量策略/目標(biāo)，資源保障；監(jiān)督質(zhì)量活動與企業(yè)目標(biāo)一致SQA經(jīng)理：編制質(zhì)量保證計劃；跨部門協(xié)調(diào)；監(jiān)控質(zhì)量目標(biāo)達成SQA工程師：過程審核、產(chǎn)品評審與測試；階段性質(zhì)量評估與問題解決配置管理人員：版本/變更管理、配置審計與可追溯性SQA組織中常見的角色分類與職能SQA人員要求142技術(shù)能力：熟悉軟件開發(fā)生命周期、質(zhì)量控制技術(shù)和測試工具分析能力：能夠分析和評估軟件過程和產(chǎn)品，識別質(zhì)量問題并提出改進建議溝通能力：能夠與開發(fā)團隊、項目經(jīng)理和其他利益相關(guān)者有效溝通，傳達質(zhì)量要求和發(fā)現(xiàn)的問題，推動質(zhì)量改進，促進團隊協(xié)作。持續(xù)學(xué)習(xí)：培訓(xùn)與認證，跟進行業(yè)標(biāo)準(zhǔn)/工具更新SQA人員要求六西格瑪?shù)慕巧团嘤?xùn)143方法：以數(shù)據(jù)為基礎(chǔ)，消除缺陷、提升質(zhì)量角色：領(lǐng)導(dǎo)者、綠帶、黑帶、大師黑帶（分層賦能與指導(dǎo)）對象核心內(nèi)容/目標(biāo)高層管理者正確認知與戰(zhàn)略引領(lǐng)；資源配置與文化推動綠帶基礎(chǔ)工具與DMAIC流程；在崗改進與數(shù)據(jù)分析入門黑帶復(fù)雜問題求解；統(tǒng)計方法（假設(shè)檢驗/回歸/方差分析等）；項目落地大師黑帶戰(zhàn)略規(guī)劃/組織變革；培訓(xùn)/輔導(dǎo)黑帶與綠帶；多項目治理六西格瑪人員培訓(xùn)本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證組織軟件質(zhì)量保證活動軟件質(zhì)量保證過程144軟件質(zhì)量保證活動145質(zhì)量保證是復(fù)審、開發(fā)方法、配置控制與程序測試的綜合應(yīng)用。質(zhì)量保證既是技術(shù)活動，也是管理活動。質(zhì)量保證的活動內(nèi)容軟件評審146同行評審：團隊內(nèi)部，早期發(fā)現(xiàn)問題，促知識共享正式評審：關(guān)鍵階段；需求/設(shè)計/代碼/測試評審（檢查表驅(qū)動）管理評審：高層評估進度/風(fēng)險/質(zhì)量；確保戰(zhàn)略一致性審計評審：獨立第三方合規(guī)性評估；識別與糾正偏差驗證與確認147驗證：過程正確性

→

文檔檢查、代碼審查、靜態(tài)分析、單元測試流程：計劃→執(zhí)行→評估→改進（形成驗證報告）確認：滿足用戶需求

→

系統(tǒng)/集成/驗收測試流程：計劃→執(zhí)行→評估→發(fā)布（決定是否發(fā)布）糾正和預(yù)防措施148糾正：已發(fā)生問題

→

根因分析/修正實施/恢復(fù)運行預(yù)防：潛在問題

→

風(fēng)險評估/過程改進/預(yù)防性培訓(xùn)目標(biāo)：問題率下降、可靠性提升、客戶滿意度提高軟件質(zhì)量控制149測試：計劃→設(shè)計→執(zhí)行→缺陷管理→評估與報告審計：過程/產(chǎn)品審計（計劃、準(zhǔn)備、執(zhí)行、報告、跟進）度量分析：定義指標(biāo)→數(shù)據(jù)收集→統(tǒng)計分析→報告與反饋軟件質(zhì)量控制是一系列確保軟件產(chǎn)品在開發(fā)過程中和最終交付時達到既定質(zhì)量標(biāo)準(zhǔn)的一系列活動。如下：軟件配置管理150軟件配置管理，簡稱SCM，是一種“保護傘”活動，它用于整個軟件工程過程。SCM活動的目標(biāo)標(biāo)識變更控制變更確保變更正確地實現(xiàn)向其他有關(guān)的人報告變更軟件配置管理151按照ISO9000-3的說明，軟件配置項可以是：與合同、過程、計劃和產(chǎn)品有關(guān)的文檔和數(shù)據(jù)；源代碼、目標(biāo)代碼和可執(zhí)行代碼；相關(guān)產(chǎn)品，包括軟件工具、庫內(nèi)的可復(fù)用軟件、外購軟件及用戶提供的軟件。隨著軟件工程過程的進展，軟件配置項(SCI)數(shù)目快速增加。軟件配置管理152實施軟件配置管理要做的事情至少有：制定配置管理計劃

應(yīng)考慮：配置標(biāo)識的規(guī)則如何建立項目數(shù)據(jù)庫如何將軟件配置項置于配置管理之下配置管理人員的職責(zé)和配置管理活動采用什么樣的配置管理工具、技術(shù)和方法軟件配置管理153實施變更控制

許多軟件工程項目沒有變更控制措施導(dǎo)致出現(xiàn)混亂。實施版本管理和發(fā)行管理它應(yīng)當(dāng)解決下列問題：采用什么方式來標(biāo)識和管理許多已存在程序(和它們的文檔)的各種版本？在軟件交付用戶之前和之后如何控制變更？誰有權(quán)批準(zhǔn)和對變更安排優(yōu)先級？如何保證變更得以正確地實施？利用什么辦法來估計變更可能引起的其他問題？這些問題歸結(jié)到軟件配置管理的5個任務(wù)，即配置標(biāo)識、版本管理、變更控制、配置審核和配置報告。

軟件配置管理154版本控制是SCM的基礎(chǔ)，它管理并保護開發(fā)者的軟件資源。版本控制管理在軟件工程過程中建立起配置對象的不同版本。版本管理可以把一些屬性結(jié)合到各個軟件版本上。通過描述所希望的屬性集合來確定（或構(gòu)造）所想要的配置。使用演變圖來表示系統(tǒng)的不同版本。版本控制軟件配置管理155軟件配置管理156圖中的各個結(jié)點都是復(fù)合對象，是一個完全的軟件版本。軟件的每一版本都是SCI（源代碼、文檔、數(shù)據(jù)）的一個集合，且各個版本都可能由不同的變種組成。例如，一個簡單的程序版本由1、2、3、4和5等部件組成。其中部件4在軟件使用彩色顯示器時使用，部件5在軟件使用單色顯示器時使用。因此，可以定義版本的兩個變種。軟件配置管理157變更控制軟件生存期內(nèi)全部的軟件配置是軟件產(chǎn)品的真正代表，必須使其保持精確。軟件工程過程中某一階段的變更，均要引起軟件配置的變更，這種變更必須嚴(yán)格加以控制和管理，保持修改信息。變更控制包括建立控制點和建立報告與審查制度。軟件配置管理158軟件配置管理159配置狀態(tài)報告為了清楚、及時地記載軟件配置的變化，需要對開發(fā)的過程做出系統(tǒng)的記錄，以反映開發(fā)活動的歷史情況。這就是配置狀態(tài)登錄的任務(wù)。登錄主要根據(jù)變更控制小組會議的記錄，并產(chǎn)生配置狀態(tài)報告。對于每一項變更，記錄：發(fā)生了什么？為什么會發(fā)生？對誰做的？什么時侯發(fā)生的？會有什么影響？軟件配置管理160軟件配置管理161每次新分配一個SCI，或更新一個已有SCI的標(biāo)識，或一項變更申請被變更控制負責(zé)人批準(zhǔn)，并給出了一個工程變更順序時，在配置狀態(tài)報告中就要增加一條變更記錄條目。一旦進行了配置審計，其結(jié)果也應(yīng)該寫入報告之中。軟件配置管理162配置狀態(tài)報告可以放在一個聯(lián)機數(shù)據(jù)庫中，以便軟件開發(fā)人員或者軟件維護人員可以對它進行查詢或修改。此外在軟件配置報告中新登錄的變更應(yīng)當(dāng)及時通知給管理人員和軟件工程師。配置狀態(tài)報告對于大型軟件開發(fā)項目的成功起著至關(guān)重要的作用。避免了可能出現(xiàn)的不一致和沖突。本章內(nèi)容軟件質(zhì)量保證概述軟件質(zhì)量保證任務(wù)軟件質(zhì)量保證活動軟件質(zhì)量保證活動軟件質(zhì)量保證過程163軟件質(zhì)量保證過程的實施164Target：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準(zhǔn)則、質(zhì)量設(shè)計準(zhǔn)則的各質(zhì)量特性設(shè)定質(zhì)量目標(biāo)。Plan：設(shè)定適合于被開發(fā)軟件的評測檢查項目(質(zhì)量評價準(zhǔn)則)。研討實現(xiàn)質(zhì)量目標(biāo)的方法或手段。Do：制作高質(zhì)量的規(guī)格說明和程序。在接受質(zhì)量檢查前先做自我檢查。Check：以Plan階段設(shè)定的質(zhì)量評價準(zhǔn)則進行評價。計算結(jié)果用質(zhì)量圖的形式表示出來。比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標(biāo)，看其是否合格。Action：對評價發(fā)現(xiàn)的問題進行改進活動，如果實現(xiàn)并達到了質(zhì)量目標(biāo)就轉(zhuǎn)入下一個工程階段。這樣重復(fù)“Plan”到“Action”的過程，直到整個開發(fā)項目完成。軟件質(zhì)量保證過程的實施165軟件過程質(zhì)量保證方法166標(biāo)準(zhǔn)化流程（CMMI/ISO+內(nèi)控流程）質(zhì)量審計（獨立檢查與改進建議）同行評審（代碼/設(shè)計/需求互審）統(tǒng)計過程控制（SPC：跟蹤缺陷率/通過率等）階段性評審（StageGate：達標(biāo)方可過關(guān)）風(fēng)險管理（識別/應(yīng)對質(zhì)量風(fēng)險）第4章軟件測試管理本章內(nèi)容軟件測試流程軟件測試制品測試用例軟件測試環(huán)境軟件測試團隊軟件測試計劃缺陷管理測試管理工具168本章內(nèi)容軟件測試流程軟件測試制品測試用例軟件測試環(huán)境軟件測試團隊軟件測試計劃缺陷管理測試管理工具169軟件測試流程170軟件測試管理1711任務(wù)書2測試計劃3測試規(guī)范4問題報告5測試報告啟動計劃執(zhí)行、控制收尾組建測試組制定測試計劃測試設(shè)計開發(fā)測試執(zhí)行測試結(jié)果處理軟件測試管理的整體目標(biāo)：跟蹤、監(jiān)測團隊在整個軟件開發(fā)工作中計劃、開發(fā)、執(zhí)行并評估所有的測試活動。軟件測試管理有助于系統(tǒng)地、規(guī)范地管理各種測試資源和測試活動，以提高測試的效率和質(zhì)量。172軟件測試管理內(nèi)容四類管理內(nèi)容：測試計劃的管理測試制品的管理測試過程的管理測試人員及組織的管理173測試計劃測試計劃通常寫成文檔，描述要進行的測試活動的范圍、方法、資源和進度，確定測試項、被測特性、測試任務(wù)、誰執(zhí)行任務(wù)、各種可能的風(fēng)險。174TestCenter中的添加計劃175本章內(nèi)容軟件測試流程軟件測試制品測試用例軟件測試環(huán)境軟件測試團隊軟件測試計劃缺陷管理測試管理工具176軟件測試制品常見測試制品（TestArtifact）：測試用例（TestCase）測試腳本（TestScript）測試套件（TestSuite）測試計劃（TestPlan）測試評估總結(jié)（TestEvaluationSummary）177本章內(nèi)容軟件測試流程軟件測試制品測試用例軟件測試環(huán)境軟件測試團隊軟件測試計劃缺陷管理測試管理工具178測試用例測試用例是為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合，一般還規(guī)定測試的開始條件、測試過程的條件和結(jié)束條件。測試用例示例：179測試用例要素（1）標(biāo)識符Identification，指編號，為整型。此項必須有，用于不同文檔間的相互引用。（2）測試項TestItem，用來準(zhǔn)確描述待測試的項目及其特征，為字符型。此項必須有，作用是指明具體的測試對象/具體測試特性要求。（3）測試環(huán)境要求TestEnvironment，指特殊的環(huán)境要求，為字符型。此項可選，在一般軟硬件環(huán)境可以不必給出。（4）輸入標(biāo)準(zhǔn)InputCriteria，準(zhǔn)確描述輸入需求，包括數(shù)據(jù)、文件或操作步驟，必要時羅列數(shù)據(jù)庫和文件，為字符型。此項必須有，作用是指明執(zhí)行測試時具體的數(shù)據(jù)及輸入步驟。（5）輸出標(biāo)準(zhǔn)OutputCriteria，指按照指定的環(huán)境和輸入標(biāo)準(zhǔn)執(zhí)行后所期望的輸出結(jié)果，為字符型。此項必須有，要求描述清楚無異議，必要時盡量提供適當(dāng)?shù)南到y(tǒng)規(guī)格說明來證明期望的結(jié)果。（6）測試用例之間的關(guān)聯(lián)，用來表明本測試用例與其他測試用例之間的依賴關(guān)系，為字符型。180測試用例設(shè)計思想（1）設(shè)計測試用例的準(zhǔn)備工作。（2）測試用例命名細則（3）測試用例編號規(guī)則。（4）測試用例劃分（5）測試用例的設(shè)計原則（6）測試用例的粒度。181測試用例設(shè)計方法（1）常規(guī)的測試用例設(shè)計。（2）初始化的測試用例設(shè)計（3）邊界的測試用例設(shè)計（4）空值的測試用例設(shè)計（5）格式錯誤的測試用例設(shè)計（6）溢出的測試用例設(shè)計（7）關(guān)聯(lián)的測試用例設(shè)計（8）唯一值的測試用例設(shè)計（9）權(quán)限不足的測試用例設(shè)計（10）角色權(quán)限的測試用例182測試用例覆蓋要求（1）正確性測試。輸入用戶實際數(shù)據(jù)以驗證系統(tǒng)是滿足需求規(guī)格說明書的要求；測試用例中的測試點應(yīng)首先保證至少覆蓋需求規(guī)格說明書中的各項功能,并且正常。（2）健壯性測