Luận văn một số kỹ thuật kiểm thử hướng mô hình Áp dụng cho phát triển các Ứng dụng web

- _ Thứ ba, kiểm thử chưa được chủ trọng trong đào tạo con người ~ _ Thứ tư, hạn chế trong kỹ thuật kiểm thử Từ đó đỏi hỏi cần phải có một phương pháp, một kỹ thuật cùng với công cụ đ

1.2, Phân loại và các kỹ thuật

1.3 Kiểm thử nh và kiểm thử ding

Chương 2 NGHIÊN CỨC VỀ KIỀM THỬ HƯỚNG MÔ HÌNH

3.1 Tổng quan về kiểm thứ hướng mỏ hình

2,1,1 Kiểm thử hướng mô hình

2.1.2 Ngôn ngữ mô hình hỏa

2.1.3 Hệ thống chuyến tiệp gán nhãn - LTS

2.1.4 Máy trạng thái hữu hạn FSM

2,1,3 Máy trạng thái mở rộng:

2.1,6 So sánh kiểm thử hướng mô hình và kiêm thủ thông thường

2.2 Các phương pháp tiếp cận kiểm thử hướng mô hinh

2.2.1 Giải thuật tìm kiểm đỗ thị - Graph Search Algorithms

2.2.2 Kiếm thử ngẫu nhiên

2.2.3 Giải thuật tìm kiếm A-star

2.2.4 Kiểm tra mô hình

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

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

3.3 Kết luận chương 3

3.4,1, Ưu điểm của kiểm thir hong mé hi

3.4.2 Nhược điểm của kiểm thử hướng mô hình

KÉT LUẬN VÀ HƯỚNG PHÁT TRIỄN

A Kết luậ

B Một số tên lại trong luận vị

C Hướng phát triển đề tài

DANH MỤC CÁC TÀI LIỆU THAM KHẢO

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi Các thông tin số

liệu và kết quả trong Luận văn được hoản thành sau một thời gian nghiên cứu, tìm

hiểu các nguồn tài liệu sách báo chuyên ngành và thông tin có nguồn gốc rõ rằng, nội dung của Iuận văn chưa từng được công hồ trang bắt kỳ một công trình nghiên

cứu nảo khác

“Hà Nội, tháng 9 năm 2016

Tác giả Luận văn

Nguyễn Phương Trang

Tôi xin gửi lời cảm ơn chân thành đến các anh, chị, em trong Trụng tâm

Phân mềm Viettel — Viettel Group đã tạo điều kiện cho tôi học tập, nghiền cứu và ứng đụng thực tiễn

Cuối cũng, tôi xin gửi lời cám ơn bạn bê, nhất là gia đình tôi những người đã

luôn bên cạnh quan tâm, động viên và tạo mọi điền kiện tất nhất, khuyến khích tôi

trong quá trình học tập và nghiên cứu để hoàn thành tốt được để tải nghiên cửu của

mình

Tôi xin trân trọng cắm ơn!

Tác giả Luận văn

Nguyễn Phương Trang

DANH MỤC CÁC TỪ VIÊT TAT VA THUAT NGU

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

Hình 1.1, Ví đụ chu trình điều khiến

Hình 1.2 Giai đoạn kiểm thử trong xử lý phần mềm

Hình I.3 Quy trình kiểm thử phần mềm

Hình 1.4 Các giai đoạn kiềm thử

Hinh 2.1 Vũng áp dụng của kiểm thử hướng mô bình

Hình 2.2 Đại diện trực quanLTS

Hình 2.3 Sơ đồ Irạng thái cho một cửa quay

Hinh 2.4 Mô hình tất định (trái) và không tất dịnh (phải)

Tình 2.5 Tool bar

Hình 2.6 Cửa số tcst case _

Hình 2.7 Quy trình kiểm thử hướng mô hình

Tình 3.1 Luồng nghiệp vụ chỉnh của hệ thẳng

Hình 3.2 Màn hình Dashboard Kỹ thuật Tập đoàn

Hinh 3.3 Màn hình Dashboard Kỹ thuật thị trường

Hình 3.4, Mô hình vào màn bình Dashboard kỹ thuật thị trường

Hinh 3.5 Các ca kiểm thử vàn mắn hình Dashboard kỹ thuật thị trường

Hình 3.6 Mô hình vào màn hình chỉ tiết Spark

Hình 3,7, Ca kiểm thử vào màn hình chỉ tiết Spark

Hình 3.8 Mô hình xem biểu đỗ xu thế KPI

Hình 3.9 Ca kiếm thử xem biểu đồ xu thể KPI

Tình 3.10 Xem chỉ tiết biểu đồ Gián đoạn thông tin mức linh

Hình 3.11 Ca kiểm thử xem chỉ tiết biểu để Gián doạn thông tin mức tỉnh

Hình 3,12 Click dn hiện đường line

Hình 3.13 Ca kiểm thử cliek ân hiện đường line

Hình 3.14 Thay dải vị trí các phản

Hình 3,L5 Ca kiêm thử thay đổi vị trí các phần

Hình 3.6 Mô hình phóng to - thu nhỏ biểu đề

Hình 3.17 Mô hình phóng to - thu nhỏ biển để,

Hình 3,18 Kiểm thử tự động vào màn hình đashboard kỹ thuật

Hình 3.19 Kiếm thử tự động xem biểu đồ Xu thể KPI

tất đa dạng và tùy theo nhu cầu đặc thù của tửng lĩnh vực, tuy nhiên điểm chung

nhất vẫn là giảm nhân lực, thời gian và sai sót Ngành công nghệ thông tín mà cụ

thể là phát triển phần mềm cũng không ngoại lệ

Kiểm thứ phần mềm luôn là một khâu rất quan trọng trong việc phát triển phần mềm, tuy nhiên hoạt động này lại tiêu tốn và chiếm tỷ trọng khá lớn công sức

và thời gian trong một dự án Do vậy, nhu cầu tự động hoá quy trình kiểm thứ phần

mễm cũng được đặt ra

Qua thực tế cho thấy, việc áp dụng kiểm thứ tự động hợp lý sẽ mang lại

thành công cho hoạt động kiếm thử phan mềm Kiểm thử tự động giúp giảm bớt

công sức, thời gian thực hiện, tăng độ tin cậy, giảm sự nhằm chản và rèn luyện kỳ

nang lập trình cho cán bộ kiểm thử Từ đó nâng cao chất lượng của sản phẩm lên cau hơn,

Đó là lý em chọn đề tài “Mật số kỹ thuật kiểm thứ hướng mô hình áp dung cho phát triển các ứng dụng Web” làm luận văn tốt nghiệp

2 Tính cấp thiết của đề tài

Kiểm thử phần mềm góp một phần rất lớn trong việc đánh giá chất lượng, một phần mềm và là quy trình bắt buộc trong các dự án phần mềm trên thế giới cũng như trong nước Tuy nhiên, hoạt động kiểm thử thường gặp nhiều khó khăn Nguyên nhân chỉnh, gồm cỏ:

