Nghiên cứu và đề xuất các phương pháp kiểm thử giao diện phần mềm

Kết quả nghiên cứu có thể làm tài liệu tham khảo về kiểm thử phần mềm, đồngthời hỗ trợ kiểm thử viên cũng như các nhà phát triển phần mềm có cơ sở để lựa chọnphương pháp hay công cụ kiểm

MỤC LỤC

LỜI CAM ĐOAN

DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ

CHƯƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1 Các khái niệm cơ bản

1.1.1 Lỗi phần mềm

1.2.2 Chi phí cho việc sửa lỗi

1.1.3 Kiểm thử phần mềm

1.2 Tiến trình kiểm thử phần mềm

1.2.1 Kiểm thử đơn vị

1.2.2 Kiểm thử tích hợp

1.2.3 Kiểm thử hệ thống

1.2.4 Kiểm thử hồi quy

1.2.5 Kiểm thử chấp nhận

1.3 Các phương pháp kiểm thử phần mềm

1.3.1 Kiểm thử hộp trắng

1.3.2 Kiểm thử hộp đen – Black box testing

1.3.3 Kiểm thử hộp xám

1.4 Các kỹ thuật kiểm thử cơ bản

1.4.1 Kiểm thử luồng điều khiển

1.4.2 Kiểm thử luồng dữ liệu

1.4.3 Kỹ thuật phân lớp tương đương

1.4.4 Kỹ thuật phân tích giá trị biên

1.4.5 Kỹ thuật đồ thị - nhân quả

1.5 Kiểm thử tự động

1.5.1 Kiến trúc kiểm thử tự động

1.5.2 Ưu và nhược điểm của kiểm thử tự động

1.5.2 Lựa chọn công cụ kiểm thử tự động

CHƯƠNG II – GIAO DIỆN VÀ CÁC VẤN ĐỀ CẦN QUAN TÂM

2.1.Khái niệm giao diện người dùng

2.2.Tại sao cần thiết kế giao diện

2.3.Các dạng giao tiếp người dùng - máy tính

2.3.1 Giao tiếp dòng lệnh

2.3.2 Giao tiếp bảng chọn

2.3.3 Giao tiếp bằng ngôn ngữ tự nhiên

2.3.4 Giao tiếp dạng hỏi đáp truy vấn

2.3.5 Giao tiếp dạng form-fill

2.3.6 Giao tiếp dạng WIMP

2.4.Tính tiện lợi của hệ thống tương tác

2.5.Nguyên lý thiết kế hệ thống có tính tiện lợi

2.5.1 Sự rõ ràng

2.5.2 Sự phản hồi

2.5.3 Tính ràng buộc

2.5.4 Tính ánh xạ

2.5.5 Tính nhất quán

2.5.6 Tính gợi ý

2.6.Các lỗi giao diện người dùng

2.6.1 Lỗi chức năng

2.6.2 Lỗi giao tiếp truyền thông

2.6.3 Lỗi cấu trúc lệnh

2.6.4 Thiếu lệnh

2.6.5 Lỗi thi hành

2.6.6 Đầu ra

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

3.2.Kiểm thử như thế nào

3.2.1 Nguyên tắc chung khi kiểm thử giao diện phần mềm

3.3.2 Chiến lược kiểm thử giao diện

3.3.Danh mục kiểm thử giao diện

3.3.1 Kiểm thử sự tuân thủ chuẩn Windows

3.3.2 Danh mục kiểm tra sự hợp thức hóa màn hình

3.3.3 Các hoạt động chuẩn

3.4.Kiểm thử giao diện tự động

3.4.1 Tạo kế hoạch kiểm thử giao diện cho công cụ kiểm thử giao diện tự động 63 3.4.2 Sử dụng công cụ kiểm thử giao diện tự động

3.4.3 Mười điều cần nhớ khi kiểm thử giao diện tự động

3.4.4 Các thủ thuật khi kiểm thử giao diện tự động

3.4.5 Một số vấn đề thường gặp với kiểm thử tự động

3.5.Đánh giá mức độ hài lòng người dùng

CHƯƠNG 4 – KIỂM THỬ GIAO DIỆN THEO PHÂN LOẠI PHẦN MỀM

4.1.Phân loại phần mềm

4.2.Kiểm thử giao diện phần mềm nghiệp vụ

4.3.Kiểm thử giao diện đối với phần mềm nhúng

4.3.1 Hệ thống nhúng và các đặc điểm cơ bản

4.3.2 Kiểm thử giao diện hệ thống nhúng

4.4.Kiểm thử giao diện đối với các ứng dụng Windows

4.5.Kiểm thử giao diện với các ứng dụng Web

4.5.1 Ứng dụng Web (Web Application)

4.5.2 Kiểm thử ứng dụng Web

4.5.3 Các công cụ kiểm thử giao diện tự động

CHƯƠNG 5 – ÁP DỤNG CÁC KỸ THUẬT KIỂM THỬ TRONG KIỂM THỬ GIAO DIỆN ỨNG DỤNG “PHẦN MỀM QUẢN LÝ BÁN HÀNG”

5.1.Giới thiệu ứng dụng “Phần mềm quản lý bán hàng”

5.1.1 Thành phần và chức năng

5.1.2 Mô-đun tiến hành kiểm thử giao diện

5.2.Lựa chọn phương pháp và kỹ thuật kiểm thử

5.2.1 Kiểm thử giao diện màn hình chính

5.2.2 Kiểm thử giao diện màn hình “Phiếu nhập hàng”5.3 Tiến hành kiểm thử giao diện ứng dụng KẾT LUẬN TÀI LIỆU THAM KHẢO

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

Thứ tự

12

DANH MỤC CÁC BẢNG

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

Bảng 5.1- Danh sách các ca kiểm thử với màn hình chính

Bảng 5.2 - Danh sách các ca kiểm thử với màn hình “Phiếu nhập hàng”

DANH MỤC CÁC HÌNH VẼ

Hình 1.1 - Chi phí sửa lỗi theo thời gian

Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V

Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác

Hình 1.4 – Kiểm thử hộp trắng

Hình 1.5 – Kiểm thử hộp đen

Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển

Hình 1.7 – Các ký hiệu trong CFG

Hình 1.8 – Các thành phần của một kiến trúc KTTĐ

Hình 2.1 – Mô hình cấu trúc UI

Hình 2.2 – Mô hình giao tiếp dòng lệnh trong window

Hình 2.3 – Mô hình giao tiếp Menu

Hình 2.4 – Giao tiếp form-fill

Hình 2.5 – Bảng tính

Hình 2.6 - Mô hình sự chấp nhận đƣợc của hệ thống

Hình 2.7 – Ví dụ về tính ràng buộc

Hình 2.8 – Tính gợi ý trong window

Hình 3.1 – Ứng dụng thỏa mãn sự đồng bộ Caption

Bảng 3.2 – Một số phím tắt và chức năng của chúng

Bảng 4.1 - So sánh giữa các ứng dụng Desktop, Client Server và Web

Hình 4.1 – Các thành phần giao diện của QTP

Hình 4.2 – Tạo Group trong AppPerfect

Hình 4.3 – Hỗ trợ thành phần Validation trong AppPerfect

Hình 4.4 – Định nghĩa tham số trong AppPerfect

Hình 4.5 – Phân tích kết quả kiểm thử với AppPerfect Test

Hình 4.6 – Lập lịch kiểm thử

Hình 5.1 – Mô-đun Hệ Thống

Hình 5.2 – Mô-đun Danh Mục

Hình 5.3 – Mô-đun Chức Năng

Hình 5.4 – Mô-đun Trợ Giúp

Hình 5.5 – Cấu trúc giao diện phần mềm Quản lý bán hàng

MỞ ĐẦU

Trong thởi đại công nghệ số hiện nay, ta có thể bắt gặp các sản phẩm công nghệ

ởtất cả các lĩnh vực: quân sự, y khoa, văn hóa nghệ thuật, đời sống xã hội,… Sự bùng

