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, đồng thờ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ọn phương pháp hay công cụ ki

MỤC LỤC

LỜI CAM ĐOAN 3

DANH MỤC CÁC BẢNG 9

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

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

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

1.1.1 Lỗi phần mềm 12

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

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

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

1.2.1 Kiểm thử đơn vị 14

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

1.2.3 Kiểm thử hệ thống 15

1.2.4 Kiểm thử hồi quy 16

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

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

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

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

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

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

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

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

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

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

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

1.5 Kiểm thử tự động 25

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

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

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

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

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

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

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

2.3.1 Giao tiếp dòng lệnh 35

2.3.2 Giao tiếp bảng chọn 36

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

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

2.3.5 Giao tiếp dạng form-fill 36

2.3.6 Giao tiếp dạng WIMP 37

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

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

2.5.1 Sự rõ ràng 40

2.5.2 Sự phản hồi 40

2.5.3 Tính ràng buộc 40

2.5.4 Tính ánh xạ 41

2.5.5 Tính nhất quán 41

2.5.6 Tính gợi ý 41

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

2.6.1 Lỗi chức năng 42

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

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

2.6.4 Thiếu lệnh 43

2.6.5 Lỗi thi hành 43

2.6.6 Đầu ra 43

CHƯƠNG 3 – KIỂM THỬ GIAO DIỆN PHẦN MỀM 44

3.1 Khái niệm kiểm thử giao diện phần mềm 44

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

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

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

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

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

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

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

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

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 63

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

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

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

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

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

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

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

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

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

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

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

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

4.5.1 Ứng dụng Web (Web Application) 72

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

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

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” 85

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

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

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

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

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

5.2.2 Kiểm thử giao diện màn hình “Phiếu nhập hàng” 89

5.3 Tiến hành kiểm thử giao diện ứng dụng 91

KẾT LUẬN 108

TÀI LIỆU THAM KHẢO 109

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

Thứ tự Ký hiệu / Chữ

1 CFG Control Flow Graphic Đồ thị luồng điều khiển

7 QTP Quick Test Professional Công cụ kiểm thử tự động

QTP

8 WIMP Window - Icons - Menus -

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 13

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

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 17

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

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

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 21

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

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

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

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

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

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

Hình 2.5 – Bảng tính 37

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

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

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

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

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

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

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

Hình 4.2 – Tạo Group trong AppPerfect 80

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

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

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

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

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

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

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

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

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

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ới bấ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ường rộ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ông nghệ 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 đa hiệ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ủa phầ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ông thể 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ót nà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ưới vai 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ết sứ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ần mề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 theo hướ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ác công cụ kiểm thử giao diện, Trên cơ sở đó, sẽ có đánh giá khách quan về việc lựa chọn phương pháp hay công cụ kiểm thử giao diện phù hợp đối với ứng dụng được nghiê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, đồng thờ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ọn phương pháp hay công cụ kiểm thử giao diện phù hợp để kiểm thử ứng dụng được xâ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ương phá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ập trung 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ần kiể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ừng loạ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êu trong 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ặc hoạ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ế

 Mã hóa và viết tài liệu

 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át triể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ành kiể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ần mề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ộn thì 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 gian

Như vậy, có thể thể thấy kiểm thử là một khâu rất quan trọng trong quá trình phá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ững chi 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 xem phầ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ường mong đợ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ỉnh hay 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ống phầ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át triể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

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ối tươ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ện nhá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ạo thà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ựa chọ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ần mề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ác lỗ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ình thà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ình viê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ân tí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ác yê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ềm hoặ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 giao dị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ốt quá 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ểm thử 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ối quan 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 qua Hì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ới khá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ướng logic, 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ảo tấ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ên truy 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ập trung 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ết kiệm được thời gian và chi phí cài đặt phần mềm Đây là phương pháp kiểm thử đơn giả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òng lệ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ỗi phá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 thay thế 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ăng phá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 đen Kiể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ột thứ 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ặt khá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ật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức ngườ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ệnh chươ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à cung

trong đồ 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 ít nhất một lần

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

 Phủ mệnh đề: Tổng hợp tất cả các khả năng đánh giá True/Fail của tất cả các đối tượng (biểu thức)