-_'Thứ nhất, kiểm thử các hệ thông phức tạp đòi hòi rất nhiều nguồn tài nguyên

và chỉ phí cao,

-_ Thứ hai, quy trình phát triển phần mềm luôn trải qua nhiều hoạt động biến

đổi thông tín sự mắt mát thông tin trong quá trình biến đổi là yếu tế chính

làm cho hoạt động kiểm thử khó khăn

- _ Thứ ba, kiểm thử chưa được chủ trọng trong đào tạo con người

~ _ Thứ tư, hạn chế trong kỹ thuật kiểm thử

Từ đó đỏi hỏi cần phải có một phương pháp, một kỹ thuật cùng với công cụ

để hỗ trợ quy trình kiểm thử, giúp cho việc kiểm thử nâng cao được chất lượng sản

phẩm mà vẫn đâm bao hop lý về mặt chỉ phí Kiểm thứ tự động theo hướng mê hình chính là một hướng tiếp cận thỏa mãn điều kiện đã đưa ra

3 Mục đích, đổi tượng, phạm vỉ nghiên cứu

ĐỀ lài tìm hiểu cơ sở lý thuyết về kiểm thử, kiểm thử hướng mô hình cũng như cách triển khai cöng cụ kiểm thứ lưởng mô hình để giảm thời gian, nguồn lực +kiểm thử và đảm bảo chất lượng phần mễm hơn so với công việc kiểm thử thủ công

Các nội dung chính sau:

(1) Tìm hiểu tổng quan về kiếm thử phân mẻm, kiểm thử nướng mô hình

(2) Nghiên cứu các kỹ thuật kiểm thứ hướng mô hình; tìm hiểu các phương pháp, công cụ kiểm thử hướng mô hình Để xuất quy trình kiêm thử hướng mê hình cho phát riển ứng dụng Wcb

(4) Thực hiện áp dựng quy trình vào quá trình phát triển img dung Web, cu

thể là Hệ thống Dashboard kỹ thuật của Viettel Group, Đánh giá hiệu quả và dưa ra các hướng phát triển tiếp theo

4 Bố cục của luận văn

Với mục tiêu đặt ra như vậy, những nội dung và kết quá nghiền cứu chính của luận văn được trình bảy trong ba chương như sau:

Chương 1: Tổng quan về kiểm thử phần mềm

Chương 2: Nghiên cứu vẻ kiểm thử hướng mô hình

10

Chương 3: Áp dụng thử nghiệm cho ứng dụng wcb hệ thống Dashboard kỹ

thuật,

Phần kết luận đưa ra những đánh giá về những kết quả đạt được và thảo luận

về hướng phát triển tiếp của luận văn

11

Chuong 1 TONG QUAN VE KIEM THU PHAN MEM

1.I Kiểm thử phần mềm

Kiểm thừ phần mẻm là quy trỉnh được sử dụng để đánh giá, kiểm tra chất

lượng phần mềm ở nhiều khia cạnh khác nhau dựa trên các yêu cầu của người sử

dụng đối với sản phẩm phần mẻm, nhằm dảm bảo phần mềm hoạt động tốt trong

các môi trường, các trường hợp khác nhau,

1.2 Phân loại và các kỹ thuật kiểm thử

Ta phân loại kiểm thử đựa vào các yếu tổ: Chiến lược kiếm thử, phương

pháp kiểm thử và kỹ thuật kiểm thử

Dựa vào chiến lược kiểm thứ ta có thể phân chỉa kiểm thử thành hai loại: kiểm thử thủ công và kiểm thử tự động

Thco phương pháp tiến hành kiểm thử ta chỉa kiểm thử làm hai loại: kiểm

thử tĩnh và kiểm thử động

Dựa vào kỹ thuật kiểm thử ta có thế nhân chỉa kiểm thử thành ba loại: kiểm

thử hộp đen kiểm thử hộp trắng vả kiểm thử hộp xám

13 Kiểm thử nh và kiểm thữ động

1.31 Kiểm thử tĩnh

Lả phương pháp kiểm thứ phần mềm thông qua việc sử dụng giấy, bút trên

bản để kiểm tra logic, kiểm tra từng chỉ tiết ngay sau khi lập trình xong, chủ yếu

kiêm tra mã và xem xét các tài liệu đặc tá

Kiểm thử fĩnh cũng có thể được thực hiện một cách tự động Nó sẽ thực hiện

kiểm tra toàn bộ bao gằm các chương Irình được phân tích bởi một trình thông dịch

hoặc biên địch dễ xác định tinh hợp lệ và cú pháp của chương trình

Các phương pháp kiểm thử tình lä Thanh tra, Duyệt

12

- Thanh tra: Phuong pháp kiểm tra ngang hàng sản phẩm phần mềm thực

hiện bởi những người nghiên cứu riêng lẻ (hay cờn gọi kiểm tra chéo giữa

các thành viên tham gia thực hiện) đề tìm ra những lỗi có thể bằng một

tiến trình chuẩn cho trước

-_ Duyệt: Là một phương pháp kiểm tra Tigang hàng với một người thiết kế

hướng nhỏm phát triển đến các hoạt động chủ ý của quá trình sản xuất

phần mềm, tham gia đặt câu hỏi và chủ thích cho các lỗi có thể có

1.3.2 Kiểm thừ động

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình

để điều tra trạng thái từng động tác của chương trinh, Đó là kiếm thử đựa trên các

ca kiểm thử xác định bằng sự thực của đối tượng kiểm thử hay chạy các

chương trình Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm

tra sự phản ứng vật lý từ hệ thông tới các biến luôn thay đôi theo thờ

lan, Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động gồm các công việc, nhập giá trị đầu vào và kiểm tra xem đầu ra có đúng kết quả mong

muốn không

Các phương pháp kiểm thử động gồm có kiêm thử đơn vị - Lữ Test, Kiểm thử tích hợp - #ergranion Test, Kiểm thừ hệ thống — System Test, va Kiém thir chấp nhận sán phẩm — Accepiance Test

1.4 Kiểm thử hộp trắng, kiểm thử hộp đen và kiểm thử hộp xám

Quá trình thiết kể trường hợp thử là quá trình xây dựng các phương pháp +kiêm thử có thể phát hiện lỗi, sai sót khiếm khuyết của phần mềm đề xây dựng một

phần mềm đạt tiêu chuẩn

Thiết kế các trường hợp kiểm thử có vai tò:

- _ Tạo ra các trường hợp kiếm thử tốt nhất có khả năng phát hiện ra lỗi, sai xót của phan mém một cách nhiều nhất

- Tao ra cdc trường hợp kiểm thử có chỉ phí rẻ nhất dồng thời tốn ít thời gian và công sức nhất,

