爲思考尋找答案

在近3年的測試工做中，一直保持一顆好奇的心，不斷的嘗試新的測試方向，手工、自動化、白盒、性能、運維，在此對本身以往的測試工做進行一次總結。

過手的項目包含網站、電視頻道、手機APP、社區終端機、銀行金融系統，沒有進入規模性測試團隊，但流程大體同樣，參加需求評審--編寫測試計劃--編寫測試用例--測試用例評審（產品、開發、項目經理）--單個模塊完成進行輪次測試（每測試一輪，進行測試結論）--幾輪測試後沒有功能性問題（至關於內測）--出測試報告--項目上線。

需求評審中多發表本身對需求產品的見解，用例評審中以測試爲中心，要求思路清晰。

用例設計

好的測試用例是用恰當的用例覆蓋更多的功能點。簡單的功能寫幾百條用例，寫的越細，需求改變，用例沒法再次使用。用例寫的太粗糙，有些功能點不能覆蓋到。觀點考慮全面，用例要靈活。多花時間研究被測的業務和需求。多學習別人的用例。

用例靈活

預期結果會寫「給出相應提示」「匹配輸入的內容」等模糊的預期結果。至於開發具體怎麼設計是他的事兒。只要是合理的，不產生歧義的，使用戶很容易理解的設計。若是產品需求中有明確的要求的，必定要寫清楚。

檢查文檔

測試人員最繁瑣的是一個項目下來要寫許多文檔，測試計劃文檔，測試用例文檔，測試論次報告，測試報告文檔，驗收方案文檔等等，要仔細檢查文檔。

測試要積累的技術

按我目前的工做，須要熟悉系統的結構，熟悉開發的語言，熟悉數據庫，除了測界面測功能，能夠查一下數據庫，數據到底有沒有存儲成功，或者修改數據庫數據查看前面效果。經過修改數據庫表數據模擬業務流程。

在前臺界面操做的時候，去查看一下服務器日誌，是否有報錯信息。經過服務器日誌有時候也能定位或判斷問題的緣由。

　　多用頁面分析或抓包工具，例如，按鈕點擊無效，那用debug工具查看頁面上這個按鈕的屬性。用抓包工具看一下請求與響應。總之，在測之過程當中試着去解剖被測系統。

測試發現問題

　測試人員最激動人心的時刻就是發現bug了。當你發現一個bug的時候，不要急着就上報到缺陷管理系統或告訴開發人員。首先肯定重現步驟。換個系統試試，換個瀏覽器再試試。或許，是你忘記清理瀏覽器緩存致使某個問題還在。好吧，最好試着定位與解析這個bug的根源。

　　第二點我要說的是，發現一個模糊的問題，應該試着站在多個角度去看待這個問題，站在用戶的角度考慮這個問題的影響。站在開發角度去看待這問題的嚴重性與修復成本。向開發去說明這個問題對用戶的影響。這樣更能開發創建和諧的關係。

測試要掌握的知識點

1.瞭解測試本質

2.要學的是軟件知識，測試是爲軟件服務的，軟件工程，編程語言，架構，網絡，一切與開發有關的知識，你都要學，這裏要學的東西很是多，不要求深度但要求廣度。咱們在需求評審的時候，有時開發人員會說到技術實現，功能的邏輯，內部處理機制，架構層級等，若是你所有不懂那多「見外」呀，固然，這些知識無形中潛移默化的做用你的測試行爲，對被測系統的理解深度以及發現問題的深度。

不要猶豫哪一個技術好學，哪一個技術有前途，哪一個技術工資高。無論你學與不學，技術就在那裏，你的技術水平不增不減。固然，也不能一直悶頭苦學，學一段時間應該停下來總結與思考。我要走什麼路線？我所走的路線還欠缺哪些能力？我還有哪些方面須要增強。固然，也應該關注一下將來的技術趨勢。

職責決訂價值