Spec Explorer và Selenium
Theo truyền thống, việc kiểm thử (nếu có) sẽ được thực hiện bởi một nhóm các Tester độc lập sau khi các chức năng được phát triển và trước khi nó được chuyển tới khách hàng. Thực tế này gây ra tốn kém rất nhiều tài nguyên do các lỗi hệ thống không được ngăn chặn sớm mà chỉ được phát hiện khi gần như đã hoàn thành hệ thống. Khi đó việc tìm kiếm và sửa lỗi sẽ rất khó khăn do không có các hiện vật kết quả của từng giai đoạn phát triển mà phải lục tìm trong một mớ hỗn độn các mã nguồn.
Kiểm thử hướng mô hình có thể khắc phục triệt để các hạn chế đó, do nó có thể tích hợp vào quá trình phát triển ứng dụng ngay từ những ngày đầu tiên, khi mới có yêu cầu cụ thể của bài toán. Thêm nữa, nếu các quá trình phía trước còn bỏ sót lỗi thì khi phát hiện lỗi ở các quá trình tiếp theo sẽ rất dễ dàng để tìm kiếm và sửa ngay lỗi xảy ra (do có lưu lại toàn bộ các hiện vật trong quá trình phát triển). Đồng thời còn có thể phán đoán ngay các lỗi tiếp theo có thể xảy ra khi hệ thống có thay đổi. Từ đó ngăn chặn được các lỗi ngay từ đầu và giảm thiểu tối đa hao phí tài nguyên cho việc phát triển cũng như bảo trì web.
Tuy nhiên, Kiểm thử hướng mô hình không phải là một công cụ vạn năng cho quá trình kiểm thử. Nó chỉ có thể áp dụng được khi đã có bản đặc tả chi tiết về hệ thống cần xây dựng. Qua đó mới có thể xác định được các trạng thái và hành vi hệ
Luận văn thạc sỹ Nguyễn Hải Dương – CB130387
29
thống một cách đúng đắn để xây dựng được mô hình trực quan. Do mấu chốt của kiểm thử hướng mô hình là việc xây dựng được các mô hình một cách đúng đắn và đầy đủ nhất có thể, nên kiểm thử hướng mô hình không thể thực hiện khi chưa xác định được các trạng thái và hành vi của hệ thống (hay cũng chính là khi chưa có đặc tả chi tiết, cụ thể về hệ thống) .
Quá trình kiểm thử hướng mô hình được bắt đầu bằng việc xác định yêu cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ thống. Việc xây dựng mô hình cần phải dựa trên các yếu tố dữ liệu đầu vào và đầu ra. Mô hình này được sử dụng để sinh đầu vào cho các ca kiểm thử. Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng với mỗi bộ đầu vào. Khi kết thúc bước này, chúng ta được các ca kiểm thử. Các kịch bản kiểm thử sẽ được thiết kế và thực thi nhằm phát hiện các lỗi/khiếm khuyết của sản phẩm bằng cách so sánh đầu ra thực tế với đầu ra mong đợi tương ứng của ca kiểm thử. Từ các kết quả kiểm thử, chúng ta sẽ quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử.
Luận văn thạc sỹ Nguyễn Hải Dương – CB130387
30
Hình 2: Quy trình kiểm thử hƣớng mô hình
Hình 2 mô tả các bước của quy trình kiểm thử hướng mô hình, trong đó:
Bước 1: Mô hình hóa mô hình kiểm thử bằng Spec Explorer
Bao gồm (1.1) Sinh mô hình và (1.2) Sinh các ca kiểm thử trong Hình 2. Ở bước này, từ bản đặc tả yêu cầu phần mềm, ta có thể xác định được các tác vụ/chức năng cần có của hệ thống. Qua đó xác định được các trạng thái/hành động/sự kiện phát sinh làm thay đổi trạng thái hệ thống. Đó chính là căn cứ để sinh mô hình kiểm thử (1.1 trong Hình 2). Ngoài ra bản đặc tả yêu cầu phần mềm cũng đóng vai trò làm đầu vào cho việc sinh các đầu ra mong muốn của từng tác vụ/chức năng hệ thống. Qua đó ta có thể đem so sánh ngay mô hình có được ở 1.1 với các đầu ra mong muốn này để đánh giá mô hình ngay từ
Luận văn thạc sỹ Nguyễn Hải Dương – CB130387
31
những bước đầu tiên, nhằm phát hiện các lỗi ngay từ sớm để có biện pháp chỉnh sửa cho đúng, cũng như cắt giảm ngay các chi phí phát sinh về sau nếu gặp phải các lỗi này.
Trong các tác vụ tiếp theo, Spec Explorer sẽ tự động sinh các ca kiểm thử và các kịch bản kiểm thử (1.2 trong Hình 2).
Bước 2. Thực hiện các kịch bản kiểm thử bằng Selenium.
Bao gồm (2) Thực hiện các kịch bản kiểm thử trong Hình 2.
Ở bước này, để tránh việc hao tổn lớn đến tài nguyên phát triển phần mềm (bao gồm cả về kinh tế và nhân lực) cho việc tạo các Adapter chuyển đổi Test Script tự sinh của Spec Explorer trong bước 1, ta sử dụng Selenium để thực
thi ra các ca kiểm thử/các kịch bản kiểm thử (2 trong Hình 2) một cách trực
quan, dễ dàng cũng như giảm các hao phí tài nguyên đến mức tối đa.
Qua bước này ta có được báo cáo kiểm thử bằng việc ghi nhận đầu ra của hệ thống với từng ca kiểm thử. Báo cáo kiểm thử này được đem so sánh với cả mô hình ở 1.1 và cả đầu ra mong muốn đã có ở trên. Từ đó đánh giá kết quả thu được khi thực hiện thực tế các ca kiểm thử/các kịch bản kiểm thử có được ở 1.2
Bước 3: Đánh giá chéo giữa mô hình và thực tế.
Bao gồm (3) Đánh giá chéo trong Hình 2.
Ở bước này, việc kiểm tra/đánh giá chéo giữa mô hình kiểm thử với thực tế là rất cần thiết. Qua đó có thể phát hiện các lỗi xảy ra trong hệ thống cũng như những tác vụ còn thiếu sót để có biện pháp xử lý kịp thời. Sau khi quyết định các giải pháp giải quyết vấn đề cần cập nhật lại mô hình, sau đó đánh giá ngay lại các tác vụ liên quan trên mô hình xem có phát hiện thêm lỗi mới nào không. Nếu không thì thực hiện lại bắt đầu từ bước 1.2 trong Hình 2.
Bước 4: Tham khảo ý kiến của chuyên gia và người dùng cuối.
Luận văn thạc sỹ Nguyễn Hải Dương – CB130387
32
Việc tham khảo kinh nghiệm kiểm thử của các chuyên gia là rất cần thiết. Nhìn vào mô hình và các yêu cầu hệ thống, họ có thể phát hiện ngay các lỗi có thể xảy ra từ rất sớm, tránh được rất nhiều các hao phí tài nguyên cho việc phát triển phần mềm về sau. (adsbygoogle = window.adsbygoogle || []).push({});
Ngoài ra, người dùng cuối cũng đóng vai trò rất quan trọng trong việc phản hồi ý kiến về các lỗi xảy ra trong quá trình chạy của hệ thống. Đây cũng là đối tượng và là mục tiêu cuối cùng mà việc phát triển hệ thống cần hướng đến để làm thỏa mãn nhu cầu của họ bằng việc nâng cao chất lượng phần mềm. Các bước kiểm thử nói trên diễn ra trong quy trình phát triển ứng dụng (Web) và có thể được thực hiện bởi các nhà phát triển bằng cách kiểm tra các mô hình ở các mức trừu tượng khác nhau, và nên được thực hiện lặp đi lặp lại cho đến khi các mô hình này đạt được các yêu cầu kiểm thử. Điều này cho phép tích hợp các ca kiểm thử ngay từ giai đoạn đầu của quá trình phát triển. Tuy nhiên, việc đánh giá khi sử dụng của ứng dụng web vẫn cần có sự tham gia của người dùng cuối. Có thể coi quá trình sử dụng của người dùng cuối như bước kiểm thử cuối cùng cho việc phát triển ứng dụng. Thông qua việc thu thập những phản hồi của người dùng cuối cũng có thể tạo ra một báo cáo đánh giá để cung cấp thông tin phản hồi ở giai đoạn nào đó của quá trình phát triển.