1、精選優質文檔-傾情為你奉上目 錄測試用例編寫方法寫及其管理流程1測試用例是軟件測試的核心 如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。 測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。 2什么是測試用例n 所謂的測試用例就是將軟件測試的行為活動，做一個科學化的組織歸納。n 軟件測試是有組織性、步驟性和計劃性的，而設計軟件測試用例的目的，就是為了能將軟件測試的行為轉換為可管理的模式。n 軟件測試是軟件質量管理中最實際的行動，同時也是耗時最多的一項。n 基于時間因素的考慮，軟件測試行

2、為必須能夠加以量化，才能進一步讓管理階層掌握所需要的測試過程，而測試用例就是將測試行為具體量化的方法之一。n 因為我們不可能進行窮舉測試，為了節省時間和資源、提高測試效率，必須要從數量極大的可用測試數據中精心挑選出具有代表性或特殊性的測試數據來進行測試。n 目前研究室測試過程中，所有的測試用例都放在測試大綱中，使用測試大綱的好處：n 保證測試功能不被遺漏；n 使得功能不被重復測試，合理安排測試人員；n 使得軟件測試不依賴于個人；3測試用例的意義使用測試用例的好處主要體現在以下幾個方面：n 在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。n 測試用例的使用令軟件測試的實施重點突

3、出、目的明確。n 在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。n 功能模塊的通用化和復用化使軟件易于開發，而相對于功能模塊的測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。n 組織性有利于測試的組織；n 功能覆蓋確保功能不被遺漏；n 重復性有利于測試的重復；n 跟蹤有利于測試的跟蹤；n 測試確認在少數高風險的測試中，必須證明確實執行了計劃執行的測試；4如何設計測試用例測試用例一般指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。值得提出的是，測試數據都是從數量極大的可用測試數據中精心挑選

4、出具有代表性或特殊性的。測試用例是軟件測試系統化、工程化的產物，而測試用例的設計一直是軟件測試工作的重點和難點。設計測試用例即設計針對特定功能或組合功能的測試方案，并編寫成文檔。測試用例應該體現軟件工程的思想和原則測試用例應由測試人員在充分了解系統的基礎上在測試之前設計好，測試用例的設計是測試系統開發中一項非常重要的內容。集成測試階段測試用例的設計依據為系統需求分析、系統用戶手冊和系統設計報告等相關資料的內容，而且測試人員要與開發人員充分交互。另外有一些內容由測試人員的相關背景知識、經驗、直覺等產生測試用例的設計需要考慮很周全。在測試系統功能的同時，還要檢查系統對輸入數據（合法值、非法值和邊界

5、值）的反應，要檢查合法的操作和非法的操作，檢查系統對條件組合的反應等。好的測試用例讓其他人能夠很好地執行測試，能夠快速地遍歷所測試的功能，能夠發現至今沒有發現的錯誤。所以測試用例應該由經驗豐富的系統測試人員來編寫，對于新手來說，應該多閱讀一些好的測試用例，并且在測試實踐中用心去體會。在編寫測試用例之前，應該給出測試大綱，大綱基本上是測試思路的整理，以保證測試用例的設計能夠清晰、完整而不是顧此失彼。測試大綱可以按照模塊、功能點、菜單和業務流程這樣的思路來策劃5測試用例分析關于測試用例的分析，通常包括以下的內容：計劃了多少個測試用例，實際運行了多少？有多少測試用例失敗了？在這些失敗的測試用例中，有

6、多少個在錯誤得到修改后最終運行成功了？這些測試平均占用的運行時間比預期的長還是短？6有沒有跳過一些測試？如果有，為什么？測試覆蓋了所有影響系統性能的重要事件嗎？等等。這些問題都可以從相關的測試用例的設計和測試問題記錄中找到相應的答案。當然，如果使用了數據庫，這些問題就更能輕松地被解答了。測試用例的分析報告可以以多種形式體現出來：文字描述、表、圖等。用例編寫方案測試工作和開發通常一同進行，所以在完成測試計劃編寫后，就可以進行用例的編寫工作。測試和開發相對應的關系如表：開發階段依據文檔編寫的用例需求分析結束后需求文檔系統測試對應的用例概要設計階段結束后概要設計、體系設計集成測試對應的用例詳細設計階

