若是公司只有我一個測試人員，我該怎麼辦？

 導語：「 我所在的公司目前就我一個測試，我一我的對接開發，對接產品，公司也沒什麼流程，我不知道我該作什麼，也沒有前人經驗能夠借鑑，我該怎麼辦？ 」

 

　　最近看到有不少剛剛步入測試行業的測試工程師發出這樣的疑問和求助，公司若是隻有我一個測試員，我該怎麼作才能把公司的工做作好呢？對於我我的發展來講，只有我一個測試，能有很好的發展前景麼？到底，這種狀況下我該走仍是該留呢？

 

**爲何會有這樣的現象**

　　首先咱們來分析一下，爲何如今這麼多公司都只有一個測試人員呢？這種現象產生的緣由大概有如下兩種：

　　第一，由於國家如今支持鼓勵自主創業，因此愈來愈多的初創型互聯網軟件公司拔地而起。這種類型的公司，處於剛起步的階段，資金都通常很是有限，因此基本只能承擔得起他們認爲必須存在的崗位，好比開發--創造生產軟件的人，銷售或者運營--可以直接幫助公司賺錢產生盈利的人；而後對於相似測試的崗位，是屬於錦上添花，而不是必須存在的角色。因此，你會發現，不少二三線城市的中小型企業，沒有設立測試崗位，基本都是開發本身開發完作簡單的自測就直接發佈上線。若是公司只設置了一個測試員的職位，也是司空見怪的，而且還說明該公司已經度過了最初始階段，開始慢慢認識到測試崗位的重要性，這反而是一種成熟進步的體現。

　　第二，也是源於國內對測試工做不重視。不少公司，認爲測試員作的事情沒有技術含量，點點點大法誰均可以作，因此讓開發作完後順便測一測，或者給到運營部門簡單試一試，基本就能夠上線了。他們對專業測試工程師的技能沒有認知，不能理解測試工做對產品質量的重要性，因此認爲測試崗位無關緊要，設置一個測試員的崗位，對他們來講已經知足到極致了。

 

**一個測試員的尷尬處境**

　　基於以上分析得出的目前互聯網行業的現狀，不少初入測試行業的測試員，在公司獨立擔當測試部門全部的工做，常常會遇到有心無力，步履維艱的尷尬處境。

　　通常在這樣的公司裏，是不會有任何規範的流程的，都是各部門的人根據本身的想法和意願來開展工做。好比，開發編程完成以後，直接發個包給測試員進行測試，沒有需求規格說明書來詳細描述這個項目的業務流程和用戶需求；開發也沒有流程來規範本身的單元測試，因此僅僅憑藉自覺和我的使命感，很難要求他們每一個人作到位，更別說提供相關的單元測試報告；因此測試並無寫測試用例的依據和基準，只能本身一邊熟悉開發給的軟件，一邊根據本身的理解來寫測試用例，這樣測試工做不只效率很低，並且也容易致使測試用例設計不充分和測試不完全的問題。

　　另外，開發對測試工做也沒有認同感，常常連續修改或者新增長需求，而後直接給版本到測試，測試基本都是按照開發的節奏來開展工做，測試工做徹底沒有自主性。常常，測試花了不少時間和努力測試產品，開了不少bug，開發並不會很積極的修復bug，固然也沒有流程來推進bug的修復，本身一個基礎測試員孤立無援，人微言輕，也說服不了開發，溝通效率很低，成果不好。

　　甚至，有時候，尚未等測試完成全部的測試工做，軟件產品已經默默的上線了，本身也沒有被通知。而後線上產品出了嚴重的問題，又會找到測試，要測試來承擔後果和責任。任何事情，好像都跟測試沒有真正的關係，深覺本身的工做沒有人重視，也沒有人理解，感受很被動，很無助。

 

**測試員該怎麼辦呢？**

　　那身處於這樣的公司，獨自一我的擔任測試崗位，面對這麼多的困難，咱們應該怎麼辦呢？不少人承受不住壓力，也感受本身無力扭轉局面，就想到要放棄，要離職跳槽。那除了選擇逃避，咱們難道沒有別的方式能夠嘗試了麼？難道沒有什麼能夠去努力去改善的麼？

　　答案是確定的，這樣的工做處境，若是你能很好的處理，能夠加速你的我的成長，積累到別人得不到的經驗值，甚至能幫你跟公司一塊兒成長，實現雙贏。那麼，要達到這樣的目的，咱們能夠從如下這幾個方面出發來開始行動。

 

>>>跟領導多溝通

　　首先，跟公司上級領導溝通，找到本身做爲一個測試員在公司的定位。領導既然設置一個測試崗位，而且招聘你進來作測試工做，確定是有本身初衷的，但願你能幫忙解決什麼樣的問題，而且達到什麼樣的效果，這是你須要經過溝通來明確的。

