我們什麼時候停止我們的專案?我們應該在我們達到目標的時候停止。可是，目標是什麼?aaron認為所謂目標，即測試應該實現的可度量
的要求，這個東西更常見的叫法——測試停止標準。
不知道有沒有程式設計師
會笑話偶說：我們專案就是乙個測試人員
在點點，甚至不要測試人員點點我們也可以順利交付給客戶很有用的產品;不知道有沒有測試人員會講：我們測試的時候除了用例
之外什麼都沒有，更不用說什麼無聊的測試停止標準 ! 不過aaron告訴你，真要在專案裡面有了這麼個東西，只會對大家都好。你想，測試停止標準就是那可以止渴的「梅」，有了它咱就有了奮鬥的方向，有了等到出頭之日的盼頭。同時因為一些專案組中測試標準也會作為版本發布標準——儘管這兩者還是有區別的——所以測試停止標準對於開發
人員和pm也是有用的。
當然，並不是所有的測試停止標準都會有這般功效，在我看來，乙個合格的測試停止標準應該滿足一下條件：
在計畫階段盡早訂立測試停止標準
沒有規矩不成方圓，先定下規矩可以幫助我們一開始就計畫的時候就在畫著「方圓」，而不是等畫了一點點之後才發現用的「規矩」不是標準版的，那樣浪費了時間。
測試停止標準應該獲得專案負責人的確認
這一條尤其適用於並不是那麼和諧的專案組以及習慣優柔寡斷的專案負責人領導的專案組。還要注意口說無憑，所以立字為據有時候也是需要的~我們的目的是要使規矩「定」下來。
對於這一條，存在這兩個風險：
一是容易導致不和諧：如果專案負責人簽了，感覺像是兄弟們在給他上枷鎖似的，更像是把一些責任推到他的身上去了。(因為存在這樣一種情況，大家訂立乙個規矩，可是後來做的東西讓top leader不滿意，普通組員這個時候好歹還可以推說我們組的規矩是這樣做的，不需要問，當時簽字確認的專案負責人這下子責任就大了。)
二是因為需求
變化，因為測試停止標準要求滿足可度量性(具體內容在後文詳談)，所以可能會涉及到比較細緻的東西，比如某個核心模組應該怎麼樣才算行——如果在後期需求變了，會不得不更改「定」下來的測試停止標準了。
對於這些風險的預防和處理，aaron雖然有些心得，但是考慮到各個作坊情況不一樣，在此就不誤導各位了。
測試停止標準應該是可度量的
aaron看來，對於測試停止標準，「可度量」這個要求是必需的，用抽象的語言來描述測試停止標準是無意義的。如在測試停止標準裡面出現「在適當的時間停止測試」這句話是不對的，所謂「合適的時間」這類詞彙，要麼讓人不解其意，要麼出現「一千個觀眾眼中有一千個哈姆萊特」這種情況，因此乙個準確的定義是必需的。
測試停止標準都是可以達到的
這個很容易理解，如果標準裡面出現了要我們三五個人十來杆搶在乙個月內造乙個跟windows
xp一模一樣的作業系統給客戶，那定這個標準的人怕是跟aaron前天一樣sb了~測試停止標準之中切忌出現不可能實現的或者很難達到的目標，比如在測試停止標準裡面出現「修復所有的bug
」這種條文，我們就要考慮實際情況中我們是否可能修復所有的bug，專案的要求是否如此嚴格——所有的bug都必須修復，而不是被處理(修復，延遲並報告等處理方式)，是否允許部分bug推遲修復?
測試停止標準的檢查者
測試停止標準作為乙個驗收標準，還需要明確規定標準執法者。沒有規矩不成方圓，但是有了規矩而不執行，也是成不了「方圓」的，所以需要執法者或者說**者，在這裡體現為檢查和核實我們的測試是否達到了標準。有時候，為了表示民主，大家一起說了算在人數不多的專案組也是乙個可取的方式。
前面講了自己的一些理解，但看著過於抽象，所以就繼續具體點講一下。開發
人員貼code，俺這邊沒code，只好貼幾張便簽紙 ……
測試標準應該包含的內容：
● 有效測試用例
(功能)執行率達到x%?
●單元測試
**行覆蓋率達到x%?
●單元測試用例
通過率x%?
● 單元測試用例設計
通過評審
● 核心模組(a,;b,d等模組)測試覆蓋
● 所發現缺陷均納入缺陷管理
系統
● 優先順序最高的bug
全部修復
● 其他bug全部被處理(修復，延遲並報告等處理方式)
●功能測試
用例模組，功能點覆蓋率達到?
按照測試型別來的測試停止標準：
比如單元測試活動在滿足以下所有條件之後可停止：
● 核心模組**100% 經過code review
● 單元測試用例設計通過評審
● 測試用例執行率100%
● 最新版本的單元測試通過率為100%
● 單元測試全域性**行覆蓋率不低於80%
●單元測試
單個模組**行覆蓋率不低於70%
● 單元測試中被測單元發現的bug
產生率不低於3個/千行**
● 所有發現缺陷
都納入缺陷追蹤系統
● 優先順序1類bug全部被修復
● 優先順序2，3類bug全部被處理(修復或者不處理並明確在測試報告指出且獲得通過)
● 完成了單元測試報告並通過評審
實際工作中會出現的停止「標準」
測試活動在滿足下列條件之一時需要暫停或者終止：
● 新的需求
變更過大，測試活動應暫停，待需求定義穩定後繼續;
● 測試超過了預定時間，且測試時間不可能繼續增加的情況下應停止測試;
● 測試成本增高(bug
發現率低於1個/周，此時所發現缺陷低於預定義的上限);
● 若開發
暫停，則相應測試也應暫停，並備份暫停點資料;
● 軟體系統通過驗收測試
;
● 軟體專案在其開發生命週期內出現重大估算
和進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點資料;
● 專案負責人申明停止專案;
● 團隊集體(開發，管理，測試，市場，銷售人員)同意停止專案(因市場及利益等原因);
上面幾張便簽來自網路
和個人實踐，只是摘選部分，切不可直接拿來作模板，否則鄙人就有誤人子弟的罪過了~這幾張便簽紙並不能直接幫助讀者建立起乙個適合自己專案的「測試停止標準」，相信大家都有這樣的能力。我將測試停止標準扯到計畫測試系列的目的，是要提醒讀者在計畫的時候就要有看到我們的結果的眼光。專案也好，測試過程
也好，都是以結果為導向的，沒有最後的成功，中間過程即使很完美，對於專案(產品)自身是沒有任何意義的(大多數情況下，專案成員在吞食失敗的挫折感的同時，至少還收穫了經驗，所以可能還會有人會享受失敗專案中的「美好的過程」)。
什麼時候我們考慮使用指令碼
指令碼的架構 指令碼宿主 在其中執行 iis,ie,wsh wscript,cscript 指令碼引擎 解釋程式 windows作業系統內建的 vbscript 與jscript 指令碼可以呼叫的物件模型 wsh,wmi,adsi,ado,cdo等 wsh 可以呼叫com物件，使用命令列，呼叫she...
我們什麼時候需要函式隱藏
technorati 標籤 c new,方法隱藏 肖建的一篇博文引發了我的思考。我們應該什麼時候使用函式隱藏 new關鍵字，不明白的請移步msdn public class base public class a base public class b base public class testc...
我們什麼時候應該使用動態記憶體
我講解一下c語言中動態分配記憶體的函式，可能有些初學c語言的人不免要問了 我們為什麼要通過函式來實現動態分配記憶體呢？系統難道不是會自動分配記憶體嗎？既然有人會問這樣的問題，那麼我在這裡好好的講解一下吧！首先讓我們熟悉一下計算機的記憶體吧！在計算機的系統中有四個記憶體區域 1 棧 在棧裡面儲存一些我...