【正文】 編寫和審核測試計劃如果在需求分析階段發(fā)現(xiàn)并結(jié)果問題需要花費$1，則在設(shè)計階段解決同樣的問題需花費$5，在編碼階段需$10，交付后解決同樣的問題需花費$200?！皆鐪y試越好在需求分析過程中測試人員需要進(jìn)行如下工作：1)理解需求，參與審核需求文檔；2)理解項目的目標(biāo)、限制，了解用戶的應(yīng)用背景；3)編寫測試計劃；4)準(zhǔn)備測試資源。+需求測試需求測試測試的對象是主意而不是代碼，針對文檔進(jìn)行測試。+好的需求文檔的特征具有清晰的格式和文檔結(jié)構(gòu)需求的內(nèi)容正確需求的內(nèi)容完整需求具有可行性需求的必要性對不同的需求優(yōu)先等級進(jìn)行定義描述明確可證性和可測試性可修改性可追蹤需求文檔被及時更新+需求測試內(nèi)容需求文檔是否符合公司的格式要求是否正確要保證需求文檔中所描述的內(nèi)容是真實可靠的這是“真正的”需求嗎？描述的產(chǎn)品是否是要開發(fā)的產(chǎn)品？需求是否完備？第一個發(fā)布的版本是否需要更多的功能？列出的需求可以減少一部分？需求是否兼容？需求有可能是矛盾的。需求是否可實現(xiàn)？如：需求設(shè)想的設(shè)備是否比實際運(yùn)行的要快？需求要求的內(nèi)存、I/0設(shè)備是否太多？需求的輸入或輸出設(shè)備要求的分辨率是否要求過高？需求是否合理？在開發(fā)進(jìn)度、開發(fā)費用、產(chǎn)品性能、可靠性和內(nèi)存使用之間存在著平衡關(guān)系。需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。+需求測試方法復(fù)查review走查walkthrough審查inspection+測試策略的內(nèi)容確定測試范圍 軟件是無法被完全測試的確定測試方法 不同的系統(tǒng)需要不同的測試方法定義測試標(biāo)準(zhǔn) 入口標(biāo)準(zhǔn)，暫停和繼續(xù)的標(biāo)準(zhǔn)，出口標(biāo)準(zhǔn)等+軟件測試結(jié)束的標(biāo)準(zhǔn)基于測試用例的使用規(guī)則1)構(gòu)造測試用例（由相關(guān)人員進(jìn)行評審）2)執(zhí)行測試用例中，當(dāng)測試用例的不通過率達(dá)到20%則拒絕繼續(xù)測試，待開發(fā)人員修正軟件后再繼續(xù)。3)當(dāng)功能性測試用例通過率達(dá)到100%，非功能性測試用例通過率達(dá)到90%時，允許正常結(jié)束?；凇皽y試期缺陷密度”規(guī)則含義：對軟件測試一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于系統(tǒng)測試基于“運(yùn)行期缺陷密度”規(guī)則含義：把軟件運(yùn)行一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于驗收測試注：一個階段的出口標(biāo)準(zhǔn)!=下一個階段的入口標(biāo)準(zhǔn)系統(tǒng)測試結(jié)束的標(biāo)準(zhǔn)!=軟件的發(fā)布標(biāo)準(zhǔn)發(fā)布標(biāo)準(zhǔn)!=軟件0缺陷選擇測試工具 是否需要，需要什么工具，怎么獲取降低軟件測試代價是企業(yè)普遍關(guān)注的問題，可通過；(萬般無奈下)+測試環(huán)境基本內(nèi)容：設(shè)備環(huán)境、軟件環(huán)境、數(shù)據(jù)環(huán)境需考慮的因素計算機(jī)平臺操作系統(tǒng)瀏覽器軟件支持平臺外圍設(shè)備網(wǎng)絡(luò)環(huán)境其他專用設(shè)備搭建測試環(huán)境時的配置原則：使用的頻度或范圍實效的可能性最大限度的模擬真實環(huán)境 +測試管理 由于測試工程中設(shè)計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進(jìn)行管理選擇缺陷管理工具和測試管理工具定義工作進(jìn)度建立風(fēng)險管理計劃+可能遇到的風(fēng)險由于設(shè)計、編碼階段出現(xiàn)大量質(zhì)量問題，導(dǎo)致測試工作量時間增加開始測試時所需的硬件、軟件沒有準(zhǔn)備好未能完成對測試人員的技術(shù)培訓(xùn)測試時的人力資源安排不足測試過程中，發(fā)生了大量的需求變更測試過程中，項目的開發(fā)計劃被大幅度調(diào)整不能及時準(zhǔn)備好測試所需的環(huán)境不能及時準(zhǔn)備好測試數(shù)據(jù)+風(fēng)險管理的過程識別風(fēng)險評估風(fēng)險制定對策跟蹤風(fēng)險+測試設(shè)計與開發(fā)+總體設(shè)計投入產(chǎn)出：測試設(shè)計的輸入是測試計劃，輸出是評審過的測試用例集合定義設(shè)計目標(biāo)遵循的原則清楚地說明沒項測試的目標(biāo)使每項測試的目標(biāo)單一，可以對應(yīng)到規(guī)格說明書中的一項需求只說明測試應(yīng)該完成什么工作，而不說明如何完成流程：總體設(shè)計開發(fā)測試用例評審測試用例+測試用例概念：為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合。+好的測試用例：容易發(fā)現(xiàn)軟件的錯誤精確的重復(fù)某測試失敗的情景，可重復(fù)性清晰的定義一個或多個期望的結(jié)果沒有冗余+測試用例的作用指導(dǎo)測試的實施作為編寫測試腳本的“設(shè)計規(guī)格說明書”評估測試標(biāo)準(zhǔn)的度量基準(zhǔn)分析缺陷的標(biāo)準(zhǔn)+白盒測試用例設(shè)計+設(shè)計方法+邏輯覆蓋法語句覆蓋判定覆蓋條件覆蓋判定條件覆蓋條件組合覆蓋路經(jīng)覆蓋基本路經(jīng)法+輔助模塊設(shè)計驅(qū)動模塊：相當(dāng)于被測程序的主程序。接受測試數(shù)據(jù)，把這些數(shù)據(jù)傳給被測模塊然后輸出實際測試結(jié)果。樁模塊：用于調(diào)用被測模塊調(diào)用的子模塊?？梢宰錾倭康臄?shù)據(jù)操作，不需要把子模塊的所有功能都帶進(jìn)來，但不容許什么都不做。+黑盒測試用例設(shè)計等價類劃分法邊界值法——“缺陷遺漏在角落里，聚集在邊界上。”因果圖法彌補(bǔ)等價類和邊界值法的不足錯誤推測法測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現(xiàn)，以保證測試是可重復(fù)的。+常見錯誤分析用戶界面問題輸入無合法性檢查和值域檢查。界面信息不能及時更新，不能正確反映數(shù)據(jù)狀態(tài)，甚至對用戶產(chǎn)生誤導(dǎo)。表達(dá)不清或過于模糊的信息提示。要求用戶輸入多余的本來系統(tǒng)可以自己得到的數(shù)據(jù)。為了得到某個設(shè)置或?qū)υ捒蛴脩舯仨氉鲈S多冗余的操作，如對話框嵌套太多。不能記憶用戶的設(shè)置或操作習(xí)慣，使每次進(jìn)入系統(tǒng)用戶都需重新操作一次初始環(huán)境。不經(jīng)用戶確認(rèn)就對系統(tǒng)或數(shù)據(jù)進(jìn)行了重大修改。形象類問題不符合用戶的操作習(xí)慣。如，快捷鍵定義不科學(xué)不實用，甚至無快捷鍵。不夠?qū)I(yè)，缺乏基本知識。界面中英文混雜，甚至拼寫錯誤。說明書或幫助的排版格式不專業(yè)：中英文不對應(yīng)，標(biāo)點的半全角問題，沒有排版準(zhǔn)則。界面元素參差不齊，文字不能完全顯示。－穩(wěn)定性問題不可重現(xiàn)的死機(jī)，或不斷申請但不能完全釋放資源，使系統(tǒng)性能越來越低。主系統(tǒng)和子系統(tǒng)使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數(shù)據(jù)庫字段名或登陸帳號。不能重現(xiàn)的錯誤，許多與代碼中的未初始化變量有關(guān)，有些與系統(tǒng)不檢查異常情況(網(wǎng)絡(luò)中斷、內(nèi)存申請不成功、長時間無響應(yīng)等)有關(guān)。其他問題運(yùn)行時不檢查內(nèi)存、硬盤空間、數(shù)據(jù)庫等。無根據(jù)的假設(shè)用戶環(huán)境：硬件/網(wǎng)絡(luò)情況；有些動態(tài)庫；假設(shè)網(wǎng)絡(luò)隨時都是聯(lián)通的。提供的版本帶病毒。提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。用戶現(xiàn)場開放和修改，又沒有記錄和保留。版本中部分內(nèi)容或接口倒退，或出現(xiàn)版本管理混亂。有些選項永遠(yuǎn)都是灰的，或有些在該變灰時沒變灰。+測試用例的評審測試或測試組件完全針對的是需求中列出的功能嗎？測試組件是否覆蓋了所有的需求？有冗余的嗎？每個測試步驟都有清楚描述的預(yù)期結(jié)果嗎？+優(yōu)先級+3級優(yōu)先級1：此測試用例必須執(zhí)行2：有時間就執(zhí)行3：可以不執(zhí)行+5級1：此測試必須通過，否則產(chǎn)品發(fā)布存在危險2：在發(fā)布前必須執(zhí)行3：時間允許就執(zhí)行4：此測試可以在下一次發(fā)布或發(fā)布后短期內(nèi)執(zhí)行5：可以不測試