如何做好和完善功能測試總結

功能測試(Functional testing )，也稱為behavioral testing(行為測試)，根據(jù)產品特征、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。

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

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

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

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

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

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

A這種情況一般分工不是很明確的小團隊都會出現(xiàn)，需求來源為客戶或者區(qū)域客服(特點是太簡單了沒經過提取，或者太自我了，很難實現(xiàn))，這時候在不規(guī)范的過程也會弄一次需求討論。

這個時候測試務必要做到這點——爭取參加需求討論會議，不用發(fā)言，只要聽就可以。因為這里沒有寫文檔的習慣，很多測試標準、需求處理細點都會在口頭上體現(xiàn)，你得眼疾手快，參加會議很好的一點就是測試過程中，碰到不一致的地方，可以有足夠的重語氣讓開發(fā)修改，因為你有證據(jù)，而不用去問開發(fā)這點是不是要改，如何實現(xiàn)。

B這種情況其實是最頭痛的，在時間緊和維護項目中經常出現(xiàn)。軟件需求功能在界面上都實現(xiàn)了，但開發(fā)只是考慮實現(xiàn)需求，卻沒有把需求與當前業(yè)務(其他模塊的邏輯)，后臺數(shù)據(jù)處理(例如某個字段更新)這些弄好。因為功能測試時，測試人員大都會跑流程或者數(shù)據(jù)庫測試，這時候模糊無標準的問題就來了，頭痛。

另外一些開發(fā)人員就會以功能實現(xiàn)，進入測試、或者邊設計邊改，測試就大工作量了。這個時候測試有這些可以扭轉一些局面——版本驗收流程、開發(fā)人員給測試人員培訓。版本驗收：像前面提出的，設計不全面等，很容易導致只完成需求，破壞了原有功能或流程功能，在拿到版本后，進行初步的重要流程驗收，可以減少很多測試工作量。

開發(fā)人員講解培訓：這個很好的解決了由于沒設計文檔導致的測試不了解內部，被動，另外也是給開發(fā)壓力，逼他們做單元和集成自測，從中測試也可以提問，不要覺得這是浪費時間，好處你試了才知道。我很壞，呵呵。

C這種情況一般實行Cmmi3之后的企業(yè)都很規(guī)范。這里我講下自己的幾個方法，更好的理解需求：模塊間邏輯圖、數(shù)據(jù)流向圖、需求用例矩陣。模塊間邏輯圖：其實就usecase圖、流程圖，只要能讓自己摸清楚模塊間的業(yè)務聯(lián)系即可，為自己的業(yè)務測試用例做準備。數(shù)據(jù)流向圖：目的是搞清楚，該某塊功能涉及哪些表、存儲過程，數(shù)據(jù)表見關系如何，其實有點像數(shù)據(jù)庫模型的小型版，很多問題在界面上實現(xiàn)了，但后臺sql處理卻有錯誤。例矩陣這個主要是對覆蓋率進行校驗，其實就是一個execl，針對某個需求點有哪些用例。

這些文檔我稍后上轉。另外在閱讀需求時，多寫一些為什么(例如：文檔上寫著某輸入框有默認值，那你注明下：默認值可以修改嗎?)

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

在做功能測試過程中，經常會碰到其他的問題。例如：對于web，所用控件的ie兼容性，標簽值顯示格式、長度，提示信息風格、內容，按鈕大小，名稱等這些，當前項目和開發(fā)人員都習慣最后處理。更多時候測試跟開發(fā)還不能達成一致，維護時還有“這是以前開發(fā)人員弄的，當前不予修改這些?！?

一些通用的界面要求可以定個標準并維護，這個初步難的話，在項目測試計劃里能注明下，并達成統(tǒng)一。這樣避免項目后期，開發(fā)人員改動，測試人員由于對工作負責又得全部測試一遍，減少工作量。

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