Giới thiệu đề tài
Đặt vấn đề
Sự gia tăng nhanh chóng của ứng dụng web yêu cầu việc bảo trì và nâng cấp tính năng liên tục Để đảm bảo chất lượng cho các ứng dụng này, tối ưu hóa giải pháp kiểm thử tự động trở thành một yêu cầu thiết yếu Kiểm thử tự động mang lại nhiều lợi ích như tiết kiệm thời gian và chi phí, đồng thời giảm thiểu sự nhàm chán cho kiểm thử viên Thông qua việc sử dụng các công cụ tự động hóa, quy trình kiểm thử sẽ cần ít nhân lực hơn, xử lý nhanh chóng các trường hợp kiểm thử và giảm thiểu lỗi do con người gây ra.
Các công cụ kiểm thử tự động hiện nay gặp phải hai nhược điểm lớn: yêu cầu kiểm thử viên có kiến thức lập trình và thời gian để viết kịch bản kiểm thử Điều này trở thành rào cản lớn vì kiểm thử viên thường có mức lương và yêu cầu tuyển dụng thấp hơn lập trình viên, dẫn đến việc họ không có kỹ năng lập trình tốt Do đó, việc đào tạo kiểm thử viên sẽ tốn nhiều thời gian và công sức.
Việc viết kịch bản kiểm thử tự động, ngay cả với những lập trình viên đã thành thạo, vẫn tốn thời gian Quy trình kiểm thử mỗi use case thường bao gồm ba bước: đầu tiên, chuyên viên cần lập bảng các bước kiểm thử và mô tả trường hợp kiểm thử bằng ngôn ngữ tự nhiên; sau đó, họ chuyển đổi các trường hợp kiểm thử thành kịch bản kiểm thử tự động.
(script) theo quy cách của framework kiểm thử tự động và bước sau cùng là chạy kịch bản.
Thời gian thực hiện hai bước đầu tiên dao động từ 10-60 phút, tùy thuộc vào độ phức tạp và số lượng test case trong mỗi use case Việc kiểm thử viên sao chép mã nguồn kịch bản từ use case này sang use case khác có thể dẫn đến sai sót do sự chủ quan, vì nhiều use case có các bước tương tự nhau Hơn nữa, việc lặp lại mã nguồn còn gây khó khăn trong việc bảo trì kịch bản kiểm thử tự động.
Kịch bản kiểm thử tự động cũng là một phần mềm, do đó, cần phải được kiểm thử để đảm bảo hoạt động đúng theo logic mong muốn Việc kiểm thử này thường được thực hiện thủ công, dẫn đến tốn thời gian và có khả năng xảy ra sai sót, làm giảm tính chính xác của kết quả kiểm thử cho use case ban đầu.
Chương 1 Giới thiệu đề tài
Mục tiêu của chúng tôi là hỗ trợ kiểm thử viên thực hiện kiểm thử tự động mà không cần lập trình, giúp rút ngắn thời gian hoàn thành kiểm thử cho một use case một cách nhanh chóng và đơn giản nhất.
Mục tiêu và phạm vi đề tài
Hiện nay trên thị trường có nhiều công cụ kiểm thử website tự động như
Các công cụ như Selenium, Ranorex và QTP giúp tái hiện các thao tác thủ công của người dùng trên trình duyệt web thông qua việc tự động chạy các kịch bản được viết bởi kiểm thử viên Các ngôn ngữ hỗ trợ viết kịch bản như JavaScript và VBScript có ưu điểm là dễ học, dễ viết và tương thích với nhiều nền tảng khác nhau.
Mặc dù các công cụ kiểm thử như Selenium WebDriver, QTP và RANOREX mang lại nhiều lợi ích, nhưng vẫn tồn tại những hạn chế đáng chú ý Selenium WebDriver là một công cụ mã nguồn mở nhưng khó sử dụng, yêu cầu kiểm thử viên phải dành thời gian học ngôn ngữ lập trình để viết kịch bản kiểm thử tự động Trong khi đó, QTP và RANOREX tích hợp tính năng Kho đối tượng (Object Repository), cho phép kỹ sư kiểm thử bổ sung test case mà không cần chỉnh sửa kịch bản, nhưng việc tạo và chỉnh sửa cho các kịch bản kiểm thử với bộ dữ liệu tương tự vẫn chưa linh hoạt Hơn nữa, cả hai phần mềm này đều có tính phí, không phù hợp với các doanh nghiệp nhỏ.
Luận văn này sẽ phát triển một mô hình và công cụ nhằm khắc phục những nhược điểm của các phần mềm kiểm thử hiện tại, cho phép kiểm thử viên viết và thực hiện các kịch bản kiểm thử mà không cần kiến thức lập trình Công cụ kiểm thử tự động được thiết kế dựa trên các Hành động (Action) đã được định nghĩa trong file Excel, với các tiêu chuẩn rõ ràng về đầu vào và đầu ra, giúp cải thiện hiệu suất kiểm thử Hiện tại, công cụ này sử dụng 26 Hành động cơ bản, tập trung vào việc phục vụ cho kiểm thử tự động ứng dụng Web.
Định hướng giải pháp
Ý tưởng của luận văn là phát triển một mô hình kiểm thử tự động cho website thông qua các hành động (Action) đã được thiết kế sẵn Các hành động này trong file Excel hoạt động dựa trên các lời gọi hàm của giao diện người dùng ứng dụng (Application User Interface).
API trong Selenium WebDriver cho phép thực hiện các hành động tương tác với phần tử web Tuy nhiên, việc viết câu lệnh API có thể là một thách thức đối với những kiểm thử viên thiếu kiến thức lập trình Để giải quyết vấn đề này, luận văn đã mô hình hóa các câu lệnh thành các action định sẵn trong file Excel, giúp kiểm thử viên dễ dàng viết kịch bản kiểm thử mà không cần kiến thức lập trình Thêm vào đó, việc tạo và chỉnh sửa nhiều bộ dữ liệu kiểm thử tương tự cũng trở nên đơn giản và dễ quản lý hơn.
Kiểm thử viên chỉ cần chuẩn bị file dữ liệu kiểm thử định dạng xlsx hoặc xls, bao gồm 4 sheet: (1) sheet metadata chứa thông tin về usecase cho báo cáo kết quả, (2) sheet Test Data mô tả kịch bản kiểm thử, (3) sheet Test Steps chi tiết các bước thực hiện, và (4) sheet Test Result lưu trữ kết quả kiểm thử Công cụ phát triển dựa trên Selenium WebDriver sẽ đọc từ file excel các thông tin như action, phương thức tìm kiếm phần tử web (id, name, xpath, ), và giá trị tương ứng để xác định phần tử Các tham số này được lưu vào lớp quản lý dữ liệu, và khi tái hiện mỗi test case, công cụ sẽ truyền các tham số và thực hiện hành động tương ứng Kết quả kiểm thử sẽ được tự động cập nhật vào Sheet Test Result trong cùng file đầu vào.
Mô hình hóa các action theo định nghĩa sẵn giúp nhanh chóng thêm mới các action, từ đó đáp ứng đa dạng kịch bản kiểm thử trong tương lai Khi cần bổ sung action mới, nhà phát triển chỉ cần viết một API với các tham số cần thiết và thêm API đó vào phần xử lý action trong lớp Bổ trợ (Helper).
Bố cục luận văn
Luận văn tốt nghiệp này gồm 6 chương với nội dung như sau:
Trong chương 2, luận văn giới thiệu cơ sở lý thuyết về kiểm thử phần mềm, bao gồm khái niệm tổng quát, nguyên tắc cơ bản, quy trình và các kỹ thuật kiểm thử Tiếp theo, chương phân tích khái niệm kiểm thử tự động, so sánh ưu điểm của nó với kiểm thử thủ công và trình bày quy trình thực hiện Cuối cùng, chương tập trung vào các công cụ kiểm thử tự động phổ biến hiện nay, nêu rõ những nhược điểm của chúng và đề xuất giải pháp khắc phục thông qua việc sử dụng công cụ kiểm thử tự động ứng dụng Web với thư viện Selenium WebDriver.
Trong chương 3, luận văn sẽ khám phá các phương pháp và giải pháp cho công cụ kiểm thử tự động ứng dụng web mà không cần lập trình Đầu tiên, sẽ có phần giới thiệu về ý tưởng sử dụng file Excel làm đầu vào và cách mô hình hóa các hành động (Action) Tiếp theo, luận văn sẽ cung cấp giải thích chi tiết về cấu hình đầu vào của từng sheet Excel và mối liên hệ dữ liệu giữa các sheet.
Trong chương 4, luận văn sẽ giới thiệu công nghệ Selenium WebDriver, cùng với kiến trúc phần mềm kiểm thử tự động, bao gồm thiết kế chi tiết và quy trình xây dựng công cụ Bài viết sẽ kèm theo hình ảnh minh họa cho từng bước trong quá trình sử dụng công cụ này.
Trong chương 5, luận văn sẽ trình bày về việc áp dụng công cụ vào dự án thực tế thông qua việc kiểm thử dựa trên bộ dữ liệu cố định Hai kiểu kiểm thử viên được sử dụng là kiểm thử viên có trình độ lập trình tốt và kiểm thử viên không có khả năng lập trình Cuối cùng, luận văn sẽ đánh giá ưu nhược điểm của các hình thức kiểm thử dựa trên kết quả thu được từ dự án thực tế.
Trong chương 6, luận văn sẽ tổng kết những thành tựu và hạn chế trong phần "Kết luận" Tiếp theo, mục "Hướng phát triển" sẽ đề xuất những hướng đi tương lai nhằm hoàn thiện đề tài nghiên cứu.
2.1 Tổng quan về kiểm thử phần mềm
2.1.1 Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi chương trình nhằm phát hiện lỗi và đảm bảo sản phẩm đáp ứng đầy đủ các tiêu chí của khách hàng Ngoài ra, kiểm thử phần mềm cung cấp cái nhìn độc lập về chất lượng, giúp đánh giá và nhận diện các rủi ro liên quan đến việc thực thi phần mềm.
2.1.2 Các nguyên tắc cơ bản của kiểm thử phần mềm
Nguyên tắc 1: Kiểm thử luôn có lỗi
Không thể khẳng định một phần mềm hoàn toàn không có lỗi, mà chỉ có thể chỉ ra những lỗi hiện có Ngay cả trong điều kiện kiểm thử nghiêm ngặt nhất, khả năng tồn tại lỗi vẫn luôn hiện hữu Vì vậy, nhiệm vụ quan trọng là phát hiện và khắc phục càng nhiều lỗi càng tốt.
Nguyên tắc 2: Kiểm thử toàn bộ là không thể
Trong hầu hết các trường hợp, kiểm thử không thể bao phủ toàn bộ kịch bản xảy ra, vì vậy chúng ta nên tập trung vào những tiêu chí quan trọng với rủi ro cao hơn Để đảm bảo sản phẩm đến tay khách hàng với rủi ro thấp nhất, việc lên kế hoạch và thiết kế các kịch bản kiểm thử với độ phủ cao là rất cần thiết.
Nguyên tắc 3: Kiểm thử càng sớm càng tốt
Kiểm thử phần mềm sớm trong quy trình phát triển giúp phát hiện lỗi hiệu quả hơn Việc phát hiện lỗi sớm không chỉ tăng khả năng tìm ra vấn đề mà còn giảm chi phí và thời gian sửa chữa.
Nguyên tắc 4: Sự tập trung của lỗi
Xác suất lỗi thường tập trung ở các module và thành phần chính của hệ thống Nhận thức được điều này giúp chúng ta định hướng tìm kiếm lỗi tại những khu vực cụ thể, từ đó nâng cao hiệu quả cho quá trình kiểm thử.
Nguyên tắc 5: Nghịch lý thuốc trừ sâu
Cơ sở lý thuyết
Tổng quan về kiểm thử phần mềm
2.1.1 Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi chương trình nhằm phát hiện lỗi và đảm bảo sản phẩm đáp ứng đúng tiêu chí của khách hàng Ngoài ra, kiểm thử phần mềm cung cấp cái nhìn độc lập, giúp đánh giá và nhận diện rõ ràng các rủi ro liên quan đến việc thực thi phần mềm.
2.1.2 Các nguyên tắc cơ bản của kiểm thử phần mềm
Nguyên tắc 1: Kiểm thử luôn có lỗi
Không thể chứng minh rằng một phần mềm hoàn toàn không có lỗi; chỉ có thể chỉ ra rằng phần mềm đang gặp lỗi Ngay cả trong những điều kiện kiểm thử nghiêm ngặt nhất, xác suất tồn tại lỗi vẫn luôn hiện hữu Vì vậy, nhiệm vụ chính là phát hiện và khắc phục càng nhiều lỗi càng tốt.
Nguyên tắc 2: Kiểm thử toàn bộ là không thể
Trong hầu hết các trường hợp, kiểm thử không thể bao phủ hết tất cả các kịch bản xảy ra Vì vậy, thay vì kiểm thử toàn bộ, chúng ta nên tập trung vào những tiêu chí quan trọng với khả năng rủi ro cao hơn Điều này được thực hiện thông qua việc lập kế hoạch và thiết kế các kịch bản kiểm thử nhằm đạt được độ phủ cao nhất, đảm bảo rằng rủi ro khi sản phẩm được giao đến khách hàng là thấp nhất.
Nguyên tắc 3: Kiểm thử càng sớm càng tốt
Kiểm thử phần mềm sớm trong quy trình phát triển giúp phát hiện lỗi hiệu quả hơn Việc phát hiện lỗi sớm không chỉ tiết kiệm thời gian mà còn giảm chi phí sửa chữa.
Nguyên tắc 4: Sự tập trung của lỗi
Xác suất lỗi thường tập trung vào các module và component chính của hệ thống Nhận thức được điều này giúp chúng ta xác định khu vực cần tìm kiếm lỗi, từ đó nâng cao hiệu quả cho quá trình kiểm thử.
Nguyên tắc 5: Nghịch lý thuốc trừ sâu
Chương 2 Cơ sở lý thuyế t
Việc sử dụng testcase liên tục có thể làm giảm khả năng phát hiện lỗi mới Do đó, cần thường xuyên kiểm tra và điều chỉnh các test case để đảm bảo hiệu quả của chúng không bị giảm sút qua nhiều lần thực hiện.
Nguyên tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh
Các ngữ cảnh khác nhau yêu cầu các phương pháp kiểm thử khác nhau Việc áp dụng chiến lược kiểm thử ứng dụng web cho kiểm thử ứng dụng di động là một sai lầm.
Nguyên tắc 7: Không có lỗi – sai lầm
Kiểm thử không phát sinh lỗi không đồng nghĩa với việc sản phẩm đã sẵn sàng ra mắt Một số bộ kiểm thử chỉ nhằm xác nhận chức năng hoạt động đúng theo yêu cầu, không phải để phát hiện lỗi mới.
2.1.3 Quy trình kiểm thử phần mềm
Bước 1: Lập kế hoạch kiểm thử
Lập kế hoạch kiểm thử là nhiệm vụ chính của Người Quản lý kiểm thử, bao gồm việc xác định phạm vi, chiến lược kiểm thử, nhận diện rủi ro và yếu tố bất ngờ, cũng như xây dựng lịch trình và môi trường kiểm thử Để đảm bảo hiệu quả, quá trình kiểm thử cần được kiểm soát chặt chẽ thông qua việc so sánh liên tục giữa tiến độ thực tế và kế hoạch đã đề ra.
Từđó các sai lệch so với kế hoạch sẽ được cập nhật thường xuyên, phát hiện được rủi ro từ sớm.
Bước 2: Thiết kế các trường hợp kiểm thử
Thiết kế kiểm thử là quá trình mà các Người phân tích kiểm thử hoặc Người thiết kế kiểm thử xác định các test case dựa trên kịch bản người dùng và các yêu cầu liên quan Việc này được thực hiện dựa trên các yêu cầu chức năng và phi chức năng để đảm bảo chất lượng kiểm thử Các test case cần phải bao phủ tất cả các yêu cầu trong chiến lược kiểm thử Đối với kiểm thử tự động, các Test Designer sẽ xây dựng các kịch bản dựa trên các test case đã định nghĩa.
Bước 3: Thực hiện kiểm thử
Trong giai đoạn này, việc thiết lập và khởi động môi trường kiểm thử là rất quan trọng Điều này đảm bảo rằng tất cả các thành phần liên quan như phần cứng, phần mềm, máy chủ, mạng và dữ liệu đã được cài đặt và sẵn sàng cho quá trình kiểm thử chính thức.
Tiếp đó các test case sẽ được thực thi theo thứ tự được định sẵn bao gồm các dữ liệu đầu vào cần thiết.
Bước 4: Đánh giá kết quả kiểm thử
Hoạt động đánh giá kiểm tra dựa trên các mục tiêu xác định cần được thực hiện cho từng mức độ test Việc đánh giá tiêu chí hoàn thành bao gồm kiểm tra các báo cáo kiểm thử theo các tiêu chí đã quy định trong kế hoạch kiểm tra Đồng thời, cần xem xét xem liệu có cần thực hiện thêm kiểm thử hay không, cũng như đánh giá xem các tiêu chuẩn hoàn thành có cần thay đổi Cuối cùng, viết báo cáo tóm tắt kiểm thử cho các bên liên quan là nhiệm vụ quan trọng.
Bước5: Đánh giá quá trình kiểm thử
Hoạt động kết thúc kiểm thử bao gồm việc xem xét và đánh giá kết quả kiểm thử lỗi, thống kê số lượng lỗi phát sinh Trong quá trình phân tích kết quả, cần so sánh kết quả thực tế với kết quả mong đợi, đồng thời gửi yêu cầu sửa chữa đến các cá nhân có trách nhiệm trong dự án và lưu trữ thông tin để phục vụ cho việc kiểm tra sau này.
2.1.4 Các loại kiểm thử phần mềm
Có 4 loại kiểm thử là kiểm thử chức năng, kiểm thử phi chức năng, kiểm thử cấu trúc, kiểm thử liên quan đến sự thay đổi.
Kiểm thử chức năng (Functionality Testing) là một phương pháp kiểm thử hộp đen, trong đó các test case được xây dựng dựa trên đặc tả của ứng dụng phần mềm hoặc thành phần cần kiểm tra Quá trình này bao gồm việc nhập các giá trị đầu vào và xác minh kết quả đầu ra, trong khi không chú trọng đến cấu trúc bên trong của ứng dụng.
Kiểm thử phi chức năng là một loại kiểm thử phần mềm nhằm đánh giá các khía cạnh phi chức năng như hiệu suất, khả năng sử dụng và độ tin cậy của ứng dụng Loại kiểm thử này được thiết kế để xác định sự sẵn sàng của hệ thống dựa trên các tham số không thuộc về chức năng, điều mà kiểm thử chức năng không thể giải quyết.
Kiểm thử tự động
2.2.1 Khái niệm kiểm thử tự động
Kiểm thử tự động là quá trình sử dụng phần mềm để tự động hóa việc thực hiện các bài kiểm tra, giúp so sánh kết quả đầu ra thực tế với kế hoạch đã định Người kiểm thử tự động sẽ viết các tập lệnh nhằm thực hiện các nhiệm vụ lặp đi lặp lại trong quy trình thử nghiệm chính thức, cũng như các kiểm thử bổ sung mà việc thực hiện thủ công gặp khó khăn.
2.2.2 So sánh kiểm thử tự động và kiểm thử thủ công
Dưới đây là bảng so sánh giữa kiểm thử tự động và kiểm thử thủ công:
Kiểm thử thủ công Kiểm thử tự động
Kịch bản kiểm thử được thực thi bởi kiểm thử viên, tái hiện thủ công từng bước theo kịch bản
Kịch bản kiểm thử được thực hiện bởi các công cụ tự động
Kiểm thử phần mềm tự động hóa có thời gian thực hiện nhanh hơn đáng kể so với kiểm thử thủ công, nhưng độ tin cậy có thể thấp do sự nhàm chán cho kiểm thử viên và rủi ro mắc lỗi Tuy nhiên, việc triển khai kịch bản bằng công cụ giúp giảm thiểu rủi ro này Kinh nghiệm của kiểm thử viên cũng ảnh hưởng đến thời gian thực hiện.
Đầu tư vào nguồn nhân lực là cần thiết, tuy nhiên, việc giảm bớt nhân lực trong quá trình kiểm thử có thể tiết kiệm chi phí Điều này đòi hỏi thời gian để đào tạo các kiểm thử viên sử dụng công cụ hiệu quả.
Kiểm thử ngẫu nhiên là phương pháp thích hợp cho các trường hợp chỉ cần chạy vài lần, trong khi các trường hợp kiểm thử liên tục và lặp đi lặp lại trong thời gian dài yêu cầu một cách tiếp cận khác.
Bảng 1 So sánh kiểm thử thủ công và kiểm thử tự động
Kết quả so sánh trong Bảng 1 cho thấy kiểm thử tự động mang lại nhiều ưu điểm vượt trội so với kiểm thử thủ công Tuy nhiên, việc triển khai kiểm thử tự động cần được người sử dụng cân nhắc một cách hợp lý.
Kiểm thử tự động là giải pháp lý tưởng cho các kịch bản kiểm thử lặp đi lặp lại, đặc biệt khi bộ dữ liệu đầu vào không thay đổi nhiều và cần thực hiện kiểm thử hồi quy với số lượng test case lớn trong thời gian ngắn Ngoài ra, việc kiểm thử trên nhiều môi trường khác nhau cũng trở nên dễ dàng hơn, giúp tối ưu hóa thời gian và giảm thiểu sự nhàm chán cho kiểm thử viên khi thực hiện thủ công.
Kiểm thử tự động áp dụng cho những dự án có tính ổn định, đặc điểm kĩ thuật được xác định trước.
Kiểm thử tự động không nên được áp dụng cho những loại kiểm thử không có tính hồi quy và không thường xuyên lặp lại Bởi vì kiểm thử tự động không thể thực hiện hoàn toàn trong mọi tình huống, đặc biệt là khi đặc điểm kỹ thuật thay đổi liên tục, nên trong nhiều trường hợp, việc tự động hóa không mang lại hiệu quả như mong đợi.
2.2.3 Quy trình kiểm thử tự động
Quy trình kiểm thử tự động gồm các bước sau:
Bước 1: Lựa chọn công cụ kiểm thử tự động thích hợp
Khi lựa chọn công cụ kiểm thử tự động, các công ty cần cân nhắc kỹ lưỡng vì mỗi công cụ có những tính năng và chi phí khác nhau Việc chọn lựa công cụ phù hợp không chỉ giúp tiết kiệm thời gian và nhân lực cho quá trình kiểm thử mà còn tối ưu hóa chi phí cho doanh nghiệp Trên thị trường hiện có nhiều công cụ kiểm thử tự động, vì vậy cần xác định những công cụ tốt nhất cho ứng dụng hoặc dự án của mình Những yếu tố quan trọng cần xem xét khi lựa chọn công cụ chính xác bao gồm tính năng, chi phí và khả năng tích hợp với quy trình làm việc hiện tại.
Khi lựa chọn công cụ kiểm thử tự động, cần đảm bảo rằng nó phù hợp với ngân sách cho phép Mặc dù có nhiều phần mềm với tính năng đa dạng, nhưng chi phí bản quyền thường khá cao Do đó, việc chọn lựa công cụ phải cân nhắc giữa khả năng đáp ứng nhu cầu và giới hạn ngân sách của dự án là rất quan trọng.
Công cụ kiểm thử cần phải tương thích với công nghệ của ứng dụng hoặc dự án đang triển khai Nếu ứng dụng chạy trên nền tảng di động, công cụ phải hỗ trợ kiểm thử các chức năng trên thiết bị di động Ngược lại, nếu là môi trường web, công cụ cần có khả năng tương tác với các phần tử web Ví dụ, Selenium là lựa chọn phù hợp cho ứng dụng web, trong khi Robotium được sử dụng cho ứng dụng Android.
MS Coded UI cho ứng dụng Windows.
Để đạt hiệu quả trong công việc, chúng ta cần tuyển dụng nhân sự có kỹ năng phù hợp, những người có khả năng nhanh chóng làm quen với công cụ mới Ví dụ, nếu chúng ta thuê một kiến trúc sư kiểm thử có kinh nghiệm với QTP nhưng lại sử dụng MS Coded UI, thì công cụ chỉ giống như một chiếc xe tốt mà không có tài xế giỏi để điều khiển.
• Công cụ phải một cơ chế báo cáo tốt để hiển thị kết quả cho các bên liên quan sau mỗi lần thực thi.
Bước 2: Xác định phạm vi kiểm thử tự động
Cần xác định rõ các module, chức năng nằm trong phạm vi kiểm thử tự động
Không phải tất cả các hoạt động kiểm thử đều có thể tự động hóa, và một số tính năng vẫn chưa được công cụ kiểm thử tự động hỗ trợ đầy đủ Để lựa chọn ứng dụng phù hợp cho việc tự động hóa kiểm thử, cần xem xét nhiều yếu tố khác nhau Ứng dụng cần đáp ứng các tiêu chí nhất định để việc tự động hóa kiểm thử trở nên hiệu quả.
Ứng dụng không nên được phát hành trong giai đoạn đầu của chu trình phát triển; thay vào đó, nó cần phải có đầy đủ hoặc ít nhất một số chức năng đã ổn định và được kiểm thử kỹ lưỡng bởi các kỹ sư kiểm thử thủ công.
• Giao diện của ứng dụng cần ổn định (Giao diện không được thay đổi một cách thường xuyên).
• Kịch bản kiểm thử thủ công đã được viết ra.
Mục tiêu chính của kiểm thử tự động là đảm bảo rằng nếu một phiên bản ứng dụng không có lỗi, thì các phiên bản tiếp theo cũng sẽ không gặp phải lỗi Do đó, kỹ sư kiểm thử thủ công không nên lãng phí thời gian vào việc tìm kiếm các lỗi hồi quy, mà thay vào đó, những vấn đề này nên được phát hiện thông qua kiểm thử tự động.
Bước 3 trong quy trình kiểm thử là lập kế hoạch kiểm thử, nơi kiểm thử viên phân tích yêu cầu dựa trên các tài liệu liên quan đến nghiệp vụ hệ thống, báo cáo tính khả thi và phân tích rủi ro Sau đó, họ sẽ tạo ra các tài liệu chi tiết cho kế hoạch kiểm thử, bao gồm bản kế hoạch kiểm thử, ước lượng kiểm thử và lịch trình kiểm thử.
Bước 4: Thiết kế kịch bản kiểm thử
Các công cụ kiểm thử tự động
Hiện nay, thị trường có nhiều công cụ và framework hỗ trợ kiểm thử tự động, đáp ứng đa dạng yêu cầu dự án Các công cụ này có thể được phân loại theo nhiều tiêu chí, trong đó chi phí là một yếu tố quan trọng, chia thành hai nhóm chính: công cụ mã nguồn mở và công cụ tính phí Selenium là một trong những công cụ mã nguồn mở nổi bật nhất trong lĩnh vực này.
Các công cụ kiểm thử phần mềm có thể được chia thành hai nhóm chính dựa trên chức năng của chúng Nhóm đầu tiên là những công cụ không yêu cầu người dùng có kiến thức lập trình, ví dụ như Selenium IDE, QTP và RANOREX Nhóm thứ hai bao gồm các công cụ hỗ trợ viết kịch bản kiểm thử chuyên sâu, đòi hỏi người kiểm thử cần có khả năng lập trình tốt, như Selenium WebDriver.
Driver, TestComplete) Chúng ta cùng điểm qua các công cụ phổ biến nhất hiện nay
Selenium là công cụ kiểm thử mã nguồn mở chuyên dùng cho kiểm thử tự động ứng dụng Web, bao gồm 4 công cụ chính: Selenium IDE, Selenium WebDriver, Selenium RC và Selenium Grid Bài viết sẽ tóm tắt công dụng, ưu và nhược điểm của từng loại công cụ Đặc biệt, Selenium WebDriver, là framework chính được sử dụng trong luận văn, sẽ được mô tả chi tiết trong Chương 4.
Selenium IDE là môi trường phát triển tích hợp đơn giản và dễ học nhất trong bộ công cụ Selenium, hoạt động dưới dạng tiện ích (plug-in) cho trình duyệt Firefox và tiện ích mở rộng (extension) cho Chrome.
Selenium IDE hoạt động theo cơ chế Ghi và chạy lại (Record and Replay), cho phép kiểm thử viên dễ dàng ghi lại các bước trong kịch bản kiểm thử và tự động tái hiện chúng khi chạy thử Ưu điểm nổi bật của Selenium IDE là dễ cài đặt và không yêu cầu kiến thức lập trình sâu, chỉ cần hiểu biết về HTML và DOM Tuy nhiên, nó cũng có nhược điểm như không hỗ trợ các biểu thức điều kiện và vòng lặp, gây khó khăn trong việc xử lý các workflow phức tạp Hơn nữa, giao diện của Selenium IDE hiển thị dữ liệu kiểm thử chung cho các bước, làm cho việc quản lý test case tương tự trở nên khó khăn Khi cần chỉnh sửa dữ liệu, kiểm thử viên phải thao tác trên từng test case một, gây bất tiện Cuối cùng, Selenium IDE thiếu khả năng cấu hình linh động trong Test suite, như khả năng bỏ qua những test case nhất định hoặc dừng lại khi test case bị Fail.
Selenium RC là công cụ kiểm thử web tự động đầu tiên cho phép người dùng sử dụng nhiều ngôn ngữ lập trình Mặc dù Selenium RC ít được sử dụng do WebDriver cung cấp nhiều tính năng mạnh mẽ hơn, người dùng vẫn có thể tiếp tục phát triển các script với RC.
Selenium RC hoạt động theo cơ chế server-client, bao gồm 2 phần chính:
Selenium Server có khả năng khởi động và tắt các trình duyệt, đồng thời diễn dịch và thực thi các lệnh Selenium Nó cũng hoạt động như một proxy HTTP, chặn và xác minh các tin nhắn HTTP giữa trình duyệt và ứng dụng kiểm thử.
• Client libraries: cung cấp một giao diện giữa mỗi một ngôn ngữ lập trình (Java, C#, Perl, Python, PHP) với Selenium-RC Server Ví dụ: Eclipse, IntelliJ IDEA, …
Selenium RC hoạt động bằng cách cho phép thư viện client giao tiếp với Selenium RC Server thông qua các lệnh Selenium Command Server sau đó truyền các lệnh này đến trình duyệt bằng cách sử dụng Javascript từ Selenium-Core Một trong những ưu điểm nổi bật của Selenium RC là khả năng hỗ trợ nhiều trình duyệt và hệ điều hành khác nhau Bên cạnh đó, việc hỗ trợ nhiều ngôn ngữ lập trình giúp Selenium RC thực hiện các hoạt động kiểm thử lặp lại và phức tạp một cách hiệu quả Hơn nữa, tốc độ thực thi của Selenium RC cũng nhanh hơn so với Selenium IDE.
Nhược điểm của Selenium RC là yêu cầu người dùng phải có kiến thức lập trình, và công cụ này cần một RC Server để thực hiện chương trình.
Selenium WebDriver là phiên bản nâng cấp của Selenium RC, cho phép gửi lệnh trực tiếp tới trình duyệt và nhận kết quả mà không cần Selenium Server, giúp đơn giản hóa quá trình cài đặt Tương tự như Selenium RC, WebDriver hỗ trợ người dùng sử dụng nhiều ngôn ngữ lập trình để tạo ra các kịch bản kiểm thử phức tạp với nhiều logic và điều kiện Selenium WebDriver cho phép viết kịch bản kiểm thử bằng nhiều ngôn ngữ, bao gồm Java.
Selenium WebDriver is compatible with multiple operating systems, including Windows, Linux, and Macintosh, and supports major browsers such as Mozilla Firefox, Google Chrome, Internet Explorer, Opera, and Safari Additionally, it is commonly used with programming languages like C#, Perl, Python, Ruby, and PHP.
Nhược điểm lớn nhất của Selenium WebDriver là yêu cầu người dùng phải có kiến thức lập trình vững để tự thiết kế các kịch bản kiểm thử Hơn nữa, WebDriver không hỗ trợ các trình duyệt mới một cách tự động; do đó, nếu cần cập nhật, người dùng phải tự thiết lập driver cho từng trình duyệt tương ứng.
Selenium Grid là một công cụ hỗ trợ Selenium RC, cho phép thực hiện kiểm thử song song trên nhiều máy và trình duyệt khác nhau Việc chạy nhiều kiểm thử cùng lúc giúp tiết kiệm thời gian và đảm bảo kiểm thử được thực hiện đồng thời trong nhiều môi trường khác nhau.
QTP [2] là một phần mềm thương mại và phải bỏ phí để mua bản quyền
QTP, với ngôn ngữ kiểm thử VBScript, có khả năng kiểm tra cả ứng dụng web và desktop, nhờ vào việc tích hợp Object Repository (OR) OR là nơi lưu trữ các đối tượng và thuộc tính tương ứng của một trang web, giúp QTP nhận diện và thực hiện các hành động trong quá trình kiểm thử Mỗi đối tượng bao gồm một phần tử web và các thuộc tính mô tả như text, type, và hành động liên quan Ban đầu, OR sẽ rỗng, nhưng khi QTP ghi lại thao tác của người dùng, nó sẽ tự động thêm các đối tượng và thuộc tính tương ứng vào OR.
Từ đó kịch bản kiểm thử (test script) khi được chạy lại sẽ lấy những thành phần trong OR để tái hiện kịch bản.
OR đóng vai trò quan trọng trong việc kết nối kịch bản kiểm thử với ứng dụng web cần kiểm tra Điều này đặc biệt hữu ích trong tình huống chuyển giao công việc, khi người mới tiếp nhận chưa có thời gian hoặc chưa hiểu rõ kịch bản Nhờ vào OR, họ vẫn có thể thực hiện kiểm thử phần mềm đúng yêu cầu chỉ bằng cách đọc cây thư mục.
Hướng tiệp cận và giải pháp
Ý tưởng giải pháp
Như trình bày trong Mục 2.2.3, quy trình kiểm thử tự động sẽ theo thứ tự như sau:
1 Kiểm thử viên chuẩn bị bản kế hoạch kiểm thử, viết kịch bản kiểm thử thủ công trong đó mô tả chi tiết các trường hợp kiểm thử (test case), dữ liệu kiểm thử và đầu ra mong muốn trong file excel.
2 Kiểm thử viên dựa trên kịch bản thủ công sẽ viết kịch bản kiểm thử tự động thông qua lập trình các câu lệnh để tương tác với các phần tử Web Đối với các phần mềm có tính năng Ghi và chạy lại như Selenium IDE thì kiểm thử viên sẽ tái hiện thủ công lần đầu kịch bản kiểm thử xong đó phần mềm sẽ ghi lại các bước thao tác.
3 Kiểm thử viên đưa kịch bản kiểm thử tự động vào để phần mềm kiểm thử chạy tự động và sau đó in ra kết quả kiểm thử Từ đó kiểm thử viên có thể so sánh kết quả kiểm thử với kết quả mong đợi ban đầu và lập báo cáo về lần kiểm thử đó.
Các framework và công cụ kiểm thử tự động ứng dụng web như Selenium, QTP, RANOREX và TestComplete đều có những nhược điểm riêng Đầu tiên, các công cụ yêu cầu lập trình câu lệnh có thể gây khó khăn cho những kiểm thử viên không có kiến thức lập trình vững Ngược lại, các công cụ ghi và chạy lại không yêu cầu lập trình, nhưng lại gặp phải vấn đề về quản lý các trường hợp kiểm thử và bộ dữ liệu kiểm thử, khiến cho tính linh hoạt bị hạn chế.
Luận văn này đề xuất một phương pháp kiểm thử mới, trong đó kiểm thử viên không cần viết mã kiểm thử mà chỉ cần định nghĩa kịch bản kiểm thử và cung cấp dữ liệu kiểm thử qua file Excel File Excel không chỉ là công cụ để ghi chép kịch bản kiểm thử thủ công mà còn cho phép mô hình hóa dữ liệu liên kết, biến nó thành kịch bản kiểm thử tự động Công cụ kiểm thử sẽ đọc và phân tích file Excel, thực thi theo kịch bản đã định nghĩa, và xuất báo cáo kết quả kiểm thử dưới định dạng HTML và Excel, giúp kiểm thử viên tiết kiệm thời gian.
Quá trình kiểm thử phần mềm bao gồm hai bước chính: viết kịch bản kiểm thử tự động và thực hiện từng bước trong kịch bản kiểm thử thủ công Đặc biệt, thao tác với dữ liệu trên file Excel cũng là một phần quan trọng trong quy trình này.
Chương 3 Hướng tiệp cận và giải pháp là công cụ quen thuộc với các kiểm thử viên thủ công, thì việc huấn luyện sử dụng công cụ cũng rất nhanh chóng
Công cụ kiểm thử website tự động dựa trên Selenium được phát triển với JavaCore và JavaSwing, trong đó JavaSwing tạo ra giao diện đồ họa thân thiện cho người dùng, còn JavaCore đảm nhiệm việc xử lý logic bên trong công cụ.
Mô hình hoạt động của công cụ kiểm thử tự động không cần lập trình
Hình 1 dưới đây mô tả về mô hình hoạt động trong công cụ kiểm thử tự động của luận văn.
Hình 1 Sơ đồ mô tả mô hình hoạt động của công cụ luận văn
Mô hình hoạt động gồm 3 phần chính: (1) phần cấu hình dữ liệu đầu vào, (2) phần thực thi và (3) là phần xuất báo cáo
Phần cấu hình dữ liệu đầu vào trong bài viết bao gồm thông tin kiểm thử, các trường hợp kiểm thử và bộ dữ liệu kiểm thử, được lưu trữ trong file Excel Luận văn thiết lập cấu trúc các trường và cơ chế liên kết dữ liệu giữa các trường trong Sheet trường hợp kiểm thử và dữ liệu kiểm thử, giúp công cụ tự động tái hiện từng bước trong kịch bản mà kiểm thử viên nhập vào Nhờ đó, kiểm thử viên không cần lập trình các câu lệnh điều khiển tự động hoặc phải ghi lại kịch bản một cách thủ công.
Phần thực thi trong kịch bản kiểm thử có nhiệm vụ đọc từng bước và thực hiện các hành động đã định sẵn với bộ dữ liệu kiểm thử tương ứng Luận văn hiện tại sử dụng 26 Action để điều khiển các phần tử web theo yêu cầu Mỗi action là tập lệnh được lập trình dựa trên thư viện Selenium WebDriver, và phạm vi của luận văn chỉ tập trung vào kiểm thử ứng dụng web, do đó các câu lệnh được cấu hình để tương tác với các phần tử web Trong tương lai, mô hình dữ liệu từ file excel có thể áp dụng cho kiểm thử trên các nền tảng khác như di động, chỉ cần thay thế Selenium WebDriver bằng các thư viện hỗ trợ điều khiển phần tử trên ứng dụng di động.
Cuối cùng, phần xuất báo cáo cung cấp hai tùy chọn là xuất file dưới định dạng Excel và HTML Bên cạnh đó, công cụ trong luận văn còn cho phép hiển thị kết quả kiểm thử dưới dạng HTML ngay trên giao diện sau khi quá trình kiểm thử hoàn tất.
Mô tả cấu hình dữ liệu đầu vào
Cấu trúc file excel đầu vào gồm 4 sheet là (1) Test Scenario, (2) Test Data,
Bài viết mô tả quy trình kiểm thử bao gồm các bước và kết quả kiểm thử Sheet Test Scenario cung cấp thông tin về chức năng cần kiểm thử, môi trường và phiên bản phát hành Sheet Test Data chứa dữ liệu kiểm thử cần thiết, trong khi Sheet Test Steps liệt kê các bước kiểm thử cụ thể Kết quả kiểm thử được tổng hợp trong Sheet Test Result, bao gồm tổng số test case, số lượng test case Pass, Fail, Skip, cùng với tỷ lệ phần trăm tương ứng Để tự động điền kết quả kiểm thử, Sheet TongHop chỉ cần tạo header theo mẫu có sẵn Nội dung chi tiết và cách kết nối giữa các sheet sẽ được trình bày ở phần tiếp theo.
Có thể mở rộng các định dạng file khác trong tương lai, nhưng Excel hoặc Google Spreadsheet là công cụ hoàn hảo.
3.3.1 Ví dụ một chức năng kiểm thử
Trước khi mô tả chi tiết từng mục trong phần cấu hình, bài viết sẽ cung cấp ví dụ về dữ liệu đầu vào trong file Excel cho chức năng kiểm thử đơn giản: chức năng đăng nhập Nội dung của sheet Test Scenario được trình bày trong Bảng 2.
Test scenario Environment Release version
Bảng 2 Cấu hình sheet Test Scenario
Tiếp đến là sheet Test Data chứa các dữ liệu kiểm thử ở Bảng 3
User or Password is not valid
User or Password is not valid
User or Password is not valid
Guru99 Bank Manage r HomeP age
Guru99 Bank New Custome r Entry Page
Bảng 3 Dữ liệu kiểm thử chức năng đăng nhập
Mỗi dòng trong bài kiểm thử đại diện cho một bộ dữ liệu cụ thể cho một test case Hai cột đầu tiên là cố định, trong khi các cột tiếp theo chứa các loại dữ liệu khác nhau được sử dụng trong kịch bản kiểm thử Số lượng cột và loại dữ liệu có thể thay đổi tùy theo yêu cầu của từng kịch bản.
Trong bài viết này, luận văn trình bày 5 test case, bao gồm 2 test case kiểm thử dữ liệu dạng Illegal, 2 test case kiểm thử dữ liệu dạng Invalid và 1 test case kiểm thử dữ liệu dạng Valid Ngoài ra, còn có 1 test case với trường Skip được đặt là Y để kiểm thử chức năng bỏ qua test case trong ứng dụng.
Bộ dữ liệu Illegal được sử dụng để kiểm tra các test case với dữ liệu đầu vào không hợp lệ Một trong các test case có trường UserID để trống, trong khi test case khác có nội dung của AlertMessage khác với thông báo mặc định của hệ thống khi người dùng đăng nhập không thành công.
Bộ dữ liệu Invalid được sử dụng để kiểm tra các test case với dữ liệu đầu vào hợp lệ, nhưng hệ thống không thực hiện thành công chức năng do dữ liệu không chính xác Luận văn này khai thác thông tin UserId và Password không tồn tại trong hệ thống, yêu cầu AlertMessage hiển thị đúng như thông báo của hệ thống khi người dùng đăng nhập không thành công.
Bộ dữ liệu Valid được sử dụng để kiểm tra thông tin phản hồi của hệ thống khi dữ liệu đầu vào chính xác Trong trường hợp này, người dùng cần cung cấp UserID và Password đúng để chương trình có thể truy cập vào trang chủ với tiêu đề "Guru99 Bank Manager HomePage".
Sheet tiếp theo trong Bảng 4 mô tả chi tiết các bước kiểm thử trong test case.
Khởi tạo trình duyệt chro me openBro wser chrome Y
9 demo navigate http://www.d emo.guru99.c om/v4/
Pass word inputTex t name passwor d
Kiểm tra vẫn ở trang login checkTit lePage
Kiểm tra đang ở trang mana ger checkTit lePage
//a[cont ains(text (),'New Custom er')]
Kiểm tra đang ở trang new custo mer checkTit lePage
Thoát trình duyệt quitBro wser Y
Bảng 4 Các bước kiểm thử chức năng đăng nhập
Cuối cùng là kết quả kiểm thử được lưu trong Sheet Test Result mô tả trong Bảng 5
Total Pass Fail Skip %Pass %Fail %Skip
Bảng 5 Kết quả kiểm thử chức năng đăng nhập
Các bước trong kịch bản kiểm thử thường phức tạp hơn so với các chức năng đơn giản Vì vậy, kiểm thử viên cần có tài liệu mô tả để hỗ trợ công việc Tài liệu này đặc biệt hữu ích khi kiểm thử viên tiếp nhận dự án từ đồng nghiệp đã nghỉ việc hoặc trong thời gian nghỉ phép Dưới đây là mô tả chi tiết và chức năng của từng sheet cấu hình đầu vào và đầu ra cho công cụ được phát triển trong luận văn.
3.3.2 Cấu hình Sheet Test Scenario
The Sheet Test Scenario features a pre-defined header template that includes three fields: UseCaseName, ENV, and ReleaseVersion Detailed information for each field in the Test Scenario sheet is outlined in Table 6.
Test scenario Tên của của chức năng cần kiểm thử
Environment Môi trường kiểm thử
ReleaseVersion Phiên bản release của dự án
Bảng 6 Thông tin chi tiết sheet Test Scenario
3.3.3 Cấu hình Sheet Test Data
Test data sẽ bao gồm nhiều bộ dữ liệu kiểm thử cho 1 test case Test case
Mô tả dữ liệu đầu vào, hành động hoặc sự kiện cùng với kết quả mong muốn là cách kiểm tra tính năng của ứng dụng phần mềm, nhằm đảm bảo rằng mọi chức năng hoạt động đúng như dự kiến.
Mỗi test case được định nghĩa bởi bốn trường thông tin chính: (1) Định danh test case, (2) Loại test case với các lựa chọn test step phù hợp, (3) Tùy chọn Skip cho phép kiểm thử viên quyết định có chạy test case trong lần kiểm thử này hay không, và (4) Dữ liệu đầu vào cùng kết quả mong muốn cho kịch bản kiểm thử.
Sheet Test Data gồm các trường TestCaseID, Type of Test Data, Skip và trường Data (không giới hạn số trường Data)
Hình 2 Cấu hình sheet Test Data
Thông tin từng trường được mô tả chi tiết ở Bảng 7
TestCaseID Định nghĩa id của test case
Trong bộ test case, có ba loại chính cần kiểm thử: Illegal, Invalid và Valid Mỗi loại test case này có mục đích kiểm thử riêng, được mô tả chi tiết trong bảng dưới đây.
Skip Gồm hai giá trị là Y hoặc N Khi không muốn run test case thì chọn Y, khi muốn run test case thì chọn N
Số lượng trường Data trong sheet Test Data phụ thuộc vào số lượng ô có định dạng {{Data}} trong trường TestData Field của sheet Test Steps Tên của các trường này tương ứng với giá trị Data; ví dụ, nếu trường TestDataField chứa {{Data1}} và {{Data2}}, thì sheet Test Data sẽ có hai trường tương ứng là Data1 và Data2.
Bảng 7 Thông tin chi tiết sheet Test Data
Trong các nghiệp vụ kiểm thử thực tế, các test case được chia thành ba loại Mục đích kiểm thử của từng loại được mô tả theoBảng 8 dưới đây.
Loại test case Mục đích
Kiểm tra thông báo được trả về từ hệ thống khi kiểm thử với bộ dữ liệu đầu vào không hợp lệ
Kiểm tra phản hồi từ trang web khi dữ liệu hợp lệ nhưng không thực hiện chức năng thành công do dữ liệu không đúng như mong muốn
Kiểm tra thông tin phản hồi hệ thống khi bộ dữ liệu đầu vào đúng như mong muốn
Bảng 8 Chi tiết các loại test case
3.3.4 Cấu hình Sheet Test Step
Trước khi định nghĩa bước kiểm tra (test step), cần hiểu rõ khái niệm phần tử web (web element) và định danh phần tử web (web element locator) Phần tử web là các thành phần độc lập trên trang như tiêu đề, nút tìm kiếm, trường nhập liệu và khu vực văn bản, được định nghĩa bằng các thẻ HTML cùng với thuộc tính và nội dung Định danh phần tử web là công cụ dùng để tìm kiếm và truy xuất các phần tử này, với nhiều loại locator như ID, name, class name, tag name, CSS Selector và Xpath Các locator như ID, name và class name thường được khuyến khích sử dụng vì tính đơn giản và ngắn gọn Trong trường hợp thiếu các thuộc tính trên, Xpath và CSS Selector sẽ hỗ trợ trong việc định vị phần tử Xpath được coi là kỹ thuật hiệu quả nhất, cho phép xác định mọi phần tử trên trang dựa vào đường dẫn XML của nó.
Test step là thao tác mà người kiểm thử thực hiện trong quá trình kiểm tra sản phẩm phần mềm Chẳng hạn, bước đầu tiên khi kiểm thử một ứng dụng web là mở trình duyệt Tiếp theo, người kiểm thử có thể thực hiện các bước như nhấp vào ô nhập liệu và điền thông tin vào đó.
