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

軟件測試行業急需大牛

　　記得2年前剛畢業的時候據說了軟件測試這個行業，當時也去百度仔細進行了一番搜索，評價基本千篇一概的看好。看好的緣由在於，專家認爲將來的互聯網市場用戶體驗至上，而產品質量與用戶體驗有緊密的聯繫，自從近年產品經理崗位火了以後，人人都是產品經理的概念深刻人心，但其實人人也都要具備質量觀念，出色的產品質量能夠提供更好的用戶體驗。

　　說被專家一席話打動有些牽強，當時就是由於本身的開發功底不足，退而求其次選擇了杭州軟件測試（www.proginn.com/users/hangzhou/csgcs/）一家公司謀生。而生活中不少事都要親歷了才知道到底是怎樣~其實，國內的軟件測試行業沒有書中以及媒體描述的那麼好，規範、流程都須要各個公司摸索制定。流程是否規範，對測試的能力要求高低，自動化與接口測試完善與否，不少工具平臺或軟件是否可以重複使用，這都說明着該公司在軟件測試方面的積累。

　　但凡接觸過軟件企業的人應該都知道，從公司的生態鏈來講，軟件測試屬於最下游，這也決定了不少狀況必需要被動接受。即便某個測試攻城獅理論知識豐富，辨識風險能力強，在測試中獨具慧眼，可是一個產品需求的變動就可讓他傻眼，接着很努力的去適應這種節奏。也許他抱怨，也許他吐槽，背後將產品、運營罵了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自動化和功能自動化有可能選擇不一樣的框架

　　第三，區分優先級，通常來講，使用頻率高的模塊優先考慮

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

　　十，介入需求必定要早

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

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