軟件制造工程組合測試

軟件制造工程組合測試第四章測試工程4.4測試的前期準(zhǔn)備軟件測試工程的作業(yè)過程可分為測試設(shè)計（包括制定測試計劃、確定測試方法等）和實施測試兩大步驟。測試規(guī)劃與測試設(shè)計對大規(guī)模開發(fā)系統(tǒng)一般不采用一次性整體測試，而是從局部依次擴大到整體的測試，按計劃，有步驟地實施測試。一般從項目需求定義開始，概要設(shè)計、詳細設(shè)計、程序編碼的各個開發(fā)階段，要進行測試設(shè)計，作成測試計劃書，還包括測試作業(yè)完成后移植運行作業(yè)的計劃。測試規(guī)劃與測試設(shè)計表4.3各開發(fā)階段的測試規(guī)劃和設(shè)計評審驗證內(nèi)容測試規(guī)劃與測試設(shè)計測試計劃書一般包括如下的一些的內(nèi)容：（1）測試工程概要、測試場所、測試方針（2）測試日程和實施體制測試規(guī)劃與測試設(shè)計（3）測試管理方法

·測試工具

·測試環(huán)境

·測試檢測清單

·驗證方法

·版本管理方法

·進度管理方法

·問題管理方法

·回歸測試方法

·設(shè)計變更管理方法測試規(guī)劃與測試設(shè)計（4）針對各階段的測試應(yīng)明確的事項

·階段測試的目的和范圍

·階段測試開始和測試終止的基準(zhǔn)

·階段測試檢測清單

·階段測試實施日程和實施體制

·階段測試的驗收基準(zhǔn)和方法4.4.2了解系統(tǒng)錯誤、缺陷的影響度

信息系統(tǒng)的測試很難實現(xiàn)在與實際運行環(huán)境（數(shù)據(jù)、使用者、硬件、時間、網(wǎng)絡(luò)、系統(tǒng)負荷等）完全一致的條件下進行的測試。在做測試計劃和測試設(shè)計時，充分理解軟件的錯誤、缺陷對用戶將會造成什么樣的影響是很重要的。4.4.2了解系統(tǒng)錯誤、缺陷的影響度軟件中即使是很微小的錯誤，有可能會給用戶造成重大的損害和影響。4.4.2了解系統(tǒng)錯誤、缺陷的影響度下圖是系統(tǒng)缺陷對一個生產(chǎn)型企業(yè)的各個方面所產(chǎn)生的影響