Ba trong số những chiến lược kiếm thử thông dụng nhất bao gầm: Kiểm thử

nhập đen, Kiểm thử hộp trắng, và Kiểm thử hộn xám

1.41 Kiểm thử hộp trằng

Kiểm thử hộp trắng (White box testing) hay còa gọi là kiểm thử hướng logic, cho phép kiểm tra câu trúc bên trong của phần mềm với mục đích dam bao rằng tắt

cả cáo câu lệnh và điều kiện sẽ được thực hiện íL nhất một lần

Hập trắng đúng nghĩa phải gọi là hộp trong suối Chính vi vậy, kỹ thuật nay còn ró một số tên khác là kiểm thử hộp thuy tinh (Glass-Box Testing) hay kiểm thử hộp trong suốt (Clear-Box Testing) Người kiểm thử truy nhập vào mã nguồn chương trình để kiểm tra và đây là cơ sở để hỗ trợ việc kiểm thử

Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:

-_ Thực hiện mọi đường dẫn độc lập ít nhất một lần

-_ Thực hiện mọi điều kiện logic (1f-then-else) trên các giá trị true và false

Trong phương pháp kiểm thử hộp trắng, có hai kỹ thuật kiêm thử hộp trắng

đó là:

- _ Kiêm thử bao phủ chu trình cơ sở

- _ Kiểm thử cấu trúc điều khiên

1.42 Kiếm thủ hộp den

Xỹ thuật kiểm thử hộp đen (Black box testing) còn được gọi là kiếm thử

hướng dữ Hệu (dala-driven) hay là kiểm thử hướng vàoZra (input/output driven)

Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen Người kiểm thử hoàn toản không quan tâm cấu trúc và hành vi bên trong của phần

mềm, chỉ cần quan tâm đến việc tìm các hiện tượng mả phần mềm không thực hiện

Theo đúng đặc tà của nó Vì thế, dữ liệu kiểm thử sẽ xuất phát từ đặc tả

Kiểm thử hộp đen cô găng tìm các loại lỗi sau:

-_ Các chức năng thiểu hoặc không đúng

-_ Các lỗi giao diện

-_ Các lỗi cấu trúc dữ liệu trong truy cập cơ sở đữ liệu bên ngoài

-_ Các lỗi thí hành

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

-_ Và các lỗi kháp,

1.43 Kiểm thứ hộp xám

Kiểm thử hộp xám (Gray box testing) đỏ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 theo tác tới đữ 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 “ố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 kiểm thử tích hợp Erergartian resiing giữa 2 modun 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à dược dưa ra dễ 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.5 Quy trình kiểm thử phần mềm

Trude khi tim hiểu một quy trình kiểm thử nhần mềm, ta cần hiểu hai khái

niệm sau: Testcase và TestScript

+ Testcase: Một tcstcaso có thể coi là một tình huống kiểm tra, được thiết kế

để kiểm tra một đối tượng có thóa mãn yêu cầu đặt ra hay không Một testcase thường có 3 phần cơ bản:

-_ Mục đích kiểm thử: Mô tả các điều kiện cần để tiễn hành kiểm tra

-_ Các hước thực hiện: Mô tả các bước thực hiện để kiểm tra một testcase

-_ Kết quả mong muốn: Kết quả trả về từ đổi tượng kiểm tra, chứng tô đối

tượng đạt yêu câu

+ Testserint: Một 1estscript là một nhóm mã lệnh đụng đặc tả kịch bản dùng

để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn hoặc cho những trường hợp kiểm tra bằng tay rất khó khăn hoặc không khả thi Các restscript

có thể tạo thủ công hoặc tạo tự động đũng công cụ kiểm tra tự động,

Tại sao phải thực hiện quy trình kiêm thử phân mềm?

- _ Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm

- _ Cần làm rõ các công đoạn, các bước kiếm thử

-_ Cần phải hiểu vả phân biệt các tính chất kiếm thử (lại sao phải kiểm thử),

các bước kiểm thừ (khi nảo kiểm thử) và các kỹ thuật kiểm thử (kiểm thử

bằng cách nàn)

16

Các Inừng hop kid thử

Dữ liệt kiếm thir

+ Lập kế hageh kiểm thể Sau khi tìm hiểu nghiệp vụ từ các tài liệu phân tích, thiết

kế, nhóm kiểm thử Lập kế hoạch kiểm thử xác dịnh các chức năng cần kiểm tra

Kế hoạch kiểm thử thường được lưu trong I le và chứa kết quả của các hoạt động

sau:

- Nhén dang các chiến lược được dùng dé kiểm tra và đâm bảo rằng sản

phẩm thỏa mãn đặc tả thiết kế phần mềm và các yêu cầu khác về phần

mềm

- _ Định nghĩa các mục tiêu và phạm vi của nỗ lực kiểm thử,

- _ Nhận đạng phương pháp luận mẻ đội kiểm thử sẽ dùng để thực hiện công

việc kiểm thứ

- _ Nhận đạng phản cứng, phần mềm và các tiện ích cần cho kiểm thứ

- _ Nhận dang các tính chát và chức năng sẽ dược kiểm thử,

-_ Xác định các hệ số rủi ro gây nguy hại cho việc kiểm thử

- _ Lập lịch kiểm thử vả phân phối công việc cho mỗi thành viên tham gia

+ Giai dogn bộ trí nhân viên kiểm thứ Việc kiềm thừ thường phải tiễn hành một cách độc lập và các nhóm độc lập có trách nhiệm tiễn hành các hoạt động kiểm thứ,

Bọi là các nhóm kiểm thử

+ Thiết kế kịch bản kiểm thử Nhóm kiểm thứ thực hiện lập kịch bản kiêm thử các

chức nàng, mô tâ các luỗng nghiệp vụ chỉnh, phụ cần kiểm tra

+ Thiết kế các trường hợp kiểm thủ Các trường hợp kiểm thử là các đặc tá dầu vào cho kiểm thử và đầu ra meng đợi của hệ thông cùng với các câu lệnh được kiểm

thử, Các trường hợp kiểm thử đủ các thông tin: Mục đích, điều kiện kiếm thử, các bước thực hiện và kết quả mong muốn

- _ Các phương pháp hộp đen đề kiếm thử dựa trên chức năng

- _ Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong

+ Thực hiện kiểm thứ.Tù các trường hợp kiểm thừ được thiết kế ở bước trên, nhóm +kiểm thử phát triển các tesL scripL và thực hiện kiêm thử phần mềm

+ Phân tích, đính gid kết quả sản phdm phan mém 48 xác nhận sản phẩm có thé sin sàng phát hành được chưa? Mô hình chung của quy trình kiểm thử phần mềm

được thể hiện trong hình 1.5

Tá tướng Dữ liêu Kết quả Kết quả

Hình 1.3 Quy trình kiểm thứ phần mềm:

Trong một dự án, kiểm thử thường trải qua các giai đoạn: Kiểm thử đơn vị,