7、段詳細設計文檔單元測試對應的用例測試用例各欄目列表如下：61用例ID用于唯一標識測試用例號，可根據自身需要定義規則，最好易于跟蹤和維護；62版本：軟件版本號63作者：編寫測試用例的人64測試時間：測試一條測試用例的相對時間65用例級別：按ABC三個等級定義66功能項：列出所測的功能項目68預置條條：列出用例的預置條件69測試目的：用例的測試目的610測試步驟：描述測試的過程、步驟或狀態611預期結果：預料中與規格相符的正確結果612執行結果：實際測試結果613測試結論：對測試作最終結論614問題ID614測試日期615測試人616備注測試用例各階段方法描述：第一階段：冒煙測試，即版本確認測試，

8、每個測試版本需通過所有該級測試用例，否則拒絕繼續測試； （至頂向底的測試方法）第二階段：關鍵路徑測試，每個測試版本需執行該級測試用例，若該級測試用例均通過，意味著軟件功能趨于穩定；（至底向頂的測試方法）第三階段：可接受級測試，該級測試用例只要執行一次通過即可，該級測試用例通過意味著可以準備發布了（驗收測試，如果有時間，最好執行該級測試用例）測試用例執行結果執行時填寫，分為通過、失敗、警告、阻塞、忽略測試用例覆蓋率分析報告7測試用例狀態轉換分析 以下測試用例生命周期圖顯示了一個典型測試用例的生命周期，依據不同類型和規模的項目可以自行定制。測試用例生命周期圖隊列中（ In Queue ） - 測試

9、用例在排隊等待中； 進程中（ In Progress ） - 表示測試正在進行，并且可能會持續一段時間，如果一個測試花費的時間少于一天或兩天，只需將它顯示在處于排隊狀態； 阻塞（ Block ） - 一些外部條件 如缺少部分功能 將無法執行測試； 忽略（ Skip ） - 已經決定（或被告知）跳過這個測試用例； 通過（ Pass ） - 終點狀態，沒問題； 失?。?Fail ） - 測試用例執行出錯； 警告（ Warn ） - 結果處于Pass和Fail之間，錯誤嚴重性等級較輕，不影響功能和性能； 關閉（ Closed ） - 以前識別出的錯誤都已經被修正。 實際項目中，一個測試用例有多個執行

10、步驟，每個步驟可能有不同結果，如步驟1通過，步驟2失敗，步驟3被步驟2中的失敗所阻塞，那么該測試狀態如何？單純指出這個測試用例阻塞或失敗都將遺漏重要的信息。因此必須指定雙重狀態，如：阻塞/失敗 ， 阻塞/警告，忽略/通過，忽略/關閉等。然而，如果顯示十幾個狀態，則測試結果可能更難以解釋。如何使結果明了又能精確反映實際結果，需要精明選擇包括哪些狀態。（舉例：多媒體播放測試用例ID129 (播放狀態如下圖) ID158、ID232、ID233） 8黑盒測試的測試用例設計目前黑盒測試的測試用例設計方法有45種：8.1等價類劃分等價列劃分設計方法是把所有可能的輸入數據，即程序的輸入域劃分成若干部分（子

11、集），然后從每一個子集中選取少量具有代表性的數據作為測試用例。等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價類的代表值就等于對這一類其他值的測試。等價類劃分有兩種不同的情況：有效等價類和無效等價類。設計時要同時考慮這兩種等價類。干個無效等價類（從不同角度違反規則）。6.在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進等價類中按以下的3個原則設計測試用例：為每一個等價類規定一個唯一的編號設計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止。設計一

12、個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。（舉例多媒體測試用例ID158：關于文件名的顯示用例類：有效文件名、無效文件名、文件名長度等）8.2邊界值分析法 使用邊界值分析方法設計測試用例，首先：應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。其次，應但選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。基于邊界值分析方法選擇測試用例的原則：1、 如果輸入條件規定了值的范圍，應取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入的數據。2、 如果輸入條件

