實用的測試理論-筆記

1.開發模型演化：瀑布模型-v模型-w模型-迭代模型-devops模型
不一樣模型下軟件測試的工做方法徹底不一樣

2.傳統軟件測試對文檔及其重視，其實，文檔並非最重要的。傳統的軟件測試理論中，測試人員極端重視文檔，是由於在不少年前的軟件測試中，不少軟件項目採用瀑布模型。

3.瀑布模型逐漸被淘汰了，由於：效率低下

4.迭代模型下，須要頻繁發佈。發佈次數越多，越須要自動化測試。此外，迭代模型的緊湊型致使了測試人員再也不像以往那樣依賴文檔，由於需求成天改。測試人員開始嘗試以思惟導圖等更簡潔的方式來替代測試用例設計文檔。測試人員在迭代模型中，真正開始介入項目前期。

5.開發模型的進化逐步打破了手工測試不可替代的神話。手工測試能夠替代，用例設計不是軟件測試人員的核心競爭力。

6.測試和核心是效率，效率要高必須自動化。因此，測試人員的核心競爭力必須是技術能力。

7.堅持「實事求是」原則的測試方案：
A.測試目標是什麼：
（常見的是：找到重要的bug，使他們獲得修復、對是否發佈產品的決策提供幫助、評估產品和實際需求的一致性）
B.怎樣組織測試，以實現測試目標：
　　b1.對於發現的bug是什麼樣的重視程度，爲何？
　　b2. 什麼樣的bug的重要性比較高，爲何？
　　b3. 工做所作的文檔應細緻到什麼程度，爲何？
C.假設程序有一個數字輸入域，在需求文檔上說明了，這個域必須可以接受一位的數字做爲輸入值，可是沒有說明若是輸入字母或者符號等等，系統會如何反應。那麼你應該去測試輸入字母或者符號的狀況嗎？假如，如今這個項目的時間很是緊急呢？

8.怎樣肯定一個項目的測試依據：
　　1.有沒有標準的需求文檔
　　2.能不能開會討論需求
　　3.有沒有了解需求的人
　　4.可不能夠由測試人員或其餘角色的人學習需求或經過操做現成軟件等方式嘗試彙總需求
　　5.能不能結合相關企業標準、行業標準、國家標準、國際標準等給項目設置一個大前提的需求
　　6.是否能夠參考同類軟件
　　7.有沒有真實用戶的反饋
　　8.有沒有違背常識的功能
　　9.有沒有犯法的功能
　　10.有沒有影響安全相關的問題
　　11.有沒有影響性能的問題
　　12.有沒有影響用戶體驗的問題

9.當沒有測試依據的時候，怎麼作測試：
結合常識、競品同類功能、用戶體驗等，杜撰一個依據，而後問需求提出方對這個需求有沒有意見。把這個依據抄送全組做爲證據。
另一種狀況，當新加入一個項目組時，你不知道測試的依據是什麼。這種狀況務必多提問，能夠把問題整理出來，以問題列表形式發給他們，而不要本身想固然得以爲需求應該是這樣。

10.咱們須要在認可測試的不可窮盡的前提下，經過技術的手段，儘可能提升測試的效率，在有限的時間和資源下，儘量多測一些。

11.覆蓋率所沒法發現的bug：
　　1.輸入特定的某個值或者某組值（代碼路徑是覆蓋了，但沒法覆蓋全部輸入值，等價類也不必定靠譜）
　　2.在編碼中遺漏的代碼（雖然覆蓋率100%，可是開發漏掉的代碼覆蓋不到）
　　3.中斷，以及其餘並行操做的狀況（代碼能夠覆蓋，運行環境上的系統中斷卻沒法覆蓋）
　　4.需求中包含的錯誤（從一開始就錯了，測試覆蓋再多錯誤的邏輯又有什麼用）
　　5.兼容性方面的錯誤（好比讓app運行在不一樣平臺或在不一樣瀏覽器上打開網頁）
　　6.配置錯誤（不是代碼的錯誤，代碼覆蓋率100%也測不到）
　　7.性能問題（又是一種覆蓋率沒法覆蓋的問題）
這些問題有一個共同點，即便你代碼覆蓋率硬生生推到100%了，仍然對這些問題無能爲力或者說對減小與發現這些問題毫無幫助。

12.「測試人員再也不發現新的bug就表明測試窮盡了」是錯誤的觀念。
緣由以下：
　　1.每週作的工做並非徹底等價的。還有多是後面幾周開發新提交的代碼少了，因此bug發現的也少了。只看曲線是沒法看出測試是否足夠的。
　　2.心理因素驅使測試人員後面幾周不如前面幾種那麼「用力」地找bug，去迎合這個曲線。

13.系統是不會天然而然穩定的，能不能穩定取決於測試設計和探索性測試到底作的好很差，以及取決於新代碼量是否減小了。

14.咱們在項目有限的時間內，是能夠經過制定計劃，而後讓團隊去評審這個計劃，來限定咱們的測試範圍的。這樣，雖然測試不能窮盡，但咱們能夠有效的縮減測試範圍。計劃的要點之一是縮減測試範圍，化無窮爲有限。

15.bug彙報和處理流程：
考慮bug是什麼，質量的多維度性，測試人員考慮各個角色的見解，bug的處理流程