導語：“ 我所在的公司目前就我一個測試，我一個人對接開發，對接產品，公司也沒什么流程，我不知道我該做什么，也沒有前人經驗可以借鑒，我該怎么辦？ ”
最近看到有很多剛剛步入測試行業的測試工程師發出這樣的疑問和求助，公司如果只有我一個測試員，我該怎么做才能把公司的工作做好呢？對於我個人發展來說，只有我一個測試，能有很好的發展前景么？到底，這種情況下我該走還是該留呢？
**為什么會有這樣的現象**
首先我們來分析一下，為什么現在這么多公司都只有一個測試人員呢？這種現象產生的原因大概有以下兩種：
第一，因為國家現在支持鼓勵自主創業，所以越來越多的初創型互聯網軟件公司拔地而起。這種類型的公司，處於剛起步的階段，資金都一般非常有限，所以基本只能承擔得起他們認為必須存在的崗位，比如開發--創造生產軟件的人，銷售或者運營--能夠直接幫助公司賺錢產生盈利的人；然后對於類似測試的崗位，是屬於錦上添花，而不是必須存在的角色。所以，你會發現，很多二三線城市的中小型企業，沒有設立測試崗位，基本都是開發自己開發完做簡單的自測就直接發布上線。如果公司只設置了一個測試員的職位，也是司空見怪的，並且還說明該公司已經度過了最初始階段，開始慢慢認識到測試崗位的重要性，這反而是一種成熟進步的體現。
第二，也是源於國內對測試工作不重視。很多公司，認為測試員做的事情沒有技術含量，點點點大法誰都可以做，所以讓開發做完后順便測一測，或者給到運營部門簡單試一試，基本就可以上線了。他們對專業測試工程師的技能沒有認知，不能理解測試工作對產品質量的重要性，所以認為測試崗位可有可無，設置一個測試員的崗位，對他們來說已經滿足到極致了。
**一個測試員的尷尬處境**
基於以上分析得出的目前互聯網行業的現狀，很多初入測試行業的測試員，在公司獨立擔當測試部門所有的工作，經常會遇到有心無力，寸步難行的尷尬處境。
一般在這樣的公司里，是不會有任何規范的流程的，都是各部門的人根據自己的想法和意願來開展工作。比如，開發編程完成之后，直接發個包給測試員進行測試，沒有需求規格說明書來詳細描述這個項目的業務流程和用戶需求；開發也沒有流程來規范自己的單元測試，所以僅僅憑借自覺和個人使命感，很難要求他們每個人做到位，更別說提供相關的單元測試報告；所以測試並沒有寫測試用例的依據和基准，只能自己一邊熟悉開發給的軟件，一邊根據自己的理解來寫測試用例，這樣測試工作不僅效率很低，而且也容易導致測試用例設計不充分和測試不徹底的問題。
另外，開發對測試工作也沒有認同感，經常連續修改或者新增加需求，然后直接給版本到測試，測試基本都是按照開發的節奏來開展工作，測試工作完全沒有自主性。經常，測試花了很多時間和努力測試產品，開了很多bug，開發並不會很積極的修復bug，當然也沒有流程來推動bug的修復，自己一個基礎測試員孤立無援，人微言輕，也說服不了開發，溝通效率很低，成果很差。
甚至，有時候，還沒有等測試完成所有的測試工作，軟件產品已經默默的上線了，自己也沒有被通知。然后線上產品出了嚴重的問題，又會找到測試，要測試來承擔后果和責任。任何事情，好像都跟測試沒有真正的關系，深覺自己的工作沒有人重視，也沒有人理解，感覺很被動，很無助。
**測試員該怎么辦呢？**
那身處於這樣的公司，獨自一個人擔任測試崗位，面對這么多的困難，我們應該怎么辦呢？很多人承受不住壓力，也感覺自己無力扭轉局面，就想到要放棄，要離職跳槽。那除了選擇逃避，我們難道沒有別的方式可以嘗試了么？難道沒有什么可以去努力去改善的么？
答案是肯定的，這樣的工作處境，如果你能很好的處理，可以加速你的個人成長，積累到別人得不到的經驗值，甚至能幫你跟公司一起成長，實現共贏。那么，要達到這樣的目的，我們可以從以下這幾個方面出發來開始行動。
>>>跟領導多溝通
首先，跟公司上級領導溝通，找到自己作為一個測試員在公司的定位。領導既然設置一個測試崗位，並且招聘你進來做測試工作，肯定是有自己初衷的，希望你能幫忙解決什么樣的問題，並且達到什么樣的效果，這是你需要通過溝通來明確的。
一般公司設置了測試崗位並且招聘到一個測試工程師，肯定是對這個崗位的輸出有所期待的，任何一份工資和人力支出肯定都是期望有所回報的。所以通過跟領導溝通，明確他希望你在這個崗位上達到什么樣的效果，完成哪些工作，以及完成到哪個程度。在這個基礎上，你再結合自己的想法，落實一些實質的工作計划，並且提出一些建設性的意見和建議。比如，領導希望你盡個人之力，完成所有的測試工作，包括測試文檔和各個測試輸出，並且產品質量不允許存在任何紕漏。這樣的要求，很顯然，當前的現實狀況是不允許的。所以你就可以分析現狀，表達出自己的難處，當然盡量不要顯出是自己的能力不足而不能擔當重任，而是現實骨感無法超越；然后可以提出一些實質性的建議。
- 如果是測試部門的初建階段，一個人肯定是沒有辦法完成所有的工作的。所以可以列出現有的工作量以及優先級，率先保證高優先級工作的質量和效率，比如產品的主要且重要模塊的功能和質量，必要的測試文檔的輸出等；如果之后還有余力和時間，再覆蓋次優先級的模塊功能，完善各種細節和文檔輸出。
- 只有一個測試員的階段，不建議自己去實現自動化測試，除非領導可以幫忙協調開發人員搭建自動化測試框架，並且協力去完成自動化測試的實現，不然一個人肯定沒有辦法在保證項目發布質量的同時，再去維護一個自動化框架的。所以這個時候，考慮自動化測試，不但不能節省人力和提高效率，反而會浪費時間和精力，適得其反。
- 建議讓項目相關人員協助測試工作，一起保證產品質量。比如開發把握好單元測試的質量，盡量把能夠直接進行系統測試的產品交付給測試人員，保證有效的資源能被充分利用起來，達到理想的測試效果；讓運營部門人員參與到測試中，可以由你寫出所有的測試用例，以及介紹一些主要的測試機巧和方法，然后分配任務到特定的人員。可以由你自己主要重點模塊的測試，其余部門人員分擔一些其他的功能模塊或者一些回歸測試，這樣，一方面可以讓相關部門人員知道測試不僅僅是點點點，而是有法可依，有技術可尋的，認識到測試工作的技術性和專業性；另一方面，全員測試，最大程度的對產品進行測試，共同努力保證產品質量。
- 如果還是沒有辦法滿足測試要求，也可以向領導申請招人名額，可是正式員工，也可以是實習生。不要害怕表達難處，也不要害怕提要求，如果是合理並且有充分理由的要求，領導不僅不會駁回，反而會覺得你是一個很有想法，而且有在為公司利益思考和努力的優秀員工。
當然，這些需求的提出，都必須建立在你充分且正確地評估了所有的測試工作量的基礎上進行，最好能有可以量化的數據，以及一些不可規避但是可以預見的風險，一起呈現給領導並努力說服他，爭取得到他的理解和支持。這樣以后工作中，有了強大的后盾，不管是部門之間的溝通，還是工作責任划分，都可以開展得更加順利。
>>>充分學習產品業務
測試也應該多跟需求和產品部門溝通，充分理解公司的業務主線，熟悉產品的功能流程。測試人員所需要必備的技能，其中之一就是業務能力，業務能力不足的測試工程師不是一個合格的測試人員！
何為業務能力？就是你對當前你所測試的產品和功能模塊的理解，以及你對你所在的行業的認知，還有相關產品的業務和知識的儲備。相信我們每一個從事在測試行業的人，平時在公司里都能發現一些這樣的情況：總有些人在需求分析會議的時候，能提出一些跟大家不太一樣又很有建設性的建議；也總有些人能在測試用例評審的時候，提出一些你沒先到但是確實對用戶場景很有針對性的測試點；也總有些人拿到產品執行測試的時候發現bug的數量和質量都讓其他人望其項背.....這就是業務能力的差異導致的對產品的理解和認知的差異。雖然，這個需要一定時間的沉淀和豐富的經驗積累，不是輕松簡單容易可以獲得的，但是，千里之行始於足下，業務能力的培養，就是從學習需求文檔開始的，然后通過跟產品和需求的溝通和討論過程中不斷提高。在這個基礎上，你才能讓自己的測試用例更加充分，並且，如果需要別的部門人員協助測試的時候，你也能更好的分配工作，跟領導匯報的時候，也能更准確的評估測試工作量，測試過程中，才能更有效的避免漏測的情況，盡最大可能滿足用戶的需求。
而且，更多的溝通和交流，也能促進部門之間的合作，當用戶需求發生變動的時候，或者測試過程中遇到需求不明朗的時候，也能更高效地確認並得到答案，良好的溝通總是能大大地提高工作的效率。
>>>制定並優化相關流程
觀察並且通過各方位了解目前你能看到的整個團隊的問題，梳理並總結給出你的建議。
一般只有一個測試崗位的初創型公司必然存在流程不規范甚至沒有任何流程的弊端，所以協助公司制定流程，或優化現有流程是個勢在必行的工作。制定一個完善的流程，不僅能提高測試工作效率，也能讓各部門的職責划分清晰明了，讓公司業務運轉更加順暢。
- 制定測試流程，規范測試的工作，先從做好自己開始。
- 規范測試各個階段的輸出。如測試計划，測試用例以及測試報告等文檔的輸出內容和格式。當然，因為是初期階段，所有的測試文檔不一定都是必須品，也不一定要特別詳細並且完全符合規范要求，可以制定一個初級版本，設立多個可視化的小目標，允許在日后工作過程中一步一步地優化和完善；
- 規范bug 的編寫模板和跟蹤處理流程。如測試提bug 的時候需要提供的必須包含的信息（步驟，數據和日志，以及現場截圖等）；bug處理過程中，無論開發還是測試修改bug狀態的時候，必須要添加相應的說明備注，方便后續跟蹤人員快速知曉整個過程。
2. 制定部門之間的合作流程，幫助各部門協作更順暢。
- 規范產品管理需求的流程。如需求分析階段，必須提供規格說明書，以作為開發和測試開始工作的依據；項目進行過程中，尤其是第一輪測試過程中，不建議增加新的需求；項目臨近發布階段，嚴禁加入新的需求；產品需要上線或者發布，必須等到測試人員完成所有測試工作並且提交測試通過的報告文檔;
- 規范開發對接測試的流程。如開發交付產品的時候，需要提供單元測試報告，保證自測通過；開發修復bug 的時候，同樣需要提供單元測試報告，或者至少提供自測結果以及對測試的建議，以幫助測試進行回歸測試；要求開發關閉bug為非修復狀態的時候，必須跟測試溝通，得到確認允許后再關閉，避免開發和測試之間的沖突矛盾；規定在項目臨近發布階段，所有重要的代碼改動都應該慎重並且經過相關人員的審核，以避免嚴重的回歸問題，或者發布后的線上問題。
- 制定各項流程只有，還需要在流程里說明，如果沒有按照流程規范執行，導致的問題和帶來的風險應該由流程打破者全權承擔。這樣才能更好的推動流程的執行，制定的流程才能發揮其最大的效益。
公司的流程制定以及管理，能很大程度的提高工作效率。測試人員有則可依，不會太被動，被產品或研發打亂了測試節奏；責任划分清晰，讓大家都明確自己該做到的本分，以及應該承擔的風險，這樣才能讓各部門的人協力合作，來保證我們的產品的質量。
>>>豐富自身技術
小公司，測試部門只有一個測試員時，是高挑戰，同時也伴隨着着高機遇。所以我們應該好好把握住機遇，讓自己伴隨着公司一起成長。等公司足夠成熟了，你如果可以獨當一面，就可以擔當起測試部門負責人的角色，成為測試部門的開創者。但是，在這之前，我們需要先強大自己的知識體系，豐富自身的硬核技術。
- 豐富測試理論基礎。從軟件測試流程，到各種測試用例設計方法，以及各種類型的測試技巧，bug的處理流程和常用管理工具等，這些基礎知識都是需要完善和扎實，只有熟練掌握了這些測試理論知識，才能形成自己的測試思維，成為一個專業並且能指導他人的測試工程師；否則，沒有這些測試基石，一切高樓大廈都只能是空想而已。
- 在公司項目中去實踐所學習的測試方法和技巧。理論總是需要實踐才能出真知，所以能學以致用才是真正的學會並掌握。所以在工作中多實踐並總結經驗，工作之余再不斷豐富知識理論，也可以去參加一些測試工程師的培訓班，實踐和理論相輔相成，讓自己的知識儲備日益豐厚。
- 最后，也可以學習一些進階的相關技術，比如公司常用的開發語言，數據庫的一些知識，以及一些常用的測試工具，如抓包工具，日志分析定位工具，自動化測試工具和性能測試工具等。想到達到一定的高度，這些技能的掌握也是必須的。
**總結**
公司如果只有你一個測試員，請不要恐慌，也不要迷茫。要知道一切成熟大公司的團隊，都是從無到有，從初創到成熟。所以，先觀察一下公司以及公司領導人，判斷其是否有能力和魄力去實現一個公司從青澀到成熟的脫變；如果答案是肯定的，請再判斷自己是否有足夠的能力和知識儲備去伴隨着公司一起成長，同時，請審視自己是否有足夠耐心和決心來支撐這一份艱辛且漫長的成長；如果答案依然是肯定的，那就不要退卻，更不要放棄，堅持過去這段低谷期，你就能看到勝利的曙光！
當然，如果前面的兩個問題，有任何一個答案是否定的，那也不需要遲疑，我們可以毅然離開，選擇一個更加適合自己的平台，實現自身的最大價值。