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

軟件測試現在算是還不錯的一個崗位，現在行業里也有很多培訓機構在做軟件測試工程師方面的培訓。如果對測試崗位有興趣的話，還是可以報名參加培訓，未來也有這樣的機會。

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

至于測試能夠干到多少歲，這個其實沒有一個嚴格的標準，要看個人的身體素質和知識水平了。可能知識水平大家都能夠理解，也就是能力強，自然就能夠走得比較久。不過，身體素質是什么標準？

其實，在IT行業有一個沒有明說的潛規則，就是測試的時間是最可能被壓縮的。

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

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

所以，擁有強健的身體，是做測試所必備的要素。當然，程序員也是一樣的，只是程序員的坑可以留到測試階段，但是測試的坑留到上線，那就會變成一口鍋讓人背了。

個人的核心競爭力與所在行業發展的趨勢，以及隨著行業及相關行業的發展對從業者提出的要求應該是有著直接關系的。

比如，十年前與現在相比，測試人員的核心競爭力已經發生了明顯的變化。

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

軟件測試行業的發展現狀

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

之前寫過《2018年度軟件測試行業現狀報告》的解讀，其中有總結以下幾點：

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

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

同時，敏捷一直強調“團隊為質量負責”，測試不再是測試人員的專屬，這里我們需要重新思考下，質量由整個團隊負責，那么測試的價值如何更好的體現——如何提高測試效率。

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

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

若我們現在具備如上所說的測試開發能力，那么至少我們是具備競爭力的。

這里需要注意的是具備了一定的開發基礎 并不等同于 能夠做好測試，之所有測試開發成為一種趨勢，是因為在具備優秀測試設計等測試能力的基礎上，若具備一定開發能力和思維的測試人員，能夠更好的從質量、效率、風險、成本之間尋求一種平衡。

什么是核心競爭力

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

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

比如性能測試，曾在一次互聯網測試開發大會上，看見過某位前輩講到過的一個案例：在定位某個性能問題時，挖掘到操作系統內核的深度，并且發現是因操作系統內核缺陷導致的性能風險，這個定位問題的過程及結果就是測試專業性深度的體現。

也可以是具備一定的測試廣度，并且能夠根據不同場景靈活適當的將其融合到一起，做到質量、成本、效率、風險的平衡。

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

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

同時，建議了解一下現有比較主流的開發、測試思想、模式，如DevOps開發模式、測試左移與右移思想等等；測試應用領域，如人工智能測試；測試技術，如數據、接口的自動化等等，使得我們對測試的認識具有一定的前瞻性。

白盒測試：

白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基于代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及里面是如何運作的。"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。

"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。

黑盒測試：

黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。

黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。

最大區別：

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

去年我們公司將近20多人的軟件測試團隊，平均每天每人要加班3個小時。

IT互聯網行業加班已經成為常態了，為了項目能迅速落地，搶占市場，只要靠人力投資，壓縮項目周期。

但今年開始，測試團隊在縮編，一直裁員。在幫同事二次推薦就業時就發現，要求變高了，以前基本是手動測試，功能測試，現在基本都要求會語言，會自動化測試，要寫腳本。

軟件測試行業，大部分人是非專業的，從培訓機構出來，這個數量規模很大，將來工作競爭壓力也不小。

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

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

qc測試主要是按照作業指導書（sop）來進行，sop中指定的測試內容必須測試到，全測的產品必須做測試記號（每個人分配不同的記號），如是QA抽檢必須記錄流水號，抽撿合格才能Pass，不管是qc還是Qa都必須做好測試報表，測試過程中如發現問題要及時通報。

經測試pass的產品如果發現有不良，可重新拿sop核對測試，如sop沒有指定測試該項內容則為sop缺陷。如sop有測試該項目且故障重現或故障不能重現，需工程師分析原因。

開發階段的品證測試必須在測試前先制定測試計劃，check list中應包含兼容測試、用戶體驗測試、ui測試、黑盒測試（有的公司同時要進行白盒測試）、性能測試、可靠性測試，當然要先搭建好測試環境。

做為測試人員只要嚴格按照check list的內容進行測試，做好測試記錄，測試過程中我現問題及時通報，測試完成后輸出測試報告并跟進bug的處理進度。

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