注：作為測試從業人員的一點建議與思考，雖然閱讀量不是很大，但是清菡個人覺得對大家能有點價值；
-- 清菡
關於「測試分工」和「測試時間」的關係，這個分2種情況：
第一種，研發技術水平高，專案業務場景相對來說比較簡單。那麼，這種情況下，如果管理人員安排乙個人寫用例，協助開發做冒煙測試，另乙個人開始測試，這樣做，相對來說問題不大。
但，這就多了時間的成本，接手過來測試的人需要重新了解這塊的需求，效率會低一些。
第二種，專案場景複雜，研發水平比較低，一旦上線會出比較大風險的專案（例如涉及優惠券、訂單之類）。如果管理人員安排乙個人寫用例，協助開發做冒煙測試，另乙個人開始測試，就會出現比較大的問題：
導致測試進度緩慢，甚至無法上線。
這個也涉及團隊協作，研發人員的責任心以及其它客觀外部因素的影響。
怎麼做？
如下，供參考
1.首先管理人員需對業務熟悉，考慮到風險範圍以及風險點在哪。此外，還需考慮到研發人員的技術能力水平及責任心。以此，來做到合理的分工，出了問題也知道出現這樣問題的原因。
2.管理人員需要有足夠的技術水平支援，能認知到專案風險的前提是清楚明白會有什麼樣的風險出現，風險點在哪（這個需要清楚前後端技術是怎麼實現的）。
3.當管理人員清楚知道了專案的複雜度，影響範圍，風險點就可以預估出合理的測試時間，不會存在評估測試時間不合理的情況。或者說出現了這類的問題，管理人員自身清楚是怎麼回事。
4.bug的出現肯定有原因 ，乙個是從操作上分析，看看是不是什麼操作自己沒想到 ，隨便瞎點點出來的，乙個是**上分析 ，看懂** ，做路徑覆蓋 。
5.測試是為了盡可能的避免出現問題，沒辦法保證一定不出問題 ，關鍵看出的問題是特定場景確實大家都沒考慮到 。還是說沒經驗， 確實考慮不到這種操作才知道會出現這樣的問題。
6. 測試估算的時間，只需考慮測試的執行時間。如果中途，由於開發延期提測，或者開發修改bug時間過長，等待新版本測試。在時間評估的時候，需考慮這個時間，把此塊時間加上（或者，發版時間，順延） 。
7. 自己估算的時間，如果後續發現時間不夠，自己加班，想辦法消化 。另外，版本結束後，吸取經驗，總結下，是哪個點消耗時間過多，是否可加速（自己總結的經驗，終身受益） 。如果確實不可加速，說明整個團隊的效能比較低。下次估算，不滿足三分之一評估**，在之前評估時間的基礎上，再加上20%的時間 。
8. 專案過程中，不接受臨時新增需求的測試，如果有臨時需求，需要增加對應的測試時間（這塊，理論上是這樣，實際情況是，很多同學，經常被強塞任務，時間卻沒有增加）。
9.用例寫全。不是憑空想象 ，例如涉及優惠券的專案，一定把優惠卷的影響因子列出來。然後用正交實驗**抽取用例。
10.如果測試用例場景寫的不夠全，交接用例過來測試的人需要把問題都列出來，總結好發給領導，讓領導去判斷，避免背鍋。
11.開發對業務不熟悉以及技術水平低， 這個不是咱們關注的， 有開發leader去把控。
12. 現實情況是，估算好的測試時間，已確定的上線時間，往往由於一些外部因素，提前上線，這個時候，測試同學，需列出已知風險，並做好本職工作，避免背鍋 。
最後。關於測試分工和測試時間的估算，此文的觀點是一些非常主觀的做法（僅供：不知道如何給測試分工及如何估算測試時間的測試從業者，一些參考）。
即可免費加入！**交流。
加油。清菡
2020.10.17 beijing
推薦文章
放假整理的四個知識，附帶小工具
希望清菡的每篇文章都對你有那麼點價值。
如果有用，點個在看吧。
聊聊測試資料
部分思路參考 對於被測系統而言，一條測試資料是指一組輸入和對應輸出的組合。因此，測試的本質其實就是乙個產生和消耗大量資料的過程。這些資料可以被用於以下兩種用途 因此，測試資料對於測試而言非常重要。對於功能測試 functional testing 而言，測試資料是否完備基本決定了測試用例設計是否完備...
軟體測試基礎知識五（軟體測試的分工）
也許專業測試裡講這種方式，很可能不叫 集體測試 因為我根據的自己的理解起了大概符合意思的名詞叫集體測試 集體測試 這種測試模式就是，公司裡所有的測試人員抱成一團兒，來乙個專案，所有測試人員就集中測試乙個專案。優點 每個測試成員的思維不同，各有優缺點，可以更快更全面的找出軟體中的bug。缺點 人力成本...
matlab時間測試
因為想把樣本篩選一下，所以簡單的分類器先跑了一下，沒想到跑完分類器在對樣本篩選時的時間大大超過了樣本進分類器的時間，這個顯然不能達到我要的節省時間目的。於是分析了一下matlab中各個環節的時間成本，一看嚇一跳，迴圈中對矩陣操作，尤其是對矩陣中很多行置空的操作直接讓時間爆掉。可是反過來一想，我其實想...