跳出測試看測試

2021-09-17 19:38:52 字數 1282 閱讀 1139

在軟體測試這個行業已經摸爬滾打了10年,經歷過top 500外企標準化的流程,也體驗過bat的快速迭代。做過複雜耗時的功能測試,體驗過糾結的ui自動化,深入過底層通訊的白盒測試、執行過60億的資料遷移、分析過2000萬使用者量伺服器的效能。我經常會聽到一些測試同學的抱怨聲:「我做的工作沒有技術含量,整天就是點按鈕,測試真是太無聊了,我要做自動化測試,我要做效能測試」。今天我的這篇文章不是想討論自動化測試或效能測試,因為講自動化和效能的文章太多太多。我就想講一講我自身對測試的一點體會和感悟,或許有不被大家認同的地方,歡迎吐槽。

大多數的測試同學目前的工作可能都是在寫測試用例和執行測試用例,以及報bug。這些工作都是作為乙個qa最基本的工作和必備的能力。如果你定位自己的角色僅僅是乙個執行者的話,那你可能就只能一直點按鈕了。我不知道大家是否思考過這樣乙個問題沒有:「乙個工作的可替代性」? 當乙個工作誰都能幹的時候,你自己在這個崗位上就是非常的危險。因為企業很可能某一天找乙個更為廉價的勞動力,就可以將你替代。企業不是慈善機構,他的目標永遠是利潤最大化。那麼,作為乙個功能測試的qa來說,應該如何去思考自己的未來和提公升自己的能力呢? 我的一點建議就是「跳出測試看測試」。這句話如何理解?其實,我們現在做的測試工作僅僅是整個軟體專案中的一部分。而我們應該跳出測試這個圈,上公升到對軟體專案的乙個整體把控,包括:參與到需求分析、需求評審、系統設計、系統設計評審、**評審等各個環節。這樣你對整個系統將會有乙個全域性的把控,對系統有更深的理解,對你測試的工作也會起到很好的幫助。

該圖是一幅標準的軟體開發測試流程體系圖。實際上作為乙個專業的測試人員除了應該涉及到黃色部分「測試工作」的區域外,還應該要涉及到紅色箭頭的部分,包括:需求、系統設計、**評審、測試評審。這樣你才能更好的了解整個產品的設計和實現,並且更多的去了解產品的細節,也能夠為你更好的測試服務。因為你的測試更加有針對性,你了解設計的缺陷或者可能存在的安全隱患,而不是之前胡亂的一通亂點。這也是我這篇文章標題的意義,只有你站在更高的層次,更全面的看整個軟體的開發測試過程,你才能得到更多的成長。

給身陷測試困惑的同學一點建議:

多去和開發溝通,了解系統設計和整體架構

多參加方案和**評審,以學習的身份融入開發

以目前參與的專案為切入點,學習開發語言,並且堅持下去

多思考現有專案流程的痛點,自己能做一些什麼樣的改進

多在團隊做一些知識分享,提高自身的團隊影響力

提取碼:frce

測試 看看你的職業走向

假如世上真的有時光隧道,可以讓時間輪迴,能夠帶領你走入各個時空幻境,甚至於連書中的虛構世界都能成為現實,你最希望去哪個時空拜訪仰慕已久的人物?現在的社會競爭是非常激烈的,我們要把握住每乙個來之不易的機會推銷自己 展示自己。要把自己最好的一面展現出來,首先要了解自己的優點在何處?這樣無論是在情場還是在...

弱網測試看這裡就夠了

在網際網路的時代裡,網路訊號扮演著乙個十分重要的角色,可以毫不誇張的說,對於部分人來講,失去了網路訊號就是失去了全世界,在網際網路產品中網路同樣影響著使用者對產品的體驗,所以身為測試開發人員對於產品 無論是b s還是c s架構 的弱網測試就顯得尤為重要。現實環境中什麼環境會出現弱網?我們在地鐵 車庫...

從簡單測試看D陣列記憶體分配策略

d語言動態陣列可以在執行期改變大小,這和c 的vector相似。似乎記得 stl原始碼分析 一書中提到vector的記憶體分配策略是倍增方式的,d語言陣列是不是也使用了相同方式呢?我做了個簡單的測試 code void main arr 0 writefln while arr.length arr...