該文章同步發佈於:我的部落格
也歡迎關注我的 Facebook 以及 Instagram 接收軟體相關的資訊!
既然要介紹 RSpec,就不得不提到測試的種類,根據下圖我們可以將測試的種類分成四大類
專注於測試程式之間每個功能在切碎後程式碼,就像 一個 Class / 一個方法 / 一個物件 / 一個模組 等等 ...
每一個小單元被單獨做測試,也就是不受到任何干擾或是其他有關係的程式碼影響,專注在我們設定的小目標上面,確保他的測試成功。
這時還是非常初期的測試,所以他才會被放在金字塔的底部,代表他是整個測試的基底。
這時候的測試還非常好寫,而且很快又很簡單,是最快樂的時候!可以一直看到綠燈亮起,覺得人生很美好
這時候的測試比 Unit Test 稍微複雜了一些,我們需要整合一項稍微完整的功能,記住,這時候的功能也只是整個應用程式的小螺絲而已,可以把剛剛介紹的 Unit Test 想像成製作螺絲的原物料。
這時候的整合測試的目的就在於檢驗這些原物料到底組裝起來能不能變成一個小螺絲,有時候每個 Unit Test 都能夠通過,但真正的組裝起來卻變成一個漢堡,這就和我們一開始的需求有出入了。
這還只是第二層,來確保 Unit Test 的方向沒有錯,合在一起也能夠滿足需求!
UI 又稱 使用者介面 ( User Interface )
這時候已經是要測試所有功能的整合,以及測試整個系統的運作流暢度和互動效果。
所以這邊可以叫做 UI Tests 的原因就在於,我們專注的點在於整個應用程式的使用效果,畫面中的互動,操作上的效率等等 ...
撰寫 E2E 的測試難度較高,執行的速度也很慢,這次的鐵人賽我們還是以 Unit Test 為主,希望專注在基礎的測試上面,畢竟要蓋成金字塔,也是需要先打地基嘛~
這時候的應用程式已經開發到一定的完成度,只剩下手動測試的部分!
對於手動測試我想也不需要解釋太多!
還是要根據事先完成的測試 SOP 規範,不是亂按一通就是手動測試
來提提優點好了!
手動測試基本上是一定會發生的,就算你什麼測試都沒有寫
因為那出自於人性,你永遠會去操作你做出來的作品,而有些 Bug 確實不會被測試框架給捕捉到,他可能很細節,或是使用起來很慢等等
這些很多都是開發工具不會告訴你的,所以這雖然在最上面,但他是非常重要的一個環節!
今天稍微介紹了一下測試的種類,看著圖片來閱讀文章,應該也能感受到一股積沙成塔的感覺,為了提升應用程式的穩定性,測試是絕對不可少的一環!
但每一個專案的開發時程都不一樣,不一定有時間讓你遵循這張圖片進行測試,這時候我們就要稍微做取捨來決定該使用哪些測試,而測試又該要用在哪個功能上面才能讓 Bug 發生時不會無處可找!