在測試行業(yè)飛速發(fā)展的今天，越來越多的人和企業(yè)重視軟件測試。測試行業(yè)的發(fā)展掀起了大眾學習測試的浪潮。

很多新人，在各種論壇學習時，經(jīng)常會看到的是大家在熱火朝天的討論著各種測試理論及測試工具，什么黑盒測試，白盒測試，功能測試，性能測試，回歸測試，自動化測試，什么winrunner，loadrunner，Testdirector，Quicktestpro……

可能也因為這個原因，導致有的人一聽說別人是做測試，喜歡問的第一個問題就是，你們測試是做白盒測試還是黑盒測試？或者就是，你們測試用什么工具呢？

也許他們認為：如果測試人員只會黑盒測試，而不會使用幾種測試工具，不會用寫測試腳本，不會做白盒測試，就算不上一名專業(yè)的測試人員。

而我要說得是，作為測試人員，功能測試是一切測試的基礎，它就像if語句是開發(fā)的基礎一樣，做不好功能測試，不管你會使用多少工具，不管你的測試腳本寫的多么出神入化，你的測試工作都是不可能做好的。

而功能測試僅僅是黑盒測試。

我大學畢業(yè)后在一家軟件公司上班。從程序員開始做起。

對應屆畢業(yè)生剛進公司，這家公司的特點是不會馬上安排你做開發(fā)工作，而是先從測試開始做。這個時候，我接觸了軟件測試。

初期的測試很簡單，給你一個產(chǎn)品，點點這個按鈕，按按那個圖標，從這邊輸入一些數(shù)據(jù)，在那邊看看輸出是否正確等等。

也許沒有真正做過測試，或者說沒有做過一個項目完整的功能測試的人，就會片面的認為所謂的“功能測試”和“黑盒測試”就是這樣，給你一個產(chǎn)品，點點這個按鈕，按按那個圖標，這邊輸入一些數(shù)據(jù)，在那邊看看輸出是否正確。

而功能測試僅僅是這樣嗎？上面描述的這種功能測試頂多能算個單元功能測試。

功能測試的重點不在單元測試，測試人員做單元的功能測試頂多是幫助開發(fā)人員調(diào)試調(diào)試產(chǎn)品而已。

功能測試的難點和重點都在項目的集成測試和系統(tǒng)測試。

舉個簡單的例子來說明一下：

一個客戶需求：

公司部門人員考核情況混亂，無法在月底得到每個人每一項績效考核分數(shù)及總分數(shù)。希望解決的問題：

建立公司人員管理。

建立考核項管理。

員工績效考核分數(shù)查詢。

解決方案：建立公司人員管理，建立考核項管理，建立分數(shù)檔案。將人員管理、考核項管理和分數(shù)管理關聯(lián)起來。

設計：

數(shù)據(jù)庫：建3個主表，人員管理表，考核類型管理表，分數(shù)總結表，將3個表關聯(lián)起來。

數(shù)據(jù)訪問層：對表的訪問及處理方式（增加，刪除，修改等）

業(yè)務處理層：界面，數(shù)據(jù)的錄入，各種業(yè)務處理。

項目的功能測試

一．首先設計項目測試計劃。測試計劃內(nèi)容包括：

1.測試時間，測試階段劃分

2.測試進度及人員安排

3.測試環(huán)境，測試資源（測試方法，測試工具等）

二．然后設計項目測試用例。項目需求分析結束后，進行測試用例書寫，用例內(nèi)容包括以下部分：（功能測試重點）

檢查是否實現(xiàn)了公司人員管理。

如果滿足了人員管理，那么在這個人員管理中，是否所有的數(shù)據(jù)都能夠正確處理。是否所有錯誤數(shù)據(jù)都能合理處理。

如果沒有滿足，那么還有哪些地方需要補充。

檢查是否建立了考核項的管理。

如果有考核項的管理，那么是否所有的管理數(shù)據(jù)是否能夠正確處理，是否所有的錯誤數(shù)據(jù)都能合理處理。

如果沒有滿足，那么還有哪些地方需要補充。

檢查這個產(chǎn)品是否建立了分數(shù)檔案管理

