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

　　◆　在測試互聯網項目時，還有一個更重要的就是如何保證性能。

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

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