業(yè)務(wù)混亂系統(tǒng)缺陷喪失顧客信任經(jīng)濟損失不可能恢復(fù)的數(shù)據(jù)業(yè)務(wù)停止不能回答用戶的咨詢送貨發(fā)生錯誤交付期延遲不能處理用戶訂貨斷貨業(yè)務(wù)狀況不明不能檢索信息不能進行業(yè)務(wù)指示產(chǎn)品報廢業(yè)務(wù)效率降低發(fā)生手工作業(yè)發(fā)生返工用戶信息產(chǎn)品信息設(shè)計信息銷售信息生產(chǎn)信息系統(tǒng)缺陷的影響圖利用各種測試支持工具測試工具：⑴作為定型測試，反復(fù)實施測試作業(yè)的支持工具；⑵確定測試分支、生成測試數(shù)據(jù)的支持工具；⑶驗證測試的覆蓋率，提高測試效率的工具；⑷性能測試的支持工具；⑸管理與測試相關(guān)連項目的支持工具；⑹變更管理、版本管理的支持工具；⑺檢測錯誤作業(yè)的支持工具。利用各種測試支持工具表4.4部分常用的測試支持工具測試支持工具注意點組合測試支持工具·支持測試計劃的編制·支持測試項目管理·測試分支管理測試程序作成工具·支持作成測試分支的測試程序測試數(shù)據(jù)生成工具·自動生成測試數(shù)據(jù)自動測試工具·記錄用戶操作、自動生成測試程序·根據(jù)測試記錄自動運行測試程序·自動生成測試記錄測試管理工具·記錄已測試的編碼部分·統(tǒng)計分析測試的覆蓋范圍性能分析工具·測量運行時的特性·統(tǒng)計分析編碼的執(zhí)行次數(shù)、耗費時間檢測錯誤工具·提供檢測錯誤的功能（一般作為開發(fā)工具的功能提供）軟件管理工具·版本管理·變更管理表4.4常用測試支持工具4.4.4測試檢測清單與測試數(shù)據(jù)根據(jù)測試計劃，按各個測試階段的目的準(zhǔn)備實施測試使用的檢測清單和測試使用的數(shù)據(jù)。4.4.4測試檢測清單與測試數(shù)據(jù)測試檢測清單是將要檢測的項目以能確認的方式用文字描述出來。在不同的測試階段作成不同的測試檢測清單，如單元（模塊）測試階段的程序檢測清單稱為PCL，組合測試階段的檢測清單稱為CCL，系統(tǒng)測試階段的檢測清單稱為SCL。4.4.4測試檢測清單與測試數(shù)據(jù)在測試中需要驗證的項目及其判別、制約條件必須全部記入檢測清單。4.4.4測試檢測清單與測試數(shù)據(jù)例如單元測試的程序檢測清單PCL要明確以下幾個方面內(nèi)容：⑴窗體顯示的輸入、輸出項目及判別條件；⑵輸出表格印刷輸出項目及判別條件；⑶數(shù)據(jù)庫/文件輸入、輸出項目及判別條件；⑷程序間傳遞的數(shù)據(jù)、信息及判別條件。4.4.4測試檢測清單與測試數(shù)據(jù)作成檢測清單應(yīng)遵循如下的原則：⑴具體性：判別條件和確認內(nèi)容必須是在測試結(jié)果中可確認的；⑵完整性：檢測內(nèi)容必須是包含設(shè)計書中的所有項目、功能；⑶有一定的密度：檢測點占測試對象的一定比例。4.4.4測試檢測清單與測試數(shù)據(jù)⑷有一定的分布率：如PCL對正常、異常、臨界處理及模塊間接口數(shù)據(jù)、信息傳輸?shù)臋z測一般按如下比率分配：①檢測正常分支的PCL條數(shù)約占70%；②檢測異常分支的PCL條數(shù)約占10%；③檢測邊界、臨界項目的PCL條數(shù)約占15%；④檢測關(guān)聯(lián)模塊間傳遞、接口項目的PCL條數(shù)約占5%。4.4.4測試檢測清單與測試數(shù)據(jù)測試檢測清單針對各種各樣的測試分支，須明確測試的前提條件、應(yīng)確認的內(nèi)容，明確在何種條件下應(yīng)有什么樣的測試結(jié)果。每個測試分支都有編號，以便于實施測試時記錄測試結(jié)果。4.4.4測試檢測清單與測試數(shù)據(jù)測試結(jié)果的記錄不僅僅是記錄檢查合格，還要記錄測試結(jié)果的具體內(nèi)容。記錄測試結(jié)果要注意易讀性，便于他人追蹤測試中發(fā)現(xiàn)的問題。根據(jù)不同用戶的要求，測試內(nèi)容和測試結(jié)果還有可能作為開發(fā)方的系統(tǒng)驗證資料提供給用戶。4.4.4測試檢測清單與測試數(shù)據(jù)在測試工程的進度管理中，可以按測試檢測清單確定的測試分支作成測試實施日程，統(tǒng)計已實施測試的分支數(shù)，確認各個測試分支組的測試進度。因此測試檢測清單又可以用于測試進度管理。4.4.4測試檢測清單與測試數(shù)據(jù)作成測試檢測清單后，根據(jù)測試檢測清單記述的測試分支準(zhǔn)備其使用的測試數(shù)據(jù)。此外，根據(jù)測試分支的覆蓋率（正常處理、例外處理等）、測試分支數(shù)，還可預(yù)算測試工程所需要的工數(shù)。測試檢測清單格式要根據(jù)測試項目的不同而進行不同的設(shè)計。一般都應(yīng)包括檢查條件、確認內(nèi)容、確認日期等，并且要注意可讀性和可實施性，便于測試者做測試數(shù)據(jù)，進行測試。4.4.5測試前期準(zhǔn)備應(yīng)確認的事項（1）開發(fā)環(huán)境和測試環(huán)境（2）確保必要的測試時間（表4.5舉例說明了開發(fā)日程延后的對策處理方法。）4.4.5測試前期準(zhǔn)備應(yīng)確認的事項（3）留有余地的測試計劃（回歸測試）測試計劃時，必須考慮如何利用測試工具等多種手段有效實施回歸測試，并且制定出留有余地的測試計劃，例如，制定精確的測試流程、有效利用測試工具、使測試盡可能自動化、留有回歸測試的時間等。此外，因為變更、修正作業(yè)可能誘發(fā)新的錯誤，要根據(jù)測試中發(fā)現(xiàn)的問題的重要度、優(yōu)先順序進行問題管理和變更管理。例如，經(jīng)判斷，對于影響度低的問題，程序的修正可放在測試的最后階段，由專人集中實施，以減少變更、修正的工作量和風(fēng)險。4.4.5測試前期準(zhǔn)備應(yīng)確認的事項（4）系統(tǒng)的各個接口是測試工程的關(guān)注點 外部接口的測試，應(yīng)盡量避免在系統(tǒng)測試和運行測試時才實施。最好是在程序開發(fā)工程期間內(nèi)，即在單元測試階段實施接口測試。最初測試時，只需要確認接口部分的動作，不必要完成系統(tǒng)整體的邏輯處理。為接口部分的處理準(zhǔn)備簡單的程序，專門的測試數(shù)據(jù)，測試接收和傳送數(shù)據(jù)的效果。4.4.5測試前期準(zhǔn)備應(yīng)確認的事項在考慮測試計劃、設(shè)計測試方案時要注意以下幾點：（1）在設(shè)計工程期間要考慮組合測試計劃書；（2）站在用戶的立場考慮系統(tǒng)錯誤、缺陷造成的影響；（3）結(jié)合各種測試方法確定測試流程；（4）搭建必要的測試環(huán)境，確定測試工具；（5）將回歸測試列入測試計劃；（6）作測試計劃時要考慮盡早實施接口測試。4.5測試的實施在作好測試計劃的基礎(chǔ)上，確認開發(fā)作業(yè)已基本完成，測試工具、數(shù)據(jù)、環(huán)境等已準(zhǔn)備好，就可以進入測試作業(yè)。4.5.1各個測試階段的測試設(shè)計和實施者單元測試一般由開發(fā)程序的程序員實施。組合測試由詳細設(shè)計者和測試設(shè)計者實施。系統(tǒng)測試和運行測試一般由從事系統(tǒng)設(shè)計作業(yè)的系統(tǒng)工程師實施，而運行測試不僅僅是由承擔(dān)開發(fā)項目的企業(yè)或部門實施，而且要以用戶為主體實施。表4.6對各個測試階段的計劃、實施測試作業(yè)者給以了說明。4.5.2實施測試的要點1、實施測試前應(yīng)確認的事項測試前必須確認系統(tǒng)是否進入測試狀態(tài)。雖然各個測試階段有不同的測試重點，但是對于作為測試對象的軟件系統(tǒng)的核心部分，要盡早實施性能測試，即對軟件系統(tǒng)的效率性進行測試。4.5.2實施測試的要點2、風(fēng)險意識采用新技術(shù)、用戶需求變更、開發(fā)人員的變動等都有可能帶來風(fēng)險。風(fēng)險度=發(fā)生概率（發(fā)生頻率）×發(fā)生時的影響程度（損失）每個開發(fā)人員在自己擔(dān)任的作業(yè)中，都應(yīng)該經(jīng)常考慮有可能發(fā)生什么樣的風(fēng)險，一旦發(fā)現(xiàn)問題應(yīng)及時與項目管理者商談，盡可能避免和防止風(fēng)險的發(fā)生。4.5.2實施測試的要點3、問題管理在測試中發(fā)現(xiàn)錯誤，修正程序，再測試，確認修正是否正確，這是一般測試作業(yè)的流程。表4.7處理問題的流程處理流程作業(yè)人員處理內(nèi)容1發(fā)現(xiàn)問題測試人員記錄測試中發(fā)現(xiàn)的問題，交給驗證人員。2判斷問題，確定修正方案驗證人員分析問題，判斷問題的重要度，確定修正方案和修正人員。3修正問題開發(fā)人員理解問題，修正程序，確認修正是否正確；記錄問題發(fā)生的原因和修正的內(nèi)容，交給驗證人員。4確認修正內(nèi)容，確定回歸測試方案驗證人員確認修正內(nèi)容，確定對修正部分的回歸測試方法和測試人員。5修正確認測試人員確認問題是否被修正，記錄確認結(jié)果，交給驗證人員。表4.7處理問題的流程：4.5.2實施測試的要點問題管理的要點如下：⑴設(shè)置專人進行問題管理，對發(fā)生的問題作最終判斷；⑵對測試結(jié)果一定要有記錄；⑶作成問題一覽表，給每個問題編號，并記錄問題解決的狀況；⑷對發(fā)生的問題要立即記錄，以免遺忘；⑸對問題的記錄要注意語言簡潔、明確、準(zhǔn)確，同時要記錄實施測試時的條件（如測試環(huán)境、測試流程、測試數(shù)據(jù)）；4.5.2實施測試的要點⑹如果感覺是很難再現(xiàn)的問題，應(yīng)馬上保留測試環(huán)境、測試數(shù)據(jù)等，以便分析原因；如果實施測試者判斷是難以用文字表達的問題，要立即找開發(fā)人員或程序修正人員，現(xiàn)場說明；⑺問題發(fā)現(xiàn)者和處理者都要記錄和判斷問題的重要度；⑻問題處理者對記錄的問題不明白、或認為沒有必要修正程序時，要與測試人員聯(lián)系、確認；對判斷為不需要修正的問題，一定要說明理由；4.5.2實施測試的要點⑼修正錯誤之后。要記錄發(fā)生問題的現(xiàn)象和修正的內(nèi)容；⑽修正錯誤時要注意對同類問題的檢查，不能在程序或系統(tǒng)的其它地方遺留同樣的錯誤。4.5.2實施測試的要點4、問題記錄表（簡稱B票）記錄測試過程中發(fā)現(xiàn)的錯誤、問題。B票不僅僅是用于記錄錯誤信息，還可以提供給質(zhì)量管理人員、驗收人員，作為追蹤、分析、確認軟件質(zhì)量的原始資料，有利于改進和提高開發(fā)質(zhì)量。4.5.2實施測試的要點根據(jù)統(tǒng)計規(guī)律，一般要求各個測試階段發(fā)現(xiàn)的錯誤應(yīng)占測試對象規(guī)模的一定比例，以確保測試的質(zhì)量。4.5.2實施測試的要點B票主要記錄如下內(nèi)容：⑴發(fā)生錯誤的現(xiàn)象，如測試中發(fā)生功能遺漏、計算結(jié)果錯誤、打印錯誤等等；⑵產(chǎn)生錯誤的原因，如由于設(shè)計不良、理解錯誤、編程不良、測試數(shù)據(jù)錯誤等原因造成；⑶采取的對應(yīng)措施，如修正設(shè)計書、程序、測試數(shù)據(jù)等；⑷發(fā)生設(shè)計書、程序修正時，記錄其修正的范圍。4.5.2實施測試的要點5、不再現(xiàn)問題 測試中常發(fā)生曾經(jīng)出現(xiàn)而以后不在出現(xiàn)的問題，我們常稱之為不再現(xiàn)問題。4.5.2實施測試的要點一類是問題發(fā)生時環(huán)境發(fā)生了改變，如：⑴測試數(shù)據(jù)有變化；⑵硬件發(fā)生變化；⑶數(shù)據(jù)庫發(fā)生變化；⑷操作系統(tǒng)發(fā)生變化；⑸某個相關(guān)連的程序版本發(fā)生變化；⑹其他相關(guān)連程序發(fā)生故障；4.5.2實施測試的要點⑺受內(nèi)存空間變化的影響；⑻受測試時間、日期變化的影響；⑼運行到某種程度時系統(tǒng)內(nèi)部發(fā)生沖突；⑽系統(tǒng)狀態(tài)發(fā)生變化（初期狀態(tài)，多次運行狀態(tài)）。上述的⑺～⑽項屬于間歇性問題，發(fā)生的頻度低，但修正很花時間。4.5.2實施測試的要點另一類是在完全相同的環(huán)境下，由于人為的原因引起的變化，如：⑴操作順序發(fā)生變化；⑵測試人員未按測試流程進行作業(yè)；⑶測試人員變更；⑷無關(guān)人員觸動了系統(tǒng)。4.5.2實施測試的要點在發(fā)生不再現(xiàn)問題時，首先要對引起不再現(xiàn)問題的原因進行分析。同時，向測試實施者確認測試時的狀況，消除人為因素，盡可能在問題發(fā)生時的相同環(huán)境下進行再次測試，使問題再現(xiàn)。其次是收集、確認問題發(fā)生時的系統(tǒng)日志、程序日志，檢查相關(guān)連的程序，反復(fù)測試使問題再現(xiàn)。4.5.2實施測試的要點6、測試中發(fā)現(xiàn)的錯誤的水平展開 對測試中發(fā)現(xiàn)的錯誤、缺陷，不能僅限于對該錯誤、缺陷的修正，要同時注意分析程序中是否有其它類似的問題；是自己的理解錯誤，還是編程習(xí)慣產(chǎn)生的錯誤；別的程序是否也有類似的錯誤等等。4.5.2實施測試的要點7、版本的管理明確發(fā)現(xiàn)的錯誤是在什么時間的程序版本上測試的。每個參加測試、修正程序的開發(fā)人員要充分理解開發(fā)項目的整體版本管理方法。4.5.2實施測試的要點8、提高測試工程的效率測試工程是需要花費整個開發(fā)工程的約25%～50%的工數(shù)的工程從外部設(shè)計階段就開始考慮提高質(zhì)量和測試規(guī)劃，直到內(nèi)部設(shè)計階段考慮整體的測試方案，逐步形成周密的測試計劃。4.5.2實施測試的要點9、防止系統(tǒng)在正式運行中出現(xiàn)故障在正式運行前，要盡可能在接近真實的數(shù)據(jù)量、網(wǎng)絡(luò)環(huán)境、終端數(shù)量、集中使用密度等實際環(huán)境進行系統(tǒng)性能驗證測試、負荷測試、耐力測試等。在正式運行前，還需要從系統(tǒng)的應(yīng)用方面考慮編制操作手冊，進行用戶培訓(xùn)，建立技術(shù)支持體制。4.5.2實施測試的要點確保系統(tǒng)測試成功的一些要點⑴在充分理解用戶業(yè)務(wù)流程的基礎(chǔ)上設(shè)計測試流程；⑵在設(shè)計測試流程時設(shè)想用戶容易發(fā)生的操作錯誤；⑶對參加測試的人員進行相關(guān)業(yè)務(wù)培訓(xùn)，使測試人員對用戶業(yè)務(wù)有一定的了解；⑷確保系統(tǒng)測試必需要的時間和人員；⑸計劃測試日程時要考慮回歸測試的時間；⑹活用測試工具，提高測試效率；4.5.2實施測試的要點⑺系統(tǒng)測試以開發(fā)方為主體，用戶為輔，并著手準(zhǔn)備運行測試；⑻系統(tǒng)測試時盡可能使用接近真實的數(shù)據(jù)；⑼設(shè)想正式運行時系統(tǒng)的負荷進行耐力測試；⑽根據(jù)可靠性成長曲線（請參見中圖4.24）判斷測試的動向和進度，在出現(xiàn)異常曲線時采取適當(dāng)?shù)膶Σ?；⑾對發(fā)現(xiàn)的問題確定優(yōu)先順序，從優(yōu)先順序高的問題著手修正；⑿對測試發(fā)現(xiàn)的問題根據(jù)需要進行水平展開；⒀重視問題管理、設(shè)計變更管理和版本管理4.5.2實施測試的要點10、測試設(shè)計和實施測試中的注意事項表4.8說明了組合測試、系統(tǒng)測試和運行測試各個測試階段的主要測試工作，以及開始和結(jié)束的條件。表4.9說明了各個測試階段在測試設(shè)計和測試實施時一般應(yīng)注意的一些主要問題。4.5.3從運行測試到實機運行

