軟件功能測試準備

　　軟件功能測試準備 軟件測試

　　了解業務需求。這個說簡單也簡單，就是參加立項會，然后看看PRD和UC。但是同時，這個也是一個復雜的過程，從單薄的PRD和UC中獲取自己最有用的信息是最考驗個人的能力的。

　　我記得羅仲濤上次說過，UC是開發人員整理自己的思路，同時呢也是為了讓測試人員通過評審他的UC，將UC與PRD分離，讓項目變得更加直觀和細化。那么PRD和UC是開發和測試人員理解項目的基礎，也是項目日后開發的藍本。

　　了解業務需求對于開發人員和測試人員同樣重要。我一直有一個想法，讓開發和測試共同參與UC的編寫，開發的同學從項目實現的角度，而測試同學可以從用戶使用的角度共同繪制這個項目的圖譜。這個會對測試同學的要求會比較高啦。

　　不過就目前的情況，我在熟悉UC的時候，比較喜歡將一個個原型圖片前后聯系起來，然后假設執行這個頁面，會跳轉到哪個頁面，然后流程性的東西都串起來了。至少大方向不會有錯誤。而因為我們對這些的了解，說不定會在評審的時候提出更多屬于自己的想法，要不就感覺被開發牽著鼻子在走，開發說要這么做，好吧，我默認就這么做。目前在評審UC的時候比較側重于每個頁面，每個功能的講評，關于流程性的講述倒比較少。

　　詳細的測試設計，測試設計我覺得越詳細越好，最好把我們所能發掘的信息點都表示在上面，這樣我們在編寫測試用例的時候就可以參照我們的測試設計，而不是繼續從UC和PRD上找出校驗點。另外呢，在畫設計圖的時候，我們也可以借此約束自己合理利用設計的時間。

　　在這次項目中，我測試設計圖有兩種類型：一種是流程類的設計圖，有開始的實心圓點，有結束的同心圓點，中間由若干個動作和判斷分值組成。這種設計圖我們在大學里都有學過，但是這次項目中，前臺都是展示型的頁面，與用戶幾乎沒有交互，所要校驗的也都是一些細節性的東西。此類設計圖，應該橫向畫，用方框型的狀態圖表示一個頁面，然后可以從這個頁面中橫向的拉出若干個校驗模塊，對每一個模塊又可以分出若干個校驗點。如此細分下去，不過此類設計圖因為不是流程性的，是以只有開始的點，而沒有結束的點，其他的畫法和第一類流程圖相似。

原文轉自：http://www.anti-gravitydesign.com