亚洲视频电影在线,久久婷婷国产麻豆91天堂,国产精品久久999

常見測(cè)試術(shù)語(yǔ)

SLA －－服務(wù)級(jí)別協(xié)議（ service level agreement ）
服務(wù)提供商與客戶之間的一個(gè)協(xié)議，用于規(guī)定服務(wù)提供商應(yīng)當(dāng)提供什么服務(wù)。

Smoke Testing －－冒煙測(cè)試? ?? ?? ?
對(duì)軟件主要功能進(jìn)行快餐式測(cè)試。最早來(lái)自于硬件測(cè)試實(shí)踐，以確定新的硬件在第一次使用的時(shí)候不會(huì)著火。

software development process －－軟件開發(fā)過(guò)程? ?? ?? ?
一個(gè)把用戶需求轉(zhuǎn)換為軟件產(chǎn)品的開發(fā)過(guò)程。

software diversity －－軟件多樣性? ?? ?? ?
一種軟件開發(fā)技術(shù)，其中，由不同的程序員或開發(fā)組開發(fā)的相同規(guī)格的不同程序，目的是為了檢測(cè)錯(cuò)誤、增加可靠性。

software element －－軟件元素? ?? ?? ?
軟件開發(fā)或維護(hù)期間產(chǎn)生或獲得的一個(gè)可交付的或過(guò)程內(nèi)的文檔。

software engineering －－軟件工程? ?? ?? ?
一個(gè)應(yīng)用于軟件開發(fā)、操作和維護(hù)的系統(tǒng)性的、有紀(jì)律的、可量化的方法。

software engineering environment －－軟件工程環(huán)境? ?? ?? ?
執(zhí)行一個(gè)軟件工程工作的硬件、軟件和固件。

software life cycle －－軟件生命周期? ?? ?? ?
開始于一個(gè)軟件產(chǎn)品的構(gòu)思，結(jié)束于該產(chǎn)品不再被使用的這段期間。

SOP －－標(biāo)準(zhǔn)操作過(guò)程（ standard operating procedures ）
書面的步驟，這對(duì)保證生產(chǎn)和處理的控制是必須的。

source code －－源代碼? ?? ?? ?
用一種適合于輸入到匯編器、編譯器或其它轉(zhuǎn)換設(shè)備的計(jì)算機(jī)指令和數(shù)據(jù)定義。

source statement －－源語(yǔ)句? ?? ?? ?
參考語(yǔ)句（ statement ）

第 132 貼【 2004 － 11 － 2 】：常見測(cè)試術(shù)語(yǔ)十四

specification －－規(guī)格? ?? ?? ?
組件功能的一個(gè)描述，格式是：對(duì)指定的輸入在指定的條件下的輸出。

specified input －－指定的輸入? ?? ?? ?
一個(gè)輸入，根據(jù)規(guī)格能預(yù)知其輸出。

spiral model? ?? ???－－螺旋模型? ?? ?? ?
軟件開發(fā)過(guò)程的一個(gè)模型，其中的組成活動(dòng)，典型的包括需求分析，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，編碼，集成和測(cè)試等活動(dòng)被迭代的執(zhí)行直到軟件被完成。

SQL －－結(jié)構(gòu)化查詢語(yǔ)句（ structured query language ）
在一個(gè)關(guān)系數(shù)據(jù)庫(kù)中查詢和處理數(shù)據(jù)的一種語(yǔ)言。

state －－狀態(tài)? ?? ?? ?
一個(gè)系統(tǒng)、組件或模擬可能存在其中的一個(gè)條件或模式。

state diagram －－狀態(tài)圖? ?? ?? ?
一個(gè)圖形，描繪一個(gè)系統(tǒng)或組件可能假設(shè)的狀態(tài)，并且顯示引起或?qū)е乱粋€(gè)狀態(tài)切換到另一個(gè)狀態(tài)的事件或環(huán)境。

state transition －－狀態(tài)轉(zhuǎn)換? ?? ?? ?
一個(gè)系統(tǒng)或組件的兩個(gè)允許狀態(tài)之間的切換。

state transition testing? ?? ???－－狀態(tài)轉(zhuǎn)換測(cè)試? ?? ?? ?
根據(jù)狀態(tài)轉(zhuǎn)換來(lái)設(shè)計(jì)測(cè)試用例的一種方法。

statement －－語(yǔ)句? ?? ?? ?
程序語(yǔ)言的一個(gè)實(shí)體，是典型的最小可執(zhí)行單元。

statement coverage －－語(yǔ)句覆蓋? ?? ?? ?
在一個(gè)組件中，通過(guò)執(zhí)行一定的測(cè)試用例所能達(dá)到的語(yǔ)句覆蓋百分比。

statement testing －－語(yǔ)句測(cè)試? ?? ?? ?
根據(jù)語(yǔ)句覆蓋來(lái)設(shè)計(jì)測(cè)試用例的一種方法。

Static Analysis －－靜態(tài)分析? ?? ?? ?
分析一個(gè)程序的執(zhí)行，但是并不實(shí)際執(zhí)行這個(gè)程序。

第 133 貼【 2004 － 11 － 3 】：常見測(cè)試術(shù)語(yǔ)十五

Static Analyzer －－靜態(tài)分析器? ?? ?? ?
進(jìn)行靜態(tài)分析的工具。

Static Testing －－靜態(tài)測(cè)試? ?? ?? ?
不通過(guò)執(zhí)行來(lái)測(cè)試一個(gè)系統(tǒng)。

statistical testing －－統(tǒng)計(jì)測(cè)試? ?? ?? ?
通過(guò)使用對(duì)輸入統(tǒng)計(jì)分布進(jìn)行分析來(lái)構(gòu)造測(cè)試用例的一種測(cè)試設(shè)計(jì)方法。

stepwise refinement －－逐步優(yōu)化? ?? ?? ?
一個(gè)結(jié)構(gòu)化軟件設(shè)計(jì)技術(shù)，數(shù)據(jù)和處理步驟首先被廣泛的定義，然后被逐步的進(jìn)行了細(xì)化。

storage testing －－存儲(chǔ)測(cè)試? ?? ?? ?
驗(yàn)證系統(tǒng)是否滿足指定存儲(chǔ)目標(biāo)的測(cè)試。

