構造可靠的軟件測試過程

測試人員的考核：

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

綜合考核

選對人，“將能君不勝”

最有價值的測試人員？

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

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

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

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

測試的兩個指標--質量振幅；高效的提高軟件測試用例的覆蓋度

軟件測試的目標是什么？

穩定控制軟件產品質量的振幅

高效提高Test Case 的Coverage（通過Case的復用；數據驅動；有效的測試設計方法）

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

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

對測試過程進行裁剪

測試策略的制定

確定測試需求；

確定測試目標

確定測試類型和方法

測試風險分析

測試計劃制定--5W

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

確定時間段

確定資源

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

確定測試過程監控方法

風險分析

如何提高工作效率

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

測試用例的覆蓋度

是個求積分的過程

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

我的看法：

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

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

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

以人為本；以項目ROI為本