nổ của công nghệ thông tin và sự ra đời của Internet tác động to lớn tới bộ mặt xã hội.Nhu cầu trao đổi thông tin ngày càng tăng, việc sử dụng máy tính không đơn thuần làngười dùng thực thi chức năng chuyên biệt nào đó trong một lĩnh vực cụ thể, mà cóthể sử dụng trong tất cả các lĩnh vực, các ngành nghề, với những mục đích khác nhau:làm việc, nghiên cứu, học tập, giải trí, trao đổi thông tin, Và người dùng cũng khôngđơn thuần là một nhóm chuyên gia với trình độ nhất định, mà họ có thể là bất kỳ ai vớibất kỳ công việc, bất cứ trình độ, ở bất kỳ lứa tuổi nào Để có thể đáp ứng thị trườngrộng lớn, cực kỳ đa dạng đó, sản phẩm công nghệ thông tin nói chung cũng như côngnghệ phần mềm nói riêng, phải đảm bảo chất lượng tốt đồng thời cả chức năng hệthống lẫn giao diện người dùng Giao tiếp và chức năng là hai mặt tương hỗ và bổsung cho nhau Phần mềm có chức năng tốt đến đâu, mà giao diện tồi cũng sẽ gây khókhăn cho người dùng, làm giảm hiệu quả chức năng hệ thống Ngược lại, với giao tiếpđược thiết kế tốt, người dùng có thể dễ dàng sử dụng phần mềm và phát huy tối đahiệu quả chức năng hệ thống

Kiểm thử là một trong những giai đoạn của quá trình phát triển phần mềm.Trước khi sản phẩm được phát hành tất cả các chức năng cũng như giao diện củaphần mềm đều cần qua kiểm thử Giao diện tuy được thiết kế tốt nhưng cũng khôngthể tránh khỏi các sai sót Kiểm thử giao diện hiệu quả sẽ phát hiện ra được các sai sótnày, tránh các lỗi về giao diện khi phát hành sản phẩm Kiểm thử giao diện đứng dướivai trò của người sử dụng, sẽ giúp phần mềm có sự thích ứng phù hợp hơn với thị hiếu

và nhu cầu của người dùng Chính vì lẽ đó, kiểm thử giao diện phần mềm là việc hếtsức cần thiết, cần nghiên cứu về kiểm thử giao diện để tìm ra phương pháp kiểm thửhiệu quả phù hợp với ứng dụng phần mềm

Luận văn trình bày lý thuyết về giao diện phần mềm, lý thuyết kiểm thử phầnmềm, đi sâu vào kiểm thử giao diện phần mềm với phương pháp nghiên cứu theohướng từ khái quát tới chi tiết, lần lượt tìm hiểu các khái niệm, các phương pháp, cáccông cụ kiểm thử giao diện, Trên cơ sở đó, sẽ có đánh giá khách quan về việc lựachọn phương pháp hay công cụ kiểm thử giao diện phù hợp đối với ứng dụng đượcnghiên cứu

Kết quả nghiên cứu có thể làm tài liệu tham khảo về kiểm thử phần mềm, đồngthời hỗ trợ kiểm thử viên cũng như các nhà phát triển phần mềm có cơ sở để lựa chọnphương pháp hay công cụ kiểm thử giao diện phù hợp để kiểm thử ứng dụng đượcxây dựng

Luận văn bao gồm năm chương Chương 1 trình bày các lý thuyết tổng quan vềkiểm thử phần mềm: các khái niệm cơ bản, tiến trình kiểm thử phần mềm, các phươngpháp, kỹ thuật kiểm thử phần mềm Chương 2 trình bày các kiến thức về giao diện vàcác vấn đề cần lưu ý khi thiết kế và kiểm thử giao diện phần mềm Chương 3 tậptrung vào kiểm thử giao diện phần mềm, nêu các hướng giải quyết và các vấn đề cầnkiểm thử giao diện Chương 4 cũng nói về kiểm thử giao diện nhưng đi sâu vào từngloại ứng dụng phần mềm Chương 5 đưa ra ví dụ áp dụng các kiến thức đã được nêutrong bốn chương đầu để kiểm thử giao diện phần mềm “Quản lý bán hàng”.

CHƯƠNG I – TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1 Các khái niệm cơ bản

1.1.1 Lỗi phần mềm

 Khái niệm

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm (bug), nhưng nhìn chung,

có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không đồng nhất giữa chương trình với đặc tả của nó” Cụ thể là:

 Phần mềm không thực hiện đúng những gì đã nêu trong đặc tả

 Phần mềm thực hiện những hành vi mà đặc tả đã nêu không được thực hiện

 Phần mềm thực hiện những hành vi không được nêu trong đặc tả

 Phần mềm không thực hiện các yêu cầu không được nêu trong đặc tả, nhưng nên thực hiện nó

 Phần mềm khó hiểu, khó sử dụng,

 Các dạng lỗi phần mềm

 Sai sót (Error): Error là một trạng thái của hệ thống, là một sự nhầm lẫn hay sự hiểu sai trong quá trình phát triển phần mềm của người phát triển Error

có thể gây nên hỏng hóc hệ thống nếu không có các hành động khắc phục

 Lỗi (Fault / Defect): xuất hiện trong phần mềm như là kết quả của error

gây ra

 Hỏng hóc (Failure): Failure được coi là xảy ra khi các hành vi bên ngoài

hệ thống không thực hiện đúng như đặc tả hệ thống đã được quy định trước.

Nó là kết quả của một lỗi xuất hiện làm cho hệ thống không thể hoạt động hoặchoạt

động nhưng cho kết quả không như mong đợi

1.2.2 Chi phí cho việc sửa lỗi

Vòng đời phát triển phần mềm (chu trình phát triển phần mềm) được chia làm nhiều giai đoạn Bao gồm:

 Lập kế hoạch

 Thiết kế

 Kiểm thử và sửa lỗi

 Phát hành và bảo trì

Theo thống kê bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạtđộng chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí trong quá trình pháttriển ban đầu của sản phẩm phần mềm [6]

Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hànhkiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng.Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phầnmềm Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể trong quá trình

phát triển Trong tài liệu “Software Engineering” của Boehm (1976), có trích dẫn kết

quả nghiên cứu của IBM, GTE và TRW, tổng kết rằng lỗi được phát hiện càng muộnthì chi phí cho việc sữa lỗi càng lớn [6] Chi phí tăng theo hàm mũ như Hình 1.1:

Hình 1.1 - Chi phí sửa lỗi theo thời gianNhư vậy, có thể thể thấy kiểm thử là một khâu rất quan trọng trong quá trìnhphát triển phần mềm, kiểm thử càng sớm, càng chặt chẽ thì sẽ càng giảm được nhữngchi phí phát sinh không đáng có cho việc sửa lỗi

1.1.3 Kiểm thử phần mềm

Kiểm thử phần mềm là quá trình thực thi hệ thống phần mềm để xác định xemphần mềm có thực hiện đúng với đặc tả hay không và thực hiện trong môi trườngmong đợi hay không

 Xác minh: Chỉ ra sản phẩm có đáp ứng được các đặc tả yêu cầu hay không Được thực hiện mỗi khi kết thúc một pha trong quy trình sản xuất, nó

giúp quyết định xem sản phẩm có đáp ứng các yêu cầu tại thời điểm kiểm tra,trước khi bắt đầu pha kế tiếp

 Thẩm định: Chỉ ra sản phẩm có đáp ứng được yêu cầu người sử dụng hay

không Thực hiện khi kết thúc quá trình sản xuất, nhằm đảm bảo sản phẩm đãđược sản xuất là đúng như mong đợi

1.2 Tiến trình kiểm thử phần mềm

Kiểm thử được thực thi ở các mức khác nhau bao gồm cả hệ thống hoàn chỉnhhay các phần của hệ thống trong suốt chu trình phát triển phần mềm Một hệ thốngphần mềm phải trải qua bốn giai đoạn kiểm thử trước khi nó được triển khai Bốn giai

đoạn đó được biết như là bốn mức kiểm thử: unit, integration, system và acceptance.

Các giai đoạn kiểm thử tương ứng với các giai đoạn khác nhau trong tiến trình pháttriển phần mềm và được khái quát hóa qua mô hình chữ V – Hình 1.2 [7]

Hình 1.2 – Các giai đoạn phát triển và kiểm thử trong mô hình chữ V

Trong đó:

 Các yêu cầu: đưa ra các yêu cầu về sản phẩm

 Đặc tả chức năng: xây dựng phần mềm để đáp ứng với đề nghị.

 Thiết kế mức cao: kiến trúc hệ thống ở mức tổng thể.

 Thiết kế mức thấp (mức chi tiết): chi tiết các đặc tả của các mô-đun trong kiến trúc.

 Lập trình: mã hóa các mô-đun.

1.2.1 Kiểm thử đơn vị

Kiểm t hử đơn vị là mức thấp nhất của kiểm thử trong mô hình chữ V Giai đoạnnày được thực hiện bởi các lập trình viên Họ chia nhỏ và kiểm thử từng đơn vịchương trình, như các thủ tục, các hàm, các phương thức, hay các lớp Mục đích của

kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất là chính xác, trong mốitương quan với dữ liệu nhập và chức năng của đơn vị đó Điều này thường đòi hỏi tất

