功能測試的重點(diǎn)在哪兒？

　　說一下本人對功能測試的理解，關(guān)于功能測試重點(diǎn)在對被測系統(tǒng)的了解上。至于測試方法：等價類劃分、邊界值、錯誤推測、因果圖....等測試方法很容易理解。把這些方法應(yīng)用到系統(tǒng)功能測試中也不難，關(guān)鍵是如何應(yīng)用？這里又引出了一個東東，叫“需求文檔”？一個系統(tǒng)不是你想測什么就測什么？也不是你認(rèn)為它是bug它就是bug的。

例如：一個登錄，用戶名沒區(qū)分大小寫，我是用小寫注冊的，但是登錄時，我用的大些卻可以登錄，這算一個bug嗎？不是個人認(rèn)為的是或不是的，要根據(jù)需求來判定。

 　　需求很重要，好吧！能得到一份完整或不變的需求對測試人員來說應(yīng)該是一件很幸福的事兒？因?yàn)槲覀兩偃ズ芏嗦闊?。好吧！假如一下我們得到了這么一份需求。那我們是不是根據(jù)需求就開始對系統(tǒng)進(jìn)行測試了呢？那么這時開發(fā)人員還沒把產(chǎn)品整出來，那我們做什么呢？要不想想我們測試什么吧?。炕蛟趺磳ο到y(tǒng)進(jìn)行測試，做哪些驗(yàn)證。這就引出來一個東東。叫“測試用例”。為什么要寫測試用例？http://www.cnblogs.com/fnng/archive/2011/09/10/2173149.html 在我的另一篇博文里有講。

想做好功能測試要做好四點(diǎn)：

1. 非常了解被測試系統(tǒng)，各個功能和各個業(yè)務(wù)邏輯。

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

3. 測試方法的學(xué)習(xí)，方法不難理解，如何運(yùn)用到項目中是關(guān)鍵

4. 測試用例，在上面三點(diǎn)的基礎(chǔ)上寫用例，一個用例可以體現(xiàn)出你對上面三點(diǎn)的掌握程度

性能測試水很深！

　　很幸運(yùn)剛進(jìn)公司老大就讓我對公司系統(tǒng)做性能測試，那時學(xué)了幾天JMeter 、LoadRunner掌握一些基本操作就以為自己會做性能測試了，在此自我鄙視一下自己的無知。其實(shí)，性能測試的重點(diǎn)不在性能測試工具的學(xué)習(xí)上。天天看到群里有人問，LR怎么用？又錄制不了腳本了。腳本回放有錯。如何設(shè)置XXX？為什么高手能用樹葉殺人呢？一般的小羅羅都在搶屠龍刀，倚天劍。以為得到了屠龍刀就是最牛B的人了。

　　當(dāng)然，你也通過分析系統(tǒng)的壓力點(diǎn)、LR錄制腳本，設(shè)置用戶，做壓力，分析結(jié)果，整理測試報告。完成了性能測試的整個過程。那么我說這個性能測試報告是有效的，但它不一定是有用的。

　　為什么說是有效的：因?yàn)樵谛阅軠y試報告中，你把測試環(huán)境、測試工具、測試方法、測試結(jié)果都描述的很清楚。那么這次性能測試就是有效的。在你所在的環(huán)境中，你是測出了這樣的效果。并未摻假，全部真實(shí)的記錄。

　　為什么說它不一定是有用的，你了解系統(tǒng)架構(gòu)么？知道數(shù)據(jù)庫、中間件、前端程序的運(yùn)行方式和處理機(jī)制么？了解網(wǎng)絡(luò)協(xié)議么？了解操作系統(tǒng)么？熟悉開發(fā)系統(tǒng)的語言么？如java  JVM的內(nèi)在機(jī)理知道么？這些都是系統(tǒng)運(yùn)行的一部分，都在影響著系統(tǒng)的性能。如果不了解這些，你如何做出有價值的有參考意義的性能測試。如果你的性能測試沒有參考意義，那不是自已在逗自己玩么。

為什么要做自動化測試？

　　貌似好多人都在熱追自動化測試，貌似自動化測試比手工測試先進(jìn)牛B。本人對自動化測試也沒什么實(shí)際經(jīng)驗(yàn)，只是對QTP、selenium淺學(xué)了兩下。這里也討論兩三句。

自動化測試無非就是用工具代替人對系統(tǒng)進(jìn)行驗(yàn)證，它如何知道怎么驗(yàn)證。這個要你一步一步教它。所以，自動化前期的投入很大。

什么項目適合自動化？

　　需求變動小、項目周期長、可復(fù)用性高。如果不滿足這三個條件，你要掂量一下是否要對項目引入自動化。

那么它的找bug能力呢？

　　我所了解在我的手工測試中，相當(dāng)一部分bug并非我按照用例測出來的。有統(tǒng)計它只能找出來30%的bug。70%還是要靠手工測試。那投入那么大，找bug能力都不強(qiáng)。為什么還有那么多公司試水，做自動化測試主要是在加入新的功能后保證已經(jīng)功能的正確性。

