功能測試的重點在哪兒？

　　說一下本人對功能測試的理解，關於功能測試重點在對被測系統的瞭解上。至於測試方法：等價類劃分、邊界值、錯誤推測、因果圖....等測試方法很容易理解。把這些方法應用到系統功能測試中也不難，關鍵是如何應用？這裡又引出了一個東東，叫“需求文件”？一個系統不是你想測什麼就測什麼？也不是你認為它是bug它就是bug的。

例如：一個登入，使用者名稱沒區分大小寫，我是用小寫註冊的，但是登入時，我用的大些卻可以登入，這算一個bug嗎？不是個人認為的是或不是的，要根據需求來判定。

 　　需求很重要，好吧！能得到一份完整或不變的需求對測試人員來說應該是一件很幸福的事兒？因為我們少去很多麻煩。好吧！假如一下我們得到了這麼一份需求。那我們是不是根據需求就開始對系統進行測試了呢？那麼這時開發人員還沒把產品整出來，那我們做什麼呢？要不想想我們測試什麼吧！？或怎麼對系統進行測試，做哪些驗證。這就引出來一個東東。叫“測試用例”。為什麼要寫測試用例？

想做好功能測試要做好四點：

1. 非常瞭解被測試系統，各個功能和各個業務邏輯。

2. 需求文件，如果你不知道怎麼測，那你一定沒看需求文件

3. 測試方法的學習，方法不難理解，如何運用到專案中是關鍵

4. 測試用例，在上面三點的基礎上寫用例，一個用例可以體現出你對上面三點的掌握程度

效能測試水很深！

　　很幸運剛進公司老大就讓我對公司系統做效能測試，那時學了幾天JMeter 、LoadRunner掌握一些基本操作就以為自己會做效能測試了，在此自我鄙視一下自己的無知。其實，效能測試的重點不在效能測試工具的學習上。天天看到群裡有人問，

　　當然，你也通過分析系統的壓力點、LR錄製指令碼，設定使用者，做壓力，分析結果，整理測試報告。完成了效能測試的整個過程。那麼我說這個效能測試報告是有效的，但它不一定是有用的。

　　為什麼說是有效的：因為在效能測試報告中，你把測試環境、測試工具、測試方法、測試結果都描述的很清楚。那麼這次效能測試就是有效的。在你所在的環境中，你是測出了這樣的效果。並未摻假，全部真實的記錄。

　　為什麼說它不一定是有用的，你瞭解系統架構麼？知道資料庫、中介軟體、前端程式的執行方式和處理機制麼？瞭解網路協議麼？瞭解作業系統麼？熟悉開發系統的語言麼？如java  JVM

為什麼要做自動化測試？

　　貌似好多人都在熱追自動化測試，貌似自動化測試比手工測試先進牛B。本人對自動化測試也沒什麼實際經驗，只是對QTP、selenium淺學了兩下。這裡也討論兩三句。

自動化測試無非就是用工具代替人對系統進行驗證，它如何知道怎麼驗證。這個要你一步一步教它。所以，自動化前期的投入很大。

什麼專案適合自動化？

　　需求變動小、專案週期長、可複用性高。如果不滿足這三個條件，你要掂量一下是否要對專案引入自動化。

那麼它的找bug能力呢？

　　我所瞭解在我的手工測試中，相當一部分bug並非我按照用例測出來的。有統計它只能找出來30%的bug。70%還是要靠手工測試。那投入那麼大，找bug能力都不強。為什麼還有那麼多公司試水，做自動化測試主要是在加入新的功能後保證已經功能的正確性。

那麼測試人員要不要學自動化測試呢？

　　我猶豫了很久還是覺得要。自動化測試畢竟是軟體測試的一個趨勢。從測試人員的自我技能的提升也一個方向。至於公司是否真的需要自動化測試，自動化測試是否得到很好的收益就另說的了。

下面是個人對一些問題的看法。

測試人員是否要懂程式碼？

懂是必須的，更客觀的說法，看下圖：

上圖是根據自己的理解所畫，根據你所做的測試工作不同，所要掌握的測試知識的多少不同。

我確認一點程式碼也不懂的測試人員，工作細心，認真的執行測試用例，也能把測試工作做好。那麼你的發展方向在那裡？你說可以做需求分析人員、質量管理人員。貌似在偏離軟體測試工作。想成為一個軟體測試高手，懂程式碼是必須的，我沒見過哪位測試高手或專家對程式碼是一竅不通的。

不懂開發的人員更能從使用者的角度測試？

見某測試人員云云，他們公司招測試人員專招非計算機不懂開發的測試人員來測試，公司的意思是這樣的人更能站在使用者的角度上去測試軟體。好吧！我不想再闡述測試人員不光只是測試介面的工作，也許你們公司就只測介面。我一直不理解有為什麼懂了計算機懂了開發就不能站在使用者的角度上去測試。非專業的人可以從非專業的角度和思路去非常規的測試點。我認為他也有可能找一些不是bug的bug去給開發人員添亂。