13、規定了值的個數，應用最大個數、最小個數、比最小個數少一、比最大個數多一的數作為測試輸入的數據。3、 根據規格說明的每個輸出條件，使用前面的原則1。4、 根據規格說明的每個輸出條件，使用前面的原則2。5、 如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例數據。6、 如果程序中使用了一個內部數據結構，應當選擇這個內部數據結構邊界上的值作為測試用例。7、 分析規格說明，找出其他可能的邊界條件。(例如多媒體測試用例ID161)8.3錯誤推測法 錯誤推測法就是根據經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設計測試用例的方法。基本思路：列

14、舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。例如：輸入數據和輸出數據為0的情況。 下表為輸出條件及相應的測試用例表。（媒體播放器測試用例ID224、ID225、ID226）84因果圖法因果圖法是一種適合于描述對于多種條件的組合、相應產生多個動作的形式的測試用例設計方法。利用因果圖生成測試用例的基本步驟：8.41.1分析軟件規格說明描述中那些是原因，那些是結果，并給每個原因和結果賦予一個標識符。8.4.2分析軟件規格說明描述的語義。找出原因和結果之間、原因和原因之間的關系，根據這些關系，畫出因果圖。8.4.3在因果圖上用一些記號表明約束或限制條件。8.4.4把因果圖

15、轉換為判定表。8.4.5把判定表的每一列拿出來作為依據，設計測試用例。（例如多媒體測試用例ID108-140）以下為因果圖建立的實例A.。根據因果圖建立判定表。按條件的各種組合情況產生對應的動作。原因1和原因2不能同時成立，故可排除這種情況。從判定表可設計出測試用例：6個測試用例是所需的數據。 例如，有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規格說明如下：若投入5角錢或1元錢的硬幣，押下橙汁或啤酒的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示零錢找完的紅燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示零錢找完的紅燈滅，

16、在送出飲料的同時退還5角硬幣?！?1)分析這一段說明，列出原因和結果原因: 1.售貨機有零錢找2.投入1元硬幣 3.投入5角硬幣 4.押下橙汁按鈕 5.押下啤酒按鈕建立中間結點，表示處理中間狀態11.投入1元硬幣且押下飲料按鈕12.押下橙汁或啤酒的按鈕13.應當找5角零錢并且售貨機有零錢找14.錢已付清結果： 21. 售貨機零錢找完燈亮 22.退還1元硬幣 23.退還5角硬幣24.送出橙汁飲料25.送出啤酒飲料B.畫出因果圖。所有原因結點列在左，所有結果結點列在右邊。C. 由于2與3 ，4與5不能同時發生，分別加上約束條件E。D.因果圖9傳統的測試用例文檔編寫有兩種方式一種是填寫操作步驟列表：

17、將在軟件上進行的操作步驟一步一步詳細記錄下來，包括所有被操作的項目和相應的值。另一種是填寫測試矩陣：將被操作項作為矩陣中的一個字段，而矩陣中的一條條記錄，則是這些字段的值。10評價測試用例的好壞有以下兩個標準是否可以發現尚未發現的軟件缺陷？是否可以覆蓋全部的測試需求？ 11.創建測試數據時主要考慮如下步驟。識別測試資源識別測試情形排序測試情形確定正確的處理結果創建測試事務 12.確定實際的測試數據時，必須說明處理測試數據的以下4個屬性。（1）深度（2）寬度（3）范圍（4）結構13.輔助測試工具做軟件測試通常需要以下一些基本工具：優秀的辦公處理軟件秒表錯誤跟蹤系統自動測試工具軟件分析工具好的操作