cả các nhánh bên trong đơn vị, từng mô-đun đều phải được kiểm tra để phát hiệnnhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong mộtđơn vị Thực tiễn đã chỉ ra rằng, việc phát hiện sớm các lỗi ở mức kiểm thử đơn vị sẽgiảm được rất nhiều chi phí cho kiểm thử ở các mức sau đó

1.2.2 Kiểm thử tích hợp

Sau khi kết thúc quá trình kiểm thử đơn vị, các mô-đun được tích hợp lại tạothành hệ thống con có cấu trúc lớn hơn, đồng thời cần tiến hành kiểm thử tích hợp.Kiểm thử tích hợp được thực thi với sự kết hợp của cả lập trình viên và các kỹ sưkiểm thử tích hợp Kết quả khi kết thúc giai đoạn kiểm thử tích hợp là dựng nên một

hệ thống ổn định, hợp lý, có thể chịu được những rung động ở mức kiểm thử hệ thống.Mục tiêu chính của kiểm thử tích hợp đó là:

 Phát hiện lỗi tương tác giữa các đơn vị

 Tích hợp các đơn vị thành hệ thống con và hệ thống hoàn chỉnh để chuẩn bịcho kiểm thử ở mức hệ thống

Các kỹ thuật kiểm thử áp dụng ở mức kiểm thử tích hợp:

 Kiểm thử cấu trúc: kiểm thử cấu trúc mã nguồn hệ thống.

 Kiểm thử chức năng: kiểm thử sự đáp ứng tốt các chức năng đặc tả của hệ

thống

 Kiểm thử hiệu năng: Kiểm thử việc vận hành của hệ thống.

 Kiểm thử khả năng chịu tải: Kiểm thử hoạt động của hệ thống dưới áp lực

về tải hay điều kiện môi trường.

Để tích hợp các mô-đun của hệ thống, tùy từng hệ thống mà kiểm thử viên lựachọn chiến lược tích hợp phù hợp Có ba kiểu chiến lược phổ biến nhất, đó là: Tích

hợp từ trên xuống (Top – Down), tích hợp từ dưới lên (Bottom – Up), và chiến lược

BigBang

1.2.3 Kiểm thử hệ thống

Kiểm thử hệ thống là một giai đoạn quyết định trong tiến trình phát triển phầnmềm, bởi vì cần thiết phải lên lịch chặt chẽ ngày phát hành, cần phát hiện hầu hết cáclỗi, và kiểm tra việc gỡ lỗi đang thực hiện, đảm bảo không phát sinh lỗi mới Kiểm thử

hệ thống bao gồm các hoạt động khác nhau: lập kế hoạch kiểm thử, thiết kế bộ kiểm

thử, chuẩn bị môi trường kiểm thử, thực thi kiểm thử theo một chiến lược rõ ràng, vàkiểm tra quá trình thực thi kiểm thử.

Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hìnhthành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trìnhviên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh.Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phântích các yêu cầu

Kiểm thử hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn cácyêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềmhoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng

bộ nhớ Sau giai đoạn này, phần mềm thường đã sẵn sàng cho khách hàng hay người

dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Các kỹ thuật kiểm thử áp dụng cho kiểm thử hệ thống:

 Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.

 Kiểm thử hiệu năng: Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví

dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng các truy vấn.

 Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Kiểm thử tập trung vào các

trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giaodịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM )

 Kiểm thử cấu hình: Quá trình kiểm thử hệ thống với mỗi cấu hình của phần mềm và phần cứng được hỗ trợ.

 Kiểm thử bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ

thống

 Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; nó

đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

1.2.4 Kiểm thử hồi quy

Kiểm thử hồi quy là một mức khác của kiểm thử mà được thực hiện trong suốtquá trình phát triển hệ thống Mỗi khi một thành phần nào đó của hệ thống có sự thayđổi, cần tiến hành kiểm thử hồi quy Mục đích chính trong kiểm thử hồi quy đó là đảm

bảo không phát sinh lỗi mới trong các thành phần không có sự thay đổi Rõ ràng kiểmthử hồi quy không phải một mức kiểm thử riêng biệt trong tiến trình kiểm thử Mốiquan hệ giữa nó với các mức kiểm thử khác trong mô hình chữ V được thể hiện quaHình 1.3 [7].

Hình 1.3 – Kiểm thử hồi quy tại các mức kiểm thử phần mềm khác

1.2.5 Kiểm thử chấp nhận

Sau khí quá trình kiểm thử hệ thống kết thúc, phần mềm được phân phát tớikhách hàng Khách hang sẽ tiến hành một loạt các kiểm thử của họ, thường được biếtđến là kiểm thử chấp nhận Yếu tố quan trọng nhất trong kiểm thử chấp nhận chính làmức độ hài lòng của người dùng với hệ thống

1.3 Các phương pháp kiểm thử phần mềm

1.3.1 Kiểm thử hộp trắng

Kiểm thử hộp trắng, còn biết tới như kiểm thử cấu trúc hay kiểm thử hướnglogic, cho phép kiểm tra tất cả cấu trúc bên trong của phần mềm với mục đích đảm bảotất cả các câu lệnh và các điều kiện sẽ được thực hiện ít nhất một lần Kiểm thử viêntruy nhập vào mã nguồn chương trình và lấy đó làm cơ sở kiểm thử, họ hoàn toàn nắmđược cấu trúc lệnh bên trong của hệ thống (Hình 1.4) Trong kiểm thử hộp trắng, tậptrung vào kiểm thử luồng điều khiển và kiểm thử luồng dữ liệu

Hình 1.4 – Kiểm thử hộp trắng

Các kỹ thuật kiểm thử:

 Kiểm thử luồng điều khiển

 Kiểm thử luồng dữ liệu

Kiểm thử luồng dữ liệu là phương pháp lựa chọn đường dẫn kiểm thử của chương trình dựa vào vị trí khai báo và sử dụng các biến trong chương trình

Ưu, nhược điểm:

Kiểm thử hộp trắng chỉ dựa trên mã nguồn chương trình để kiểm thử, do đó tiếtkiệm được thời gian và chi phí cài đặt phần mềm Đây là phương pháp kiểm thử đơngiản nhất, và cũng sớm phát hiện ra lỗi của chương trình ngay trong cấu trúc dònglệnh Nó giúp hạn chế các lỗi tiềm ẩn sẽ phát sinh khi cài đặt và sử dụng chương trình

Nhược điểm chính của kiểm thử hộp trắng là không thể phát hiện hết các lỗiphát sinh khi chạy chương trình Kiểm thử hộp trắng thiếu tính khách quan, kiểm thửviên cũng là người lập trình mà không đứng trên vai trò người sử dụng

1.3.2 Kiểm thử hộp đen – Black box testing

Kiểm thử hộp đen còn được biết tới với các tên gọi khác như kiểm thử chức năng(function testing), kiểm thử hướng dữ liệu (data driven) hay kiểm thử hướng vào ra(input/output driven) Trong kỹ thuật này, kiểm thử viên coi phần mềm như một hộp đen,hoàn toàn không quan tâm tới cấu trúc và hành vi bên trong hệ thống – Hình 1.5 Với bộ

dữ liệu đầu vào, họ chỉ quan tâm đầu ra sẽ là gì, có đúng như đặc tả hay không Kiểm thửhộp đen tập trung vào các yêu cầu chức năng của hệ thống Kiểm thử hộp đen không thaythế kiểm thử hộp trắng, nó kết hợp với kỹ thuật kiểm thử hộp trắng, bổ sung các khả năngphát hiện các lớp lỗi khác với các phương pháp kiểm thử khác

Hình 1.5 – Kiểm thử hộp đenKiểm thử hộp đen cố gắng phát hiện các loại lỗi sau:

 Các chức năng thiếu hoặc không đúng với đặc tả

 Các lỗi truy cập cơ sở dữ liệu bên ngoài

 Các lỗi giao diện

 Các lỗi thi hành

 Các lỗi khi khởi tạo hoặc kết thúc

Các kỹ thuật kiểm thử hộp đen

 Phân lớp tương đương

 Phân tích giá trị biên

Mặt khác kiểm thử viên không biết các phần mềm thực sự được xây dựng nhưthế nào, do đó có thể kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra mộtthứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, trong khi

đó một số phần của chương trình lại bị bỏ sót không được kiểm thử

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặtkhác nó lại có nhược điểm của “thăm dò mù”.

1.3.3 Kiểm thử hộp xám

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuậtbên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mứcngười sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng dữliệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra

rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sựkhác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp giữa 2 mô-đun mãlệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là đượcđưa ra để kiểm thử Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu đểquyết định, ví dụ, giá trị biên hay thông báo lỗi

