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

Để làm Kiểm thử gắn vào, các tester có thể dùng 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 hợp làm rõ các việc sau:

Thế nào là Kiểm thử tăng tiến Mục đích của việc làm kĩ thuật này là gì? Các cách thức để làm nó là gì? Những điểm tốt của kĩ thuật này? Nhược điểm của việc làm 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ử gắn vào tăng tiến, là một trong các cách thức làm Kiểm thử gắn vào, trong đó có sự phối hợp của các nguyên tắc và khái niệm cơ bản.

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

Khi làm kĩ thuật test này, ta sẽ kiểm thử đã có lần module khác nhau trong thời điểm kiểm thử đơn vị (unit). tiếp theo, các module sẽ được gắn vào 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ì gắn vào cả một hệ thống lớn vào nhau cùng lúc rồi làm kiểm thử trên sản phẩm sau cùng thì với kĩ thuật này, việc ta làm đó là phối hợp đã có lần module theo hướng tăng dần, cụ thể là lần lượt thêm đã có lần module một rồi dần dần tăng lên, làm 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 gắn vào vào hệ thống, sẽ được kiểm thử theo nhóm để đảm bảo việc gắn vào và trao đổi tin tức giữa các module đã thành công.

Giống như trong kiểm thử gắn vào, việc kiểm thử tập hợp chủ yếu vào kiểm tra giao tiếp giữa các module (interface), những mối liên lạc gắn vào, và dòng tin tức 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 phối 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 app phần mềm bao gồm những module sau đây:

cách thức tiếp cận Kiểm thử gắn vào Tăng tiến

Mỗi Module: M1, M2, M3, v.v… được kiểm tra một cách khác nhau (unit testing)

đã có lần modules được gắn vào và test để đảm bảo khi phối 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 phối 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 phối 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 giống như 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 gắn vào vẫn đang đi đúng hướng.

Hình 2

Hình 3

Hình 4

II. Mục đích của việc làm 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 gắn vào vào.

xác định được bug/defect sớm hơn và rất dễ biết được nó diễn ra ở thời điểm gắn vào module nào. Nhờ đó, cấp quyền vận chuyển tận nhàer (lập trình viên) xác định việc nằm ở đâu và điều tra Tại sao nhanh hơn. Ví dụ, M1 và M2 được gắn vào thành công nhưng khi thêm M3 vào lại gây ra lỗi, lúc này lập trình viên có thể nhanh nhẹn khoanh vùng để tìm hiểu về lỗi này.

Việc phát giác lỗi sớm sẽ giúp đỡ ta xử lí, giải quyết mà không cần phải “đập hết đi xây lại” và kiệm ước chi phí hơn.

III. Các cách thức để làm nó là gì?

Trước khi đi vào nói về các cách thức cụ thể, hãy cùng xem qua hai khái niệm “Stubs”“Drivers”. Hai khái niệm này sẽ được nhắc đến khá liên tục trong content bài viết.

Stubs và drivers đều là những đoạn vận chuyển tận nhàe giả hay mô phỏng được dùng trong kiểm thử gắn vào 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 vài module khác lại cần phải có các module này.

Stubs được dùng trong cách thức kiểm thử Top-down và được biết đến 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 để dùng hoặc chưa được phát triển.

Drivers được dùng trong cách thức kiểm thử Bottom-up và được biết đến 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 để dùng hoặc chưa được phát triển.

một vài người có thể sẽ có một thắc mắc khi bắt tay vào kiểm thử đó là, vì sao lại không chờ tới khi tất cả các module của app đượ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 dễ làm nhất đó là nếu chờ đợi, thì thời gian làm 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 vận chuyển tận nhàe 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 tìm hiểu căn nguyên của defect khó khăn hơn. cách thức kiểm thử này được biết đến với tên là Kiểm thử gắn vào Big-Bang.

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

1. Top Down

Đúng như tên của nó, việc kiểm thử được làm 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), tiếp theo tới các module nhánh phía dưới 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 app sẽ được kiểm thử trước.

cách thức này đi theo dòng cấu trúc của app. 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 dùng các stubs.

Cùng xem ví dụ sau đây:

Module: web 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)

cách thức tiếp cận Kiểm thử gắn vào 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 gắn vào và test

