1. Trang chủ
  2. » Luận Văn - Báo Cáo

Báo cáo cuối kỳ Đề tài gui testing (aplication)

36 0 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề GUI Testing (Aplication)
Tác giả Đinh Nguyệt Quỳnh, Nguyễn Huỳnh Thái Sơn, Mai Hồ Thiên Thạch, Lê Trọng Thiện, Hồ Thị Thu Trầm, Trần Lê Thiên Trí
Người hướng dẫn GVHD: Từ Thị Xuân Hiền
Trường học Trường Đại Học Công Nghiệp Thành Phố Hồ Chí Minh
Chuyên ngành Đảm Bảo Chất Lượng Và Kiểm Thử Phần Mềm
Thể loại báo cáo
Năm xuất bản 2024
Thành phố Thành phố Hồ Chí Minh
Định dạng
Số trang 36
Dung lượng 3,19 MB

Nội dung

GUI testing là quá trình kiểm tra giao diện đồ họa người dùng GUI của một phầnmềm hoặc ứng dụng để đảm bảo nó đáp ứng các yêu cầu và hoạt động như mongmuốn.. GUI testing cũng giúp kiểm t

Trang 1

BỘ CÔNG THƯƠNG

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP THÀNH PHỐ HỒ CHÍ MINH

KHOA CÔNG NGHỆ THÔNG TIN

MÔN: ĐẢM BẢO CHẤT LƯỢNG VÀ KIỂM THỬ PHẦN MỀM

BÁO CÁO CUỐI KỲ

Đề tài: GUI testing (Aplication)

1 Đinh Nguyệt Quỳnh 20096651

2 Nguyễn Huỳnh Thái Sơn 21040531

Trang 2

1 Giới Thiệu

1.1 Khái niệm về GUI Testing

GUI là viết tắt của Giao diện đồ họa người dùng (tiếng Anh: Graphical UserInterface) Nó là một dạng giao diện người dùng cho phép bạn giao tiếp với máytính hay các thiết bị điện tử bằng chữ viết và hình ảnh thay vì chỉ là các dòng lệnhđơn thuần GUI bao gồm các thành phần như cửa sổ, biểu tượng, menu, thanhcông cụ… Mỗi thành phần có chức năng riêng và giúp người dùng thực hiện cácthao tác khác nhau

GUI testing là quá trình kiểm tra giao diện đồ họa người dùng (GUI) của một phầnmềm hoặc ứng dụng để đảm bảo nó đáp ứng các yêu cầu và hoạt động như mongmuốn

GUI testing giúp đảm bảo rằng giao diện người dùng dễ sử dụng, dễ hiểu và phùhợp với mọi đối tượng người dùng GUI testing cũng giúp kiểm tra tính tương tácgiữa các thành phần của giao diện người dùng, ví dụ như các nút, biểu tượng,menu… Đồng thời, GUI testing giúp phát hiện các lỗi trong giao diện người dùng,

ví dụ như lỗi hiển thị, lỗi chức năng…

1.2 Lợi ích của GUI so với giao diện truyền thống

- GUI cung cấp tiêu chuẩn giao diện của hệ điều hành khách hàng

- GUI rất linh hoạt nên có thể được sử dụng trong hầu hết các lĩnh vực ứngdụng

- Người dùng có thể chọn sử dụng bàn phím hoặc thiết bị chuột

- Người dùng có giao diện tự nhiên hơn với các ứng dụng: nhiều cửa sổ có thể hiểnthị đồng thời, nhờ đó khả năng hiểu của người dùng được cải thiện

- Người dùng kiểm soát: các màn hình có thể được truy cập theo trình tự mà ngườidùng mong muốn

Trang 3

Hình ảnh minh họa giao diện truyền thống

Hình ảnh minh họa GUI

Minh họa về Gui tốt và Gui chưa tốt

GUI chưa tốt

Trang 4

- Giao diện cũ kỹ không thân thiện với người dùng

- Dù nhìn đơn giản nhưng lại thiếu tính trực quan

