應(yīng)用程序或網(wǎng)站的功能測試是SDLC（軟件開發(fā)生命周期）的最重要階段之一。開發(fā)人員、測試人員、項目經(jīng)理、運營人員，甚至管理人員都需要多多少少參與到整個項目的功能測試。測試工作由測試部門分配，測試部門提供服務(wù)的穩(wěn)定性至關(guān)重要。在建立多部分協(xié)作的工作文化的過程中，作為測試人員應(yīng)當(dāng)首先意識到，不僅可以對產(chǎn)品進行功能測試，還可以為公司的產(chǎn)品做出更多貢獻。

在應(yīng)用程序交付給用戶面前之前，找出BUG并修復(fù)它們至關(guān)重要。軟件的成功取決于用戶的滿意度，如果應(yīng)用程序的界面中充斥著錯誤和BUG，不僅難以贏得新用戶還會流失老用戶。

大多數(shù)測試工程師對功能測試如何給企業(yè)創(chuàng)造價值都比較清楚也都很進行了很多的嘗試和實踐。通常，功能測試會占用測試人員一天工作當(dāng)中的大部分時間。但是，除了執(zhí)行功能測試之外，還有其他方法可以為產(chǎn)品增加更多的價值。

作為測試人員，可以通過應(yīng)用程序的嚴格CI/CD管道幫助軟件團隊在保障軟件質(zhì)量的前提下更快地迭代。除了功能測試之外，測試人員還可以通過以下方法為網(wǎng)絡(luò)產(chǎn)品增加價值。下面讓我們一一道來。

利益相關(guān)者

每個項目的不同部分的成員對項目都有自己不同的需求和想法。但是當(dāng)使用者是最終使用該產(chǎn)品的用戶時，最重要的還是利益相關(guān)者的的看法嗎？從利益相關(guān)者的立場上消除個人偏見和思維慣式可以極大地改善測試過程并增強應(yīng)用程序或網(wǎng)站的健壯性。列出對交付內(nèi)容表示興趣的人，記錄利益相關(guān)者的期望，并根據(jù)利益相關(guān)者的心態(tài)做出適當(dāng)變化和指定相關(guān)的規(guī)范防止方向跑偏，以避免陷入下圖所示的情況：

因此，除了提供功能測試以外，測試工程師還需要根據(jù)與利益相關(guān)者進行有效溝通并掌握情況以便及時了解進度。測試人員遇到BUG時，通常會報告該BUG并追蹤BUG解決進度流程。但是，要增加價值，還需要報告的內(nèi)容為對利益相關(guān)者影響方面。另外，還需要檢查準備好的測試報告如何更多考慮全局情況，而不是專注于單個功能，讓決策者更全面了解軟件的前世今生，以便做出更合適的決策。

解決此問題的一個好方法是適應(yīng)左移測試。左移測試是指即使在產(chǎn)品準備之前也要盡量進行測試。可以與利益相關(guān)者坐在一起，了解他們真實的需求和潛藏在這些需求之下的心理動機和期望，以便編寫更加符合業(yè)務(wù)需求的測試用例避免漏測和過度測試。

過渡到QAOps

QAOps是指通過與DevOps團隊進行良好協(xié)調(diào)來維護產(chǎn)品的軟件質(zhì)量。目標是提供具有更快的CI/CD流程的健壯的應(yīng)用程序和軟件服務(wù)。QAOps致力于與開發(fā)和運營團隊與QA部門合作，以并行方式執(zhí)行可擴展的測試自動化用例，以便更好地在DevOps中實現(xiàn)連續(xù)測試更好更快的進行軟件的更新迭代。

傾聽用戶反饋

我們都知道，無論整個團隊對產(chǎn)品的感覺如何良好，用戶的意見都是最重要的。了解用戶對產(chǎn)品的反饋以及功能的實用性、易用性甚至比功能實現(xiàn)更重要。在部分場景下，特定功能完全符合需求方和測試人員的期望，但會給用戶帶來額外的負擔(dān)以及使用困難。

測試人員應(yīng)報告可能困擾用戶的風(fēng)險。除了客戶支持團隊之外，還有誰能更好地了解用戶的想法？畢竟，他們是直接與用戶密切聯(lián)系的人。將客戶的反饋聲音用作最有價值的數(shù)據(jù)，并在軟件團隊發(fā)揮巨大的作用。

了解用戶故事

在敏捷開發(fā)框架中，測試人員應(yīng)該多去了解用戶故事，以評估發(fā)布周期所需必要的工作。它是從最終用戶的角度對應(yīng)用程序上的功能的描述。它描述了用戶的分類和屬性，他們的需求和想要的東西以及為什么他們想要特定功能。用戶故事的主要目的是確定項目為用戶帶來的價值。產(chǎn)品負責(zé)人和測試人員了解用戶情況并根據(jù)要求確定任務(wù)的優(yōu)先級。