1.4 Các kỹ thuật kiểm thử cơ bản

1.4.1 Kiểm thử luồng điều khiển

Có hai loại câu lệnh cơ bản trong một đơn vị chương trình, đó là: lệnh chỉ định

(assignment statement) và lệnh điều kiện (condition statement) Lệnh chỉ định là những lệnh được biểu diễn bằng ký tự chỉ định “ = ” Ví dụ như: x = 2 *y, trong đó x,

y đều là biến Lệnh điều kiện là các lệnh có chứa các lệnh điều khiển, như if(), lặp for(), lặp while(), goto Trường hợp không có lệnh điều khiển, các lệnh chương trình

được thực hiện theo trình tự mà nó xuất hiện Sự thành công khi thi hành một lệnhchương trình bắt nguồn từ luồng điều khiển của đơn vị đó

Đồ thị luồng điều khiển (control flow graph - CFG) là đồ thị có hướng, biểu

diễn một chương trình, với:

 Đỉnh: biểu diễn một lệnh tuần tự hay một khối lệnh

 Cung: biểu diễn các nhánh rẽ của lệnh điều kiện

 Một đỉnh vào và một đỉnh ra được thêm vào để biểu diễn điểm vào và ra của chương trình

Lộ trình trong CFG là đường đi xuất phát từ đỉnh vào, đi qua các đỉnh và cungtrong đồ thị và kết thúc ở đỉnh ra Chu trình tạo dữ liệu đầu vào kiểm thử cho kiểm thửluồng điều khiển được mô tả trong lưu đồ dưới đây – Hình 1.6

Hình 1.6 – Chu trình sinh dữ liệu đầu vào kiểm thử cho kiểm thử luồng điều khiển

 Lựa chọn đường đi: đường đi được lựa chọn từ CFG phải thỏa mãn tiêu chuẩn lựa chọn đường và dựa trên cấu trúc của CFG

 Sinh dữ liệu đầu vào kiểm thử: Có hai loại đường đi trong kiểm thử luồng điều khiển:

o Đường đi được (feasible path)

o Đường không đi được (infeasible path)

 Các ký hiệu trong CFG – Hình 1.7

Hình 1.7 – Các ký hiệu trong CFG

Tiêu chuẩn lựa chọn đường đi (Path selection criteria)

 Phủ tất cả các đường: tất cả các đường đi (bao gồm cả các đường điđược và không đi được) đều được lựa chọn.

 Phủ lệnh: Lựa chọn các đường đi sao cho tất cả các lệnh được chạy

1.4.2 Kiểm thử luồng dữ liệu

Ít nhất một nửa mã nguồn chương trình bao gồm các lệnh khai báo dữ liệu, nhưlà: định nghĩa cấu trúc dữ liệu, các đối tượng riêng, giá trị mặc định ban đầu và cácthuộc tính Lỗi dữ liệu là lỗi phổ biến nhất trong các lỗi mã nguồn, do đó kiểm thửluồng dữ liệu là kỹ thuật không thể thiếu trong kiểm thử cấu trúc

Một đơn vị chương trình chấp nhận đầu vào, thực hiện tính toán, gán giá trị mớicho biến, và trả về kết quả Phương pháp kiểm thử luồng dữ liệu chọn lựa một sốđường diễn tiến của chương trình dựa vào việc cấp phát, định nghĩa, và sử dụngnhững biến trong chương trình

Có hai mức kiểm thử luồng dữ liệu:

 Kiểm thử luồng dữ liệu tĩnh: kỹ thuật này tập

trung thường được biết đến như luồng dữ liệu bất

thường thường khi sử dụng biến:

xác định lỗi tiềm năng,

Ba loại tình huống bất

o Loại 1: Đã được khai báo nhưng sau đó lại được khai báo lại

o Loại 2: Không được khai báo nhưng lại được tham chiếu tới

o Loại 3: Được khai báo nhưng không được tham chiếu

 Kiểm thử luồng dữ liệu động: liên quan tới việc thực thi chương trình thực tế

Kỹ thuật này tương tự như kiểm thử luồng điều khiển: Cần xác định đường đi

để thi hành, và đường đi được lựa chọn dựa trên tiêu chuẩn kiểm thử luồng dữliệu Các bước cơ bản:

o Vẽ đồ thị luồng dữ liệu (Data flow graph - DFG)

o Chọn một hay nhiều tiêu chuẩn kiểm thử luồng dữ liệu

o Xác định đường đi trong DFG đáp ứng tiêu chuẩn đã chọn

o Rút ra các biểu thức vị từ từ các path được lựa chọn

o Giải các biểu thức vị từ thu được đầu vào kiểm thử

1.4.3 Kỹ thuật phân lớp tương đương

Việc kiểm thử tất cả các đầu vào của chương trình là không thể Vì thế, khikiểm thử chương trình nên giới hạn một tập con tất cả các trường hợp đầu vào có thể

có Một tập con như vậy cần có hai tính chất:

 Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết

 Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một

số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểmthử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giátrị bất kỳ trong cùng lớp

Hai vấn đề xem xét ở trên tạo thành một phương pháp của kỹ thuật hộp đen và gọi là phân hoạch tương đương

Các bước thực hiện trong kỹ thuật phân lớp tương đương – gồm ba bước:

 Đối với mỗi dữ liệu vào, xác định các lớp tương đương từ miền dữ liệu vào

 Chọn dữ liệu đại diện cho mỗi lớp tương đương

 Kết hợp các dữ liệu thử bởi tích Đề-các để tạo ra bộ dữ liệu kiểm thử

Nguyên tắc phân hoạch lớp tương đương:

 Nếu dữ liệu vào thuộc một

khoảng, xây dựng: o Một lớp các giá trị

o “n” lớp hợp lệ

 Nếu dữ liệu là điều kiện ràng buộc, xây dựng:

o Một lớp với điều kiện ràng buộc được thỏa mãn

o Một lớp với ràng buộc không được thỏa mãn

1.4.4 Kỹ thuật phân tích giá trị biên

Lỗi phần mềm thường xuất hiện gần các giá trị biên của miền dữ liệu đầu vào,

do đó tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểmthử

Nguyên tắc kiểm thử dữ liệu vào gồm:

Nguyên tắc chọn dữ liệu kiểm thử:

 Nếu dữ liệu vào thuộc một

khoảng, chọn: o Hai giá trị biên

o Bốn giá trị test = giá trị biên ± sai số nhỏ nhất

 Nếu dữ liệu vào thuộc danh sách các giá trị, chọn:

o Bốn giá trị test gồm: phần tử đầu tiên, phần tử thứ hai, phần tử kề cuối và phần tử cuối

 Nếu dữ liệu vào là điều kiện ràng buộc số giá trị, chọn:

o Số giá trị tối thiểu, số giá trị tối đa và một số các giá trị không hợp lệ

 Tự vận dụng khả năng và thực tế để chọn các giá trị biên cần kiểm thử

1.4.5 Kỹ thuật đồ thị - nhân quả

Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sởđưa ra một sự mô tả xúc tích các điều kiện logic và các hành vi kèm theo Phươngpháp này sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thànhphần phần mềm Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai)

của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện.

Đồ thị nhân - quả được tạo như sau:

 Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt

kê dựa trên đặc tả và được định danh cho mỗi nhân – quả

 Các quan hệ giữa các nguyên nhân (đầu vào) và các kết quả (đầu ra) được biểu diễn trong đồ thị để làm rõ ràng các quan hệ logic

 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân

và kết quả Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này

1.5 Kiểm thử tự động

Kiểm thử tự động (KTTĐ) là quá trình mà các bước kiểm thử lặp đi lặp lạiđược thực hiện bởi các công cụ kiểm thử phần mềm như Winrunner, Load runner,QTP,…, sử dụng đầu vào của các test case và dự đoán kết quả đầu ra dưới môi trườngđược kiểm soát KTTĐ thường được áp dụng trong kiểm thử hồi quy Kiểm thử hồiquy được tiến hành lặp lại mỗi khi hệ thống có các sự thay đổi lớn, nó tìm ra các lỗiphát sinh khi hệ thống có những sự thay đổi hay trong quá trình khắc phục các lỗi kháccủa hệ thống

Tự động hóa kiểm thử có thể thay thế kiểm thử thủ công hay không?

Kiểm thử thủ công là quá trình mà chức năng của ứng dụng được kiểm thử dướicác môi trường khác nhau và các điều kiện cho nó được chỉ định chức năng, giao diện,tính dễ sử dụng, hiệu năng, khả năng bảo mật,… bởi kiểm thử viên, với các đầu vào đượcyêu cầu từ nhóm phát triển ứng dụng và các tài liệu ứng dụng có tính chất khác nhau