如果分數(shù)檔案進行了統(tǒng)一管理，那么所有的數(shù)據(jù)是否正確處理了，是否所有的錯誤數(shù)據(jù)也合理處理了。

如果沒有滿足，那么還有哪些地方需要補充。

檢查各個模塊之間的關聯(lián)是否都正確。（難點）

例如：

當某一員工考核項里面分數(shù)變化后，員工分數(shù)統(tǒng)計表里面分數(shù)是否也重新計算了。

當客戶要求業(yè)務全面能夠滿足后。

檢查產(chǎn)品的各種業(yè)務流程中的輸入輸出是否都是正確，各種錯誤輸入都能夠正確處理。

進入各個界面檢查。

檢查各個頁面的布局是否合理，界面是否友好

按鈕等等是否能夠正常使用

輸入輸出是否正確

操作是否簡易等等

……

三．按照測試計劃，測試用例實施測試。

首先根據(jù)測試用例檢查產(chǎn)品的設計、實現(xiàn)是否能滿足客戶的要求，可根據(jù)需求追蹤矩陣制作的checklist進行檢查。

然后實施測試用例：

除了執(zhí)行上面已經(jīng)寫好的測試用例外，實施測試用例還有個難點是設計測試數(shù)據(jù)。（因為測試數(shù)據(jù)等跟產(chǎn)品的設計，產(chǎn)品結構等有很大的關系，所以測試數(shù)據(jù)只能在產(chǎn)品已經(jīng)成形后，才能具體設計。）

四．發(fā)現(xiàn)問題后，記錄BUG，并跟蹤，并根據(jù)修改及影響情況，進行回歸測試。

（這一點項，任何測試都是一樣的。而且也是非常重要的，在這里我也不詳細解釋了，詳細對BUG記錄及BUG跟蹤進行講解的文檔也是非常多了，包括缺陷管理工具。）

這就是一個項目功能測試的基本流程。

上面所描述的也只是項目功能測試的冰山一角。真正實施起來時，還有很多的細節(jié)需要處理，比如：如何才能寫一個合理的測試計劃；如何合理安排測試進度；測試用例用什么形式寫；發(fā)現(xiàn)了BUG怎么進行匯報和跟蹤；什么情況下需要做大量的回歸測試等等。

舉這個例子就是想糾正一些人的錯誤觀點。

功能測試這樣的黑盒測試一點都不簡單。

它要求對需求和業(yè)務有非常深刻的理解。同時最好要有軟件開發(fā)知識或編寫代碼的經(jīng)驗，能理解產(chǎn)品的設計，實現(xiàn)的過程。最后很重要的是，能夠根據(jù)需求和設計實現(xiàn)，寫出好的用例，構思出合適的測試數(shù)據(jù)來找出產(chǎn)品中的錯誤。這些是測試的基礎，方法和工具是測試的輔助手段。

測試做的好壞也并不是你會寫代碼，你會做白盒測試，你會做使用好多好多種工具，你就能好測試了。測試的基礎一定是功能測試，如果你連產(chǎn)品的功能，業(yè)務流程等都不能夠完整的理解，那么你的測試是不可能做好的。

當然，也并不是只要會做功能測試就一切ok了。

如果永遠只會做功能測試，只會做黑盒測試，不會白盒測試，不會寫測試腳本，不會使用工具，那么你的測試道路只會越走越窄。寫測試腳本，使用工具等都是提高測試水平很好的方法，但是前提是要有好的基矗

最后建議一下測試新人，剛?cè)胄袝r，不要盲目的學習各種各樣的工具及寫漂亮的測試腳本。學這些肯定是有用的，但是要分清主次。測試初期，首先要練習自己的基本功：比如如何寫“測試計劃”，如何去理解一個產(chǎn)品的設計原理，業(yè)務流程，如何寫“測試用例”，怎么設計測試數(shù)據(jù)。再學習些開發(fā)的知識，能理解產(chǎn)品的一些重要設計和實現(xiàn)原理等。

這些都學的比較扎實后，再去考慮學習工具和各種各樣的測試方式來提升自己。

相信通過這樣的學習模式，你的測試道路會越走越寬，越走越好～

請聯(lián)系網(wǎng)站客服，了解詳細的優(yōu)惠課程信息~

優(yōu)質(zhì)、權威、便捷、省心