立項後測試需要拿到的文檔

1、需求說明書

2、原型圖（及UI圖）

3、介面文檔

4、資料庫字典（表的數量、緩存機制）

需求評審

參加人員：開發、測試及需求人員，由需求人員主持講解。

為了會議的有效舉行，測試及開發人員需要在會議開始之前熟悉需求文檔及原型，將有疑問 的點標註出來在會議中一一確認，對不明確的點要督促開發及需求一併關注，對不能立馬得到肯定回復的點記錄在一起，會議結束後，郵件整理好發出給各位參與的人員。

在項目可控的進度中，需求評審時必要的環節。當然，有些比較小的項目會忽略此階段，個人認為這是非常有必要的環節，這不但減少了後期開發、測試、需求人員的意見分歧，保證項目的進度的必要手段。

用例編寫（同時根據開發計劃編寫測試計劃）

用例功能類型

所在就職部門將用例分成7類：

1、主流程：該模塊實現的主要功能流程。

2、備選流：不一定完成執行一個功能，而是終止了流程。

3、異常流：由於某些異常原因，使流程的功能無法實現。

4、業務規則：必填項，強制的要求。

5、正常類：返回功能、必填項輸入範圍、頁面按鈕的切換等。

6、異常類：網路異常、返回異常等。

7、界面檢查：針對每個頁面的樣式及內容檢查。

註：幾個大類中主流程、正常類、異常類、和界面檢查四個大類使用的比較多，一個項目不需要涵蓋所有的用例類別，只需要根據所在項目的實際情況來進行測試用例的分類即可。

編寫用例可在TestLink及excel上進行，一般會在TestLink上進行，小項目會比較習慣用excel進行，excel記錄測試用例的欄位有：

用例編號、功能模塊、功能類型、用例等級、用例描述、前置條件、數據、測試步驟、預期結果、客戶端、執行結果、備註、設計人、執行人等

用例編寫注意點：

1、儘可能結合用例設計方法設計測試用例

2、不要只根據需求文檔明確標出的需求編寫用例，還需要多考慮一些衍生的場景；

3、用例編寫前，先畫出整個功能的煎藥流程圖；

4、用例描述簡潔且帶有結果，不要重複贅述；

5、用例步驟和預期結果要一致，且一個步驟對應一個預期結果。

測試用例的編寫方法

1、等價類劃分

2、邊界值分析法

3、錯誤推斷法

4、因果分析法

5、場景法

用例評審

參與人員：開發、測試、需求人員、項目經理，由測試人員主導。

此環節在開發完成功能之前進行，根據評審時提的點進行用例完善，完善後郵件發給參與人員。

在項目組中，更多情況下測試比開發會更瞭解需求，專業決定我們對需求的理解是肯定更接近客戶的，我們的對需求理解後的輸出產物是測試用例，某種意義上講用例是對需求細化的一種。 而開發對需求理解會更偏向於功能實現，產物就是程序。所以開發、測試經常會存在需求理解不一致的情況，開發也不會那麼細緻的去理解需求，這點相信所有的項目經理和需求分析都是有共鳴的：

我們做測試用例評審的作用有但不侷限於以下3點：

1、統一開發、測試、需求三方對需求的理解

2、幫組開發更細緻的去理解需求、同時養成看需求的習慣

3、需求分析人員在一定程度上對需求的理解也是有盲點的，通過評審可以挖出這些盲點（需求評審的作用也是一樣）

4、測試人員的能力和經驗不一樣，所有用例也會有差異性，通過評審可以指出我們遺漏的場景，從而能更好的保障咱們的項目質量

5、在用例評審時，很多交互設計上的問題，前後臺交互的問題等都會暴露

6、如果測試用例在開發完成前進行評審，很多時候開發人員即使不去看需求說明書，只要他認真的參加了用例評審會，基本上也不會出現遺漏需求，需求實現偏差太大的情況了.因為你要去每個開發人員那麼仔細的去看需求，短時間內是不太可能的。用例評審是這個過渡期的橋樑。

一般可根據計劃時間完成用例編寫，中間會預留1天給他們看需求。在評審每一個模塊的用例之前，會明確點名這幾個人要注意，在評審的過程中，問開發一些問題,不是隻單純的講用例,他們可以不看需求，但是我會提問一下,們要同時提升開發人員的參與感。

測試執行

showcase測試：

測試到開發的電腦上進行，主要執行一下關鍵測試用例、流程用例，由開發操作，測試人員一起查看。showcase不通過，則打回，郵件發出。

冒煙測試：

showcase測試通過後，提交到測試，由測試人員開始大量跑關鍵測試用例。若針對某個模塊跑用例時，出現較多問題，則也可重新打回給開發。

未完待續……

來源：51Testing軟體測試網

更多精彩內容請關注微信公眾號「Testin」