測試人員為什麼被“小看”？

可能和上個問題有關，看到好多測試人員在抱怨工資比開發人員低。被開發人員鄙視，不被公司重視。我想有相當一部分人不是學軟體測試專業的吧！？好點的是從培訓機構出來的，還有些是計算機專業開發知識不夠硬，轉做軟體測試的。還有一些是與計算機專業無關的也能來做軟體測試。

不得不說一般的測試工作伸縮性較大，如：功能測試，懂計算機的人員能做，不懂計算機的人員按裝測試用例也可進行。但你讓他開發個功能試試。不懂程式設計，肯定做不了。我只想學測試工作入門容易精通難，如果想做一個不被“小看”的測試人員只有提高自己的技術。

如果，你但找出了bug而且提出現這個bug的原因以及告訴開發人員到哪個地方去修復它。我想你會得到開發人員的尊重。如果，你能發現一個深入系統發現一個系統潛在的bug。而你這個bug有可能會公司造成重在損失。由於你的發現挽回了這些損失，那我想你會得到上司的尊重。

測試人員的目標是白盒測試？

　　好多測試人員把做白盒測試看為測試人員的終極目標。認為做白盒的測試人員是最牛的。

　　我們來分析一下一個常規的流程，一個開發人員需要了解需求，根據需求編寫某一功能程式碼。那麼白盒測試人員要對開發人員的功能程式碼進行單元測試。那麼他也需要了解這個功能需求，瞭解被測功能程式碼，寫白盒測試用例，他還需要保證測試用例程式碼的準確性，覆蓋率等等。這個過程的成本是很高的。

　　我不否認有Junit 、Qunit等測試框架可以提高測試效率。那麼我們經過白盒測試的功能程式碼是沒有問題的，就能保證整個系統沒有bug了。答案是否定的。那麼我們後續還要進行整合測試，介面測試、安全測試，這樣算下來測試成本要遠遠高於開發成本。對於測試團隊來說，不管是整體技術能力還是人員數量都要求很高。

對於一般公司的成本與收益來講，白盒測試由開發人員完成。因為沒有人比自己更瞭解自己所開發的程式碼。那麼開發人員如何做好對自己功能程式碼的單元測試？往下看

測試人員與開發人員的比例

　　相信這也是開發人員熱議的一個話題，最典型的就是拿微軟與谷歌來比較，微軟的測試人員與開發人員的比例是2：1 ，而谷歌測試人員與開發人員的比例為1：10 ；同樣是兩個牛X公司，為什麼會存在這麼大的差異呢？我想不會有人會認為谷歌的測試人員比微軟的牛得多，谷歌一個測試人員可以幹微軟二十個人的工作。

公司對測試人員的定位不同

　　微軟的測試員人叫“軟體測試開發工程師”，加上了“開發”二字，就不單單的測試黑盒那點事兒了。他們要做的事情兒很多。他們要設計測試計劃、開發測試自動化軟體、debug、調查研究問題。他們的測試工程師要與開發工程師一起，從產品定義(product definition)到產品開發(product development)再到產品維護(product servicing)，在整個產品生命週期中，不斷貢獻各種建議、測試文件以及測試資料。這麼龐大的工作量，不是少數測試人員能夠勝任的。

　　那麼谷歌呢？他們的測試人員又做些什麼。在Google，質量並不等於測試。“質量不是被測試出來的”，他們將測試與開發融合，做為一個開發人員，你必須對保證自己的所做工作的質量。我的感覺有點“全民皆兵”，一個全民皆兵的民族只能被全部消滅，不可能被打到。一個“全民皆測”的軟體公司還有什麼質量是保證不了的。當你上則所的時候，會發現牆上寫著“今天，你測了嗎？”哈哈！！

國內的測試國情

為什麼國內與國外同樣都是測試人員，差距咋就那麼大呢?這與我們國內的測試行業“國情”有關。微軟是做什麼產品的，一個嚴重的bug對他們造成的損失是不可估量的。當然微軟一開始也沒意識到測試的重要性，那都是在血和累的教訓中逐漸總結出來的。

反觀國內，有幾家公司是做微軟那種產品的，如果你們公司是給政府做專案的，因為某些單位做某些專案是為了讓“上面”撥款。其實，這某些單位用不用這個系統就另說了，只要上面檢查的時候有這個東西就成。你們懂的！！國內的大多數公司做的都是一些一般的專案，質量要求不高，營收入不高，能預算到測試的費用就更少了。所以，測試人員屬於配菜，不是主食。有測試人員大談後期維護成本可能存的風險。貪圖眼前利益的大有人在。淡定！國情！國情！