軟件測試必須要知道十個關鍵點

軟件測試行業急需大牛

　　記得2年前剛畢業的時候聽說了軟件測試這個行業，當時也去百度仔細進行了一番搜索，評價基本千篇一律的看好。看好的原因在于，專家認為未來的互聯網市場用戶體驗至上，而產品質量與用戶體驗有緊密的聯系，自從近年產品經理崗位火了之后，人人都是產品經理的概念深入人心，但其實人人也都要具有質量觀念，出色的產品質量可以提供更好的用戶體驗。

　　說被專家一席話打動有些牽強，當時就是因為自己的開發功底不足，退而求其次選擇了軟件測試一家公司謀生。而生活中很多事都要親歷了才知道究竟是怎樣~其實，國內的軟件測試行業沒有書中以及媒體描述的那么好，規范、流程都需要各個公司摸索制定。流程是否規范，對測試的能力要求高低，自動化與接口測試完善與否，很多工具平臺或軟件是否能夠重復使用，這都說明著該公司在軟件測試方面的積累。

　　但凡接觸過軟件企業的人應該都知道，從公司的生態鏈來說，軟件測試屬于最下游，這也決定了很多情況必須要被動接受。即使某個測試攻城獅理論知識豐富，辨識風險能力強，在測試中獨具慧眼，但是一個產品需求的變更就可以讓他傻眼，接著很努力的去適應這種節奏。也許他抱怨，也許他吐槽，背后將產品、運營罵了N多遍，但是毫無用處，產品運營主導必然是趨勢，測試主導是做不出好產品的。

　　還有一個點的確爭論了很久，就是關于出現問題承擔責任的問題。如果產品上線沒有問題那是皆大歡喜，如果有問題，幾乎所有人都會把測試拉上一起墊背。他們會認為就算上游環節各種問題，但是到了測試這里就應該“合理把控”各種，將風險點羅列出來并告知各責任人，有時候一句“為什么沒有測出來”竟讓測試同學無言以對。

　　看了以上的內容，各位看官會覺得戾氣太重，的確，測試的地位往往很尷尬，有種“別人狂歡有我毛事，出了問題我很悲催”之感。但不可否認的是，一個好的測試人員非常難得，懂業務懂代碼，寫的了接口測試，做的了性能優化，還能協調各種矛盾。所以好的測試可以成為好的開發，可以成為好的產品，可以成為好的運維……

　　一，軟件測試要做什么？

　　在每個軟件企業，測試人員參與的需求主要來自以下三個方面：

　　1，產品經理——針對產品本身，也許是功能優化，也許是模塊新增

　　2，產品運營——將產品配合運營活動展開，用于拓展新用戶及提升用戶活躍度

　　3，技術人員（開發主導）——技術改造或代碼重構

　　所以，對于測試人員來說，需要了解產品想怎么玩兒，用戶會怎么玩兒，運營想要用戶怎么玩兒，開發怎么實現，測試怎么進行，何為技術難點。我去！這是要把PD、運營、開發集于一身的節奏啊！

　　我相信在很多公司最了解產品的一定是測試，因為隨著測試人員盡早的參與整個流程，就會接觸所有的角色。所以總結下來基本就是測試比產品了解開發，比開發了解運營，比運營了解產品，還要最了解測試及產品質量。

　　二，軟件測試工程師的幾個階段

　　各行各業的成員都有不同的能力階段，軟件測試也不例外。依據每個人的能力不同，所做的事情是有明顯區分的，這里列出了常見的幾種進行分析。

　　1，手工測試（純黑盒測試），即使發現缺陷的能力非常強，也會很快遇到發展瓶頸，因為任何手工測試的風險都較高，并且投入產出比不盡如人意。項目變更后，能夠復用的只有個人經驗，對團隊建立與知識沉淀是幾乎無幫助的。（經驗可以分享？誰能保證人人適用呢。）

　　2，黑盒自動化測試，稍微進階了一些，提高了效率，可以做到定時自動執行，但是維護自動化腳本也是相當痛苦的，就算可以將一些代碼抽象為公共模塊，卻無法避免前端的改動。目前產品功能自動化測試都基于比較淺的層次，所以是否開展、以多大范圍開展是個值得仔細權衡的點。

　　3，接口測試（包括接口自動化），這算比較深入的，有時感覺當一個測試真正拋開了前端頁面，從接口層面開始介入測試時，他才真的成為了一名合格的測試攻城獅。此時可做的內容如滿天繁星，想象空間無窮。

　　4，性能測試，無論對于App還是后臺服務器，性能都是非常重要的點，專業的性能測試攻城獅對單一方向的要求很高，對性能問題的嗅覺也會更敏感。

　　5，白盒測試，這個方向非常高深，真正的白盒測試是要能夠去驗證代碼的正確性和有效性，這些攻城獅的水平應該高于很多開發。

　　好的測試真的很屌，不這樣覺得往往是因為沒發現。自己曾經“coding能力不夠，所以入了測試這行”的想法真的是圖樣圖森破啊。

　　三，軟件測試工程師的職位

　　就像文章開頭所說到的，好的軟件測業發展試工程師不僅能在測試崗位上繼續有造詣，也有能力從事一些其他崗位工作的，以下列舉出常見的，當然跨度很大的崗位調動肯定也會存在，只是這更大程度取決于個人能力與喜好，很難通用。