18、系統多樣化平臺14. 執行測試執行測試是執行所有的或選定的一些測試用例，并觀察其測試結果的過程。盡管為執行測試所做的準備和計劃工作會貫穿于軟件開發生命周期之中，但是執行測試往往都會在軟件開發生命周期的末期，或者接近末期進行，即在編碼完成之后進行。由于測試過程一般分成代碼審查、單元測試、集成測試、系統測試和驗收測試幾個階段，盡管這些階段在實現細節方面都不相同，但其工作流程方面卻是一致141執行測試的過程由以下4個部分組成輸入。要完成工作所必須的入口標準或可交付的結果。執行過程。從輸入到輸出的過程或工作任務。檢查過程。確定輸出是否滿足標準的處理過程。輸出。推出標準或工作流程產生的可交付的結果。15

19、 評估測試軟件測試的主要評測方法包括測試覆蓋和質量評測。測試覆蓋是對測試完全程度的評測，它是由測試需求和測試用例的覆蓋或已執行代碼的覆蓋表示的。質量評測是對測試對象（系統或測試的應用程序）的可靠性、穩定性以及性能的評測，它建立在對測試結果的評估和對測試過程中確定的變更請求（缺陷）分析的基礎上。16覆蓋評測覆蓋指標提供了“測試的完全程度如何”這一問題的答案。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋。簡而言之，測試覆蓋是就需求（基于需求的）或代碼的設計/實施標準（基于代碼的）而言的完全程度的任意評測，如用例的核實（基于需求的）或所有代碼行的執行（基于代碼的）16.質量評測測試覆蓋的

20、評估提供對測試完全程度的評測，在測試過程中已發現缺陷的評估提供了最佳的軟件質量指標。 17.性能評測評估測試對象的性能行為時，可以使用多種評測，這些評測側重于獲取與行為相關的數據，如響應時間、計時配置文件、執行流、操作可靠性和限制。 18.測試的成功經驗為了減少系統的開發費用，越早測試越好，這是多年來軟件行業的一個成功經驗，即在整個軟件開發生命周期中通過各種軟件工程技術盡量早地完成各種軟件測試任務。首先，軟件的整個測試生命周期是與軟件的開發生命周期基本平齊的過程 在軟件開發生命周期中，軟件是通過迭代來不斷加以完善的。在這種環境中，對于每個作為測試目標的工作版本，測試的生命周期還都必須具有一種迭

21、代方法。對于針對每個工作版本執行的測試，都做出了增補和改進，并累積為一個測試體，用于后續階段的回歸測試。19.測試種類階段和用例關系具體的關系如表所示：測試階段測試類型執行人員單元測試模塊功能測試，包含部分接口測試，路徑測試開發人員集成測試接口測試、路徑測試、含部分功能測試開員人員，如果測試人員水平較較高的可以由測試人員執行系統測試功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試測試人員驗收測試對于實際項目基本上同上，并包含文檔測試，對于軟件產品主要測試相關技術文檔。測試人員，可能包含用戶20測試用例版本管理版本管理是用例管理的核心部分，建議用Visual sou

22、rcesafe對用例進行控制。（流程如下）201編寫用例：測試工程師根據需求規約、概要設計，詳細設計等文檔編定測試用202用例評審：原則上用例象程序一樣，要經過多次的修改才可以通過，實際工作中通常進行一次。203用例修改：評審結束后，需要根據評審意見進行修改，修改后通常不再進行評審。如果時間和人力充裕的情況下，對用例的評審就象測試開發部門的產品一樣，要經過反復的評評審和修改，然后正式投入使用，因為每次評審都可能有新的發現。204使用用例：在執行任務時版本按制庫取出用例，執行用例時建試超拔接在用例記錄上記錄測試結果，這樣做有兩個好處：首先是下次測試時可以看見上次測試結果，可以起一個提醒的作用，其

23、次，可以統一把發現的缺陷輸入到數據中，在輸入時可以進行分析，同時避免輸入重復的缺陷，每次使用后送入版本控制庫，進行版本控制。205用例升級/維護：隨著軟件的不斷修改、升級，對應的用例也需要升級維護。針對同一個項目，可以根據需求的變更不斷進行維護，對于軟件測試用例來說，就隨著軟件版本的升級而用例的維護版本也要升級，測試用例和版本要做到一一對應。21軟件測試流程：22軟件測試結果統計分析軟件問題統計與分析，在對軟件產品測試過程中發現的問題進行充分分析、歸納和總結的基礎上，由全體參與測試的人員完成“軟件問題傾向分析表”，對該軟件或該類型系統軟件產品在模塊、功能及操作等方面出錯傾向及其主要原因進行分析

