【轉】搜狗測試經理分享

在回答你們問題以前，我先分享下管理理念，同時結合搜狗測試的經驗，對其中的概念進行舉例說明。

1、領導力模型：

打造高產出測試團隊的過程，其實也是領導力打造的過程，過程以下。

      

1.      以身做則。

這個很簡單，不用過多解釋。若是指望團隊有高度的責任心、有很強的學習氛圍，那麼做爲Leader首先要以身做則，不然再談管理都是奢求。

2.      共啓願景。

a)        樹立本身的願景和目標。

做爲團隊的Leader，首先問問本身，本身的目標和願景是什麼：是作好眼下的測試工做便可；仍是但願在知足項目任務的同時，還能作點技術性提升的工做(自動化、性能測試)；仍是但願在測試領域進行更多的探索，成爲領域專家，把團隊打造像谷歌測試同樣的高標準團隊。咱們心中先要有這個目標和願景，這是驅動咱們去打造一支高產出團隊的核心動力。

舉例：搜狗測試團隊的願景就是打形成爲一支業界專業的測試團隊，這個願景和信念，咱們是逐步樹立起來，而且堅決不移的。

b)        感召他人。

將來的目標和願景不是一我的就能實現的，須要有一羣有共同目標和理想的人一塊兒努力才能實現，因此咱們須要找到這樣的人，這一環節咱們稱之爲感召他人。

感召他人不是強求，團隊中必定會有一部分人不認同你的願景，不要緊隨他去。但也要堅信必定會有部分人認同你的願景，咱們只要作的事情是發現這樣的人、辨別真僞，最終找到他們。

c)        樹立榜樣。

搭建一個平臺或者經過某種制度，讓團隊中的成員可以彼此瞭解到每一個人的工做表現，爲團隊樹立榜樣。

舉例：在搜狗瀏覽器測試團隊，咱們有一個制度：每一個季度團隊每位成員進行目標公示和述職。這個過程當中團隊每位成員要講本身在作什麼，如今的進度如何，把作出來的成績show給你們。在這個過程當中，團隊中的榜樣就會逐步樹立出來。

3.      挑戰現狀。

這一環節，最重要的發現團隊中的問題，將問題排定優先級，針對高優先級的問題，分析緣由，找解決方案，而後去執行。

舉例：咱們在團隊內部搭建了一個知識庫的系統，在這個系統上，團隊成員能夠將本身的經驗進行總結，而後發文章出來。可是一段時間內，團隊成員的分享熱情不是很高，須要Leader不斷去push。

爲了解決這一問題，咱們作了這麼幾件事：

1)      激勵鼓勵。每月對知識庫的發文數量和質量高的同窗，進行獎勵，獎勵是一本書。

2)      培養組員的總結意識。在平常工做中，Leader挖掘能夠進行總結的點，與組員一同分析，推動組員完成總結。

3)      提高組員成就感。在組員分享文章後，Leader要看組員的文章，若是有分享意義的話點贊。若是分享意義很大的話，鼓勵組員投稿到51testing等影響力更大的論壇。

4)       最後，還有一點，績效考覈。將經驗總結髮知識庫文章列爲績效考覈中的一項，而且明確衡量標準。

經過以上的努力，團隊中逐步涌現出來一批優秀的成員，我所帶領瀏覽器測試團隊在每一個季度會在搜狗內部知識庫發表上百篇文章，其中有幾篇在51tesing投稿後被錄入期刊雜誌。

 

file:///C:/Users/Deadwalk/AppData/Local/Temp/msohtmlclip1/01/clip_image004.jpg

4.      使衆人行。

這一環節最重要的是，搭建團隊成員的溝通交流平臺，促進團隊中與咱們有着相同目標和願景的成員一同交流和工做。

舉例：搜狗測試團隊的內部交流平臺有微信公衆號編輯部、技術委員會、管理委員會等交流平臺。以微信公衆號編輯部爲例：

1).      微信公衆號編輯部分別有5個微信組：黑盒組、白盒組、自動化組、項目管理組、團隊文化組。

