boss問我們對于公司當前功能測試是否有完善意見，突然覺得這個話題離我們很近，卻總來沒深入總結過。還好要求明天上交報告，先在此做些總結，到時候拼裝下給boss.

　　接觸測試三年了，從測試工程師到測試組長兼sepg，然后跳槽繼續測試工程師。一路下來都在跟需求跟業務打交道。做好測試首先要做好需求、理解業務，這個不用多說了，相信很多人都總結過。當然也聽到過一些言論“換單位了，那業務不是沒用了”，換單位后，業務沒用這是必然的，我也是從易制毒換到當前的稅務，但有一點都是跟政府行業，其實我們要做的是摸索和總結如何快速獲取和掌握新業務，內容不同，但方法是可以通用的。

　　對于需求處理，我接觸的有以下三種情況。

　　A、有需求說明，無設計文檔。

　　B、有需求分析文檔，快完成時臨時補充設計文檔。

　　C、有需求分析文檔和設計文檔。

　　A這種情況一般分工不是很明確的小團隊都會出現，需求來源為客戶或者區域客服（特點是太簡單了沒經過提取，或者太自我了，很難實現），這時候在不規范的過程也會弄一次需求討論。這個時候測試務必要做到這點??爭取參加需求討論會議，不用發言，只要聽可以。因為這里沒有寫文檔的習慣，很多測試標準、需求處理細點都會在口頭上體現，你得眼疾手快，參加會議很好的一點是測試過程中，碰到不一致的地方，可以有足夠的重語氣讓開發修改，因為你有證據，而不用去問開發這點是不是要改，如何實現。

　　B這種情況其實是頭痛的，在時間緊和維護項目中經常出現。軟件需求功能在界面上都實現了，但開發只是考慮實現需求，卻沒有把需求與當前業務（其他模塊的邏輯），后臺數據處理（例如某個字段更新）這些弄好。因為功能測試時，測試人員大都會跑流程或者數據庫測試，這時候模糊無標準的問題來了，頭痛。另外一些開發人員會以功能實現，進入測試、或者邊設計邊改，測試大工作量了。這個時候測試有這些可以扭轉一些局面??版本驗收流程、開發人員給測試人員培訓。版本驗收：像前面提出的，設計不全面等，很容易導致只完成需求，破壞了原有功能或流程功能，在拿到版本后，進行初步的重要流程驗收，可以減少很多測試工作量。開發人員講解培訓：這個很好的解決了由于沒設計文檔導致的測試不了解內部，被動，另外也是給開發壓力，逼他們做單元和集成自測，從中測試也可以提問，不要覺得這是浪費時間，好處你試了才知道。我很壞，呵呵。

　　C這種情況一般實行Cmmi3之后的企業都很規范。這里我講下自己的幾個方法，更好的理解需求：模塊間邏輯圖、數據流向圖、需求用例矩陣。模塊間邏輯圖：其實usecase圖、流程圖，只要能讓自己摸清楚模塊間的業務聯系即可，為自己的業務測試用例做準備。數據流向圖：目的是搞清楚，該某塊功能涉及哪些表、存儲過程，數據表見關系如何，其實有點像數據庫模型的小型版，很多問題在界面上實現了，但后臺sql處理卻有錯誤。例矩陣這個主要是對覆蓋率進行校驗，其實是一個execl，針對某個需求點有哪些用例。這些文檔我稍后上轉。另外在閱讀需求時，多寫一些為什么（例如：文檔上寫著某輸入框有默認值，那你注明下：默認值可以修改嗎？）

　　或許你們覺得讓測試參加會議，讓開發講解這些有點難，但記住一點：做測試的一定要“主動”。

　　在做功能測試過程中，經常會碰到其他的問題。例如：對于web，所用控件的ie兼容性，標簽值顯示格式、長度，提示信息風格、內容，按鈕大小，名稱等這些，當前項目和開發人員都習慣后處理。更多時候測試跟開發還不能達成一致，維護時還有“這是以前開發人員弄的，當前不予修改這些。” 一些通用的界面要求可以定個標準并維護，這個初步難的話，在項目測試計劃里能注明下，并達成統一。這樣避免項目后期，開發人員改動，測試人員由于對工作負責又得全部測試一遍，減少工作量。

　　功能測試，先抓主干，在測分支這是恒定的原則。但如何完善功能測試這個值得討論，測試前如何分析需求，編寫用例，測試通過準則。測試中確定測試版本，選擇用例，測試優先級。項目后期的測試分析，用例優化等等。