Kiểm thử thủ công vừa có ưu điểm vừa có nhược điểm Kiểm thử đặc biệt (Ad hoc

testing) có thể thực hiện bằng kiểm thử thủ công, nó hầu như luôn cần thiết như chức

năng của ứng dụng và được hiểu rõ hơn bởi một kiểm thử viên Thực tế cho thấy, ad hoctesting phát hiện ra nhiều lỗi hơn KTTĐ Nhược điểm của kiểm thử thủ công là phải chạylại nhiều lần một kiểm thử khi xây dựng phức tạp gây mệt mỏi đối với mọi nỗ lực củakiểm thử viên, và rất dễ xảy ra các lỗi slipping không được chú ý

Một trong những ưu điểm khi so sánh kiểm thử tự động với kiểm thử thủ công

đó là các công cụ kiểm thử sẽ không cảm thấy mệt mỏi trong quá trình kiểm thử lặp đilặp lại như con người Tuy nhiên KTTĐ là một quy trình tốn kém hơn khi so sánh vớikiểm thử thủ công KTTĐ yêu cầu hiểu biết về công việc với các công cụ kiểm thử.Xây dựng các ca kiểm thử và kiểm thử các framework tốn nhiều thời gian hơn kiểmthử thủ công Trường hợp ứng dụng lớn, được phát triển trên nhiều nền tảng hay đa

ngôn ngữ người dùng và cần lặp lại nhiều lần quá trình kiểm thử thì sẽ hiệu quả hơnnếu áp dụng KTTĐ.

KTTĐ không hoàn toàn thay thế kiểm thử thủ công, mục đích của KTTĐ làgiảm các hoạt động kiểm thử thủ công và các hoạt động kiểm thử dư thừa bằng cách

sử dụng một giải pháp có hệ thống để đạt được một phạm vi và độ bao phủ các trườnghợp kiểm thử tốt hơn, giảm chi phí và thời gian kiểm thử trong suốt vòng đời phầnmềm Qua đó nâng cao chất lượng, tăng độ tin cậy, tăng hiệu quả của quá trình kiểmthử, giải phóng các kỹ sư kiểm thử phần mềm khỏi việc thực hiện các công việc lặp lạinhàm chán

1.5.1 Kiến trúc kiểm thử tự động

Kiến trúc tự động hóa kiểm thử, hay một framework, bao gồm các công cụkiểm thử, thiết bị, các kịch bản kiểm thử, tiền điều kiện, và người điều khiển để hệthống tự động kiểm thử có tác dụng và hiệu quả Tạo và duy trì một framework KTTĐ

là chìa khóa cho thành công của các dự án KTTĐ trong mỗi tổ chức Sự thi hành mộtframework tự động thông thường bao gồm các nhóm KTTĐ: nhóm kiểm thử phát triển

(Development Test Group), nhóm kiểm thử hiệu năng (Performance Test Group), nhóm kiểm thử khả năng mở rộng (Scalability Test Group), nhóm kiểm thử tự động (Automation Test Group), nhóm kiểm thử khả năng chống đỡ (Sustaining Test Group).

Mỗi framework KTTĐ bao gồm 6 thành phần như trong Hình 1.8 dưới đây:

Hình 1.8 – Các thành phần của một kiến trúc KTTĐ

Hệ thống được kiểm thử (System to be tested): Đây là thành phần đầu tiên của

một kiến trúc tự động Các hệ thống con của hệ thống được kiểm thử phải vững chắc

ổn định Nếu không, tự động hóa kiểm thử sẽ không có hiệu quả Tất cả các hệ thống

con trong hệ thống phải bền vững và làm việc với nhau chặt chẽ trước khi bắt đầu một

dự án KTTĐ

Nền tảng kiểm thử (Test platform): là nền tảng hay các điều kiện thuận lợi mà

trên đó hệ thống sẽ được kiểm thử

Thư viện các ca kiểm thử (Test case Library): Nó hữu ích để biên dịch các

thư viện của các bước kiểm thử có thể tái sử dụng của các tiện ích cơ bản được dùng

như các khối được xây dựng trong các kịch bản KTTĐ Mỗi tiện ích thường thi hànhmột nhiệm vụ riêng hỗ trợ tính tự động hóa của ca kiểm thử

Bộ thực thi kiểm thử tự động (Automated Testing Practices): Các thủ tục mô

tả các ca kiểm thử sử dụng công cụ kiểm thử và các thư viện test case đã được tài liệuhóa như thế nào Một khuôn mẫu ca kiểm thử tự động nhất quán trên tất cả các cakiểm thử tự động được phát triển bởi các kỹ sư khác nhau

Công cụ (Tools): Việc phát triển các kịch bản kiểm thử khác nhau yêu cầu các

loại công cụ khác nhau Các công cụ hỗ trợ bao gồm nhà máy kiểm thử, bộ phân tíchyêu cầu, bộ theo dõi các khuyết điểm, công cụ quản lý cấu hình Sự tích hợp của công

cụ KTTĐ và công cụ hỗ trợ như defect tracking sẽ quyết định báo cáo tự động các

nhược điểm của các ca kiểm thử hỏng

Bộ điều hành (Administrator): Bộ điều hành framework tự động quản lý các

thư viện ca kiểm thử, các nền tảng, và các công cụ kiểm thử; duy trì bảng kiểm kê củacác mẫu thử; cung cấp các hướng dẫn; và giúp cho kiểm thử viên sử dụng các thư viện

ca kiểm thử để viết kịch bản kiểm thử Thêm vào đó, bộ điều hành còn cung cấp cáchướng dẫn hỗ trợ người dùng của các công cụ kiểm thử và duy trì mối liên hệ giữa cácnhà cung cấp công cụ và người dùng

Kiến trúc tự động hóa đảm bảo:

 Các công cụ kiểm thử khác nhau và các thiết bị kết hợp làm việc chặt chẽ với nhau

 Thư viện của các kịch bản ca kiểm thử được tái sử dụng cho các dự án kiểm thử khác nhau, như vậy sẽ giảm được công sức phát triển bị nhân lên

 Tạo sự nhất quán trong cách viết kịch bản kiểm thử của các kiểm thử viên, không ai được viết script theo cách chỉ của riêng mình họ

 Tính nhất quán được duy trì trong toàn bộ các kịch bản kiểm thử

 Quy trình tự động hóa bộ kiểm thử được kết hợp và sẵn dùng cho mỗi lần kiểm thử hồi quy

 Con người hiểu được sự phản hồi của hệ thống trong KTTĐ.

1.5.2 Ưu và nhược điểm của kiểm thử tự

động Ưu điểm:

 Không cần sự can thiệp của kiểm thử viên

 Việc viết script đơn giản và có thể tái sử dụng, ngoại trừ một số trường hợpứng dụng phức tạp

 Giảm chi phí khi thực hiện khi cần kiểm thử số lượng lớn ca kiểm thử hoặc

ca kiểm thử lặp lại nhiều lần

 Có thể giả lập các tình huống khó thực hiện được bằng tay

 Phát hiện nhanh các lỗi trong quá trình kiểm thử khi có những sự thay đổi

 Tốn chi phí cho việc bảo trì và chỉnh sửa các script

 Việc xây dựng các nguyên lý chức năng trong scripts với các ứng dụng phức tạp có thể gây mệt mỏi, nhàm chán

 Phụ thuộc dữ liệu đầu vào thủ công cho dù các scipt có thể tái sử dụng

1.5.2 Lựa chọn công cụ kiểm thử tự động

Có rất nhiều công cụ KTTĐ với các ưu và nhược điểm khác nhau Mỗi ứngdụng phần mềm hay các ứng dụng web lại được xây dựng trên một nền tảng vớinhững đặc điểm riêng Vì thế việc lựa chọn công cụ kiểm thử cho phù hợp không hềđơn giản Trong tương lai, với sự phát triển không ngừng của công nghệ phần mềm,vai trò của kiểm thử được đánh giá cao hơn, sẽ cần những đội ngũ chuyên gia chuyênnghiên cứu và tìm ra bộ công cụ kiểm thử phù hợp với từng sản phẩm phần mềm

Dưới đây là các tiêu chí cơ bản, có thể dựa trên đó để lựa chọn công cụ kiểmthử phù hợp với ứng dụng cần kiểm thử

1.5.1.1 Tiêu chí 1: Mục tiêu nhóm kiểm thử

Mục tiêu của nhóm kiểm thử là một trong những chìa khóa cho mọi thành công.Nếu nhóm là một phần của đội QA hay R&D, onsite hay offshore, tất cả các thông số

