黑盒測試和白盒測試(軟件測試能報(bào)名嗎)

軟件測試現(xiàn)在算是還不錯(cuò)的一個(gè)崗位，現(xiàn)在行業(yè)里也有很多培訓(xùn)機(jī)構(gòu)在做軟件測試工程師方面的培訓(xùn)。如果對測試崗位有興趣的話，還是可以報(bào)名參加培訓(xùn)，未來也有這樣的機(jī)會。

測試工程師相對于程序員來說，門檻會稍微低一點(diǎn)點(diǎn)，但是未來的發(fā)展空間還是挺大的，而且要做精了，還是很有難度。從最初級的黑盒測試到白盒測試，然后進(jìn)階到自動化測試。未來其實(shí)測試工程師還是會和代碼有很深度的接觸。

至于測試能夠干到多少歲，這個(gè)其實(shí)沒有一個(gè)嚴(yán)格的標(biāo)準(zhǔn)，要看個(gè)人的身體素質(zhì)和知識水平了。可能知識水平大家都能夠理解，也就是能力強(qiáng)，自然就能夠走得比較久。不過，身體素質(zhì)是什么標(biāo)準(zhǔn)？

其實(shí)，在IT行業(yè)有一個(gè)沒有明說的潛規(guī)則，就是測試的時(shí)間是最可能被壓縮的。

可能對軟件工程有點(diǎn)了解的人都知道，簡單來說，軟件研發(fā)的過程包括需求分析設(shè)計(jì)->系統(tǒng)設(shè)計(jì)->編碼->測試->上線。當(dāng)然，測試又分為了幾個(gè)階段，這里就不去再拆分了。而測試作為系統(tǒng)上線前的最后一個(gè)階段，常常會成為項(xiàng)目周期緊張時(shí)被壓縮的對象。

也就是說，原計(jì)劃4月1日提測，5月1日上線，但是由于需求的變化，程序員呼呲呼呲的加班改功能，大呼4月1日不可能提測，做不完，然后測試的時(shí)間也就被壓縮了。而這個(gè)時(shí)候如果你認(rèn)為程序員給你的就是可以流暢的進(jìn)行測試的版本，那就大錯(cuò)特錯(cuò)了。中間可能出現(xiàn)各種各樣阻礙你測試用例執(zhí)行的情況，最終結(jié)果就是，上線時(shí)間是推不了的，測試就來個(gè)007吧。

所以，擁有強(qiáng)健的身體，是做測試所必備的要素。當(dāng)然，程序員也是一樣的，只是程序員的坑可以留到測試階段，但是測試的坑留到上線，那就會變成一口鍋?zhàn)屓吮沉恕?/p>

個(gè)人的核心競爭力與所在行業(yè)發(fā)展的趨勢，以及隨著行業(yè)及相關(guān)行業(yè)的發(fā)展對從業(yè)者提出的要求應(yīng)該是有著直接關(guān)系的。

比如，十年前與現(xiàn)在相比，測試人員的核心競爭力已經(jīng)發(fā)生了明顯的變化。

隨著敏捷、類敏捷、Devops等模式的引入，系統(tǒng)架構(gòu)由單體架構(gòu)到SOA再到微服務(wù)等架構(gòu)的發(fā)展，以及數(shù)據(jù)治理、人工智能的應(yīng)用，軟件交付周期逐漸縮短，技術(shù)復(fù)雜度不斷提升，對測試人員提出了越來越高的要求。

軟件測試行業(yè)的發(fā)展現(xiàn)狀

我們可以先了解一下測試行業(yè)的發(fā)展趨勢以及隨著相關(guān)行業(yè)的發(fā)展，對測試人員提出了哪些要求，我想若我們達(dá)到了未來發(fā)展的要求，那么這就是具備競爭力的體現(xiàn)。

之前寫過《2018年度軟件測試行業(yè)現(xiàn)狀報(bào)告》的解讀，其中有總結(jié)以下幾點(diǎn)：

測試人員對需求分析的投入在逐漸增大，同時(shí)測試人員逐漸開始注重客戶問題的分析，更關(guān)注用戶體驗(yàn)和用戶反饋。敏捷和類敏捷型項(xiàng)目已經(jīng)占到了已經(jīng)極高的百分比，而DevOps模式的使用已經(jīng)持續(xù)數(shù)年穩(wěn)定增長，DevOps正在成為軟件交付的最佳模式 ， 同時(shí)我們發(fā)現(xiàn)瀑布或類瀑布開發(fā)模式比重逐漸降低。較去年，自動化測試技術(shù)比例基本保持穩(wěn)定且處在一個(gè)高占比的狀態(tài)。不了解、不使用自動化的越來越少。同時(shí)令人興奮的是，發(fā)現(xiàn)越來越多的測試人員將自動化技術(shù)應(yīng)用于日志和數(shù)據(jù)分析、綜合監(jiān)測。

