Kiểm thử tích hợp là gì và nó được thực hiện như thế nào? (Phần 2)

Bài này sẽ giới thiệu phần còn lại của bài báo: Kiểm thử tích hợp giao diện đồ họa của ứng dụng và Tại sao lại cần kiểm thử tích hợp.

Kiểm thử tích hợp giao diện đồ họa của ứng dụng

Hãy nói về làm thế nào chúng ta có thể bao hàm kiểm thử tích hợp trong phương pháp kiểm thử hộp đen. Tất cả chúng ta đều hiểu rằng một ứng dụng web là một ứng dụng đa tầng. Chúng ta có front-end: người dùng cuối có thể nhìn thấy được, chúng ta có middle layer chứa logic business, thực hiện việc xác nhận tính hợp lệ của dữ liệu, tích hợp một số API của bên thứ 3, ... tiếp đó chúng ta có lớp là cơ sở dữ liệu.

Cùng kiểm tra ví dụ dưới đây: Tôi là người sở hữu một công ty quảng cáo và tôi dán những bài quảng cáo trong các trang web khác nhau. Cuối tháng, tôi muốn nhìn thấy có bao nhiêu người đã xem bài quảng cáo của tôi và bao nhiêu người đã click vào bài quảng cáo của tôi. Tôi cần một bản báo cáo hiển thị cho bài quảng cáo của tôi và tôi tính phí một cách phù hợp cho khách hàng của tôi. GenNext software đã phát triển sản phẩm này cho tôi và dưới đây là kiến trúc: UI– Module giao diện người dùng: người dùng cuối có thể nhìn thấy được, nơi mà tất cả các dữ liệu đầu vào được đưa ra. BL – Là module logic nghiệp vụ: chứa tất cả những sự tính toán và các hàm nghiệp vụ đặc trưng. VAL – Là module xác nhận tính hợp lệ dữ liệu: chứa tất cả những sự xác nhận tính đúng đắn của dữ liệu đầu vào. CNT – Là module nội dung: chứa tất cả những nội dung tĩnh, cụ thể cho các dữ liệu đầu vào được nhập bởi người dùng. Những nội dung này được hiển thị trong báo cáo. EN– Là module máy, module này đọc tất cả những dữ liệu từ module BL, VAL và CNT và trích xuất câu lệnh truy vẫn SQL và khởi động nó đến cơ sở dữ liệu. Schedule – Là một module cái mà lên kế hoạch tất cả những báo cáo dựa trên sự lựa chọn của người dùng (hàng tháng, hàng quý, hàng nửa năm, hàng năm) DB – Là cơ sở dữ liệu. Bây giờ, hãy nhìn kiến trúc tổng thể của ứng dụng web, như là một đơn vị duy nhất, kiểm thử tích hợp trong trường hợp này sẽ tập trung vào luồng dữ liệu giữa các module. Câu hỏi ở đây là:

1. Các module BL, VAL, CNT sẽ đọc và biên dịch dữ liệu được nhập trong module giao diện người dùng như thế nào?
2. Module BL, VAL và CNT có đang nhận đúng dữ liệu từ UI?
3. Định dạng dữ liệu nào từ BL, VAL, CNT được chuyển tới module EQ?
4. EQ sẽ đọc dữ liệu và trích xuất câu lệnh truy vấn như thế nào?
5. Câu lệnh truy vấn có được trích xuất đúng?
6. Trình lập lịch có đang lấy dữ liệu đúng cho báo cáo?
7. Bộ kết quả được nhận bởi EN, từ cơ sở dữ liệu có đúng và như mong đợi không?
8. EN có thể gửi câu trả lời trở lại BL, VAL, CNT?
9. Module UI có thể đọc dữ liệu và hiển thị nó tới giao diện một cách phù hợp?

