構造可靠的軟體測試過程

標籤：軟體測試   水平測試   穩定性   安全性   百分比   

測試人員的考核：

用Bug對測試人員進行考核，意味著開發與測試開始對立

綜合考核

選對人，“將能君不勝”

最有價值的測試人員？

一個測試團隊，測試人員水平很高，發現的bug少，而且都是核心問題；

測試真的需要寫Test Case嗎？ -- 需要看寫Case佔用的時間佔總測試時間的時間百分比

高水平與低水平測試人員的區別：Case的覆蓋度和對業務的理解；

自動化測試過程，而不是自動化測試

測試的兩個指標--品質振幅；高效的提高軟體測試案例的覆蓋度

軟體測試的目標是什嗎？

穩定控制軟體產品品質的振幅

高效提高Test Case 的Coverage（通過Case的複用；資料驅動；有效測試設計方法）

軟體測試管理的兩個派系？ -- CMM和敏捷

怎麼做項目分級，在這個基礎上進行軟體測試裁剪呢？

對測試過程進行裁剪

測試策略的制定

確定測試需求；

確定測試目標

確定測試類型和方法

測試風險分析

測試計劃制定--5W

確定測試的目標、方法、環境、工具等（功能性需求；非功能性需求--效能指標、可靠性穩定性指標、安全性指標）

確定時間段

確定資源

自動化的測試分析（解決什麼問題；花費多少成本；提高多少效率）

確定測試過程監控方法

風險分析

如何提高工作效率

可複用的產品多（指標：測試資源複用率）；無用的工作少（指標：有效測試工時率）；和開發的配合好（指標：協作點數量，協作點正確率）；測試專案進度貼合度好（指標：項目變動率，工期貼合度）；自動化測試提高效率（指標：自動化手工測試案例率）

測試案例的覆蓋度

是個求積分的過程

有效度量測試案例覆蓋度增加的條件（定義baseline；定義顆粒度--單位；單個功能點進行有效規整--確定最小測試範圍；提高的方式是功能點的組合和測試資料的增加；每輪增加case的量和率）

我的看法：

不寫case，那麼測試的最大價值在人身上，而非case或工具上，這時如果有人員流動，risk會很高；而且如果對於經驗相對不足的測試人員，即使時間很短，讓其使用探索式測試，很可能會陷入局部最優，case的coverage低於寫case的Coverage，從而導致效率低下

測試，本身是一門綜合能力要求相對較高的專業，那麼要求測試人員無論從業務，還是測試能力上都要有廣度，並有相應的深度；中庸之道很重要 ，走某一個極端都會物極必反

對於如何提高測試效率，測試人員可以在某方面通過改進測試得以提高，但某種程度上起決定作用的還是Boss對測試的重視程度，以及測試人員在整個項目過程中的地位

以人為本；以項目ROI為本

本文出自 “Sunny” 部落格，請務必保留此出處http://1994520.blog.51cto.com/1984520/1679020

構造可靠的軟體測試過程