Stress Testing －－壓力測(cè)試? ?? ?? ?
在規(guī)定的規(guī)格條件或者超過(guò)規(guī)定的規(guī)格條件下，測(cè)試一個(gè)系統(tǒng)，以評(píng)價(jià)其行為。類似負(fù)載測(cè)試，通常是性能測(cè)試的一部分。

structural coverage －－結(jié)構(gòu)化覆蓋? ?? ?? ?
根據(jù)組件內(nèi)部的結(jié)構(gòu)度量覆蓋率。

structural test case design －－結(jié)構(gòu)化測(cè)試用例設(shè)計(jì)? ?? ?? ?
根據(jù)組件內(nèi)部結(jié)構(gòu)的分析來(lái)設(shè)計(jì)測(cè)試用例的一種方法。

structural testing －－結(jié)構(gòu)化測(cè)試? ?? ?? ?
參考結(jié)構(gòu)化測(cè)試用例設(shè)計(jì)（ structural test case design ）

structured basis testing －－結(jié)構(gòu)化的基礎(chǔ)測(cè)試? ?? ?? ?
根據(jù)代碼邏輯設(shè)計(jì)測(cè)試用例來(lái)獲得 100 ％分支覆蓋的一種測(cè)試用例設(shè)計(jì)技術(shù)。

structured design －－結(jié)構(gòu)化設(shè)計(jì)? ?? ?? ?
軟件設(shè)計(jì)的任何遵循一定紀(jì)律的方法，它按照特定的規(guī)則，例如：模塊化，有頂向下設(shè)計(jì)，數(shù)據(jù)逐步優(yōu)化，系統(tǒng)結(jié)構(gòu)和處理步驟。

structured programming －－結(jié)構(gòu)化編程? ?? ?? ?
在結(jié)構(gòu)化程序開發(fā)中的任何包含結(jié)構(gòu)化設(shè)計(jì)和結(jié)果的軟件開發(fā)技術(shù)。

structured walkthrough －－結(jié)構(gòu)化走讀? ?? ?? ?
參考走讀（ walkthrough ）

第 134 貼【 2004 － 11 － 4 】：常見測(cè)試術(shù)語(yǔ)十六

stub －－樁? ?? ?? ?
一個(gè)軟件模塊的框架或特殊目標(biāo)實(shí)現(xiàn)，主要用于開發(fā)和測(cè)試一個(gè)組件，該組件調(diào)用或依賴這個(gè)模塊。

symbolic evaluation －－符號(hào)評(píng)價(jià)? ?? ?? ?
參考符號(hào)執(zhí)行（ symbolic execution ）

symbolic execution －－符號(hào)執(zhí)行? ?? ?? ?
通過(guò)符號(hào)表達(dá)式來(lái)執(zhí)行程序路徑的一種靜態(tài)分析設(shè)計(jì)技術(shù)。其中，程序的執(zhí)行被用符號(hào)來(lái)模擬，例如，使用變量名而不是實(shí)際值，程序的輸出被表示成包含這些符號(hào)的邏輯或數(shù)學(xué)表達(dá)式。

symbolic trace －－符號(hào)軌跡? ?? ?? ?
一個(gè)計(jì)算機(jī)程序通過(guò)符號(hào)執(zhí)行是經(jīng)過(guò)的語(yǔ)句分支結(jié)果的一個(gè)記錄。

syntax testing －－語(yǔ)法分析? ?? ?? ?
根據(jù)輸入語(yǔ)法來(lái)驗(yàn)證一個(gè)系統(tǒng)或組件的測(cè)試用例設(shè)計(jì)技術(shù)。

system analysis －－系統(tǒng)分析? ?? ?? ?
對(duì)一個(gè)計(jì)劃的或現(xiàn)實(shí)的系統(tǒng)進(jìn)行的一個(gè)系統(tǒng)性調(diào)查以確定系統(tǒng)的功能以及系統(tǒng)與其它系統(tǒng)之間的交互。

system design －－系統(tǒng)設(shè)計(jì)? ?? ?? ?
一個(gè)定義硬件和軟件構(gòu)架、組件、模塊、接口和數(shù)據(jù)的過(guò)程以滿足指定的規(guī)格。

system integration －－系統(tǒng)集成? ?? ?? ?
一個(gè)系統(tǒng)組件的漸增的連接和測(cè)試，直到一個(gè)完整的系統(tǒng)。

System Testing －－系統(tǒng)測(cè)試? ?? ?? ?
從一個(gè)系統(tǒng)的整體而不是個(gè)體上來(lái)測(cè)試一個(gè)系統(tǒng)，并且該測(cè)試關(guān)注的是規(guī)格，而不是系統(tǒng)內(nèi)部的邏輯。

第 135 貼【 2004 － 11 － 7 】：常見測(cè)試術(shù)語(yǔ)十七

technical requirements testing －－技術(shù)需求測(cè)試? ?? ?? ?
參考非功能需求測(cè)試（ non-functional requirements testing ）

test automation －－測(cè)試自動(dòng)化? ?? ?? ?
使用工具來(lái)控制測(cè)試的執(zhí)行、結(jié)果的比較、測(cè)試預(yù)置條件的設(shè)置、和其它測(cè)試控制和報(bào)告功能。

test case －－測(cè)試用例? ?? ?? ?
用于特定目標(biāo)而開發(fā)的一組輸入、預(yù)置條件和預(yù)期結(jié)果。

test case design technique －－測(cè)試用例設(shè)計(jì)技術(shù)? ?? ?? ?
選擇和導(dǎo)出測(cè)試用例的技術(shù)。

test case suite －－測(cè)試用例套? ?? ?? ?
對(duì)被測(cè)軟件的一個(gè)或多個(gè)測(cè)試用例的集合。

test comparator －－測(cè)試比較器? ?? ?? ?
一個(gè)測(cè)試工具用于比較軟件實(shí)際測(cè)試產(chǎn)生的結(jié)果與測(cè)試用例預(yù)期的結(jié)果。

test completion criterion －－測(cè)試完成標(biāo)準(zhǔn)? ?? ?? ?
一個(gè)標(biāo)準(zhǔn)用于確定被計(jì)劃的測(cè)試何時(shí)完成。

test coverage －－測(cè)試覆蓋? ?? ?? ?
參考覆蓋率（ Coverage ）

