軟件測(cè)試行業(yè)供需現(xiàn)狀

隨著敏捷、DevOps等開(kāi)發(fā)模式的引入以及大數(shù)據(jù)治理與應(yīng)用、人工智能機(jī)器學(xué)習(xí)與深度學(xué)習(xí)的應(yīng)用的發(fā)展、軟件交付周期逐漸縮短、技術(shù)復(fù)雜度不斷提升對(duì)測(cè)試人員質(zhì)量保障與效率提升等方面提出了越來(lái)越高的要求。因此，對(duì)人員的要求也是在不斷提高的，一方面響應(yīng)基礎(chǔ)功能需求的手工測(cè)試人員基本飽和，另一方面懂測(cè)試的測(cè)試開(kāi)發(fā)面試達(dá)標(biāo)者比例過(guò)低。

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

通過(guò)之前對(duì)近幾年《軟件測(cè)試行業(yè)現(xiàn)狀報(bào)告》的解讀，以及結(jié)合對(duì)當(dāng)下軟件測(cè)試左移與右移思考，總結(jié)了以下幾點(diǎn)：

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

敏捷及DevOps模式的應(yīng)用，對(duì)測(cè)試人員提出了不同于以往的要求，以前測(cè)試基本上都在開(kāi)發(fā)階段之后和產(chǎn)品上線之前完成，使得測(cè)試人員在開(kāi)發(fā)階段之前加大了對(duì)需求分析等測(cè)試分析和設(shè)計(jì)、同時(shí)不斷提高自動(dòng)化測(cè)試技術(shù)應(yīng)用，促進(jìn)研發(fā)內(nèi)建質(zhì)量。（測(cè)試左移）

隨著業(yè)務(wù)、用戶對(duì)產(chǎn)品質(zhì)量提出更高的要求，以及測(cè)試開(kāi)發(fā)技術(shù)發(fā)展與應(yīng)用，促使測(cè)試技術(shù)多樣化發(fā)展，如，日志和數(shù)據(jù)分析、質(zhì)量運(yùn)營(yíng)、服務(wù)監(jiān)測(cè)等。（測(cè)試右移）

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

DevOps模式更是對(duì)測(cè)試、尤其是自動(dòng)化測(cè)試、編碼能力提出了更高的要求。

功能測(cè)試人員發(fā)展的局限性

一方面功能測(cè)試的深度廣度的潛在延伸性很強(qiáng)，另一方面想突破傳統(tǒng)功能測(cè)試思維的確很難。在軟件測(cè)試左移的思想中，測(cè)試人員對(duì)需求分析的投入在逐漸增大，這里的難點(diǎn)就是如何突破傳統(tǒng)認(rèn)知的測(cè)試設(shè)計(jì)深度、廣度問(wèn)題。

大多數(shù)功能測(cè)試人員，半年工作經(jīng)驗(yàn)可以基本的了解軟件測(cè)試相關(guān)流程，但因?qū)Ｗ⒂诠δ苄枨蟮姆治?、?yàn)證、容易出現(xiàn)忽略功能需求背后的業(yè)務(wù)需求、用戶需求，對(duì)產(chǎn)品整體的質(zhì)量把握不到位，容易出現(xiàn)得此失彼的問(wèn)題，也難以將功能測(cè)試做成閉環(huán)。

功能測(cè)試的深度和廣度的延伸性不僅僅體現(xiàn)了功能需求本身，還包括產(chǎn)品架構(gòu)設(shè)計(jì)、開(kāi)發(fā)技術(shù)棧、服務(wù)內(nèi)容與模式、用戶群體等等。

我們清楚的認(rèn)識(shí)到，一個(gè)優(yōu)秀的測(cè)試工程師，應(yīng)該做到：

