公司開發與測試工作的現狀
- 開發基本不自測，甚至沒有自測的環境，特別是涉及多個系統的對接。
- 提測后很多基本的功能都不能正常使用。
- 項目管理比較混亂，但是最終的發布日期又被項目經理定死，所以測試時間常常被壓縮。
- 沒有對於開發人員的質量方面的考核。
這就造成版本提測后測試人員需要快速展開測試，盡可能多的發現bug，眾所周知一些高等級的bug發現的越早后期研發的維護成本越低，所以如何在短的時間內快速復現一些嚴重級別的bug至關重要。
以下從個人的測試經驗和測試流程上說一下個人 的想法。
測試堅持的原則
測試前做好工作計划
俗話說不打無准備的仗，測試前做好工作計划，首先明白該版本如何開展測試，這個版本的測試重點在哪里，這個前期可以加強跟研發的溝通，弄明白測試的重點。然后根據重點規划測試工作。
盡早開展測試
版本提測后盡早展開測試工作，一方面缺陷越早的暴露后期研發的維護成本越低，另一方面根據自己的測試經驗來看一個測試周期中發現bug的曲線圖是一個不對稱的拋物線，前期的工作效率是非常高的，這可能跟測試人員的求知欲有關，測試周期越長后期發現bug的概率越低，所以版本提測后盡快展開測試如果沒有高優先級的任務不要中斷測試，不然反過頭來在進行測試時已找不到了當時靈敏的嗅覺了。
二八原則
軟件中80%的bug存在於20%的代碼中，這要求測試人員對產品的業務及內部邏輯比較了解，知道哪一塊的代碼容易出問題。
及時反饋
無論是軟件開發還是軟件測試溝通是必不可少的，測試發現bug后除了將bug的畢現的步驟及詳細結果提交到缺陷管理庫中還需要知會相關的研發人員，縮短bug的流轉周期。實時將軟件的質量情況上報到項目經理或產品經理，他們可以根據版本質量情況作出相應的調整。及時反饋客服、生產、用戶的問題並將問題轉化為需求或測試用例。
軟件測試方法及技巧
代碼驅動測試
一段程序已經發生的錯誤越多，其中存在的錯誤概率也就越大，錯誤集中發生的現象，可能和程序員的編程水平和習慣有很大關系，因此對發生錯誤較多的程序段，因進行更深的測試。
bug驅動測試
Bug具有連帶效應，發現一個bug之后如果舉一反三能盡早發現更多類似的bug。Bug的修復往往會引入新的bug，應該着重測試與該問題相關的業務。
狀態機測試
態機是一種用來對對象行為進行建模的工具，其作用主要是描述對象在它的生命周期內所經歷的狀態序列，以及如何響應來自外界的各種事件。在計算機科學中，有限狀態機被廣泛用於建模應用行為、硬件電路系統設計、軟件工程，編譯器、網絡協議、和計算與語言的研究。
狀態機可歸納為4個要素，即現態、條件、動作、次態。
狀態機在通信領域的應用，在一次呼叫中，從建立連接到通話完畢，要經歷摘機、撥號、應答、進行通話、掛機等過程，話機的狀態及狀態遷移如下：
狀態的遷移需要條件（通常說的事件）和動作（即處理函數）來觸發，所以我們測試時除了測試穩定的狀態外，更應着重測試從現態遷移到次態的這個過程。
運行日志或log日志驅動測試
日志一般用於記錄程序運行信息，從而使開發者方便開發調試，無論是在調試還是測試的時候，日志都可以幫助我們解決問題，尤其是在測試驅動的開發中，日志更是我們的得力助手。從運行日志或log日志中可以參悟到研發的一些設計思路及業務流程，這樣我們可以從中得到一些測試點。
測試流程上的優化
案例
項目：綜合客服項目
時間點：項目10月中旬開始調研，客戶要求1月15號項目上線。
項目實際里程碑如下：
實際項目開發周期
該項目計划14周結項，實際用時29周左右，維護時間17周大於開發時間。
項目中bug統計如下：
bug類型統計中設計類型的問題占57%，中間需求多次變更。urgent和high等級的bug占比為41%，前期開發時間較長留給測試時間較短，問題在后面集中爆發，且嚴重問題較多，造成研發維護成本提高。
從案例中可以看出造成項目浪費的關鍵因素在於前期需求不明確，需求多次變更，測試介入時間晚很多嚴重問題后期才爆發，造成研發工作返工。所以我認為測試可以提前到需求階段，讓測試人員參與需求的制定及評審。從該項目的需求包可以看出給出的需求很泛泛，未能明確具體的細節，在這個階段研發人員和測試人員的關注點不同，研發人員更關注的是怎么實現這個功能，測試人員更能從用戶角度出發怎么去使用，如何使用更方便，這樣有利於需求澄清與細化，讓需求更加的明確。
在軟件設計階段和開發階段測試人員提供測試用例驅動開發進行工作，同時測試人員需要提高自己的專業技能最好能夠在開發階段進行單元測試。經驗數據表明，編碼階段的一個問題遺留到驗收測試去解決，所須費用將增加5倍，如下圖，一個問題越遺留到后面階段解決，付出代價就越高，而且是成倍遞增關系。