1、運行測試的主要特征⑴運行測試以使用者為主體⑵運行測試是進行業(yè)務(wù)測試4.5.3從運行測試到實機運行

2、運行測試的結(jié)束 在結(jié)束運行測試，進入實機運行時，必須是用戶的所有與系統(tǒng)相關(guān)的人員都能夠使用該系統(tǒng)。因此為了確保系統(tǒng)實機運行能夠順利進行，用戶培訓(xùn)是非常必要的。一般在開發(fā)計劃中應(yīng)包括用戶培訓(xùn)計劃，準(zhǔn)備與實際系統(tǒng)接近的培訓(xùn)系統(tǒng)，在運行測試階段同時實施用戶培訓(xùn)。4.5.3從運行測試到實機運行

從運行測試到實機運行作以下幾點總結(jié)：①運行測試要以用戶為主體進行設(shè)計、實施；②業(yè)務(wù)測試是在運行測試階段實施，而不是在系統(tǒng)測試階段實施；③在進行運行測試前作成操作手冊；④盡早明確實機運行的評價基準(zhǔn)；⑤運行測試的設(shè)計、實施要從技術(shù)、業(yè)務(wù)、環(huán)境等多方面考慮；⑥運行測試是用戶培訓(xùn)的最好時機。4.5.4測試實例說明--單元測試測試策略單元測試一般總是把白盒測試法和黑盒測試法結(jié)合運用。先用黑盒測試法設(shè)計出一組基本的測試用例，然后用白盒測試法，根據(jù)覆蓋標(biāo)準(zhǔn)補充新的測試用例以滿足覆蓋標(biāo)準(zhǔn)。一般情況下，單元測試以白盒法為主。4.5.4測試實例說明--單元測試主要工作：根據(jù)詳細設(shè)計書作成單元測試使用的程序檢測清單（PCL）