2).       每一個組有4-5位成員，他們每週會固定時間進行問題溝通、討論、最終完成當週的微信推文。

5.      激勵人心。

經過各類資源(晉升、加薪、內部獎項設立、公司牛獎的爭取等手段)來鼓勵和激勵團隊中表現優秀的成員。

舉例：仍然以微信公衆號編輯部爲例， 每1個半月會進行各個組的評比活動，每一個組須要派表明對前一階段的工做進行述職，而後編輯部的全體成員進行記名投票，選出最優秀的一組，頒發啄木鳥獎盃和獎金。

 

如何搭建一個高產出的測試團隊，這塊確實不怎麼了解，本身一我的撐着這麼多項目，其實挺累的，也沒有好的方法去優化
1.公司作的都是小型的項目，同步進行項目的有兩三個。
2.測試人員就只有一個

怎麼才能建設好測試的管理和產出？

 

我先以測試團隊只有你一人做爲前提，給下個人建議吧：
1.明確當前項目的目標。由於測試團隊是支持性團隊，因此測試團隊規模大小及目標，是與項目目標相匹配的。若是當前項目是屬於創業型團隊，短時間內測試團隊的目標就是完成項目任務爲主，那麼我以爲還談不上搭建團隊，更談不上搭建高產出的測試團隊了。若是當前項目已經有用戶基礎了，正在逐步擴張的過程，那麼測試團隊的資源也應該隨之進行調整。

2.爭取測試資源。從你的描述來看，彷佛你我的已經沒法支撐項目任務了，因此是否是要想上反饋正確更多的測試資源。

3.保證基本的測試產出。項目任務再多，這也不妨礙咱們作一些基本的總結，例如：測試過程當中的問題有哪些、測試過程當中學習到的知識有哪些。這些內容將它總結起來造成文檔，往後對我的是有很大幫助的。

 

痕跡，你好
首先感謝你的提問。我將你提出的問題拆分出來分別回答

問題1：目前咱們公司測試部門都是執行手工測試，測試人員對自動化測試都不熟悉，而老闆忽然之間要求整個測試部門人員要用自動化來測試，
且必須立刻要會，這種狀況下，該怎麼樣才能讓全部測試人員迅速學會自動化測試呢？而後有什麼方法能避免老闆由於測試人員沒有立刻掌握自動化技術，而不滿呢？

回答：在回答這個問題以前，我以爲咱們仍是有必要搞清楚幾個問題：
1)老闆忽然之間要求整個測試部門人員要用自動化測試的緣由是什麼？是由於對測試質量不滿意，仍是由於對測試效率不滿意？仍是由於其餘什麼緣由。

2)若是老闆是由於測試質量不滿意，那麼出現了什麼樣的問題，這些問題經過自動化測試是否是就能保證?

3)若是老闆是對測試效率不滿意，指望經過自動化測試提高效率，那麼就是這個工做如何開展的問題了。進一步咱們要想的是：
a.這個工做如何開展，是否是能夠考慮部分人員先掌握自動化技術，部分人仍是保持原有的手工測試。
b.若是全部人員都掌握自動化技術可能帶來什麼樣新的問題？好比：能力相對低的人可能投入很是高的學習成本；沒有意願的人可能學習不會；有能力有意願的人學會以後存在穩定性的問題等等。這些問題老闆是否又是知道的？ 