了解用戶故事有助于制定驗收標準并涵蓋更多使用場景的測試方案。如果故事內(nèi)容過于龐大，則必須將其分解為不同的模塊，甚至根據(jù)不同用戶分類分解。使用測試透視圖來評估用戶故事可以使清楚地了解每一個節(jié)點花費的時間。市場上有許多在線協(xié)作工具可幫助管理者將整個團隊保持在一個儀表板上，可以在其中分配任務(wù)并跟進團隊的進度。

探索新測試工具

很多跡象表明傳統(tǒng)手動功能測試人員受到行業(yè)中使用頻率較高的自動化測試工具的威脅。有些人試圖抵制這種變化，覺得自己的某個技能或者某個方面的優(yōu)勢可以抵消這些技術(shù)帶來的不確定性和威脅。不幸的是，一旦我們了解如何利用工具提高測試效率，大多數(shù)人都會意識到自動化是一個福音。作為一名測試人員，至少應(yīng)具有有關(guān)測試自動化工具以及在領(lǐng)域的相關(guān)機會的基本知識。

使用自動化測試工具，測試人員可以保留用戶操作記錄的備份，并在適當(dāng)?shù)臅r間使用日志。其他一些用途包括檢測日志中的不同模式、模擬用戶行為、復(fù)制生產(chǎn)數(shù)據(jù)等。作為測試團隊中的探索者，可能需要向他人展示如何輕松使用工具來解決問題的案例。

例如，如果我們考慮進行手動跨瀏覽器測試以驗證網(wǎng)站的兼容性時，都知道這樣的測試非常耗時且費力。如果不了解自動化測試或者對編程語言使用有困難，幾乎沒人愿意使用Selenium來提高工作效率。作為一名手動測試人員，一開始了解測試自動化時，可能會對Selenium自動化測試感到猶豫和不安全，但是一旦掌握了這些技巧，就會發(fā)現(xiàn)測試周期交付速度的提高會大幅提高。

代碼審查

不要將所有時間都花在功能測試上。測試人員需要對代碼更改保持更高的警惕，代碼審查提供了一個很好的契機。在每個發(fā)布周期中，都需要有一段時間開發(fā)團隊可以坐在那里審查滿足發(fā)布要求所需的代碼更改。要進行更深入的質(zhì)量檢查，測試工程師需要積極參與代碼審查過程，并了解應(yīng)用程序中可能發(fā)生的更改。測試人員不僅應(yīng)該參與其中，而且還應(yīng)該就這些更改做出自己的貢獻。

作為功能測試員，每天都在與應(yīng)用程序進行交互驗證。每天都需要執(zhí)行多個測試場景，記錄問題，回歸缺陷。雖然代碼審查可能對你比較困難，但是從實際使用角度也可以提出一些有價值的建議。

用戶體驗

忽略用戶體驗，是在急于發(fā)布應(yīng)用程序的軟件公司中遇到的通病之一。急于發(fā)布功能組件或產(chǎn)品有時會優(yōu)先于功能部件或產(chǎn)品的正確性、穩(wěn)定性。在發(fā)布產(chǎn)品之前，必須進行深入的檢查，條件允許的話可以通過Beta測試解決這些錯誤。采取必要的手段來收集信息，業(yè)務(wù)指標和廣泛的意見，以從用戶的角度評估產(chǎn)品的質(zhì)量。記錄證據(jù)留存（防止背鍋），并提出建議以促進改進。

如果是超快速發(fā)版，很可能會開始出現(xiàn)不一致的死循環(huán)。一般經(jīng)驗來講，多個開發(fā)人員的參與以及將開發(fā)任務(wù)的一部分外包給不同的團隊會導(dǎo)致更多的不穩(wěn)定風(fēng)險。用戶接觸點、圖標、操作、文本、功能、性能和關(guān)鍵流程是質(zhì)量檢查的一些重要元素。

嚴守Deadlines

很多測試人員比較苦惱的就是執(zhí)行了許多重復(fù)的工作以及大量浪費在溝通上的時間，以至于整個流程會因此變得混亂導(dǎo)致拖延，有些測試人員戲稱搬磚。但是事實上，任何項目規(guī)劃最終的就是時間節(jié)點，必須嚴格遵守最后期限。最終目標必須是通過避免這些問題來節(jié)省時間。同時保持工作進展速度和工作質(zhì)量，聽起來像是一個大坑。但是如果將團隊內(nèi)部和跨部門溝通做好，這兩者會在一定程度上達到統(tǒng)一，將會減少很多不必要的更改，給測試工作減少很多時間的浪費。

