最近跟一些剛剛進入軟體測驗行業的朋友去交流,發現了一個有趣的現象,就是對于這個行業的很多問題的認識都是一致的片面,當然也可以理解為誤區,自己利用一點時間,把他們對于這個行業的認識誤區都羅列出來,然后結合自己這么多年的作業經驗和大家一同交流一下,畢竟自己也是從這個階段走過來的,后來者能少走些彎路是最好的,
自己整理了軟體測驗人員最容易陷入的28個誤區,文章后面附帶思維導圖,
1、測驗和開發永遠都是死對頭
雖然測驗與開發的作業性質是對立的,但是目的都是為了專案更好的發展,
我以前發起過一個倡議:我們討論的時候不要用他們(開發人員)和我們(測驗人員),而是統一用咱們,因為開發人員和測驗人員本來就是一起的,如果測驗人員能與開發人員成為朋友,你會發現,作業會非常順心,在我所在的企業中,測驗人員和開發人員關系非常融洽,互相尊重,對大家的作業能力和技術表示肯定,
其中的訣竅重點在于測驗這邊的溝通,誰也接受不了別人指責自己得意之作,所以測驗要以幫助開發讓開發的‘孩子’更健康,讓開發‘帶孩子’別那么辛苦;
測驗是系統它爹,開發是系統它媽,當媽的那么痛苦的生出來,當爹的要揍,當媽的能同意么,脾氣上來了,當爹你就緩一下,哄哄,當媽的也不是傻子,她也知道對錯的,當媽的要實在糊涂,那你還猶豫什么,抽她(哈哈,開個玩笑,還是要以理服人),
2、測驗人員不需要了解軟體開發知識
測驗人員跟開發人員交流不暢,主要是有以下幾個原因:
(1)測驗人員如果看不懂開發代碼,會導致BUG描述不清晰,不準確,開發人員不明白BUG應該怎么重現,或者你想說的是什么,甚至是一些很膚淺的bug,卻被測驗人員認為是非常嚴重的問題,
(2)測驗人員的開發知識匱乏,將不是BUG的BUG提交給開發人員,或者提出的建議性意見在開發中實作起來比較困難,又無法給出一個合理的解決辦法(開發人員易于實作的辦法),
(3)測驗出BUG的同時,無法清晰準確地定位BUG出現的源頭,導致與開發人員交涉次數過于頻繁,時間是寶貴的,缺乏交流有害,交流過多也容易出問題,
所以,測驗人員對開發知識的了解是必須的,
(4)如果不了解開發知識,測驗人員很容易被開發人員牽著鼻子走,對于一些BUG的PK,經常是理屈詞窮,因為開發人員隨便一忽悠,你如果不了解個中奧妙,你一個字也說不上來,
(5)自動化測驗和性能測驗包括專案管理,都會要求對軟體開發有深入的理解,如何能設計一個好的自動化框架,好的性能測驗用例,如何管理一個開發團隊,這都需要我們在軟體開發方面有所掌握,
所以,測驗了解軟體開發知識是必須的,
3、軟體測驗很簡單
軟體測驗入門相對比開發人員確實更容易一些,原因是開發一開始就要掌握一門語言,而測驗到中后期才需要掌握開發語言技術,測驗更重視的是測驗思路,方法,以及測驗工具的掌握,但是到了中后期,軟體測驗需要掌握的知識量將遠大于開發人員,測驗后期要掌握功能,性能,自動化,介面,協議,抓包,安全性,包括移動端等一系列測驗工具,技術難度性絲毫不亞于開發技術,
4、測驗就是為了找到bug
測驗人員不僅需要找到bug,還要跟蹤bug直至問題得以被修復,對缺陷進行確認測驗并關閉缺陷,測驗員還需要分析問題原因,避免因此問題影響到其他功能,
不僅如此,測驗還需要對軟體進行性能測驗、自動化測驗和安全性測驗等一系列其他測驗手段,目的是找出系統漏洞,找出性能瓶頸,服務器抗壓能力及穩定性,這已經遠遠超過找bug的范疇,
5、自動化測驗太難
很多初學者都認為自動化測驗相比性能和功能都要難很多,實際上每個測驗方向做精通都不容易,自動化只是測驗其中的一部分,功能測驗做到極致也不容易,性能測驗做到精通也同樣需要各種技術手段,自動化無非就是需要懂一些代碼,難點不在技術,而是思路和實施操作,實際上只要付出同樣多的努力,無論是性能還是自動化,都可以做的很好,
6、手工測驗沒有挑戰性
手工測驗是測驗的基本功,也是每一個測驗必經之路,但是真正做好的人沒有幾個,很多人認為手工測驗就是點點點,我認為這個說法就是對測驗的污蔑,手工測驗的范圍很大,包含涉及的內容也非常多,例如資料準確性,表單值域,邏輯分析,業務梳理,互動易用性,逆向思維,UI兼容性,cookie等...單單說業務邏輯和業務流程測驗,就有多少人測驗不全面,分析不到位而導致發布上線后出現嚴重問題,
7、軟體測驗作業重復又枯燥
軟體測驗的范圍很廣,測驗的手段和方法也是不一樣的,而且每個人測驗一個專案的思路也不同,實際上認為重復性作業的人,往往是技術差的人,因為他始終沒有任何成長,
真正做好測驗的人對待每一個專案都可以使用不一樣的測驗方法,介面測驗結束就測功能,功能測完了就做做自動化,上線之前做做性能測驗,測驗工具也可以隨意更換,對于我來說,每一個新專案的開始,都是一次新的挑戰,作業8年,絲毫沒有感覺到枯燥乏味,
8、女生比較適合做軟體測驗
很多人都覺得女生做測驗比較吃香,事實上身邊做測驗的也確實女生比男生要多,一個是因為女生天生比男生細心,二是很多人都覺得因為開發大多是男生,女生做測驗跟開發溝通會更順暢,這其實是一些客觀的實際因素,但是并不代表男生不適合做測驗,經過統計,各大公司的測驗負責人男生比女生要更多,
9、白盒測驗是開發人員干的事:
一個合格的測驗人員必須掌握白盒測驗,理解其中的原理,不管什么樣的測驗,都必須要有測驗人員的思維才能做好,白盒測驗有著其測驗理論與技術,完全可以有專職的白盒測驗人員進行,避免開發人員自己測驗自己的程式,
10、測驗就是給開發擦屁股的
大家應該都清楚,在實際的作業中通常是測驗驅動開發的,也就是說是測驗在主導著專案的進展,開發人員的技術水平直接體現在bug的數量上,開發的能力測驗一清二楚,也是測驗人員在驅動著開發人員做出改變,如果測驗不能驅動開發,被開發牽著鼻子走,只有一個原因,就是測驗人員能力弱,無法勝任這個角色,
11、我不適合做開發,做測驗吧
這個觀點特別適應于應屆畢業生,在以前面試的程序中,有些人就覺得我代碼寫的不好,所以入行轉做測驗的作業,還有一部分人稍微明白一點開發,但是覺得自己在開發方面沒什么優勢,主動給自己定位做測驗作業,其實測驗要掌握的技能遠比開發多得多,至少面要廣得多,要做一個好的測驗人員,遠比做一個開發人員難得多,
12、機器自動化將會代替手工測驗
現在很多人都在傳自動化測驗將會替代手工測驗,首先有這種想法的人,一定還沒有真正了解自動化測驗,自動化是為了做回歸測驗的,自動化腳本是人工撰寫或錄制完成的,只能覆寫大體的業務流程,并不能對軟體進行詳細的測驗覆寫,詳細的測驗還是需要手工完成的,不然自動化腳本維護的時間成本將會大大增加,適得其反,而且新功能是必須進行手工測驗的,只有老功能才可以進行自動化測驗,自動化是為了提高測驗效率而存在的測驗手段,而不是為了替代手工測驗而出現的,測驗技術交流群:439198493
13、使用了測驗工具,就是進行了有效的測驗
測驗工具是為了協助測驗工程師更高效的完成測驗作業,是否能夠有效測驗,完全取決于使用工具的人的技術水平,水平強,則測驗結果有參考價值,水平弱,則測驗結果一塌糊涂,
建議大家還是要以手工測驗為基礎,工具只是為了提高測驗效率,為了更好的完成測驗作業,并不是用工具測驗就一定有效,
14、規范化軟體測驗是增加專案成本
一個軟體測驗程序如果不規范的話,結果一定不會很理想,規范嚴謹的測驗程序,可以大大提高測驗質量,這不是增加專案成本,而是減少了專案的隱患,甚至是上線后的損失,
一家不重視測驗規范的公司,其產出的軟體一定不會有太大的市場競爭力,其后果,也不應該由測驗人員承擔,
15、期望短期通過增加軟體測驗投入,迅速達到零bug率
測驗人員都應該知道一個原則,就是完全測驗是不可能的,所謂的零BUG,就連阿里巴巴也做不到,并且軟體測驗是貫穿整個專案生命周期的,需要盡早的介入測驗,如果在專案后期加大測驗力度,也并不能有效的提高測驗質量,因為測驗人員沒有時間理解軟體的業務流程和介面邏輯,
16、忽視需求階段的參與
軟體測驗的開展一定是從需求階段展開的,沒有需求檔案就無法衡量測驗周期和測驗范圍,也就無法撰寫測驗計劃和測驗用例,所以忽視需求階段的參與,對于專案質量來說是災難性的結果,
17、忽視用戶操作密集和核心功能的回歸測驗
很多人認為用戶經常操作的地方就不會出現問題,但是一個專案更新后,很可能導致以前的核心功能受到了影響,新的代碼對老的業務造成了破壞,所以說,回歸測驗一定不能忽視核心功能以及用戶密集操作的模塊,相反,應該重點回歸!
18、忽視軟體測驗建檔
軟體測驗建檔,指的是軟體的測驗記錄是否有效的存盤,是否可查詢,如果測驗不建檔,那么測驗報告就無從考察,測驗結果也有沒有了依據,所以測驗建檔是必要環節,不可忽略,
19、軟體開發完成之后進行軟體測驗
軟體測驗是貫穿整個專案生命周期的,必須要在需求階段的時候介入,在單元測驗完成后就進行集成測驗也就是介面測驗,這可以發現80%的軟體缺陷,如果開發完成才介入測驗,那么專案發布上線的時間即將會大大延長,而且很多問題修復成本也將會大大增加,
20、軟體發布如果發現質量問題,都是測驗人員的錯
很多人都覺得測驗通過后,在用戶使用時發現bug一定是測驗人員沒有測驗到位而導致的,我曾經的作業中就經歷過多次這類問題,但是測驗人員堅持認為該功能缺失測驗過,并且沒有出現這類問題,后來經過本人的辯論終于找到了問題的原因,就是開發人員的疏忽導致封包封版時,沒有保存最新代碼導致問題出現,
首先,如果大家以后遇到這樣的情況出現,千萬不要心急如焚,手忙腳亂,要先確定該功能是否測驗過,是否通過測驗了,如果沒有測驗,那么毫無疑問測驗背鍋,如果測驗通過還出現了問題,極有可能是開發人員封版時沒有保存最新的代碼而導致的,或者是開發人員在發布最終版本時擅自修改了部分代碼,
21、專案進度緊的時候少做些測驗,時間富裕時多做測驗
專案測驗時間緊張的時候很容易出現測驗不到位,測驗不全面,導致發布后出現問題的情況,正常的處理辦法,應該是使用敏捷測驗方法,測驗范圍堅決不能縮水,測驗用例可以忽略掉表單值域的用例,著重撰寫流程性測驗用例,并且開發完成了一個模塊,測驗就測驗一個模塊,這樣可以大大加快測驗效率,本人很喜歡使用敏捷測驗的方法,不僅可以減少測驗時間,質量也不會打折扣,記住一點,敏捷測驗一定要對人員進行明確的分工,避免重復性測驗帶來的效率降低,
22、軟體測驗作業沒有前途,只有程式員才是軟體高手
相信很多人都認為測驗沒有開發人員厲害,這確實是市場現狀,很多測驗技術確實不如開發強,但是論前途,我覺得測驗比開發更有挖掘潛力,測驗的發展是多樣化的,而且范圍很廣,薪資也完全不亞于開發人員,真正的全堆疊測驗工程師,技術也絕不會輸給開發,甚至超越開發,小編在作業中,也經常會遇到開發人員前來向我請教性能技術和自動化技術,
23、軟體測驗就是保證軟體無故障運行
軟體測驗不僅要保證軟體無故障運行,更要保障軟體的易用性,健壯性,穩定性,安全性,兼容性,用戶體驗等一系列的因素,所以單純為了無故障則顯得有些膚淺了,
24、軟體測驗的環境就選用戶的環境
軟體測驗分為三個環境,分別是“測驗環境”、“HA環境”(準線上環境)、“線上環境”,用戶環境指的是第三個“線上環境”,而測驗的重點用該是在“測驗環境”和“HA環境”中,用戶環境中并不能隨意提交資料進行測驗,只能在最后beta驗收階段時才會采用這個環境的測驗,
25、開發人員更適合做軟體測驗
我們常常聽到這樣的問題:“為什么軟體的開發者們不適合測驗他們自己開發的軟體?”事實上,軟體開發人員測驗自己所開發軟體的行為就如同學生在完成考試試卷后再對自己的成績進行評估,這種做法毫無意義
(1)開發人員對其所寫代碼有主觀認同感
人們通常會對自己所犯錯誤視而不見或者拒絕承認,同樣的,在軟體開發領域,程式員們對待其開發的應用程式就像對待自己的孩子一樣,拒絕承認自己的孩子有什么不好的地方,這就是為什么軟體開發人員難于發現和改正自己的錯誤,
(2)開發人員對軟體過于樂觀的心態
開發人員進行開發的目標是將軟體所需的功能完美的展現出來,當程式的功能運轉正常的時候他們會自我感覺良好,因為他們的主要目標就是功能二字,而測驗人員與他們想的卻不一樣,測驗人員通常會從不同的角度切入進軟體內部,打破程式員們慣有的思維方式,通過各種不同的測驗用例把軟體潛在的不足之處引發出來,
26、bug越多測驗越有效
測驗Bug的數量并不能說明測驗的有效性,反倒能說明開發人員的技術水平,測驗bug數量多則改的代碼就多,改的越多,越可能引發其他問題的出現,甚至到后期bug越來越多,原本沒有問題的模塊也開始出現問題,測驗的有效性不能以發現bug的數量而決定,更應該根據問題的隱蔽性或嚴重性來決定,
27、關注測驗的執行而忽略了測驗的設計
執行測驗一定是按照提前設計好的方法進行的,測驗的方法就是測驗用例,如果不進行測驗用例的設計,直接進行測驗執行階段,再強大的測驗工程師也無法保證測驗的全面性,相信大家都知道撰寫測驗用例的原則,是100%的覆寫需求,可見測驗設計階段的重要性,
28、測驗是為了證明軟體的正確性
測驗不僅要證明軟體的正確性,更應該證明軟體是錯的,測驗人員不能只考慮正確的流程,往往出錯最多的是逆向思維測驗,反邏輯測驗,違背常規的測驗是最有效的測驗,所以說測驗不是為了證明軟體的正確性,而是恰恰相反的證明軟體的錯誤性,
覺得有用的話,文章和圖片都可以馬起來留著以后用!
一:必學基礎
不管是做什么作業,基礎都是非常重要的,首先我們進入一個行業的基本要求就是對這個行業的認識以及作業的流程了解清楚,一下就是我總結的測驗工程師應該必備的基礎知識:
測驗基礎概念
mysql資料庫
linux作業系統