• 懂業(yè)務(wù)：能夠站在用戶角度理解業(yè)務(wù)、用戶需求，能扎實(shí)通過(guò)測(cè)試設(shè)計(jì)的保證業(yè)務(wù)質(zhì)量。
• 懂技術(shù)：具備技術(shù)解決方案思維和能力，提升產(chǎn)品質(zhì)量和測(cè)試效率。
• 懂架構(gòu)：具備產(chǎn)品架構(gòu)的基本認(rèn)識(shí)和識(shí)別架構(gòu)設(shè)計(jì)中的質(zhì)量、性能風(fēng)險(xiǎn)，保證產(chǎn)品需求和實(shí)現(xiàn)能夠滿足用戶需求及產(chǎn)品發(fā)展需要。

我們不難得出測(cè)試逐漸向測(cè)試開(kāi)發(fā)過(guò)渡已經(jīng)是一種顯在的發(fā)展趨勢(shì)，無(wú)論我們決定將來(lái)走技術(shù)路線還是管理路線。

但具備了一定的開(kāi)發(fā)能力并不等同于能夠做好測(cè)試，之所有測(cè)試開(kāi)發(fā)成為一種趨勢(shì)，是因?yàn)闇y(cè)試人員在具備優(yōu)秀測(cè)試設(shè)計(jì)等業(yè)務(wù)測(cè)試能力的基礎(chǔ)上，若同時(shí)具備一定開(kāi)發(fā)能力和技術(shù)解決思維，能夠更好的從質(zhì)量、效率、風(fēng)險(xiǎn)、成本之間尋求一種平衡。

自動(dòng)化測(cè)試方向認(rèn)知的片面性

談到自動(dòng)化測(cè)試，很多人認(rèn)為這是測(cè)試人員職業(yè)發(fā)展的一個(gè)方向，但對(duì)這個(gè)方向的認(rèn)識(shí)并不都是充分的，比如，當(dāng)面試的時(shí)候問(wèn)到自己設(shè)計(jì)的自動(dòng)化測(cè)試用例的優(yōu)缺點(diǎn)，自動(dòng)化測(cè)試框架選擇的合理性體現(xiàn)在哪里時(shí)，很難有清晰的回答。

如何圍繞產(chǎn)品質(zhì)量提高測(cè)試效率，不僅僅是將手工用例轉(zhuǎn)變?yōu)樽詣?dòng)化用例這么片面，其中還包含了自動(dòng)化測(cè)試策略、框架選型，自動(dòng)化的可維護(hù)性、可擴(kuò)展性、可持續(xù)性等方面的諸多考慮，一個(gè)難以維護(hù)、擴(kuò)展的自動(dòng)化測(cè)試實(shí)踐，是失敗的。

“圍繞產(chǎn)品質(zhì)量，提升測(cè)試效率，通過(guò)不斷的技術(shù)創(chuàng)新、應(yīng)用，不斷提高測(cè)試整體流程能力（單位時(shí)間能夠提供多少服務(wù)）。”假如一個(gè)測(cè)試團(tuán)隊(duì)的人數(shù)相對(duì)固定、測(cè)試時(shí)間充足，他提升效率的目的又是什么呢？

從這種角度來(lái)思考，個(gè)人認(rèn)為測(cè)試效率提升的根本意義在于：

• 做更多的有價(jià)值的測(cè)試（測(cè)試左移或右移的投入）
• 實(shí)現(xiàn)真正的縮減成本（減少人力投入）。
• 擁抱變化，適應(yīng)開(kāi)發(fā)模式的轉(zhuǎn)變，比如類(lèi)敏捷、DevOps模式下的頻繁迭代、持續(xù)部署。

測(cè)試職業(yè)發(fā)展

測(cè)試職業(yè)發(fā)展方向大致分為管理方向及技術(shù)方向。無(wú)論我們決定將來(lái)走技術(shù)路線還是管理路線。都需要注意測(cè)試逐漸向測(cè)試開(kāi)發(fā)過(guò)渡已經(jīng)是一種顯在的發(fā)展趨勢(shì)，這樣就要求我們需要具備一定的測(cè)試開(kāi)發(fā)能力和技術(shù)解決思維。

