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

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

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

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

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

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

　　A這種情況一般分工不是很明確的小團(tuán)隊(duì)都會(huì)出現(xiàn)，需求來源為客戶或者區(qū)域客服（特點(diǎn)是太簡(jiǎn)單了沒經(jīng)過提取，或者太自我了，很難實(shí)現(xiàn)），這時(shí)候在不規(guī)范的過程也會(huì)弄一次需求討論。這個(gè)時(shí)候測(cè)試務(wù)必要做到這點(diǎn)??爭(zhēng)取參加需求討論會(huì)議，不用發(fā)言，只要聽可以。因?yàn)檫@里沒有寫文檔的習(xí)慣，很多測(cè)試標(biāo)準(zhǔn)、需求處理細(xì)點(diǎn)都會(huì)在口頭上體現(xiàn)，你得眼疾手快，參加會(huì)議很好的一點(diǎn)是測(cè)試過程中，碰到不一致的地方，可以有足夠的重語氣讓開發(fā)修改，因?yàn)槟阌凶C據(jù)，而不用去問開發(fā)這點(diǎn)是不是要改，如何實(shí)現(xiàn)。

　　B這種情況其實(shí)是頭痛的，在時(shí)間緊和維護(hù)項(xiàng)目中經(jīng)常出現(xiàn)。軟件需求功能在界面上都實(shí)現(xiàn)了，但開發(fā)只是考慮實(shí)現(xiàn)需求，卻沒有把需求與當(dāng)前業(yè)務(wù)（其他模塊的邏輯），后臺(tái)數(shù)據(jù)處理（例如某個(gè)字段更新）這些弄好。因?yàn)楣δ軠y(cè)試時(shí)，測(cè)試人員大都會(huì)跑流程或者數(shù)據(jù)庫測(cè)試，這時(shí)候模糊無標(biāo)準(zhǔn)的問題來了，頭痛。另外一些開發(fā)人員會(huì)以功能實(shí)現(xiàn)，進(jìn)入測(cè)試、或者邊設(shè)計(jì)邊改，測(cè)試大工作量了。這個(gè)時(shí)候測(cè)試有這些可以扭轉(zhuǎn)一些局面??版本驗(yàn)收流程、開發(fā)人員給測(cè)試人員培訓(xùn)。版本驗(yàn)收：像前面提出的，設(shè)計(jì)不全面等，很容易導(dǎo)致只完成需求，破壞了原有功能或流程功能，在拿到版本后，進(jìn)行初步的重要流程驗(yàn)收，可以減少很多測(cè)試工作量。開發(fā)人員講解培訓(xùn)：這個(gè)很好的解決了由于沒設(shè)計(jì)文檔導(dǎo)致的測(cè)試不了解內(nèi)部，被動(dòng)，另外也是給開發(fā)壓力，逼他們做單元和集成自測(cè)，從中測(cè)試也可以提問，不要覺得這是浪費(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ǔ)過程，數(shù)據(jù)表見關(guān)系如何，其實(shí)有點(diǎn)像數(shù)據(jù)庫模型的小型版，很多問題在界面上實(shí)現(xiàn)了，但后臺(tái)sql處理卻有錯(cuò)誤。例矩陣這個(gè)主要是對(duì)覆蓋率進(jìn)行校驗(yàn)，其實(shí)是一個(gè)execl，針對(duì)某個(gè)需求點(diǎn)有哪些用例。這些文檔我稍后上轉(zhuǎn)。另外在閱讀需求時(shí)，多寫一些為什么（例如：文檔上寫著某輸入框有默認(rèn)值，那你注明下：默認(rèn)值可以修改嗎？）

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

　　在做功能測(cè)試過程中，經(jīng)常會(huì)碰到其他的問題。例如：對(duì)于web，所用控件的ie兼容性，標(biāo)簽值顯示格式、長(zhǎng)度，提示信息風(fēng)格、內(nèi)容，按鈕大小，名稱等這些，當(dāng)前項(xiàng)目和開發(fā)人員都習(xí)慣后處理。更多時(shí)候測(cè)試跟開發(fā)還不能達(dá)成一致，維護(hù)時(shí)還有“這是以前開發(fā)人員弄的，當(dāng)前不予修改這些！ 一些通用的界面要求可以定個(gè)標(biāo)準(zhǔn)并維護(hù)，這個(gè)初步難的話，在項(xiàng)目測(cè)試計(jì)劃里能注明下，并達(dá)成統(tǒng)一。這樣避免項(xiàng)目后期，開發(fā)人員改動(dòng)，測(cè)試人員由于對(duì)工作負(fù)責(zé)又得全部測(cè)試一遍，減少工作量。

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