問題2：同時由於老闆對測試部門不是很看重，故測試人員的薪資都廣泛很低，致使測試人員的積極性不是很高，且對公司的熱情不高，產品質量相對也受到了一些影響，這樣會致使公司對員工不滿意，員工對公司老闆也不滿意，造成一個惡性循環。該怎麼解決呢？
回答：說老實話，這個問題是個不太好回答的問題。我只是說說本身的見解，如何不妥，歡迎你們指出批評。
意識形態：
1)看清狀況，堅決本身的信念。不能否認，國內存在大量的企業和公司，對測試部門不重視的狀況，相應的待遇也會低許多。形成這一問題的根本緣由是，測試這一行業在國內在發展才區區幾年，相比較開發崗位發展數十年，咱們還在起步階段。再加上國內在測試行業各式各樣的人都有，也在必定程度上形成了外界對測試行業的水平低的認識。這個問題是客觀存在的，咱們怨天尤人也沒用。測試的將來只有經過你們一塊兒的努力，讓咱們作的事情愈來愈有價值，讓咱們愈來愈受重視。做爲團隊的Leader，首先不能丟了這個信念。
2)證實文化。鑑於搜狗測試團隊的過去經驗，也是這樣一個過程：基於手工測試、竭盡全力地加班加點保證項目的質量--逐步獲得上層領導的確定--領導逐步給予了部分資源支持--開始嘗試自動化測試領域--進一步獲得領導的承認---再給予資源支持。因此，我只能說：哥們，我知道你如今很苦，但惟有經過證實文化讓領導認識到測試的價值。
具體問題：
談了前面2點意識形態以後，該回答實際具體的問題解決方法上了。

1)    是否全部的員工都對公司不熱情？是否有潛力的員工是能夠挖掘的？

2)    是否能夠經過將資源從新調配的方式，保證與你有着一樣的意識形態、與你有着同一目標的員工留下，與他們一同保證好產品的質量，進而進一步爭取更大地支持。

 

 作爲測試團隊管理人員，請問下您在平常的技術提高和管理工做是如何把握平衡的？以前作的項目遇到過徹底放棄技術只管理人員和平常工做的模式，這樣很容易不服衆並且在關鍵技術問題上給不出有效意見；若是投入很大精力去關注技術，又會浪費不少時間沒法統籌管理項目；還請大牛hi, 感謝你的提問。你的提問的確是如今周邊不少同事提到過的問題：作純管理，沒有技術難以服衆；兼顧技術和管理工做又難以平衡時間。這樣的問題該如何處理。

我說說本身的經驗感覺，若是不妥，歡迎指正。

1.      技術與管理的轉換。我將技術管理崗位的工做狀態分爲三個階段:

a)        純技術階段：剛作管理崗位時，因爲對管理知識不是很重視(如人員談話、團隊氛圍打造等等)，因此精力基本都放在技術方面上，工做內容也主要是知足項目的各類工做。

b)        狂補管理知識階段：由於前期不重視管理，致使了各類管理問題：人員離職了，發現不會員工談話，學習人員談話；組員工做士氣低落了，學習激勵鼓勵；人員有缺口不會面試了，學習招聘面試；對兄弟團隊溝通被投訴了，學習溝通技巧等等，因此在這個階段狂補管理知識，基本上是缺什麼補什麼，也是我本身整個工做過程當中最苦逼的一個階段。

c)        迴歸業務階段：上一個階段，隨着本身不斷地遇到問題，不斷的學習惡補，終於發現本身在員工談話、績效考覈、招聘面試、團隊結構等方面逐步駕輕就熟的時候，就開始迴歸業務，學習業務中各項的技術。

隨着團隊的不斷髮展，也會在管理上不斷遇到問題(例如空降到一個新的團隊)，仍然會不斷地學習，可是會相比以前更加從容了。因此，挺過第二個階段，也許你會有更多的精力學習技術。

2.      技術的學習途徑。技術積累的途徑也是多樣的，在早期非管理崗位時能夠經過自我學習進行積累；後期作管理崗位時，可讓組員進行學習總結，而後將總結後的內容講解給你。

3.      技術的瞭解深度。管理者瞭解技術的目的通常來講是：招聘面試、人員培養、決策制定。基於這三點，只要我瞭解的技術不影響個人招聘面試考察、人員培養以及相關的決策，那麼我對於技術的瞭解程度就不用過深。舉個例子：搜狗網址導航首頁這個項目，我做爲管理者只是瞭解到框架結構，例如整個項目都有哪些模塊組成；前臺頁面和後臺是如何通訊的；數據存儲在哪裏，經過什麼方式得到……可是更爲具體的知識點如Redis的字段都有哪些，經過哪些命令進行讀取寫入，如何進行Redis的持久化存儲等等若是沒有精力適可而止。