PCL有矩陣型PCL

和表格式PCL。無論哪種格式，都有檢查項目、檢查條件、確認內(nèi)容、確認時間等基本內(nèi)容。作成PCL的主要思路是針對詳細設(shè)計書中的每個功能項目，列出其執(zhí)行時需要的條件，確認在相對應(yīng)的條件下應(yīng)產(chǎn)生的結(jié)果。4.5.4測試實例說明--單元測試主要工作：根據(jù)詳細設(shè)計書和PCL則可作成測試數(shù)據(jù)通?？梢杂靡慌鷶?shù)據(jù)來測試一個或幾個PCL的檢查項目，一般不采用一條數(shù)據(jù)測試一個或幾個PCL。使用問題記錄表（B票）記錄在測試過程中程序發(fā)生錯誤和對錯誤進行處理的相關(guān)信息。對測試結(jié)果進行整理。在測試結(jié)果中需要注明測試的輸入數(shù)據(jù)和輸出數(shù)據(jù)，并標(biāo)注相對應(yīng)的PCL的檢查項目編號。4.5.4測試實例說明--單元測試測試實例p120

程序檢測清單（PCL）表4.11是一個矩陣型PCLp122表4.12是一個表格式PCLp123

測試數(shù)據(jù)

P121

問：要完成PCL中的所有測試項目的測試，應(yīng)怎樣補充測試 數(shù)據(jù)？問題記錄表（B票）

