Test Pyramid (tạm dịch: kim tự tháp kiểm thử)

Kim tự tháp kiểm thử là một khái niệm được phát triển bởi Mike Cohn. Phần quan trọng của nó là bạn nên có nhiều low-level unit test hơn là high-level end-to-end test thực thi thông qua GUI.

test-pyramid-1

Theo Martin Fowler thì kiểm thử tự động (test automation) nghĩa là các bài kiểm thử mà đưa một ứng dụng đi thông qua giao diện người dùng của nó. Có nhiều công cụ thường cho phép tính năng lưu lại sự tương tác với ứng dụng and sau đó cho phép thực hiện lại tương tác đó, kiểm tra xem ứng dụng có trả về cùng kết quả hay không. Việc lưu lại các bài kiểm thử kiểu này được thực hiện khá dễ dàng và người thực hiện không cần phải có kiến thức về lập trình.

Nhưng cách tiếp cận này nhanh chóng gặp vấn đề và trở thành một ice-cream cone. Việc kiểm thử thông qua UI như vậy sẽ chậm và tốn thời gian cho việc build. Thường thì kiểu kiểm thử này đòi hỏi phải cài đặt phần mềm kiểm thử tự động, nghĩa là có thể chỉ thực hiện hiện được trên một số máy nhất định. Điều qua trọng nhất là những bài kiểm thử kiểu như vậy rất là dễ “gãy”. Chỉ cần có một cải tiến cho hệ thống là có thể dễ dàng dẫn đến việc phá vỡ các bài kiểm thử như thế mà sau đó phải thực hiện lại trên hệ thống mới. Bạn có thể giảm rủi ro này bằng cách bỏ các công cụ lưu-quay lại (record-playback) nhưng làm các bài kiểm thử khó viết hơn. Thậm chí dù có nhiều kinh nghiệm  tốt trong việc viết chúng, những bài kiểm thử end-to-end dễ đưa đến những vấn đề không xác định được. Tóm lại, những bài kiểm thử mà thực thi end-to-end thông qua UI là: dễ “gãy”, tốn công sức để viết và tốn thời gian để thực thi. Vì vậy, tam giác này cho rằng bạn nên thực thiện nhiều bài kiểm thử tự động hơn nữa thông qua các unit test hơn là thông qua GUI truyền thống.

Tam giác này cũng đề cập đến một tầng trung gian các bài kiểm thử được thực thi thông qua một tầng dịch vụ (service layer) của ứng dụng, mà như Martin Fowler muốn đề xuất giống như là các SubcutaneousTest [1]. Những bài kiểm tra này có thể mang đến nhiều thuận lợi cho end-to-end test nhưng tránh được những phức tạp với các UI framework. Trong những ứng dụng web, bài kiểm thử này sẽ tương ứng với việc kiểm thử thông qua một lớp API trong khi phần UI trên đầu của kim tự tháp sẽ tương ứng với những bài kiểm thử sử dụng một công cụ gì đó chẳng hạn như Selenium hoặc Sahi.

Kim tự tháp kiểm thử xuất hiện nhiều trong các vòng kiểm thử của Agile và có nhiều điều để nói về việc xây dựng một danh mục kiểm thử được cân bằng tốt (well-balanced test portfolio). Đặc biệt, một vấn đề khá phổ biến là các nhóm quy kết các khái niệm về end-to-end test, UI test và customer facing test (kiểm thử trực tiếp với khách hàng) thành một. Những khái niệm này là những đặc điểm mang tính trực giao. Ví dụ, các UI behavior của một javascript UI nên được kiểm thử với javascript unit test sử dụng công cụ như Jasmine chẳng hạn. Một tập hợp các quy trình nghiệp vụ phức tạp có thể được kiểm thử bằng việc nhận phần chụp lại trong mẫu biểu khi gặp trực tiếp khách hàng, nhưng chỉ chạy module thích hợp như các unit test.

[1] SubcutaneousTest: nghĩa là một bài kiểm thử hoạt động dưới giao diện của một ứng dụng. Điều này đặc biệt có giá trị khi thực hiện kiểm thử chức năng (functional test) của một ứng dụng: khi bạn muốn thực hiện bài kiểm thử end-to-end behavior nhưng khó thực hiện thông qua UI.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s