2.6.1. Lỗi chức năng
Một chƣơng trình có vấn đề về chức năng nếu nó không thực thi việc gì đó nên làm, hay thực hiện một cách khó khăn hoặc không hoàn thành. Các đặc tả định nghĩa chức năng chƣơng trình cho một nhóm sự thi hành, nhƣng sự định nghĩa cuối cùng của câu hỏi chƣơng trình tƣởng là làm cái gì lại dựa trên cảm nhận của ngƣời dùng.
Một chƣơng trình có vấn đề chức năng nếu có gì đó mà ngƣời dùng mong đợi nhƣng khi thực hiện lại khó khăn, lúng túng, khó hiểu, hay bất khả thi. Vấn đề này bị coi là lỗi chức năng nếu sự mong đợi của ngƣời dùng là hợp lý.
Chú ý: Mọi chƣơng trình đều có vấn đề về chức năng bởi các ngƣời dùng khác nhau thì sự trông đợi của họ cũng rất khác nhau. Không thể đoán trƣớc đƣợc sự trông mong của tất cả mọi ngƣời. Bạn hầu nhƣ không thể đáp ứng đƣợc nhu cầu của tất cả mọi ngƣời mà không bị mất đi tính đơn giản và tính toàn vẹn của chƣơng trình.
2.6.2. Lỗi giao tiếp truyền thông
Để tìm ra các lỗi giao tiếp truyền thông, cần trả lời một số câu hỏi sau đây. Làm thế nào để biết cách sử dụng chƣơng trình nhƣ thế nào? Thông tin nào hiển thị sẵn trên màn hình? Các thông tin đó đã đủ chƣa, nó có dễ hiểu, có phản cảm? Hệ thống có phản hồi gì khi gây ra một lỗi hay khi ngƣời dùng nhấn <Help>? Các thông tin đó có hữu ích, có chính xác, có cái gì gây khó chịu, gây nhầm lẫn, khó hiểu hay trình bày xấu?
2.6.3. Lỗi cấu trúc lệnh
Một số lỗi cấu trúc lệnh thƣờng gặp với giao diện phần mềm: lệnh có dễ bị mất trong chƣơng trình? Có nhiều lệnh khó hiểu hay dễ gây khó hiểu với các lệnh khác không? Các lỗi nào mà ngƣời dùng tạo ra, chi phí thời gian, và tại sao phát sinh lỗi?
2.6.4. Thiếu lệnh
Bên cạnh lỗi về cấu trúc lệnh còn có lỗi thiếu lệnh. Điển hình của thiếu lệnh là việc chƣơng trình bắt bạn nghĩ theo hƣớng cứng nhắc, gƣợng ép, hay không có hiệu quả. Ngƣời dùng có thể tùy chỉnh nó phù hợp với kiểu làm việc của bạn hay những nhu cầu cơ bản? Quan trọng thế nào là tùy chỉnh cho một chƣơng trình nhƣ thế?
2.6.5. Lỗi thi hành
Tốc độ là một tính chất trong phần mềm tƣơng tác. Bất kỳ thứ gì khiến ngƣời dùng thấy chƣơng trình thực thi chậm đều là vấn đề. (Đặc biệt là khi có chƣơng trình cạnh tranh cảm nhận nhanh hơn).
2.6.6. Đầu ra
Hầu hết các chƣơng trình hiển thị, in, vẽ đồ thị, hay lƣu thông tin. Các kết quả đó có đáp ứng đúng định dạng dữ liệu yêu cầu hay không? Kết quả có ý nghĩa, có thể đọc đƣợc hay không? Đầu ra có phù hợp với nhu cầu cần thiết của ngƣời dùng hay không? Tất cả các câu hỏi này đều liên quan tới lỗi đầu ra của ứng dụng.
CHƢƠNG 3 – KIỂM THỬ GIAO DIỆN PHẦN MỀM 3.1. Khái niệm kiểm thử giao diện phần mềm
Một ứng dụng tốt phải đảm bảo giao diện ngƣời dùng tốt, nó phải đảm bảo các yêu cầu về tính tiện dụng đã đƣợc nêu trong Mục 2.4 của luận văn. Kiểm thử tính tiện dụng là một dạng kiểm thử đảm bảo ứng dụng đáp ứng các yêu cầu ngƣời dùng. Kiểm thử giao diện ngƣời dùng là trƣờng hợp đặc trƣng nhất của kiểm thử tính tiện dụng, và thƣờng đƣợc biết đến nhƣ là kiểm thử giao diện.
Kiểm thử giao diện là quá trình thử nghiệm giao diện ngƣời dùng đồ họa của một sản phẩm để đảm bảo đáp ứng đúng nhƣ đặc tả đã đƣợc viết ra. Điều này thƣờng đƣợc thực hiện thông qua việc sử dụng một loạt các ca kiểm thử.
Bảng 3.1 - Các mức kiểm thử và các loại kiểm thử giao diện phù hợp
Mức thấp Kiểm thử danh mục kiểm tra
Sự điều hƣớng
Ứng dụng
Phân lớp tƣơng đƣơng
Giá trị biên
Bảng quyết định
Kiểm thử chuyển đổi trạng thái
Tích hợp Tích hợp màn hình nền Giao tiếp Đồng bộ hóa Phi chức năng Kiểm thử Soak Kiểm thử tính tƣơng thích Nền tảng và môi trƣờng 3.2. Kiểm thử nhƣ thế nào
Một vấn đề trong kiểm thử GUI đó là cần phải ánh xạ từ một hành động có nghĩa vào một chƣơng trình hành động. Ví dụ nhƣ lựa chọn một đối tƣợng thứ hai trong một bảng ghi sẽ bao gồm hai hành động riêng biệt. Trƣớc tiên, mục tiêu của hành động là “bảng ghi”, bằng cách nào đó phải chuyển tới một mã đối tƣợng thực tế. Thứ hai, sự kiện ngữ nghĩa “lựa chọn đối tƣợng thứ hai” phải đƣợc dịch ra một chƣơng trình hành động trên đối tƣợng mã.
3.2.1. Nguyên tắc chung khi kiểm thử giao diện phần mềm
Một ca kiểm thử trong phát triển ứng dụng là một tập hợp các điều kiện hoặc các biến mà theo đó kiểm thử viên sẽ xác định xem ứng dụng hay hệ thống phần mềm đang làm việc có chính xác hay không. Trong kiểm thử giao diện, rất dễ bỏ sót các trƣờng hợp kiểm thử, vì vậy cần có một giải pháp kiểm thử kỹ lƣỡng hơn. Các phần mềm ứng dụng hay website có giao diện riêng và rất khác nhau. Tuy nhiên chúng vẫn có những bố cục chung và có các nguyên tắc chung khi kiểm thử giao diện phần mềm.
Dƣới đây là danh sách các ca kiểm thử cần lƣu ý khi kiểm thử giao diện [11]. - Các trƣờng bắt buộc
Nếu màn hình yêu cầu nhập dữ liệu trong các trƣờng cụ thể, các nhà thiết kế cần chỉ ra các trƣờng bắt buộc với một dấu hoa thị màu đỏ, và tạo một cảnh báo nếu để trống dữ liệu.
- Các lỗi kiểu dữ liệu
Nếu màn hình chứa các kiểu dữ liệu đặc biệt nhƣ ngày tháng, số, tiền tệ,… thì phải đảm bảo chỉ đúng kiểu dữ liệu đó đƣợc nhập vào.
- Kích thƣớc các trƣờng dữ liệu
Nếu màn hình chứa các text box cho phép nhập dữ liệu, đảm bảo rằng kích thƣớc dữ liệu nhập vào không vƣợt quá chiều rộng của trƣờng đó trong bảng (ví dụ, tiêu đề có kích thƣớc tối đa là 100 ký tự trong cơ sở dữ liệu thì không đƣợc phép vƣợt quá 100 ký tự nhập vào từ giao diện ngƣời dùng).
- Các hƣớng dẫn trên màn hình
Bất kỳ màn hình nào cũng không thể tự nó giải thích cho ngƣời dùng thông thƣờng, do vậy nên có các hƣớng dẫn trên màn hình để hỗ trợ ngƣời dùng. - Các hƣớng dẫn ngắn
Các hƣớng dẫn thƣờng rất dài, đôi khi gây phiền phức hay mất tính thẩm mỹ. Để vẫn đảm bảo hƣớng dẫn ngƣời dùng mà không gây các phản tác dụng này, cần lựa chọn từ ngữ, chỉ giữ lại các thông tin diễn đạt xúc tích dễ hiểu.
- Các thanh tiến trình
Nếu màn hình chờ kết quả kéo dài trên 5s, nên có thanh tiến trình để ngƣời dùng biết rằng quá trình vẫn đang tiếp diễn (chƣơng trình đang xử lý).
Nếu ứng dụng mở cùng một tài liệu nhiều lần, nó sẽ nối thêm một số duy nhất để mở tài liệu này để giữ một tài liệu ghi đè khác. Ví dụ, nếu ứng dụng mở một tài liệu có tên Test.txt và cũng ngƣời dùng đó lại mở tài liệu này lần nữa, hãy thêm yếu tố thời gian hoạc số tuần tự vào sau nó (Test2.txt hay Test_031213.txt).
- Thẩm mỹ không nhất quán
Mỗi màn hình nhìn, cảm nhận và thiết kế phải phù hợp với các màn hình khác trong cùng ứng dụng. Việc tạo và sử dụng cùng một hƣớng dẫn kiểu cách là cách tốt nhất để đảm bảo tính nhất quán trong toàn ứng dụng.
- Tên viết tắt không nhất quán
Nếu các màn hình chứa các ký hiệu viết tắt (ví dụ: Nbr cho number, Amt cho amount,…), thì các ký hiệu này phải nhất quán trên tất cả các màn hình của ứng dụng. Một lần nữa, các hƣớng dẫn về kiểu cách chính là chìa khóa đảm bảo vấn đề này.
- Xác nhận khi lƣu
Nếu màn hình cho phép sự thay đổi dữ liệu mà không cần lƣu, trƣớc khi ứng dụng chuyển sang màn hình hay bản ghi khác cần hiển thị gợi ý tới ngƣời dùng để xác nhận việc lƣu dữ liệu.
- Xác nhận khi xóa
Nếu một ngƣời xóa một mục, sẽ là một ý hay khi đƣa ra thông báo xác nhận việc xóa. Tuy nhiên, trong các trƣờng hợp giao diện ngƣời dùng cho phép xóa nhiều bản ghi trong một dòng, các nhà phát triển cần xem xét việc bỏ qua yêu cầu xác nhận này bởi nó rất dễ gây khó chịu cho ngƣời dùng khi phải liên tiếp click vào các yêu cầu xác nhận.
- Chữ cái đầu tiên
Nếu giao diện ngƣời dùng có các combo-box hay các list-box, đảm bảo rằng khi gõ một chữ cái bất kỳ, thì combo-box hay list-box đó sẽ xổ xuống danh sách các mục đƣợc bắt đầu bằng chữ cái đó, thay vì danh sách có thứ tự mặc định ban đầu.
- Ngữ pháp và chính tả
Đảm bảo các ca kiểm thử tìm kiếm các lỗi ngữ pháp và chính tả. - Bảng cuộn (Table Scrolling)
Nếu ứng dụng liệt kê thông tin dƣới dạng bảng và dữ liệu trong bảng vƣợt quá một trang, scrolling sẽ giúp di chuyển dữ liệu nhƣng vẫn khéo léo giữ nguyên tiêu đề bảng.
- Ghi lỗi
Nếu các lỗi không thể tránh (fatal errors) xảy ra khi ngƣời dùng sử dụng ứng dụng, đảm bảo rằng ứng dụng ghi lại các lỗi này vào một tệp tin log, trình xem sự kiện, hay bảng cơ sở dữ liệu để xem lại lần sau. Ghi lại tiến trình xảy ra lỗi, ngƣời đăng nhập, và thời gian lỗi.
- Thông báo lỗi
Đảm bảo rằng các thông báo lỗi đầy đủ thông tin, đúng ngữ pháp và phù hợp. - Phím tắt (Shortcuts)
Nếu ứng dụng cho phép các phím tắt (nhƣ CTRL+S để lƣu), cần kiểm thử mỗi shortcut để đảm bảo nó hoạt động trên tất cả các trình duyệt khác nhau (nếu là ứng dụng web).
- Các lựa chọn không khả thi
Không hiển thị các chỉ dẫn cho các lựa chọn không khả thi tại thời điểm xác định. Ví dụ, do trạng thái của dữ liệu, không thể thực hiện chức năng in tại thời điểm đó, thì trên màn hình không đƣợc hiển thị nút In (Print).
- Danh mục không hợp lệ
Không hiển thị các danh mục không khả thi trong bối cảnh ngƣời dùng đang thực hiện.
- Nhất quán các hộp thoại
Các hộp thoại cần nhất quán về thiết kế trên tất cả các màn hình của ứng dụng. Sử dụng hƣớng dẫn về kiểu hộp thoại cho tất cả các hộp thoại. Thiết kế không thể có hộp thoại Save/Cancel trên một màn hình và một hộp thoại OK/Cancel trên màn hình khác. Nhƣ vậy là không nhất quán. Mặc định, với các hộp thoại, phím <Enter> đƣợc thiêt đặt nhƣ nút OK, phím <Esc> đƣợc thiêt đặt nhƣ nút Cancel.
- Kiểu phông màn hình
Đảm bảo phông màn hình phù hợp từ màn hình này tới màn hình khác. Sự không phù hợp phông chữ trong cùng một câu và việc sử dụng quá nhiều phông
chữ có thể làm giảm đi tính chuyên nghiệp của giao diện ngƣời dùng của phần mềm.
- Kích cỡ phông chữ màn hình
Đảm bảo kích cỡ phông chữ phù hợp giữa các màn hình. Một giao diện ngƣời dùng tốt sẽ có một hƣớng dẫn phong cách đi kèm cụ thể, chỉ rõ kiểu phông chữ và kích cho từng nội dung nhƣ header, footer, body text,...
- Màu sắc
Đảm bảo các màn hình không sử dụng các tập màu khác nhau tạo ra một giao diện không phù hợp và kém thông minh. Hƣớng dẫn phong cách cần định rõ màu sắc cho từng thành phần: header, footer, body background,…
- Biểu tƣợng
Đảm bảo tất cả các biểu tƣợng (icon) đều nhất quán trong toàn ứng dụng bằng cách sử dụng một tập icon chung. Ví dụ, một liên kết trở lại BACK chứa một icon bên cạnh nó, trên một màn hình không nên sử dụng các icon khác nhau so với các màn hình khác. Tránh sử dụng các icon nghệ thuật tự do, lựa chọn các icon đƣợc thiết kế chuyên nghiệp để thiết kế màn hình có cái nhìn và cảm nhận một cách tổng thể.
- Văn bản mô tả
Có văn bản mô tả (narrative text) là một cách tốt để giao tiếp đƣa ra chỉ dẫn cách sử dụng một màn hình cụ thể. Đảm bảo rằng các narrative text xuất hiện tại cùng một vị trí trên màn hình đối với tất cả các màn hình.
- Đảm bảo tính ngắn gọn
Đảm bảo rằng các văn bản tƣờng thuật, các thông báo lỗi và các hƣớng dẫn khác đƣợc trình bày dễ hiểu mà ngắn gọn và rõ ràng.
- Liên kết
Nếu ứng dụng có các liên kết trên màn hình (ví dụ lƣu dƣới dạng Spreadsheet, Export, Print, Email,…), đảm bảo các liên kết có khoảng cách phù hợp giữa chúng và các liên kết khác, xuất hiện với cùng thứ tự trên các màn hình, và màu sắc các liên kết phải nhất quán.
Nếu ứng dụng có trình đơn, đảm bảo các trình đơn này áp dụng cho các màn hình cụ thể đã bị vô hiệu hóa, và thứ tự các mục trong mỗi trình đơn phải nhất quán giữa các màn hình.
- Nút bấm
Nếu ứng ụng có các nút bấm (ví dụ: Submit, OK, Cancel, ...), đảm bảo việc hiển thị các nút bấm này theo thứ tự nhất quán giữa các màn hình (Ví dụ,
Submit rồi tới Cancel).
- Tab
Cần có các ca kiểm thử kiểm tra hoạt động của phím Tab trong ứng dụng. Thứ tự Tab thông thƣờng nên thiết lập theo chiều ngang của các trƣờng. Trong một số trƣờng hợp có thể thiết lập theo chiều dọc.
3.3.2. Chiến lược kiểm thử giao diện
Điều đầu tiên khi nhắc tới giao diện mà ngƣời ta sẽ liên tƣởng tới đó chính là tính thẩm mỹ. Do đó song song với việc kiểm thử tính tiện lợi của hệ thống (đã nêu trong Mục 2.4 và 2.5 của Chƣơng 2 luận văn), cần kiểm tra tính thẩm mỹ của giao diện phần mềm. Để kiểm thử giao diện phần mềm, có thể áp dụng một trong các chiến lƣợc sau đây:
- Tập trung vào các lỗi để giảm bớt phạm vi kiểm chứng - Chia các vấn đề cần quan tâm
- Thiết kế kỹ thuật kiểm chứng ở nơi thích hợp - Phân lớp và các giai đoạn kiểm chứng
- Kiểm thử tự động hóa có thể ở bất cứ nơi nào thích hợp
3.3. Danh mục kiểm thử giao diện
Để không bỏ sót các trƣờng hợp kiểm thử, cần lập một danh sách các trƣờng hợp cần kiểm thử (testing checklist). Nhìn chung, kiểm thử giao diện các ứng dụng đều cần kiểm thử danh sách dƣới đây và đƣợc phân thành ba nhóm danh mục chính:
- Kiểm thử sự tuân thủ của cửa sổ - Danh mục sự hợp thức hóa màn hình - Các hành động chuẩn
3.3.1. Kiểm thử sự tuân thủ chuẩn Windows
3.3.1.1. Ứng dụng
Mở ứng dụng bằng cách kích đúp chuột vào icon của nó. Trong khi ứng dụng đang mở, nên hiển thị một Loading message với các thông số: tên ứng dụng, phiên
bản, và ảnh nền giống nhƣ icon của ứng dụng đƣợc phóng to. Có thể không đăng nhập, mà vào ngay màn hình chính của ứng dụng. cửa sổ chính phải có tiêu đề giống nhƣ tiêu đề icon của nó. Ví dụ nhƣ ứng dụng Window Media Player trong hình 3.1 thể hiện rất tốt điều này.
Hình 3.1 – Ứng dụng thỏa mãn sự đồng bộ Caption
Đóng ứng dụng, tùy thuộc tính chất và yêu cầu của ứng dụng, mà có thể hiển thị hoặc không hiển thị thông báo yêu cầu ngƣời dùng xác thực thao tác đóng ứng dụng.
Kiểm tra trƣờng hợp một ngƣời dùng liên tục mở ứng dụng, chƣơng trình tốt sẽ cho kết quả cùng trở về màn hình chính, ngƣợc lại nếu có thể mở đồng thời nhiều cửa sổ ứng dụng thì đây là một lỗi giao diện. Tƣơng tự nhƣ vậy, kiểm tra trƣờng hợp mở nhiều lần ứng dụng khi chƣơng trình đang tải (loading).
Với mỗi cửa sổ làm việc, khi chƣơng trình đang bận, nên hiển thị biểu tƣợng đồng hồ cát để ngƣời dùng biết rằng chƣơng trình đang xử lý, hoặc có thể hiển thị một