- Các liên kết khó hiểu, không có sự tổ chức rõ ràng

- Việc tìm kiếm thông tin hoặc điều hướng giữa các danh mục không hiệu quảGUI tốt

Giao diện trực quan: Google Drive có một giao diện rất trực quan, với các

biểu tượng rõ ràng cho các loại tệp và thư mục Người dùng có thể kéo thả tệptrực tiếp vào giao diện để tải lên, hoặc nhấp vào các biểu tượng để mở, chỉnhsửa hoặc chia sẻ tệp

Trang 5

Tổ chức rõ ràng: Các tệp và thư mục trong Google Drive được tổ chức theo

cấu trúc rõ ràng, tương tự như một hệ thống tệp trên máy tính, giúp ngườidùng dễ dàng tìm thấy và quản lý tệp của mình

Thông báo trạng thái: Khi người dùng tải lên một tệp hoặc thực hiện các

thao tác như di chuyển, sao chép hoặc xóa tệp, Google Drive cung cấp phảnhồi ngay lập tức bằng cách hiển thị thanh tiến trình, thông báo trạng thái vàxác nhận khi hành động hoàn thành

Thiết kế giao diện nhất quán: Từ thanh công cụ, biểu tượng, cho đến cách bố

trí tệp và thư mục, Google Drive duy trì tính nhất quán xuyên suốt ứng dụng.Điều này giúp người dùng dễ dàng sử dụng ngay cả khi chuyển giữa các dịch

vụ của Google như Google Docs, Sheets, và Slides

Dễ dàng điều hướng: Google Drive sử dụng một cấu trúc điều hướng gọn

gàng với menu bên trái chia các mục như “My Drive” (Drive của tôi), “Sharedwith me” (Chia sẻ với tôi), “Recent” (Gần đây) và “Starred” (Được đánh dấusao) Người dùng có thể dễ dàng chuyển qua lại giữa các mục và nhanh chóngtìm thấy tệp hoặc thư mục họ cần

Tìm kiếm mạnh mẽ: Thanh tìm kiếm của Google Drive cực kỳ mạnh mẽ, cho

phép tìm kiếm theo tên tệp, loại tệp, hoặc các từ khóa liên quan bên trong tàiliệu Điều này giúp người dùng dễ dàng điều hướng và tìm kiếm tệp ngay cảkhi có hàng ngàn tệp được lưu trữ

Tương thích đa thiết bị: Google Drive hoạt động mượt mà trên nhiều nền

tảng khác nhau như web, ứng dụng di động (iOS, Android), và các ứng dụngdesktop, đảm bảo trải nghiệm nhất quán và liền mạch trên tất cả các thiết bị

Tính dễ kiểm thử: Giao diện của Google Drive có thể dễ dàng kiểm thử tự

động với các công cụ như Selenium hoặc các công cụ kiểm thử giao diện khác

Bố cục đơn giản và sự nhất quán trong cách thức hoạt động của các yếu tốgiúp dễ dàng tạo các kịch bản kiểm thử tự động cho nhiều tình huống khácnhau, như tải tệp lên, chỉnh sửa tệp, và chia sẻ

1.3 Khó khăn trong kiểm thử GUI

GUI (giao diện người dùng đồ họa) mang lại nhiều lợi ích, nhưng cũng tạo ra nhiều tháchthức khi kiểm thử Đặc điểm điều khiển sự kiện và khả năng tương tác đa dạng của GUIdẫn đến sự phức tạp không chỉ đối với lập trình viên mà cả đối với người kiểm thử

Trang 6

1 Phần mềm điều khiển sự kiện:

