Don Norman đã mô tả trong cuốn sách “The design of everyday things” sáu nguyên lý thiết kế để hệ thống có tính tiện lợi [4]. Đó là:
Phản hồi (Feedback) Ràng buộc (Constraints) Ánh xạ (Mapping) Nhất quán (Consistency) Gợi ý (Affordance) 2.5.1. Sự rõ ràng
Sự rõ ràng đƣợc xem nhƣ những phần hệ thống liên quan cần phải đƣợc nhìn thấy. Nó là nguyên tắc cơ bản nhất trong việc giao tiếp mô hình với ngƣời dùng. UI cần có khả năng giúp cho ngƣời sử dụng nhận biết trạng thái hiện hành của hệ thống và cần phải thực hiện thao tác nào. Thí dụ, khi di chuột đến bất kỳ vị trí nào trên màn hình, ngƣời sử dụng cần đƣợc biết điều gì xảy ra nếu nhấn chuột.
2.5.2. Sự phản hồi
Sự phản hồi chính là sự đáp trả của hệ thống khi ngƣời dùng thực hiện một hành động. Khi có bất kỳ thay đổi nào, nó cần đƣợc nhìn thấy. Có thể phản hồi thông qua âm thanh, hình ảnh, xúc giác. Thí dụ, khi ngƣời dùng nhấn phím, hệ thống sẽ có sự phản hồi là phím đó bị nhấn hay nhả. Hay khi thực hiện thao tác xóa tệp, kết quả trả về là tệp dữ liệu bị mất đi.
2.5.3. Tính ràng buộc
Mức độ khó sử dụng hệ thống liên quan trực tiếp đến tổng số khả năng. Ràng buộc là các giới hạn vật lý, ngữ nghĩa, văn hóa và logic trên tổng số khả năng.
Thí dụ với đồ chơi xe gắn máy, thiết kế tận dụng lợi thế ràng buộc để cho khả năng lắp ráp đơn giản. Bộ đồ chơi có 12 chi tiết với các ràng buộc nhƣ sau:
Ràng buộc vật lý: bánh trƣớc chỉ có thể lắp vừa một vị trí.
Ràng buộc ngữ nghĩa: Tài xế ngồi trên ghế và mặt quay về phía trƣớc. Ràng buộc văn hóa: Đèn vàng lắp phía trƣớc, đèn đỏ lắp phía sau. Ràng buộc logic: Hai đèn xanh, hai màu trắng đi với nhau.
Hình 2.7 – Ví dụ về tính ràng buộc
2.5.4. Tính ánh xạ
Ánh xạ là quan hệ giữa các điều khiển (controls) và ảnh hƣởng của nó trên hệ thống. Ánh xạ tự nhiên lấy lợi thế của sự tƣơng ứng vật lý và các chuẩn văn hóa. Ví dụ, xoay tay lái xe về bên trái để rẽ trái, xoay sang bên phải để rẽ phải. Ánh xạ tự nhiên phải tƣơng quan với tri thức về thế giới thực.
2.5.5. Tính nhất quán
Tính nhất quán có mối quan hệ với tính tƣơng tự trong hành vi xuất hiện trong các tình huống tƣơng tự. Tuy nhiên tính nhất quán có nhiều dạng khác nhau, nên gây khó khăn trong thiết kế. Nó không phải là một thuộc tính đơn của hệ thống tƣơng tác, nó cần đƣợc áp dụng trong nhiều tình huống, nhƣ: cách đặt tên, cách tham số cho lệnh, hay cách sắp xếp bố cục giao diện,…
Tính nhất quán có thể đƣợc biểu diễn theo thuật ngữ của dạng biểu diễn đầu vào và đầu ra khi tôn trọng ngữ nghĩa của hành động trong một vài mô hình khái niệm của hệ thống. Thí dụ, trƣớc khi giới thiệu tƣờng minh các phím mũi tên, một vài hệ soạn thảo văn bản sử dụng vị trí tƣơng đối của phím trên bàn phím để chỉ hƣớng thao tác (lên, xuống, sang trái, sang phải).
2.5.6. Tính gợi ý
Tính gợi ý là khả năng mà ngƣời dùng có thể xác định cách sử dụng đối tƣợng chỉ bằng việc quan sát nó. Tính gợi ý đƣơc phân chia thành nhiều cấp độ khác nhau. Tri thức có thể hạn chế để chỉ cảm nhận thông tin hiện có và ngƣời dùng không cần phải nhớ những thông tin khác, ngoại trừ thông tin mà họ quan sát đƣợc.
Khả năng gợi ý đƣợc áp dụng rất nhiều trong các hệ thống tƣơng tác. Windows là một ví dụ điển hình, thí dụ các phím lệnh 3D rất có tính gợi ý, chỉ cần quan sát ngƣời dùng có cảm giác có thể nhấn phím. Xem ví dụ trong hình 2.8.
Hình 2.8 – Tính gợi ý trong window
2.6. Các lỗi giao diện ngƣời dùng
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ế? (adsbygoogle = window.adsbygoogle || []).push({});
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ý). (adsbygoogle = window.adsbygoogle || []).push({});
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,... (adsbygoogle = window.adsbygoogle || []).push({});
- 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