P125

測試結(jié)果

P1264.5.4測試實例說明--組合測試組合測試需考慮的問題:

數(shù)據(jù)穿越接口可能丟失。一模塊可能破壞另一模塊功能。子功能組裝可能未產(chǎn)生所要求的主功能。全程數(shù)據(jù)結(jié)構(gòu)可能出問題。誤差累積問題。測試策略由獨立的測試小組進行測試用例通常采用黑盒法設(shè)計推進方式可采用漸增式或非漸增式模塊組合后，應(yīng)進行回歸測試（采用軟件改動前測試時執(zhí)行過的測試用例對改動后的軟件再進行測試。）4.5.4測試實例說明--組合測試主要工作：測試流程和測試計劃。測試流程的作成，一般可以利用基本設(shè)計的各個子系統(tǒng)的數(shù)據(jù)流程圖，按照各個子系統(tǒng)的輸入?yún)?shù)，自頂向下設(shè)計測試流程。同時，要做好測試計劃，落實各個子系統(tǒng)的測試期間、測試人員和驗收人員。CCL。CCL的作成一般以各個子系統(tǒng)的相關(guān)聯(lián)幾個程序模塊為單位進行。它主要檢測各個程序模塊之間的參數(shù)設(shè)置和傳遞是否正確，確認關(guān)聯(lián)程序運行的最后結(jié)果。4.5.4測試實例說明--組合測試主要工作：測試數(shù)據(jù)。測試數(shù)據(jù)的作成要按照CCL的檢查條件進行，一般要注意多個參數(shù)的各種組合條件的測試數(shù)據(jù)、數(shù)據(jù)記錄條數(shù)(1條或多條)和特殊條件下的測試數(shù)據(jù)的做成。當(dāng)然，基本數(shù)據(jù)文件（例如初期設(shè)定文件等），各種代碼表的數(shù)據(jù)文件要事先準(zhǔn)備好。4.5.4測試實例說明--組合測試主要工作：B票。組合測試階段的B票作成方法與單元測試階段的B票作成方法基本相同。其目的是要把測試過程中所發(fā)現(xiàn)的設(shè)計不良和程序錯誤記錄到B票中，以保證快速有效地解決問題，提高程序系統(tǒng)的質(zhì)量。測試結(jié)果。作成測試結(jié)果的目的首先是要使測試人員和驗收人員按照CCL和測試結(jié)果對各個子系統(tǒng)的功能進行嚴(yán)格檢查，其次是要證明所進行的組合測試是有效的。4.5.4測試實例說明--組合測試測試實例p127