test driver －－測(cè)試驅(qū)動(dòng)? ?? ?? ?
一個(gè)程序或測(cè)試工具用于根據(jù)測(cè)試套執(zhí)行軟件。

test environment －－測(cè)試環(huán)境? ?? ?? ?
測(cè)試運(yùn)行其上的軟件和硬件環(huán)境的描述，以及任何其它與被測(cè)軟件交互的軟件，包括驅(qū)動(dòng)和樁。

第 136 貼【 2004 － 11 － 8 】：常見測(cè)試術(shù)語(yǔ)十八

test execution －－測(cè)試執(zhí)行? ?? ?? ?
一個(gè)測(cè)試用例被被測(cè)軟件執(zhí)行，并得到一個(gè)結(jié)果。

test execution technique －－測(cè)試執(zhí)行技術(shù)? ?? ?? ?
執(zhí)行測(cè)試用例的技術(shù)，包括手工、自動(dòng)化等。

test generator －－測(cè)試生成器? ?? ?? ?
根據(jù)特定的測(cè)試用例產(chǎn)生測(cè)試用例的工具。

test harness －－測(cè)試用具? ?? ?? ?
包含測(cè)試驅(qū)動(dòng)和測(cè)試比較器的測(cè)試工具。

test log －－測(cè)試日志? ?? ?? ?
一個(gè)關(guān)于測(cè)試執(zhí)行所有相關(guān)細(xì)節(jié)的時(shí)間記錄。

test measurement technique －－測(cè)試度量技術(shù)? ?? ?? ?
度量測(cè)試覆蓋率的技術(shù)。

Test Plan －－測(cè)試計(jì)劃? ?? ?? ?
一個(gè)文檔，描述了要進(jìn)行的測(cè)試活動(dòng)的范圍、方法、資源和進(jìn)度。它確定測(cè)試項(xiàng)、被測(cè)特性、測(cè)試任務(wù)、誰(shuí)執(zhí)行任務(wù)，并且任何風(fēng)險(xiǎn)都要沖突計(jì)劃。

test procedure －－測(cè)試規(guī)程? ?? ?? ?
一個(gè)文檔，提供詳細(xì)的測(cè)試用例執(zhí)行指令。

test records －－測(cè)試記錄? ?? ?? ?
對(duì)每個(gè)測(cè)試，明確的記錄被測(cè)組件的標(biāo)識(shí)、版本，測(cè)試規(guī)格，和實(shí)際結(jié)果

test report －－測(cè)試報(bào)告? ?? ?? ?
一個(gè)描述系統(tǒng)或組件執(zhí)行的測(cè)試和結(jié)果的文檔。

Test Script －－測(cè)試腳本? ?? ?? ?
一般指的是一個(gè)特定測(cè)試的一系列指令，這些指令可以被自動(dòng)化測(cè)試工具執(zhí)行。

Test Specification －－測(cè)試規(guī)格? ?? ?? ?
一個(gè)文檔，用于指定一個(gè)軟件特性、特性組合或所有特性的測(cè)試方法、輸入、預(yù)期結(jié)果和執(zhí)行條件。

第 137 貼【 2004 － 11 － 9 】：常見測(cè)試術(shù)語(yǔ)十九

test strategy －－測(cè)試策略? ?? ?? ?
一個(gè)簡(jiǎn)單的高層文檔，用于描述測(cè)試的大致方法，目標(biāo)和方向。

test suite －－測(cè)試套? ?? ?? ?
測(cè)試用例和 / 或測(cè)試腳本的一個(gè)集合，與一個(gè)應(yīng)用的特定功能或特性相關(guān)。

test target －－測(cè)試目標(biāo)? ?? ?? ?
一組測(cè)試完成標(biāo)準(zhǔn)。

testability －－可測(cè)試性? ?? ?? ?
一個(gè)系統(tǒng)或組件有利于測(cè)試標(biāo)準(zhǔn)建立和確定這些標(biāo)準(zhǔn)是否被滿足的測(cè)試執(zhí)行的程度。

Testing －－測(cè)試? ?? ?? ?
IEEE 給出的定義是： 1 ）一個(gè)執(zhí)行軟件的過(guò)程，以驗(yàn)證其滿足指定的需求并檢測(cè)錯(cuò)誤。 2 ）一個(gè)軟件項(xiàng)的分析過(guò)程以檢測(cè)已有條件之間的不同，并評(píng)價(jià)軟件項(xiàng)的特性。

thread testing －－線程測(cè)試? ?? ?? ?
自頂向下測(cè)試的一個(gè)變化版本，其中，遞增的組件集成遵循需求子集的實(shí)現(xiàn)。

time sharing －－時(shí)間共享? ?? ?? ?
一種操作方式，允許兩個(gè)或多個(gè)用戶在相同的計(jì)算機(jī)系統(tǒng)上同時(shí)執(zhí)行計(jì)算機(jī)程序。其實(shí)現(xiàn)可能通過(guò)時(shí)間片輪轉(zhuǎn)、優(yōu)先級(jí)中斷等。

top-down design －－由頂向下設(shè)計(jì)? ?? ?? ?
一種設(shè)計(jì)策略，首先設(shè)計(jì)最高層的抽象和處理，然后逐步向更低級(jí)別進(jìn)行設(shè)計(jì)。

top-down testing －－自頂向下測(cè)試? ?? ?? ?
集成測(cè)試的一種策略，首先測(cè)試最頂層的組件，其它組件使用樁，然后逐步加入較低層的組件進(jìn)行測(cè)試，直到所有組件被集成到系統(tǒng)中。

traceability －－可跟蹤性? ?? ?? ?
開發(fā)過(guò)程的兩個(gè)或多個(gè)產(chǎn)品之間關(guān)系可以被建立起來(lái)的程度，尤其是產(chǎn)品彼此之間有一個(gè)前后處理關(guān)系。

traceability analysis －－跟蹤性分析? ?? ?? ?
（ 1 ）跟蹤概念文檔中的軟件需求到系統(tǒng)需求；（ 2 ）跟蹤軟件設(shè)計(jì)描述到軟件需求規(guī)格，以及軟件需求規(guī)格到軟件設(shè)計(jì)描述；（ 3 ）跟蹤源代碼對(duì)應(yīng)到設(shè)計(jì)規(guī)格，以及設(shè)計(jì)規(guī)格對(duì)應(yīng)到源代碼。分析確定它們之間正確性、一致性、完整性、精確性的關(guān)系。