GUI được thiết kế dựa trên mô hình điều khiển sự kiện, nơi mỗi hành động củangười dùng (nhấp chuột, nhập liệu, kéo thả) được xử lý dưới dạng một sự kiện Sốlượng các sự kiện mà người dùng có thể khởi tạo là vô hạn, điều này gây khó khăncho việc kiểm thử đầy đủ mọi trường hợp Ví dụ, khi một người dùng nhấp chuộtvào một nút, sự kiện có thể kích hoạt một chuỗi hành động khác nhau trong ứngdụng Nếu ứng dụng không được thiết kế tốt, những sự kiện này có thể gây ra lỗikhông lường trước, ví dụ như khi một cửa sổ bật lên đột ngột và ngăn cản quytrình đang thực hiện Việc này đòi hỏi người kiểm thử phải có một bộ kiểm thử đadạng để kiểm tra từng sự kiện một cách cẩn thận, nhưng cũng rất dễ bỏ sót cáckịch bản không phổ biến

Ví dụ: Người dùng có thể nhấp vào bất kỳ đối tượng nào trong cửa sổ ứng dụng, ví dụ

như một trường văn bản hoặc một nút Nếu lập trình viên không xử lý đúng các sự kiệnkhi người dùng nhấp vào những vị trí này trong các ngữ cảnh khác nhau, ứng dụng có thểgặp lỗi

2 Nhiều sự kiện không mong muốn:

Trong môi trường GUI, nhiều sự kiện không mong muốn có thể xảy ra và gây racác vấn đề phức tạp trong kiểm thử Khi một sự kiện được kích hoạt, chẳng hạnnhư một cú nhấp chuột trên màn hình, ứng dụng có thể chuyển từ trạng thái nàysang trạng thái khác hoặc từ một chức năng này sang chức năng khác Khi mộttính năng không hoàn thành bị bỏ dở, nó có thể ảnh hưởng đến các tính năng khác.Điều này dẫn đến các đường dẫn tiềm ẩn rất lớn trong quá trình kiểm thử, làm tăng

cơ hội lập trình viên mắc lỗi Để kiểm thử hết các đường dẫn này là điều vô cùngkhó khăn

Ví dụ: Một tình huống đơn giản là khi người dùng đang nhập dữ liệu vào một biểu mẫu,

nhưng họ nhấp vào nút quay lại hoặc chuyển sang một tính năng khác mà không lưu dữliệu Lỗi có thể xảy ra nếu không có quy trình lưu tự động hoặc cơ chế cảnh báo ngườidùng về việc mất dữ liệu

3 Sự kiện không được yêu cầu:

Các sự kiện không được yêu cầu là những sự kiện xảy ra không phải do hành độngtrực tiếp của người dùng, mà có thể do hệ điều hành hoặc các phần mềm trunggian gây ra Những sự kiện này có thể phá vỡ quá trình hoạt động của ứng dụnghoặc tạo ra các ngữ cảnh kiểm thử không lường trước được Các sự kiện như thếnày rất khó kiểm soát và kiểm thử, vì chúng có thể xuất hiện bất cứ lúc nào và tạo

ra nhiều trường hợp lỗi tiềm ẩn

Ví dụ: Hãy tưởng tượng khi một ứng dụng đang xử lý một quy trình và đột nhiên hệ điều

hành hiển thị một hộp thoại yêu cầu người dùng nạp giấy vào máy in Nếu lập trình viênkhông xử lý tốt tình huống này, ứng dụng có thể bị treo hoặc dừng đột ngột, gây ra lỗikhông mong muốn

4 Lập trình hướng đối tượng:

GUI thường sử dụng mô hình lập trình hướng đối tượng (OOP), nơi các thành

Trang 7

phần giao diện như cửa sổ, nút, trường văn bản được coi là các đối tượng vớithuộc tính và phương thức riêng Việc này giúp cho GUI dễ phát triển và mở rộnghơn, nhưng cũng đồng thời tăng thêm phức tạp trong quá trình kiểm thử Cácthuộc tính của các đối tượng này, từ kích thước, màu sắc, vị trí, cho đến nội dung

và các sự kiện liên quan, đều cần được kiểm thử đầy đủ Đặc biệt là khi các đốitượng phải thay đổi trạng thái hoặc thuộc tính dựa trên đầu vào của người dùng,việc đảm bảo rằng tất cả các thuộc tính đều được quản lý đúng cách trở thành mộtthách thức lớn

Ví dụ: Một hộp kiểm (checkbox) có thể ảnh hưởng đến trạng thái của các thành phần