sẽ ảnh hưởng tới giao diện mà các tester sẽ cần từ hệ thống, đầu ra, báo cáo, cấu hình,

…

Lựa chọn công cụ kiểm thử tốt là cách lựa chọn sao cho hệ thống kết hợp tốtvới các thành phần xung quanh, đảm bảo phương pháp làm việc mới là ít nhất Cáchthức làm việc của nhóm, sẽ tác động tới khả năng viết kịch bản (scripting) của công cụ,trong một số trường hợp, script có hiệu quả tốt hơn, và nếu không, cần xem xét lạinhóm kiểm thử, môi trường và phương pháp làm việc

1.5.1.2 Tiêu chí 2: Nền tảng và ứng dụng hỗ trợ

Công cụ kiểm thử phải phù hợp và tương thích với các công cụ phát triển cũngnhư công cụ kiểm soát chất lượng được dùng trong tổ chức Sự tương thích này đảmbảo toàn bộ quá trình kiểm thử sẽ được kết hợp nhuần nhuyễn với quá trình phát triểnphần mềm và dễ dàng hơn cho nhóm phát triển cũng như nhóm kiểm thử Ngược lại,

sẽ gây khó khăn trong quá trình xây dựng và phát triển kịch bản kiểm thử

Kiểm tra nền tảng mà các sản phẩm công ty đang chạy trên đó Công cụ kiểmthử cũng phải chạy trên cùng nền tảng đó Windows, Linux, Mobile là một vài ví dụ vềplatform tồn tại trên thị trường hiện nay Kiểm thử ứng dụng, kiểm thử web, kiểm thửserver,… thường đều cần sự hỗ trợ đặc biệt của các công cụ kiểm thử, có nghĩa là nó

sẽ có khả năng điều khiển luồng hoạt động và đầu ra của ứng dụng

1.5.1.3 Tiêu chí 3: Các kiểu kiểm thử

Không nhiều công cụ KTTĐ có thể thực hiện tất cả các kiểu kiểm thử vàphương pháp kiểm thử, cũng có một số linh hoạt hơn Lựa chọn tool theo kiểu kiểmthử mà ứng dụng cần, trong một vài trường hợp ứng dụng đang làm việc với nhiềugiao diện người dùng, GUI, Web, Linux, giao diện Java, các ứng dụng qua bên thứ 3.Đôi khi tổ chức chế độ làm việc cần thích hợp hơn, như kiểm thử chức năng, kiểm thửđơn vị, kiểm thử chấp nhận làm việc đứng trên vai trò khách hàng,…

Phân tích môi trường hoạt động, sẽ cho biết cần kiểu kiểm thử nào Sau khi xácđịnh được các kiểu kiểm thử cần tiến hành, sắp xếp mức độ ưu tiên và mức độ quantrọng của chúng Không phải mọi công cụ đều hỗ trợ tất cả các kiểu kiểm thử, nên phảiđảm bảo chúng sẽ hỗ trợ những loại có mức ưu tiên cao, nếu chúng làm việc, và đã lựachọn được một framwork tự động, sẽ có thể xây dựng được những hỗ trợ cần thiết cònlại

1.6.1.4 Tiêu chí 4: Khả năng lập trình

Một vài công cụ có khả năng viết kịch bản, một số không, một số có cả hai lựachon Dựa trên khả năng lập trình của nhóm kiểm thử và nhu cầu sử dụng chức năngtạo kịch bản của công cụ kiểm thử mà lựa chọn công cụ phù hợp Viết kịch bản KTTĐyêu cầu khả năng lập trình và có thể khó khăn đối với các kiểm thử viên ít kinh

nghiệm Từ trình độ của nhóm kiểm thử viên mà quyết định lựa chọn công cụ cho hợplý.

Nếu quyết định hướng công cụ KTTĐ có khả năng tạo script, cần lựa chọncông cụ được phát triển với ngôn ngữ tương đồng với hầu hết người dùng Ví dụ, nếuhầu hết kiểm thử viên hay lập trình viên biết nhiều về Java, thì nên lựa chọn công cụKTTĐ với khả năng lập trình bằng Java Khi đó, không chỉ nhận được một công cụ

mà hầu hết mọi người đều biết cách xử lý, nếu mọi người quen với ngôn ngữ lập trình

đó, việc phát triển và bảo trì sẽ nhanh hơn và tin cậy hơn

Nếu quyết định chọn công cụ KTTĐ không có khả năng viết script, cần phải thửkhả năng giao diện của nó, các phương pháp thiết kế kiểm thử khác như là: thiết kếMoular trực quan, thiết kế Keyword Driven, ghi lại lịch sử người dùng, hay khả năngghi âm Các kịch bản KTTĐ rất hữu ích ngay cả khi công cụ KTTĐ cung cấp nhữngcách thức dễ dàng để KTTĐ, bởi vì script thường cung cấp tính năng mạnh mẽ hơn,

nó cho phép thi hành những hành động mà các kiểu KTTĐ không thực hiện được

Một lưu ý trước khi lựa chọn công cụ với khả năng tạo script hay không, đó làcông cụ đó cần có sẵn sự hỗ trợ tốt về trợ giúp, các tài liệu tham khảo hay các diễn đàntrao đổi Các thông tin này sẽ rất hữu ích và giúp kiểm thử viên tiếp cận và sử dụngcông cụ được thuận lợi hơn

1.6.1.5 Tiêu chí 5: Khả năng ghi sự kiện

Hiện nay trên thị trường có hai loại ghi âm (ghi sự kiện) Loại thứ nhất là kiểughi lại các bước kịch bản, công cụ KTTĐ bật trạng thái ghi, sau đó tester thực hiệntheo luồng kịch bản Khi kết thúc quá trình ghi sẽ có một mô tả đầy đủ về scenario.Ngày nay loại hình ghi âm này có thể chơi, không chỉ mô tả script, không chỉ mô tả lạiGUI / blocks Loại hình ghi âm thứ 2, đó là ghi âm thành video Tester thực hiện kịchbản kiểm thử và phát hiện ra một khiếm khuyết hay những thứ có thể gây ra khiếmkhuyết, loại hình ghi âm này sẽ tạo ra một tệp tin movie từ chính luồng hoạt động củakịch bản

1.6.1.6 Tiêu chí 6: Công nghệ ứng dụng

Cho dù bạn đang kiểm thử giao diện hay kiểm thử Web, đảm bảo hệ thốngKTTĐ, sẽ biết làm thế nào để vận hành kiểm soát một cách đáng tin cậy nhất Dù ứngdụng cần kiểm thử giao diện là ứng dụng web hay phần mềm nghiệp vụ,… khi KTTĐphải biết làm thế nào để vận hành kiểm soát một cách đáng tin cậy nhất Một sốtrường hợp, ứng dụng không có bất kỳ giao diện GUI nào hay chỉ một phần GUI hoạtđộng, trong trường hợp đó xem xét phương pháp làm việc của kiểm thử viên, lựa chọnlàm việc kết hợp hay thông qua các công cụ của bên thứ ba, cũng có thể coi như kiểmthử thủ công

Công cụ KTTĐ phải hỗ trợ công nghệ ứng dụng, nhưng đồng thời cũng phải hỗtrợ phương pháp làm việc của kiểm thử viên Công cụ KTTĐ phải hỗ trợ, cho kiểmthử GUI, tất cả các điều khiển chuẩn hay không chuẩn để kích hoạt chúng và phân tíchkết quả trả về.

1.6.1.7 Tiêu chí 7: Nguồn dữ liệu kiểm thử

Trong nhiều trường hợp cần thiết phải kiểm thử dữ liệu các trường, cùng mộtscenario nhưng có thể có nhiều dữ liệu đầu vào khác nhau, việc kiểm thử nguồn dữliệu hay tích hợp nguồn dữ liệu là cần thiết, triệt để kiểm thử các nguồn dữ liệu khácnhau để đảm bảo quá trình xử lý của ứng dụng chính xác Khi lựa chọn công cụKTTĐ, cần kiểm tra xem định dạng dữ liệu nó có thể sử dụng, như file text, XML,bảng cơ sở dữ liệu hay các dạng khác Hầu hết các trường hợp này kiểm thử viên đều

có thể tự thực hiện, tuy nhiên nếu có sự hỗ trợ của công cụ KTTĐ, có thể tiết kiệmđược nhiều thời gian ngay từ khi bắt đầu Các hoạt động này luôn có hai chi phí chính:

chi phí tức thì (Immediate) và chi phí tiếp diễn (Continued) Chi phí tức thì là chi phí

cho tài nguyên khi bắt đầu tạo và kích hoạt hành động tích hợp, chi phí tiếp diễn là chiphí để duy trì và cập nhật về sau

