Kiểm thử Tăng tiến - Incremental Testing là gì?

Để thực hiện Kiểm thử tích hợp, các tester có thể sử dụng rất nhiều kĩ thuật kiểm thử. Trong bài viết này, hãy cùng tìm hiểu về kĩ thuật kiểm thử tăng tiến. Bài viết sẽ tập trung làm rõ các vấn đề sau:

• Thế nào là Kiểm thử tăng tiến
• Mục đích của việc thực hiện kĩ thuật này là gì?
• Các phương pháp để thực hiện nó là gì?
• Những ưu điểm của kĩ thuật này?
• Nhược điểm của việc thực hiện nó là gì?

I. Thế nào là Kiểm thử Tăng tiến

**Kiểm thử tăng tiến** hay còn gọi là **Kiểm thử tích hợp tăng tiến**, là một trong các phương pháp thực hiện Kiểm thử tích hợp, trong đó có sự kết hợp của các nguyên lý và khái niệm căn bản.

Kĩ thuật này giống như là sự kết hợp giữa hai phương pháp Kiểm thử đơn vị (Module Testing) và kiểm thử tích hợp.

Khi thực hiện kĩ thuật test này, chúng ta sẽ kiểm thử từng module riêng biệt trong giai đoạn kiểm thử đơn vị (unit). Sau đó, các module sẽ được tích hợp dần dần vào và kiểm tra kĩ càng, để đảm bảo rằng, giao tiếp (interface) và tương tác giữa các module được mượt mà.

Như đã nêu ở trên, thay vì tích hợp cả một hệ thống lớn vào nhau cùng lúc rồi thực hiện kiểm thử trên sản phẩm cuối cùng thì với kĩ thuật này, việc chúng ta làm đó là kết hợp từng module theo hướng tăng dần, cụ thể là lần lượt thêm từng module một rồi dần dần tăng lên, thực hiện hiện kiểm thử, rồi lại đưa thêm module vào, cho tới khi tất cả các module hay thành phần được thêm vào một cách hợp logic, tạo nên sản phẩm đúng với yêu cầu. Những module được tích hợp vào hệ thống, sẽ được kiểm thử theo nhóm để đảm bảo việc tích hợp và trao đổi thông tin giữa các module đã thành công.

Giống như trong kiểm thử tích hợp, việc kiểm thử tập trung chủ yếu vào kiểm tra giao tiếp giữa các module (interface), những mối liên hệ tích hợp, và dòng thông tin lưu chuyển giữa các module. Quy trình này được lặp đi lặp lại cho tới khi các module được kết hợp hoàn toàn và xuất sắc vượt qua các bài kiểm tra.

Ví dụ

Hãy tìm hiểu ví dụ sau đây để hiểu hơn về khái niệm này:

Một hệ thống hay một ứng dụng phần mềm bao gồm những module sau đây:

Phương pháp tiếp cận Kiểm thử Tích hợp Tăng tiến

• Mỗi Module: M1, M2, M3, v.v… được kiểm tra một cách riêng biệt (unit testing)

• Từng modules được tích hợp và test để đảm bảo khi kết hợp với nhau chúng vẫn vận hành tốt.

• Trong Hình 2, Module M1 và Module M2 được kết hợp và test

• Trong Hình 3, Module M3 tiếp tục được thêm vào và test

• Trong Hình 4, Module M4 được thêm vào và test để đảm bảo mọi module sau khi kết hợp vào vẫn chạy mượt mà.

• Những module còn lại cũng sẽ được thêm vào tương tự như vậy và sau mỗi lần thêm vào chúng đều được kiểm tra để đảm bảo việc tích hợp vẫn đang đi đúng hướng.

Hình 2

Hình 3

Hình 4

II. Mục đích của việc thực hiện kĩ thuật này là gì?

* Đảm bảo các module khác nhau có thể vận hành trơn tru với nhau sau khi được tích hợp vào.

• Xác định được bug/defect sớm hơn và dễ dàng biết được nó xảy ra ở giai đoạn tích hợp module nào. Nhờ đó, cho phép lập trình viên (dev) xác định vấn đề nằm ở đâu và điều tra nguyên nhân nhanh hơn. Ví dụ, M1 và M2 được tích hợp thành công nhưng khi thêm M3 vào lại gây ra lỗi, lúc này dev có thể nhanh chóng khoanh vùng để tìm hiểu về lỗi này.
• Việc phát hiện lỗi sớm sẽ giúp ta xử lí, sửa chữa mà không cần phải “đập hết đi xây lại” và tiết kiệm chi phí hơn.