khác trong giao diện Nếu hộp kiểm được chọn, một trường nhập liệu có thể bị vô hiệuhóa Người kiểm thử cần kiểm tra xem hành vi này có đúng trong mọi kịch bản không, vànếu không, điều này có thể dẫn đến lỗi

Ví dụ: Khi người dùng nhập thông tin khách hàng vào một cửa sổ và sau đó tạo một đơn

đặt hàng mới cho khách hàng đó ở một cửa sổ khác, trường "ngày đặt hàng cuối cùng"trong cửa sổ đầu tiên có nên được tự động cập nhật không? Nếu không, dữ liệu có thểkhông khớp nhau và gây ra lỗi trong hệ thống

6 Miền đầu vào vô hạn:

Người dùng có thể nhập liệu theo nhiều cách khác nhau trong các trường dữ liệucủa một giao diện Ví dụ, với 7 trường dữ liệu, người dùng có thể nhập theo 5040trình tự khác nhau (7!) Số lượng trình tự nhập liệu này tăng lên nhanh chóng đốivới các màn hình phức tạp hơn Trong khi lập trình viên phải đảm bảo rằng ứngdụng hoạt động chính xác cho mọi trình tự nhập liệu, người kiểm thử phải lựachọn cẩn thận những trường hợp kiểm thử đại diện để đảm bảo tính đúng đắn của

hệ thống mà không bỏ sót lỗi

Ví dụ: Một ứng dụng có thể yêu cầu người dùng nhập thông tin cá nhân vào các trường

dữ liệu Nếu người dùng nhập sai thứ tự hoặc bỏ qua một số trường, ứng dụng phải xử lýtình huống này một cách hợp lý, ví dụ hiển thị thông báo lỗi hoặc yêu cầu nhập lại

7 Nhiều cách vào, nhiều cách ra:

Trong một ứng dụng GUI, người dùng thường có nhiều cách để thực hiện mộtchức năng hoặc truy cập một tính năng, chẳng hạn như qua phím tắt, chuột, hoặcmenu Điều này dẫn đến việc phải kiểm thử nhiều trường hợp khác nhau để đảmbảo rằng mỗi phương pháp đều hoạt động chính xác Số lượng cách vào và ra từmột chức năng khiến cho quá trình kiểm thử trở nên phức tạp hơn nhiều

Trang 8

Ví dụ: Để thoát khỏi một màn hình, người dùng có thể nhấn phím "Esc", nhấp vào nút

"Thoát" hoặc chọn tùy chọn từ menu Người kiểm thử cần đảm bảo rằng tất cả cácphương thức này hoạt động tương tự và không gây ra lỗi

8 Quản lý cửa sổ:

Môi trường GUI cho phép người dùng thực hiện các thao tác như di chuyển, thayđổi kích thước, phóng to, thu nhỏ, hoặc đóng cửa sổ Những hành động này có thểtác động đến trạng thái của ứng dụng, gây ra các vấn đề như làm mất dữ liệu hoặcngắt kết nối với cơ sở dữ liệu Người kiểm thử phải kiểm tra xem ứng dụng xử lýnhững hành động này như thế nào, đồng thời phải quyết định liệu có cần kiểm thửtất cả các thao tác cửa sổ tiêu chuẩn hay không, vì việc này thường thuộc về tráchnhiệm của hệ điều hành

Ví dụ: Nếu một người dùng đóng cửa sổ trong khi đang thực hiện một giao dịch, việc

đóng cửa sổ có thể khiến cơ sở dữ liệu rơi vào trạng thái không nhất quán Việc kiểm thửphải đảm bảo rằng ứng dụng có thể xử lý đúng tình huống này, ví dụ như yêu cầu ngườidùng hoàn thành hoặc hủy giao dịch trước khi cho phép đóng cửa sổ

Trang 9

2 Chiến lược kiểm thử GUI

2.1 Nguyên tắc kiểm thử áp dụng cho GUI

Cách tiếp cận đề xuất của chúng tôi để kiểm thử GUI dựa trên một