1.6.1.8 Tiêu chí 8: Thực thi kiểm thử tự động

Ngày nay chúng ta muốn thấy được quá trình phát triển, ngay cả thời gian chạynếu có thể, và quá trình kiểm thử là một phần trong quy trình phát triển và triển khaiphần mềm Nắm bắt được xu hướng này, rất nhiều tổ chức phát triển công cụ KTTĐ

đã phát triển tính năng này cho công cụ Để có thể lựa chọn công cụ phù hợp, cần thựchiện một số bước kiểm tra dưới đây

Trước tiên, kiểm tra khả năng tích hợp vào hệ thống kiểm thử hay quản lý dự

án Sau đó, quyết định sẽ thực thi nó tại đâu, các lựa chọn có thể là:

 Từ giao diện công cụ (tool interface)

 Từ giao diện công cụ quản lý kiểm thử (Test Management tool interface)

 Được liệt kê thông qua ứng dụng desktop khác

Mỗi trường hợp đều có ưu và nhược điểm riêng, một điều mà cần xem xét khilựa chọn đó là yếu tố đầu ra Các công cụ được tích hợp, trong nhiều trường hợpkhông được tích hợp bằng cách thực hiện và trong nhiều trường hợp được tích hợpbằng cách thu thập đầu ra và quản lý kết quả Bên cạnh đó, nên chạy tất cả các trườnghợp kiểm thử để áp dụng khi cần chạy theo chu kỳ, thông thường chúng chạy trongthời gian dài và không cần kiểm thử viên phải giám sát, do đó hệ thống phải có khảnăng tự khắc phục một số lỗi trong quá trình chạy, thông báo các lỗi đó và tiếp tụcchạy

Thông thường sau phát triển một phần nhỏ ứng dụng, hoặc sau khi khắc phụcnhững khiếm khuyết gây ảnh hưởng một phần ứng dụng, chúng ta mong muốn chạythử ngay lập tức và trong thời gian ngắn, do đó sẽ sử dụng tool ở chế độ này.

Một số công cụ có khả năng hoạt động trên các hệ thống khác tốt hơn là trênchính hệ thống nội bộ Đây là lựa chọn tốt khi kiểm thử việc phân phối và các ứngdụng đa hệ thống

1.6.1.9 Tiêu chí 9: Khả năng phân tích dữ liệu đầu ra

Trong kiểm thử phần mềm, không nhất thiết cần phân tích dữ liệu đầu ra củaứng dụng Tuy nhiên, trong một số trường hợp điều này là cần thiết Trong kiểm thử

hộp đen, hay kiểm thử ứng dụng đầu cuối, cần tập trung vào giao diện khách (client),

không cần phân tích đầu ra ứng dụng mà không phải giao diện đồ họa client Nhưngđối với kiểm thử hộp trắng, chúng ta mong muốn công cụ KTTĐ có khả năng phântích, thậm chí so sánh kết quả đầu ra với kết quả mong đợi Đầu ra bên ngoài có thể làcác tệp tin văn bản, xml, log, ivr, hay ảnh, Khi đó nên lựa chọn công cụ có khả năng

hỗ trợ phân tích đầu ra sẽ hữu ích hơn

1.6.1.10 Tiêu chí 10: Đầu ra các công cụ kiểm thử

Nói một cách đơn giản nhất, đầu ra của công cụ kiểm thử chính là các thôngbáo hay các phản hồi trả về của công cụ sau các bước kiểm thử ứng dụng Nếu mọi cakiểm thử đều thất bại, cần đặt ra câu hỏi, đã kiểm thử những gì, có thể tái tạo lại nómột cách thủ công hay không? Mọi công cụ kiểm thử, đều được yêu cầu thông báo lạicác hành động và các bước thực hiện hay luồng làm việc của nó, đồng thời sẽ thôngbáo lại các lỗi xảy ra và các trường hợp nghi ngờ có thể gây ra lỗi.Trong trường hợpcông cụ KTTĐ được tích hợp vào hệ thống Test Management, cần biết trạng thái chạytrong thời gian thực hiện, kết quả cuối cùng là đạt hay không đạt khi quá trình kiểmthử kết thúc Nếu công cụ KTTĐ tạo và xuất một báo cáo, cần biết định dạng dữ liệunào là phù hợp nhất: HTML, XML hay một định dạng dữ liệu nào Một số hệ thốngmuốn tích hợp các báo cáo của công cụ KTTĐ vào hệ thống báo cáo, hay platform của

họ, để đảm bảo tất cả các báo cáo có chung một định dạng

1.6.1.11 Tiêu chí 11: Khả năng mở rộng

Nếu công cụ KTTĐ không hỗ trợ tất cả các kiểu hay công nghệ kiểm thử cầnthiết, cần xem xét công cụ đó có hỗ trợ các tùy biến giúp chúng ta có thể kích hoạt cáctính năng khác của hệ thống theo yêu cầu Các tùy chỉnh này có thể bao gồm:

-Hỗ trợ các API mở rộng, có thể làm việc với các tổ hợp COM, DLL,

ActiveX hay công nghệ OLE

-Hỗ trợ Java mở rộng, gọi rountines trong Java

-Hỗ trợ dòng lệnh

-Làm việc với các hệ thống kiểm soát tài nguyên

-Kiểm thử hệ thống đa ngôn ngữ, hỗ trợ OCR và các kiểu ký tự

1.6.1.13 Tiêu chí 13: Chính sách giá cả

Với KTTĐ sẽ phải bỏ ra một phần chi phí khi mua và nâng cấp các công cụ cóbản quyền Vì vậy cần cân nhắc tới giá cả và chính sách dịch vụ trước khi lựa chọncông cụ kiểm thử phần mềm tự động Có thể dựa trên:

-Phí bản quyền trên mỗi người dùng/ nhiều người dùng, cố định hay thay đổi, có thời hạn hay vô thời hạn

CHƯƠNG II – GIAO DIỆN VÀ CÁC VẤN ĐỀ CẦN QUAN TÂM

KHI THIẾT KẾ GIAO DIỆN 2.1 Khái niệm giao diện người dùng

Giao diện đồ họa người dùng (Graphical user interface – GUI) hay giao diện người dùng (User Interface – UI) là bộ mặt, là thành phần trung gian để thực hiện giao

tiếp, giữa con người và máy tính Nó là nơi người sử dụng nhập thông tin vào hệthống máy tính (đầu vào) và nhận thông tin phản hồi từ máy tính (đầu ra) [5] Có rấtnhiều loại giao diện khác nhau (bàn phím điện thoại, màn hình máy tính, màn hình các

bộ điều khiển VCR), nhưng chúng đều có chung một cấu trúc, bao gồm: người dùng,

hệ thống, đầu vào và đầu ra như mô tả trong Hình 2.1

Hình 2.1 – Mô hình cấu trúc UI

2.2 Tại sao cần thiết kế giao diện

UI chính là nơi giao tiếp giữa người dùng và máy tính Nó là một phần của hệthống, nơi mà người dùng có thể nhìn, sờ, nghe và giao tiếp Người sử dụng không thểxâm nhập vào hệ thống nếu thiếu UI UI tác động trực tiếp tới cảm nhận của ngườidùng về hệ thống Phụ thuộc vào giao diện mà hệ thống thắng lợi hay thất bại trongviệc giúp người dùng thực hiện nhiệm vụ Một hệ thống có chức năng tốt đến đâu, nếugiao diện tồi sẽ gây khó khăn cho người sử dụng, đôi khi gây hiểu nhầm, dẫn tới việcthi hành chức năng bị sai gây hậu quả nghiêm trọng Thiết kế UI đóng vai trò quantrọng trong quá trình phát triển hệ thống phần mềm bởi những lợi ích mà việc thiết kếtốt UI mang lại [5]:

 Giảm thời gian lập trình

 Giảm chi phí cho những trục trặc do giao diện

 Tăng khả năng bán được của sản phẩm

 Giảm những bệnh nghề nghiệp do dùng máy tính

 Giảm những lỗi nguy hiểm đến tính mạng

 Dễ hiểu giao diện trực quan

 Linh hoạt trong sử dụng hầu hết các phạm vi ứng dụng

 GUI tốt làm giảm công sức trong việc bảo trì hệ thống

2.3 Các dạng giao tiếp người dùng - máy tính

Tùy từng mục đích sử dụng mà UI được thiết kế cho phù hợp Có thể hiểu mỗikiểu giao diện như một kiểu tương tác giữa người dùng và máy tính Các dạng tươngtác cơ bản [4]:

 Giao tiếp dòng lệnh

 Giao tiếp bảng chọn (menu)

 Giao tiếp bằng ngôn ngữ tự nhiên

 Giao tiếp dạng hỏi đáp truy vấn

 Giao tiếp dạng form điền

 Giao tiếp dạng WIMP (Window - Icons - Menus - Pointers)