雖然測(cè)試開(kāi)發(fā)逐漸成為測(cè)試人員的基本能能力要求，但不要進(jìn)入一味追求開(kāi)發(fā)能力。具備了一定的開(kāi)發(fā)能力并不等同于能夠做好測(cè)試，之所有測(cè)試開(kāi)發(fā)成為一種趨勢(shì)，是因?yàn)闇y(cè)試人員在具備優(yōu)秀測(cè)試設(shè)計(jì)等業(yè)務(wù)測(cè)試能力的基礎(chǔ)上，若同時(shí)具備一定開(kāi)發(fā)能力和技術(shù)思維，能夠更好的從質(zhì)量、效率、風(fēng)險(xiǎn)、成本之間尋求一種平衡。

培養(yǎng)全面的測(cè)試能力

• 懂業(yè)務(wù)：能夠站在用戶角度理解業(yè)務(wù)、用戶需求，能扎實(shí)通過(guò)測(cè)試設(shè)計(jì)的保證業(yè)務(wù)質(zhì)量。
• 懂技術(shù)：具備技術(shù)解決方案思維和能力，提升產(chǎn)品質(zhì)量和測(cè)試效率。
• 懂架構(gòu)：具備產(chǎn)品架構(gòu)的基本認(rèn)識(shí)和識(shí)別架構(gòu)設(shè)計(jì)中的質(zhì)量、性能風(fēng)險(xiǎn)，保證產(chǎn)品需求和實(shí)現(xiàn)能夠滿足用戶需求及產(chǎn)品發(fā)展需要。

建立良好的質(zhì)量意識(shí)

我們清楚一切測(cè)試活動(dòng)都是圍繞用戶、業(yè)務(wù)需求保障產(chǎn)品質(zhì)量而開(kāi)展，而保障產(chǎn)品質(zhì)量的核心是測(cè)試設(shè)計(jì)，而非測(cè)試技術(shù)，測(cè)試技術(shù)大多僅是解決測(cè)試設(shè)計(jì)執(zhí)行的可行性、效率問(wèn)題。

拓展測(cè)試廣度與深度

隨著類(lèi)敏捷、DevOps模式的發(fā)展、軟件交付周期逐漸縮短、技術(shù)復(fù)雜度不斷提升對(duì)測(cè)試人員質(zhì)量保障與效率提升等方面提出了越來(lái)越高的要求。

在敏捷開(kāi)發(fā)模型的軟件生命周期中，我們通過(guò)不斷快速的迭代，以使其最大限度地符合客戶對(duì)系統(tǒng)的需求。此時(shí)測(cè)試的關(guān)注點(diǎn)基本停留在開(kāi)發(fā)階段，以保證產(chǎn)品達(dá)到上線標(biāo)準(zhǔn)。引入DevOps之后，我們不僅要關(guān)注產(chǎn)品的質(zhì)量是否達(dá)標(biāo)，還需要使產(chǎn)品或功能價(jià)值預(yù)期得到及時(shí)的驗(yàn)證。

因此，我們不僅要將測(cè)試左移，還要進(jìn)行測(cè)試右移，通過(guò)監(jiān)控產(chǎn)品在生產(chǎn)環(huán)境的運(yùn)作情況，來(lái)驗(yàn)證其價(jià)值并獲得反饋，從而持續(xù)改進(jìn)。我們通過(guò)以下三個(gè)方面來(lái)了解一下測(cè)試左移與右移。

1.新功能是什么？

在開(kāi)發(fā)環(huán)境，我們開(kāi)發(fā)新功能，并且通過(guò)測(cè)試保證其達(dá)到產(chǎn)品驗(yàn)收標(biāo)準(zhǔn)。