số nguyên tắc, hầu hết trong số đó đều quen thuộc Bằng cáchtuân theo những nguyên tắc này, chúng tôi sẽ phát triển một quytrình kiểm thử có thể áp dụng chung cho bất kỳ ứng dụng GUInào Lưu ý rằng cách tiếp cận kiểm thử này không bao gồm kiểmthử hộp trắng (white-box testing) của mã ứng dụng một cách chitiết Phương pháp này tập trung vào các lỗi GUI và sử dụng GUI đểthực hiện các bài kiểm thử, vì vậy nó rất thiên về kiểm thử hộpđen (black-box testing)

Tập trung vào lỗi để giảm phạm vi kiểm thử

Chúng tôi dự định phân loại lỗi thành các loại và thiết kế cácbài kiểm thử để phát hiện từng loại lỗi Bằng cách này, chúngtôi có thể tập trung kiểm thử và loại bỏ sự trùng lặp

Phân chia vấn đề (chia để trị)

Bằng cách tập trung vào từng loại lỗi cụ thể và thiết kế cáctrường hợp kiểm thử để phát hiện những lỗi đó, chúng tôi cóthể chia nhỏ vấn đề phức tạp thành nhiều vấn đề đơn giản hơn

Kỹ thuật thiết kế kiểm thử khi phù hợp

Các kỹ thuật kiểm thử hộp đen truyền thống mà chúng tôi sửdụng để kiểm thử các ứng dụng dựa trên biểu mẫu vẫn phù hợptrong trường hợp này

Kiểm thử theo tầng và theo giai đoạn

Chúng tôi sẽ sắp xếp các loại kiểm thử thành một loạt các giaiđoạn kiểm thử Nguyên tắc ở đây là chúng tôi sẽ thực hiệnkiểm thử ở cấp độ chi tiết thấp nhất trước Sau đó, chúng tôithực hiện các bài kiểm thử tích hợp giữa các thành phần vàcuối cùng là kiểm thử ứng dụng đã được tích hợp Bằng cáchnày, chúng tôi có thể xây dựng quá trình kiểm thử thành từngtầng đáng tin cậy

Trang 10

Tự động hóa kiểm thử ở bất kỳ đâu có thể

Tự động hóa thường thất bại vì quá tham vọng Bằng cách chiaquy trình kiểm thử thành các giai đoạn, chúng tôi có thể tìmkiếm cơ hội để tận dụng tự động hóa ở những chỗ phù hợp,thay vì cố gắng sử dụng tự động hóa ở mọi nơi

2.2 Quy trình kiểm thử cấp cao

Hình 1 trình bày một quy trình kiểm thử cấp cao Chúng tôi có thểchia quy trình này thành ba giai đoạn chính: Thiết kế kiểm thử,Chuẩn bị kiểm thử và Thực thi kiểm thử Trong bài viết này, chúngtôi sẽ tập trung vào giai đoạn đầu tiên: Thiết kế kiểm thử và tìmkiếm cơ hội để sử dụng các công cụ tự động hóa nhằm thực hiệncác bài kiểm thử một cách hiệu quả

Figure 1 - The high-level test process

Trang 11

2.3 Các loại lỗi GUI

Chúng ta có thể liệt kê một số lỗi đa dạng có thể xảy ra trong một ứng dụng dựa trên mô hình client/server mà chúng ta có thể kiểm tra thông qua giao diện đồ họa (GUI) Danh sách bên dưới chắc chắn chưa đầy đủ, nhưng nó thể hiện được sự đa dạng của các loại lỗi Nhiều lỗi trong số này liên quan đến giao diện đồ họa, trong khi các lỗi khác liên quan đến chức năng bên dưới hoặc các giao diện giữa ứng dụng GUI và các thành phần khác của mô hình client/server Bảng 1 - Sự đa dạng của các lỗi trong các ứng dụng GUI

1 Data validation (Xác thực dữ liệu)