III. Các phương pháp để thực hiện nó là gì?

Trước khi đi vào nói về các phương pháp cụ thể, hãy cùng xem qua hai khái niệm ***“Stubs”*** và ***“Drivers”***. Hai khái niệm này sẽ được nhắc đến khá thường xuyên trong nội dung bài viết.

Stubs và drivers đều là những đoạn code giả hay mô phỏng được sử dụng trong kiểm thử tích hợp hay kiểm thử đơn vị (component/module testing) khi mà một hay nhiều module chưa được phát triển xong nhưng để test được một số module khác lại cần phải có các module này.

Stubs được sử dụng trong phương pháp kiểm thử Top-down và được biết tới như là những “called programs”. Stubs giả lập giao tiếp giữa các module (interface) ở cấp độ thấp hơn, chưa sẵn sàng để sử dụng hoặc chưa được phát triển.

Drivers được sử dụng trong phương pháp kiểm thử Bottom-up và được biết tới như là những “calling programs”. Drivers mô phỏng giao tiếp giữa các module (interface) ở cấp độ cao nhất chưa sẵn sàng để sử dụng hoặc chưa được phát triển.

Một số người có thể sẽ có một thắc mắc khi bắt tay vào kiểm thử đó là, tại sao lại không chờ tới khi tất cả các module của ứng dụng được hoàn thành rồi mới test thay vì dùng các stub/driver này?

Câu trả lời đơn giản nhất đó là nếu chờ đợi, thì thời gian thực hiện dự án sẽ bị kéo dài ra vì testers sẽ chỉ có thể cứ ngồi ì ra đó mà chờ cho tới khi tất cả các module được code xong. Thêm vào đó, việc chờ tới khi tất cả các thành phần đã được hoàn thiện như vậy sẽ khiến cho việc phân tích căn nguyên của defect khó khăn hơn. Phương pháp kiểm thử này được biết tới với tên gọi là Kiểm thử tích hợp Big-Bang.

Vậy là chúng ta đã đi qua hai khái niệm về stubs và drivers, tiếp theo hãy xem các phương pháp luận của Kiểm thử Tăng tiến là gì:

1. Top Down

Đúng như tên gọi của nó, việc kiểm thử được thực hiện từ trên xuống dưới. Cụ thể là từ module trên cùng trên cây cấu trúc chương trình (module gọi các module khác), sau đó tới các module nhánh phía dưới sử dụng trực tiếp module vừa kiểm thử. Những module tạo nên bộ khung và lớp bề mặt của ứng dụng sẽ được kiểm thử trước.

Phương pháp này đi theo dòng cấu trúc của ứng dụng. Các module hay các thành phần chưa được hoàn thiện hay chưa được phát triển được thay thế bằng cách sử dụng các stubs.

Cùng xem ví dụ dưới đây:

• Module: Website Login viết tắt là L

• Module: Order viết tắt là O

  • Module Order Summary viết tắt là OS (chưa phát triển)

• Module: Payment viết tắt là P

  • Module Cash Payment viết tắt là CP
  • Module Debit/Credit Payment viết tắt là DP (chưa phát triển)
  • Module Wallet Payment viết tắt là WP (chưa phát triển)

• Module: Reporting viết tắt là R (chưa phát triển)

Phương pháp tiếp cận Kiểm thử Tích hợp Tăng tiến

1.1.Test case sẽ được phát triển theo hướng sau:

Test Case1: Module L và Module O sẽ được tích hợp và test

Test Case2: Module L, O và P sẽ được tích hợp và test

Test Case3: Module L, O, P và R sẽ được tích hợp và test.

Tương tự như vậy các test cases khác sẽ được tạo ra.

Loại kiểm thử này được gọi là kiểm thử theo chiều ***“ngang trước”***. Tất cả các module cùng lớp được tích hợp vào và kiểm thử trước. Một phương pháp khác gọi là kiểm thử theo chiều “sâu trước”

1.2. Khi đó test cases sẽ được phát triển theo hướng sau:

Test Case1: Module L và Module O sẽ được tích hợp và test

Test Case2: Module L, O và OS sẽ được tích hợp và test

Test Case3: Module L, O, OS, P sẽ được tích hợp và test

