如何做好和完善功能測(cè)試總結(jié)

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

今天boss問(wèn)我們對(duì)于公司當(dāng)前功能測(cè)試是否有完善意見(jiàn)，突然覺(jué)得這個(gè)話題離我們很近，卻總來(lái)沒(méi)深入總結(jié)過(guò)。還好要求明天上交報(bào)告，先在此做些總結(jié)，到時(shí)候拼裝下給boss.

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

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

A、有需求說(shuō)明，無(wú)設(shè)計(jì)文檔。

B、有需求分析文檔，快完成時(shí)臨時(shí)補(bǔ)充設(shè)計(jì)文檔。

C、有需求分析文檔和設(shè)計(jì)文檔。

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

這個(gè)時(shí)候測(cè)試務(wù)必要做到這點(diǎn)——爭(zhēng)取參加需求討論會(huì)議，不用發(fā)言，只要聽(tīng)就可以。因?yàn)檫@里沒(méi)有寫(xiě)文檔的習(xí)慣，很多測(cè)試標(biāo)準(zhǔn)、需求處理細(xì)點(diǎn)都會(huì)在口頭上體現(xiàn)，你得眼疾手快，參加會(huì)議很好的一點(diǎn)就是測(cè)試過(guò)程中，碰到不一致的地方，可以有足夠的重語(yǔ)氣讓開(kāi)發(fā)修改，因?yàn)槟阌凶C據(jù)，而不用去問(wèn)開(kāi)發(fā)這點(diǎn)是不是要改，如何實(shí)現(xiàn)。

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

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

開(kāi)發(fā)人員講解培訓(xùn)：這個(gè)很好的解決了由于沒(méi)設(shè)計(jì)文檔導(dǎo)致的測(cè)試不了解內(nèi)部，被動(dòng)，另外也是給開(kāi)發(fā)壓力，逼他們做單元和集成自測(cè)，從中測(cè)試也可以提問(wèn)，不要覺(jué)得這是浪費(fèi)時(shí)間，好處你試了才知道。我很壞，呵呵。

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

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

或許你們覺(jué)得讓測(cè)試參加會(huì)議，讓開(kāi)發(fā)講解這些有點(diǎn)難，但記住一點(diǎn)：做測(cè)試的一定要“主動(dòng)”。

在做功能測(cè)試過(guò)程中，經(jīng)常會(huì)碰到其他的問(wèn)題。例如：對(duì)于web，所用控件的ie兼容性，標(biāo)簽值顯示格式、長(zhǎng)度，提示信息風(fēng)格、內(nèi)容，按鈕大小，名稱等這些，當(dāng)前項(xiàng)目和開(kāi)發(fā)人員都習(xí)慣最后處理。更多時(shí)候測(cè)試跟開(kāi)發(fā)還不能達(dá)成一致，維護(hù)時(shí)還有“這是以前開(kāi)發(fā)人員弄的，當(dāng)前不予修改這些?！?

一些通用的界面要求可以定個(gè)標(biāo)準(zhǔn)并維護(hù)，這個(gè)初步難的話，在項(xiàng)目測(cè)試計(jì)劃里能注明下，并達(dá)成統(tǒng)一。這樣避免項(xiàng)目后期，開(kāi)發(fā)人員改動(dòng)，測(cè)試人員由于對(duì)工作負(fù)責(zé)又得全部測(cè)試一遍，減少工作量。

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