traceability matrix －－跟蹤矩陣? ?? ?? ?
一個(gè)用于記錄兩個(gè)或多個(gè)產(chǎn)品之間關(guān)系的矩陣。例如，需求跟蹤矩陣是跟蹤從需求到設(shè)計(jì)再到編碼的實(shí)現(xiàn)。

第 138 貼【 2004 － 11 － 10 】：常見測(cè)試術(shù)語(yǔ)二十

transaction －－事務(wù) / 處理? ?? ?? ?
（ 1 ）一個(gè)命令、消息或輸入記錄，它明確或隱含的調(diào)用了一個(gè)處理活動(dòng)，例如更新一個(gè)文件。（ 2 ）用戶和系統(tǒng)之間的一次交互。（ 3 ）在一個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)中，完成一個(gè)特定目的的處理單元，如恢復(fù)、更新、修改或刪除一個(gè)或多個(gè)數(shù)據(jù)元素。

transform analysis －－事務(wù)分析? ?? ?? ?
系統(tǒng)的結(jié)構(gòu)是根據(jù)分析系統(tǒng)需要處理的事務(wù)獲得的一種分析技術(shù)。
trojan horse －－特洛伊木馬? ?? ?? ?
一種攻擊計(jì)算機(jī)系統(tǒng)的方法，典型的方法是提供一個(gè)包含具有攻擊性隱含代碼的有用程序給用戶，在用戶執(zhí)行該程序的時(shí)候，其隱含的代碼對(duì)系統(tǒng)進(jìn)行非法訪問(wèn)，并可能產(chǎn)生破壞。

truth table －－真值表? ?? ?? ?
用于邏輯操作的一個(gè)操作表格。

Unit Testing －－單元測(cè)試? ?? ?? ?
測(cè)試單個(gè)的軟件組件，屬于白盒測(cè)試范疇，其測(cè)試基礎(chǔ)是軟件內(nèi)部的邏輯。

Usability Testing －－可用性測(cè)試? ?? ?? ?
測(cè)試用戶使用和學(xué)習(xí)產(chǎn)品的容易程度。

validation －－確認(rèn)? ?? ?? ?
根據(jù)用戶需要確認(rèn)軟件開發(fā)的產(chǎn)品的正確性。

verification －－驗(yàn)證? ?? ?? ?
評(píng)價(jià)一個(gè)組件或系統(tǒng)以確認(rèn)給定開發(fā)階段的產(chǎn)品是否滿足該階段開始時(shí)設(shè)定的標(biāo)準(zhǔn)。

version －－版本? ?? ?? ?
一個(gè)軟件項(xiàng)或軟件元素的一個(gè)初始發(fā)布或一個(gè)完整的再發(fā)布。

volume testing －－容量測(cè)試? ?? ?? ?
使用大容量數(shù)據(jù)測(cè)試系統(tǒng)的一種策略。

Walkthrough －－走讀? ?? ?? ?
一個(gè)針對(duì)需求、設(shè)計(jì)或代碼的非正式的同行評(píng)審，一般由作者發(fā)起，由作者的同行參與進(jìn)行的評(píng)審過(guò)程。

waterfall model －－瀑布模型? ?? ?? ?
軟件開發(fā)過(guò)程模型的一種，包括概念階段、需求階段、設(shè)計(jì)階段、實(shí)現(xiàn)階段、測(cè)試階段、安裝和檢查階段、操作和維護(hù)階段，這些階段按次序進(jìn)行，可能有部分重疊，但很少會(huì)迭代。

White Box Testing －－白盒測(cè)試? ?? ?? ?
根據(jù)軟件內(nèi)部的工作原理分析來(lái)進(jìn)行測(cè)試。

第 139 貼【 2004 － 11 － 11 】：測(cè)試是一個(gè)持續(xù)進(jìn)行的過(guò)程，而不是一個(gè)階段

在傳統(tǒng)的瀑布式開發(fā)模型中定義了專門的測(cè)試階段，如單元測(cè)試階段，集成測(cè)試階段或系統(tǒng)測(cè)試階段。然而，這并不意味著測(cè)試只有在這個(gè)時(shí)候才進(jìn)行。我遇到過(guò)很多項(xiàng)目，在這些項(xiàng)目中，對(duì)測(cè)試的理解都基于了階段這個(gè)概念，在他們的思維中，測(cè)試只有在適當(dāng)?shù)臅r(shí)候才開始，并且在某個(gè)點(diǎn)就可以結(jié)束了。這是一個(gè)錯(cuò)誤的理解，并且對(duì)產(chǎn)品的質(zhì)量來(lái)說(shuō)是很危險(xiǎn)的。現(xiàn)代的測(cè)試已經(jīng)發(fā)展成為一個(gè)全過(guò)程的驗(yàn)證和確認(rèn)活動(dòng)，它貫穿于整個(gè)開發(fā)生命周期的始末。為了獲得最大的受益，測(cè)試的開發(fā)和準(zhǔn)備必須在編碼之前就應(yīng)當(dāng)開始，同時(shí)為了保證最終的質(zhì)量，我們必須在開發(fā)過(guò)程的每個(gè)階段保證其過(guò)程的質(zhì)量。

第 140 貼【 2004 － 11 － 12 】：測(cè)試必須被計(jì)劃、被控制，并且被提供時(shí)間和資源