Test Case2: Module L, O và P sẽ được gắn vào và test

Test Case3: Module L, O, P và R sẽ được gắn vào và test.

giống như 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 gắn vào vào và kiểm thử trước. Một cách thức 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 gắn vào và test

Test Case2: Module L, O và OS sẽ được gắn vào và test

Test Case3: Module L, O, OS, P sẽ được gắn vào và test

Test Case4: Module L, O, OS, P, CP sẽ được gắn vào và test

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

Ưu điểm của cách thức Top-down

phát giác sớm các lỗi cấu trúc

Vạch ra tổng thế làm việc, chương trình khung sườn của app ngay từ những thời điểm đầu tiên đồng thời sớm chỉ ra những lỗi quan hệ tới design (design hệ thống)

Những lỗi có khuynh hướng diễn ra ở các module thuộc cấp độ cao được kiểm tra và phát giác từ sớm.

Nhược điểm của cách thức Top-down

Sẽ có những module trọng yếu nhưng lại bị test ở thời điểm 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 có khả năng do khoảng cách khá xa giữa module cần test và module chứa các data để cung ứng cho module cần test.

Phải tạo ra các stub để cung ứng các module 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 data giữa hai module mà không thể tạo ra đầy đủ data như module thật nên khi test bằng stub sẽ không thể test hết các tình thế về tương tác của các module thật được.

2. Bottom-up

Trong cách thức này, kiểm thử được làm từ dưới lên. Cụ thể là, các module ở lớp dưới cùng (module lá) sẽ được gắn vào và kiểm thử trước (các module này không gọi module nào khác) và tiếp theo đế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 gắn vào 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ụ sau đâ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 quan hệ:

cách thức tiếp cận Kiểm thử gắn vào 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: gắn vào và kiểm thử các module Marks-Practical-theory

Test Case3: gắn vào và kiểm thử các module Percentage-Marks-Practical-Theory

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

Test Case5: gắn vào và kiểm thử các module Rank-Sports Grade-Percentage-Marks-Practical-Theory

Ưu điểm của cách thức Bottom-up

cách thức này hết sức hữu ích cho những app dùng mô hình design từ dưới lên.

Việc tạo ra điệu kiện test trong cách thức bottom-up dễ làm hơn.

Để khởi đầu kiểm thử ở mức độ thấp nhất của sơ đồ cấu trúc, ta phải khởi đầu bằng việc chọn ra những module hoặc chức năng tối trọng yếu để kiểm thử ngay từ đầu. Việc này cấp quyền 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 giác.

Nhược điểm của cách thức Bottom-up

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

Các lỗi về design cấu trúc thường được phát giác muộn hơn

Trong cách thức này, chỉ tới khi module sau cùng được build xong thì ta mới có sản phẩm app chạy được.

giống như 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 data giữa hai module. is not a complete implementation of related Module.

3. Sandwich

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

cách thức tiếp cận:

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

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

Kiểm thử Top-down khởi đầ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 khởi đầu từ lớp giữa này tiếp theo 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 dùng stub và driver, giao diện người sử 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 cách thức 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 cách thức 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 làm được hai cách thức kiểm thử Top-down và bottom-up

Nhược điểm của cách thức kiểm thử Sandwich

Trước khi phối 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 phối hợp cả hai cách thức bottom-up và top-down nên chi phí làm cũng cao hơn.

cách thức này không phù 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ử gắn vào. Trong cách thức kiểm thử này, kiểm thử gắn vào được làm trên các module riêng rẽ như là một phần của kiểm thử đơn vị và trong thời điểm kế tiếp, các module và thành phần của app được gắn vào tăng dần và khi đó việc kiểm thử sẽ được làm trên một nhóm các module được phối hợp lại.

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

mặc dù vậy cả 3 cách thức 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 cách thức đều nhắm vào kiểm thử theo lớp

Cả ba cách thức đều quan tâm tới design cấu trúc hay cấp bậc

Cả ba cách thức đều gắn vào các lớp theo hướng tăng dần

Ưu điểm

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

Nhược điểm:

cách thức kiểm thử này tương đối tốn thời gian do yêu cầu dùng stub và driver. song song với đó 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

Nguồn viblo.asia