旁述：測試過程中如何應對頻繁的版本變更？對於這個問題，其實要視實際的情況，如企業、團隊、專案、產品、市場等等多個方面的因素，不能一概而論，所以，解決的辦法有多種。今天我沒有回答」如何應對「頻繁的版本變更這個問題，下面的內容，當作提醒，呵呵。
1、為什麼會有頻繁的變更？
2、多少變更可以集成為乙個「版本」？測試的物件如何確定？
3、從「應對」轉為「避免」
一、為什麼會有頻繁的變更？
1、首先需要解釋一下：
1.1 這裡所指的「變更」多數情況下理解為版本內容變更，即軟體產品內容需求的變更，而不是軟體配置管理中定義的」配置項(configuration item)"的變更。
1.2 這裡所指的「版本」是指軟體產品版本，並不是某個配置項（configuration item）的版本。
2、該問題的提出，主要原因應該是「需求」的變更過於頻繁。
3、需求的變更頻繁的原因有很多，比如商業合作計畫變更導致、使用者需求變更導致、產品定位和市場營銷變更導致等等。。。
二、多少變更可以集成為乙個「版本」？
1、並不是每次變更都需要構建成乙個「軟體版本」的。比如，昨天張三（程式設計師）改了乙個函式名稱，李四在今天上午加了乙個功能，王五在今天下午刪除了乙個介面按鈕。。。我們沒有必要對這三次在相臨的不同時間裡所做的變更分別構建和定義成三個版本。。。
2、「軟體版本」應該是有明確的原因或計畫的。如上述所說，對於相臨的不同的時間裡所做的多次變更並不需要分別構建不同的版本。那麼多少次變更、或者什麼時候才需要構建乙個版本出來呢？其實這就是「版本計畫」要管理和關注的了。版本計畫定義了有多少版本、每個版本的內容有什麼、版本的開發周期、版本的發布時間等等。近幾年，軟體行業好像在主推「敏捷開發」，「每日構建」（daily build）是敏捷開發的核心思想，每日構建放在我們討論的這個問題上，會出現什麼情況呢？我們是不是需要對每個daily build版本做一次「完整」的測試？答案當然是否定的！版本確認測試（build verification test）就是簡化版地測試活動。因為實際上，我們不太可能在人工測試的情況下每天測試乙個新的版本。所以，實際上，對於版本測試（基於可執行的和測試的版本），我們是需要花費一定的時間去做全面的測試的。這個時間段我們叫做【版本測試週期】，乙個版本的測試，需要乙個【版本測試週期】。有的版本需要2至3天完成測試，有的版本可能需要乙個月來完成測試。
三、從「應對」轉為「避免」
1、讓我們（特別是測試人員）感覺的版本變更頻繁的原因，主要有幾點：
1.1 需求變化過快、同時又急於發布。
1.2 測試時間不足，計畫中的測試方案沒有執行、測試用例沒有執行。
1.3 需求變更的成本過高（變更過程長、複雜，版本構建時間長）。
1.4 需求變更的提出、決定過程短，沒有多方協商，致使涉及到的人員沒有得到知會、沒有時間調整計畫。比如需求變更時沒有與開發團隊、測試團隊確認，產品/專案負責人在短時間內要求實現變更。致使開發團隊、測試團隊來不及調整開發、測試計畫。
軟體測試過程中的度量
在軟體測試過程中，可以將度量分為兩大類 1 衡量測試效率和測試工作量 工作量指標 例如，測試效率評價 測試進度s曲線等.2 從質量 的角度表明測試的結果 結果指標 例如，缺陷 數量 到達模式 系統崩潰和掛起的次數等.測試過程s曲線 追蹤測試過程也許是軟體測試階段管理中最重要的追蹤任務。建議的一種度量...
如何看待測試過程中的漏測發生
漏測，相信對於每個測試同學而言，都是 談虎變色 的事，但是實際工作中，我們稍有不謹慎便會和它來一次 親密接觸 那麼，現在我們來聊聊測試中的漏測。石頭中文網 www.10tou.com 一方面，會讓他人對你的技術 業務能力產生懷疑，而且發生多次後，甚至會質疑你存在的價值 另一方面，自己內心會很愧疚和自...
測試面試過程中的幾點困惑
最近在面試中遇到了很多困惑和無奈，筆者總結了幾條，與諸君分享。順便也談談筆者對面試的一些淺解。困惑二 我覺得 怪圈。很多人在面試的溝通中，非常喜歡用 我覺得 來開始回答問題。因為我比較喜歡用非常具體的場景來提問，那麼在該場景中按照邏輯上來講，必然存在著確切的因果關係或特定的解決方法。如果一切都是 我...