最後，分享下個人時間分配和管理職責：

1.一週5天，有3天是管理相關的工做，2天是業務技術相關的工做。

2.我目前的管理職責有：團隊目標規劃、團隊人力結構規劃、團隊問題收集與解決、向上工做彙報、總結&述職、衝突解決、考勤管理、績效考覈、晉升&加薪管理。

3.之前是個人管理職責，可是通過後期人員培養，已經下放的權限有：項目管理(方案制定&進度控制)、人員培養、招聘面試、會議組織、人員談話、TB活動組織、項目彙報等。

 

你平日的工做內容有哪些，做爲Leader，你的工做量確定要大，搜狗瀏覽器日益穩定，手動及自動測試大家應該天天都跑一遍，因此幾乎不會有什麼bug了。除非開發新增長了某個應用，而後大家集中測試，是你們都手動而後自動，仍是部分人手動，部分人自動呢？
若是某天瀏覽器發展很穩定了，大家的工做又是什麼呢，除了自動跑用例外

 

您好，我想問下，您的測試團隊是怎麼制定績效考覈標準的呢？另，如何寫季度計劃或目標呢？咱們公司主要是什麼項目來了就測什麼項目，測試團隊很難本身把控制定測試計劃

1、績效考覈的原則：smart原則
Specific——明確性
     所謂明確就是要用具體的語言清楚地說明要達成的行爲標準。明確的目標幾乎是全部成功團隊的一致特色。不少團隊不成功的重要緣由之一就由於目標定的模棱兩可，或沒有將目標有效的傳達給相關成員。

     BadCase：
     在2015年Q1目標制定時，測試技能目標是「提升測試設計能力」，這樣簡單的看沒有什麼問題若是仔細來看，這個目標很不明確，提升測試設計能力方法有不少例如：掌握瞭解測試設計方法、增強測試敏感度等，提升測試設計能力這個目標制定是失敗的

      改進方案：
      修改後的測試能力目標設定爲：完成三次B級模塊測試用例設計，這樣就很明確了。

Measurable——可衡量性
      衡量性就是指目標應該是明確的，而不是模糊的。應該有一組明確的數據，做爲衡量是否達成目標的依據。

      若是制定的目標沒有辦法衡量，就沒法判斷這個目標是否實現。好比領導有一天問「這個目標離實現大概有多遠？」團隊成員的回答是「咱們早實現了」。這就是領導和下屬對團隊目標所產生的一種分歧。緣由就在於沒有給他一個定量的能夠衡量的分析數據。但並非全部的目標能夠衡量，有時也會有例外，好比說大方向性質的目標就難以衡量。

     badCase：
     2015年Q1目標設定時，衡量固定渠道包自動化完成狀況時，寫的是高質量完成固定渠道包自動化腳本，其實這個標準是不可衡量的，什麼是高質量？沒法進行評定
     改進方案：
     修改後的衡量標準爲：固定渠道包自動化腳本可以運行且沒有BUG，這樣的衡量標準是有辦法衡量的。

Attainable——可實現性
       目標是要可以被執行人所接受的，若是上司利用一些行政手段，利用權利性的影響力一廂情願地把本身所制定的目標強壓給下屬，下屬典型的反映是一種心理和行爲上的抗拒：我能夠接受，可是否完成這個目標，有沒有最終的把握，這個可很差說。一旦有一天這個目標真完成不了的時候，下屬有一百個理由能夠推卸責任：你看我早就說了，這個目標確定完成不了，但你堅持要壓給我。
    
      「控制式」的領導喜歡本身定目標，而後交給下屬去完成，他們不在意下屬的意見和反映，這種作法愈來愈沒有市場。今天員工的知識層次、學歷、本身自己的素質，以及他們主張的個性張揚的程度都遠遠超出從前。所以，領導者應該更多的吸納下屬來參與目標制定的過程，即使是團隊總體的目標。

      定目標成長，就先不要想達成的困難，否則熱情還沒點燃就先被畏懼給打消念頭了。

     問題：
     在計劃制定時，沒有本身去評估工做量就將其寫入計劃中，致使的就是一個季度過完後，計劃沒有完成

     改進方案：
     切合實際的制定本身能力範圍內的計劃，就算是要學習一門編程語言也是同樣，不能一口吃一個胖子。

