成為測試主管第一步

 
　　◆　在這里可以跟大家說一下，我就曾經(jīng)在產(chǎn)品發(fā)布權(quán)限不在測試這里部門的情況下，成功的讓研發(fā)決定推遲發(fā)布了大約一半以上的項目,。大多數(shù)的測試部門主管，很難頂住來自項目/技術(shù)經(jīng)理的壓力是有理由的，因為他們根本不了解你做了哪些工作。有時候一些情況下，看似不可能的事情任務(wù)要想做成完成，關(guān)鍵要看在于事情的技巧，。流程表示了只是一個大方向的東西，而且，你永遠也無法將責任推卸給流程也許是對的，更多情況下，作為測試主管，需要但將做事的方法與風格可以影響到推廣到測試流程的推廣中。

　　◆　在測試互聯(lián)網(wǎng)項目時，還有一個更重要的就是如何保證性能。

　　◆　也許大家會說不就是性能測試并不是單獨存在的。其實不是完全正確，如果有充足的優(yōu)秀高手 人力資源做性能測試當然很好，但性能測試也不能完全保證所有的項目完全沒有性能問題都完美無缺，因此，項目投入期間，同時性能測試是一個這個費時費力的工作，所以往往都是一般在 資源不足的情況下開展的。作為測試主管，更應(yīng)該，要學會判斷那些相對更加重要的問題項目影響面會更廣，需要集中做性能測試。這時你也許會問，那么會有人問其它相對不太重要的項目與問題怎么辦，？其實做過性能調(diào)優(yōu)的人都知道，大部分的性能問題都是由于一兩個弱智的SQL語句導(dǎo)致的，所以可以從流程上加強對SQL查詢語句在I/O問題的跟蹤與評審,，從而避免大部分性能問題。
 
　　◆　上面分析了不同公司根據(jù)上文的分析，不同類型的產(chǎn)品在測試流程上的是有很大差異的。這時，也許大家你也許可以把握測試流程大的方向了，但真正是否適合現(xiàn)有的測試 團隊與研發(fā) 團隊，則仍需要精心的調(diào)整，。當我遇到問題的時候，第一時間往往有時候不是去尋找流程不對的問題，而是通過現(xiàn)有 資源與執(zhí)行的方法可能需要著手來微調(diào)一下你的測試流程，直到發(fā)現(xiàn)問題的所在，并紀錄下來，最后整合到原來設(shè)定的流程中。
 
　　◆　這樣的情況大概常常發(fā)生：比如說在需求上的處理，可能會有很多的測試人員會經(jīng)常指責需求人員撰寫的文檔非常粗糙不詳細，無法進行測試，。好像在我的記憶中，需求人員常常就是被罵的得灰頭土臉，但是經(jīng)過這些年在測試崗位上的工作，我才漸漸發(fā)現(xiàn)，其實有時候需求人員更需要鼓勵鼓勵是比職責更加有效的工作方式。這可能是一個放之四海皆準的工作態(tài)度。，指責只能加深對立，。其實在驗收需求時，由于當時大家也只是知道一個大概我們的需求人員也只能從大致上把握核了解，可能大多數(shù)情況下是：原則上沒有問題就通過了，。但然而，這種不負責任的態(tài)度卻是給我們在做的測試工作帶來相當多的麻煩。也只有在這樣的時候，這些問題才能真正暴露出來，從而使測試設(shè)計時就會發(fā)現(xiàn)很多問題并沒有寫清楚，。一般情況下，很多測試人員這時就多半會放棄手邊的工作，并消極地認為認為無法做工作無法繼續(xù)下去。，等東西出來，并將問題最終歸結(jié)到是需求給的不詳細，而大加指責�！　簟�從我對測試主管工作的記事以來，就在印象中保留了這樣的一幕。記的剛進一家公司時，我 團隊中的人員就開始經(jīng)常會有下屬跟我說抱怨，公司的 需求工程師讓我們太失望了。需求如何如何不好，然而，多少有些經(jīng)驗的我，當時我是把幾家國內(nèi)我服務(wù)過的頂尖公司情況作了一個簡單的對比，的需求跟公司的需求人員的需求做了比較這時才發(fā)現(xiàn)，發(fā)現(xiàn)，原來我們公司的需求人員還是做的得不錯的，。讓測試人員把心態(tài)調(diào)整過來是測試主管的另外一件事。試問，，如果是你做需求作為 需求工程師，是否會比他們做的好嗎得更好?？有了這樣的基調(diào)，就可以讓然后建議測試人員去總結(jié)不清楚的地方，給需求人員一個相對比較具體和明確的意見，這樣順利的了解了需求。
 