Mỗi tiêu chuẩn chọn đường đều có ưu và nhược điểm riêng của nó Tùy từng trường hợp mà lựa chọn tiêu chuẩn chọn đường cho phù hợp với cấu trúc của CFG

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ác thuộ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ới cho 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ụng nhữ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 xác định lỗi tiềm năng, thường được biết đến như luồng dữ liệu bất thường Ba loại tình huống bất thường khi sử dụng biến:

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ế, khi kiể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ểm thử 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:

 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ểm thử

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ương phá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ành phầ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

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ưới cá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 được yê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 hoc testing 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ạy lạ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ủa kiể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 đi lặ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ới kiể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ểm thử 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ơn nế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ường hợ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ần mề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ểm thử, 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ại nhà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ột framework 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ành mộ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ệu hó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 ca kiể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ích yê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ủa cá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ác hướ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ác nhà 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

Nhược điểm:

 Do yêu cầu công nghệ nên đòi hỏi các kiểm thử viên phải có nhiều kinh nghiệm

và có khả năng viết script

 Có thể tốn nhiều thời gian và chi phí cho công việc ban đầu khi xây dựng các framework và các thư viện

 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 ứng dụ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ới nhữ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ên nghiê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ểm thử 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ốt vớ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ách thứ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ại nhó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ũng như 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 đảm bả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ển phầ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ểm thử 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ểm thử 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ều giao 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 độ quan trọ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ựa chọn được một framwork tự động, sẽ có thể xây dựng được những hỗ trợ cần thiết còn lạ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ựa chon 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ăng tạ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ợp

lý

Nếu quyết định hướng công cụ KTTĐ có khả năng tạo script, cần lựa chọn cô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ếu hầ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ăng ghi âm Các kịch bản KTTĐ rất hữu ích ngay cả khi công cụ KTTĐ cung cấp những cá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 đàn trao đổ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ụng cô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ểu ghi 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ện theo 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ại GUI / blocks Loại hình ghi âm thứ 2, đó là ghi âm thành video Tester thực hiện kịch bả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ếm khuyế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ủa kị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ống KTTĐ, 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ù ứng dụ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ọn là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ểm thử 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ểm thử 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ích kế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ột scenario 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ác nhau để đả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à chi phí để 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ạy nế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 khai phầ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ực hiệ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 khi lự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ợp khô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ợp bằ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ường hợp kiểm thử để áp dụng khi cần chạy theo chu kỳ, thông thường chúng chạy trong thờ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ục chạ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ục những khiếm khuyết gây ảnh hưởng một phần ứng dụng, chúng ta mong muốn chạy thử 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ên chí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 ứng dụ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ân tí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ông bá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 ca kiể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ại cá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ông bá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ợp công cụ KTTĐ được tích hợp vào hệ thống Test Management, cần biết trạng thái chạy trong 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ểm thử 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ệu nà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ống muố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ần thiế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ác tí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ự

cụ không có sự hỗ trợ thích hợp, sẽ phải tiêu tốn rất nhiều thời gian để tìm hiểu cách

sử dụng và đặc biệt khó khăn mỗi khi xảy ra sự cố

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ọn cô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ất nhiề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ười dù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 trong việ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ếu giao 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ệc thi hành chức năng bị sai gây hậu quả nghiêm trọng Thiết kế UI đóng vai trò quan trọ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ỗi kiể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ương tá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ại giao 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ư MS DOS, 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ím chứ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ùy tiệ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ùng mớ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ác chuyê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ầu ngườ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ếng nó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ếp giữ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ủa mộ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ấn

số

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 cho ngườ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 ích cho 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ông tin, 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-fill Bả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ồm mộ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 giao diệ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 độc lậ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ích thướ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 nhau vớ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ột thao 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 được thiế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ột lự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 bao hà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ột mụ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ặc hình ảnh), và hệ thống sẽ xử lý thao tác tương ứng với mục được chọn đó Có nhiều kiể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 đặc trưng thể hiện các chế độ khác nhau của con trỏ Ví dụ, thông thường con trỏ được biể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ũi tê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 (Command button), 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ăng suấ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ột thuộ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à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ả

 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ố 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ế?

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