測(cè)試并不是一個(gè)隨機(jī)的活動(dòng)，測(cè)試必須被計(jì)劃，并且被安排足夠的時(shí)間和資源。測(cè)試活動(dòng)應(yīng)當(dāng)受到控制，測(cè)試的中間產(chǎn)物應(yīng)當(dāng)被評(píng)審并納入配置管理。
? ?? ?測(cè)試計(jì)劃是一個(gè)關(guān)鍵的管理功能，它定義了各個(gè)級(jí)別的測(cè)試所使用的策略、方法、測(cè)試環(huán)境、測(cè)試通過(guò)或失敗準(zhǔn)則等內(nèi)容。測(cè)試計(jì)劃的目的是要為有組織的完成測(cè)試提供一個(gè)基礎(chǔ)。從管理的角度來(lái)看，測(cè)試計(jì)劃是最重要的文檔，這是由于它幫助管理測(cè)試項(xiàng)目。如果一個(gè)測(cè)試計(jì)劃是完整并且經(jīng)過(guò)深思熟慮的，那么測(cè)試的執(zhí)行和分析將平滑的進(jìn)行。
? ?? ?測(cè)試計(jì)劃可以分級(jí)，也可以是一個(gè)總的計(jì)劃，并且測(cè)試計(jì)劃是一個(gè)不斷演進(jìn)的文檔。如果不考慮應(yīng)用軟件的最初來(lái)源（復(fù)用的組件或已實(shí)現(xiàn)的組件），軟件需求是測(cè)試活動(dòng)的驅(qū)動(dòng)。因此，測(cè)試計(jì)劃應(yīng)當(dāng)關(guān)注于文檔化的需求。此外，支持測(cè)試的過(guò)程應(yīng)當(dāng)被文檔化下來(lái)以創(chuàng)建一個(gè)可重復(fù)的過(guò)程，該過(guò)程將保證開發(fā)工作產(chǎn)品的質(zhì)量。
? ?? ?一個(gè)好的測(cè)試計(jì)劃應(yīng)當(dāng)：
1 、在檢測(cè)主要缺陷方面有一個(gè)好的選擇
2 、提供絕大部分代碼的覆蓋率
3 、是靈活的
4 、易于執(zhí)行、回歸和自動(dòng)化
5 、定義要執(zhí)行測(cè)試的種類
6 、清晰的文檔化了期望的結(jié)果
7 、當(dāng)缺陷被發(fā)現(xiàn)的時(shí)候，提供缺陷核對(duì)
8 、清晰的定義測(cè)試的目標(biāo)
9 、明確測(cè)試的策略
10 、清晰定義測(cè)試的出口標(biāo)準(zhǔn)
11 、沒(méi)有冗余
12 、確認(rèn)風(fēng)險(xiǎn)
13 、文檔化測(cè)試的需求
14 、定義可交付的測(cè)試件

第 141 貼【 2004 － 11 － 15 】：測(cè)試應(yīng)該有重點(diǎn)

盡管我們的測(cè)試是需要按照一定的級(jí)別進(jìn)行，但資源和時(shí)間是有限的，實(shí)際上我們不可能無(wú)休止的進(jìn)行測(cè)試，因此在有限的時(shí)間和資源下如何有重點(diǎn)的進(jìn)行測(cè)試是測(cè)試管理者需要充分考慮的事情。例如，在單元測(cè)試的時(shí)候，對(duì)于哪些函數(shù)我們需要重點(diǎn)測(cè)試，哪些函數(shù)可以粗略測(cè)試，哪些函數(shù)可以不測(cè)試；而對(duì)于系統(tǒng)測(cè)試，則要考慮首先應(yīng)當(dāng)保證哪些功能的測(cè)試，其次應(yīng)當(dāng)保證哪些功能的測(cè)試等等。測(cè)試的重點(diǎn)選擇需要根據(jù)多個(gè)方面考慮，包括測(cè)試對(duì)象的關(guān)鍵程度，可能的風(fēng)險(xiǎn)，質(zhì)量要求等等。這些考慮與經(jīng)驗(yàn)有關(guān)，隨著實(shí)踐經(jīng)驗(yàn)的增長(zhǎng)，你的判斷也會(huì)更有效。

第 142 貼【 2004 － 11 － 16 】：測(cè)試不是為了證明程序的正確性

正如 Mayer 所說(shuō)的，測(cè)試的目的是證偽而不是證真。事實(shí)上，證明程序的正確性是不可能的，一個(gè)大型的集成化的軟件系統(tǒng)不能被窮盡測(cè)試以遍歷其每條路徑。即使遍歷了所有的路徑，錯(cuò)誤仍有可能隱藏。我們做測(cè)試是為了盡可能的去發(fā)現(xiàn)錯(cuò)誤。因此，測(cè)試必須包含一系列測(cè)試級(jí)別。這些測(cè)試級(jí)別能最大化對(duì)被測(cè)對(duì)象的覆蓋。
? ? 必須有一些標(biāo)準(zhǔn)可以用于平均所有的測(cè)試活動(dòng)。所有可以跟蹤到需求的測(cè)試可以通過(guò)三個(gè)方式進(jìn)行執(zhí)行：
在正常的數(shù)據(jù)流量下的有效信息；
在一個(gè)控制環(huán)境中使用超量的數(shù)據(jù)輸入速率；
使用一個(gè)預(yù)先計(jì)劃的正常數(shù)據(jù)和異常數(shù)據(jù)的組合；
? ? 理想的測(cè)試環(huán)境要能夠使得一個(gè)系統(tǒng)在可控的方式下被破壞。例如，數(shù)據(jù)及數(shù)據(jù)組合必須不斷變化直到系統(tǒng)不能夠以正常的方式接受。系統(tǒng)支持變得不可接受的點(diǎn)必須被確認(rèn)并文檔化下來(lái)。
? ? 必須在所有的測(cè)試級(jí)別上運(yùn)行測(cè)試，且同時(shí)使用正常條件和異常條件。這是很嚴(yán)格的，即使在測(cè)試環(huán)境難以建立的情況下。

第 143 貼【 2004 － 11 － 17 】：測(cè)試是不可能窮盡的，當(dāng)測(cè)試出口條件滿足時(shí)就可以停止測(cè)試