　　通常公司設置了測試崗位而且招聘到一個測試工程師，確定是對這個崗位的輸出有所期待的，任何一份工資和人力支出確定都是指望有所回報的。因此經過跟領導溝通，明確他但願你在這個崗位上達到什麼樣的效果，完成哪些工做，以及完成到哪一個程度。在這個基礎上，你再結合本身的想法，落實一些實質的工做計劃，而且提出一些建設性的意見和建議。好比，領導但願你盡我的之力，完成全部的測試工做，包括測試文檔和各個測試輸出，而且產品質量不容許存在任何紕漏。這樣的要求，很顯然，當前的現實情況是不容許的。因此你就能夠分析現狀，表達出本身的難處，固然儘可能不要顯出是本身的能力不足而不能擔當重任，而是現實骨感沒法超越；而後能夠提出一些實質性的建議。

• 若是是測試部門的初建階段，一我的確定是沒有辦法完成全部的工做的。因此能夠列出現有的工做量以及優先級，率先保證高優先級工做的質量和效率，好比產品的主要且重要模塊的功能和質量，必要的測試文檔的輸出等；若是以後還有餘力和時間，再覆蓋次優先級的模塊功能，完善各類細節和文檔輸出。
• 只有一個測試員的階段，不建議本身去實現自動化測試，除非領導能夠幫忙協調開發人員搭建自動化測試框架，而且合力去完成自動化測試的實現，否則一我的確定沒有辦法在保證項目發佈質量的同時，再去維護一個自動化框架的。因此這個時候，考慮自動化測試，不但不能節省人力和提升效率，反而會浪費時間和精力，拔苗助長。
• 建議讓項目相關人員協助測試工做，一塊兒保證產品質量。好比開發把握好單元測試的質量，儘可能把可以直接進行系統測試的產品交付給測試人員，保證有效的資源能被充分利用起來，達到理想的測試效果；讓運營部門人員參與到測試中，能夠由你寫出全部的測試用例，以及介紹一些主要的測試機巧和方法，而後分配任務到特定的人員。能夠由你本身主要重點模塊的測試，其他部門人員分擔一些其餘的功能模塊或者一些迴歸測試，這樣，一方面可讓相關部門人員知道測試不只僅是點點點，而是有法可依，有技術可尋的，認識到測試工做的技術性和專業性；另外一方面，全員測試，最大程度的對產品進行測試，共同努力保證產品質量。  
• 若是仍是沒有辦法知足測試要求，也能夠向領導申請招人名額，但是正式員工，也能夠是實習生。不要懼怕表達難處，也不要懼怕提要求，若是是合理而且有充分理由的要求，領導不只不會駁回，反而會以爲你是一個頗有想法，並且有在爲公司利益思考和努力的優秀員工。

　　固然，這些需求的提出，都必須創建在你充分且正確地評估了全部的測試工做量的基礎上進行，最好能有能夠量化的數據，以及一些不可規避可是能夠預見的風險，一塊兒呈現給領導並努力說服他，爭取獲得他的理解和支持。這樣之後工做中，有了強大的後盾，無論是部門之間的溝通，仍是工做責任劃分，均可以開展得更加順利。

 

>>>充分學習產品業務

　　測試也應該多跟需求和產品部門溝通，充分理解公司的業務主線，熟悉產品的功能流程。測試人員所須要必備的技能，其中之一就是業務能力，業務能力不足的測試工程師不是一個合格的測試人員！

　　何爲業務能力？就是你對當前你所測試的產品和功能模塊的理解，以及你對你所在的行業的認知，還有相關產品的業務和知識的儲備。相信咱們每個從事在測試行業的人，平時在公司裏都能發現一些這樣的狀況：總有些人在需求分析會議的時候，能提出一些跟你們不太同樣又頗有建設性的建議；也總有些人能在測試用例評審的時候，提出一些你沒先到可是確實對用戶場景頗有針對性的測試點；也總有些人拿到產品執行測試的時候發現bug的數量和質量都讓其餘人望其項背.....這就是業務能力的差別致使的對產品的理解和認知的差別。雖然，這個須要必定時間的沉澱和豐富的經驗積累，不是輕鬆簡單容易能夠得到的，可是，千里之行始於足下，業務能力的培養，就是從學習需求文檔開始的，而後經過跟產品和需求的溝通和討論過程當中不斷提升。在這個基礎上，你才能讓本身的測試用例更加充分，而且，若是須要別的部門人員協助測試的時候，你也能更好的分配工做，跟領導彙報的時候，也能更準確的評估測試工做量，測試過程當中，才能更有效的避免漏測的狀況，盡最大可能知足用戶的需求。

　　並且，更多的溝通和交流，也能促進部門之間的合做，當用戶需求發生變更的時候，或者測試過程當中遇到需求不明朗的時候，也能更高效地確認並獲得答案，良好的溝通老是能大大地提升工做的效率。

>>>制定並優化相關流程

　　觀察而且經過各方位瞭解目前你能看到的整個團隊的問題，梳理並總結給出你的建議。

