這篇總結推遲了好久，一直想在工作一年之後寫一篇總結，由于各種瑣事以及感覺想法的不成熟，一推再推。這兩天尤為強烈，不管怎樣都應該把這一年多測試工作學到的知識和想法記錄下來。
軟體測試行業在國内發展時間較短，每個公司對軟體測試公司的定位和工作内容也不經相同。本人隻在一個公司從事測試工作并時間不長，如有偏見歡迎指正，不勝感激。^_^!!
功能測試的重點在哪兒？
說一下本人對功能測試的了解，關于功能測試重點在對被測系統的了解上。至于測試方法：等價類劃分、邊界值、錯誤推測、因果圖....等測試方法很容易了解。把這些方法應用到系統功能測試中也不難，關鍵是如何應用？這裡又引出了一個東東，叫“需求文檔”？一個系統不是你想測什麼就測什麼？也不是你認為它是bug它就是bug的。
例如：一個登入，使用者名沒區分大小寫，我是用小寫注冊的，但是登入時，我用的大些卻可以登入，這算一個bug嗎？不是個人認為的是或不是的，要根據需求來判定。
需求很重要，好吧！能得到一份完整或不變的需求對測試人員來說應該是一件很幸福的事兒？因為我們少去很多麻煩。好吧！
假如一下我們得到了這麼一份需求。那我們是不是根據需求就開始對系統進行測試了呢？那麼這時開發人員還沒把産品整出來，那我們做什麼呢？要不想想我們測試
想做好功能測試要做好四點：
1. 非常了解被測試系統，各個功能和各個業務邏輯。
2. 需求文檔，如果你不知道怎麼測，那你一定沒看需求文檔
3. 測試方法的學習，方法不難了解，如何運用到項目中是關鍵
4. 測試用例，在上面三點的基礎上寫用例，一個用例可以展現出你對上面三點的掌握程度
性能測試水很深！
很幸運剛進公司老大就讓我對公司系統做性能測試，那時學了幾天jmeter 、loadrunner掌握一些基本操作就以為自己會做性能測試了，在此自我鄙視一下自己的無知。其實，性能測試的重點不在性能測試工具的學習上。天天看到群裡有人問，lr怎麼用？又錄制不了腳本了。腳本回放有錯。如何設定xxx？為什麼高手能用樹葉殺人呢？一般的小羅羅都在搶屠龍刀，倚天劍。以為得到了屠龍刀就是最牛b的人了。
當然，你也通過分析系統的壓力點、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)，在整個産品生命周期中，不斷貢獻各種建議、測試文檔以及測試資料。這麼龐大的工作量，不是少數測試人員能夠勝任的。
<a href="http://www.cnblogs.com/fnng/archive/2011/09/06/2169206.html">http://www.cnblogs.com/fnng/archive/2011/09/06/2169206.html</a>
那麼谷歌呢？他們的測試人員又做些什麼。在google，品質并不等于測試。“品質不是被測試出來的”，他們将測試與開
發融合，做為一個開發人員，你必須對保證自己的所做工作的品質。我的感覺有點“全民皆兵”，一個全民皆兵的民族隻能被全部消滅，不可能被打到。一個“全民
皆測”的軟體公司還有什麼品質是保證不了的。當你上則所的時候，會發現牆上寫着“今天，你測了嗎？”哈哈！！
<a href="http://www.aqee.net/how-google-tests-software-part-three/">http://www.aqee.net/how-google-tests-software-part-three/</a>
國内的測試國情
為什麼國内與國外同樣都是測試人員，差距咋就那麼大呢?這與我們國内的測試行業“國情”有關。微軟是做什麼産品的，一個嚴重的bug對他們造成的損失是不可估量的。當然微軟一開始也沒意識到測試的重要性，那都是在血和累的教訓中逐漸總結出來的。
反觀國内，有幾家公司是做微軟那種産品的，如果你們公司是給政府做項目的，因為某些機關做某些項目是為了讓“上面”撥款。其
實，這某些機關用不用這個系統就另說了，隻要上面檢查的時候有這個東西就成。你們懂的！！國内的大多數公司做的都是一些一般的項目，品質要求不高，營收入
不高，能預算到測試的費用就更少了。是以，測試人員屬于配菜，不是主食。有測試人員大談後期維護成本可能存的風險。貪圖眼前利益的大有人在。淡定！國情！
國情！
入測不深，思緒淩亂，不知所言。