是軟件測(cè)試方法(軟件測(cè)試的方法一共有幾種)
1.軟件測(cè)試的方法一共有幾種
1、從是否關(guān)心內(nèi)部結(jié)構(gòu)來(lái)看 （1）白盒測(cè)試：又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，是一種按照程序內(nèi)部邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)，設(shè)計(jì)測(cè)試數(shù)據(jù)并完成測(cè)試的一種測(cè)試方法。
（2）黑盒測(cè)試：又稱為數(shù)據(jù)驅(qū)動(dòng)測(cè)試，把測(cè)試對(duì)象當(dāng)做看不見(jiàn)的黑盒，在完全不考慮程序內(nèi)部結(jié)構(gòu)和處理過(guò)程的情況下，測(cè)試者僅依據(jù)程序功能的需求規(guī)范考慮，確定測(cè)試用例和推斷測(cè)試結(jié)果的正確性，它是站在使用軟件或程序的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系出發(fā)進(jìn)行的測(cè)試。（3）灰盒測(cè)試：是一種綜合測(cè)試法，它將“黑盒”測(cè)試與“白盒”測(cè)試結(jié)合在一起，是基于程序運(yùn)行時(shí)的外部表現(xiàn)又結(jié)合內(nèi)部邏輯結(jié)構(gòu)來(lái)設(shè)計(jì)用例，執(zhí)行程序并采集路徑執(zhí)行信息和外部用戶接口結(jié)果的測(cè)試技術(shù)。
2、從是否執(zhí)行代碼看 （1）靜態(tài)測(cè)試：指不運(yùn)行被測(cè)程序本身，僅通過(guò)分析或檢查源程序的語(yǔ)法、結(jié)構(gòu)、過(guò)程、接口等來(lái)檢查程序的正確性。（2）動(dòng)態(tài)測(cè)試：是指通過(guò)運(yùn)行被測(cè)程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率、正確性和健壯性等性能指標(biāo)。
3、從開(kāi)發(fā)過(guò)程級(jí)別看 （1）單元測(cè)試：又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位----程序模塊或功能模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于檢驗(yàn)程序各模塊是否存在各種差錯(cuò)，是否能正確地實(shí)現(xiàn)了其功能，滿足其性能和接口要求。
（2）集成測(cè)試：又叫組裝測(cè)試或聯(lián)合，是單元測(cè)試的多級(jí)擴(kuò)展，是在單元測(cè)試的基礎(chǔ)上進(jìn)行的一種有序測(cè)試。旨在檢驗(yàn)軟件單元之間的接口關(guān)系，以期望通過(guò)測(cè)試發(fā)現(xiàn)各軟件單元接口之間存在的問(wèn)題，最終把經(jīng)過(guò)測(cè)試的單元組成符合設(shè)計(jì)要求的軟件。
（3）系統(tǒng)測(cè)試：是為判斷系統(tǒng)是否符合要求而對(duì)集成的軟、硬件系統(tǒng)進(jìn)行的測(cè)試活動(dòng)、它是將已經(jīng)集成好的軟件系統(tǒng)，作為基于整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、人員、數(shù)據(jù)等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。在系統(tǒng)測(cè)試中，對(duì)于具體的測(cè)試類型有：（1）功能測(cè)試：對(duì)軟件需求規(guī)格說(shuō)明書中的功能需求逐項(xiàng)進(jìn)行的測(cè)試，以驗(yàn)證功能是否滿足要求。
（2）性能測(cè)試：對(duì)軟件需求規(guī)格說(shuō)明書的功能需求逐項(xiàng)進(jìn)行的測(cè)試，以驗(yàn)證功能是否滿足要求。（3）接口測(cè)試：對(duì)軟件需求規(guī)格說(shuō)明中的接口需求逐項(xiàng)進(jìn)行的測(cè)試。
（4）人機(jī)交互界面測(cè)試：對(duì)所有人機(jī)交互界面提供的操作和顯示界面進(jìn)行的測(cè)試，以檢驗(yàn)是否滿足用戶的需求。（5）強(qiáng)度測(cè)試：強(qiáng)制軟件運(yùn)行在異常乃至發(fā)生故障的情況下（設(shè)計(jì)的極限狀態(tài)到超出極限），驗(yàn)證軟件可以運(yùn)行到何種程序的測(cè)試。
（6）余量測(cè)試：對(duì)軟件是否達(dá)到規(guī)格說(shuō)明中要求的余量的測(cè)試。（7）安全性測(cè)試：檢驗(yàn)軟件中已存在的安全性、安全保密性措施是否有效的測(cè)試，（8）可靠性測(cè)試：在真實(shí)的或仿真的環(huán)境中，為做出軟件可靠性估計(jì)而對(duì)軟件進(jìn)行的功能（其輸入覆蓋和環(huán)境覆蓋一般大于普通的功能測(cè)試） （9）恢復(fù)性測(cè)試：對(duì)有恢復(fù)或重置功能的軟件的每一類導(dǎo)致恢復(fù)或重置的情況，逐一進(jìn)行的測(cè)試。
（10）邊界測(cè)試：對(duì)軟件處在邊界或端點(diǎn)情況下運(yùn)行狀態(tài)的測(cè)試。（11）數(shù)據(jù)處理測(cè)試：對(duì)完成專門數(shù)據(jù)處理功能所進(jìn)行的測(cè)試。
（12）安裝性測(cè)試：對(duì)安裝過(guò)程是否符合安裝規(guī)程的測(cè)試，以發(fā)現(xiàn)安裝過(guò)程中的錯(cuò)誤。（13）容量測(cè)試：檢驗(yàn)軟件的能力最高能達(dá)到什么程度的測(cè)試。
（14）互操作性測(cè)試：為驗(yàn)證不同軟件之間的互操作能力而進(jìn)行的測(cè)試。（15）敏感性測(cè)試：為發(fā)現(xiàn)在有效輸入類中可能引起某種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)的組合而進(jìn)行的測(cè)試。
（16）標(biāo)準(zhǔn)符合性測(cè)試：驗(yàn)證軟件與相關(guān)國(guó)家標(biāo)準(zhǔn)或規(guī)范（如軍用標(biāo)準(zhǔn)、國(guó)家標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)及國(guó)際標(biāo)準(zhǔn)）一致性的測(cè)試。（17）兼容性測(cè)試：驗(yàn)證軟件在規(guī)定條件下與若干個(gè)實(shí)體共同使用或?qū)崿F(xiàn)數(shù)據(jù)格式轉(zhuǎn)換時(shí)能滿足有關(guān)要求能力的測(cè)試。
（18）中文本地化測(cè)試：驗(yàn)證軟件在不降低原有能力的條件下，處理中文能力的測(cè)試。4、從執(zhí)行過(guò)程是否需要人工干預(yù)來(lái)看 （1）手工測(cè)試：就是測(cè)試人員按照事先為覆蓋被測(cè)軟件需求而編寫的測(cè)試用例，根據(jù)測(cè)試大綱中所描述的測(cè)試步驟和方法，手工地一個(gè)一個(gè)地輸 入執(zhí)行，包括與被測(cè)軟件進(jìn)行交互（如輸入測(cè)試數(shù)據(jù)、記錄測(cè)試結(jié)果等），然后觀察測(cè)試結(jié)果，看被測(cè)程序是否存在問(wèn)題，或在執(zhí)行過(guò)程中是否會(huì)有一場(chǎng)發(fā)生，屬于比較原始但是必須執(zhí)行的一個(gè)步驟。
（2）自動(dòng)化測(cè)試：實(shí)際上是將大量的重復(fù)性的測(cè)試工作交給計(jì)算機(jī)去完成，通常是使用自動(dòng)化測(cè)試工具來(lái)模擬手動(dòng)測(cè)試步驟，執(zhí)行用某種程序設(shè)計(jì)語(yǔ)言編寫的過(guò)程（全自動(dòng)測(cè)試就是指在自動(dòng)測(cè)試過(guò)程中，不需要人工干預(yù)，由程序自動(dòng)完成測(cè)試的全過(guò)程；半自動(dòng)測(cè)試就是指在自動(dòng)測(cè)試過(guò)程中，需要手動(dòng)輸入測(cè)試用例或選擇測(cè)試路徑，再由自動(dòng)測(cè)試程序按照人工指定的要求完成自動(dòng)測(cè)試）5、從測(cè)試實(shí)施組織看 （1）開(kāi)發(fā)測(cè)試：開(kāi)發(fā)人員進(jìn)行的測(cè)試 （2）用戶測(cè)試：用戶方進(jìn)行的測(cè)試 （3）第三方測(cè)試：有別于開(kāi)發(fā)人員或用戶進(jìn)行的測(cè)試，由專業(yè)的第三方承擔(dān)的測(cè)試，目的是為了保證測(cè)試工作的客觀性6、從測(cè)試所處的環(huán)境看 （1）阿爾法測(cè)試：是由一個(gè)用戶在開(kāi)發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測(cè)試 （2）。
2.軟件測(cè)試方法有哪些
1、按是否查看程序內(nèi)部結(jié)構(gòu)分為：
(1)黑盒測(cè)試（black-box testing）：只關(guān)心輸入和輸出的結(jié)果
(2)白盒測(cè)試（white-box testing）：去研究里面的源代碼和程序結(jié)構(gòu)
2、按是否運(yùn)行程序分為：
(1)靜態(tài)測(cè)試（static testing）：是指不實(shí)際運(yùn)行被測(cè)軟件，而只是靜態(tài)地檢查程序代碼、界面或文檔可能存在的錯(cuò)誤的過(guò)程。
靜態(tài)測(cè)試包括：
對(duì)于代碼測(cè)試，主要是測(cè)試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。
對(duì)于界面測(cè)試，主要測(cè)試軟件的實(shí)際界面與需求中的說(shuō)明是否相符。
對(duì)于文檔測(cè)試，主要測(cè)試用戶手冊(cè)和需求說(shuō)明是否真正符合用戶的實(shí)際需求。
(5)動(dòng)態(tài)測(cè)試（dynamic testing），是指實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試數(shù)據(jù)，檢查輸出結(jié)果和預(yù)期結(jié)果是否相符的過(guò)程
3、按階段劃分：
(1)單元測(cè)試（unit testing），是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。
樁模塊（stud）是指模擬被測(cè)模塊所調(diào)用的模塊，驅(qū)動(dòng)模塊（driver）是指模擬被測(cè)模塊的上級(jí)模塊，驅(qū)動(dòng)模塊用來(lái)接收測(cè)試數(shù)據(jù)，啟動(dòng)被測(cè)模塊并輸出結(jié)果。
(2)集成測(cè)試（integration testing），是單元測(cè)試的下一階段，是指將通過(guò)測(cè)試的單元模塊組裝成系統(tǒng)或子系統(tǒng)，再進(jìn)行測(cè)試，重點(diǎn)測(cè)試不同模塊的接口部門。
集成測(cè)試就是用來(lái)檢查各個(gè)單元模塊結(jié)合到一起能否協(xié)同配合，正常運(yùn)行。
(3)系統(tǒng)測(cè)試（system testing），指的是將整個(gè)軟件系統(tǒng)看做一個(gè)整體進(jìn)行測(cè)試，包括對(duì)功能、性能，以及軟件所運(yùn)行的軟硬件環(huán)境進(jìn)行測(cè)試。
系統(tǒng)測(cè)試的主要依據(jù)是《系統(tǒng)需求規(guī)格說(shuō)明書》文檔。
(4)驗(yàn)收測(cè)試（acceptance testing），指的是在系統(tǒng)測(cè)試的后期，以用戶測(cè)試為主，或有測(cè)試人員等質(zhì)量保障人員共同參與的測(cè)試，它也是軟件正式交給用戶使用的最后一道工序。
驗(yàn)收測(cè)試又分為a測(cè)試和beta測(cè)試，其中a測(cè)試指的是由用戶、測(cè)試人員、開(kāi)發(fā)人員等共同參與的內(nèi)部測(cè)試，而beta測(cè)試指的是內(nèi)測(cè)后的公測(cè)，即完全交給最終用戶測(cè)試。
4、黑盒測(cè)試分為功能測(cè)試和性能測(cè)試：
1）功能測(cè)試（function testing），是黑盒測(cè)試的一方面，它檢查實(shí)際軟件的功能是否符合用戶的需求。
包括邏輯功能測(cè)試（logic function testing）
界面測(cè)試（UI testing）UI=User Interface
易用性測(cè)試（usability testing）：是指從軟件使用的合理性和方便性等角度對(duì)軟件系統(tǒng)進(jìn)行檢查，來(lái)發(fā)現(xiàn)軟件中不方便用戶使用的地方。
兼容性測(cè)試（compatibility testing）：包括硬件兼容性測(cè)試和軟件兼容性測(cè)試
2）性能測(cè)試（performance testing）
軟件的性能主要有時(shí)間性能和空間性能兩種
時(shí)間性能：主要指軟件的一個(gè)具體事務(wù)的響應(yīng)時(shí)間（respond time）。
空間性能：主要指軟件運(yùn)行時(shí)所消耗的系統(tǒng)資源。
軟件性能測(cè)試分為：
一般性能測(cè)試：指的是讓被測(cè)系統(tǒng)在正常的軟硬件環(huán)境下運(yùn)行，不向其施加任何壓力的性能測(cè)試。
穩(wěn)定性測(cè)試也叫可靠性測(cè)試（reliability testing）：是指連續(xù)運(yùn)行被測(cè)系統(tǒng)檢查系統(tǒng)運(yùn)行時(shí)的穩(wěn)定程度。
負(fù)載測(cè)試（load testing）：是指讓被測(cè)系統(tǒng)在其能忍受的壓力的極限范圍之內(nèi)連續(xù)運(yùn)行，來(lái)測(cè)試系統(tǒng)的穩(wěn)定性。
壓力測(cè)試（stress testing）：是指持續(xù)不斷的給被測(cè)系統(tǒng)增加壓力，直到將被測(cè)系統(tǒng)壓垮為止，用來(lái)測(cè)試系統(tǒng)所能承受的最大壓力。（Validate the system or software can allowed the biggest stress.）
3.軟件測(cè)試方法的分類有哪些
1）按照測(cè)試技術(shù)劃分
黑盒測(cè)試：功能測(cè)試，必須
白盒測(cè)試：邏輯結(jié)構(gòu)測(cè)試，代碼的邏輯、算法、結(jié)構(gòu)是否正確，要求必須懂得代碼，需要編寫測(cè)試用例，可選
灰盒測(cè)試：介于中間
注意：在單元測(cè)試時(shí)，白盒應(yīng)用相對(duì)較多，在集成測(cè)試時(shí)，灰盒測(cè)試應(yīng)用相對(duì)較多，在系統(tǒng)、驗(yàn)收測(cè)試時(shí)一般就不會(huì)使用白盒測(cè)試和灰盒測(cè)試了。
2）按是否需要運(yùn)行代碼劃分
靜態(tài)測(cè)試：界面測(cè)試，文檔測(cè)試，代碼測(cè)試【重點(diǎn)關(guān)注代碼的規(guī)范性，一般檢查變量的命名，注釋的頻率，編程的規(guī)范性，不需要寫測(cè)試用例，一般只需要有代碼審查單】
注意：一般經(jīng)常把白盒測(cè)試和靜態(tài)測(cè)試的要素結(jié)合在一起，形成靜態(tài)白盒測(cè)試
動(dòng)態(tài)測(cè)試：運(yùn)行程序進(jìn)行檢查，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符
3）按軟件特性分類
功能測(cè)試
性能測(cè)試
4.軟件測(cè)試方法
第一類測(cè)試方法是試圖驗(yàn)證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計(jì)執(zhí)行的；而第二類測(cè)試方法則是設(shè)法證明軟件是“不工作的”。
還有兩大類：白盒法和黑盒法。
白盒法：你清楚程序的流程時(shí)，用不同的數(shù)據(jù)測(cè)試你程序的代碼，驗(yàn)證程序的正確性，有：條件測(cè)試，路徑測(cè)試，條件組合。。。。
白盒法用在程序開(kāi)發(fā)階段的前期。
黑盒法：主要用于程序開(kāi)發(fā)階段的后期，即程序的流程測(cè)試正確后，測(cè)試程序的結(jié)果。有什么因果法，邊緣值法等。
具體你可以買本軟件工程方面的書看看。
還有一下方法：
功能測(cè)試：可接受性測(cè)試：用戶界面測(cè)試：探索或開(kāi)放'型的測(cè)試：性能測(cè)試：回歸測(cè)試：強(qiáng)力測(cè)試：集成與兼容性測(cè)試：裝配/安裝/配置測(cè)試：國(guó)際化支持測(cè)試：本地化語(yǔ)言測(cè)試：
這些都是測(cè)試的方法.
5.軟件測(cè)試的方法有哪幾種
《全國(guó)計(jì)算機(jī)等級(jí)考試三級(jí)教程軟件測(cè)試》目錄 第1章 軟件測(cè)試的基本概念1.1 軟件質(zhì)量的概念1.1.1 軟件質(zhì)量的定義1.1.2 軟件質(zhì)量的屬性1.1.3 軟件質(zhì)量模型1.1.4 軟件質(zhì)量的度量1.1.5 影響軟件質(zhì)量的主要因素1.2 軟件測(cè)試的概念1.2.1 軟件測(cè)試的定義與目的1.2.2 軟件測(cè)試的原則1.3 軟件的缺陷與錯(cuò)誤1.3.1 軟件缺陷的定義和類型1.3.2 軟件缺陷的級(jí)別1.3.3 軟件缺陷產(chǎn)生的原因1.3.4 軟件缺陷的構(gòu)成第1章 軟件測(cè)試的基本概念1.1 軟件質(zhì)量的概念1.1.1 軟件質(zhì)量的定義1.1.2 軟件質(zhì)量的屬性1.1.3 軟件質(zhì)量模型1.1.4 軟件質(zhì)量的度量1.1.5 影響軟件質(zhì)量的主要因素1.2 軟件測(cè)試的概念1.2.1 軟件測(cè)試的定義與目的1.2.2 軟件測(cè)試的原則1.3 軟件的缺陷與錯(cuò)誤1.3.1 軟件缺陷的定義和類型1.3.2 軟件缺陷的級(jí)別1.3.3 軟件缺陷產(chǎn)生的原因1.3.4 軟件缺陷的構(gòu)成1.3.5 修復(fù)軟件缺陷的代價(jià)1.4 軟件測(cè)試的經(jīng)濟(jì)學(xué)與心理學(xué)1.4.1 軟件測(cè)試的心理學(xué)1.4.2 軟件測(cè)試的經(jīng)濟(jì)學(xué)1.5 軟件質(zhì)量保證1.5.1 軟件質(zhì)量保證概要1.5.2 軟件質(zhì)量保證活動(dòng)的實(shí)施1.5.3 軟件的驗(yàn)證與確認(rèn)1.5.4 驗(yàn)證和確認(rèn)任務(wù)分析 本章小結(jié) 第2章 軟件生存周期中測(cè)試的實(shí)施2.1 軟件開(kāi)發(fā)階段2.1.1 軟件生存周期2.1.2 軟件測(cè)試的生存周期模型2.1.3 軟件測(cè)試過(guò)程模型2.1.4 測(cè)試信息流2.2 需求獲取與分析階段的測(cè)試2.2.1 需求評(píng)審的實(shí)施2.2.2 需求規(guī)格說(shuō)明的評(píng)審2.2.3 Wiegers 用例與需求評(píng)審表2.2.4 基于原型的測(cè)試2.2.5 基于需求的測(cè)試覆蓋率評(píng)估2.3 設(shè)計(jì)階段的測(cè)試2.3.1 設(shè)計(jì)的測(cè)試因素2.3.2 設(shè)計(jì)評(píng)審的實(shí)施2.3.3 設(shè)計(jì)規(guī)格說(shuō)明的評(píng)審2.3.4 設(shè)計(jì)元素的覆蓋原則2.4 編程階段的測(cè)試2.4.1 白盒測(cè)試與黑盒測(cè)試2.4.2 源代碼的控制流覆蓋原則2.4.3 源代碼的數(shù)據(jù)流覆蓋原則2.4.4 源代碼的靜態(tài)分析與動(dòng)態(tài)測(cè)試2.5 運(yùn)行和維護(hù)階段的測(cè)試2.6 回歸測(cè)試2.6.1 回歸測(cè)試的概念2.6.2 回歸測(cè)試的類型2.6.3 回歸測(cè)試的時(shí)機(jī)2.6.4 回歸測(cè)試的實(shí)施 本章小結(jié) 第3章 代碼檢查、走查與評(píng)審3.1 桌上檢查3.1.1 桌上檢查的實(shí)施3.1.2 桌上檢查的檢查表3.2 代碼檢查3.2.1 特定的角色和職責(zé)3.2.2 代碼檢查的實(shí)施3.2.3 用于代碼檢查的檢查表3.3 走查3.3.1 特定的角色和職責(zé)3.3.2 走查的實(shí)施3.3.3 走查中的靜態(tài)分析技術(shù)3.4 同行評(píng)審3.4.1 同行評(píng)審的角色和職責(zé)3.4.2 同行評(píng)審的內(nèi)容3.4.3 評(píng)審的方法和技術(shù)3.4.4 評(píng)審工作 本章小結(jié) 第4章 白盒測(cè)試4.1 覆蓋率的概念4.2 邏輯覆蓋4.2.1 語(yǔ)句覆蓋與塊覆蓋4.2.2 判定覆蓋（分支覆蓋）4.2.3 條件覆蓋4.2.4 條件/判定覆蓋4.2.5 條件組合覆蓋4.2.6 路徑覆蓋4.2.7 ESTCA覆蓋4.2.8 LCSAJ覆蓋4.3 路徑測(cè)試4.3.1 分支結(jié)構(gòu)的路徑測(cè)試4.3.2 循環(huán)結(jié)構(gòu)的路徑測(cè)試4.3.3 圈復(fù)雜度與基本路徑測(cè)試4.4 數(shù)據(jù)流測(cè)試4.4.1 定義∕使用測(cè)試的幾個(gè)定義4.4.2 定義∕使用測(cè)試舉例4.4.3 定義∕使用路徑測(cè)試覆蓋指標(biāo)4.5 基于覆蓋的測(cè)試用例選擇4.5.1 覆蓋率的使用4.5.2 使用最少的測(cè)試用例來(lái)達(dá)到覆蓋4.6 程序插樁技術(shù)4.6.1 程序插樁4.6.2 用于測(cè)試覆蓋率的程序插樁4.6.3 用于斷言檢測(cè)的程序插樁4.6.4 用于數(shù)據(jù)流異常檢測(cè)的程序插樁 本章小結(jié) 第5章 黑盒測(cè)試5.1 等價(jià)類測(cè)試5.1.1 等價(jià)類的概念5.1.2 等價(jià)類測(cè)試的原則5.1.3 等價(jià)類方法測(cè)試用例設(shè)計(jì)舉例5.2 邊界值分析5.2.1 邊界值分析的概念5.2.2 選擇測(cè)試用例的原則5.2.3 邊界值方法測(cè)試用例設(shè)計(jì)舉例5.3 基于判定表的測(cè)試5.3.1 判定表的概念5.3.2 基于判定表的測(cè)試用例設(shè)計(jì)舉例5.4 基于因果圖的測(cè)試5.4.1 因果圖的適用范圍5.4.2 用因果圖生成測(cè)試用例5.4.3 因果圖法測(cè)試用例設(shè)計(jì)舉例5.5 基于狀態(tài)圖的測(cè)試5.5.1 狀態(tài)圖5.5.2 利用狀態(tài)轉(zhuǎn)換樹(shù)生成測(cè)試用例5.5.3 利用狀態(tài)轉(zhuǎn)換表生成測(cè)試用例5.6 基于功能圖的測(cè)試5.6.1 功能圖5.6.2 功能圖法設(shè)計(jì)測(cè)試用例舉例5.7 基于用例和場(chǎng)景的測(cè)試5.7.1 基本流和備選流5.7.2 利用用例和場(chǎng)景設(shè)計(jì)測(cè)試用例的實(shí)例5.8 基于有向圖的測(cè)試用例設(shè)計(jì)5.8.1 使用基于有向圖的測(cè)試的場(chǎng)合5.8.2 基于事務(wù)流建模設(shè)計(jì)測(cè)試用例5.8.3 基于控制流建模設(shè)計(jì)測(cè)試用例5.8.4 基于有向圖設(shè)計(jì)測(cè)試用例的過(guò)程5.9 基于正交實(shí)驗(yàn)設(shè)計(jì)法的測(cè)試5.9.1 提取功能說(shuō)明，構(gòu)造因子/ 狀態(tài)表5.9.2 加權(quán)篩選，生成因素分析表5.9.3 利用正交表構(gòu)造測(cè)試數(shù)據(jù)集5.10 其他黑盒測(cè)試用例設(shè)計(jì)技術(shù) 本章小結(jié) 第6章 單元測(cè)試和集成測(cè)試6.1 單元測(cè)試的基本概念6.1.1 單元測(cè)試的定義6.1.2 單元測(cè)試與集成測(cè)試、系統(tǒng)測(cè)試的區(qū)別6.1.3 單元測(cè)試環(huán)境6.2 單元測(cè)試策略6.2.1 自頂向下的單元測(cè)試策略6.2.2 自底向上的單元測(cè)試策略6.2.3 孤立測(cè)試6.2.4 綜合測(cè)試6.3 單元測(cè)試分析6.3.1 模塊接口6.3.2 局部數(shù)據(jù)結(jié)構(gòu)6.3.3 獨(dú)立路徑6.3.4 出錯(cuò)處理6.3.5 邊界條件6.4 單元測(cè)試的測(cè)試用例設(shè)計(jì)原則6.4.1 單元測(cè)試的測(cè)試用例設(shè)計(jì)步驟6.4.2 單元測(cè)試中的白盒測(cè)試與黑盒測(cè)試6.5 集成測(cè)試的基本概念6.6 集成測(cè)試策略6.6.1 基于分解的集成策略6.6.2 基于功能的集成6.6.3 基于路徑的集成6.6.4 基于調(diào)用圖的集成6.7 集成測(cè)試分析6.7.1 體系結(jié)構(gòu)分析6.7.2 模塊單元分析6.7.3 接口分析6.7.4 風(fēng)險(xiǎn)分析6.7.5 可測(cè)試性分析6.7.6 集成測(cè)試策略分析6.7.7 常見(jiàn)的集成測(cè)試故障6.8 集成測(cè)試的測(cè)試用例設(shè)計(jì)原則6.8.1 集成測(cè)試的測(cè)試用例設(shè)計(jì)步驟6.8.2 場(chǎng)景測(cè)試 本章小結(jié) 第7章 系統(tǒng)測(cè)試7.1 系統(tǒng)測(cè)試概念7.2 系。
6.軟件測(cè)試的方法有哪些
電腦軟件是計(jì)算機(jī)系統(tǒng)中的程序，數(shù)據(jù)，有關(guān)文檔的集合.
電腦軟件（ComputerSoftware）是指計(jì)算機(jī)系統(tǒng)中的程序及其文檔。程序是計(jì)算任務(wù)的處理對(duì)象和處理規(guī)則的描述；文檔是為了便于了解程序所需的闡明性資料。程序必須裝入機(jī)器內(nèi)部才能工作，文檔一般是給人看的，不一定裝入機(jī)器。
軟件是用戶與硬件之間的接口界面。用戶主要是通過(guò)軟件與計(jì)算機(jī)進(jìn)行交流。軟件是計(jì)算機(jī)系統(tǒng)設(shè)計(jì)的重要依據(jù)。為了方便用戶，為了使計(jì)算機(jī)系統(tǒng)具有較高的總體效用，在設(shè)計(jì)計(jì)算機(jī)系統(tǒng)時(shí)，必須通盤考慮軟件與硬件的結(jié)合，以及用戶的要求和軟件的要求。
軟件的正確含義應(yīng)該是：
(1)運(yùn)行時(shí)，能夠提供所要求功能和性能的指令或計(jì)算機(jī)程序集合。
(2)程序能夠滿意地處理信息的數(shù)據(jù)結(jié)構(gòu)。
(3)描述程序功能需求以及程序如何操作和使用所要求的文檔。
軟件具有與硬件不同的特點(diǎn)：
(1)表現(xiàn)形式不同
硬件有形，有色，有味，看得見(jiàn)，摸得著，聞得到。而軟件無(wú)形，無(wú)色，無(wú)味，看不見(jiàn)，摸不著，聞不到。軟件大多存在人們的腦袋里或紙面上，它的正確與否，是好是壞，一直要到程序在機(jī)器上運(yùn)行才能知道。這就給設(shè)計(jì)、生產(chǎn)和管理帶來(lái)許多困難。
(2)生產(chǎn)方式不同
軟件是開(kāi)發(fā)，是人的智力的高度發(fā)揮，不是傳統(tǒng)意義上的硬件制造。盡管軟件開(kāi)發(fā)與硬件制造之間有許多共同點(diǎn)，但這兩種活動(dòng)是根本不同的。
(3)要求不同
硬件產(chǎn)品允許有誤差，而軟件產(chǎn)品卻不允許有誤差。
4）維護(hù)不同
硬件是要用舊用壞的，在理論上，軟件是不會(huì)用舊用壞的，但在實(shí)際上，軟件也會(huì)變舊變壞。因?yàn)樵谲浖恼麄€(gè)生存期中，一直處于改變（維護(hù)）狀態(tài)。
軟件分為系統(tǒng)軟件和應(yīng)用軟件
系統(tǒng)軟件如：操作系統(tǒng)
應(yīng)用軟件如：word wps rar 等
7.軟件測(cè)試的方法有哪些
測(cè)試的有2種方法答：黑盒測(cè)試和白盒測(cè)試黑盒：這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō)明書，檢查程序的功能是否符合它的功能說(shuō)明。
黑盒測(cè)試又叫做功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。白盒：此方法把測(cè)試對(duì)象看做一個(gè)透明的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。
通過(guò)在不同點(diǎn)檢查程序的狀態(tài)，確定實(shí)際的狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。
軟件測(cè)試按過(guò)程分為三個(gè)步驟答：?jiǎn)卧獪y(cè)試：?jiǎn)卧獪y(cè)試又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位 ─ 程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。
單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試。
集成測(cè)試：在運(yùn)行（可能是不完整）的應(yīng)用中保證軟件單元被結(jié)合后能正常操作的測(cè)試執(zhí)行的階段系統(tǒng)測(cè)試：當(dāng)應(yīng)用作為整體運(yùn)行時(shí)的測(cè)試執(zhí)行階段軟件測(cè)試的步驟是什么？1） 測(cè)試過(guò)程按4個(gè)步驟進(jìn)行，即單元測(cè)試（Unit Testing）、集成測(cè)試（Integrated Testing）、確認(rèn)測(cè)試（Validation Testing）和系統(tǒng)測(cè)試（System Testing）及發(fā)版測(cè)試。2） 開(kāi)始是單元測(cè)試，集中對(duì)用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。
3） 集成測(cè)試把已測(cè)試過(guò)的模塊組裝起來(lái)，主要對(duì)與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進(jìn)行測(cè)試。4） 確認(rèn)測(cè)試則是要檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說(shuō)明中確定了的各種需求，以及軟件配置是否完全、正確。
應(yīng)該考慮進(jìn)行如何測(cè)試的測(cè)試方法黑盒測(cè)試 （Black box testing） ── 不考慮內(nèi)部設(shè)計(jì)和代碼，根據(jù)需求和功能進(jìn)行測(cè)試。白盒測(cè)試 （White box testing） ── 根據(jù)應(yīng)用軟件的代碼的內(nèi)部邏輯，按照代碼的語(yǔ)句、分支、路徑和條件進(jìn)行測(cè)試。
功能測(cè)試（functional testing）——對(duì)一個(gè)應(yīng)用軟件的功能模塊進(jìn)行黑盒測(cè)試。這種測(cè)試應(yīng)當(dāng)由測(cè)試人員進(jìn)行。
但這并不意味著程序員在推出軟件之前不進(jìn)行代碼檢查。（這一原則適用于所有的測(cè)試階段。）
系統(tǒng)測(cè)試 ── 針對(duì)全部需求說(shuō)明進(jìn)行黑盒測(cè)試，包括系統(tǒng)中所有的部件?；貧w測(cè)試 （regression testing） ── 每當(dāng)軟件經(jīng)過(guò)了整理、修改、或者其環(huán)境發(fā)生變化，都重復(fù)進(jìn)行測(cè)試。
很難說(shuō)需要進(jìn)行多少次回歸測(cè)試，特別是是到了開(kāi)發(fā)周期的最后階段。進(jìn)行此種測(cè)試，特別適于使用自動(dòng)測(cè)試工具。
負(fù)荷試驗(yàn) （load testing） ── 在大負(fù)荷條件下對(duì)應(yīng)用軟件進(jìn)行測(cè)試。例如測(cè)試一個(gè)網(wǎng)站在不同負(fù)荷情況下的狀況，以確定在什么情況下系統(tǒng)響應(yīng)速度下降或是出現(xiàn)故障。
壓力測(cè)試 （stress testing） ── 經(jīng)?？梢耘c“負(fù)荷測(cè)試”或“性能測(cè)試”相互代替。這種測(cè)試是用來(lái)檢查系統(tǒng)在下列條件下的情況：在非正常的巨大負(fù)荷下、某些動(dòng)作和輸入大量重復(fù)、輸入大數(shù)、對(duì)數(shù)據(jù)庫(kù)進(jìn)行非常復(fù)雜的查詢，等等。
性能測(cè)試 （performance testing） ── 經(jīng)?？梢耘c“壓力測(cè)試”或“負(fù)荷測(cè)試”相互代替。理想的“性能測(cè)試”（也包括其他任何類型的測(cè)試） 都應(yīng)在質(zhì)量保障和測(cè)試計(jì)劃的文檔終予以規(guī)定。
可用性測(cè)試 （usability testing） ── 是專為“對(duì)用戶友好”的特性進(jìn)行測(cè)試。這是一種主觀的感覺(jué)，取決于最終用戶或顧客。
可以進(jìn)行用戶會(huì)見(jiàn)、檢查、對(duì)用戶會(huì)議錄像、或者使用其他技術(shù)。程序員和測(cè)試人員通常不參加可用性測(cè)試。
安裝/卸載測(cè)試 （install/uninstall testing） ── 對(duì)安裝/卸載進(jìn)行測(cè)試 （包括全部、部分、升級(jí)操作）。安全測(cè)試 （security testing） ── 測(cè)試系統(tǒng)在應(yīng)付非授權(quán)的內(nèi)部/外部訪問(wèn)、故意的損壞時(shí)的防護(hù)情況。
這需要精密復(fù)雜的測(cè)試技術(shù)。兼容性測(cè)試 （compatability testing） ── 測(cè)試在特殊的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)環(huán)境下的軟件表現(xiàn)。
α 測(cè)試 （alpha testing） ── 在開(kāi)發(fā)一個(gè)應(yīng)用軟件即將完成時(shí)所進(jìn)行的測(cè)試。此時(shí)還允許有較小的設(shè)計(jì)修改。
通常由最終用戶或其他人進(jìn)行這種測(cè)試，而不是由程序員和測(cè)試人員來(lái)進(jìn)行。β 測(cè)試 （beta testing） ── 當(dāng)開(kāi)發(fā)和測(cè)試已基本完成，需要在正式發(fā)行之前最后尋找毛病而進(jìn)行的測(cè)試。
通常由最終用戶或其他人進(jìn)行這種測(cè)試，而不是由程序員和測(cè)試人員來(lái)進(jìn)行。
8.軟件測(cè)試常見(jiàn)的3種方式是什么,分別可將軟件測(cè)試分為哪些測(cè)試
V模型 v模型在軟件測(cè)試方面，V模型是最廣為人知的模型，盡管很多富有實(shí)際經(jīng)驗(yàn)的測(cè)試人員還是不太熟悉V模型，或者其它的模型。
V模型已存在了很長(zhǎng)時(shí)間，和瀑布開(kāi)發(fā)模型有著一些共同的特性，由此也和瀑布模型一樣地受到了批評(píng)和質(zhì)疑。V模型中的過(guò)程從左到右，描述了基本的開(kāi)發(fā)過(guò)程和測(cè)試行為。
V模型的價(jià)值在于它非常明確地標(biāo)明了測(cè)試過(guò)程中存在的不同級(jí)別，并且清楚地描述了這些測(cè)試階段和開(kāi)發(fā)過(guò)程期間各階段的對(duì)應(yīng)關(guān)系。局限性：把測(cè)試作為編碼之后的最后一個(gè)活動(dòng)，需求分析等前期產(chǎn)生的錯(cuò)誤直到后期的驗(yàn)收測(cè)試才能發(fā)現(xiàn)。
W模型 W模型W模型由Evolutif公司提出，相對(duì)于V模型，W模型更科學(xué)。W模型是V模型的發(fā)展，強(qiáng)調(diào)的是測(cè)試伴隨著整個(gè)軟件開(kāi)發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。
測(cè)試與開(kāi)發(fā)是同步進(jìn)行的，從而有利于盡早地發(fā)現(xiàn)問(wèn)題。W模型也有局限性。
W模型和V模型都把軟件的開(kāi)發(fā)視為需求、設(shè)計(jì)、編碼等一系列串行的活動(dòng)，無(wú)法支持迭代、自發(fā)性以及變更調(diào)整。 X模型 X模型X模型的左邊描述的是針對(duì)單獨(dú)程序片段所進(jìn)行的相互分離的編碼和測(cè)試，此后將進(jìn)行頻繁的交接，通過(guò)集成最終成為可執(zhí)行的程序，然后再對(duì)這些可執(zhí)行程序進(jìn)行測(cè)試。
己通過(guò)集成測(cè)試的成品可以進(jìn)行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個(gè)部分發(fā)生。
由圖中可見(jiàn)，X模型還定位了探索性測(cè)試，這是不進(jìn)行事先計(jì)劃的特殊類型的測(cè)試，這一方式往往能幫助有經(jīng)驗(yàn)的測(cè)試人員在測(cè)試計(jì)劃之外發(fā)現(xiàn)更多的軟件錯(cuò)誤。但這樣可能對(duì)測(cè)試造成人力、物力和財(cái)力的浪費(fèi)，對(duì)測(cè)試員的熟練程度要求比較高。
H模型 H模型H模型中， 軟件測(cè)試過(guò)程活動(dòng)完全獨(dú)立，貫穿于整個(gè)產(chǎn)品的周期，與其他流程并發(fā)地進(jìn)行，某個(gè)測(cè)試點(diǎn)準(zhǔn)備就緒時(shí)，就可以從測(cè)試準(zhǔn)備階段進(jìn)行到測(cè)試執(zhí)行階段。軟件測(cè)試可以盡早的進(jìn)行，并且可以根據(jù)被測(cè)物的不同而分層次進(jìn)行。
這個(gè)示意圖演示了在整個(gè)生產(chǎn)周期中某個(gè)層次上的一次測(cè)試“微循環(huán)”。圖中標(biāo)注的其它流程可以是任意的開(kāi)發(fā)流程，例如設(shè)計(jì)流程或者編碼流程。
也就是說(shuō)， 只要測(cè)試條件成熟了，測(cè)試準(zhǔn)備活動(dòng)完成了，測(cè)試執(zhí)行活動(dòng)就可以進(jìn)行了。 H模型揭示了一個(gè)原理：軟件測(cè)試是一個(gè)獨(dú)立的流程，貫穿產(chǎn)品整個(gè)生命周期，與其他流程并發(fā)地進(jìn)行。
H模型指出軟件測(cè)試要盡早準(zhǔn)備， 盡早執(zhí)行。不同的測(cè)試活動(dòng)可以是按照某個(gè)次序先后進(jìn)行的，但也可能是反復(fù)的，只要某個(gè)測(cè)試達(dá)到準(zhǔn)備就緒點(diǎn)，測(cè)試執(zhí)行活動(dòng)就可以開(kāi)展。
更多相關(guān)的測(cè)試知識(shí)，可以關(guān)注下 搜狗測(cè)試 微信公眾號(hào)，那上面會(huì)發(fā)各種測(cè)試相關(guān)的文章。