24、。軟件問題傾向分析表將為以后開發工作提供一個參考，使開發人員根據軟件問題傾向分析表明確在開發過程中應注意和回避的問題。該表也可為以后的測試工作明確測試重點提供依據。按版本統計結果圖表達的是軟件的不同版本在測試時檢測出的缺陷(Bug)數的對應關系。這里的版本指的是同一軟件經過不同的測試階段并修復Bug及作必要的調整后所產生的軟件產品。顯然，該圖所表達的測試結果的變化是非常理想的。日期統計結果表達的是在一個測試階段所發現的缺陷數與測試日期之間的對應關系。測試過程中所發現的缺陷是隨著時間的推移而增多的，但一段時間后，測試所發現的缺陷增加會漸緩，甚至沒有增加，如果測試還在進行，那么表明，在現有測試用例

25、、軟硬件環境及相關條件下已經很難再發現新的缺陷了（雖然可以肯定系統中仍然存在缺陷），那么這個測試階段應該考慮停止了。按等級統計圖表達的是測試中所發現的不同等級的缺陷的數目。關于A、B、C、D等級（或者還有E、F、G、）所表達的不同含義由相關測試和開發人員來制定，而這種按等級的統計結果可以清楚地反映開發工作中的薄弱之處按原因統計結果 ：表達的是測試所發現的缺陷數目與究其原因缺陷所屬的軟件工程的不同階段之間的關系。這個圖表會又一次驗證軟件工程的任何階段都會有導致程序中產生錯誤的因素，只是程度和數目不同而已。通過該圖表的分析，可以清楚地看到，軟件工程中的哪個階段更應該加強控制。按模塊統計：表達的是程

26、序的不同模塊與在其中所發現的缺陷數目之間的關系。缺陷的產生有多方面的原因，但也可以從該圖中反映出哪些程序員所開發的模塊中Bug很多，而另一些程序員的則很少，那么在相同的系統設計和工作條件下，這也反映了程序員的工作能力或者責任感的不同按公開關閉日期統計：表達的是在測試過程中每日發現的錯誤報告公開、關閉的對應關系圖。公開是指錯誤被發現并被公告，關閉則指錯誤已被處理完畢的狀況。圖中中間兩條粗線反映的是錯誤累計公開和累計關閉的實際狀況。隨著時間的推移，累計公開和累計關閉的錯誤數目都是漸增的，但到某個時間點，兩條曲線會會合，即累計公開的數目等于累計關閉的數目，那就是說所有發現的錯誤都得到了處理。錯誤原因

27、根本分析：表達的是錯誤原因分析，其中縱軸表達的是每類測試發現錯誤占所有錯誤的百分比。可以看出，只有每個錯誤都被明確細致地歸類后才能得到這樣的分析圖表，也才能知道該從哪里去控制以減少錯誤的產生。23、測試軟件開發設計人員在軟件開發設計時，不可能完全預見用戶實際使用軟件系統的情況。另外，一個軟件產品可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為、測試的過程，以發現那些似乎只有最終用戶才能發現的問題。測試是在軟件開發公司內模擬軟件系統的運行環境下的一種驗收測試，即軟件開發公司組織內部人員，模擬各類用戶行為對即將面市的軟件產品（稱為版本）進行測試，試圖發現并修改錯誤經過測試調整的軟件產品稱為版

28、本。緊隨其后的測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用版本，并要求用戶報告異常情況，提出批評意見。然后軟件開發公司再對版本進行改錯和完善。所以，一些軟件開發公司把測試看成是對一個早期的、不穩定的軟件版本所進行的驗收測試，而把測試看成是對一個晚期的、更加穩定的軟件版本所進行的驗收測試。24回 歸 測 試回歸測試是指軟件系統被修改或擴充（如系統功能增強或升級）后重新進行的測試，是為了保證對軟件所做的修改沒有引入新的錯誤而重復進行的測試。每當軟件增加了新的功能，或者軟件中的缺陷被修正，這些變更都有可能影響軟件原有的功能和結構。24.1回歸測試技術和測試數據回歸測試一般采用黑盒測試