敏捷及DevOps模式的應(yīng)用，對測試人員提出了不同于以往的要求（以前測試基本上都在開發(fā)階段之后和產(chǎn)品上線之前完成），使得測試人員在開發(fā)階段之前加大了對需求分析等測試分析和設(shè)計(jì)（測試左移）、同時(shí)不斷提高自動化測試技術(shù)的投入和應(yīng)用、促使測試技術(shù)多樣化（如，日志和數(shù)據(jù)分析，產(chǎn)品質(zhì)量運(yùn)營）發(fā)展（測試右移）。

同時(shí)，敏捷一直強(qiáng)調(diào)“團(tuán)隊(duì)為質(zhì)量負(fù)責(zé)”，測試不再是測試人員的專屬，這里我們需要重新思考下，質(zhì)量由整個(gè)團(tuán)隊(duì)負(fù)責(zé)，那么測試的價(jià)值如何更好的體現(xiàn)——如何提高測試效率。

DevOps模式更是對測試、尤其是自動化測試、編碼能力提出了更高的要求。

在這樣的行業(yè)發(fā)展背景和趨勢之下，我們不難得出 測試逐漸向測試開發(fā)過渡 已經(jīng)是一種潛在或者顯在的趨勢，無論我們決定將來走技術(shù)路線還是管理路線。

若我們現(xiàn)在具備如上所說的測試開發(fā)能力，那么至少我們是具備競爭力的。

這里需要注意的是具備了一定的開發(fā)基礎(chǔ) 并不等同于 能夠做好測試，之所有測試開發(fā)成為一種趨勢，是因?yàn)樵诰邆鋬?yōu)秀測試設(shè)計(jì)等測試能力的基礎(chǔ)上，若具備一定開發(fā)能力和思維的測試人員，能夠更好的從質(zhì)量、效率、風(fēng)險(xiǎn)、成本之間尋求一種平衡。

什么是核心競爭力

什么是核心競爭力，我個(gè)人認(rèn)為核心競爭力一定程度可以理解為不可替代性，所做的事情或者所具備的能力是否可以能被大部分人替代，這就是 是否具備核心競爭力的一個(gè)重要體現(xiàn)。

相對于測試而言，核心競爭力可以是在某一領(lǐng)域的專業(yè)性深度足夠深。

比如性能測試，曾在一次互聯(lián)網(wǎng)測試開發(fā)大會上，看見過某位前輩講到過的一個(gè)案例：在定位某個(gè)性能問題時(shí)，挖掘到操作系統(tǒng)內(nèi)核的深度，并且發(fā)現(xiàn)是因操作系統(tǒng)內(nèi)核缺陷導(dǎo)致的性能風(fēng)險(xiǎn)，這個(gè)定位問題的過程及結(jié)果就是測試專業(yè)性深度的體現(xiàn)。

也可以是具備一定的測試廣度，并且能夠根據(jù)不同場景靈活適當(dāng)?shù)膶⑵淙诤系揭黄穑龅劫|(zhì)量、成本、效率、風(fēng)險(xiǎn)的平衡。

比如產(chǎn)品迭代初期，一方面產(chǎn)品初步成形，需求變更頻繁、功能穩(wěn)定性差，同時(shí)受到客戶和市場壓力，往往迭代時(shí)間緊張，此時(shí)對于測試要解決的就是質(zhì)量與效率平衡問題，自然而然想到自動化測試，然而這個(gè)時(shí)候自動化是不是合適的呢，顯然自動化初期投入到項(xiàng)目的確能起到效率提升的目的，但隨著迭代發(fā)展，會出現(xiàn)什么情況？需求變更引入的自動化維護(hù)成本，如果此時(shí)業(yè)務(wù)測試不具備測試開發(fā)能力，那么這個(gè)維護(hù)成本將變的更高，本來就項(xiàng)目時(shí)間緊張，自動化維護(hù)工作自然而然就變的力不從心，由此，一兩個(gè)版本迭代之后，自動化測試就慢慢淡出了視野之外。一般來講，需求度量一般要從最原始的需求開始，比如迭代初期項(xiàng)目時(shí)間緊，考慮到版本穩(wěn)定性，通常不會選擇自動化測試（除非自動化的開展或重構(gòu)成本非常的低），而是從需求優(yōu)先級、質(zhì)量目標(biāo)、測試覆蓋等角度，對測試廣度、測試深度進(jìn)行測試策略設(shè)計(jì)，優(yōu)先保障核心功能質(zhì)量。這也是很多公司對測試開發(fā)的要求是首先要懂測試、然后懂開發(fā)的原因，能夠?qū)I(yè)務(wù)測試遇到的問題提出適合的技術(shù)解決方案，避免盲目開展自動化、工具開發(fā)，導(dǎo)致“藥不對癥”。