Relevant——相關性

      目標的相關性是指實現此目標與其餘目標的關聯狀況。若是實現了這個目標，但對其餘的目標徹底不相關，或者相關度很低，那這個目標即便被達到了，意義也不是很大。

      由於畢竟工做目標的設定，是要和崗位職責相關聯的，不能跑題。好比一個前臺，你讓她學點英語以便接電話的時候用得上，這時候提高英語水平和前臺接電話的服務質量有關聯，即學英語這一目標與提升前臺工做水準這一目標直接相關。若你讓她去學習六西格瑪，就比較跑題了，由於前臺學習六西格瑪這一目標與提升前臺工做水準這一目標相關度很低。

Time-bound——時限性

      目標特性的時限性就是指目標是有時間限制的。例如，我將在2005年5月31日以前完成某事。5月31日就是一個肯定的時間限制。沒有時間限制的目標沒有辦法考覈，或帶來考覈的不公。上下級之間對目標輕重緩急的認識程度不一樣，上司着急，但下面不知道。到頭來上司能夠暴跳如雷，而下屬以爲委屈。這種沒有明確的時間限定的方式也會帶來考覈的不公正，傷害工做關係，傷害下屬的工做熱情。

      實施要求：目標設置要具備時間限制，根據工做任務的權重、事情的輕重緩急，擬定出完成目標項目的時間要求，按期檢查項目的完成進度，及時掌握項目進展的變化狀況，以方便對下屬進行及時的工做指導，以及根據工做計劃的異常狀況變化及時地調整工做計劃。

      總之，不管是制定團隊的工做目標，仍是員工的績效目標，都必須符合上述原則，五個原則缺一不可。 制定的過程也是對部門或科室先期的工做掌控能力提高的過程，完成計劃的過程也就是對本身現代化管理能力歷練和實踐的過程。
2、績效考覈的內容：
   1.從問題出發，根據問題制定行動方案，對目標制定衡量標準。
   2.績效考覈的內容：除了完成既有的測試項目(我稱之爲固有職責)，還能夠添加一些提升方面的目標。例如，在個人測試團隊中前後經歷過這幾種目標：
         a.固有職責+知識沉澱
         b.固有職責+突破(技術突破或者我的問題解決)+創新
         c.固有職責+影響力+創新   （目前是這個衡量體系）
  附一張組內的績效考覈表格 <ignore_js_op>  

 

您好，我還想問下，怎麼總結本身的工做貢獻呢？總以爲幹了不少的活，可是到總結的時候無從寫起，也不知道本身從中學到了什麼，能給些建議麼？

這個問題還真是個很差回答的問題。我提供下我工做總結的角度以供參考吧。
1.業務測試質量。
2.團隊結構
   a.人員招聘成果
   b.人員培養成果
3.團隊氛圍
   a.團隊TB活動
   b.團隊會議產出狀況
4.團隊積累程度
   a.文章總結
   b.公共用例庫創建
   c.對內講座
   d.對外影響力打造
5.技術創新：
   a.自動化測試
   b.白盒測試
   c.性能測試
   d.黑盒測試改進
6.管理創新：
   a.流程規範改進
   b.工做方法改進
....
還有不少，再也不一一列舉，請本身發散想吧。

 

你好，咱們是總員工數20幾個的小小公司，測試團隊目前共有3人。
我在這家公司也已待了三年。剛進公司不久，就委任我爲測試部負責人，
一兩年前，公司老總就想讓咱們搞自動化測試，
可是沒人沒技術，而且都把自動化想的很美，也不看看適不適合搞。
基於種種緣由自動化一直沒弄。咱們都是給客戶作傳統項目的，也一直在弄本身的產品平臺，可是到如今，
也沒有穩定的產品版本出來。
因爲各類個各樣的緣由吧，領導對個人工做有了見解。
目前我又懷孕了，因此由別人暫代測試部負責人了，這種狀況下，我將何去何從？
或者公司的自動化將如何開展？

