常見測試術(shù)語

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

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

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

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

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

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

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

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

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

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

source statement －－源語句
參考語句（ statement ）

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

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

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

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

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

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

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

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

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

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

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

statement testing －－語句測試
根據(jù)語句覆蓋來設(shè)計測試用例的一種方法。

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

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

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

Static Testing －－靜態(tài)測試
不通過執(zhí)行來測試一個系統(tǒng)。

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

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

storage testing －－存儲測試
驗證系統(tǒng)是否滿足指定存儲目標(biāo)的測試。

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

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

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

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

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

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

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

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

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

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

symbolic evaluation －－符號評價
參考符號執(zhí)行（ symbolic execution ）

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

symbolic trace －－符號軌跡
一個計算機(jī)程序通過符號執(zhí)行是經(jīng)過的語句分支結(jié)果的一個記錄。

syntax testing －－語法分析
根據(jù)輸入語法來驗證一個系統(tǒng)或組件的測試用例設(shè)計技術(shù)。

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

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

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

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

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

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

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

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

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

test case suite －－測試用例套
對被測軟件的一個或多個測試用例的集合。

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

test completion criterion －－測試完成標(biāo)準(zhǔn)
一個標(biāo)準(zhǔn)用于確定被計劃的測試何時完成。

test coverage －－測試覆蓋
參考覆蓋率（ Coverage ）

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

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

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

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

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

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

test harness －－測試用具
包含測試驅(qū)動和測試比較器的測試工具。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

truth table －－真值表
用于邏輯操作的一個操作表格。

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

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

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

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

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

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

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

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

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

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

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

第 140 貼【 2004 － 11 － 12 】：測試必須被計劃、被控制，并且被提供時間和資源

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

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

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

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

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

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

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

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

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

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

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

第 146 貼【 2004 － 11 － 22 】：測試自動化能解決一部分問題，但不是全部

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

第 147 貼【 2004 － 11 － 23 】：測試不能僅僅包括功能性的驗證，還需要包括非功能性的驗證

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

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

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

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

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

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

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

由一個獨立于開發(fā)的專業(yè)測試組來從事項目的測試是一個比較好的實踐，并且能有效解決上面的問題。

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

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

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

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

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

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。

免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

常見測試術(shù)語