雖然我認(rèn)為核心競爭力一定程度可以理解為不可替代性，但并不意味著封閉，反而要有更加的開放思想，幫助團(tuán)隊(duì)測試人員提升基礎(chǔ)能力水平，提升他們對測試的理解和認(rèn)識。進(jìn)一步思考測試技術(shù)能力的水平賦能和流程能力建設(shè)，這對我們的發(fā)展有著更大的幫助，也是我們價(jià)值的重要體現(xiàn)。

同時(shí)，建議了解一下現(xiàn)有比較主流的開發(fā)、測試思想、模式，如DevOps開發(fā)模式、測試左移與右移思想等等；測試應(yīng)用領(lǐng)域，如人工智能測試；測試技術(shù)，如數(shù)據(jù)、接口的自動化等等，使得我們對測試的認(rèn)識具有一定的前瞻性。

白盒測試：

白盒測試又稱結(jié)構(gòu)測試、透明盒測試、邏輯驅(qū)動測試或基于代碼的測試。白盒測試是一種測試用例設(shè)計(jì)方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的。"白盒"法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進(jìn)行測試。

"白盒"法是窮舉路徑測試。在使用這一方案時(shí)，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨(dú)立路徑數(shù)是天文數(shù)字。

黑盒測試：

黑盒測試也稱功能測試，它是通過測試來檢測每個(gè)功能是否都能正常使用。在測試中，把程序看作一個(gè)不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。

黑盒測試著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對軟件界面和軟件功能進(jìn)行測試。

最大區(qū)別：

二者最大的區(qū)別就是測試對象不一樣，白盒測試主要針對的是程序代碼邏輯，黑盒測試主要針對的是程序所展現(xiàn)給用戶的功能，簡單的說就是前者測試后臺程序后者測試前臺展示功能。

去年我們公司將近20多人的軟件測試團(tuán)隊(duì)，平均每天每人要加班3個(gè)小時(shí)。

IT互聯(lián)網(wǎng)行業(yè)加班已經(jīng)成為常態(tài)了，為了項(xiàng)目能迅速落地，搶占市場，只要靠人力投資，壓縮項(xiàng)目周期。

但今年開始，測試團(tuán)隊(duì)在縮編，一直裁員。在幫同事二次推薦就業(yè)時(shí)就發(fā)現(xiàn)，要求變高了，以前基本是手動測試，功能測試，現(xiàn)在基本都要求會語言，會自動化測試，要寫腳本。

軟件測試行業(yè)，大部分人是非專業(yè)的，從培訓(xùn)機(jī)構(gòu)出來，這個(gè)數(shù)量規(guī)模很大，將來工作競爭壓力也不小。

至于和開發(fā)比，那開發(fā)基本找的都是專業(yè)的，難度也是很大的，我碰到過有開發(fā)做累了想做測試的，但沒有測試想做開發(fā)的。如果說測試加班需要2小時(shí)，那開發(fā)的加班則是他的2倍。

在工廠中測試一般分為2種，一種是生產(chǎn)線的qc（包括qa）測試，一種是開發(fā)階段的品證測試（軟件+硬件）。

qc測試主要是按照作業(yè)指導(dǎo)書（sop）來進(jìn)行，sop中指定的測試內(nèi)容必須測試到，全測的產(chǎn)品必須做測試記號（每個(gè)人分配不同的記號），如是QA抽檢必須記錄流水號，抽撿合格才能Pass，不管是qc還是Qa都必須做好測試報(bào)表，測試過程中如發(fā)現(xiàn)問題要及時(shí)通報(bào)。

經(jīng)測試pass的產(chǎn)品如果發(fā)現(xiàn)有不良，可重新拿sop核對測試，如sop沒有指定測試該項(xiàng)內(nèi)容則為sop缺陷。如sop有測試該項(xiàng)目且故障重現(xiàn)或故障不能重現(xiàn)，需工程師分析原因。

開發(fā)階段的品證測試必須在測試前先制定測試計(jì)劃，check list中應(yīng)包含兼容測試、用戶體驗(yàn)測試、ui測試、黑盒測試（有的公司同時(shí)要進(jìn)行白盒測試）、性能測試、可靠性測試，當(dāng)然要先搭建好測試環(huán)境。

做為測試人員只要嚴(yán)格按照check list的內(nèi)容進(jìn)行測試，做好測試記錄，測試過程中我現(xiàn)問題及時(shí)通報(bào)，測試完成后輸出測試報(bào)告并跟進(jìn)bug的處理進(jìn)度。

只要嚴(yán)接按照以上步驟進(jìn)行測試，測試人員一般不會背黑鍋。但，如果是自己的失誤造型不良輸出那就另當(dāng)別論了！