29、技術來測試軟件的高級需求，而無須考慮軟件的實現細節，也可能采用一些非功能測試來檢查系統的增強或擴展是否影響了系統的性能特性，以及與其他系統間的互操作性和兼容性問題。 錯誤猜測在回歸測試中是很重要的。錯誤看起來像是通過直覺發現軟件中的錯誤或缺陷，實際上錯誤猜測主要來自于經驗，測試者是使用了一系列技術來確定測試所要達到的范圍和程度，這些技術主要有：有關軟件設計方法和實現技術；有關前期測試階段結果的知識；測試類似或相關系統的經驗，了解在以前的這些系統中曾在哪些地方出現缺陷；典型的產生錯誤的知識，如被零除錯誤；通用的測試經驗規則。設計和引入回歸測試數據的重要原則是，應保證數據中可能影響測試的因素與未經

30、修改擴充的原軟件上進行測試時的哪些因素盡可能一致，否則要想確定觀測到的測試結果是由于數據變化還是很困難的。 回歸測試的范圍在回歸測試范圍的選擇上，一個最簡單的方法是每次回歸執行所有在前期測試階段建立的測試，來確認問題修改的正確性，以及沒有造成對其他功能的不利影響。 常用的用例選擇方法可以分為以下3種。（1）局限在修改范圍內的測試（2）在受影響功能范圍內回歸（3）根據一定的覆蓋率指標選擇回歸測試242回歸測試人員由于回歸測試一般與系統測試和驗收測試相關，所以要由測試組長負責，確保選擇使用合適的技術和在合理的質量控制中執行充分的回歸測試。測試人員在回歸測試工作中將設計并實現測試新的擴展或增強部分所

31、需的新測試用例，并使用正規的設計技術創建或修改已有的測試數據。在回歸測試過程中，測試過程由一個測試觀察員來監控測試工作。在回歸測試完成時測試組組長負責整理并歸檔大量的回歸測試結果，包括測試結果記錄、回歸測試日志和簡短的回歸測試總結報告243下面簡要介紹常用的3種排錯方法。原始類排錯方法是最常用也是最低效的方法，只有在萬般無奈的情況下才使用它，主要思想是“通過計算機找錯”。 回溯法能成功地用于程序的排錯。 歸納和演繹法采用“分治”的概念，首先基于錯誤出現有關的所有數據，假想一個錯誤原因，用這些數據證明或反駁它；或者一次列出所有可能的原因，通過測試一一排除。只要某次測試結果說明某種假設已呈現倪端，

32、則立即精化數據，進一步進行深入的測試。244有問題提到，修改一處老問題可能引入幾處新問題，有時程序越改越亂，但若能做到每次糾錯前都細心注意以下3個問題，情況將大為改觀。 導致這個錯誤的原因在程序其他部分還可能存在嗎？本次修改可能對程序中相關的邏輯和數據造成什么影響？引起什么問題？上次遇到的類似問題是如何排除的25測試策略測試策略描述測試小組用于測試整體和每個階段的方法。要描述如何公正、客觀地開展測試，要考慮模塊、功能、整體、系統、版本、壓力、性能、配置和安裝等各個因素的影響，要盡可能地考慮到細節，越詳細越好，并制作測試記錄文檔的模板，為即將開始的測試做準備。測試記錄具體說明如下。相對日期的測試

33、進度表測試任務開始時間期限測試計劃完成說明書完成之后起7天4周測試案例完成測試計劃完成12周第一階段測試通過代碼完成6周第二階段測試通過Beta構造6周第三階段測試通過發布構造4周測試方法選擇的綜合策略以下是各種測試方法選擇的綜合策略，可在實際應用過程中參考。n 首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率的最有效方法。n 在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。n 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。n 對于業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