Mô tả: Kiểm tra xem dữ liệu nhập vào có tuân thủ đúng quy tắc vàđịnh dạng mong muốn hay không (ví dụ: số, ký tự, ngày giờ).Lỗi: Không kiểm tra định dạng hoặc phạm vi dữ liệu hợp lệ, dẫnđến nhập sai hoặc lỗi trong hệ thống

Ví dụ: Trường “Ngày sinh” chấp nhận dữ liệu dạng “abc” thay vìđịnh dạng ngày hợp lệ

2 Incorrect field defaults (Giá trị mặc định sai của các trường)

Mô tả: Giá trị mặc định của một trường trong giao diện khôngchính xác

Lỗi: Giá trị ban đầu của trường không đúng hoặc không hữu ích,gây nhầm lẫn cho người dùng

Ví dụ: Trường “Số lượng” được mặc định là 0 thay vì để trống, làmngười dùng không để ý và gửi đi dữ liệu sai

3 Mis-handling of server process failures (Xử lý không đúng lỗi từ máy chủ)

Mô tả: Giao diện không quản lý tốt các lỗi từ phía máy chủ, nhưkết nối thất bại hoặc máy chủ không phản hồi

Lỗi: Không có thông báo hoặc thông báo không rõ ràng về lỗi từmáy chủ

Trang 12

Ví dụ: Khi kết nối tới server thất bại, ứng dụng vẫn “treo” màkhông thông báo cho người dùng biết.

4 Mandatory fields, not mandatory (Trường bắt buộc nhưng không kiểm tra)

Mô tả: Các trường được đánh dấu là bắt buộc nhưng không đượckiểm tra khi người dùng bỏ qua

Lỗi: Người dùng có thể gửi biểu mẫu mà không điền đủ thông tincần thiết

Ví dụ: Trường "Email" là bắt buộc nhưng lại không có thông báonếu bỏ trống

5 Wrong fields retrieved by queries (Truy vấn trả về sai trường dữ liệu)

Mô tả: Kết quả truy vấn trả về dữ liệu từ các trường không đúnghoặc không liên quan

Lỗi: Thông tin hiển thị trên màn hình không khớp với yêu cầu

Ví dụ: Người dùng tìm kiếm theo mã khách hàng nhưng hệ thốnglại trả về tên sản phẩm

6 Incorrect search criteria (Tiêu chí tìm kiếm sai)

Mô tả: Các tiêu chí tìm kiếm không chính xác hoặc không hoạtđộng như mong đợi

Lỗi: Tìm kiếm không trả về dữ liệu phù hợp hoặc không có kết quảnào

Ví dụ: Tìm kiếm “Hóa đơn tháng 10” nhưng hệ thống chỉ hiển thịhóa đơn của tháng 9

7 Field order (Thứ tự trường không chính xác)

Mô tả: Thứ tự các trường trên giao diện không hợp lý, gây khókhăn cho người dùng

Lỗi: Người dùng nhầm lẫn khi nhập dữ liệu

Ví dụ: Trường “Tên” hiển thị sau trường “Họ” khiến người dùngnhập sai thứ tự

Trang 13

8 Multiple database rows returned, single row expected (Nhiều dòng dữ liệu trả về thay vì một)

Mô tả: Truy vấn mong đợi trả về một kết quả duy nhất nhưng lạitrả về nhiều dòng dữ liệu

Lỗi: Làm rối thông tin và gây nhầm lẫn cho người dùng

Ví dụ: Người dùng tìm một mã đơn hàng nhưng hệ thống lại trả vềdanh sách nhiều đơn hàng

9 Currency of data on screens (Tính tức thời của dữ liệu trên màn hình)

Mô tả: Dữ liệu trên giao diện có được cập nhật kịp thời hay không.Lỗi: Dữ liệu cũ vẫn hiển thị dù đã được cập nhật từ server

Ví dụ: Một sản phẩm đã được bán hết nhưng giao diện vẫn hiểnthị là “Còn hàng”

10 Window object/DB field correspondence (Đồng bộ giữa đối tượng cửa sổ và trường cơ sở dữ liệu)

