国产成人久久精品激情,久久精品国产影库免费看,久久―日本道色综合久久

常見測試術語

SLA －－服務級別協議（ service level agreement ）
服務提供商與客戶之間的一個協議，用于規定服務提供商應當提供什么服務。

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

software development process －－軟件開發過程? ?? ?? ?
一個把用戶需求轉換為軟件產品的開發過程。

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

software element －－軟件元素? ?? ?? ?
軟件開發或維護期間產生或獲得的一個可交付的或過程內的文檔。

software engineering －－軟件工程? ?? ?? ?
一個應用于軟件開發、操作和維護的系統性的、有紀律的、可量化的方法。

software engineering environment －－軟件工程環境? ?? ?? ?
執行一個軟件工程工作的硬件、軟件和固件。

software life cycle －－軟件生命周期? ?? ?? ?
開始于一個軟件產品的構思，結束于該產品不再被使用的這段期間。

SOP －－標準操作過程（ standard operating procedures ）
書面的步驟，這對保證生產和處理的控制是必須的。

source code －－源代碼? ?? ?? ?
用一種適合于輸入到匯編器、編譯器或其它轉換設備的計算機指令和數據定義。

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

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

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

specified input －－指定的輸入? ?? ?? ?
一個輸入，根據規格能預知其輸出。

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

SQL －－結構化查詢語句（ structured query language ）
在一個關系數據庫中查詢和處理數據的一種語言。

state －－狀態? ?? ?? ?
一個系統、組件或模擬可能存在其中的一個條件或模式。

state diagram －－狀態圖? ?? ?? ?
一個圖形，描繪一個系統或組件可能假設的狀態，并且顯示引起或導致一個狀態切換到另一個狀態的事件或環境。

state transition －－狀態轉換? ?? ?? ?
一個系統或組件的兩個允許狀態之間的切換。

state transition testing? ?? ???－－狀態轉換測試? ?? ?? ?
根據狀態轉換來設計測試用例的一種方法。

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

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

statement testing －－語句測試? ?? ?? ?
根據語句覆蓋來設計測試用例的一種方法。

Static Analysis －－靜態分析? ?? ?? ?
分析一個程序的執行，但是并不實際執行這個程序。

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

Static Analyzer －－靜態分析器? ?? ?? ?
進行靜態分析的工具。

Static Testing －－靜態測試? ?? ?? ?
不通過執行來測試一個系統。

statistical testing －－統計測試? ?? ?? ?
通過使用對輸入統計分布進行分析來構造測試用例的一種測試設計方法。

stepwise refinement －－逐步優化? ?? ?? ?
一個結構化軟件設計技術，數據和處理步驟首先被廣泛的定義，然后被逐步的進行了細化。

storage testing －－存儲測試? ?? ?? ?
驗證系統是否滿足指定存儲目標的測試。

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

structural coverage －－結構化覆蓋? ?? ?? ?
根據組件內部的結構度量覆蓋率。

structural test case design －－結構化測試用例設計? ?? ?? ?
根據組件內部結構的分析來設計測試用例的一種方法。

structural testing －－結構化測試? ?? ?? ?
參考結構化測試用例設計（ structural test case design ）

structured basis testing －－結構化的基礎測試? ?? ?? ?
根據代碼邏輯設計測試用例來獲得 100 ％分支覆蓋的一種測試用例設計技術。

structured design －－結構化設計? ?? ?? ?
軟件設計的任何遵循一定紀律的方法，它按照特定的規則，例如：模塊化，有頂向下設計，數據逐步優化，系統結構和處理步驟。

structured programming －－結構化編程? ?? ?? ?
在結構化程序開發中的任何包含結構化設計和結果的軟件開發技術。

structured walkthrough －－結構化走讀? ?? ?? ?
參考走讀（ walkthrough ）

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

stub －－樁? ?? ?? ?
一個軟件模塊的框架或特殊目標實現，主要用于開發和測試一個組件，該組件調用或依賴這個模塊。

symbolic evaluation －－符號評價? ?? ?? ?
參考符號執行（ symbolic execution ）

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

symbolic trace －－符號軌跡? ?? ?? ?
一個計算機程序通過符號執行是經過的語句分支結果的一個記錄。

syntax testing －－語法分析? ?? ?? ?
根據輸入語法來驗證一個系統或組件的測試用例設計技術。

system analysis －－系統分析? ?? ?? ?
對一個計劃的或現實的系統進行的一個系統性調查以確定系統的功能以及系統與其它系統之間的交互。

system design －－系統設計? ?? ?? ?
一個定義硬件和軟件構架、組件、模塊、接口和數據的過程以滿足指定的規格。

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

System Testing －－系統測試? ?? ?? ?
從一個系統的整體而不是個體上來測試一個系統，并且該測試關注的是規格，而不是系統內部的邏輯。

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

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

test automation －－測試自動化? ?? ?? ?
使用工具來控制測試的執行、結果的比較、測試預置條件的設置、和其它測試控制和報告功能。

test case －－測試用例? ?? ?? ?
用于特定目標而開發的一組輸入、預置條件和預期結果。

test case design technique －－測試用例設計技術? ?? ?? ?
選擇和導出測試用例的技術。

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

test comparator －－測試比較器? ?? ?? ?
一個測試工具用于比較軟件實際測試產生的結果與測試用例預期的結果。

test completion criterion －－測試完成標準? ?? ?? ?
一個標準用于確定被計劃的測試何時完成。

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

