如何做好和完善功能測試總結(jié)
功能測試(Functional testing )，也稱為behavioral testing（行為測試），根據(jù)產(chǎn)品特征、操作描述和用戶方案，測試一個產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計需求。
今天boss問我們對于公司當(dāng)前功能測試是否有完善意見，突然覺得這個話題離我們很近，卻總來沒深入總結(jié)過。還好要求明天上交報告，先在此做些總結(jié)，到時候拼裝下給boss.
接觸測試三年了，從測試工程師到測試組長兼sepg，然后跳槽繼續(xù)測試工程師。一路下來都在跟需求跟業(yè)務(wù)打交道。做好測試首先要做好需求、理解業(yè)務(wù)，這個不用多說了，相信很多人都總結(jié)過。當(dāng)然也聽到過一些言論“換單位了，那業(yè)務(wù)不是沒用了”，換單位后，業(yè)務(wù)沒用這是必然的，我也是從易制毒換到當(dāng)前的稅務(wù)，但有一點都是跟政府行業(yè)，其實我們要做的是摸索和總結(jié)如何快速獲取和掌握新業(yè)務(wù)，內(nèi)容不同，但方法是可以通用的。
對于需求處理，就我接觸的有以下三種情況。
A、有需求說明，無設(shè)計文檔。
B、有需求分析文檔，快完成時臨時補充設(shè)計文檔。
C、有需求分析文檔和設(shè)計文檔。
A這種情況一般分工不是很明確的小團隊都會出現(xiàn)，需求來源為客戶或者區(qū)域客服（特點是太簡單了沒經(jīng)過提取，或者太自我了，很難實現(xiàn)），這時候在不規(guī)范的過程也會弄一次需求討論。
這個時候測試務(wù)必要做到這點——爭取參加需求討論會議，不用發(fā)言，只要聽就可以。因為這里沒有寫文檔的習(xí)慣，很多測試標(biāo)準(zhǔn)、需求處理細點都會在口頭上體現(xiàn)，你得眼疾手快，參加會議很好的一點就是測試過程中，碰到不一致的地方，可以有足夠的重語氣讓開發(fā)修改，因為你有證據(jù)，而不用去問開發(fā)這點是不是要改，如何實現(xiàn)。
B這種情況其實是最頭痛的，在時間緊和維護項目中經(jīng)常出現(xiàn)。軟件需求功能在界面上都實現(xiàn)了，但開發(fā)只是考慮實現(xiàn)需求，卻沒有把需求與當(dāng)前業(yè)務(wù)（其他模塊的邏輯），后臺數(shù)據(jù)處理（例如某個字段更新）這些弄好。因為功能測試時，測試人員大都會跑流程或者數(shù)據(jù)庫測試，這時候模糊無標(biāo)準(zhǔn)的問題就來了，頭痛。
另外一些開發(fā)人員就會以功能實現(xiàn)，進入測試、或者邊設(shè)計邊改，測試就大工作量了。這個時候測試有這些可以扭轉(zhuǎn)一些局面——版本驗收流程、開發(fā)人員給測試人員培訓(xùn)。版本驗收：像前面提出的，設(shè)計不全面等，很容易導(dǎo)致只完成需求，破壞了原有功能或流程功能，在拿到版本后，進行初步的重要流程驗收，可以減少很多測試工作量。
開發(fā)人員講解培訓(xùn)：這個很好的解決了由于沒設(shè)計文檔導(dǎo)致的測試不了解內(nèi)部，被動，另外也是給開發(fā)壓力，逼他們做單元和集成自測，從中測試也可以提問，不要覺得這是浪費時間，好處你試了才知道。我很壞，呵呵。
C這種情況一般實行Cmmi3之后的企業(yè)都很規(guī)范。這里我講下自己的幾個方法，更好的理解需求：模塊間邏輯圖、數(shù)據(jù)流向圖、需求用例矩陣。模塊間邏輯圖：其實就usecase圖、流程圖，只要能讓自己摸清楚模塊間的業(yè)務(wù)聯(lián)系即可，為自己的業(yè)務(wù)測試用例做準(zhǔn)備。數(shù)據(jù)流向圖：目的是搞清楚，該某塊功能涉及哪些表、存儲過程，數(shù)據(jù)表見關(guān)系如何，其實有點像數(shù)據(jù)庫模型的小型版，很多問題在界面上實現(xiàn)了，但后臺sql處理卻有錯誤。例矩陣這個主要是對覆蓋率進行校驗，其實就是一個execl，針對某個需求點有哪些用例。
這些文檔我稍后上轉(zhuǎn)。另外在閱讀需求時，多寫一些為什么（例如：文檔上寫著某輸入框有默認值，那你注明下：默認值可以修改嗎？）
或許你們覺得讓測試參加會議，讓開發(fā)講解這些有點難，但記住一點：做測試的一定要“主動”。
在做功能測試過程中，經(jīng)常會碰到其他的問題。例如：對于web，所用控件的ie兼容性，標(biāo)簽值顯示格式、長度，提示信息風(fēng)格、內(nèi)容，按鈕大小，名稱等這些，當(dāng)前項目和開發(fā)人員都習(xí)慣最后處理。更多時候測試跟開發(fā)還不能達成一致，維護時還有“這是以前開發(fā)人員弄的，當(dāng)前不予修改這些。”
一些通用的界面要求可以定個標(biāo)準(zhǔn)并維護，這個初步難的話，在項目測試計劃里能注明下，并達成統(tǒng)一。這樣避免項目后期，開發(fā)人員改動，測試人員由于對工作負責(zé)又得全部測試一遍，減少工作量。
功能測試，先抓主干，在測分支這是恒定的原則。但如何完善功能測試這個值得討論，測試前如何分析需求，編寫用例，測試通過準(zhǔn)則。測試中確定測試版本，選擇用例，測試優(yōu)先級。項目后期的測試分析，用例優(yōu)化等等。
【編輯推薦】