Mô tả: Sự liên kết giữa các đối tượng giao diện và các trường dữliệu trong cơ sở dữ liệu

Lỗi: Dữ liệu không được hiển thị đúng vị trí hoặc bị gán sai đốitượng

Ví dụ: Mục "Giá" hiển thị số lượng sản phẩm thay vì số tiền

11 Correct window modality? (Chế độ cửa sổ đúng chưa?)

Mô tả: Kiểm tra xem cửa sổ có chế độ hoạt động đúng không (vídụ: cửa sổ chính, cửa sổ bật lên cần phải modal hay không).Lỗi: Cửa sổ không ngăn tương tác với các phần khác khi cần

Ví dụ: Một hộp thoại cảnh báo không phải là modal và cho phépngười dùng tiếp tục thao tác sai

12 Window system commands not available/don’t work (Lệnh hệ thống không hoạt động)

Trang 14

Mô tả: Các lệnh hệ thống như đóng, phóng to, thu nhỏ không hoạtđộng hoặc bị vô hiệu.

Lỗi: Người dùng không thể thao tác cơ bản với cửa sổ

Ví dụ: Nút “Đóng” của cửa sổ không phản hồi khi nhấn

13 Control state alignment with state of data in window? (Trạng thái điều khiển khớp với dữ liệu chưa?)

Mô tả: Kiểm tra xem các điều khiển (như nút bấm) có phản ánhđúng trạng thái dữ liệu không

Lỗi: Nút “Lưu” vẫn kích hoạt dù không có thay đổi dữ liệu

14 Focus on objects needing it? (Tiêu điểm đặt đúng đối tượng chưa?)

Mô tả: Đảm bảo tiêu điểm (focus) được đặt ở đúng đối tượng khicửa sổ mở

Lỗi: Người dùng phải nhấn chuột để di chuyển tiêu điểm thay vìđược định sẵn

Ví dụ: Khi mở hộp thoại, tiêu điểm không nằm trong trường nhậpliệu đầu tiên

15 Menu options align with state of data or application mode? (Tùy chọn menu khớp với trạng thái dữ liệu không?)

Mô tả: Các tùy chọn trên menu phải phản ánh đúng trạng thái dữliệu hoặc chế độ ứng dụng

Lỗi: Menu hiển thị các tùy chọn không khả dụng hoặc không liên

Lỗi: Lệnh “Xóa” vẫn hoạt động dù không có mục nào được chọn

17 Synchronization of window object content (Đồng bộ nội dung đối tượng trong cửa sổ)

Trang 15

Mô tả: Kiểm tra xem nội dung giữa các đối tượng giao diện cóđồng bộ không.

Lỗi: Một cửa sổ cập nhật nhưng không được phản ánh ở cửa sổkhác

Ví dụ: Cửa sổ chi tiết đơn hàng không tự cập nhật khi thông tinthay đổi trong cửa sổ chính

18 State of controls aligns with state of data in window? (Trạng thái điều khiển khớp với dữ liệu)

Mô tả: Các điều khiển như nút, hộp kiểm phải đúng với trạng tháicủa dữ liệu

Lỗi: Nút “Hủy” không bị vô hiệu hóa sau khi đã hủy thao tác

Bằng cách nhắm vào các loại lỗi khác nhau trong danh sách này,chúng ta có thể tạo ra một bộ các loại kiểm thử khác nhau, mỗiloại tập trung vào một nhóm lỗi cụ thể và đảm bảo độ bao phủ tất

cả các loại lỗi

2.4 Bốn giai đoạn kiểm thử GUI

1 Giai đoạn cấp độ thấp (Low Level)

Mục tiêu: Kiểm tra các thành phần nhỏ của giao diện, đảm bảochúng hoạt động đúng và tuân thủ các tiêu chuẩn thiết kế Giaiđoạn này liên quan nhiều đến kiểm thử đơn vị (unit testing).Các loại kiểm thử:

Navigation (Điều hướng):

Kiểm tra luồng điều hướng giữa các trang hoặc màn hình trongứng dụng

Trang 16