程序檢測清單（CCL）主要檢測各個程序模塊之間的參數(shù)設(shè)置和傳遞是否正確，確認關(guān)聯(lián)程序運行的最后結(jié)果。表4.15CCL清單p128測試數(shù)據(jù)

P127

測試數(shù)據(jù)的作成要按照CCL的檢查條件進行，一般要注意多個參數(shù)的各種組合條件的測試數(shù)據(jù)、數(shù)據(jù)記錄條數(shù)(1條或多條)和特殊條件下的測試數(shù)據(jù)的做成。當(dāng)然，基本數(shù)據(jù)文件（例如初期設(shè)定文件等），各種代碼表的數(shù)據(jù)文件要事先準(zhǔn)備好。

問題記錄表（B票）

測試結(jié)果整理

P1294.6軟件調(diào)試測試與調(diào)試的比較調(diào)試的步驟調(diào)試?yán)щy的原因調(diào)試策略軟件測試與調(diào)試

測試與調(diào)試的比較

測試(test)調(diào)試(debug)以已知條件開始,使用預(yù)先定義的程序,有預(yù)知的結(jié)果以不可知內(nèi)部條件開始,結(jié)果一般不可預(yù)見有計劃被動的由獨立的測試組，在不了解軟件設(shè)計的條件下完成由程序作者進行發(fā)現(xiàn)錯誤找出錯誤位置，排除軟件調(diào)試調(diào)試的步驟從錯誤的外部表現(xiàn)形式著手，確定出錯位置；研究有關(guān)部分的程序，找出出錯的內(nèi)在原因；修改設(shè)計和代碼，以排除有關(guān)錯誤；進行回歸測試，以確認錯誤是否排除，是否引起新的錯誤；若不能通過回歸測試，則撤消此次修改活動，恢復(fù)設(shè)計和代碼至此次修改之前的狀態(tài)，并重復(fù)上述過程，直到錯誤得以改正。軟件調(diào)試調(diào)試?yán)щy的原因心理方面：高度焦慮、不愿接受可能發(fā)現(xiàn)的錯誤錯誤本身的特點錯誤癥狀和引起錯誤的原因相隔很遠（高度耦合的程序結(jié)構(gòu)）；錯誤癥狀可能在另一個錯誤被糾正后消失或暫時消失；錯誤癥狀可能實際并不是由錯誤引起的（如誤差）；錯誤癥狀可能是由不易跟蹤的人工操作引起的；軟件調(diào)試調(diào)試?yán)щy的原因錯誤本身的特點(續(xù))錯誤癥狀可能是和時間相關(guān)，而不是處理問題；很難再現(xiàn)錯誤癥狀的輸入條件；錯誤癥狀可能時有時無（如在軟硬件結(jié)合的嵌入式系統(tǒng)中）錯誤癥狀可能是由于把任務(wù)分布在若干不同處理器上運行而造成軟件調(diào)試調(diào)試策略猜測法通過分析錯誤癥狀，根據(jù)以往的經(jīng)驗，輔助使用已有的計算機工具，猜測錯誤的原因并進行定位。在程序中插入打印語句使用注釋或GOTO語句運行部分程序使用調(diào)試工具軟件調(diào)試調(diào)試策略跟蹤法檢查錯誤征兆，確定最先發(fā)現(xiàn)錯誤“癥狀”的位置，然后人工沿程序的控制流往回跟蹤源代碼，直到找出錯誤的根源；也可以向前跟蹤每條語句的執(zhí)行情況，找到最先出現(xiàn)錯誤的地方進行分析軟件調(diào)試調(diào)試策略原因排除法:先假定錯誤原因，然后利用數(shù)據(jù)證明或否定假設(shè)（歸納法）；或先列出所有可能的原因，然后逐一排除。（演繹法）收集有關(guān)數(shù)據(jù)組織數(shù)據(jù)研究數(shù)據(jù)間的關(guān)系提出假設(shè)證明假設(shè)糾正錯誤不能不能能能歸納法調(diào)試的過程軟件調(diào)試調(diào)試策略原因排除法:先假定錯誤原因，然后利用數(shù)據(jù)證明或否定假設(shè)（歸納法）；或先列出所有可能的原因，然后逐一排除。（演繹法）列舉可能原因排除不會發(fā)生的原因收集更多的測試結(jié)果分析余下的原因證明假設(shè)糾正錯誤無剩余有剩余能不能演繹法調(diào)試過程4.7軟件質(zhì)量與測試工程