2.3.1 Giao tiếp dòng lệnh

Giao tiếp dòng lệnh là kiểu giao tiếp có tính lịch sử và rất phổ biến Nó là loạigiao tiếp cơ bản nhất giữa người dùng và máy tính trong một vài hệ thống như MSDOS, UNIX Với kiểu giao tiếp này, người dùng nhập lệnh bằng cách nhấn các phímchức năng để thực hiện các yêu cầu của mình Tuy nhiên các lệnh không thể nhập tùytiện, người dùng bắt buộc phải nhớ lệnh và cú pháp lệnh Vì vậy, rất ít người dùngmới sử dụng phương thức giao tiếp này, trong khi nó lại là lựa chọn của hầu hết cácchuyên gia bởi đây là cách giao tiếp nhanh nhất để máy tính hiểu và thực thi yêu cầungười dùng Hình 2.2 dưới đây là một ví dụ về giao tiếp dòng lệnh trong window

Hình 2.2 – Mô hình giao tiếp dòng lệnh trong window

sẽ chiếm rất nhiều không gian màn hình, gây khó khăn khi người dùng không thể nhớđiểm xuất phát.

Hình 2.3 – Mô hình giao tiếp Menu

2.3.3 Giao tiếp bằng ngôn ngữ tự nhiên

Giao tiếp bằng ngôn ngữ tự nhiên là lĩnh vực đang được quan tâm rất nhiều và

là xu hướng thời đại trong tương lai Ngôn ngữ tự nhiên được hiểu bao gồm cả tiếngnói và chữ viết Ngôn ngữ tự nhiên quá phức tạp và nhập nhằng ngay cả trong giao tiếpgiữa người với người, vì vậy để máy tính có thể hiểu được ngôn ngữ tự nhiên là mộtđiều rất khó Đây vẫn là bài toán hóc búa đối với các nhà khoa học

2.3.4 Giao tiếp dạng hỏi đáp truy vấn

Hỏi đáp là một cơ chế đơn giản nhằm cung cấp dữ liệu cho một ứng dụng củamột lĩnh vực nào đó Người dùng được yêu cầu bởi một loạt các câu hỏi Các câu hỏiđược miêu tả trong nhiều dạng khác nhau: dạng Yes/No, dạng đa lựa chọn, dạng nhấnsố

Kiểu giao tiếp này khá tự nhiên, đơn giản, dễ thiết kế và rất thích hợp chongười dùng mới và thiếu kinh nghiệm

2.3.5 Giao tiếp dạng form-fill

Giao diện form-fill được sử dụng chủ yếu để nhập dữ liệu Nó cũng rất hữu íchcho các ứng dụng khôi phục dữ liệu Giao diện là một form cung cấp các mục thôngtin, và người sử dụng điền các giá trị thích hợp vào các mục đó Kiểu giao diện này dễhọc và dễ dùng, đặc biệt thích hợp cho người dùng mới

Hình 2.4 – Giao tiếp form-fillBảng tính là một hình thức phát triển cao hơn của form-fill Bảng tính bao gồmmột lưới các ô, mỗi ô chứa một giá trị nhất định hoặc một công thức Người sử dụng

có thể nhập và thay đổi các giá trị và công thức theo thứ tự bất kỳ, hệ thống sẽ duy trì

sự nhất quán giữa các giá trị được hiển thị và đảm bảo cho tất cả các công thức sẽđược thực hiện đúng Do đó, người sử dụng có thể thao tác với các giá trị để xem hiệuứng xảy ra khi thay đổi các giá trị thông số khác nhau Điển hình nhất của loại giaodiện này chính là bảng tính trong MSExcel như trong Hình 2.5

Hình 2.5 – Bảng tính

2.3.6 Giao tiếp dạng WIMP

Môi trường tương tác phổ biến nhất hiện nay là WIMP - thường được gọi là hệthống các cửa sổ Giao diện WIMP bao gồm các thành phần: Window - cửa sổ, Icons -biểu tượng, Menu, Pointer - con trỏ

 Cửa sổ (Windows)

Các cửa sổ là các vùng làm việc của màn hình, có thể xem như màn hình độclập Một cửa sổ có thể chứa văn bản hoặc đồ họa, có thể di chuyển và căn chỉnh kíchthước trong giới hạn cho phép Có thể đồng thời thao tác trên nhiều cửa sổ khác nhauvới các ứng dụng khác nhau Các cửa sổ được bố trí khác nhau tùy theo từng hệ thống.Cửa sổ thường được thiết kế kết hợp với các thành phần khác để tăng sự linh hoạt vàhữu ích

 Biểu tượng (Icons)

Biểu tượng là những ảnh kích thước nhỏ, đại diện cho một đối tượng hay mộtthao tác nào đó Khi nhấn vào biểu tượng, hệ thống sẽ thực hiện đúng thao tác đượcthiết kế và tác động tới đối tượng ngầm định

 Bảng chọn (Menus)

Menu là một trong những đặc trưng của hệ thống cửa sổ Một menu đưa ra mộtlựa chọn các thao tác hay dịch vụ có thể được trình diễn bởi hệ thống vào lúc quyđịnh Các menu cung cấp các kiểu thông tin trong biểu mẫu của một danh sách tuần tựcác thao tác mà nó có thể duyệt qua Mỗi menu được đặt tên riêng với ý nghĩa baohàm về chức năng của menu đó Có thể click chuột hoặc nhấn phím để lựa chọn mộtmục thuộc menu Khi đó, mục được chọn được làm nổi bật lên (thay đổi màu sắc hoặchình ảnh), và hệ thống sẽ xử lý thao tác tương ứng với mục được chọn đó Có nhiềukiểu bảng chọn khác nhau:

o Bảng chọn kéo xuống (Pull-down): di chuyển chuột đến và nhấn thì

bảng chọn mới hiện ra

o Bảng chọn rơi xuống (Drop-down): chỉ cần di chuyển chuột đến thì

bảng chọn tự hiện ra

o Bảng chọn bật lên (Pop-up): không cần di chuột, chỉ cần nhấn chuột

phải, bảng chọn sẽ hiện lên

 Con trỏ (Pointer)

Con trỏ là thành phần quan trọng trong thiết kế WIMP, nó được dùng để định vị

và lựa chọn Con trỏ được biểu diễn dưới nhiều dạng khác nhau, nó có biểu tượng đặctrưng thể hiện các chế độ khác nhau của con trỏ Ví dụ, thông thường con trỏ đượcbiểu diễn dưới dạng mũi tên, nhưng khi vẽ một đường thẳng nó sẽ thay đổi thành mũitên hai chiều Khi con trỏ có biểu tượng đồng hồ cát, đó là lúc hệ thống đang xử lýmột tiến trình nào đó

Ngoài các thành phần cơ bản nêu trên, giao tiếp kiểu WIMP còn sử dụng một sốthành phần khác để tăng tính linh hoạt mềm dẻo như các phím lệnh (Commandbutton), thanh công cụ (ToolBar), bảng màu và các hộp thoại

2.4 Tính tiện lợi của hệ thống tương tác

Giao diện phần mềm cần thiết kế đảm bảo tính tiện lợi của hệ thống Theo 9241-11, tính tiện lợi được xem như phạm vi trong đó sản phẩm được sử dụng bởi một

ISO-nhóm người xác định để đạt được những mục tiêu xác định với tính hiệu quả, năngsuất và sự thoả mãn trong ngữ cảnh sử dụng xác định [4].

Tính tiện lợi không phải là thuộc tính của một sản phẩm riêng lẻ mà là mộtthuộc tính của việc tương tác với sản phẩm trong ngữ cảnh sử dụng Nielsel đã môhình hóa sự chấp nhận được của toàn bộ hệ thống như Hình 2.6 dưới đây [7]

 Khả năng vượt lỗi (Errors): Hệ thống ít lỗi và dễ vượt qua lỗi.

 Tính chủ quan (Subjective Satisfaction): Đáp ứng tính chủ quan, người

dùng có thích thú sử dụng hệ thống?

2.5 Nguyên lý thiết kế hệ thống có tính tiện lợi

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à:

 Sự rõ ràng (Visibility)

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ànhì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ộthà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ôngqua â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ả

 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

nó cần được áp dụng trong nhiều tình huống, như: cách đặt tên, cách tham số cholệ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 đầuvà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ệmcủ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 thaotá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ượngchỉ 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ầnphả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átngười dùng có cảm giác có thể nhấn phím Xem ví dụ trong hình 2.8