二:介面測驗技術
介面測驗是測驗系統組件間介面的一種測驗,介面測驗主要用于檢測外部系統與系統之間以及內部各個子系統之間的互動點,測驗的重點是要檢查資料的交換,傳遞和控制管理程序,以及系統間的相互邏輯依賴關系,介面測驗需要學習的知識有:
介面測驗的原理
抓包工具的使用
介面測驗工具
協議拓展,正則運算式,資料處理

三:自動化技術
自動化測驗作為測驗行業需求最大的技術點,招聘要求隨處可見,進階高級測驗工程師必會點之一,什么?你不會代碼?學!什么?你代碼基礎薄弱?學!一句話,如果你連自動化都不會,那么你敢說自己是高級測驗工程師?自動化需要學習的東西如下:
自動化化基礎原理
webUI與Selenium框架
app自動化和Appium框架
robootFramework自動化工具

四:性能測驗技術
性能測驗是通過自動化的測驗工具模擬多種正常、峰值以及例外負載條件來對系統的各項性能指標進行測驗,負載測驗和壓力測驗都屬于性能測驗,性能測驗需要掌握的知識有一下幾點:
性能測驗基礎概念
性能工具lr
性能調優
性能報告方案

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/290849.html
標籤:其他
上一篇:您的嵌入式開發團隊的靜態代碼分析工具是什么? 這份指南你一定需要
下一篇:介面測驗知識