編寫有效的測試用例和詳細的測試報告是快速執(zhí)行任務(wù)的另一種方法。這一句話中使用了詳細和快速兩個詞，聽起來可能是矛盾的，但是詳細的報告需要一次性的努力。使用合適的工具和保持良好的使用習(xí)慣，你可以快速訪問查看必要的日志內(nèi)容、用戶數(shù)據(jù)以及錯誤信息。

解決BUG

很多測試人員認為他們的工作有時候十分枯燥，看起來毫無意義，如果沒有發(fā)現(xiàn)BUG，又會讓他們覺得無法安心上線。一段時間后，像工具人一樣運行測試腳本可能會變得有些乏味。執(zhí)行一個測試用例，編寫一個測試報告，將該BUG標記給開發(fā)人員，并驗證該修復(fù)程序聽起來很簡單，在某種程度上的確是這樣。

但是，如果你想提高自己在這個工作鏈條中的價值和地位，那么就不能僅僅把自己當(dāng)做是一個提示BUG的人，該怎么辦？那就成為一個解決BUG的人。

最常見的誤解之一：測試人員就是在發(fā)現(xiàn)、報告、驗證BUG之間循環(huán)。事實上測試人員的工作并不會因為報告BUG而結(jié)束。如果測試人員通過縮小搜索范圍來找到避免大海撈針地找原因，那就離解決BUG還近了一步。例如，除了指出BUG外，測試工程師還可以為開發(fā)人員提供一種更輕松的修復(fù)方法。這樣，測試人員就可以與開發(fā)人員合作并幫助團隊節(jié)省時間、提高質(zhì)量和效率?？v觀全局，能夠解決BUG的測試人員可以成為行業(yè)的稀缺物種！在求職市場上也會更加受到青睞。

學(xué)習(xí)數(shù)據(jù)科學(xué)

擁有大量原始數(shù)據(jù)，重要的是選擇最相關(guān)的信息并熟練地使用它。在這里，我們談?wù)摰氖菙?shù)據(jù)科學(xué)（俗稱大數(shù)據(jù)），它正在挖掘存·儲在數(shù)據(jù)倉庫中的海量信息池。即使逐步交付和部署，也無法測試所有內(nèi)容，即使是在最佳測試環(huán)境中也難以測試！

就生產(chǎn)用途而言，借助大數(shù)據(jù)相關(guān)技術(shù)，測試人員可以獲得詳細的信息。但是作為測試人員，需要學(xué)習(xí)如何充分利用所有數(shù)據(jù)。數(shù)據(jù)科學(xué)可以幫助測試人員集中精力進行更有效的測試。反過來，這將有助于整個組織提供更好的交付質(zhì)量。

積極競爭

在當(dāng)今快節(jié)奏的技術(shù)世界中，企業(yè)只需一晃神的功夫，就足夠使競爭對手脫穎而出。隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展，以及行業(yè)的內(nèi)卷化的增強，企業(yè)之間的競爭將越來越激烈。導(dǎo)致公司產(chǎn)品出現(xiàn)地獄般漏洞的原因，最常見鍋還是測試人員來背的。

在敏捷大行其道的軟件行業(yè)，測試人員還需要篩選測試業(yè)務(wù)情況和其他風(fēng)險，以將競爭對手產(chǎn)品與自己產(chǎn)品的優(yōu)缺點進行比較。除了功能測試之外，還要考慮其他一些標準，包括可用性測試、安全性測試、性能測試和穩(wěn)定性測試。

總結(jié)

雖然功能測試確實具有不可替代的重要性，但這并不意味著測試人員可以長期專注于此！大多數(shù)測試人員擔(dān)心未知的變化，缺乏編碼技能。真實情況是除了功能測試之外，還有其他方法可以為組織增加自身價值。

測試是確保產(chǎn)品在到達最終用戶之前無可替代的環(huán)節(jié)。在某些組織中，測試人員的貢獻經(jīng)常被忽略。許多測試人員想知道他們何時可以與DevOps成員（即使團隊宣城他們就是DevOps成員）一起坐在會議室上討論產(chǎn)品和技術(shù)方案。QAOps將專注于DevOps中的連續(xù)測試，從而將盡可能改變這一現(xiàn)狀。

因此，作為一名測試人員，想知道自己對服務(wù)或應(yīng)用程序所做的貢獻，可以自己先審視一下自己為產(chǎn)品增加的價值。即使決策權(quán)屬于領(lǐng)導(dǎo)和項目經(jīng)理，測試人員在其中的作用也不能忽視。測試人員可以為其他成員做出正確的決定奠定了基礎(chǔ)，從而幫助團隊充分發(fā)揮全部潛力。