Trong thực tế, sự giao tiếp của dữ liệu được hoàn thành dưới định dạng XML. Vì vậy dữ liệu mà người dùng nhập vào trong giao diện người dùng, nó được đổi sang định dạng XML. Trong kịch bản của chúng ta, dữ liệu mà người dùng nhập vào trong UI module được chuyển đổi sang file XML, được biên dịch bới 3 module BL, VAL, CNT. Module EN đọc file kết quả dạng XML được sinh ra bởi 3 modules và trích xuất lệnh SQL từ nó và truy vấn tới cơ sở dữ liệu. Module EN cũng nhận được bộ kết quả và chuyển đổi nó sang một file XML và trả nó về module UI cái mà chuyển đổi kết quả thành mẫu mà người dùng có thể đọc được và hiển thị nó. Ở giữa, chúng ta có module trình lập lịch để nhận bộ kết quả từ module EN, tạo và lên kế hoạch những báo cáo. Vậy kiểm thử tích hợp đi vào hình ảnh ở đâu? Việc kiểm thử liệu thông tin/ dữ liệu có đang đi theo luồng đúng hoặc sẽ không là kiểm thử tích hợp, cái mà trong trường hợp này sẽ xác nhận những file XML. Những file XML có được sinh ra một cách đúng đắn? Chúng có chứa dữ liệu đúng? Dữ liệu có được chuyển đúng từ module này sang module khác? Tất cả những biểu hiện này sẽ được kiểm thử như là một phần của kiểm thử tích hợp. Thử tạo ra hoặc lấy những file XML và cập nhật những cái thẻ (tags) và kiểm tra biểu hiện. Đây là những cái rất khác so với việc kiểm thử thông thường cái mà testers thường làm, nhưng điều này sẽ thêm giá trị cho kiến thức và sự hiểu biết của tester về ứng dụng.

Một vài điều kiện kiểm thử mẫu khác có thể như sau:

• Các lựa chọn trình đơn có đang mở ra cửa sổ đúng không?
• Các cửa sổ có thể gọi tới cửa sổ đang được kiểm thử không?
• Với mọi cửa sổ, cần nhận dạng/định danh functions gọi tới cửa sổ mà ứng dụng nên cho phép
• Nhận dạng tất cả cuộc gọi từ cửa sổ kiểm thử tới các tính năng khác mà ứng dụng nên cho phép
• Nhận dạng những cuộc gọi có thể đảo chiều: những cửa sổ đang gọi đóng lại trước khi cửa sổ được gọi xuất hiện
• Kiểm thử những cách khác nhau để thực hiện các cuộc gọi tới cửa sổ khác , ví dụ: menus, buttons, keywords

Tại sao cần kiểm thử tích hợp?

Chúng ta nhận thấy rằng Kiểm thử tích hợp khá phức tạp và yêu cầu một số kỹ năng logic và phát triển phần mềm. Điều đó là đúng! Vậy mục đích của việc tích hợp kiểm thử tích hợp vào chiến lược kiểm thử phần mềm là gì? Dưới đây là một số lí do:

• Trong thực tế, khi các ứng dụng được phát triển, nó được chia thành các module nhỏ và mỗi dev sẽ được giao một module. Logic được thực hiện bởi mỗi dev khá là khác nhau , do vậy việc kiểm tra xem logic thực hiện bởi mỗi dev có như mong đợi và có trả về giá trị đúng theo những tiêu chuẩn được quy định là rất quan trọng.
• Nhiều thời điểm, bề mặt hoặc cấu trúc dữ liệu thay đổi khi nó di chuyển từ module này đến module khác. Một vài giá trị được thêm vào hoặc bị bỏ đi gây ra lỗi cho các module sau này.
• Các modules cũng tương tác với một vài công cụ hoặc APIs của bên thứ ba cái mà cũng cần được kiểm thử xem dữ liệu được chấp nhận bởi APIs/ công cụ đó có đúng không và kết quả trả về có như mong đợi.
• Một vấn đề rất thông thường trong kiểm thử - Sự thay đổi requirements thường xuyên! Nhiều khi dev deploy những thay đổi mà không thực hiện kiểm thử đơn vị, khi đó, việc kiểm thử tích hợp trở lên rất quan trọng.

Cuối cùng, kết luận các bước để kick off những kiểm thử tích hợp:

• Hiểu rõ kiến trúc của ứng dụng
• Nhận dạng/định danh các modules
• Hiểu rõ vai trò mỗi module, mỗi module làm gì
• Hiểu làm thế nào dữ liệu được di chuyển từ một module sang module khác
• Hiểu rõ dữ liệu được nhập vào hệ thồng và được nhận lại như thế nào (điểm vào và điểm ra của ứng dụng)
• Cô lập ứng dụng để phù hợp với nhu cầu kiểm thử
• Định danh và tạo các điều kiện kiểm thử
• Lấy một điều kiện tại một thời điểm và viết ra những test cases

Đây là tất cả về kiểm thử tích hợp và việc thực hiện nó trong cả phương pháp kiểm thử hộp trắng và kiểm thử hộp đen. Hi vọng chúng tôi đã giải thích nó một cách rõ ràng với các ví dụ liên quan. Nguồn dịch: http://www.softwaretestinghelp.com/what-is-integration-testing/