Test Case4: Module L, O, OS, P, CP sẽ được tích hợp và test

Tương tự như vậy các test cases khác sẽ được tạo ra.

Ưu điểm của phương pháp Top-down

• Phát hiện sớm các lỗi cấu trúc

• Vạch ra tổng thế hoạt động, chương trình khung sườn của ứng dụng ngay từ những giai đoạn đầu tiên đồng thời sớm chỉ ra những lỗi liên quan tới design (thiết kế hệ thống)

• Những lỗi có khuynh hướng xảy ra ở các module thuộc cấp độ cao được kiểm tra và phát hiện từ sớm.
  

Nhược điểm của phương pháp Top-down

• Sẽ có những module quan trọng nhưng lại bị test ở giai đoạn sau cuối của vòng phát triển

• Việc tạo ra các điều kiện test sẽ rất khó khăn và nhiều khi không khả thi do khoảng cách khá xa giữa module cần test và module chứa các dữ liệu để cung cấp cho module cần test.

• Phải tạo ra các stub để phục vụ các module sử dụng chúng và viết stub không dễ như ta tưởng.

• Stub không phải là một bản chạy hoàn hảo của module. Nó chỉ mô phỏng sự trao đổi dữ liệu giữa hai module mà không thể tạo ra đầy đủ dữ liệu như module thật nên khi test bằng stub sẽ không thể test hết các trường hợp về tương tác của các module thật được.

### 2. Bottom-up

Trong phương pháp này, kiểm thử được thực hiện từ dưới lên. Cụ thể là, các module ở lớp dưới cùng (module lá) sẽ được tích hợp và kiểm thử trước (các module này không gọi module nào khác) và sau đó đến lần lượt là các module trực tiếp gọi 1 hay nhiều module vừa được kiểm thử được tích hợp vào và test. Những module chưa có hay chưa được phát triển sẽ được thay thế bởi các drivers.

Cùng xem ví dụ dưới đây để hiểu rõ hơn:

Modules Rank, Marks, Percentage và Sports Grade chưa được phát triển nên chúng sẽ được thay thế bởi các driver liên quan:

Phương pháp tiếp cận Kiểm thử Tích hợp Bottom up

Test case sẽ được phát triển theo hướng sau đây:

Test Case1: Kiểm thử đơn vị hai module Practical và Theory

Test Case2: Tích hợp và kiểm thử các module Marks-Practical-theory

Test Case3: Tích hợp và kiểm thử các module Percentage-Marks-Practical-Theory

Test Case4: Kiểm thử đơn vị Module Sports Grade

Test Case5: Tích hợp và kiểm thử các module Rank-Sports Grade-Percentage-Marks-Practical-Theory

Ưu điểm của phương pháp Bottom-up

• Phương pháp này hết sức hữu ích cho những ứng dụng sử dụng mô hình thiết kế từ dưới lên.

• Việc tạo ra điệu kiện test trong phương pháp bottom-up đơn giản hơn.

• Để bắt đầu kiểm thử ở mức độ thấp nhất của sơ đồ cấu trúc, ta phải bắt đầu bằng việc chọn ra những module hoặc chức năng tối quan trọng để kiểm thử ngay từ đầu. Việc này cho phép ta tìm ra những lỗi sai sớm hơn.

• Lỗi interface (giao tiếp giữa 2 module) sớm được phát hiện.
  

Nhược điểm của phương pháp Bottom-up

• Viết drivers thường khó hơn viết stub

• Các lỗi về thiết kế cấu trúc thường được phát hiện muộn hơn

• Trong phương pháp này, chỉ tới khi module cuối cùng được build xong thì chúng ta mới có sản phẩm ứng dụng chạy được.

• Tương tự như stub, driver không phải là bản chạy hoàn chỉnh của module thật. Nó chỉ mô phỏng luồng dữ liệu giữa hai module. is not a complete implementation of related Module.
  

3. Sandwich

Phương pháp này là sự kết hợp giữa phương pháp Top-down và Bottom-up. Cả stub và driver được sử dụng để thay thế cho những module chưa được phát triển hoặc chưa hoàn thiện.

Phương pháp tiếp cận:

• Một lớp trung gian (middle layer) được xác định ra để từ đó triển khai việc kiểm thử kiểu bottom-up và top-down. Lớp trung gian này được gọi là lớp mục tiêu (target layer).