自動化一直沒有作起來的緣由具體是什麼呢？

基於之前的經驗，要作自動化須要注意的幾個事項：
1.自動化準則問題，即什麼樣的模塊適合作自動化測試？根據以往的經驗：
   1)需求穩定的模塊適合作自動化，但願頻繁變動的不適合。
   2)功能邏輯層強的模塊適合作自動化(例如搜狗瀏覽器的收藏功能有添加、刪除、拖拽等等)，純UI層的模塊不適合作自動化。
   3)新功能不適合作自動化，須要反覆迴歸的模塊適合自動化。自動化的目的主要是將測試人員從重複性的工做中解放出來，主要是迴歸測試用。
2.自動化的收益比，即投入產出比問題。投入成本有：
   1)人力成本，包括人員招聘、人員培養。
   2)自動化腳本的開發成本。
   3)自動化腳本的維護成本。
   針對以上3個成本，咱們須要儘量想辦法去下降成本，例如培養一我的掌握自動化和外面招一個有經驗的自動化工程師相比，若是後者成本低則採用後者。
3.工具意識問題。自動化在我看來只是提升工做效率的方式之一，除了用例自動化的方式以外，咱們還有不少中提升測試效率的方法，例如開發便捷的測試工具。

 

我想問下大家在寫自動化自動化測試腳本或者搭建測試環境中若是碰到沒法解決的問題，通常都是怎麼解決的？常去的網站的有哪些？是否是國外的社區比國內的社區反饋會更有效率和更有幫助？謝謝！

1.遇到沒法解決的問題，通常是怎麼解決的。
   這個解決的方法不少，總結的來講有這麼幾種：
   1)靠本身思考和分析。遇到問題不會立刻上網查找，首先仍是要本身打log、單步調試去查找緣由。好比：咱們在編寫一個自動添加收藏的用例時，在某些環境會添加失敗。經過打log等方式，在腳本中定位出來在部分機器環境上，窗口的類名參數會有不一樣，致使自動化腳本識別失敗。
   2)上網搜索查資料。通常是google，搜索的範圍很廣，沒有特定的網站。
   3)求助公司內部能力更強的人。如其餘團隊的牛人，或者求助開發。好比：咱們在進行搜狗瀏覽器自動化測試時，因爲新版瀏覽器採用了DUI技術，這使得窗口根本沒法識別。這時候咱們與開發溝通後，一同進行協做，開發在瀏覽器代碼內部提供UIA自動化接口，測試開發工程師在外部對UIA的庫函數進行封裝，最終，咱們一同解決了瀏覽器的自動化問題。

 

大神你好！有點糾結.
狀況是這樣的.如今在一家作證劵軟件的公司上班.被測試的軟件是用c++寫的。如今看開發代碼調試找bug都沒問題.可是不怎麼會寫.看外面的職位要求高一些的測試都是要會java.python和vbs等等這些。如今的狀況是 我java和c++都不怎麼精通.網上說c++很是難不是專業開發人員沒有必要學這個.因此搞得我很糾結.我原本準備學c++的(畢竟公司周圍都是c++大神)又擔憂駕馭不了學個半桶水還不如學個簡單的好比java學得相對熟悉一點更加靠譜,但願羣主能指點一下.

chb447，你好
C++的確是一門比較難的語言，以前作開發的時候聽前輩們說，通常須要3-4年的持續不斷學習和鍛鍊，才能在C++領域成爲駕輕就熟的專家，因此足見其難度。但話又說話來，C++若是熟練掌握，那麼其餘的語言則不成問題，因此學什麼語言不成核心問題，核心問題是編程能力和coding能力的水平。
基於以上的問題，個人建議是：
搞清楚你要獲得的是什麼。
   若是是在現公司要將測試的深度進一步加深(如單元測試)的話，那麼必然還得死磕C++。
   若是是在現公司要將自動化測試水平提高的話，那麼外圍的Python\java等語言均可以達到，因此能夠考慮學一些高級腳本語言。
   若是是看到其餘公司的JD描述要求python考慮跳槽的話，那麼我能夠負責任地告訴你，JD描述的具體語言不是關鍵點，仍然是編碼動手能力和紮實的基礎。因此繼續學習C++不矛盾，只要你學得紮實，有很強的動手能力，那麼新公司仍然會接收你。

 