　　1，產品經理：我一直認為測試轉崗產品是很正常的，但是局限性在于測試能不能把眼光放高，原先是關注每個細節，而現在要考慮全局而有取舍。對產品的熟悉程度固然達標，但是能否將一個人的想法傳遞給你的leader及團隊還需要多加努力。

　　2，項目經理：測試轉項目經理的難度應當是最小的，許多能力是通用的，對技術的了解在一定程度也能夠支撐，但是在如今的互聯網企業都弱化了項目經理的概念，需要更快速的應對變化，去到一個逐漸被市場淘汰的崗位真的好嗎？

　　3，測試專家：這就自動拓展到上文中的軟件測試幾個階段了，如今的市場對專家級別的需求太急切了，軟件測試在國內發展的年限不久，可想一個專家是多么搶手的。

　　4，運維工程師：這個轉崗有一定的難度，但是如果本身接觸的就是服務器的測試工作，并且對服務器的各種操作都很熟悉，轉崗還是很有希望的。

　　四，軟件測試工程師的一些誤區

　　1，發現的問題停留于表面，而不繼續深挖

　　2，對整個產品沒有宏觀概念，而緊摳每個細節

　　3，測試執行對于質量保障的作用不超過50%，真正想要做好，應當從上游開始慢慢規范4，一味相信自動化測試

　　5，不要認為測試工程師的任務僅僅是測試

　　6，不區分測試重點，認為測試做到大而全總是沒錯的

　　五，軟件測試工程師的好習慣建議

　　1，先分析，再執行，這樣會事半功倍

　　2，測試的最終目的是把控目的，不要想著找出所有bug

　　3，堅信測試工程師也是有地位的，對于產品、運營那些變態的需求學會合理拒絕，測試工作當然自己做主

　　4，MindManager、流程圖等軟件經常使用，會對你的思維拓展有幫助

　　但絕不是做好了上面五個環節就能代表自己很出色，因為你一定還聽說過“bug是找不完的”這么個預言。

　　那么問題來了，軟件測試到底是要做什么！

　　這個問題有些糾結，因為翻開書，都會先把軟件工程大篇幅描述一遍，然后告訴你一整套規范的軟件企業流程，具體怎么用，幾乎沒有涉及。當你了解之后，進了公司，發現“我X，完全不一樣”，說好的這些規范怎么都不執行，這個公司是不是不靠譜啊。

　　答案當然是否定的，leader當然知道需求的變更、開發的延遲都會對軟件質量帶來風險，但是對當下的市場來說，按照流程按部就班肯定不符合大局。那么測試工程師要怎樣適當地將風險降低呢？分享一些小經驗，對于大牛來說直接跳過吧。

　　七，熟悉產品各個模塊

　　對任何一個產品，增加對產品的熟知程度總歸不是壞事。當知道產品的開發邏輯是怎樣的，便能很好的響應需求變更。

　　舉個例子，產品的需求原本使用A方案實現，卻由于需求進行了微調，使用B方案將更適合。對于沒有經驗的產品經理，往往從開發那里獲取方案，此時開發流程已經開始，調整方案將會增加工作量，帶來風險是必然的，那么對測試來說，該如何給出建議？

　　如果對產品邏輯不知曉，當然是任由開發“擺布”，后期二次改動同樣需要工作量。但如果熟悉產品邏輯，可以將兩種實現方案進行比較，列出優缺點進行評估，最終采用更合理的方式解決問題。

　　所以，對產品各個模塊的熟悉是測試人員一個非常必要的能力。

　　八，對于測試用例的優先級明確劃分

　　在測試時，大家總是會忽略測試用例的重要性。一個產品動輒上千的用例實在讓人頭疼。但是，好的測試用例能夠幫助測試工程師在時間緊急的時候提高測試效率。

　　測試工程師對測試用例一定不陌生，但是挑選待執行的用例時往往比較隨意，有一句話特別好，“差不多就行了”。但這個差不多往往是坑了自己，工作量變大，有效性可能降低，反而得不償失。

　　九，能做成自動化測試要努力

　　如果你有想法把產品的部分功能做成自動化測試，那么恭喜你，至少為自己減少工作量提高效率找了一個好思路。But，自動化沒有想象中那么簡單。

　　首先，得要研究不同的自動化測試框架，并且找到當前產品適用的

　　第二，區分好產品模塊，哪里適合，哪里不適合，比如UI自動化和功能自動化有可能選擇不同的框架

　　第三，區分優先級，一般來說，使用頻率高的模塊優先考慮

　　另外，實現時一定要考慮方案是否完善，一個半成品的自動化測試代碼更加坑人。

　　十，介入需求一定要早

　　千萬不要認為測試工作開始于開發的動工，了解需求對于測試工作太重要了。工作中，經常會出現產品經理描述需求不明確，或者產品、開發、測試三方理解不一致，提前統一戰線必然有利于降低風險。

　　同時，討論評估需求時，測試工程師可以從需求的來源進行分析，提出這個需求是不是該這么做，雖然沒有太多的工作量，但是對于產品的質量和可用性是很有好處的。

程序員杭州軟件測試杭州APP開發杭州PHP工程師