測試用例是軟體測試的最小單位，是測試工程師的子彈。對軟體測試入門者來說，測試用例是第一位的，有了好的測試用例你就能發現別人沒有發現的bug。只有當你具有良好的、開放型的測試思維，你才能得到優秀的測試用例。
1. 我們要熟悉產品的需求規格說明書(軟件需求是測試的標準與範圍)。若需求不具體或者需求文檔過於簡略，這時測試應該去推動需求的制定。
a. 測試以需求規格說明書為基礎，但同時也要去發現它裡面的錯誤，推動需求的完善。
b. 測試工作是貫穿於整個軟體開發過程的，越早發現錯誤，修正這個錯誤的成本就越小。
2. 測試工程師要瞭解專案的整體安排(即專案的時程)
a. 測試是無窮盡的vs.實際測試是有限的 <= 測試的經濟面(時間、成本等限制)
3.預備好測試環境
a. 工作環境與測試環境要分開
b. 功能測試環境和性能測試環境要分開
c. 提前準備好硬體(伺服器、客戶端、網路設備)和軟體(作業系統、瀏覽器)
d. 測試支援平台也是測試環境的一部分。測試支援平台：一套測試的自動化辦功系統，例如測試用例管理系統、bug管理系統、測試報告產生系統等。
e. 把搭建測試環境時遇到的問題和相應的解決辦法記錄下來，形成文字，以備之後查詢。
<<測試常用專有名詞>>
黑盒測試：只知道功能的測試。 <= 功能測試
白盒測試：只知道程式碼結構的測試。
<= 單元測試
灰盒測試：知道功能也知道程式碼結構。
<= 執行某個功能中所有的單元測試??
功能測試：對產品的功能做測試。
性能測試：一般是檢驗在普通場景下產品的性能。
壓力測試：檢驗產品在極端條件下的性能(極端條件下的性能測試)。
回歸測試：
1. 在開發人員修復一個bug後，去驗證這個修改是否正確所做的測試。
2. 在軟體開發後期，選擇否依部分重要的測試用例去驗證產品的某一個版本工作是否正常。
單元測試：函數級別的測試，一般都由開發人員來完成。
整合測試：將各模組代碼整合到一起，實現一個或一些功能。驗證代碼的整合是否正確。
系統測試：針對子系統做測試，也就是大一點的整合測試。
邊界值：是確定合法輸入與非法輸入的判斷條件(通常會在邊界值的左右在各選一個值來測試，也就是每一個邊界值得測試會有邊界左值、邊界值、邊界右值，三種值)。
等價類：將涵意或影響相似的值分在同一類中，並為每一個類選一個代表即可。例如，在0~100中，如果以偶數奇數來分類的話，就是兩類，各選一個奇數和偶數來測試就可以了。
里程碑：軟體專案一般可分為多個階段，每做完一個階段，我們就說實現了或達到一個里程碑。
評審(Review)：
bug重現(再現)：不能重現的bug，它的嚴重性一般都不會很高。
BVT(Build
Verification Testing)測試：在一個新版本出來後，先要做一個最簡單的測試，保證這個版本的基本功能工作正常。亦稱冒煙(煙霧)測試。
自動化測試：透過測試工具來實現自動運行的測試。
UI測試的關注點：
1.
界面元素要符合通用規範
2.
窗口能在不同的尺寸下顯示正常
3.
支持用戶不同的作業系統的設置
4.
支持用戶使用不同的解析度
5.
處理好焦點問題
6.
作語法檢查，避免文字錯誤
7.
對不方便人群的支持
8.
支持快捷建
測試計劃的關注點：
1.
測試時間的安排
2.
測試人員的安排及任務分配
3.
測試資源的安排，包括需要的軟體、硬體
4.
自動化測試的安排
5.
測試風險的分析以及對策
<<設計測試用例的一些思維>>
1. 一個測試用例只負責一個細小的使用場景，越細越好。
2. 軟體的基本數據也在測試範圍之內。
3. 檢查默認值是一種很好的測試思想和習慣。
4. 使用"排列組合"的方式編寫測試用例(測試是無窮盡的vs.實際測試是有限的)。
5. 輸入框為空是一種特殊值。
6. 做軟體測試時，總有一些"附屬項"需要驗證。
7. 測試用例要有覆蓋到極限值(邊界值測試)的情況。
8. 登入驗證在安全性方面要多多考慮。
9. 懷疑一切，驗證一切。
10. 網頁得標題欄也是需要測試的。
11. 考慮一個測試點時，需更多的從動態的角度出發。
12. 快捷鍵的驗證。
13. 下拉式表單的每一個子項都要測試。
14. 即便功能類似，用例還是要分開寫。
15. 幫助文件的內容也是需要測試的。
16. 在測試一項複雜的功能時，可嘗試使用Bottom-Up的測試邏輯。
17. 不要忽視功能點，他們也需要被測試。
18. 所有不正確的需求、設計和程序錯誤都可以報告為bug，讓相關人員去修正。
19. 測試員的眼界要越過被測試的對象，可以考慮與之相互通信的”兄弟軟體”之間的協作。
20. 工具攔中的每項設置都需要遍歷；設置之間的組合可以隨機來做，不必遍歷。
21. 測試人員應站在最終用戶的角度上看問題(UX)。例如，輸入框得到默認的輸入焦點；快捷鍵等。
22. 在每一個軟體的需求之外，還存在著一些”公理”，不言自明的。需求規格書不可能面面俱到，測試員可以根據這些”公理”來擴展需求。
23. 不以機率小而不為。
24. 有些功能可能是界面上沒有入口、看似沒有的，但是在某些條件下卻會出現。
25. 盡量對可能交互或產生影響的產品都有所了解，這樣在考慮問題的時候思路會更開闊。
26. 再考慮複雜場景前，可先以基本場景為切入點，接著列一些提綱，然後再根據一個個的提綱去思考、去突破。
27. 數據不是靜止的，我們需要使用動態的思維方式來考慮問題。
28. 瞭解同事的工作，就能夠做一些跨模組的思考，把測試做得更深入。並避免報告重複的bug。
29. 面對一個窗口的時候，從”變量”入手做測試是一個好的思路。既然它是變量，變成什麼就都有可能。
30. 除了琢磨模組自身內部包含的功能外，我們還要把它和其他相關模組放在一起測試。
31. 有效數據和無效數據都是需要驗證的(有時候他們被稱為合法的和非合法的數據)，測試中需要正反兩方面的用例。
32. 拆解功能的流程，然後逐一分析測試，用以避免遺漏掉很多問題。
33. 狹義上的UI測試：專指對操作介面的非功能性的測試。
34. 文檔保持更新，測試保持更新，保持一種在動態前進的心理預期。任何文檔不可能是一勞永逸的。
沒有留言:
張貼留言