kiêm thử tích hợp, kiểm thử hệ thống và kiếm thử chấp nhận

18

Tộn bộ hệ thống, Inhn tử khách hàng

Hình 1.4 Các giai đoạn kiểm thử 1.5.1 Kiểm thứ đơn vị

Một đơn vị (Unit Testing) là một thành phần phần mềm nhỏ nhất mà ta cĩ thể

kiểm thử được Vi dy, cde him (Function), thủ tục (Proeedure), lớp (Class) hay

phương thức (Aethod) đều cĩ thể được xem là Unit

Unit Test thường do lập trình viên thực hiện Cơng đoạn này cần được thực

hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thơng thường, Unit Test địi hỏi kiểm thử viên cĩ kiến thức về thiết kế

và code của chương trình Mục đích của Unit Test là bảo đảm thơng tin được xử lý

và xuất (khỏi UniU 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 Unit Điều này thường địi hỏi tất cả các nhánh bên trong Unit đề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 Unit

Cùng với các mục kiểm thử khác, Unit Test cũng địi hỏi phải chuẩn bị trước

các ca kiém thir (Test case) hoac kich ban kiém thir (Test script), trong d6 chi dinh

rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các Test case

và Test script này cĩ thể tái sử dụng được

1.%2 Kiểm thử tích hợp

Kiểm thử tích hợp (Integration test) két hop c4c thành phần của một ứng

dụng và kiểm thử như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra

các thành phẩn và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra giao tiếp giữa chúng

Hai mục tiêu chính của Integration Test:

-_ Phát hiện lễi giao tiếp xây ta giữa các Unit

-_ Tích hợp các Unit don lẻ thành các hệ thống nho (Subsystem) va cudi

cùng là cả hệ thống hoàn chỉnh (Sus£zm) chuẩn bị cho kiểm thử ở mức hệ

thống (Svstem Tes0)

Trong Unit Tesr, lập trình viên tìm các lỗi liên quan đến chức nãng và cấu

trúc nội tại của UniL Có một số phén kiểm thử đơn gián trên giao tiếp giữa UniL vôi

các thành phân liên quan khác, tuy nhiên mọi giao tiếp liên quan dén Unit chi thét

sự được kiểm tra đầy đủ khi các Lnit tích hợp với nhau trong khi thực hiện

Integration Test

C6 4 loai kiém thir trong Integration Test:

-_ Kiểm thit edu tric (Structure Test): Tuong ty White Box Test, kiém thừ

cầu trúc nhằm bảo đâm các thành phan bên trong chương trinh chay ding

và chú trọng đến hoạt động của các thành phần cấu trúc nội bộ của

chương trình, chăng hạn các câu lệnh và nhánh bên trong

-_ Kiểm thủ: chức năng (Funcdional Tes0: Tương tự Black Box Tel, kiểm

thử chức năng chỉ chủ trọng dến chức năng của chương trình, không quan

tâm đến cầu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật

-_ Kiểm thử hiệu năng (Performance Test): Kiém thử việc vận hành của hệ

thống,

20

Sysuem Test bất đầu khi tắt cả các thành phần của phần mễm đã được tích

hợp thành công Thông thường loại kiểm thử này tốn tất nhiều công sức và thời

gian Ở mức độ hệ thống, người kiểm thử cũng tìm kiểm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác lên quan đến chất

lượng của toàn hệ thống

Điểm khác nhau ohat giita Integration Test va System Test 14 System Test

cha tong các hành vi và lỗi trên toàn hệ thống, còn Integration Test cha trong việc

giao liếp giữa các đơn thẻ hoặc đối lượng khi ching lam việc cùng nhau Thông, thường ta phải thực hiện Unit Test vả Intepration Test để bảo đảm mọi Unit và sự

tương tác giữa chúng hoạt động chỉnh xác trước khí thực hién System Test

Thông thường, System Test có các loại kiểm thử sau:

-_ Kiểm thừ chức năng (Fancflonel Tesj: Bào đảm các hành vì của hệ

thống thỏa mãn đúng yêu cầu thiết kế

- Kiém thứ hiệu ning (Performance Tes): Bao đâm tôi ưu việc phân bỗ tài nguyên hệ thẳng (ví đụ bộ nhớ) nhằm đại các chỉ tiều như thời gian xử

lý hay đáp ứng câu truy vấn

-_ Kiểm thir dp ie (Stress Test): Day 1A loai kiém thir dugc tiến hành khi

đã có phiên bản làm việc, nhằm tim hiểu hoạt động của hệ thống trong

các trưởng hợp tải trọng lớn (dữ liệu lớn, số người sử dụng lớn, tải

nguyên hạn chẻ ) Mục đích của kiếm thử áp lực là, tìm ra ngưỡng chịu

tải của hệ thống, tìm ra ngưỡng hệ thống đạt và không đạt Ngoài ra, kiểm

21

thử áp lực còn xắc dịnh các trạng thái dặc biệt như các nguyên nhâu dẫn

đến hệ thông không đạt, tính toàn vẹn đữ liệu,

-_ Kiểm thuữ bảa mật (Security Test): 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 (Recovery Tes): Được tiễn hành nhằm làm

hệ thống ngừng hoạt động và đánh giá khả năng phục hỗi sau đó Với các

hệ thống có khá năng phục hồi tự động, ta cần đánh giá các công đoạn tải

thiết lập thông số, khả năng khôi phục dữ liệu và tái khởi động Với các

trường hợp đòi hỏi khởi động lại thủ công, ta cần đánh giả thời gian

ngừng để sửa chữa (ÄMTTR — Mean Time To Repair) và trong một số

trường hợp đánh giá ca chí phí cho việc khởi phục

1.5.4 Niễm thứ chấp nhận sẵn phẩm

Thông thường, sau giai đoạn System Test là Kiểm thử chấp nhaatnj

(Acceptance Tes0, được khách hàng thực hiện Mục đích của Acceptance Test là để

chứng mình nhần mềm (hỏa mãn tắt cá yêu cầu của khách hàng và khách hàng chấp

nhận sản

Đối với những sản phâm dành bản rộng rãi trên thị trưởng cho nhiều người

sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha

Alpha Test va kiém thir Beta — Beta Test, Véi Alpha Test, ngudi ding kiểm thứ

phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghỉ nhận các lỗi hoặc

phan hồi và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi toi cho

người ding đề kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa

1.5.5 Một số cấp độ kiêm thứ khác

Ngoài các cắp độ trên, còn một số cấp độ kiểm thử khác như:

22

> Kidm tha hdi quy — Regression Testing

Kiểm thử hồi quy dùng để kiểm tra các phần được sửa chữa trong phần mềm,

để đảm bảo rằng những sự thay đổi đó không gây ra lỗi trong những phần khác

Tà tiến hành lại các phép thử đã thành công mỗi khi tích hợp thêm mồ đun

hoặc khi cập nhật mã nguồn chương trình

Khi chúng tz tích hợp thêm mô đun vào hệ thống hoặc khi tiến hành nâng cấp chương trình thì sẽ tạo ra một số tô hợp trạng thái mới dẫn đến:

-_ Xuất hiện lỗi ở mô đun trước đây chưa gây lỗi

-_ Khắc phục một lỗi mới có thể sẽ làm ảnh hưởng tới một lỗi chúng ta đã

sửa

-_ Sinh ra lỗi mới mã trước đây chưa có

> Kiểm thử tính đúng Correctness testing

Tính đúng đắn là yêu cầu tối thiền của nhần mềm, là mục đích chủ yếu của kiểm thử

1.56 Các phương pháp kiểm thứ con người

Hai phương pháp kiểm thử cơn người chủ yếu là Code Inspections và Talinhroughs lai phương pháp này bao gồm một nhóm người đọc và kiểm tra

theo mã lệnh của chương trình Mục tiêu của chúng là để tìm ra lỗi mả không gỡ lỗi

Mét Inspection hay Walkthrough la 1 sự cải tiễn của phương pháp kiểm tra

mà lập trình viên đọc chương trình của họ trước khi kiểm thử nó Zzspctiens và

Ialithrouglis hiệu quà hơn là bởi vì những người khác sẽ kiểm thử chương trình tốt

hơn chính tác giả của chương trình đó

nspections/Walkthroughs và kiểm thù bằng máy tính bỗ sung cho nhau Hiệu quả tìm lỗi sẽ kém đi nếu thiểu đi I trong 2 phương pháp Và đối với việc sữa

đỗi chương trình cũng nên sử dụng các phương pháp kiểm thử nảy cùng như các kỹ

thuật kiếm thử hồi quy

3 Tổng duyét— Walkthrough

Walkthrough 1a một thuật ngữ mô tả sự xem xót kỹ lưỡng của một quá trình

ở mức trừu tượng trong đó nhà thiết kế hay lập trình viên lãnh đạo các thành viên trong nhóm và những người có quan tâm khác thông qua một sản phẩm phần mễm,

và những người tham gia đặt câu hỏi và ghỉ chú những lỗi có thể có, việc vi phạm

các chuẩn phát triển và các vấn dễ khác Walkthrough mã lệnh là 1 tập các thú tục

và các công nghệ lỗi cho việc doc nhém ma lénh Trong mét Walkthrough, nhom

các nhà phát triển — với 3 hoặc 4 thành viên là tốt nhất — thực hiện xét duyệt lại Chỉ

1 trong các thánh viên là tác giả của chương trình

Một ưu điểm khác của waltthrougle, hiệu quả trang chỉ phí gỡ lỗi, là 1 thực

tế mà khí một lễi được tìm thây, nó thưởng được định vị chính xác trong mã lệnh

“Thêm vào đó, phương pháp này thường tìm ra 1 tập các lỗi, cho phép sau đó các lỗi

đó được sửa tất cả với nhau Mặt khác, kiểm thử dựa trên máy tính, chỉ tìm ra triệu

chứng của lỗi và các lỗi thường được tìm ra và sứa lằn lượt từng lỗi một

> Thanh tra mã ngudn — Code Inspection

Thanh tra mã nguồn là I tập hợp các thủ tục và các kỹ thuật dò lỗi cho việc đọc các nhóm mã lệnh Một nhỏm kiểm duyệt thưởng gồm 4 người Một trong số

đó đồng vai trò là người điều tiết _ một lập trình viên lão luyện và không được lả tác giả của chương trình và phải không quen với các chí tiết của chương trình

Người điều tiết có nhiệm vụ: phân phối nguyên liệu và lập lịch cho các buổi kiểm duyệt, chỉ đạo phiên làm việc, ghỉ lại tit cả các lỗi được tìm thấy và đâm bảo là các lỗi sau đó được sửa Thành viên thứ hai là một lập trình viên Các thành viên còn lại

trưng nhóm thường là nhà thiết kế của chương trình (nếu nhà thiết kế khác lập trình

viên) và một chuyên viên kiểm thử,

24

1⁄6 Kết luận chương 1

Trong chương này, ta đi vào tìm hiểu để có cái nhìn tổng quan về kiểm thứ phan mam, phan loai kiểm thử đựa vào các yếu tố: Chiến lược kiểm thứ, phương,

pháp kiểm thử và kỹ thuật kiểm thử,

Luận văn cũng tìm hiểu về quy trình phần mềm, các khái niệm về trường hợp

kiểm thử (testcase), kịch bản kiểm thử (testscript) Quy trình phần mềm gồm các

giai đoạn kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận sản phẩm và các phương pháp kiểm thử con người

Chương 2 NGHIÊN CỨU VỀ KIỂM THỦ HƯỚNG

MÔ HÌNH

1.1 Tổng quan về kiểm thứ hướng mô hình

3.1.1 Kiểm thứ hưảng mô hình

Kiểm thi hướng mô hình thường mang nghĩa kiểm thử chức năng với các đặc tả kiểm thử được dựa trên một mô hình kiểm thử Mô bình kiêm thử được bắt nguồn từ các yêu cầu của hệ thống Chỉ có một số ít các phương pháp sử dụng kiểm

thử hướng mô hình cho việc kiểm thử phí chức năng Tiêu chuẩn bao phủ thường được chú ý đến tại cấn độ kiếm thử mô hình Thành phẩn bên trong của hệ thống

không nhất thiết phải được thể hiện ra (kiểm thử hộp đen — hộp xám) Kiểm thử hướng mô hình có thể được áp dụng tại tất cả các cấp bậc từ unit test dén system

test

Kiểm thử hướng mô hình là một công nghệ mới có liên quan tới kiểm tra phần mm Một mô hình mô tả hành vi mong muốn cho việc Kiểm tra hệ thống

(System Under Test - SUT) là diém chinh trong thử nghiệm dựa trén mé hinh, Hanh

vi mong muốn thường được chỉ định trong tai liệu đặc tả SUT

SUT được kiểm tra thông qua cách tiếp cận kiểm thử hộp đen Kiểm thử hộp

đen có nghĩa rằng chúng ta chỉ quan sát đầu ra hệ thông xem xét với một đầu vào

nhất định, không cần biết mã code đẳng sau nó Đầu ra quan sát từ SUT được sơ sánh với đầu ra mong muốn của hệ thống đưa ra bởi mô hình Trái ngược với kiểm

thử hộp đen là kiểm thử hộp trắng kiểm tra cấu trúc bên trong của hệ thông

26

Hình 2.1 Vùng áp dụng của kiểm thử hướng mô hình

Kiểm thử hướng mô hình đóng một vai trò quan trọng trong việc kiểm chứng

(verification) phần mềm hướng mô hình Có rất nhiều ưu điểm của kiểm thử hướng

phương pháp kiểm thử trước khi phát triển sẽ giúp ta giảm được chỉ phí,

hơn nữa kinh nghiệm cho thấy rằng việc tạo ra các mô hình kiểm thử

chính thức cũng giúp ta tìm ra được các khiếm khuyết và mâu thuẫn trong

yêu câu

27

2.1.2 Ngôn ngữ: mỗ hình búa

Ngôn ngữ mô hình hoá là ngôn ngữ được sử dụng để thể hiện thông tin hoặc

một hệ thống trang một cấu trúc được xác dịnh bởi một tập các quy lắc; các quy tắc này được sử dụng để giải thích ý nghĩa của các thành phẩn trong cấu trúc Ngôn ngữ

mô hình hoá có thể là ở dang văn bản hoặc đỗ họa Kiếm thir img dung web với

cách tiếp cận thử nghiệm dựa trên mô hỉnh dòi hỏi chúng ta sử dụng mô hình Một

mô hình mô tả hành vi đúng của hệ thống Các đặc 1á hệ thống, tài liệu về những gì

hệ thông có khả năng làm, chí rõ hệ thẳng phải làm những gì khi các một số yếu tổ được sử dụng và hệ thống phản hồi những gỉ khi sử dụng các yếu tổ đó Ví dụ, đặc

tả sẽ cho chúng ta biết nên xảy ra cái gì nếu người dùng bám vào một liên kết trong

trình duyệt Hệ thống sẽ phản hôi với các tp tin được yêu cầu hay đưa ra lỗi Tắt cả

Với một mô hình, chúng ta có thể tạo ra thuật toán kiểm tra các trưởng hợp

để xác mình SUT có những hành vì phù hợp Một mõ hình có thể được mồ tả theo

những cách khác nhau với sự khác biệt riêng cúa chúng Nhớ răng mỗi một công cụ

thử nghiệm đựa trên mô hình sử đụng mô hình khác nhau để tạo ra các trưởng hợn

thử nghiệm Trong các phần sau, chúng ta nêu các ngôn ngữ mô hình phố biến nhất

được sử dụng trong thừ nghiệm dựa trên mỏ hình

2.1.3 Hệ thắng chuyên tiến gắn nhân - LTS

lIệ thống chuyên tiếp gán nhãn (Labelled Transition Systems - LTS) bao gồm một tập các trạng thái và một bệ chuyển tiếp giữa những trạng thái Có một trạng thái ban đầu gọi là sọ Mỗi sự chuyển tiếp được gán nhãn bởi một hành động

Những trạng thái (ransition) tượng trưng cho trạng thái của hệ thông và những nhan (label) tượng trưng cho các hành động mà hệ thống quan sắt được Lahcl được

lây từ một bộ 1 Thông thường, một LTS là một bội bến số: [4]

28

($,So,L,—)

S là một tập các trạng thái khác rỗng và L là tập các hành động quan sát được (còn gọi là label) Chúng ta cũng có một Label đặc biệt r mà không một phân tử nào của r € L và dùng cho hành động ở bên trong Quan hệ chuyên tiếp — là một tập

con của sản phẩm từ bộ trạng thái, Label và trạng thái đầu ra:

+ €S§x(LUfr]) x S,wíth r £ L

Chúng ta viết s —› t nếu có một chuyển tiếp gán nhãn hành động u chuyển

hệ thống từ trạng thái s sang trạng thái £, đó là (s,w,t) e — Những trạng thái mà

không thẻ làm một hoạt động bên trong được gọi là ôn định, trong khi các trạng thái

mà không thể làm một đầu ra hay hoạt động bên trong được gọi là ở không hoạt

động Một trong những lý thuyết tốt trong phạm vỉ LTS là đầu vào/đầu ra tuân thủ mối quan hệ Đại diện trực quan LTS được biêu diễn trong hình 1

dime?

coffee!

button? coffee!

Hinh 2.2 Dai dién true quanLTS

G hinh trén ta viét qO “™*— ql: chuyén tiép gan nhin dime tir trang thai q0 tới trạng thái q1, hay còn viết (q0, dime, q1) Tương tự ta có:

{(q0 dime, q1), (q1, button, q3) (q3, coffee, q0)}

29

((q0 nikel, q2) (q2, nikel, q4), (q4, button, q5) (q5, coffec, q0}

'Traoe của LT§ được định nghĩa nhự sau:

3.1.4 Máy trạng thái hữu hạn FSM

Máy trạng thái hitu han (Finite State Machine - FSM) bay còn gọi là một

Olomat trạng thải hữu hạn hoặc gọi đơn gián hơn là máy trạng thái Nó là một mô

hình hành vi bao gồm một số hữn hạn các trạng thái, các chuyển tiếp giữa các trạng,

thái này, và các bảnh động, tương tự như một đề thị luồng, trong đó có thể kiểm tra

iều kiện được đáp ứng Một cách chính thức quyết

=> su€ S là trạng thái ban đầu;

=> Là bộ đầu vào (inpu0 khác rỗng hữu hạn;

30

— O là bộ đầu ra (outpuÐ khác rỗng hữu hạn và bao gồm Ø, đầu ra rỗng;

=> ô là hàm chuyển tiếp trang thi: 8: $x I$

=> 4.14 ham diu ra (output), A: $x TO

Sự khác nhau chỉnh giữa một LTS và một FSM là một FSM có đầu vào va

đầu ra luân phiên những nhãn trong khi một LTS có thế có đầu vào và đầu ra xuất hiện trong một thứ tự ngẫu nhiên Hơn nữa, một LTS được cho phép có các bộ trạng

thái vô hạn và ruột bộ Label vê hạn, trong khi một FSM phải có một bộ trạng thái

‘hou hạn và một bộ đầu vào hữu hạn Một máy trạng thái hữu hạn FSM đáp ứng trên

một đầu vào ¡ cho trước trong trạng thái s Điều này tạo ra một sự chuyển tiếp trạng

thai 6(s,i) va ddu ra 2 (s,i) M61 dai diện trực quan của một FSM được dưa ru trong

hình dưởi đây:

Hinh 2.3 Sơ đồ trạng thái cho một cửa quay

'Ví dụ cửa quay ở lối vào của khu vui chơi Ban đầu, cửa quay đang bị khóa,

ngăn không cho xâm nhập Khi nhéi đồng xu vào khc cắm ở gần cửa, cánh cửa mở

ra cho phép một khách hàng duy nhất đi qua Sau khí khách hàng đi qua, cánh cửa

khóa lại cho đến khi một đẳng xu khác được chèn vào

Đây được coi như một máy trạng thái, cửa quay có bai trạng thái Mũi tên từ chấm đen chỉ vào khóa cho biết đây là trạng thái ban đầu Có hai yêu tô đâu vào ảnh

hưởng tới trạng thái của cửa quay: đưa đồng xu vào khe cắm (coin) và đây cửa

(push), Với trạng thái cửa khóa, đẩy cánh cửa vào không có hiệu lực Đưa 1 coin

vào, trạng thái chuyển từ khóa sang mở khóa Với trạng thái cửa mở khóa, đưa tiên

31

vào không có tác dụng; nghĩa là, dua thêm coin vào thì trang thải cửa vẫn là mở

khóa, Tuy nhiên, khách hàng đây cửa, hành động push, thì sẽ chuyên trạng thái mớ

Day (push) Khoa Không cô gỉ

Mở khóa Xu (coin) Mở khóa Không có gì

bay (push) Khéa Khóa cửa quay

Bang 2.1 Háng chuyển đổi trạng thái

21,5, May trang thdi mé ring - ESM

Các máy trạng thái mở rộng (Extended State Machine - ESM) có điểm tương

đồng với những máy trạng thái hữu hạn (FSM4) nhưng nó được mở rộng với những

biến giá trị, Là một mô hình nãng cao dựa trên máy trạng thải hữu hạn truyền thống,

là một mê hình hảnh vi kết hợp của các trạng thái, các chuyển tiếp và các hành

động Ngôn ngữ mô hình ESM được sử dụng cho mô hình hệ thống trong công cụ

kiểm tra dựa trên mô hình Gmaphwalker, GVST Trong suốt sự chuyên tiếp từ trạng

thái hiện tại sang trang thai khác, các giá trị mới có thể được gán clio các biến nay

Sử dụng những biến này, chúng ta có thể làm một Irừu tượng đến mô hình của

chúng ta bằng cách làm giảm bớt việc sử dụng các trạng thái Với những biến này

chúng ta có thể xây dựng thuộc tính để có thế sử dụng giống nhự một sự bảo vệ

đành cho sự chuyến tiếp nhất định Bảo vệ ảnh hưởng hành vi máy trạng thái bởi sự chuyển tiếp kha đụng khi diều kiện cho phép |4J Rõ ràng hơn, thí ESM là một bộ

S là một bộ các trạng thái và so đại diện cho trạng thái ban đầu và soeS Ký

hiệu I đại diện cho đầu vao (input) va O 1 dau ra [19] Hơn nữa, ESM giống như

một FSM Tuy nhiên, ESM được cho phép cho bộ trạng thái, đầu vào, và đầu ra là

vô hạn Như đã đề cập, chúng tôi muốn sử dụng các biến mở rộng Để có thể sử

dụng các biến, chúng ta phải tham số hóa trạng thái đề lưu trữ những biến này, bằng không chúng ta không thẻ sử dụng các biến đó đề xây dựng thuộc tính

Sử dụng các biến chúng tôi giới thiệu miền D, nó được ký hiệu giống như là không gian của những giá trị khả dụng Bởi vì các biến bô sung, chúng ta phải thay đổi quan hệ chuyển tiếp (,) Phần tử trong ồ, là một bộ của (s, i, p, a, 0, £) và có thể

là đọc giống như "trong trạng thái s với đầu vào ¿ dưới điều kiện p, chúng ta cập nhật biến bằng hành động a, đưa đầu ra ø tới trạng thái £° Sự chuyển tiếp có thể mô

tả một cách trực quan bởi một gán nhãn từ một trạng thái này đến trạng thái khác

bằng:

ip /ao

s—et

Chúng ta cho phép bỏ qua thành phần không quan trọng Gán thuộc tính

p=True, nhận dạng hành d6ng a = id, va một đầu ra rỗng Quan hệ chuyển tiếp hiện

nay chính thức như là một bộ:

ổy €§xI x P(D) x [0] x A(D) x S

Trong mối quan hệ chuyền tiếp, đầu ra được ký hiệu là [O] nghĩa là chúng ta

có một chuỗi phần tử loại Ø Trong mối quan hệ chuyển tiếp P(D) biểu thị sự sắp

xếp thứ tự đầu tiên trên miền 7 x D, bao gồm đầu vào như tham số và A(D) biểu thị

tất cả các hành động có thẻ cập nhật những biển đó Nó không bắt buộc sử dụng các

thuộc tính và cập nhật hành động trong mỗi lần chuyển tiếp

ESM là tất định (tất nghĩa là bạn luôn có thê tính được số/việc kế tiếp

xảy ra sẽ là gì dựa trên sô/'

đã được tạo trước đó) chúng ta cần dau ra va trang

thái mới là đơn nhất đã được xác định bởi trạng thái và đầu vào hiện hành Tuy

33

nhiên, chúng ta phải đưa vào sử dụng các thuộc tính tốt Đề chúng ta có thể có nhiều chuyển tiếp hơn với đầu vào ¡ và rời khỏi trạng thái s 5,5 =(s, i, pj, ajo sj) Voi jen, biểu thị sự chuyển tiếp j này Biến giá trị X¿ cho trạng thái p là cần thiết để phân ra,

do đó X, ñ Xị = Ø; Vj # k và j, k eu

Nó không yêu cầu có một mô hình tất định, vì ngôn ngữ mô hình này cũng

hỗ trợ thuyết không tất định Dành cho mô hình là không tất định có s € S và ¡ €I với hơn một bộ trong ð Ta có cập nhật hàm chuyển tiếp vì nếu không sự chuyển tiếp và đầu ra sẽ không liên quan với nhau: S x I— P(S x Ø)

Button | n>=10/

n~=10, [Tea]

Hình 2.4 Mô hình tắt định (trái) và không tắt định (phải)

Một ví dụ cho thấy sự khác nhau giữa thuyết không tất định và thuyết tất

định được cho thấy trong vi dụ 2 [4] Trong ví dụ 2, thuộc tính được hiển thị sau khi

dấu | Các hành động cập nhật hiển thị sau khi dấu /, trước danh sách đầu ra, và đóng với một dấu chấm phẩy Trong ví dụ 2 máy coffee bên trái là tất định và máy coffee bén phai la không tất định Sự khác nhau là sự chuyển tiếp bổ sung

Button/[Tea] trong máy coffee bên phải Điều này làm máy coffee bên phải sản xuất

ra hoặc là Coffee hoặc là Tea Nó là ẩn số mong đợi cái gì khi với Button dau vào

của nó hoặc là Tea hoặc là Coffee Vì khi n = 10 và Button đầu vào được sử dụng

đầu ra sẽ là: {(n = 0, [Coffee]), (n = 0, [Tea])}

34

2.1.6 So sắnh kiêm thử hướng mãi hình và kiểm thủ thông thường

Trong chương | ta đã đi tìm hiểu tổng quan về kiểm thử thông thường và ở phần trên ta cũng tìm hiểu tổng quan về kiểm thử hướng mô hình Trong phần này chúng ta sẽ so sánh để làm rõ đặc điểm của mỗi loại kiểm thứ

Hiện nay ở nhiều công ty, kiểm thử phần mễm thường dược các kiểm thử viên thiết kế thủ công Diều nảy có một nhược điểm lớn đó là sẽ gây tiêu tốn một

lượng chỉ phí cao cho việc xây đựng, thực hiện và duy trì các bộ kiểm thứ, Đồng

thời ta không có cách truy xuất từ yêu cầu để ra ca kiểm thử, vả điều nảy đẫn đến là khi có một yêu cầu thay đổi, các kiểm thử viên đều phải kiểm tra lại các bộ kiếm

thứ một cách thủ công, điều này tạo ra một lượng chỉ phí lớn về thởi gian, công sức

và nhân lực cúa đội dự án Còn đối với kiêm thử hướng mô hình, việc tạo ra mô

hình kiểm thử ban đâu cũng tiêu tôn lượng chí phí lớn, tuy nhiên chỉ phí cho việc

đuy trì kiểm thử trong kiểm thử hướng mô hình lại thấp hơn rất nhiều dv mô hình

kiểm thir va các ca kiểm thử được tạo ra một cách thích hợp và dé đàng thay đổi Ngoài ra, khi nhìn vào một mô bình kiểm thử cũng dễ hiểu hơn là một bộ kiểm thử

Ta thấy rằng chỉ phí cho việc kiểm thử sẽ tăng din theo mức độ hoàn thành của ST, Việc sinh kiểm thử theo cách thủ công sẽ tốn nhiều chỉ nhí và sinh kiểm thử hướng mã nguồn có một hạn chế chính là việc kiểm thử chí có thể thực hiện sau khí đã phát triển xong Ngược lại, kiểm thứ hướng mô hình được tiễn hành ngay sau

khí có bản đặc tả yêu câu, cho phép tìm ra các khiếm khuyết trước khâu phát triển;

từ bản đặc tả yêu cầu ta đã có thể xây dung được các mô hình và các ca kiểm thứ để

Thực hiện kiểm thứ hệ thông Bởi việc tiến hành kiểm thử theo hướng mô hình được

bắt đâu từ sớm nên điều này rất hữu ích trong việc sớm kiểm tra lại bản thiết kế và phát hiện ra lỗi một cách sớm nhất có thể,

2.2 Các phương pháp tiếp cận kiểm thử hướng mô hình

Trong phần này ta sẽ đi vào tìm hiểu các kỹ thuật kiểm thử hộp đen thường

được sử dụng trong thực tế:

thuật tìm kiểm đồ thị

- Kiém thử ngẫu nhiên

-_ Giải thuật tìm kiểm Á-s†ar

- _ Kiểm tra mô hình - Model checking

-_ Phân lớp tương dương Equivalence partitioning

-_ Kỹ thuật đồ thị nhân - quả - Cause-Effect Graph

-_ Kiểm thử so sánh

2.3.1 Giải thuật tìm kiếm đỗ thị - Graph Search Algorithms

Nhiéu mô hình hành vi thực chất chính là các dỗ thị Các hành vi dược mô tả chính là toàn bộ của các con đường có thể đi qua những để thị này Khi đó các giải Thuật tim kiếm đề thị có thế được sử đụng đẻ tìm kiểm các con đường với những

Thuộc tỉnh nhất định

2.2.2 Kiểm thứ ngẫu nhiên

Có rất nhiều phương pháp tiếp cận việc sinh kiểm thứ có gắng trong việc

sinh ra các ca kiểm thử từ các mô hình kiểm thử một cách “thông minh” Điều này

hiện vẫn còn cần phải bàn luận rất nhiều mặc dủ những nỗ lực nảy luôn được chứng,

minh Dặc biệt là trong kiểm thử hộp đen, có rất nhiễu các thành phần bên trong không được biết đến và xác định nguồn gắc của thông tin kiểm thử là một quá trình

rất tốn kém Phương pháp thống kê cho kiểm thử như kiểm thử ngẫu nhiên là một

giải pháp hữu hiệu tong những trường hợp này

Trong phương pháp tiếp cận kiểm thử ngẫu nhiên (Random testing), ta

thường sử dụng một lượng lén các ca kiểm thử được tạo ra mà không cẩn tốn quá

nhiều công sức vào từng ca kiểm thử đơn lê Những xem xét mang tính thống kê cho thấy các khiếm khuyết thường phân bố ngẫu nhiên trên toàn bộ chương trình

36

Trong những trường hợp như vậy, kiểm thử ngẫu nhiên thường có những lợi thế hơn bắt kỳ loại kiểm thứ nào khác, Tuy nhiên với giá định rằng các khiếm khuyết thường nằm gần những vùng ranh giới có thế thay đổi nó thì kiểm thử ngẫu nhiên

lại cho thấy một hiệu quả kém hơn hẳn so với kiểm thử phân vủng (partition

1esting) Nhiều nghiên cứu chỉ ra rằng phần lớn lý do đề kiếm thử ngẫu nhiên thành

công chính là các kỹ thuật khác chưa hoàn thiện đến một mức độ nhất định hoặc các đặc tả yêu cầu cũng là một phần gây ra khiểm khuyết Nguyễn nhân chính của vấn

đề trên lại là đo sai lầm của con người, cả bên phát triển hay bên kiểm thử Chẳng

hạn như kiếm thử viên bỏ quên một số trường hợp hoặc đơn giản là không hè biết đến sự tồn tại của chúng,

Câu hỏi về khả năng ứng dụng của các phương pháp kiểm thử dựa trên xác

suất hiện vẫn dang là chủ dễ được nghiên cửu Vỉ dụ, nêu các SUT chứa một trạng

thái phức tạp bên trong, sau đó có thể chỉ có một vài chuỗi đài của các đầu với một xác xác suất rất nhỏ dẫn đến các trạng thải xác định khác Khi đó kiểm thử đựa trên

xác suất có thể đưa ra kết quả không thỏa đáng, hoặc nó sẽ cẩn một thời gian dải

cho đến khi những chuỗi này được tạo ra

2.3.3 Giải thuật tìm hiém A-star

Giải thuật tìm kiếm A-star (hay còn được gọi là Á*} là một thuật toán tìm kiểm trong đồ thị Thuật toán nảy tìm một đường đi từ một nút khới đầu tới m¿

đích cho trước (hoặc tới một nút thỏa mãn một điều kiện đích) Thị

nút

toán này sử

đụng mộ "đánh giá heuristie* để xếp loại từng nút theo ước lượng về tuyến đường

tốt nhất đi qua nút đó Thuật toán nảy duyệt các nút theo thứ tự của đánh giá

heuristic này Do đó, thuật toán A* là một ví dụ của tìm kiểm theo lựa chọn tốt nhất

2.2.4 Kiém tra nô hình

Kiểm tra mô hình (Madel Checking) được phát triển đầu tiên bởi Edmud

Clarke va Allen Emerson, sau đó được Jean-Pierre Queille va Joseph Sifakis phat

triển tiếp Đúng như tên gọi, trong kỹ thuật này các thuộc tính của một mô hình sẽ

a7