那么測試人員要不要學(xué)自動化測試呢？

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

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

測試人員是否要懂代碼？

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

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

我確認(rèn)一點(diǎn)代碼也不懂的測試人員，工作細(xì)心，認(rèn)真的執(zhí)行測試用例，也能把測試工作做好。那么你的發(fā)展方向在那里？你說可以做需求分析人員、質(zhì)量管理人員。貌似在偏離軟件測試工作。想成為一個軟件測試高手，懂代碼是必須的，我沒見過哪位測試高手或?qū)＜覍Υa是一竅不通的。

不懂開發(fā)的人員更能從用戶的角度測試？

見某測試人員云云，他們公司招測試人員專招非計算機(jī)不懂開發(fā)的測試人員來測試，公司的意思是這樣的人更能站在用戶的角度上去測試軟件。好吧！我不想再闡述測試人員不光只是測試界面的工作，也許你們公司就只測界面。我一直不理解有為什么懂了計算機(jī)懂了開發(fā)就不能站在用戶的角度上去測試。非專業(yè)的人可以從非專業(yè)的角度和思路去非常規(guī)的測試點(diǎn)。我認(rèn)為他也有可能找一些不是bug的bug去給開發(fā)人員添亂。

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

可能和上個問題有關(guān)，看到好多測試人員在抱怨工資比開發(fā)人員低。被開發(fā)人員鄙視，不被公司重視。我想有相當(dāng)一部分人不是學(xué)軟件測試專業(yè)的吧??？好點(diǎn)的是從培訓(xùn)機(jī)構(gòu)出來的，還有些是計算機(jī)專業(yè)開發(fā)知識不夠硬，轉(zhuǎn)做軟件測試的。還有一些是與計算機(jī)專業(yè)無關(guān)的也能來做軟件測試。

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

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

測試人員的目標(biāo)是白盒測試？

　　好多測試人員把做白盒測試看為測試人員的終極目標(biāo)。認(rèn)為做白盒的測試人員是最牛的。

　　我們來分析一下一個常規(guī)的流程，一個開發(fā)人員需要了解需求，根據(jù)需求編寫某一功能代碼。那么白盒測試人員要對開發(fā)人員的功能代碼進(jìn)行單元測試。那么他也需要了解這個功能需求，了解被測功能代碼，寫白盒測試用例，他還需要保證測試用例代碼的準(zhǔn)確性，覆蓋率等等。這個過程的成本是很高的。

　　我不否認(rèn)有Junit 、Qunit等測試框架可以提高測試效率。那么我們經(jīng)過白盒測試的功能代碼是沒有問題的，就能保證整個系統(tǒng)沒有bug了。答案是否定的。那么我們后續(xù)還要進(jìn)行集成測試，接口測試、安全測試，這樣算下來測試成本要遠(yuǎn)遠(yuǎn)高于開發(fā)成本。對于測試團(tuán)隊來說，不管是整體技術(shù)能力還是人員數(shù)量都要求很高。

對于一般公司的成本與收益來講，白盒測試由開發(fā)人員完成。因?yàn)闆]有人比自己更了解自己所開發(fā)的代碼。那么開發(fā)人員如何做好對自己功能代碼的單元測試？往下看

測試人員與開發(fā)人員的比例

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

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

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

http://www.cnblogs.com/fnng/archive/2011/09/06/2169206.html

　　那么谷歌呢？他們的測試人員又做些什么。在Google，質(zhì)量并不等于測試?！百|(zhì)量不是被測試出來的”，他們將測試與開發(fā)融合，做為一個開發(fā)人員，你必須對保證自己的所做工作的質(zhì)量。我的感覺有點(diǎn)“全民皆兵”，一個全民皆兵的民族只能被全部消滅，不可能被打到。一個“全民皆測”的軟件公司還有什么質(zhì)量是保證不了的。當(dāng)你上則所的時候，會發(fā)現(xiàn)墻上寫著“今天，你測了嗎？”哈哈?。?/p>

http://www./how-google-tests-software-part-three/

國內(nèi)的測試國情

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

反觀國內(nèi)，有幾家公司是做微軟那種產(chǎn)品的，如果你們公司是給政府做項目的，因?yàn)槟承﹩挝蛔瞿承╉椖渴菫榱俗尅吧厦妗睋芸?。其?shí)，這某些單位用不用這個系統(tǒng)就另說了，只要上面檢查的時候有這個東西就成。你們懂的?。鴥?nèi)的大多數(shù)公司做的都是一些一般的項目，質(zhì)量要求不高，營收入不高，能預(yù)算到測試的費(fèi)用就更少了。所以，測試人員屬于配菜，不是主食。有測試人員大談后期維護(hù)成本可能存的風(fēng)險。貪圖眼前利益的大有人在。淡定！國情！國情！

入測不深，思緒凌亂，不知所言。