完美測試體系

大自然素以平衡為美，穩定，可持續是很多事物的一個穩态。

　　捕魚，講究獵殺不絕，生生不息。

　　順應自然的運作法則，我自底向上進行一個分析和思考，看看我夢想中的完美測試體系。

　　階段一，運轉起來。

　 　好了，流程制定起，運轉起來，這個階段完美嗎？也挺好的，穩定，有效，并且，可以比較ok的完成老闆給定的任務。然而，許多團隊易出現一種現象，進入該 穩定的狀态後，由于項目緊，大家工作忙無有效能力提高，一個項目接一個，忙，無改進，忙，死循環。 人走人來，可謂穩定而不完美。

　　階段二，打破平衡，改進效益。

　　要有自動化，打破忙的重複的勞動，也許一開始并不順利，畢竟新生事物剛開始成長都是艱難的，相信自己，做下去。

　　要有性能專家，不斷改進性能測試需求。

　 　如何打破？有潛力的，主動性好的人，不要給予100%項目時間，50%－70%夠了，指派更有前瞻性的工作，例如，新的測試技術産出，自動化實踐，即将 進行的下版本測試分析預研性工作。記住，管理人員敢于失敗敢于承擔。培養起骨幹人員，不斷有所産出。形成一個小的可持續改進循環。靜等有能力的人出現。

　　階段三，旋轉，完美起來。

　　有了骨幹人員的成長，相信，一定有能力完成：

　 　2、業務精通的測試分析專家，能夠有效制定精細的測試政策，包括版本子產品的測試重點，使用哪些技術測試，制定有效的分層測試戰略。分層測試在這裡可以大 規模節省成本，例如，使用自動化完成關鍵部分的接口級測試，而不是做難于大規模産出效益的ui級自動化。使用ui自動化測試最有必要，易于改動引發問題的 部分。分層測試可以有效節省測試用例設計和可測性的工作量。通過子產品分離，可以有效分離bug産生原因，便于開發修改和回歸。

　　3、性能測試專家，與測試政策同時制定，分析系統可能存在的性能問題，完成高效的性能測試需求，如，利用什麼樣的工具或改進現有工具，高效完成哪些性能名額測試。

我們來看看，現在一次完美的測試過程：

　　項目立項，由使用者和boss立項，研發和測試跟進，各技術專家評審需求，除提供有效的場景供使用者和開發确定外，測試分析專家（架構師）給予可測 試性需求，包括不限于，使用者級需求的可測試性分析；白盒測試的限制和接口，如庫的導出标準；與開發的架構師一起确定整體設計方案是否合理有效，并指導或确 定可測試性設計要求。

　　項目設計，開發在處理使用者需求的同時，跟進前期測試，完成自動化測試需求，測試專家的可測試性需求跟蹤和測試政策的制定。

　　項目編寫內建，項目的自動化工程師和執行人員介入，按照項目流程和政策進行內建測試，并同時産出相關自動化用例，完成制定的測試分析專家的分層測試政策與其他測試政策。

　　項目系統測試，根據政策，至少2輪以上，快速回歸自動化，內建發散性測試和探索性測試，充分發揮大家的思考發散能力，将上一階段的問題發現并送出，并回溯起來，不斷改進前期過程。

　　項目穩定性和場景測試，由相關人員進行場景測試，保證到最終使用者的可靠的使用。

　　是否完美呢？它有高效的運作方式，有經驗豐富和技術牛人指導前期，有完整高效的分層政策和自動化保證快速開發，有穩定性與使用者場景保證最終的可 靠性釋出。如果說不完美，有一點，還缺少那麼一點點預見性，那麼，培養具有市場前瞻性的技術專家吧，例如，提前半年分析超大流量的測試技術，提前研究移動 終端的快速測試技術。

　　自底向上，意味着，很多東西我們管理需要培養起有能力的人員由他們自然推動，而不是靠從上向下的強推自動化，強推所謂的靈活流程。

　　至于流程，在完美測試體系中，它應該融入到我們的研發和測試平台中。自然随性，不知不覺跟進了流程。這是流程的最高境界。

　　在測試界中，易于出現無成就感的問題，在這裡，沒有任何問題，每個人有向上發展的動力，有其不同的價值展現。最終的大牛進入研發過程改進中。

　　所謂大局觀，是一種思路，在管理過程中，抓住前瞻性的重要不緊急工作，把它做好。那麼，自然，穩定的，可持續的完美測試體系，在未來，可成矣。

　　“飲鸩止渴”， 萬萬不可。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/