2015/09/28
閱讀 2.1k
收藏 407
在初創公司，大部分都沒有專門的qa（質量保證）人員，此時測試的活兒基本上就是產品做了。
實際上這活兒也挺適合產品做的，畢竟沒有誰能比寫prd的那個人更了解產品細節了。
這半個月經歷了兩次較大的**架構更新。時間緊，資源少，沒時間系統的搞沙盤測試，依然像往常一樣，全員大幫哄，做了一夜黑盒就完事兒了。
結果上線之後各種bug，使用者反饋壓爆客服。還好技術團隊比較牛掰，嚴重的缺陷當天基本都解決掉，才沒造成過大的損失。
之前一直沒系統的去思考過測試方面的事情，親身經歷才感覺到後果的嚴重性。
從專案管理的角度，測試嚴格來說屬於專案質量管理中的質量計畫，質量保證，質量控制三個環節中的最後一環，是驗收整個專案質量的關鍵環節。
而現在的創業團隊大都是敏捷型開發團隊，也就是一些文章裡經常說的「小作坊」~沒有繁重的工作流程和複雜的層級關係，溝通和執行的效率都很高。
所以傳統的專案管理理論中大部分是不適用於初創階段的，這時候就得結合自身情況，用合適的方法具體分析了。
就測試而言，系統的軟體測試方法非常多，單元測試，整合測試，系統測試，α測試，β測試，回歸測試，模糊測試等等……
最常見的三種是：
下面分別再從8個維度重新歸納一下。
首先，測試人員的核心能力在於提出具有價值的問題。這需要結合技術和產品的角度來思考。
測試開始之前，我們要先知道從哪開始測試：
基本上，了解好上面的資訊就可以開始制定相應的測試計畫了。在時間允許的情況下，一定要記得：（這次就是沒寫吃了大虧）
寫測試用例！
寫測試用例！
寫測試用例！
從使用者場景測試：
自己做的產品，我們一定有自己的理解，而使用者實際上是如何使用的？在什麼樣的情景下使用？都是我們需要慢慢的通過與使用者的交流，產品的資料積累，使用者研究得來的，測試的時候當然也不能漏掉。當然，角色要多少有多少，具體看我們產品有什麼需要了。
意料之外的bug常常就會在這裡出現，不過一般都是小bug，但更深入的想想，其實會有更多產品本身的問題。
資料對於產品的意義咱們就不多提了，往往經得住考驗的功能點都是基於資料做出的。
然而，資料多了也同樣愁人，不管是使用者還是我們自己開發，資料一多，出現錯誤的概率也隨之增加。
根據不同的使用者型別和使用者場景，出現極限資料時的測試也不可忽視
寫一些小的指令碼讓測試自動化也是非常高效的~
這時就完全從使用者和測試者本身的角度來思考問題了，錯誤提醒和訊息是經常出現問題的地方。
錯誤資訊的確會影響使用者體驗。然而，錯誤始終是不可避免的，就像我們永遠寫不出沒有任何bug的程式一樣。
雖然最理想的狀態是避免使用者遇見錯誤資訊，但這幾乎不可能。
對於出錯情況的設計、實現和確認很可能與預期相反，但只要測試時善於發現這些意料外的bug，改進它們就更有頭緒了。
當連線斷斷續續或意外中斷時，很多場景我們都要重新考慮：
這類測試最容易發現錯誤和bug。不僅是開關機，確認裝置是否正常工作，嘗試使用者使用的整個流程也至關重要。
帶著問題，才能發現問題
測試往往大家被認為是完全按照邏輯的、可計畫和**的，然而只有在真正編寫測試指令碼，實施測試計畫，在通過和失敗，正確和錯誤的反饋中不斷總結，我們才能越來越接近上線後的真實狀態。
stay hungry，stay foolish
乾貨收藏 測試人員必看的經典書籍
機器學習測試入門與實踐 這本書是今年非常推薦的一本書，對於想要轉型和在ai 大資料方向發展的測試人員必讀的一本書。內容包括大資料基礎，大資料測試指南，機器學習測試基礎以及ai在測試領域的探索與實踐，與ai時代測試人員的未來發展。全程軟體測試 第3版 作者是朱少民老師，適合已經自學了一段時間或有一點基...
乾貨！測試入門Python必會的21個知識點！
在這裡梳理了一下測試小白想要入門python編碼必備的知識點，大家可以按照這個知識點進行深入學習，每乙個知識點網上都有大量的資料，這裡就不一一枚舉了！重要的是大家在了解知識點以後，要真正上手編碼，出現問題，解決問題，如此往復才能使自己的編碼能力得到本質的提公升！對於測試人員來講，工作中缺少編碼環境，...
乾貨 創業做產品最不該犯的四個錯誤
分享會實錄 緣創派 分享內容 本文分為兩個部分，第一部分是創業做產品應該避開的坑，第二部分是群友的q a。第一部分 我們在做產品會遇到什麼坑呢？第乙個坑就是偽需求 我們很多人發現很多需求，很多想法，但是，這個想法真的值得做成產品嗎？真的是這個時候做成產品嗎？真的是普遍的需求嗎？我在緣創派看到一些專案...