軟件測(cè)試考試重點(diǎn)總結(jié)

軟件工程要點(diǎn)軟件是程序+數(shù)據(jù)+文檔。軟件危機(jī)產(chǎn)生的具體原因：需求不明確、缺乏理論指導(dǎo)、軟件開發(fā)規(guī)模和復(fù)雜度不斷增大。為了消除軟件危機(jī)，引入了軟件工程的概念，即使用系統(tǒng)化、規(guī)范化、數(shù)量化等工程化的方法和原則進(jìn)行軟件開發(fā)和維護(hù)。越早發(fā)現(xiàn)軟件缺陷，修復(fù)缺陷的花費(fèi)就越少，尤其是在需求和設(shè)計(jì)階段。軟件工程三要素：方法（如何開發(fā)軟件）、工具（提高效率）和過(guò)程（將方法和工具結(jié)合，規(guī)定方法使用的順序、每個(gè)階段交付物等）。軟件工程框架：目標(biāo)、過(guò)程和原則。目標(biāo)：生產(chǎn)具有正確性、可用性、開銷適宜、進(jìn)度保障并且項(xiàng)目成功的軟件產(chǎn)品。過(guò)程：生產(chǎn)一個(gè)成功軟件產(chǎn)品的步驟，包括開發(fā)過(guò)程、運(yùn)作過(guò)程和維護(hù)過(guò)程，這些過(guò)程覆蓋需求、設(shè)計(jì)、編碼、測(cè)試、維護(hù)等一系列活動(dòng)。原則：在生產(chǎn)軟件產(chǎn)品的過(guò)程中要遵循一些原則，比如選擇適宜的開發(fā)模型、合適的設(shè)計(jì)方法等。軟件生命周期（人有生命周期，軟件也存在生命周期）：定義（項(xiàng)目計(jì)劃、需求分析等）設(shè)計(jì)（概要設(shè)計(jì)+詳細(xì)設(shè)計(jì)）、實(shí)施（編碼）、測(cè)試和維護(hù)等活動(dòng)。這種按時(shí)間、按階段劃分任務(wù)是軟件工程一種思想。軟件生命周期模型瀑布模型、迭代模型、快速原型模型、增量模型、螺旋模型、敏捷開發(fā)、軟件構(gòu)件概念：讓軟件開發(fā)像機(jī)械制造工業(yè)一樣，可以用各種標(biāo)準(zhǔn)和非標(biāo)準(zhǔn)的零件來(lái)進(jìn)行組裝。好處：降低成本、構(gòu)件復(fù)用。軟件重用：可以原封不動(dòng)的拿來(lái)用或進(jìn)行修改后在使用。SOA(Service-OrientedArchitecture）,也叫面向服務(wù)的體系結(jié)構(gòu)或面向服務(wù)架構(gòu))是指為了解決在Internet環(huán)境下業(yè)務(wù)集成的需要，通過(guò)連接能完成特定任務(wù)的獨(dú)立功能實(shí)體實(shí)現(xiàn)的一種軟件系統(tǒng)架構(gòu)。重點(diǎn)是S服務(wù)和A架構(gòu)。QA是針對(duì)過(guò)程進(jìn)行質(zhì)量管理，Tester是針對(duì)軟件進(jìn)行測(cè)試。軟件項(xiàng)目管理內(nèi)容包括需求管理、項(xiàng)目估算與進(jìn)度管理、配置項(xiàng)管理、風(fēng)險(xiǎn)（潛在的問題）管理、項(xiàng)目質(zhì)量管理、項(xiàng)目資源管理（資金、財(cái)物等）。軟件項(xiàng)目管理的根本目的是通過(guò)對(duì)成本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行分析和管理，使軟件項(xiàng)目的整個(gè)生命周期都能在有效的控制下，按照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成。配置管理是對(duì)產(chǎn)品進(jìn)行標(biāo)識(shí)、存儲(chǔ)和控制，以維護(hù)其完整性、可追溯性以及正確性的學(xué)科。最終目標(biāo)是實(shí)現(xiàn)軟件產(chǎn)品的完整性、一致性、可控性，使產(chǎn)品極大程度地與用戶需求相吻合，它通過(guò)控制、記錄、追蹤對(duì)軟件的修改和每個(gè)修改生成的軟件組成部件來(lái)實(shí)現(xiàn)對(duì)軟件產(chǎn)品的管理功能。軟件配置項(xiàng)：操作手冊(cè)、服務(wù)、軟件包、協(xié)議等，即在軟件開發(fā)過(guò)程中產(chǎn)生的文檔、數(shù)據(jù)、程序等。我們通過(guò)配置管理（控制、記錄、追蹤）將配置項(xiàng)管理起來(lái)。比如，需求階段的配置項(xiàng)有需求文檔、設(shè)計(jì)階段有概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔。配置項(xiàng)通常會(huì)有一個(gè)基線，如果后期有變更，需要更新基線。V模型軟件測(cè)試基礎(chǔ)引起缺陷的原因：人自身原因、時(shí)間壓力、復(fù)雜的外部系統(tǒng)、技術(shù)的革新、復(fù)雜的代碼、復(fù)雜的系統(tǒng)架構(gòu)，主要體現(xiàn)在程序和文檔中。軟件測(cè)試立場(chǎng)不同，測(cè)試的目的不同。開發(fā)者角度確認(rèn)軟件已正確地實(shí)現(xiàn)了用戶的要求，證明軟件中不存在錯(cuò)誤，建立對(duì)軟件質(zhì)量的信心；用戶角度發(fā)現(xiàn)軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該產(chǎn)品。軟件測(cè)試目的：發(fā)現(xiàn)缺陷，提高質(zhì)量；驗(yàn)證是否滿足需求；建立軟件質(zhì)量的信心。軟件測(cè)試原則：（1）測(cè)試顯示缺陷的存在；（2）窮盡測(cè)試是不可能的；（3）測(cè)試盡早介入；（4）缺陷集群性（80-20原則）；（5）殺蟲劑悖論；（6）測(cè)試活動(dòng)依賴于測(cè)試背景；（7）不存在缺陷的謬論。質(zhì)量度量是為了改進(jìn)軟件測(cè)試的質(zhì)量，提高測(cè)試效率，改進(jìn)測(cè)試過(guò)程的有效性。軟件測(cè)試工作流程：測(cè)試計(jì)劃、測(cè)試需求分析和用例設(shè)計(jì)、實(shí)現(xiàn)和執(zhí)行測(cè)試用例、測(cè)試出口準(zhǔn)則和報(bào)告、測(cè)試活動(dòng)結(jié)束，其中控制貫穿整個(gè)測(cè)試工作流程。基于生命周期的軟件測(cè)試1、軟件測(cè)試與軟件開發(fā)一樣，都是一個(gè)過(guò)程。包括測(cè)試流程和方法，及管理測(cè)試項(xiàng)目的進(jìn)度、質(zhì)量和成本，還有一系列覆蓋整個(gè)測(cè)試階段的任務(wù)。2、全生命周期測(cè)試意味著測(cè)試與開發(fā)并行，有利于盡早的發(fā)現(xiàn)缺陷，縮短項(xiàng)目開發(fā)的周期。3、生命周期各階段測(cè)試工作劃分：需求、設(shè)計(jì)、編程、測(cè)試、安裝/集成、維護(hù)，不同的階段測(cè)試重點(diǎn)不同。需求階段重點(diǎn)是定義的需求要符合客戶的要求；（需求階段是非常重要的，需求沒有做好，后期工作會(huì)很難開展）設(shè)計(jì)和編程階段重點(diǎn)是驗(yàn)證設(shè)計(jì)和程序?qū)崿F(xiàn)了需求；（是否實(shí)現(xiàn)了用戶提出的需求）測(cè)試和安裝階段重點(diǎn)是檢查實(shí)現(xiàn)的系統(tǒng)是否符合系統(tǒng)說(shuō)明書；維護(hù)階段重點(diǎn)重新測(cè)試系統(tǒng)改變的部分和未改變部分能正常工作。擴(kuò)展：項(xiàng)目的概念：包含起始點(diǎn)和結(jié)束點(diǎn)，屬于范圍的范疇。通常維護(hù)階段是在項(xiàng)目結(jié)束之后，一般不屬于項(xiàng)目的范疇。4、測(cè)試計(jì)劃是描述要進(jìn)行的測(cè)試活動(dòng)的范圍、方法、資源和進(jìn)度的文檔。測(cè)試計(jì)劃最關(guān)鍵的一步就是將軟件分解成單元，寫成測(cè)試需求。5、測(cè)試的準(zhǔn)入和準(zhǔn)出條件P1036、基于風(fēng)險(xiǎn)的軟件測(cè)試風(fēng)險(xiǎn)就是潛在的問題，風(fēng)險(xiǎn)的級(jí)別是由兩方面（維度）決定的，即出現(xiàn)不確定事件的可能性和出現(xiàn)后所產(chǎn)生的影響。比如地震出現(xiàn)的可能性和影響跟地理位置有關(guān)。如何處理風(fēng)險(xiǎn)？什么都不做，接受風(fēng)險(xiǎn)；轉(zhuǎn)移風(fēng)險(xiǎn)；減輕風(fēng)險(xiǎn)；避免風(fēng)險(xiǎn)。基于風(fēng)險(xiǎn)的軟件測(cè)試是指首先評(píng)估被測(cè)軟件的風(fēng)險(xiǎn)，然后根據(jù)不同的風(fēng)險(xiǎn)采用不同力度的測(cè)試。步驟：（1）列出風(fēng)險(xiǎn)列表（2）評(píng)估每個(gè)風(fēng)險(xiǎn)的級(jí)別（3）進(jìn)行考察每個(gè)風(fēng)險(xiǎn)的測(cè)試（4）當(dāng)風(fēng)險(xiǎn)消失而新的風(fēng)險(xiǎn)出現(xiàn)時(shí)，重新調(diào)整測(cè)試策略。基于風(fēng)險(xiǎn)的測(cè)試是一種有效的測(cè)試方法，在什么情況下可以使用？測(cè)試任務(wù)面臨時(shí)間壓力（測(cè)試時(shí)間不夠）、系統(tǒng)需求質(zhì)量不高或不完整、風(fēng)險(xiǎn)級(jí)別?；陲L(fēng)險(xiǎn)的軟件測(cè)試的活動(dòng)實(shí)踐：（1）根據(jù)風(fēng)險(xiǎn)確定測(cè)試優(yōu)先級(jí)（2）根據(jù)風(fēng)險(xiǎn)情況確定測(cè)試完備性，例如風(fēng)險(xiǎn)越大需要測(cè)試更充分和完備（3）確定測(cè)試資源的分配（4）及時(shí)監(jiān)控測(cè)試進(jìn)度（5）加速測(cè)試信心提升。7、生命周期各個(gè)階段的測(cè)試要求需求階段：需求階段測(cè)試目標(biāo)是保證需求分析的正確性和充分性。設(shè)計(jì)階段：設(shè)計(jì)階段要根據(jù)需求分析詳細(xì)定義要交付的產(chǎn)品。之后要對(duì)交付物進(jìn)行評(píng)審。編碼階段：編碼階段首要問題是編碼是否和設(shè)計(jì)一致，因?yàn)榫幋a是根據(jù)設(shè)計(jì)進(jìn)行的。這個(gè)階段要輸出編碼說(shuō)明書、程序文檔、可執(zhí)行程序、流程圖等。測(cè)試階段：在全生命周期的測(cè)試中，需求、設(shè)計(jì)、編碼都進(jìn)行了測(cè)試，這里測(cè)試主要是第三方的確認(rèn)測(cè)試，來(lái)檢驗(yàn)所開發(fā)的系統(tǒng)是否按照用戶提出的要求運(yùn)行。測(cè)試階段會(huì)經(jīng)過(guò)一系列的測(cè)試活動(dòng)，比如功能測(cè)試、性能測(cè)試、強(qiáng)度測(cè)試等，最終需要生成測(cè)試報(bào)告。安裝階段：安裝階段測(cè)試準(zhǔn)備有安裝計(jì)劃、安裝流程圖、安裝文件和程序清單、安裝的預(yù)期結(jié)果以及安裝過(guò)程中出現(xiàn)問題的應(yīng)對(duì)措施、用戶手冊(cè)等。驗(yàn)收階段：首先定義用戶角色，定義驗(yàn)收的標(biāo)準(zhǔn)，編制驗(yàn)收計(jì)劃，執(zhí)行驗(yàn)收計(jì)劃，填寫驗(yàn)收結(jié)論。維護(hù)階段：維護(hù)階段重點(diǎn)是測(cè)試和培訓(xùn)（維護(hù)階段由運(yùn)維人員完成，我們需要培訓(xùn)相關(guān)人員正確使用軟件）評(píng)審的目的是發(fā)現(xiàn)問題，并非找缺陷。評(píng)審在測(cè)試的各個(gè)階段都要進(jìn)行。軟件測(cè)試分類與分級(jí)1、軟件配置項(xiàng)是為獨(dú)立的配置管理而設(shè)計(jì)的且能滿足最終用戶要求的一組軟件，簡(jiǎn)稱軟件配置項(xiàng)。即我們?cè)谲浖_發(fā)過(guò)程中，產(chǎn)生的所有信息，包括代碼（目標(biāo)代碼和源代碼）、文檔（需求文檔、設(shè)計(jì)文檔等）、報(bào)告（測(cè)試報(bào)告等）。要成為配置項(xiàng)必須經(jīng)過(guò)審核。比如，新生成的需求分析文檔，需要經(jīng)過(guò)審核，審核通過(guò)才能成為配置項(xiàng)，如果增加需求，就需要提交變更申請(qǐng)，經(jīng)過(guò)需求變更委員會(huì)CCB的審核，進(jìn)行變更。2、軟件配置管理就是來(lái)管理這些配置項(xiàng)的投放和變更，即項(xiàng)目過(guò)程中，不斷產(chǎn)生新的信息，就需要記錄并報(bào)告配置的狀態(tài)和變更要求，驗(yàn)證配置的完整性、正確性和一致性。3、基線是指受配置管理控制的某個(gè)研制階段的結(jié)束點(diǎn)時(shí)軟件成分的技術(shù)狀態(tài)，是已經(jīng)經(jīng)過(guò)正式審核和同意，它是下一步軟件開發(fā)的基礎(chǔ)。在產(chǎn)生新的配置項(xiàng)后，需要對(duì)其進(jìn)行評(píng)審，一旦評(píng)審?fù)ㄟ^(guò)，該配置項(xiàng)就可以成為基線。4、軟件測(cè)試分類：從不同的角度，分類不同。是否關(guān)心內(nèi)部結(jié)構(gòu)：白盒、黑盒、灰盒測(cè)試；開發(fā)過(guò)程級(jí)別：?jiǎn)卧?、集成、系統(tǒng)、驗(yàn)收測(cè)試；是否執(zhí)行程序：靜態(tài)測(cè)試、動(dòng)態(tài)測(cè)試；執(zhí)行過(guò)程是否需要人工干預(yù)：手工測(cè)試、自動(dòng)化測(cè)試；測(cè)試實(shí)施組織：開發(fā)測(cè)試、用戶測(cè)試、第三方測(cè)試。5、基于CSCI的軟件測(cè)試分類，共有6大特性，13個(gè)測(cè)試內(nèi)容。并非所有的測(cè)試內(nèi)容都需要測(cè)試，要根據(jù)需求說(shuō)明有選擇的測(cè)試。6、根據(jù)不同的情況對(duì)軟件測(cè)試的分級(jí)也會(huì)有所不同，常關(guān)注的分級(jí)主要有生命周期測(cè)試的分級(jí)、錯(cuò)誤及其對(duì)軟件測(cè)試通過(guò)影響的分級(jí)、完整性測(cè)試的分級(jí)、測(cè)試用例的分級(jí)等。7、單元測(cè)試主要發(fā)現(xiàn)組件內(nèi)部的功能性和非功能性的問題，其中功能性包括：邏輯錯(cuò)誤和功能丟失；非功能性包括：語(yǔ)法錯(cuò)誤、缺少注釋、代碼不具有良好結(jié)構(gòu)性、空指針、數(shù)組越界等。（這里單元可以使單獨(dú)的模塊、也可以使程序或者功能）。集成測(cè)試主要對(duì)接口進(jìn)行測(cè)試以及檢查與系統(tǒng)其它部分相互作用的測(cè)試。系統(tǒng)測(cè)試強(qiáng)調(diào)測(cè)試環(huán)境，測(cè)試環(huán)境不是生產(chǎn)環(huán)境，需要接近用戶的真實(shí)環(huán)境。在需求規(guī)格說(shuō)明書中每一個(gè)功能描述可能會(huì)有一個(gè)或者多個(gè)需求。測(cè)試策略用于描述某項(xiàng)特定測(cè)試工作的方法和目標(biāo)。系統(tǒng)測(cè)試要交付的文檔：系統(tǒng)測(cè)試計(jì)劃、系統(tǒng)測(cè)試計(jì)劃評(píng)審報(bào)告、系統(tǒng)測(cè)試用例、系統(tǒng)測(cè)試用例評(píng)審報(bào)告、系統(tǒng)測(cè)試腳本、系統(tǒng)測(cè)試腳本評(píng)審報(bào)告、系統(tǒng)測(cè)試報(bào)告、系統(tǒng)測(cè)試報(bào)告評(píng)審報(bào)告、缺陷跟蹤記錄等。軟件錯(cuò)誤分級(jí)分為兩方面：錯(cuò)誤分類和錯(cuò)誤級(jí)別劃分。錯(cuò)誤分類按軟件生命周期分類有用戶需求錯(cuò)誤、產(chǎn)品需求錯(cuò)誤、設(shè)計(jì)錯(cuò)誤、編碼錯(cuò)誤、數(shù)據(jù)錯(cuò)誤、發(fā)行錯(cuò)誤。按軟件使用分類有功能錯(cuò)誤、性能錯(cuò)誤、界面錯(cuò)誤、流程錯(cuò)誤、數(shù)據(jù)錯(cuò)誤、提示錯(cuò)誤（能夠正確提示信息）、常識(shí)錯(cuò)誤等。按GB/T15532-2008分類有程序問題、文檔問題、設(shè)計(jì)問題等。錯(cuò)誤級(jí)別劃分大致分為5級(jí)，第1級(jí)是嚴(yán)重缺陷（死機(jī)、死循環(huán)等）、第2級(jí)是較嚴(yán)重缺陷（重要功能無(wú)法使用等）、第3級(jí)是一般性缺陷、第4級(jí)是較小缺陷、第5級(jí)是其他缺陷。通常前兩級(jí)或前三級(jí)的缺陷是必須修復(fù)的。注：以上錯(cuò)誤分類根據(jù)不同公司要求會(huì)有變化。軟件缺陷管理1、任何軟件都存在缺陷，軟件缺陷包括檢測(cè)缺陷（交付給用戶之前檢測(cè)出的缺陷）和殘留 缺陷（軟件發(fā)布之后存在的缺陷）。軟件缺陷主要體現(xiàn)在3方面，即軟件錯(cuò)誤、軟件失效和軟件故障。其中軟件失效指軟件功能的能力喪失、程序操作背離了程序需求。軟件故障是軟件沒有表現(xiàn)出人們所期待的正確結(jié)果（常指發(fā)布之后使用中出現(xiàn)的問題），軟件故障屬于殘留缺陷，危害較大。2、判斷缺陷的5條原則：（1）軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書要求的功能（2）軟件出現(xiàn)了產(chǎn)品說(shuō)明書指明不應(yīng)該出現(xiàn)的錯(cuò)誤（3）軟件實(shí)現(xiàn)了產(chǎn)品說(shuō)明書中未提到的功能（4）軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)（5）軟件難以理解、不易使用、運(yùn)行緩慢或者從測(cè)試員的角度看最終用戶認(rèn)為不好。例如：（1）計(jì)算器產(chǎn)品規(guī)格說(shuō)明書規(guī)定能夠進(jìn)行加法運(yùn)算，但測(cè)試過(guò)程中按下加法按鈕沒有反應(yīng)。（2）產(chǎn)品規(guī)格說(shuō)明書還可能規(guī)定計(jì)算器不會(huì)死機(jī)，或者停止反應(yīng)。如果隨意敲鍵盤導(dǎo)致計(jì)算器死機(jī)或停止反應(yīng)。（3）如果使用計(jì)算器進(jìn)行測(cè)試，發(fā)現(xiàn)除了加、減、乘、除之外還可以求平方根，但是產(chǎn)品規(guī)格說(shuō)明沒有提及這一功能。（4）在測(cè)試計(jì)算器時(shí)若發(fā)現(xiàn)電池沒電會(huì)導(dǎo)致計(jì)算不正確，而產(chǎn)品說(shuō)明書是假定電池一直都有電的。（5）測(cè)試發(fā)現(xiàn)按鈕太小、界面不美觀等。3、缺陷產(chǎn)生的原因？（1）需求定義不完善（2）客戶與開發(fā)之間沒有良好的溝通（3）對(duì)軟件需求的故意偏離（4）邏輯設(shè)計(jì)錯(cuò)誤（5）編碼錯(cuò)誤（6）不符合文檔編制與編碼規(guī)定（7）測(cè)試過(guò)程不足（8）規(guī)程/標(biāo)準(zhǔn)錯(cuò)誤（9）文檔編制錯(cuò)誤4、經(jīng)過(guò)對(duì)以上原因的調(diào)查分析，發(fā)現(xiàn)缺陷主要產(chǎn)生在需求分析階段和設(shè)計(jì)階段。其中在需求階段，會(huì)產(chǎn)生軟件需求規(guī)格說(shuō)明書，說(shuō)明書中規(guī)定了軟件應(yīng)該實(shí)現(xiàn)的功能、不應(yīng)該出現(xiàn)的功能、功能模塊是如何操作的、軟件要滿足哪些性能要求等。需求規(guī)格說(shuō)明書經(jīng)過(guò)評(píng)審（屬于靜態(tài)測(cè)試）后就成配置項(xiàng)。需求階段會(huì)生成需求跟蹤矩陣RTM，在后期各個(gè)階段通過(guò)對(duì)比RTM，獲得需求覆蓋程度。5、我們的目的是找出缺陷，但是有很多缺陷難以找出，主要的原因有：（1）缺陷很難看到（2）缺陷看到了很難抓到（3）抓到了無(wú)法修改或很難修改（4）人們隨時(shí)都會(huì)犯錯(cuò)，造成軟件中存在缺陷。6、缺陷的描述即當(dāng)我們發(fā)現(xiàn)缺陷后，如何記錄缺陷并把它描述出來(lái)，就需要描述如下信息：（1）可追蹤信息，即缺陷ID，具有唯一性；（2）缺陷的基本信息，包括缺陷標(biāo)題、嚴(yán)重程度、緊急程度等；（3）缺陷的詳細(xì)描述，主要包括缺陷產(chǎn)生的情況、缺陷重現(xiàn)步驟等；（4）測(cè)試環(huán)境說(shuō)明，即在什么環(huán)境下進(jìn)行的測(cè)試，有助于缺陷重現(xiàn)；（5）必要的附件，例如發(fā)生缺陷時(shí)的截圖等。（6）統(tǒng)計(jì)信息7、在缺陷描述的基礎(chǔ)上，還要對(duì)缺陷進(jìn)行分類，在分類之前我們首先需要知道缺陷的屬性，缺陷的屬性包括屬性名稱描述、缺陷標(biāo)識(shí)、缺陷類型、嚴(yán)重程度、缺陷優(yōu)先級(jí)、缺陷狀態(tài)、缺陷起源、缺陷來(lái)源、缺陷根源等。并非嚴(yán)重程度越高修復(fù)缺陷的優(yōu)先級(jí)就越高，因?yàn)橛行╉?xiàng)目時(shí)間緊迫，并且修改這一缺陷會(huì)涉及項(xiàng)目其他各個(gè)模塊，在這種情況下，該缺陷可能會(huì)遺留下來(lái)。在測(cè)試過(guò)程中會(huì)產(chǎn)生很多缺陷，因此我們需要對(duì)缺陷進(jìn)行分類，分成哪些類型？目前有很多組織制定缺陷分類標(biāo)準(zhǔn)，書上列出的有5中分類法，這里不再列出。通常情況下，不同的公司對(duì)缺陷的分類是不同的，會(huì)根據(jù)一些標(biāo)準(zhǔn)制定適合本公司的缺陷分類。8、實(shí)際應(yīng)用中缺陷分類通常是按照以下幾種形式：按缺陷的表現(xiàn)形式（功能、賦值、接口等）、按嚴(yán)重程度劃分（非常嚴(yán)重、嚴(yán)重、中等、微小、其他）、按修復(fù)優(yōu)先級(jí)劃分（高、中、低）、按起源（需求、設(shè)計(jì)、編碼及測(cè)試階段發(fā)現(xiàn)的缺陷）和來(lái)源（文檔、代碼等）劃分、按根源（造成缺陷的根本性因素）劃分9、在缺陷生命周期（缺陷從提出到解決，并通過(guò)復(fù)查）過(guò)程中，不同角色有不同的工作內(nèi)容：測(cè)試人員（發(fā)現(xiàn)缺陷）：初始化new再修正reopen關(guān)閉close開發(fā)人員（修復(fù)缺陷）：待修正open拒絕reject修正fixed項(xiàng)目經(jīng)理（對(duì)項(xiàng)目負(fù)責(zé)，對(duì)產(chǎn)品質(zhì)量負(fù)責(zé)）：待修正open待分配評(píng)審委員會(huì)（當(dāng)測(cè)試與開發(fā)存在分歧時(shí)，通常由需求人員決定）：待修正open關(guān)閉close不同的公司對(duì)缺陷管理的流程也不同，角色也可能有其他分工，但大致都是以上內(nèi)容。10、缺陷分析步驟：記錄缺陷、缺陷分類、缺陷分析、編寫缺陷分析報(bào)告。11、缺陷報(bào)告是軟件測(cè)試過(guò)程中重要的文檔，記錄了缺陷發(fā)生的環(huán)境、缺陷的處理過(guò)程和狀態(tài)、反應(yīng)了測(cè)試的相關(guān)過(guò)程和狀況。12、報(bào)告缺陷的基本原則：（1）盡快報(bào)告軟件缺陷（缺陷發(fā)現(xiàn)越晚修復(fù)缺陷的成本就越高，是非線性的關(guān)系）（2）有效的描述軟件缺陷（描述要短小精悍、單一、使用業(yè)界表達(dá)術(shù)語(yǔ)和表達(dá)方式、明確指出錯(cuò)誤類型）好的缺陷描述能夠幫助開發(fā)人員重現(xiàn)bug（3）在報(bào)告軟件缺陷時(shí)不做任何評(píng)價(jià)（4）確保缺陷可以重現(xiàn)（寫清楚重現(xiàn)步驟或者附加bug出現(xiàn)的圖片）13、寫好缺陷報(bào)告的5C原則：描述準(zhǔn)確、語(yǔ)言簡(jiǎn)潔、表述清晰、內(nèi)容完整、格式一致14、缺陷報(bào)告的主要內(nèi)容：（1）問題報(bào)告的名稱；（2）缺陷嚴(yán)重程度；（3）缺陷的緊急程度；（4）缺陷的提交人；（5）缺陷的提交時(shí)間；（6）缺陷所屬項(xiàng)目或模塊；（7）缺陷指定解決人；（8）缺陷指定的解決時(shí)間；(9)缺陷處理人；（10）缺陷處理結(jié)果描述；（11）缺陷處理時(shí)間；（12）缺陷驗(yàn)證人；（13）缺陷驗(yàn)證結(jié)果描述；（14）缺陷驗(yàn)證時(shí)間。（其中標(biāo)題、bugid、嚴(yán)重程度、重現(xiàn)步驟、測(cè)試結(jié)果、附加信息）軟件測(cè)試過(guò)程及測(cè)試過(guò)程管理1、軟件測(cè)試是一個(gè)過(guò)程，或者需要將過(guò)程抽象成模型，該過(guò)程定義了軟件測(cè)試的流程和方法，由一組有序的測(cè)試活動(dòng)組成。2、常用的軟件測(cè)試模型V模型：由開發(fā)模型瀑布模型變種而來(lái)，它明確了測(cè)試過(guò)程中存在不同類型、不同級(jí)別的測(cè)試，同時(shí)描述了這些測(cè)試與開發(fā)過(guò)程各個(gè)階段的對(duì)應(yīng)關(guān)系。V模型的局限性是測(cè)試進(jìn)行的較晚，在編碼之后進(jìn)行，容易使人理解為軟件開發(fā)的最后一個(gè)階段，且主要是針對(duì)程序找缺陷，使得對(duì)需求分析階段、設(shè)計(jì)階段等隱藏的問題一直到后期的驗(yàn)收測(cè)試才發(fā)現(xiàn)。W模型特點(diǎn)：（1）盡早地和不斷地進(jìn)行軟件測(cè)試的原則（2）增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)（3）W模型是雙V，開發(fā)是V，測(cè)試也是與此并行的V。V模型和W模型局限性：整個(gè)活動(dòng)是串行過(guò)程，無(wú)法適應(yīng)需求變更等調(diào)整、無(wú)法有效支持迭代、無(wú)法體現(xiàn)完整測(cè)試過(guò)程。H模型，它將測(cè)試獨(dú)立出來(lái)，當(dāng)某個(gè)測(cè)試時(shí)間點(diǎn)準(zhǔn)備完畢后，就可以進(jìn)入測(cè)試階段，適合第三方做測(cè)試。H模型也體現(xiàn)了分層概念，不同層次的測(cè)試按照某個(gè)次序先后進(jìn)行，也可以重復(fù)進(jìn)行。運(yùn)用場(chǎng)景：V模型：需求明確，階段明確，W模型：盡早測(cè)試，需求不足時(shí)可以先設(shè)計(jì)原型系統(tǒng)，通過(guò)不斷與客戶溝通完善需求和系統(tǒng)改進(jìn)。測(cè)試過(guò)程中的活動(dòng)及內(nèi)容階段對(duì)應(yīng)階段測(cè)試活動(dòng)對(duì)應(yīng)階段的產(chǎn)物需求驗(yàn)證和確認(rèn)需求說(shuō)明書并制定測(cè)試計(jì)劃測(cè)試需求、組織團(tuán)隊(duì)、測(cè)試計(jì)劃設(shè)計(jì)驗(yàn)證和確認(rèn)設(shè)計(jì)文檔、模型等，測(cè)試設(shè)計(jì)及評(píng)審測(cè)試計(jì)劃完善、方案、測(cè)試用例等編碼代碼、評(píng)審、搭建環(huán)境、單元測(cè)試測(cè)試用例及缺陷等測(cè)試執(zhí)行測(cè)試、缺陷管理缺陷報(bào)告和測(cè)試報(bào)告安裝安裝測(cè)試、確認(rèn)產(chǎn)品安裝程序、安裝文檔、用戶手冊(cè)等維護(hù)培訓(xùn)、維護(hù)、變更管理、測(cè)試維護(hù)手冊(cè)、測(cè)試報(bào)告等軟件測(cè)試過(guò)程中關(guān)鍵活動(dòng)提取測(cè)試需求、制定測(cè)試計(jì)劃、制定測(cè)試策略和方法、開展測(cè)試設(shè)計(jì)、執(zhí)行測(cè)試用例、分析測(cè)試結(jié)果CMMI軟件成熟度模型，共五個(gè)級(jí)別：初始級(jí)、可重復(fù)級(jí)、定義級(jí)、管理級(jí)、優(yōu)化級(jí)。CMMI提供用于過(guò)程改進(jìn)的框架。測(cè)試過(guò)程主要工作內(nèi)容項(xiàng)目啟動(dòng)—確定項(xiàng)目組長(zhǎng)，進(jìn)行項(xiàng)目的前期準(zhǔn)備。測(cè)試需求分析—以軟件開發(fā)需求為基礎(chǔ)，形成可測(cè)試的內(nèi)容。制定測(cè)試計(jì)劃—確定測(cè)試范圍、測(cè)試策略和方法，以及對(duì)風(fēng)險(xiǎn)、日程表、資源等進(jìn)行分析和評(píng)估。測(cè)試設(shè)計(jì)和開發(fā)—制定測(cè)試的技術(shù)方案、設(shè)計(jì)測(cè)試用例、選擇測(cè)試工具、寫測(cè)試腳本等，并且進(jìn)行評(píng)審。測(cè)試實(shí)施和執(zhí)行—建立或設(shè)置相關(guān)的測(cè)試環(huán)境，準(zhǔn)備測(cè)試數(shù)據(jù)，執(zhí)行測(cè)試用例，并提交發(fā)現(xiàn)的缺陷。測(cè)試結(jié)果的審查和分析—分析測(cè)試結(jié)果，確定產(chǎn)品質(zhì)量，提供發(fā)布依據(jù)。軟件測(cè)試計(jì)劃是指導(dǎo)測(cè)試過(guò)程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測(cè)試策略測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。測(cè)試計(jì)劃編寫內(nèi)容：測(cè)試目的、測(cè)試環(huán)境（軟硬件）、測(cè)試策略、測(cè)試階段劃分、功能描述及功能覆蓋說(shuō)明、測(cè)試用例清單（測(cè)試計(jì)劃與測(cè)試用例及需求有關(guān)聯(lián)）、準(zhǔn)入準(zhǔn)出條件、風(fēng)險(xiǎn)等。測(cè)試需求的收集（來(lái)源）：被測(cè)系統(tǒng)相關(guān)資料文檔、客戶與需求分析員的溝通、相關(guān)背景、正式與非正式培訓(xùn)、其他等。測(cè)試策略：測(cè)試策略描述當(dāng)前測(cè)試的目標(biāo)和所采用的測(cè)試方法，包括測(cè)試方式（手動(dòng)/自動(dòng)）、測(cè)試工具、測(cè)試量、測(cè)試策略還要描述測(cè)試不同階段（單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試）的測(cè)試對(duì)象、范圍和方法以及每個(gè)階段內(nèi)所要進(jìn)行的測(cè)試類型（功能測(cè)試、性能測(cè)試、壓力測(cè)試等）測(cè)試文檔：需求說(shuō)明書、測(cè)試計(jì)劃文檔、測(cè)試用例文檔、缺陷報(bào)告等軟件靜態(tài)測(cè)試1、靜態(tài)測(cè)試概念：不執(zhí)行程序代碼而尋找代碼中可能存在的錯(cuò)誤或評(píng)估程序代碼的過(guò)程。2、靜態(tài)測(cè)試對(duì)象：項(xiàng)目開發(fā)過(guò)程中產(chǎn)生的相關(guān)產(chǎn)物，例如文檔、源程序等。3、靜態(tài)測(cè)試特點(diǎn)：不用運(yùn)行程序、可以人工進(jìn)行、不需要特別的條件，容易開展、測(cè)試人員要求高4、靜態(tài)測(cè)試主要包括：各階段的評(píng)審、代碼檢查、程序分析、軟件復(fù)雜性分析、軟件質(zhì)量度量等。7.1各階段評(píng)審5、一般評(píng)審主要包括：培訓(xùn)評(píng)審、預(yù)備評(píng)審、同行評(píng)審（需求階段的規(guī)格說(shuō)明書是評(píng)審的重要內(nèi)容）6、同行評(píng)審：由開發(fā)軟件產(chǎn)品作者以外的其他人檢查工作產(chǎn)品，以發(fā)現(xiàn)缺陷并尋找改進(jìn)的機(jī)會(huì)。7、同行評(píng)審類型包括：審查、小組評(píng)審、走查、桌面評(píng)審、臨時(shí)評(píng)審，正式程度由強(qiáng)到弱，審查最正式，但也是花費(fèi)較高的，通常被評(píng)審對(duì)象較重要或風(fēng)險(xiǎn)較高采用的評(píng)審類型越正式。8、審查比較正式，因此有一系列流程，包括計(jì)劃、總體會(huì)議、準(zhǔn)備、會(huì)議、返工、跟蹤、因果分析。9、規(guī)格說(shuō)明書的詳細(xì)評(píng)審：完整性；精確性；準(zhǔn)確性；一致性；相關(guān)性；可行性；代碼無(wú)關(guān)性和可測(cè)試性7.2代碼檢查10、代碼檢查：以組為單位閱讀代碼，是一系列規(guī)程和錯(cuò)誤檢查技術(shù)的集合。代碼檢查屬于靜態(tài)白盒測(cè)試。主要檢查代碼和設(shè)計(jì)的一致性、代碼對(duì)標(biāo)準(zhǔn)的遵循、代碼的可讀性、代碼的邏輯表達(dá)正確性、代碼結(jié)構(gòu)的合理性。11、代碼檢查的內(nèi)容：完整性檢查；一致性檢查；正確性檢查；可修改性檢查、可預(yù)測(cè)性檢查、健壯性檢查；可理解性檢查；可驗(yàn)證性檢查；結(jié)構(gòu)性檢查；可追溯性檢查；代碼標(biāo)準(zhǔn)符合性檢查。12、代碼檢查方式：技術(shù)評(píng)審、代碼審查、代碼走查、桌面檢查。13、代碼審查的內(nèi)容：代碼和設(shè)計(jì)的一致性；代碼執(zhí)行標(biāo)準(zhǔn)的情況；代碼的邏輯表達(dá)正確性；代碼結(jié)構(gòu)的合理性；代碼的可讀性。（步驟：準(zhǔn)備、程序閱讀、審查會(huì)、編寫報(bào)告）11、代碼審查和代碼走查都是由若干程序員和測(cè)試員組成小組進(jìn)行，審查更為正式，走查非正式，大多數(shù)項(xiàng)目團(tuán)隊(duì)以審查為主。12、技術(shù)評(píng)審是最正式的代碼檢查類型，有高度的組織化，要求每個(gè)參與者都具有較好的經(jīng)驗(yàn)。13、代碼走查主要有文檔和源程序代碼、檢查功能、檢查界面、檢查流程、檢查提示信息、函數(shù)檢查、數(shù)據(jù)類型和變量檢查、條件判斷檢查、循環(huán)檢查、輸入輸出檢查、注釋檢查、程序（模塊）檢查、數(shù)據(jù)庫(kù)檢查、表達(dá)式檢查、接口分析、函數(shù)調(diào)用關(guān)系圖及模塊控制流程圖等17項(xiàng)檢查14、代碼安全性就是你的代碼在運(yùn)行時(shí)，或被別人調(diào)用時(shí)產(chǎn)生錯(cuò)誤的容易程度。15、代碼安全性檢查或靜態(tài)錯(cuò)誤分析主要用于確定在源程序是否有某類錯(cuò)誤或“危險(xiǎn)/不安全”的結(jié)構(gòu)。一般可借助工具對(duì)代碼進(jìn)行安全性檢查。7.3軟件復(fù)雜性分析16、軟件危機(jī)產(chǎn)生的最直接原因：軟件復(fù)雜性已遠(yuǎn)遠(yuǎn)超出人們對(duì)復(fù)雜性控制的能力。17、對(duì)軟件復(fù)雜性的度量主要有兩種：面向過(guò)程度量和面向?qū)ο蠖攘俊?8、軟件復(fù)雜性由模塊復(fù)雜性和總體復(fù)雜性組成，其中模塊復(fù)雜性又分為模塊內(nèi)部結(jié)構(gòu)復(fù)雜性和模塊接口復(fù)雜性。19、模塊接口復(fù)雜性主要體現(xiàn)在模塊之間的調(diào)用關(guān)系上。22、軟件復(fù)雜性的控制主要包括模塊復(fù)雜性、模塊結(jié)構(gòu)復(fù)雜性和總體復(fù)雜性。23、軟件模塊復(fù)雜性的控制主要從模塊的大小和功能來(lái)進(jìn)行。聚性對(duì)模塊獨(dú)立性進(jìn)行控制，追求高內(nèi)聚低耦合）、扇入扇出、模塊接口來(lái)進(jìn)行。掌握Halstead復(fù)雜度計(jì)算和McCabe圈復(fù)雜度計(jì)算的思想，在實(shí)際工作中復(fù)雜的程序計(jì)算通常由測(cè)試工具來(lái)完成。面向?qū)ο蠖攘康奶匦裕壕钟蛐?；封裝性；信息隱藏；繼承性；抽象。7.4軟件質(zhì)量模型軟件質(zhì)量理解為：是許多質(zhì)量屬性的綜合體現(xiàn)，各種質(zhì)量屬性反映了軟件質(zhì)量的方方面面。ISO/IEC9126規(guī)定，軟件質(zhì)量可以從以下6種特性來(lái)評(píng)價(jià)：功能性、可靠性、可用性、效率、維護(hù)性、可移植性。軟件質(zhì)量可用特定的軟件質(zhì)量特性來(lái)表示，而軟件質(zhì)量特性反映了軟件的本質(zhì)，通常用軟件質(zhì)量模型來(lái)描述影響軟件質(zhì)量的特性。軟件質(zhì)量度量是從整體上對(duì)軟件質(zhì)量進(jìn)行測(cè)評(píng)在軟件開發(fā)中，軟件度量的根本目的是管理的需要。為什么需要度量？驗(yàn)證策略是否正確提供客觀證據(jù)，證明我們需要做什么什么是需要做的，即提供目標(biāo)和指導(dǎo)如果偏離目標(biāo)需要干預(yù)并改進(jìn)軟件動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試概念：執(zhí)行程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異。8.1白盒測(cè)試1、白盒測(cè)試主要是從程序內(nèi)部邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)設(shè)計(jì)測(cè)試數(shù)據(jù)并完成測(cè)試的測(cè)試方法，白盒測(cè)試把程序看做一個(gè)透明盒子，而黑盒測(cè)試就是把程序看做黑色的盒子，不考慮程序內(nèi)容結(jié)構(gòu)。2、調(diào)試和白盒測(cè)試區(qū)別：調(diào)試強(qiáng)調(diào)發(fā)現(xiàn)問題并修正，通常由程序員完成；白盒測(cè)試強(qiáng)調(diào)發(fā)現(xiàn)缺陷，通常由開發(fā)該代碼的程序員或測(cè)試人員完成。3、邏輯覆蓋包括：語(yǔ)句覆蓋：強(qiáng)調(diào)程序中所有語(yǔ)句被執(zhí)行過(guò)，設(shè)計(jì)的測(cè)試用例只要遍歷所有語(yǔ)句即可。判定（分支）覆蓋：強(qiáng)調(diào)程序中所有判定分支被執(zhí)行過(guò)，設(shè)計(jì)的測(cè)試用例只要遍歷所有分支即可。條件覆蓋：強(qiáng)調(diào)程序中所有判定條件真假值被執(zhí)行過(guò)，設(shè)計(jì)的測(cè)試用例只要遍歷所有判定條件即可。判定/條件覆蓋：上述兩種覆蓋的組合，即要所有判定分支被執(zhí)行過(guò)，所有判定條件也要執(zhí)行。條件組合覆蓋：強(qiáng)調(diào)程序中判定條件以組合的形式被執(zhí)行過(guò)，設(shè)計(jì)的測(cè)試用例只要遍歷所有條件組合即可。路徑覆蓋：強(qiáng)調(diào)從程序所有可能路徑出發(fā)，設(shè)計(jì)滿足遍歷所有路徑的測(cè)試用例。4、基本路徑測(cè)試步驟：將程序代碼結(jié)構(gòu)轉(zhuǎn)換成程序控制流圖計(jì)算程序控制流圖的圈復(fù)雜度（設(shè)計(jì)測(cè)試用例的最少數(shù)量）列出測(cè)試路徑針對(duì)測(cè)試路徑設(shè)計(jì)測(cè)試用例圈復(fù)雜度的計(jì)算方法：（1）V(G)=m(弧數(shù))-n（節(jié)點(diǎn)數(shù)）+p（分離的數(shù)目）判定節(jié)點(diǎn)+1強(qiáng)連通程序圖在平面上圍成的區(qū)域個(gè)數(shù)。8.2黑盒測(cè)試黑盒測(cè)試通常又稱為功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，把測(cè)試對(duì)象當(dāng)作看不見內(nèi)容的黑盒，在不考慮內(nèi)部結(jié)構(gòu)和處理過(guò)程的情況下，測(cè)試人員根據(jù)程序功能需求規(guī)范考慮確定測(cè)試用例和推斷測(cè)試結(jié)果的正確性。黑盒測(cè)試可以導(dǎo)出執(zhí)行程序所有的功能需求的輸入條件集，實(shí)現(xiàn)功能覆蓋。功能覆蓋中最常見的是需求覆蓋。2、黑盒測(cè)試的目的是為了進(jìn)行功能測(cè)試，然后找出功能點(diǎn)，然后再設(shè)計(jì)測(cè)試用例。3、黑盒測(cè)試方法主要有等價(jià)類劃分、邊界值分析、因果圖、猜測(cè)法、隨機(jī)測(cè)試。4、等價(jià)類劃分，其中等價(jià)類，把所有可能的輸入數(shù)據(jù),即程序的輸入域劃分成若干部分；劃分，從每一部分中選取少數(shù)有代表性的數(shù)據(jù)做為測(cè)試用例，代表性數(shù)據(jù)等同于該類中的其他值。5、邊界值分析法就是對(duì)輸入或輸出的邊界值進(jìn)行測(cè)試的一種黑盒測(cè)試方法,稍高于其邊界值及稍低于其邊界值的一些特定情況，選取正好等于，剛剛大于，或剛剛小于邊界的值做為測(cè)試數(shù)據(jù)的方法。例如，5<x<10一個(gè)范圍，設(shè)計(jì)用例取4.9、5、5.1、7、9.9、10、10.16、邊界值分析是等價(jià)類劃分方法的補(bǔ)充，所有測(cè)試階段都可使用7、因果圖是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測(cè)試用例的方法，該方法充分考慮了輸入情況的各種組合及輸入條件之間的相互制約關(guān)系。因果圖產(chǎn)生是因?yàn)榈葍r(jià)類法、邊界值法分析著重考慮輸入條件，未考慮輸入條件之間的關(guān)系。8、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試都采用黑盒測(cè)試。8.3灰盒測(cè)試1、灰盒測(cè)試是一種綜合性測(cè)試，結(jié)合了白盒測(cè)試與黑盒測(cè)試，既要能了解代碼（可以沒有開發(fā)經(jīng)驗(yàn)），也要掌握黑盒測(cè)試常用方法。2、灰盒測(cè)試的思想：基于程序運(yùn)行時(shí)的外部表現(xiàn)同時(shí)又結(jié)合程序內(nèi)部邏輯結(jié)構(gòu)來(lái)設(shè)計(jì)用例，執(zhí)行程序并采集程序路徑執(zhí)行信息和外部用戶接口結(jié)果的測(cè)試技術(shù)，其目的是驗(yàn)證軟件滿足外部指標(biāo)以及軟件的所有通道或路徑都進(jìn)行了檢驗(yàn)。因此，在測(cè)試階段中灰盒測(cè)試主要用在集成測(cè)試階段。8.4測(cè)試用例設(shè)計(jì)一個(gè)好的測(cè)試用例是指可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。高質(zhì)量測(cè)試用例的特點(diǎn)：正確性（要符合需求規(guī)格說(shuō)明書要求）、完整性（不僅僅體現(xiàn)在功能測(cè)試的完整性上，還應(yīng)涉及性能測(cè)試、安全測(cè)試等）、準(zhǔn)確（開發(fā)人員執(zhí)行測(cè)試步驟應(yīng)能正確得到描述缺陷）、清晰簡(jiǎn)潔（測(cè)試用例描述要少而精，避免口語(yǔ)化）、可維護(hù)性（測(cè)試用例可以修改、刪除）、適應(yīng)性（符合特定測(cè)試環(huán)境或符合測(cè)試團(tuán)隊(duì)測(cè)試情況）、可重用性（類似測(cè)試可以修改測(cè)試用例后直接使用）、其他。測(cè)試用例的覆蓋內(nèi)容：正確性測(cè)試、容錯(cuò)性（健壯性）測(cè)試、完整（安全）性測(cè)試、接口測(cè)試、數(shù)據(jù)庫(kù)測(cè)試、邊界值測(cè)試、壓力測(cè)試、等價(jià)劃分測(cè)試、錯(cuò)誤推測(cè)、效率、可理解（操作）性測(cè)試、可移植性測(cè)試、回歸測(cè)試、比較測(cè)試。針對(duì)不同的測(cè)試類型和測(cè)試階段，測(cè)試用例編寫的側(cè)重點(diǎn)不同，并非以上內(nèi)容都要覆蓋。測(cè)試用例主要元素：測(cè)試環(huán)境、測(cè)試數(shù)據(jù)、測(cè)試步驟、測(cè)試結(jié)果。測(cè)試用例編寫要素：標(biāo)識(shí)ID、標(biāo)題、描述、環(huán)境、步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、備注。測(cè)試用例的注意事項(xiàng)功能檢查面向用戶考慮數(shù)據(jù)處理軟件流程測(cè)試測(cè)試用例的設(shè)計(jì)步驟測(cè)試需求分析：分析需求文檔，明確測(cè)試對(duì)象業(yè)務(wù)流程分析：不僅僅要明確功能測(cè)試，還需要對(duì)整個(gè)業(yè)務(wù)邏輯和處理流程有清晰的認(rèn)識(shí)測(cè)試用例設(shè)計(jì)測(cè)試用例評(píng)審：有利于查出測(cè)試用例存在的缺陷和漏洞，增強(qiáng)測(cè)試用例的正確性測(cè)試用例更新完善測(cè)試用例分級(jí)：重要性和優(yōu)先級(jí)（高、中、低）測(cè)試用例的誤區(qū)。8.5單元測(cè)試1、單元測(cè)試又稱模塊測(cè)試是開發(fā)者編寫的一段測(cè)試代碼，用來(lái)檢測(cè)被測(cè)代碼的一個(gè)很小的、很明確的功能是否正確。2、單元測(cè)試由于涉及代碼和程序內(nèi)部邏輯結(jié)構(gòu)，主要以白盒測(cè)試為主，黑盒測(cè)試為輔。3、單元測(cè)試主要5方面內(nèi)容：模塊接口測(cè)試、局部數(shù)據(jù)結(jié)構(gòu)測(cè)試、路徑測(cè)試、錯(cuò)誤處理測(cè)試、邊界測(cè)試4、單元測(cè)試是在編碼、編譯、靜態(tài)分析和代碼審查后進(jìn)行的。5、在項(xiàng)目開發(fā)中，通常情況下一些模塊會(huì)先被開發(fā)完畢，但跟這些模塊存在關(guān)聯(lián)的其他模塊還沒有開發(fā)完畢，這時(shí)對(duì)其進(jìn)行測(cè)試就需要我們自己編寫驅(qū)動(dòng)模塊和樁模塊來(lái)代替未開發(fā)完的模塊。6、驅(qū)動(dòng)模塊相當(dāng)于所測(cè)模塊的主程序，例如c語(yǔ)言中的main函數(shù)，我們傳入用例參數(shù)通過(guò)驅(qū)動(dòng)模塊來(lái)調(diào)用需要測(cè)試的模塊。7、樁模塊相當(dāng)于未開發(fā)出的模塊，屬于被測(cè)模塊的下級(jí)模塊，代替由被測(cè)模塊所調(diào)用的模塊的功能。8、由驅(qū)動(dòng)模塊、被測(cè)模塊和樁模塊就構(gòu)成了一個(gè)完成的環(huán)境。驅(qū)動(dòng)模塊用于模擬被測(cè)模塊的上層模塊，測(cè)試執(zhí)行時(shí)由驅(qū)動(dòng)模塊調(diào)用，樁模塊模擬被測(cè)模塊執(zhí)行過(guò)程中所調(diào)用的模塊，測(cè)試執(zhí)行時(shí)，樁模塊使被測(cè)模塊能完整閉合地運(yùn)行。9、單元測(cè)試中的驅(qū)動(dòng)模塊和樁模塊不屬于要交付的產(chǎn)品，因此在開發(fā)結(jié)束后就不使用了，所以在設(shè)計(jì)時(shí)要盡量簡(jiǎn)單。10、單元測(cè)試步驟：構(gòu)造測(cè)試用例環(huán)境（準(zhǔn)備好驅(qū)動(dòng)模塊和樁模塊）、設(shè)計(jì)黑盒測(cè)試用例（主要驗(yàn)證該模塊實(shí)現(xiàn)的功能）、設(shè)計(jì)白盒測(cè)試用例（找出單元內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)使用可能存在的問題）。8.6集成測(cè)試集成測(cè)試又稱組裝測(cè)試或聯(lián)合測(cè)試，是單元