　　◆　其實有時候不是流程不對流程在這其中并沒有太多值得指責的地方，而是相互的理解與支持,換位思考而對流程的執(zhí)行態(tài)度，卻是更加關(guān)鍵的。我們不得不學會如何換位思考，并更多地從他人的角度來看待這些問題。
 
　　◆　同樣的問題還出現(xiàn)在還有需求變更上，很多測試人過不了這一關(guān)，�？偸撬麄冎肛熝邪l(fā)人員，讓研發(fā)那些本來就已經(jīng)惱火的 軟件工程師更加火冒三丈。換位思考一番，其實不難了解，，其實需求變更對研發(fā)工程師來說是更大的麻煩，。他們需要修改設(shè)計，、代碼，相較而測試只要需改測試用例，他們的工作確實更加麻煩。簡單來說，就ok了，其實大家要分析什么樣的需求變更最可怕，而不是眉毛胡子一把抓,其實測試對需求變更并不可怕，怕的是只有在提交時才發(fā)現(xiàn)，導(dǎo)致測試時間不夠，才會真正讓測試人員心慌。這時需要從研發(fā)流程上保證變更及時的通知到測試就可以了行，。也許有人會說你也需要說：，說的倒很容易，如果研發(fā)不按照你的要求做怎么辦！其實這里你只要用我所采用的方法是用數(shù)據(jù)說話，在項目進行時統(tǒng)計發(fā)生過多少次這樣的事情，讓研發(fā)管理層知道，讓項目組之間有一個比較，。一方面，如果是一家公司重視質(zhì)量的公司，必然會引起重視；另一方面，從 質(zhì)量管理部門角度本身出發(fā)，也應(yīng)該推動公司重視質(zhì)量。，隨著時間的增加，需求變更給測試人員的反饋一定會有下降的趨勢，。關(guān)鍵是測試不能抓住雞毛就一直揪著不放寬容一些來看待身邊的同事，要允許別人他們犯錯，對于解決問題本身來說會大有裨益。只要趨勢是好的就可以了。同時如果出現(xiàn)這樣的情況并且極大影響到了測試進度，則要與研發(fā)部門溝通清楚,，如果研發(fā)不認可的情況下還可以請上級進行評估一下。

　　◆　上面說的是不同態(tài)度在同樣流程下的實現(xiàn)不同結(jié)果,下面主要講一下關(guān)于自身 資源是否勝任做流程上規(guī)定的事情，某些工作，也許并不一定是測試部門的優(yōu)勢，而另外一些，則需要根據(jù)測試 團隊的基本能力和 資源進行評估。比如像性能測試、SQL的trace、自動化功能測試、單元測試集成、游戲性測試。其實這些流程上的關(guān)鍵點，可能大多數(shù)從功能測試上來一路走來的測試人員是無法做的到，這時要善于利用 資源，不一定要測試做，可以從通過流程上保正有人來做積極調(diào)動其它部門的同事。，或是找有能力的人來做，測試可以進行監(jiān)控。其實這種技術(shù)含量高一點的測試，對人的因素要求更大高，可以借助研發(fā)團隊一起來做會有更好的效果，。記的第一次做Oracle數(shù)據(jù)庫性能監(jiān)控時，就是請的Oracle的DBA專家?guī)椭�設(shè)計了性能參數(shù)，成功的地進行了關(guān)于Oracle應(yīng)用的性能測試。現(xiàn)在國內(nèi)的測試人員普遍的技術(shù)水平不高，嚴重的限制了測試的發(fā)展，希望測試的同行能真正的提升 測試技術(shù)水平，把這些高難度的測試做起來，而不是僅僅只是工具上玩玩，。只有真正提升測試 團隊的技術(shù)含量，這樣別人才會更信賴你，這也是我這么多年來的一點經(jīng)驗。如果你對開發(fā)很精通，、同時又精通對測試頗有研究，、善于診斷性能與架構(gòu)上的問題，、經(jīng)常會幫助研發(fā)部門解決一些他們無法解決的事情，、同時又還懂的如何做測試管理，并了解研發(fā)人員的心態(tài)，那就真得的找不出你還有不成功的理由了任何理由讓人不對你刮目相看了。