有測(cè)試大師說(shuō)測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤，一個(gè)好的測(cè)試是發(fā)現(xiàn)以前沒(méi)有發(fā)現(xiàn)的錯(cuò)誤。但是這個(gè)要求可能會(huì)使人走入極端。其實(shí)，不同的系統(tǒng)有著不同的質(zhì)量要求，對(duì)于質(zhì)量要求嚴(yán)格的系統(tǒng)，可能需要進(jìn)行長(zhǎng)時(shí)間的，全面的測(cè)試，盡可能的去挖掘系統(tǒng)中的缺陷。然而對(duì)于質(zhì)量要求不是很嚴(yán)格的系統(tǒng)，系統(tǒng)是允許可以出現(xiàn)錯(cuò)誤的，因此我們通過(guò)測(cè)試是要使得系統(tǒng)的缺陷數(shù)量能夠降到可接受的范圍內(nèi)。
? ? 測(cè)試是不可能窮盡的，資源和時(shí)間是有限的。因此我們?cè)谧鰷y(cè)試的時(shí)候需要分析哪些功能是對(duì)用戶很關(guān)鍵的，在這些功能中出現(xiàn)某類型錯(cuò)誤對(duì)用戶是不可接受的，而相對(duì)其它一些功能，出現(xiàn)的錯(cuò)誤是可以容忍的，這樣，我們?cè)跍y(cè)試的時(shí)候，重點(diǎn)就應(yīng)當(dāng)去尋找那些用戶不可接受的錯(cuò)誤，而不是漫無(wú)目的的去搜索錯(cuò)誤。同時(shí)我們應(yīng)當(dāng)對(duì)測(cè)試定義合理的出口標(biāo)準(zhǔn)，這是因?yàn)闇y(cè)試是沒(méi)有窮盡的，系統(tǒng)中的問(wèn)題你總是可以一直發(fā)現(xiàn)下去，然而我們不能無(wú)休止的去尋找這些問(wèn)題。當(dāng)條件滿足的時(shí)候，我們就應(yīng)當(dāng)停止測(cè)試。而測(cè)試出口條件的設(shè)置需要考慮系統(tǒng)的質(zhì)量要求及系統(tǒng)的資源要求。曾經(jīng)有人說(shuō)過(guò)：當(dāng)時(shí)間和資源用盡的時(shí)候，測(cè)試也就停止了。這是沒(méi)有辦法的最好辦法。

第 144 貼【 2004 － 11 － 18 】：測(cè)試是開發(fā)的朋友，不是開發(fā)的敵人

測(cè)試人員和開發(fā)人員經(jīng)常無(wú)法有效的一起工作。這一方面是因?yàn)殡p方工作的性質(zhì)不同（開發(fā)的工作是構(gòu)建系統(tǒng)，而測(cè)試的工作是去破壞系統(tǒng)），另一方面也可能是因?yàn)楣芾淼脑蛟斐闪藴y(cè)試和開發(fā)之間的矛盾。不管是什么原因，這個(gè)矛盾，對(duì)于產(chǎn)品來(lái)說(shuō)不是一件好事。
? ? 如何處理好測(cè)試與開發(fā)之間的關(guān)系是現(xiàn)代軟件管理研究中的一個(gè)課題。開發(fā)和測(cè)試作為一個(gè)整體都是服務(wù)于產(chǎn)品，都要為產(chǎn)品的質(zhì)量負(fù)責(zé)。從這一點(diǎn)上來(lái)講，開發(fā)和測(cè)試的利益是一致的。要知道，如果在產(chǎn)品交付使用之前，測(cè)試人員遺漏了一個(gè)問(wèn)題，而這個(gè)問(wèn)題最終在用戶手上被發(fā)現(xiàn)，并產(chǎn)生比較嚴(yán)重的后果的時(shí)候，那么，我想無(wú)論是開發(fā)還是測(cè)試，最終都逃避不了責(zé)任。我們要為質(zhì)量服務(wù)，測(cè)試的目的是要去尋找錯(cuò)誤，最終提高產(chǎn)品的質(zhì)量，而不是去找開發(fā)的茬，只有當(dāng)雙方都認(rèn)識(shí)到這一點(diǎn)的時(shí)候，開發(fā)和測(cè)試就有共同交流的基礎(chǔ)了。測(cè)試應(yīng)當(dāng)是開發(fā)的朋友，他幫助開發(fā)尋找遺留在產(chǎn)品中的缺陷，使得開發(fā)人員能夠產(chǎn)生的更好的產(chǎn)品。測(cè)試和開發(fā)不應(yīng)當(dāng)是敵人。

第 145 貼【 2004 － 11 － 19 】：測(cè)試人員應(yīng)當(dāng)站在公正的立場(chǎng)上進(jìn)行測(cè)試

我們說(shuō)測(cè)試是開發(fā)的朋友，這并不等于測(cè)試就應(yīng)當(dāng)處處維護(hù)開發(fā)人員，替開發(fā)人員隱瞞缺陷或縱容缺陷的存在。這是對(duì)朋友的誤解。我們要知道缺陷的存在最終只會(huì)影響到整個(gè)產(chǎn)品。在開發(fā)過(guò)程中，測(cè)試人員一直承擔(dān)著質(zhì)量把關(guān)人員的角色，尤其是測(cè)試將會(huì)是產(chǎn)品最終交付給用戶之前的最后一道關(guān)卡。如果測(cè)試人員不能站在公正的立場(chǎng)上去執(zhí)行測(cè)試，并如實(shí)的記錄和報(bào)告缺陷，那么最后受傷的不僅僅是開發(fā)人員，還會(huì)包括測(cè)試人員自己。對(duì)質(zhì)量負(fù)責(zé)，不僅僅是對(duì)自己負(fù)責(zé)，也是對(duì)開發(fā)負(fù)責(zé)和對(duì)產(chǎn)品負(fù)責(zé)。

第 146 貼【 2004 － 11 － 22 】：測(cè)試自動(dòng)化能解決一部分問(wèn)題，但不是全部

工具所能發(fā)揮的作用依賴于使用工具的人。因此，對(duì)工具的過(guò)分依賴將降低人的能動(dòng)性，并最終使測(cè)試本身受到損害。適當(dāng)?shù)氖褂脺y(cè)試工具能夠減輕測(cè)試人員的機(jī)械性工作，提高工作效率，而濫用工具會(huì)降低測(cè)試的質(zhì)量。并不是任何工作都適合自動(dòng)化的，如何合理的自動(dòng)化測(cè)試，合理的選擇適當(dāng)?shù)臏y(cè)試工具已經(jīng)是研究人員感興趣的一個(gè)課題。

第 147 貼【 2004 － 11 － 23 】：測(cè)試不能僅僅包括功能性的驗(yàn)證，還需要包括非功能性的驗(yàn)證