Ví dụ: Xác nhận rằng khi nhấn nút "Tiếp theo", ứng dụng chuyểnsang màn hình tiếp theo.

Cách tiếp cận:

 Chuẩn bị một danh sách kiểm tra chi tiết bao gồm các yếu tố sau:

o Hiển thị: Kiểm tra các thành phần như nút, nhãn, biểu mẫu.

o Chức năng: Đảm bảo các nút bấm và menu thực hiện đúng thao tác.

o Tính nhất quán: Đảm bảo giao diện thống nhất về màu sắc, font chữ và

kích thước

 Dùng công cụ quản lý checklist (Excel, Trello, TestRail) để theo dõi tiến độ

Ví dụ:

 Kiểm tra sự hiện diện và hoạt động của nút "Đăng nhập"

 Đảm bảo các trường "Email""Mật khẩu" đều có nhãn và thông báo lỗi nếunhập sai

Trang 17

2 Giai đoạn ứng dụng (Application)

Mục tiêu: Tập trung vào kiểm thử các chức năng chính của ứngdụng thông qua giao diện người dùng Các loại kiểm thử ở đâythường được sử dụng trong kiểm thử đơn vị hoặc kiểm thử hệthống chức năng

Các loại kiểm thử:

Equivalence Partitioning (Phân vùng tương đương):

Phân chia dữ liệu đầu vào thành các nhóm tương đương để giảmthiểu số lượng trường hợp kiểm thử mà vẫn đảm bảo hiệu quả Vídụ: Kiểm tra các nhóm tuổi dưới 18, 18–65, và trên 65 với cùngmột logic xử lý

Boundary Values (Giá trị biên):

Kiểm tra các giá trị nằm tại ranh giới của các điều kiện để tìm ralỗi Ví dụ: Kiểm tra trường "Tuổi" với giá trị biên là 17, 18, 65, và66

Decision Tables (Bảng quyết định):

Kiểm tra các trường hợp kiểm thử dựa trên nhiều điều kiện vàhành động Ví dụ: Với các điều kiện khác nhau (tuổi và tình trạngtài chính), ứng dụng có cấp khoản vay hay không?

State Transition Testing (Kiểm thử chuyển đổi trạng thái):

Đảm bảo hệ thống hoạt động đúng khi chuyển từ trạng thái nàysang trạng thái khác Ví dụ: Khi chuyển từ “Đang chờ duyệt” sang

“Đã phê duyệt”, các nút liên quan phải kích hoạt hoặc vô hiệu hóađúng cách

Trang 18

3 Giai đoạn tích hợp (Integration)

Mục tiêu: Kiểm tra tính tương thích và liên kết giữa các thànhphần khác nhau của hệ thống, đặc biệt là sự tương tác giữa client

và server Các kiểm thử này thường thuộc kiểm thử hệ thống.Các loại kiểm thử:

Desktop Integration (Tích hợp trên máy tính để bàn):

Kiểm tra xem các ứng dụng GUI có tương thích với môi trườngdesktop hay không

Ví dụ: Đảm bảo ứng dụng có thể mở tệp trực tiếp từ hệ điều hành.C/S Communications (Giao tiếp giữa Client/Server):

Kiểm tra sự tương tác giữa giao diện người dùng và máy chủ(server)

Ví dụ: Đảm bảo các yêu cầu từ client được gửi lên server và nhậnphản hồi đúng cách

4 Giai đoạn phi chức năng (Non-Functional)

Mục tiêu: Tập trung vào các khía cạnh phi chức năng như hiệusuất, khả năng tương thích, và môi trường vận hành của ứng dụngGUI

Các loại kiểm thử:

Soak Testing (Kiểm thử tải dài hạn):

Kiểm tra ứng dụng bằng cách để nó chạy liên tục trong thời giandài để phát hiện các vấn đề như rò rỉ bộ nhớ

Ví dụ: Chạy ứng dụng trong 24 giờ để kiểm tra xem có vấn đề gì

về hiệu suất không

Ngày đăng: 28/12/2024, 14:54