專案測試經驗

詢問：測試架構師的工作職責只適合大公司。如果是乙個只有10個測試人員或更少的測試人員的小公司，可沒資源來做這些測試活動了。那麼應該開展哪些測試活動才是最適合小公司的。

其實我工作的第一家公司，雖然測試人員也有大幾十號人，但是運作上其實還是乙個小公司，資源缺乏，人力不足，產品時間緊。因此，對於小公司測試活動的認識，我也是走了彎路後，最近才反思合理的測試策略應該是什麼。

先說說小公司的特點：公司失敗的風險很大，產品失敗的風險也大，並且用於研發的時間和人力都少。

那麼小公司的特點說明什麼？說明小公司的測試必須是快速開展，快速見效，有可能測試的不全面，但是只要保住了可以保命的質量，規避了保命的風險就可以滿足老闆的需求。這裡就談到，小公司的自動化測試什麼時候搞合適？

我的建議是：產品第一版的測試就不要投一點力量搞自動化了，誰知道下個月還做不做這個產品。只有產品銷量成功，公司立志2－3年都要繼續完善該產品時，才有必要投入自動化測試。

畢竟自動化測試的成本是很貴的，你投乙個人搞自動化測試，你就少了乙個保障關鍵特性質量的測試人員。今天，我終於理解和原諒了04年讓我中止搞自動化測試的那位測試經理。我當時一味心思認為只有自動化測試才是測試活動中最有技術含量的工作，並沒有站在公司的角度，從大局思考投入產出。

那麼小公司不搞自動化測試了，是否就意味著小公司的測試就可以進行monkey testing。錯！小公司可以把時間放在基於風險測試的研究和掌握中，基於風險的測試就是解決資源和時間都不夠情況下，我們如何把產品質量引起的失敗風險降低到最低的一種最佳投入產出測試準則。

同時，小公司更需要測試人員參與到專案的需求討論，架構討論活動中，發揮小公司靈活言論自由的優勢，把需求和架構的問題盡早消滅，根據統計50％的bug都是在需求和架構設計階段就埋入了的，而這些bug要在系統測試階段發現，不但難度大，而且非常耗時。

另外，小公司測試人員要盡可能使用測試工具進行**自動測試，只要能自動進行**相關測試的工具就盡可能拿來用，雖然會遺漏**編寫的缺陷，但也比在後期完全依靠系統測試來發現，省人省時多了。

最後，小公司測試可以在功能測試上少花一些人和時間，只做verification, 不做testing，當然前提是：已做好了基於風險的測試分析，並進行了充分的early testing。但是在效能測試和壓力測試方面，還是要依賴工具盡可能去測試，暴露產品在少數極端情況下和長時間正常情況下的bug。

總結小公司測試策略的建議：

i. 不要過早投入開展自動化測試；

ii.一定要掌握基於風險的測試方法；

iii. 盡可能使用自動測試工具進行**級測試；

iv.功能測試側重verification, 少做testing

v. 重視效能和壓力測試。（以上言論僅代表作者的個人觀點，不代表51testing觀點）