你好，諸葛先生。我是一名純手工測試人員，從事黑盒測試也有幾年了，以前一直在深圳發展，在恰好學習了點東西且工做能夠駕輕就熟的時候轉到本身的家鄉發展了，可能因爲家鄉發展的機會很少，也沒有像那些一線城市在這行的各方各面的壓力，致使目前工做一直比較安逸。幾年了，感受還在吃老本，還在用着兩年前的思惟與技術（一個小公司，測試不受重視是一方面。另外一方面作的是純手工的web界面測試），這讓我很不安。如今由於一些私人緣由目前沒有換工做，但之後也不想這麼發展下去。因爲本人對代碼還有必定的興趣（熟練C語言，瞭解點JAVA），且深知自動化測試的優點與發展趨勢，雖然公司目前用不到自動化，但想將學習自動化做爲本身的前進目標。我如今的疑問就是不知道從哪裏下手，只知道本身要學的東西不少，因此想麻煩諸葛先生對於我這種狀況給出必定的建議與學習方向，不甚感激

 hi,kellyred
您說的問題我理解是您將來職業發展的問題，個人建議是這樣：
1.測試將來的職業發展有不少路，並非只有自動化一條路可走，例如：
   1)項目管理方向。對項目的過程管理進行持續不斷的優化，尤爲是最近這兩年敏捷測試及項目過程實踐，各個公司變得重視。
   2)產品人員方向。
   3)測試專家方向，這包括自動化測試專家、白盒測試專家、性能測試專家等等。
   4)業務專家方向。雖然在技術上不是其長項，可是在業務領域方向很是熟悉，典型的有銀行、電信項目的測試專家。
   因此，您能夠看看本身適合選擇哪一個。
2.知行合一。
   不管是您最後選擇了項目管理，仍是選擇了自動化方向，剩下就只有一個建議了：知行合一。學習--->實踐--->總結----->再學習，經過這樣一個過程，按部就班。
    舉個例子：
    1.發現工做中的問題。咱們的組員每次測試輸入法彈泡功能時，都要重複一些工做，好比設置註冊表，配置一個文件，而後殺一些特殊進程，修改系統時間，最後切換輸入法出來。那麼這個工做過程當中有沒有可能去用一些腳原本解決呢？
    2.學習和調研相應的語言。有同窗就去本身學習了python語言，發現用python語言能夠作註冊表操做、文件操做、進程操做等相關的事情，因此他就邊查書，邊試着寫腳本替代以上的過程，最後開發出來這樣一個一鍵部署的腳本。
    3.將以前學習到的知識點總結造成本身的筆記。而後重複以上的步驟1，再去挖掘更多的能夠提高的腳本。經過這樣一個過程，也許能夠提高本身的能力。

 

 你們好，我如今在一家新公司的一個項目組作測試工做，目前此項目組只有我一我的，後續還會不斷招人；領導但願我能搭建完整的測試體系，包括技術、管理等，但我不知道如何下手，不知道從哪裏開始。。請各位各抒己見，給予寶貴的意見和建議。很是感謝！

測試團隊從小到大，我的以爲離不開兩點：人和事 1.人：     人員招聘     人員培訓     目標設定     績效考覈     等等以上體系的創建 2.事：這個就比較大了，細節展開有     黑盒測試：         1)測試用例設計規範         2)BUG管理流程及相關規範     自動化測試：         1)自動化測試流程         2)自動化測試框架         ...     測試管理：         1)缺陷管理系統         2)用例管理系統         3)測試流程中每一個環節的規範、要求和輔助系統