目前很多公司進(jìn)行的測(cè)試，其范圍僅局限在功能領(lǐng)域內(nèi)進(jìn)行測(cè)試。這一方面可能有產(chǎn)品進(jìn)度的壓力影響，另一方面則是測(cè)試人員對(duì)測(cè)試的理解還比較局限。從用戶角度來(lái)講，其需求除了功能性需求外，還包括了非功能性需求，有些非功能需求可能是顯性的，而有些非功能需求則是隱性的。我們?cè)跍y(cè)試的時(shí)候，應(yīng)當(dāng)關(guān)注所有的需求，在驗(yàn)證功能的同時(shí)，還需要驗(yàn)證產(chǎn)品的性能、可靠性、穩(wěn)定性、可維護(hù)性、安全性、可操作性、可安裝性等等。一個(gè)產(chǎn)品的缺陷往往會(huì)在其性能的邊界上產(chǎn)生，如果我們忽視了這部分的測(cè)試，很多缺陷將漏過(guò)測(cè)試進(jìn)入到用戶手上。

第 48 貼【 2004 － 11 － 24 】：盡早的、頻繁的進(jìn)行測(cè)試

現(xiàn)代測(cè)試的一個(gè)重要哲學(xué)要求盡可能早的，盡可能頻繁的進(jìn)行測(cè)試，盡可能多的從開發(fā)那邊獲得反饋信息。這包含著要求測(cè)試盡可能早的進(jìn)行準(zhǔn)備，并且和開發(fā)人員一起進(jìn)行評(píng)審、走讀、單元測(cè)試、原型評(píng)價(jià)、早期模擬等等。早期測(cè)試的目的是盡可能早的發(fā)現(xiàn)任何意想不到的壞的消息，并且?guī)椭_發(fā)人員產(chǎn)生高質(zhì)量的單元。
? ? 該方法希望在缺陷產(chǎn)生的時(shí)候發(fā)現(xiàn)并糾正缺陷，它假設(shè)了在早期測(cè)試中發(fā)現(xiàn)的問(wèn)題能夠被描述并及時(shí)修正。許多項(xiàng)目管理人員延遲了缺陷修正的時(shí)間直到開發(fā)人員已經(jīng)完成了所有特性的設(shè)計(jì)和編碼。這大大提高了系統(tǒng)出錯(cuò)的可能，也增加了修改的成本。一般來(lái)說(shuō)，一次完成一個(gè)特性的設(shè)計(jì)和編碼，并保證其正確性將更加有效一些。
? ? 為什么我們要盡早的發(fā)現(xiàn)缺陷和修正缺陷呢？這主要有以下原因：
1 、缺陷的修改成本隨著階段的推移將急劇上升，在產(chǎn)品發(fā)布之后修正一個(gè)缺陷的成本將是需求階段的 100 倍，甚至更高；
2 、缺陷具有放大的特點(diǎn)，缺陷修改延遲幾個(gè)星期甚至幾個(gè)月將使得系統(tǒng)更容易出錯(cuò)；
3 、設(shè)計(jì)判定和一些小的代碼限制及條件很容易被忘掉；
4 、盡早修正缺陷可以節(jié)省重新分析設(shè)計(jì)的時(shí)間；
5 、早期的問(wèn)題反饋有助于防止類似錯(cuò)誤的產(chǎn)生；
6 、大量的缺陷和問(wèn)題跟蹤工作將被減輕；
7 、如果必要的話，可以重新設(shè)計(jì)和編碼，而這個(gè)工作越往后期越不可能

第 149 貼【 2004 － 11 － 25 】：盡早的產(chǎn)生一個(gè)綜合的主測(cè)試計(jì)劃

提供和維護(hù)一個(gè)主測(cè)試計(jì)劃（ Master Testing Plan ），包含所有預(yù)期的測(cè)試活動(dòng)和測(cè)試交付物。綜合的測(cè)試計(jì)劃應(yīng)當(dāng)結(jié)合總的項(xiàng)目和程序開發(fā)計(jì)劃，并保證資源和責(zé)任在項(xiàng)目中盡可能早的被了解和分配。
? ?? ?大部分項(xiàng)目沒(méi)有盡早的描述測(cè)試的問(wèn)題。主測(cè)試計(jì)劃解決了這個(gè)問(wèn)題并且使得測(cè)試的工作和策略可以被項(xiàng)目中的每個(gè)人看到和理解。主測(cè)試計(jì)劃至少應(yīng)當(dāng)包括測(cè)試的總工作量，分配所有主要工作的責(zé)任以及在所有測(cè)試級(jí)別上應(yīng)交付的物件。其目的是要提供一個(gè)大的活動(dòng)圖并且協(xié)調(diào)所有的測(cè)試工作。
? ?? ?主測(cè)試計(jì)劃涉及到項(xiàng)目組所有成員，包括用戶、客戶和管理人員。在測(cè)試評(píng)價(jià)中所包含的每個(gè)人的活動(dòng)應(yīng)當(dāng)被描述，包括那些分配給開發(fā)人員的活動(dòng)，例如：?jiǎn)卧u(píng)審和測(cè)試。產(chǎn)品經(jīng)理以及那些在項(xiàng)目之外的人員將發(fā)現(xiàn)主測(cè)試計(jì)劃有助于把測(cè)試過(guò)程融合到整個(gè)項(xiàng)目開發(fā)過(guò)程中去。隨著項(xiàng)目的進(jìn)行，主測(cè)試計(jì)劃也將被修正和更新。
? ?? ?創(chuàng)建主測(cè)試計(jì)劃不需要花費(fèi)許多工作量，并且它不需要是一個(gè)特別冗長(zhǎng)的或者嚴(yán)肅的文檔。許多內(nèi)容可以通過(guò)類似于 RAD ，頭腦風(fēng)暴等方法在項(xiàng)目早期被完成。

第 150 貼【 2004 － 11 － 26 】：對(duì)質(zhì)量要求較高的產(chǎn)品或大型復(fù)雜的產(chǎn)品成立獨(dú)立的測(cè)試組