test driver －－測試驅動? ?? ?? ?
一個程序或測試工具用于根據測試套執行軟件。

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

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

test execution －－測試執行? ?? ?? ?
一個測試用例被被測軟件執行，并得到一個結果。

test execution technique －－測試執行技術? ?? ?? ?
執行測試用例的技術，包括手工、自動化等。

test generator －－測試生成器? ?? ?? ?
根據特定的測試用例產生測試用例的工具。

test harness －－測試用具? ?? ?? ?
包含測試驅動和測試比較器的測試工具。

test log －－測試日志? ?? ?? ?
一個關于測試執行所有相關細節的時間記錄。

test measurement technique －－測試度量技術? ?? ?? ?
度量測試覆蓋率的技術。

Test Plan －－測試計劃? ?? ?? ?
一個文檔，描述了要進行的測試活動的范圍、方法、資源和進度。它確定測試項、被測特性、測試任務、誰執行任務，并且任何風險都要沖突計劃。

test procedure －－測試規程? ?? ?? ?
一個文檔，提供詳細的測試用例執行指令。

test records －－測試記錄? ?? ?? ?
對每個測試，明確的記錄被測組件的標識、版本，測試規格，和實際結果

test report －－測試報告? ?? ?? ?
一個描述系統或組件執行的測試和結果的文檔。

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

Test Specification －－測試規格? ?? ?? ?
一個文檔，用于指定一個軟件特性、特性組合或所有特性的測試方法、輸入、預期結果和執行條件。

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

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

test suite －－測試套? ?? ?? ?
測試用例和 / 或測試腳本的一個集合，與一個應用的特定功能或特性相關。

test target －－測試目標? ?? ?? ?
一組測試完成標準。

testability －－可測試性? ?? ?? ?
一個系統或組件有利于測試標準建立和確定這些標準是否被滿足的測試執行的程度。

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

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

time sharing －－時間共享? ?? ?? ?
一種操作方式，允許兩個或多個用戶在相同的計算機系統上同時執行計算機程序。其實現可能通過時間片輪轉、優先級中斷等。

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

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

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

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

traceability matrix －－跟蹤矩陣? ?? ?? ?
一個用于記錄兩個或多個產品之間關系的矩陣。例如，需求跟蹤矩陣是跟蹤從需求到設計再到編碼的實現。

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

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

transform analysis －－事務分析? ?? ?? ?
系統的結構是根據分析系統需要處理的事務獲得的一種分析技術。
trojan horse －－特洛伊木馬? ?? ?? ?
一種攻擊計算機系統的方法，典型的方法是提供一個包含具有攻擊性隱含代碼的有用程序給用戶，在用戶執行該程序的時候，其隱含的代碼對系統進行非法訪問，并可能產生破壞。

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

Unit Testing －－單元測試? ?? ?? ?
測試單個的軟件組件，屬于白盒測試范疇，其測試基礎是軟件內部的邏輯。

Usability Testing －－可用性測試? ?? ?? ?
測試用戶使用和學習產品的容易程度。

validation －－確認? ?? ?? ?
根據用戶需要確認軟件開發的產品的正確性。

verification －－驗證? ?? ?? ?
評價一個組件或系統以確認給定開發階段的產品是否滿足該階段開始時設定的標準。

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

volume testing －－容量測試? ?? ?? ?
使用大容量數據測試系統的一種策略。

Walkthrough －－走讀? ?? ?? ?
一個針對需求、設計或代碼的非正式的同行評審，一般由作者發起，由作者的同行參與進行的評審過程。

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

White Box Testing －－白盒測試? ?? ?? ?
根據軟件內部的工作原理分析來進行測試。

第 139 貼【 2004 － 11 － 11 】：測試是一個持續進行的過程，而不是一個階段

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

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

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

第 141 貼【 2004 － 11 － 15 】：測試應該有重點

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

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

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

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

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

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

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

第 145 貼【 2004 － 11 － 19 】：測試人員應當站在公正的立場上進行測試

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

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

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

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

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

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

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

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

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

第 150 貼【 2004 － 11 － 26 】：對質量要求較高的產品或大型復雜的產品成立獨立的測試組

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

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

第 151 貼【 2004 － 11 － 29 】：在每個開發階段，使用質量評價標準

許多項目看上去都進行的非常不錯，但到它們進入集成測試和系統測試后，這時，甚至一個簡單的測試都無法運行起來。如何避免這種現象的產生呢？一個好的方法是盡早測試，并且在每個階段上通過測試數據來評價其是否能通過階段的質量標準。當你堅持使用測試來分階段證明每一個特性或對象被完成，那么你就能保證各階段的設計和代碼被真正的按照質量要求完成。

第 152 貼【 2004 － 11 － 30 】：開發和維護一個測試需求和目標的風險優先級列表

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

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

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

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: 用例驅動的需求過程實踐特性、用例、需求－－ Rational軟件白皮書用例的需求分析-讀書筆記 Bug databases Performance test tools C++單元測試工具列表軟件測試相關的６３個國外站點微軟的軟件測試方法（二）微軟的軟件測試方法常見測試術語

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

牽著老婆滿街逛

導航

統計

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

工具官網

技術網站

開源網站

其他窩點

收藏網站

銀行官網

友情鏈接

資源共享

搜索

積分與排名

最新評論

閱讀排行榜

常見測試術語