　　通常只有一個測試崗位的初創型公司必然存在流程不規範甚至沒有任何流程的弊端，因此協助公司制定流程，或優化現有流程是個勢在必行的工做。制定一個完善的流程，不只能提升測試工做效率，也能讓各部門的職責劃分清晰明瞭，讓公司業務運轉更加順暢。

1. 制定測試流程，規範測試的工做，先從作好本身開始。

•  規範測試各個階段的輸出。如測試計劃，測試用例以及測試報告等文檔的輸出內容和格式。固然，由於是初期階段，全部的測試文檔不必定都是必須品，也不必定要特別詳細而且徹底符合規範要求，能夠制定一個初級版本，設立多個可視化的小目標，容許在往後工做過程當中一步一步地優化和完善；
• 規範bug 的編寫模板和跟蹤處理流程。如測試提bug 的時候須要提供的必須包含的信息（步驟，數據和日誌，以及現場截圖等）；bug處理過程當中，不管開發仍是測試修改bug狀態的時候，必需要添加相應的說明備註，方便後續跟蹤人員快速知曉整個過程。

　　 2.  制定部門之間的合做流程，幫助各部門協做更順暢。

•  規範產品管理需求的流程。如需求分析階段，必須提供規格說明書，以做爲開發和測試開始工做的依據；項目進行過程當中，尤爲是第一輪測試過程當中，不建議增長新的需求；項目臨近發佈階段，嚴禁加入新的需求；產品須要上線或者發佈，必須等到測試人員完成全部測試工做而且提交測試經過的報告文檔;
• 規範開發對接測試的流程。如開發交付產品的時候，須要提供單元測試報告，保證自測經過；開發修復bug 的時候，一樣須要提供單元測試報告，或者至少提供自測結果以及對測試的建議，以幫助測試進行迴歸測試；要求開發關閉bug爲非修復狀態的時候，必須跟測試溝通，獲得確認容許後再關閉，避免開發和測試之間的衝突矛盾；規定在項目臨近發佈階段，全部重要的代碼改動都應該慎重而且通過相關人員的審覈，以免嚴重的迴歸問題，或者發佈後的線上問題。
• 制定各項流程只有，還須要在流程裏說明，若是沒有按照流程規範執行，致使的問題和帶來的風險應該由流程打破者全權承擔。這樣才能更好的推進流程的執行，制定的流程才能發揮其最大的效益。

 　　公司的流程制定以及管理，能很大程度的提升工做效率。測試人員有則可依，不會太被動，被產品或研發打亂了測試節奏；責任劃分清晰，讓你們都明確本身該作到的本分，以及應該承擔的風險，這樣才能讓各部門的人合力合做，來保證咱們的產品的質量。

 

>>>豐富自身技術

　　小公司，測試部門只有一個測試員時，是高挑戰，同時也伴隨着着高機遇。因此咱們應該好好把握住機遇，讓本身伴隨着公司一塊兒成長。等公司足夠成熟了，你若是能夠獨當一面，就能夠擔當起測試部門負責人的角色，成爲測試部門的開創者。可是，在這以前，咱們須要先強大本身的知識體系，豐富自身的硬核技術。

• 豐富測試理論基礎。從軟件測試流程，到各類測試用例設計方法，以及各類類型的測試技巧，bug的處理流程和經常使用管理工具等，這些基礎知識都是須要完善和紮實，只有熟練掌握了這些測試理論知識，才能造成本身的測試思惟，成爲一個專業而且能指導他人的測試工程師；不然，沒有這些測試基石，一切高樓大廈都只能是空想而已。
• 在公司項目中去實踐所學習的測試方法和技巧。理論老是須要實踐才能出真知，因此能學以至用纔是真正的學會並掌握。因此在工做中多實踐並總結經驗，工做之餘再不斷豐富知識理論，也能夠去參加一些測試工程師的培訓班，實踐和理論相輔相成，讓本身的知識儲備日益豐厚。
• 最後，也能夠學習一些進階的相關技術，好比公司經常使用的開發語言，數據庫的一些知識，以及一些經常使用的測試工具，如抓包工具，日誌分析定位工具，自動化測試工具和性能測試工具等。想到達到必定的高度，這些技能的掌握也是必須的。

**總結**

　　公司若是隻有你一個測試員，請不要恐慌，也不要迷茫。要知道一切成熟大公司的團隊，都是從無到有，從初創到成熟。因此，先觀察一下公司以及公司領導人，判斷其是否有能力和魄力去實現一個公司從青澀到成熟的脫變；若是答案是確定的，請再判斷本身是否有足夠的能力和知識儲備去伴隨着公司一塊兒成長，同時，請審視本身是否有足夠耐心和決心來支撐這一份艱辛且漫長的成長；若是答案依然是確定的，那就不要退卻，更不要放棄，堅持過去這段低谷期，你就能看到勝利的曙光！

　　固然，若是前面的兩個問題，有任何一個答案是否認的，那也不須要遲疑，咱們能夠毅然離開，選擇一個更加適合本身的平臺，實現自身的最大價值。