這就要求從產(chǎn)品生命周期開(kāi)始時(shí)，各個(gè)角色（測(cè)試、開(kāi)發(fā)、產(chǎn)品負(fù)責(zé)人等）對(duì)業(yè)務(wù)場(chǎng)景、用戶需求達(dá)成一致的認(rèn)識(shí)，從而使其從需求到最后的測(cè)試驗(yàn)證，進(jìn)行高度的協(xié)作和溝通，最后交付最有價(jià)值的功能。同時(shí)測(cè)試人員能夠根據(jù)用戶需求進(jìn)行需求分析，發(fā)現(xiàn)產(chǎn)品前期設(shè)計(jì)是否存在問(wèn)題或者補(bǔ)充產(chǎn)品設(shè)計(jì)。同時(shí)，通過(guò)及早引入自動(dòng)化測(cè)試，協(xié)助研發(fā)內(nèi)建質(zhì)量。

這里體現(xiàn)出了測(cè)試左移的核心思想。

2.新功能是否價(jià)值？

我們將新功能部署到生產(chǎn)環(huán)境以后，接下來(lái)就應(yīng)該衡量業(yè)務(wù)價(jià)值是否達(dá)到預(yù)期。

通過(guò)對(duì)用戶日志或數(shù)據(jù)進(jìn)行分析感知用戶的行為變化。比如：比如頁(yè)面新增了一個(gè)導(dǎo)出功能，發(fā)布上線后，發(fā)現(xiàn)用戶的點(diǎn)擊導(dǎo)出按鈕的次數(shù)幾乎為零，很可能是因?yàn)橛脩舾静恍枰@個(gè)功能，或者導(dǎo)出按鈕的顏色、位置等易用性（產(chǎn)品質(zhì)量屬性之一）原因?qū)е掠脩魶](méi)有使用。這時(shí)候需要思考如何對(duì)該功能進(jìn)行調(diào)整。如果一個(gè)功能沒(méi)有使用或者沒(méi)有給產(chǎn)品帶來(lái)顯著的價(jià)值，在功能正確性和性能驗(yàn)證上投入大量精力又有什么意義呢？

這里體現(xiàn)出了測(cè)試右移的思想。

3.新功能線上是否是可靠的？

測(cè)試大多數(shù)情況只能覆蓋已知的測(cè)試場(chǎng)景。產(chǎn)品部署在用戶環(huán)境運(yùn)行的過(guò)程中，可能會(huì)由于某些不確定性因素（比如數(shù)據(jù)量突然陡增，用戶訪問(wèn)突然陡增、網(wǎng)絡(luò)不穩(wěn)定或者數(shù)據(jù)盤(pán)損壞等等）導(dǎo)致產(chǎn)品或功能失效，由于其不確定性使得測(cè)試人員很難模擬測(cè)試場(chǎng)景，因此產(chǎn)品線上質(zhì)量運(yùn)營(yíng)需要通過(guò)監(jiān)控的手段開(kāi)展，通常我們需要監(jiān)控兩種特性：可用性、性能。

通過(guò)持續(xù)獲取用戶日志或數(shù)據(jù)，分析產(chǎn)品性能、程序進(jìn)程等穩(wěn)定性、產(chǎn)品質(zhì)量健康度進(jìn)行問(wèn)題報(bào)警、預(yù)警。同時(shí)增加用戶溝通反饋渠道，獲取用戶反饋從而及時(shí)調(diào)整。除此之外，這一點(diǎn)也充分體現(xiàn)了Dev、 QA、Ops的協(xié)作，像監(jiān)控等原本只能Ops做的事，現(xiàn)在Dev或QA一樣可以做。

這里也體現(xiàn)出了測(cè)試右移的思想。

提升測(cè)試核心競(jìng)爭(zhēng)力

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

所以我們需要以發(fā)展的眼光，來(lái)看未來(lái)測(cè)試行業(yè)會(huì)對(duì)我們提出哪些要求，進(jìn)而驅(qū)動(dòng)自己適應(yīng)未來(lái)發(fā)展要求。

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

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

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

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

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

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

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