測(cè)試是一個(gè)需要專業(yè)技能的工作，它需要專門的培訓(xùn)和實(shí)踐，你不應(yīng)當(dāng)把它看作是一個(gè)開發(fā)之外附帶的工作。大部分人認(rèn)為（尤其是項(xiàng)目管理人員）測(cè)試是項(xiàng)目工作中的一部分，因此他們認(rèn)為只要能夠小心的徹底的測(cè)試自己的工作，就能夠提交高質(zhì)量的工作結(jié)果。我們完全可以理解好的測(cè)試是每個(gè)人的任務(wù)。我們也知道測(cè)試是過(guò)程的一部分，并且在大部分情況下，我們知道需要做什么，需要得到什么。然而，事實(shí)上在進(jìn)度和競(jìng)爭(zhēng)的壓力下，測(cè)試任務(wù)經(jīng)常被第一個(gè)延遲、裁減或完全繞開。為什么會(huì)這樣呢？我們應(yīng)當(dāng)做些什么才能使得組內(nèi)每個(gè)人更好的履行他的責(zé)任呢？
? ?? ?大部分問(wèn)題是心里上的問(wèn)題：
? ?當(dāng)我們知道會(huì)有更多的問(wèn)題被發(fā)現(xiàn)的時(shí)候，測(cè)試會(huì)讓人沮喪；
? ?當(dāng)我們認(rèn)為每一樣?xùn)|西都已經(jīng)被完成的時(shí)候，測(cè)試讓人厭煩；
? ?弱的測(cè)試讓我們感覺獲得比實(shí)際上更多的進(jìn)展；
? ?對(duì)開發(fā)人員來(lái)說(shuō)，測(cè)試暴露的問(wèn)題越多，意味著有更多的返工需要進(jìn)行；
? ?對(duì)管理人員來(lái)說(shuō)，測(cè)試看起來(lái)像是虛的工作，在項(xiàng)目陷入問(wèn)題的時(shí)候是可以被砍調(diào)的；
? ?開發(fā)人員相信用戶和客戶愿意購(gòu)買低質(zhì)量的，但功能更多的產(chǎn)品；

? ? 由一個(gè)獨(dú)立于開發(fā)的專業(yè)測(cè)試組來(lái)從事項(xiàng)目的測(cè)試是一個(gè)比較好的實(shí)踐，并且能有效解決上面的問(wèn)題。

第 151 貼【 2004 － 11 － 29 】：在每個(gè)開發(fā)階段，使用質(zhì)量評(píng)價(jià)標(biāo)準(zhǔn)

許多項(xiàng)目看上去都進(jìn)行的非常不錯(cuò)，但到它們進(jìn)入集成測(cè)試和系統(tǒng)測(cè)試后，這時(shí)，甚至一個(gè)簡(jiǎn)單的測(cè)試都無(wú)法運(yùn)行起來(lái)。如何避免這種現(xiàn)象的產(chǎn)生呢？一個(gè)好的方法是盡早測(cè)試，并且在每個(gè)階段上通過(guò)測(cè)試數(shù)據(jù)來(lái)評(píng)價(jià)其是否能通過(guò)階段的質(zhì)量標(biāo)準(zhǔn)。當(dāng)你堅(jiān)持使用測(cè)試來(lái)分階段證明每一個(gè)特性或?qū)ο蟊煌瓿桑敲茨憔湍鼙ＷC各階段的設(shè)計(jì)和代碼被真正的按照質(zhì)量要求完成。

第 152 貼【 2004 － 11 － 30 】：開發(fā)和維護(hù)一個(gè)測(cè)試需求和目標(biāo)的風(fēng)險(xiǎn)優(yōu)先級(jí)列表

現(xiàn)代測(cè)試的一個(gè)重要實(shí)踐是在測(cè)試被設(shè)計(jì)和創(chuàng)建之前建立一個(gè)需要覆蓋的目標(biāo)清單。這個(gè)清單細(xì)化了需要測(cè)試的內(nèi)容，并且被用于指導(dǎo)和驅(qū)動(dòng)測(cè)試設(shè)計(jì)和開發(fā)工作。根據(jù)風(fēng)險(xiǎn)的優(yōu)先級(jí)（一般分為高、中、低）有助于使測(cè)試關(guān)注于高風(fēng)險(xiǎn)區(qū)域。
? ? 下面是一個(gè)如何獲取測(cè)試清單的指導(dǎo)：
盡可能早的開始并且覆蓋所有需求或功能設(shè)計(jì)規(guī)格；
使用頭腦風(fēng)暴和非正式會(huì)議來(lái)創(chuàng)建一些大家擔(dān)心的事項(xiàng)列表；
在評(píng)審期間，評(píng)價(jià)清單中的每一項(xiàng)，并設(shè)定優(yōu)先級(jí)；
把清單中的內(nèi)容分成三個(gè)主要的增量組：需求、設(shè)計(jì)和代碼；
把每個(gè)增量組分解成一個(gè)小部分的邏輯組；

? ? 由于清單列表可能會(huì)變得非常長(zhǎng)，因此把它們分類是很有幫助的。遺漏的目標(biāo)可以很容易從這些組中被確認(rèn)。
? ? 隨著每個(gè)測(cè)試被開發(fā)，相關(guān)的清單目標(biāo)和組被進(jìn)行了記錄，作為測(cè)試描述的一部分。通過(guò)一些簡(jiǎn)單的測(cè)試管理工具，你可以報(bào)告需求和目標(biāo)的測(cè)試覆蓋情況，尤其是哪些還沒(méi)有被任何測(cè)試覆蓋到的目標(biāo)。

posted on 2006-07-27 21:26 楊粼波閱讀(701) 評(píng)論(0) 編輯收藏引用所屬分類: 軟件工程

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
【推薦】100%開源！大型工業(yè)跨平臺(tái)軟件C++源碼提供，建模，組態(tài)！

相關(guān)文章: 用例驅(qū)動(dòng)的需求過(guò)程實(shí)踐特性、用例、需求－－ Rational軟件白皮書用例的需求分析-讀書筆記 Bug databases Performance test tools C++單元測(cè)試工具列表軟件測(cè)試相關(guān)的６３個(gè)國(guó)外站點(diǎn) 微軟的軟件測(cè)試方法（二）微軟的軟件測(cè)試方法常見測(cè)試術(shù)語(yǔ)

網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問(wèn) Chat2DB 管理

牽著老婆滿街逛

導(dǎo)航

統(tǒng)計(jì)

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊(cè)

收藏夾(39)

工具官網(wǎng)

技術(shù)網(wǎng)站

開源網(wǎng)站

其他窩點(diǎn)

收藏網(wǎng)站

銀行官網(wǎng)

友情鏈接

資源共享

搜索

積分與排名

最新評(píng)論

閱讀排行榜

常見測(cè)試術(shù)語(yǔ)