• Target layer được xác định bằng phương pháp Heuristic, cụ thể là, chọn một lớp mà ở đó số lượng các stub và driver cần sử dụng là nhỏ nhất.

• Kiểm thử Top-down bắt đầu từ lớp trung gian này và di chuyển dần xuống về phía những module ở cấp độ thấp hơn. Lớp phía dưới middle layer cũng được gọi là bottom layer.

• Kiểm thử Bottom-up cũng bắt đầu từ lớp giữa này sau đó di chuyển lên phía các module thuộc vào lớp trên cùng. Lớp phía trên middle layer cũng được gọi là Top layer.

• Bặng việc sử dụng stub và driver, giao diện người dùng và các chức năng của những module cấp độ thấp hơn sẽ lần lượt được kiểm thử.

• Chỉ có lớp trung gian (middle layer) là đối tượng duy nhất bị bỏ lại để test sau cùng.
  

Ví dụ:

Test case có thể được phát triển theo hướng sau đây áp dụng phương pháp Sandwich:

Test Case1: Kiểm thử A, X, Y, và một cách riêng rẽ - khi đó việc kiểm thử A sẽ thuộc vào kiểm thử top layer và kiểm thử X, Y và Z sẽ thuộc vào kiểm thử bottom layer.

Test Case2: Kiểm thử A, G, H và I

Test Case3: Kiểm thử G, X, và Y

Test Case4: Kiểm thử H và Z

Test Case5: Kiểm thử A, G, H, I, X, Y, và Z

Ưu điểm của phương pháp kiểm thử Sandwich

• Nó vô cùng hữu ích đối với một dự án lớn mà trong đó có nhiều dự án con.

• Có thể cùng lúc thực hiện được hai phương pháp kiểm thử Top-down và bottom-up
  

Nhược điểm của phương pháp kiểm thử Sandwich

• Trước khi kết hợp được các module vào với nhau, các hệ thống con chưa hoàn thiện này và các giao tiếp giữa các module chưa được kiểm thử kĩ càng.

• Cũng chính bởi kết hợp cả hai phương pháp bottom-up và top-down nên chi phí thực hiện cũng cao hơn.

• Phương pháp này không thích hợp cho những hệ thống mà trong đó các module phụ thuộc chặt chẽ lẫn nhau.

IV. Tổng kết

Kiểm thử Tăng tiến là một trong các kĩ thuật Kiểm thử Tích hợp. Trong phương pháp kiểm thử này, kiểm thử tích hợp được thực hiện trên các module riêng rẽ như là một phần của kiểm thử đơn vị và trong giai đoạn kế tiếp, các module và thành phần của ứng dụng được tích hợp tăng dần và khi đó việc kiểm thử sẽ được thực hiện trên một nhóm các module được kết hợp lại.

Trong ba phương pháp thực hiện kiểm thử Tích hợp Tăng tiến nêu ra trên đây, việc lựa chọn phương pháp nào để áp dụng phụ thuộc và cấu trúc của ứng dụng cũng như vị trí của những module tiềm ẩn nhiều nguy cơ xảy ra lỗi.

Tuy nhiên cả 3 phương pháp này đều được xếp vào hạng mục kiểm thử theo chiều ngang (horizontal) bởi các lí do sau đây:

• Cả ba phương pháp đều tập trung vào kiểm thử theo lớp

• Cả ba phương pháp đều quan tâm tới thiết kế cấu trúc hay cấp bậc

• Cả ba phương pháp đều tích hợp các lớp theo hướng tăng dần
  

Ưu điểm

Với phương pháp kiểm thử này, việc xác định lỗi sớm sẽ dễ dàng hơn, và cũng vì vậy mà các lập trình viên cũng dễ tìm ra nguyên nhân gây ra lỗi hơn. Bởi vì nó sử dụng những nguyên lí căn bản của kiểm thử cấu trúc, nên phương pháp kiểm thử này thực tế rất hiệu quả và có độ chính xác cao.

Nhược điểm:

Phương pháp kiểm thử này tương đối tốn thời gian do yêu cầu sử dụng stub và driver. Bên cạnh đó nó còn lặp lại khá nhiều bước.

*Nguồn tham khảo:* http://www.softwaretestinghelp.com/incremental-testing/ http://www.cse.hcmut.edu.vn/~hiep/KiemthuPhanmem/LyThuyetViet/Chuong08.pdf