1. Trang chủ
  2. » Luận Văn - Báo Cáo

Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh

58 2 0
Tài liệu được quét OCR, nội dung có thể không chính xác
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Kiểm thử hướng mô hình và ứng dụng trong phát triển ứng dụng cho điện thoại di động thông minh
Tác giả Ngụ Hoàng Thành
Người hướng dẫn PGS.TS. Huỳnh Quyết Thắng
Trường học Đại học Bách Khoa Hà Nội
Chuyên ngành Công nghệ thông tin
Thể loại Luận văn thạc sỹ
Năm xuất bản 2015
Thành phố Hà Nội
Định dạng
Số trang 58
Dung lượng 1,06 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Tuy nhiên trong thực tế tại Việt Nam rất it công ty chủ trọng đúng mức vào công, doan kiểm thử này đo tiết kiệm chi phi, đo trình độ nhân công hoặc lý do khác trong, khí đầy là điều then

Trang 1

1.1.1 Các khái niệm liên quan trong kiếm th

1.12 Quy trinh kiém thử (TestProcess)

1⁄2 _ Tổng quan về kiểm thử hướng mô hình

1.2.1 Khải niệm về kiếm thử hướng mô hình

1.2.2 Cách Hưức làm việc của kiểm thử hướng mồ hình

1.2.3 Uu thé của kiểm thứ hướng mÖ hình

1.2.4 So sánh kiêm thử hướng mô hình và kiêm thử thông thườn,

1.2.5 Khả năng ứng dụng kiệm thứ hướng mô hình trong phát triển ứng dụng

cho điện thoại Ái động thông mini

1.2.6 Giới thiệu một số công cụ miễn phí hỗ trợ ko

2.2 Cơ sở lý thuyết án dung treng spec explorer

2.24 Trang thai (state)

2.22 Ady tao ma hink tw động (model automata

2.2.3 Chương trình mô hình (model progran)

2.24 Dipét trang “hái (State exploration)

Trang 2

Xây dựng các Ca kiểm thử (viết ra bằng cách thủ công)

g dụng kỹ thuật sinh kiểm thử tự động hướng mô hình 3.2.1 Phân tích han đầu

3.2.2 Xây dựng chương trình mô hình cho

Œ t quả chỉnh đại được trong đề tai:

Những khó khăn và hướng giải qu

Trang 3

LOI CAM DOAN

Tôi xin cam đoạn: Luận văn "Kiểm thứ hướng mô hình va img ung trong phat triển ứng dụng cho điện thoại di đông thông mình" là do bản thân tôi tự thực hiện đưới

sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng - Viện Công nghệ thông tin và Truyền

thông - Đại học Bách khoa Hà Nội,

Tác giả luận văn

Neé Hoang Thanh

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 4

thuật ngữ Từ viết đây đủ Ý nghĩa

AAT Adapter Action Langage Nes net mô hình hóa duợc sử dụng

TỰP impementation Under ‘fest | Bộ phản thực thí cần kiểm thử

MBT Model Based Testing Kiểm thử hướng mô hinh

oTc Intel Open Source Trưng tâm công nghệ mã nguồn mở

Technology Center của Intel

SUT System Under Test TIệ thông sắn kiếm thir

Trang 5

Danh mục các bảng

Tảng 2: Cá kiểm thử đã dùng với HowTo 8cene của Turle Rún - 48

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 6

Danh mục các hình vẽ

Tình 1-1: Mỗi liên hệ giữa sai sói, lỗi và thất bại - 9

Ba phương pháp cơ bản tích hợp kiểm thử vào kỹ nghệ hệ thống 14 : Cách thức vận hành của kiểm thử hướng mô hình - 16

: Quy trình sử dụng spec expÌOrer

: Nommal Traee Sample

Hinh 2-3: LoadAndSave ‘race Sample

Hinh 2-4: ShowOldMap Trace Sample

inh 2-5: Hinh anh vé model program,

Tình 2-6: Hình ảnh ví dụ về ca kiểm thứ - 36

Hình 2-7: Hinh ảnh minh hoa state trong ca kiếm thử (S32) 37 Hinh 2-8: Hinh anh minh hoa state trong ca kiém thir (S65) - - 38

Hình 3-1: Scene Flow của Turtle Rưa

Hình 3-2: Mô hình Sceneiflow của Lurtle Run

linh 3-3: Ca kiểm thứ Seenelrlow của Turtls Rune, -

Hình 3-4: Mô hình và ca kiểm thử TopScene của Turtle Run

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 7

MỞ ĐẦU

1 Lý do chọn đề tài

Kiểm thử phản mềm luôn là mội khâu vất quan trong tong việc phát triển phan

xuêm Tuy nhiên trong thực tế tại Việt Nam rất it công ty chủ trọng đúng mức vào công,

doan kiểm thử này (đo tiết kiệm chi phi, đo trình độ nhân công hoặc lý do khác) trong, khí đầy là điều then chốt ảnh hưởng lói chất lượng săn phẩm đâu ra

Khi làm việc tại một công ty phát triển phần mềm ở Việt Nam, tôi nhận thấy chất lượng của các sân phẩm luôn ở một tức mà có ruột tít thường dược sử dụng là

“chap nan được”, do đó sản phẩm công ty nẻi riêng và có lẽ là cả ngành gia cổng phin mém Việt Nam nôi chung dều chưa cỏ tiếng nỏi, chưa thẻ sánh ngang với các

wurde khác trên thể giới Ngoài ra, chất lượng của việc kiểm thử cũng là một vẫn dé nan

giải

Do dé tdi chon để tài này như một hưởng di hứa hẹn giải quyết các van dé vé chất lượng phản mềm nói chung và chất lượng ứng đụng trên điện thoại thông minh (lĩnh vực mà tôi đang phát triển) được cải thiện trong khi vẫn dam bảo chỉ phí sẵn xuất

trong khoảng cạnh tranh

2 Tính cẤp thiết của để tải

Thư dã nói ở trên, tại Việt Nam chất lượng trong việc kiểm thữ trong lĩnh vực

phát triển phan nói chung và phát triên ứng đụng cho điện thoại thông minh nói

riêng đang là một vân đề nan giới Qua quá trình từra hiểu của tác giá, vấn đề kiếm thứ phần mềm cho ứng dụng trên điện thoại đi dộng thông mình có những nguyên nhân chính sau:

®- Quy Hình kiểm thử mang rhiểu tỉnh chất chủ quan và lộ thuộc vào từng kiểm thử viên Tại cáo công ty phản mẻm vừa vả nhỏ, việc kiếm thủ chưa cỏ quy chuẩn rõ ring dẫn dến việc xây dựng các ca kiểm thử cũng nhụ việc liển hành kiểm thử phụ

thuộc rất nhiều vào cách nhìn nhận vân đề của kiếm thử viên

« Do tiết kiêm chỉ phi nên bỏ qua nhiêu công đoạn kiếm thử Các công ty phan mềm ở Việt Nam phần lớn đều dựa trên lĩnh vực “outsource” (lâm cho khách hang)

trước ngoài Để tăng lợi nhuận, giảm gió thành (tăng tính cạnh tranh), chỉ phí cho việc

âm thử thường bị cắt giảm và xem nhẹ nhật lä với các dự án nhỏ, chỉ phí thấp Rất nhiều dự án phát triển ứng dụng cho diện thoại di động thông minh rơi vào trường hợp

nay

« Kỹ thuật kiểm thử cẻn nhiều hạn chế Các kỹ thuật kiêm thủ chủ yêu là k

thứ thủ công vá phụ thuộc vào trình dộ của kiểm thử viên, trong, khi các kiểm thử viên thường không được đào tạo bài bàn dẫn đến việc kiểm thử còn hạn chế về mặt kỹ thuật

Trang 8

Tử dò dỏi hỏi cần phải có một phương, phảp, một kỹ thuật củng với ông cụ dễ

ữ, giúp cho khâu này cải thiện được chất lượng mà vẫn đâm:

lý về mặt chỉ phí Kiểm thử tự động — kiêm thử hướng mnô hình chính là một

thưởng tiếp cân hứa hen dap tmg dược các diều kiện dã để ra

3 Nhiệm vụ trong luận văn

Với mục dịch ứng dụng dược kỹ thuật kiểm thử hưởng mô hình vào phát triển

ứng dụng cho điện thoại đi động thông minh (smart phone), luận vẫn tập trung nghiền cứu cáo nội dung chỉnh saư :

« _ Tìm hiến vẻ các kỹ thuật kiểm thử và tấp trung vào kiếm thử hướng mô hình

«_ Thm liểu các công cụ, lựa chọn công cụ thích hợp,

«— Ấp đụng công cụ vào quả trình phát triển ứng dụng cho điện thoại đì động thông

«- Dánh giá hiệu quả và đưa ra các hướng phát triển tiếp theo

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

Chương ï- Giới thiêu tổng quan về kiếm thủ phần mềm và kiếm thử hướng mỗ

hình Chương này trình bảy về các khải niệm cơ bản trong kiểm thứ, tiếp đó sẽ trinh bảy về các khái niệm cũng như đặc điểm chưng của kiểm thử hướng mô hình

Chương 2: Phương pháp sử đựng công cụ kiếm thử hướng mê hình Chương nảy tập trung vào việc mô tá quy trình, cách thúc thực hiện kiểm thử hướng mô hình

thằng cách sử dụng céng cu Spee Explorer

Chương 3: Thực nghiệm và đánh giá kết quả Chương cuỗi cùng nảy sẽ trình

¡ dụng của một dự án thực tế về phát triển ứng dụng trên smart phone (phát triển game Turle Rum), đưa các kết quả khi chưa áp dụng kiểm thử hướng mô hình và sau khi áp dựng kỹ thuật này Tử đó đánh giá tru, nhược điểm của kỹ thuật đối với việc phát triển ứng, dụng trên điện thoại di déng théng minh

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 9

Chương 1 TỎNG QUAX VẺ KIỀM THU PHAN MEM VA

KIEM THU HUONG MO HINH 1.41 Tổng quan về kiểm thử

1.1.1 Các khải niệm Hiên quan trong kiểm thử

Ta sé di tim hiểu một vải thuật ngĩữ cơ bản trong kiếm thủ Trong dé tai nay ta sé

sử dụng thuật ngữ LUI' (Implementation Under Test) hoặc SUT (System L/nder '[øst)

đêu mong ý nghữa là phần thực thi hoặc hệ thông đăng cần được kiểm thử Ta có thê hiểu đơn giản day là đổi tượng ta đang muốn kiểm thử nó

11.11 Sai sói, Lỗi, Hồng hóc

Tây là ba thuật ngit co ban của việc kiếm thử mã ta cân phải làm rõ

Dinah nghĩa 1 — Sai sải(F nu: Là một sai sét “tĩnh” trong hệ thông [9]

“Định nghĩa 2 ~ LÃi (Error): Là một trạng thái nội bộ của hệ thông xây ra sai sốt

khi hệ thông đang được vận hành |9|

Định nghĩa 3 — Thất bại (Fatlure): Là sự sai khác cô thễ thẫy được trong thực

tế của hệ thông so với đự kiến [9]

Sơ đỗ sau thê hiện môi quan hệ giữa sai sót, lỗi và thất bai

Tình 1-1: Mắi liên hệ giữa sai sói, lỗi và thất bại

Su dé trên biểu (lu quá trình phát sinh thất bại của hệ thống bắt dầu từ những sai sót, những sai sót này trong quá trình hệ thống được thực thi sẽ tạo ra lỗi làm cho kết quế của hệ thông không đúng như chúng ta mong muốn vả tạo ra thất bại

Vậy đầu là nguồn gốc của những sai sớt? “Ta có thể quy nguyên nhân của những,

sai sót về ba nguyên nhân chính sau:

Thử nhất, cẩn phải kể đến là những sai lằm, thiểu sót trong yêu cầu của hệ

thông, "Trong trường hợp nàt sự hệ thông dã thiếu mất một sỏ trường hợp sử dụng,

của hệ thống hoặc thiểu định nghầa những hành động mã la cưng muốn hệ thông thực hiện Những sai sót thuộc loại này có thế được phát hiện bằng việo phân tích yêu cầu

Trang 10

‘Tint hai, 1a các sai sót liên quan đến chức năng của hệ thống, ví dụ như việc sai khác giữa đặc tả kiểm thử với kết quả của thực li của hệ thống trong khi kiểm thủ Sai sót này thường xảy ra đo thiểu sót trong quá trình phát triển, cải đặt của phản mềm hoặc do phần cứng Sai sót loại này có thể dược phát hiện bằng kiểm thử chức năng

Ol này gắn liễn với những đặc

Thứ ba, là các sai sói phi chức năng Những s

tả phi chức năng của hệ thống như hiệu năng, tỉnh bảo mật, tính mở rộng, tính tương thích của hệ thống, ĐỂ có thể phát hiện các sai sót loại này la cần có những phương pháp tương ứng với từng đặc điểm phi chức năng cụ thể Ngoài ra ta cũng có thế phát

“hiện các sai sót loại nảy trong quả trình thực thị hệ thông để kiểm thứ

Trong phần này La số lnn rõ các khôi niệm liên quan, từ đó đua ra khái miệm đâu

là kiểm thứ và đâu không phải là kiểm thứ

Kiém thit (testing) trong thực tả có thê vừa là thẩm định (falidation) vừa là kiểm chimg (Verification) |9} Trudc bél ta edu hidu thậm định và kiểm chứng là gì

Dinh nghĩa 4 — Thẫm định (validation): Thắm định là quá trình đánh giá một

tệ thống đã đảm báo rằng nó pluù hợp với đặc tả hoặc mục đích sử dụng [9]

Định nghĩa 5 — Kiém ching (verification): Kiém chứng là quả trình xác mảnh kết quả của một giai đoạn phái triển hệ thống có thực hiện đúng và đầy đã yêu câu được đưa ra ở giai đoạn trước đó hay không [9]

'ta có thể hiểu một cách đơn giản hơn là kiểm chứng sẽ phát hiện ra lỗi lập trình, tức là tìm ra sai khác giữa hệ thống ta lạo ra với những yêu cầu đã được để ra Còn

thâm định sẽ phát hiện ra hệ thông có đáp ứng đứng như cầu thực tế hay không, đo đó

‡a có thẻ phát hiện ra lỗi thiết kế ở nức cao hơn kiểm chứng

Định nghĩa 6 — Kiểm thữ (Tesing): Kiểm thử là quá trình đánh giá mật cách có

hé théng (systematically) mét hệ thông băng việc quan sát hoạt động của nó [S]

Định nghĩa 7 — Gỡ lỗi (Debugging): Gỡ lỗi là quá trình tim ra sai sót din dén thất bại của hệ thống |9]

Dinh nghia 6 cho ta thay 16 rang, kiểm thử vừa có thể là thấm định, vừa có thế la

kiểm chủng Lhông thường kiểm thử viên sẽ tạo ra các ca kiểm thứ từ đặc tá yêu cầu cửa hệ thống một cách thủ công, khi đó việc kiểm thử chính là kỹ thuật thẩm định hệ thông Đối với kiểm thử hướng mê hình, ca kiểm thử thường được sinh tự động từ mé

tả của hệ thông thi khi đó kiếm thứ lả việc ta xác rminh lại kết quá thực thủ của hệ thống, đối với các ca kiểm thử này, lúo đó kiểm thủ chính là kỹ thuật kiểm chứng,

Ở đây ta cần phân biệt kiếm thử và gõ lỗi Có thể hiểu rằng kiếm thử là quá

trình thm ra thất bại trong khi gỡ lỗi là quá trình xác định sai sót tạo ra các thất bại đó

Trang 11

1.1.1.3 Một số định nghĩa thuật ngữ liên quan khác

Định nghĩa 8 — Ca kiểm thứ: Miột ca kiểm thứ là một bộ các giá trị đầu vào và

thành vị mong muốn tương ứng của hệ thẳng, Trong để tài này ta sé sit dung từ “ca

kiểm thử” ứng với khái niệm này.[L1]

Dinh nghia 9 — Cũ kiếm thử trừu tượng: ca kiếm thử trùu tượng là ca kiếm thử bao gốm những thông từn trừu tượng vẻ dầu vào cũng như dầu ra Ca kiểm thử loại nảy thường không chứa các giá trị của tham số cụ thể hoặc là tên của các chức năng [1 1]

Ca kiểm thử trừu tượng thường là bước đâu tiên trong việc tạo ra ca kiểm thử

Chúng thường dược sử dụng để dưa ra ý tưởng vẻ câu trúc của ca kiếm thử hoặc thông,

lệc thỏa mãn các tiêu chí Các thông tin cản thiếu sẽ được thêm vào ca kiếm thử

Định nghĩa 10 — Cú kiểm thử cụ thế: Một ca kiểm thủ cụ thể là một ca kí

thử trừu tượng cộng thêm toàn bộ thông tin cụ thé bi thiến để thực hiện ca kiếm the]

Ca kiểm thứ cụ thể bao gồm thông tin hoàn chỉnh và có thẻ được thục hiện trong quá trrnh kiếm thử toàn bê hệ thống, To đó với một ca kiếm thử đơn giãn thường không đủ để tạo ra quả trình kiểm thứ cho kết quả cao

Định nghĩa 11 — Hộ kiểm thứ (test suife): Một bộ kiểm thử là một tập hợp các

ca kiểm thử Trong đề tải này ta số sử dựng “bộ kiểm thủ” ứng với khái niệm nảy

Các khái niệm về bệ kiểm thử trừu tượng và cụ thế có thé được định nghĩa

tương tự như định nghĩa về ca kiếm thứ [11]

Định nghĩa 12 — Tiêu chuẩn kiểm thứ (test oracle): Một tiêu chuẩn kiểm thủ là

một bộ bao gồm các hiểu biết về hành vĩ mong mudén cra SOT [11]

Mỗi một ca kiếm thử bất buộc phải có một vài thông tin tiểu chuẩn để ta có thể

so sảnh được kết quả quan sát trực tế với hành vị mong, muén cia SUT Né lêu ta không,

có những tiêu chuân này thì việc kiểm thử sẽ không thế tầm ra được thất bại Các tiêu chuẩn thường gặp là mong muốn oủa người dùng, các sản phẩm khác để so sánh, phiên bản trước dây của chính hệ thống, những suy đoán về mục dich sử dụng, các tiêu chuẩn

liên quan đến huật pháp hoặc thông số đặc tâ kiểm thử

Định nghĩa 13 — Dặc tả kiểm thit (test specification): Mit dio 1ã kiểm thử là một mô tả về môi trường của hệ thống hoặc các hành vi mong muốn của hệ thông Những đặc tà này được sử dụng để tạo ra các bộ kiếm thử đồng thời cũng được dùng

để so sánh giữa bảnh vị mong muốn và hành vị quan sát được của hệ thống [L1]

Đặc tả kiểm thử dược dùng để tạo ra các bộ kiểm thử Hai đặc tả có thẻ khác

nhau ở một số khia cạnh như khía cạnh trừu tượng hoặc hinh thức Đặc tả kiểm thử thường là kết quả của sự thỏa thuận giữa bên cung cấp hệ thông và khách hảng, trong,

đó phần quan trọng thường được mô tả một cách kỹ cảng, phân íL quan trọng hơn

được mô tã sơ sài hơn Thông thường tiêu chí để đánh giá đâu là phân quan trọng sẽ

Trang 12

dựa trên mong muồ l& hậu quả có thể cỏ của thất bại Để có thể

thực hiện được các bộ kiếm thữ ta cân đến các công cụ kiếm thử và các bộ khung kiểm

thu

Định nghĩa 14 — Công ox kiém thit (test software): Công cụ kiêm thử là một

loại phần mêm được sử dụng trong quả trình kiêm thử Thỏ biến nhất là các test

generator, các bộ khung kiểm thứ, vả những bộ kiểm thử được tạo ra từ chúng [11]

Định nghĩa 15 — Hộ khung kiém thit (test framework): 136 khung kiém thir 1a

xnột bộ khung (Eamework) với mục dích tự động hỏa quả trình kiểm thử, thục thi

bộ kiểm thứ và tự động sinh ra các bao cáo tương ứng [11]

Các #amework thường cung cấp khả năng tụ động hỏa ở một mức nhất định

xảo đó Ví dụ: TƯniL (Java) hoặc CppUnit (CĐ) là bộ khung kiểm thữ cho phép định nghĩa một cách đơn giãn, tích hợp và thực thì ở mức troit test

1.1.2 Quy trình kiểm thử (Lest Process)

Có rất nhiễu cấp độ trừu tượng mà việc phát triển hệ thống có thế đạt được từ việc phân tích yêu cầu cho đến việc thực hiện các đoạn mã, Kiểm thứ có thê được thực Tuện ở tải cả các cấp độ trừu tượng này Do đó chúng 1a cần xem xét các cấp độ kiểm:

thủ khác nhau đựa theo mê hình chữ V (V-model) rồi từ đó sẽ là quả trình tích hợp quy

trình kiểm thử vào kỹ nghệ hệ thông (system engineering)

1.1.2.1 Củc cấp độ kiểm thữ trong V^ModeL

Có rất nhiều mô hinh mö tả cho ta làm thế nảo đẻ quản lý việc phát triển hệ

thống, trong đó nổi bật nhật là mô tình chữ V (V-modeb V-moiel là viết tắt của

Verification software development mode! (mé hinh phat trién phan mém xác minh)

Cũng tương tự như các mô hình khác về vòng, đời phát triển của phân mễm (mỏ hình thác nước, mô hình xoắn ốc, .) V-model dua ra các giai đoạn chính trong quá trình

phát triển phần mềm Trong V¬modcl ứng với từng giai đoạn phát triển phan mém khác nhau ta có các cấp đô kiếm thử khác nhau Hình dưới đây sẽ cho ta thây rõ hơn vé V- model

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 13

Từ hình vẽ lrên ta thấy được bốn cấp độ khác nhau của kiểm thữ Lương ứng với

bến giai đoạn kháo nhau trong quá trình phát triển phân mềm

Kiểm thử đơn vị: Là cấp độ thấp nhất của kiếm thủ trong V-model Trong

thử đơn vị cá tả kiểm thử sẽ được xây dụng dựa tiên thiết kế chỉ tiết của hệ thể

Mục đích chính của kiểm thử đơn vị là tìm ra các lỗi vẻ mặt lập trình, các lỗi đữ liệu,

lỗi xử lý logic của từng chức nắng trong SUT

Kiểm thứ tích hợp: Trong kiểm thữ tích hợp đặc tả kiêm thử dược xây dung dua

trên thiết kế hệ thông Mu đích của kiếm thử tích hợp giống như tên gọi là tim ra các lỗi về liên kết giữa các thành phần, các chức năng trong SUT

Kiểm thử hệ thống: Mục đích cửa kiểm thử hệ thống là xem xéL loàn bộ hệ

thông đã được xây dụng nên có thực hiện đúng theo đặc 1ä hệ thẳng được đưa ra từ ban đầu hay không,

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 14

Kiểm thứ chấp nhận: Mục tiều ctta ki

r như cầu thực tế

thử chấp nhận lä xác minh lại tình dúng, Ngoài ra kiêm thữ chấp nhận còn đánh giá

Ta có thể nhận thấy rằng kiểm thử chấp nhận chỉnh là quả trình thấm dịnh (validalion) còn kiểm thứ đơn vị, kiếm thử tích hợp, kiểm thử hệ thông lá quả Irùh +iêm chứng (verification) tĩng với định nghĩa đã niêu trên

1.122 Tích hợp quy trình kiểm thử trong kỹ nghệ hệ thông

_ Ta có ba cách thức cơ bản để tích hợp quy trình kiếm thử trong phát triển hệ

thong Do la: fa) Kiểm thứ sau khi phát triển, (b) tực hiện kiêm thử và phát triển hệ

thông song song với nhan, và (©) bi đâu bằng việc kiếm thử (test-driven development)

Linh sau sẽ thể hiện ba cách thức này

phat triển song, phát triển

Hình 1-3: Ba phương pháp cơ bản tích hợp kiểm thử vào kỹ nghệ hệ thống

phát hiện ra thất bại trong SUT Những thất bại mày thường do việc thiêu đây đủ hoặc

sai khác so với yêu cầu, Dối v phương pháp này thì việc thay đổi yêu cầu sau giai

doạn triển khai sẽ dẫn đến việc tăng cao vẻ củu phí |3

Trang 15

Kiểm thứ và phải triển hệ thẳng song song với nhau: Thực tế cho thấy thời

gian dành cho kiểm thử rất hạn chế, vì vậy ta (hưởng mong muốn có thế bắt đầu việc

kiểm thử cảng sớm cảng tốt Việc xây đựng các bộ kiểm thử và SUT đồng thời nhằm phục vụ cho mục dịch: hệ thông dược kiểm thử ngay khi có thể, Với phương pháp này,

sai sót được phát biện sớm hơn, kéo theo người quân lý đự án có thé dua ra được xử lý

sớm hơn phương pháp (a), tuy nhiền vẫn dễ sai sót về yêu cầu được tìm ra sau khi triển

khai vẫn còn tên tại nên phương pháp nay vẫn đòi hỏi chỉ phí lớn [3]

Phat trién hệ thẳng dựa trên kiễm thử (kiểm thứ: trước phát triển): Là phương, pháp mả các ca kiểm thử được tạo ra trước khi bắt đầu triển khai hệ thông Jo dé ca kiểm thử số thất bại trước tiên, và nhiệm vụ của việc phát Iriển hệ thông là làm sao có thể vượt qua được các ca kiểm thứ Khi ta viết ra việc kiếm thứ trước khi triển khai thì

số lượng hay đôi oan thiết của yêu câu trong pha triển khai sẽ được giảm xuống Tuy nhiên điêu này có thể kéo theo việc các SUT sẽ chỉ được triển khai với mục liêu là tránh việc phát hiện ra thất bại |3|

1.2 Tổng quan về kiếm thử hướng mô hình

1.2.1 Khải niệm về kiểm thử hướng mô hình

_ _ Kiém thử hướng mô hỉnh thường mang nghĩa kiểm thử chức nắng với các đặc tả

n thử dược dựa trên một mô hình kiểm thứ Mỏ hình kiếm thứ dược bắt nguồn từ

phi chức năng Trong kiếm thử hưởng mô hình, các bộ

kiểm thử được đưa ra mội cách tự động (hoặc bán tr động) từ các mô hình kiểm thử Kiểm thứ hướng mồ hình có thể được áp đựng tại tất cá các cấp độ kiểm thử từ kiểm

thử dơn vị dếu kiểm thử hệ thó

Kiểm thử hướng mô lủnh được coi là ruột phương pháp hình thức gọn nhẹ dễ

kiểm chứng các hệ thông phần mềm [8]

Kiểm thử hướng mô hình là một phương pháp hình thúc vi nó tạo ra các đặc tả

kỹ tuật (hoặc mô hình) của SỤT theo một cách thức xác định (có ng]ữa là máy tính có thể đọc được) Nó gạn nhẹ bởi vì, trái với phương pháp hình thức khác, kiếm thử hướng mô hình không, chủ trọng véo toán học chứng mình rằng, phần thực thí phủ hợp với đặc tả trong mọi trường hợp có thể, Những gì kiểm thử hướng mô hình làm là sinh

xa một bộ kiểm thử từ mô hình một cách có hệ thông, sau dó thực thi kiểm thử trên SUT với việc lin rằng SỤT sẽ thực hiện theo những gì mà mỗ hình thể hiện

Sự khác nhau giữa phương pháp hình thức “gọn nhẹ” và “nặng nhọc” dựa trên

việc tin tưởng hay đảm bảo hoàn toàn Sự đảm bão hoàn toàn ở đây có thể hiểu là mức

đô áp dụng phương pháp này trong phát triển hệ thông sẽ đảm bảo hệ thống khi van

hành sẽ cho ta kết quả giống hệt kết quả kiếm thủ, đảm bão rằng tất cả trường hợp có thể xây ra (với một mức độ nào đỏ và dược chứng minh bằng các lý Huyết (oán học) ta déu đã kiếm soát được Trong thực tế chỉ phí cần thiết cho sự đảm bảo hoàn toàn

Ngô Hoàng Thành Tớp 12BCNTT2 — Khóa 2012B

Trang 16

thường rất dắt (dôi khi la cực kỹ dất), vi vậy kiểm thứ hướng mồ hình sẽ là một phương,

pháp lĩnh hơạt hơn, thích hợp áp đụng chơ các dự án chỉ phí thấp

1.2.2 Cách thức làm việc của kiểm thứ hưởng mổ hình

Kiểm thử hướng mô hình là kỹ thuật kiểm thử tước khi xây đựng phẩn thực thị

Do đẻ các đặc tà kiểm thử và các ca kiểm thử được tạo ra trước khi ta xây dựng phần mềm Từ những ca kiểm thử này ta có thể dánÌ: giá lại dược tính đáng dắn của mô hình cững như của yêu câu đầu vào và có những điền chỉnh phù hợp trong khi xây dung phân thục thị 11ình sau sẽ thể hiện cách thức làm việc của kiểm thử hướng mô hình [8]

Tĩnh 1-4: Cách thức vận hành của kiểm thử hướng mô hình

(NG: No good trường hợp không thỏa mãn một yêu câu nào đỏ)

"trong kiểm thứ hưởng mô hình, đầu tiên từ yêu câu của hệ thống ta sẽ xây dung

lên mô hình tương ứng Từ mmô bình nảy la sẽ sinh ra các cá kiểm thử Do mô hình

được xây dựng theo những chuẩn đặc tả xác định từ trước nên việc sinh ra các ca kiếm

thử này hoàn toàn có thể bự động hỏa Việc sinh ra các ca kiểm thử ngay tại giải đoạn

nảy cũng thẻ hiện tính chất của kiểm thử hướng mô hình là một phương pháp kiểm thử

trước khi phát triển Ngoài ra từ mô hình xây dựng, dược ta có thẻ dựa lại các phản hỏi,

ái hợp lý đến các yêu cần của hệ thống đề có những điều chính hợp lý

cca kiểm thử đã được sinh ra ta có thế xác định được những vẫn đề của

mồ hình cũng như của hệ thông trước khi phát triển, và từ đó có thể đua ra các phản

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 17

‘héi đến cá mô hình, yêu cầu ban dầu cũng nlưư phản thực thi (bộ phận trực tiép phat

triển hệ thông)

1.2.3 Ưu thế 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 Irong việc kiểm chứng,

(verification) phan mém hướng mồ hình Có rất nhiều ưu điểm của kiêm thử hướng mô Từnh như sau:

« Thứ nhất, mô hình kiêm thử được sử dựng thường xuyên thường khá nhỏ,

hiểu, để dàng bảo trì

«_ Thứ hai, việc sử dụng các mô hình kiểm thứ thường cho phép ta truy xuất nguồn

gốc từ yêu cầu đến ca kiểm thử

œ_ Thứ ba, kiểm thử hưởng mô hình có thể được sĩ dụng cho kiểm thử sau khi phát

triển hệ thống tốt như phương pháp test-first (Œest-driven) Như đã để cập đền trong

phân 1.1.2.2, các phương pháp kiểm thể trước khi phát triển sẽ giúp la giảm được chi 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 †a tìm ra dược các sai sớt và mâu thuần trong yêu cầu

« Thứ tư, cũng chỉnh là ưu diễm mà dẻ tải tập trung váo: có thể sinh kiểm thử tự động (automatic tes generation) tix cdc mé hình Túc là tô hình kiểm thử có thể được

sử dụng để tạo ra các bộ kiểm thủ từ nhỏ đến rất lớn thỏa mãn một tiêu chuẩn tương từng một cách tự đông Điều này cho phép ta tạo ra dông thời các bộ kiểm thử nhỏ, thực

tiện nhanh hoặc là các bộ kiểm thử lớn với lượng sai sót có thẻ phát hiện được lớn

1.2.4 So sánh kiểm thử hướng mồ hình và kiém (hi thông thường

1rước tiên, kiểm thủ thông thường (eowertional (esting) ở đây ta ngầm hiểu là

hai phương piúáp: tạo kiểm thử thủ công hoặc tạo kiểm thử tự động đựa lrên mã nguồn

(eoda-based tast generation)

Trong nhiễu công ty, kiểm thứ được thiết kế thú công bởi kiêm thử viên hoặc bởi người phát lriển, cả bai cách này đều có uu — nhược điểm của nó Tuy nhiên muội nhược điểm chung là chúng ta cẩn có một lượng chỉ phí cao cho việc tạo ra, 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à hệ quả của nó là với mỗi một thay đối yêu câu ta đêu cân kiểm tra lại các

bộ kiểm thử một cách thủ công, diều này tạo ra một lượng chỉ phi lớn Đôi với kiểm thữ hướng mô hình, việc tạo ra mô bình kiếm thử ban đâu cũng tiêu lồn lượng chỉ phi

cao, tuy nhiên ngược lại với kiểm thứ thủ công, chỉ phi cho việc duy trì kiểm thứ trong

kiểm thử hưởng mỏ bình lại thấp hơn nhiều đo: Mô hình kiểm thữ dược tạo ra ruột cách Thích hợp một lẳn vá sau đé toàn bộ bộ kiểm thử sẽ được sinh ra một cách tự động, Ngoài ra, mồ hình kiểm thứ thường để hiểu hơn là bộ kiểm thứ

Trang 18

Trong phương pháp sinh kiểm thứ tự động dựa trên mã nguồn, mã nguồn của he thông được kiếm thử theo hướng chức năng Có rất nhiêu thiết bị và mô hình

để chạy nã nguồn, từ đó cho phép từm ra được sự thiếu nhất quán trong luồng điều khiển và luồng dữ liệu (thường sẽ là nguyên nhân chính gây ra những hành vị không, mong muén cia hé théng — vi du nhu bệ thống bị treo chẳng hạn) Do các thiêu sót

hoặc dư thừa của các đặc tã kiểm thử, kiểm thử trướng mã nguồn không phát hiện dược

các sai sót chức năng cũng như phát hiện ra việc thiêu sót chức năng,

Ta đều thầy rằng chỉ phí cho việo kiếm thử sẽ tăng đân theo mức độ hoàn thành của SUT Việc simh kiểm thử theo cách thú công sẽ tổn nhiêu chỉ phí, trong khi sinh kiểm thử hướng mã nguồn có một tran chế chính là việc kiểm thữ chỉ có thể thực hiện sau khi đã phát triển xong Ngược lại, kiểm thử hướng mô hình cho phép tìm ra các sai

sót (rước khâu phái Iriển Việc tạo ra các mô hình thử nghiêm chính thức và thống nhất

sẽ giúp cho việc phát hiện những, mâu thuẫn trong bản thân đặc tả yêu câu

1.2.5 Kha nang ing dung kiểm thử hướng mô hinh trong phát triển ứng dụng

cho điện thoại di động thông minh

125.1 Đặc trưng của riệc phát triễn ứng đụng trên điện thoại đi động thông mình

Qua quá trình làm việc tục tổ của tác giả trong lĩnh vực phát triên ứng dụng nói

chung va trỏ chơi nói riêng cho điện thoại đi động thông mình, tác giả nhận thấy việc phát triển ứng dụng cho điện thoại di động thông mình tại Việt Nam có những đặc

trưng sat

« Môi trường phat triển và môi trưởng ứng dụng là hoản toản khác nhau: Dây là đặc điểm chung chia việc phát triển ứng dụng cho điện thoại đi động thông mình, khi

mà môi trường phát triển ứng dụng là máy lính cá nhân (hệ điều hành window hoặc

OSX) trong khi ứng dụng thực tế được cải đặt và sử dụng trên điện thoại di động thông,

mình (hệ điều hành phố biến hiện nay là Android và iOS) Vi vậy việc kiểm thử thực tế

dều tập trung vào việc quan sát hành vi của ứng dụng trên thiết bị thật một cách thủ

công

œ- Ngôn ngữ lập trình cổ định: Đối việc phái triển ứng đụng trên điện thoại đi động

hiện nay, ngôn ngữ sử dụng phố biển trên Android là Java, trén iOS la ObjC va Swift Các ngôn ngữ lập trình khác sẽ gặp nhiều hạn ché khi phát triển các ửng dụng trên diện thoại đi động thông mình Hiện nay đã có nhiễu công cụ phát triển không phụ thuộc vào nên tăng ứng dạng (cross-platform) sử dụng các ngôn ngữ lập trình khác (phổ biển

là C# voi Unity, Xamarin), tuy nhién trong : nhiều trường hợp ta vẫn cản sử đụng Java

với Android (hoặc ObjC, Sw1ft với 10'S) để có thể thực hiện được các chức năng cần

thiết và tích hợp vào trưng công cụ phát triển đã nêu

«_ THời gian phát triển ngắn (2 dến 6 tháng): Trên thực tế các ứng dung trên diện

thoại đi động thông minh cũng có thể chia ra nhiều mức độ phụ thuộc vào chỉ phí, quy

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 19

mồ, thời gian phát triển Tuy nhiên thực tế cho thây tại Việt Nam, số lượng các ủng,

đụng phải triển trong thời gian ngắu (từ 2 đến 6 tháng) chiếm đa số Kéo theo đỏ chỉ phí cho việc phát triển các ứng đụng này thường hạn chế và điều này khiến công đoạn

kiểm thứ thường bi coi nhe dé dam bảo lợi nhuận

1252 Khả năng áp dụng kiếm thữ hướng mô hình trang phát triễn ứng dung cho

điện thoại di động thông nưình

ức độ phù hạp:

Như đã trình bày ở trên (mục 1.2.1), kiếm thử hướng mồ hình là một phương pháp kiểm thứ gọn nhẹ đã kiểm thứ hệ thống Ta thấy rằng kiểm thứ hưởng mô hình không tập rung vào việc đâm bảo hoàn toàn ứng dụng sẽ phủ hợp với đốc tả trong mọi

trường hợp có thê Trên thực té do đặc điểm đâu tiên của việc phát triển ứng dụng trên

điện thoại di động thông mình Ủủ việc đảm bảo hoàn toàn gần như là không khả thí

Trái lại, tính chất “gon nhẹ” của kiểm thử hướng mô hình lại hoàn toàn thích hợp với dic điểm trên Xét trên một khía cạnh nào đó, khi phát triển ứng, đụng cho diện thoại dĩ động Thông minh, 1a tin rằng việc phát triển trên nên tảng phát triển sẽ cho ta kết quả trên nên táng từng dụng là tương đồng nhau

Kiểm thử hưởng mô hình dòi hỏi việc xây dựng mô hình theo một cách thúc xác định (48 may tính có thể đọc được) Điều này rất đề áp đụng vào phát triển ứng dụng cho điện thoại di động thông mình khi ngôn ngữ lập tĩnh cho các ứng dụng nảy là cố định Œava, ObjC, SwifL hoặc Ơ# dối với công cụ không phụ thuộc nên tầng),

Ngoài ra, đo tính “gọn nhẹ” của kiểm thữ hướng mô hình đem Tại cho ching ta

xuột phương pháp kiếm thứ húa hẹn tiết kiệm chỉ phí, điều nảy phủ hợp với đặc điểm

đa phân cáo ứng dụng trên điện thoại di động thông trình là những ứng dụng phảt triển

trong thời gian ngăn, chỉ phí thấp

Các hạn chế:

Tuy nhiên, kiểm thử hướng mô hình khi áp dụng vào phát triển ứng dụng trên điện thoại di động thông, minh cũng sỏ những rào cắn vả hạn chế nhật định

Trước hết cũng chính do đặc điểm đầu tiên của việc phát triển ứng dụng trên

điệu thoại đi động thông mình mã việc lự động hóa khi áp dựng kiểm thủ hướng mô

trình sẽ gặp nhiều hạn chẻ

Sau đó, do hạn chế về số lượng ngỏn ngữ lập trình đẻ phát triển ứng dụng kẻo

theo việc lựa chọn công cụ hỗ trợ kiểm thủ hưởng mỗ hình trong phát triển ứng dụng,

trên điện thoại di động thông minh sẽ gặp nhiều khỏ khăn Trên thể giới hiện nay có

nhiều công cụ hỗ trợ kiểm thử hướng mô hình, tuy nhiền không phải công cu nào cũng,

có thể áp đụng trong phát triển ứng dụng cho điện thoại đi động thông mính Ta sẽ tìm hiểu sơ qua về các công cụ đỏ trong phần sau

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 20

Ưu diém:

« Có thể cải đặt và chạy trên cả môi trường Linux (bao gồm cả Ubuntu va Fedora)

va window

«Do việc kết hợp AAL vớ

đựng mô hình để tiếp cận và nằm bắt đối với lập trình v

œ- Được Inel ứng dụng thứ nghiệm trên các hệ thống khác nhau nên tính tin cây và

iệu quả của cổng cụ này đã được kiếm chúng

« Có hỗ trợ kiểm thử hưởng mô hình trên Android

TorX là một công cụ do nhỏm nghiên cứu về các công cụ và phương pháp hình

thie (Fonual Methods and Tools) tai truémg WT (University of Twerle) cia Ha Lan

dưa ra Công cụ nảy hỗ trợ rất nhiều ngôn ngữ mồ hình hỏa (ngôn ngữ dễ mô tä mô

Từnh) khác nhau để xây dựng mỗ hit Ngôn ngữ lập trình được hỗ trợ chink 1a ƠI 1 và Java [12]

Trang 21

« Ngdén ngit mé hinh héa déc lập với ngôn ngữ lập trinh nên khó nắm bắt hơn đối

với lập trình viên

1.263 Spec Explorer

Spec Lxplorer lả công cụ hỗ trợ kiềm thứ hướng mô hình do Miorosoft phát triển

và tích hợp vào trong Visual siulio Công cụ này sử đụng Cord Scripting Language kết

hẹp với C# dé xây dụng mô hình Ngôn ngữ lập trình được hỗ trợ là Cử [6]

Uu điểm:

« Được tích hợp cùng với Visunl suadio (là một bộ công cu lap Irình đẩy đủ do Microsoft phát triển)

«Ngôn ngữ mö hình háa sử đụng Cord Seripting Language kết hợp với Cử nên đã

tiếp cận với lập trinh viên

«_ Hỗ trợ ngôn ngữ lập trình C# nên hứa hẹn khả năng kết hợp với các công cụ phát triển ứng dụng cho điện thoại đi động thông ruinh không phụ thuộc nền tảng (Unity, Xamarin),

«- Giao điện đồ họa trực quan, đễ sử dụng

“Nhược điểm:

«œ Chỉ cải đặt được trên wimdow và đi cùng với VisunÏ siudho

«- Ngôn ngữ lập trình hề trợ là C#mả đây không phải là ngồn ngữ mà bản thân các

niên tăng điện thoại đi động thông mình hỗ trợ Do đỏ cần phải kết hợp với các công cụ không phụ thuộc nền tảng khác

Do đặc diễm đề sử dụng, dễ tiếp cận dối với lập trình viên dòng thời hửa hẹn khả

xăng kết hợp cũng các công cụ phát triển không phụ thuộc nên láng cho điện thoại di động thêng minh khác (Unity, Xamarin) nên đề tải sẽ lựa chọn spec explorer làm công

cụ đề áp dụng kiểm thử hướng mồ hình vào phát tiểu (ng dụng cho điện thoại di dông thông mình

13 Kết chương

Chương 1 dã trinh bảy được:

«Vẻ kiểm thử nói chưng

> Cac dinh nghĩa cơ bản về kiểm thứ nói chung,

3% Một số quy trình kiến thử cơ bản

kiểm thử hướng mô hình

> Đưa ra khải niệm cơ bản về kiểm thử hướng mồ hình

3 Tùn hiểu cách thức hoại động của kiểm thử hướng mô hình

> 8o sánh kiểm thử hướng mô hình với thử thêng thường

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 22

> Banh gia khả năng áp dụng kiểm thử hướng mô hình vào phát triển ứng dụng,

cho điện thoại đi động thông mình - _

> Giới thiệu và so sánh một số công cụ miễn phí hỗ trợ kiểm thứ hướng mô hình

Từ đó ta có những cải nhìn tổng quan sau:

©) Kiém thử là một quá trình quan trọng, có thể được ứng dung trong bắt kỳ khâu

Tiảo của quá trình phát triển hệ thông

* _ Có nhiều phương pháp áp đụng các kỹ thuật kiếm thử trong quá trình phát triển

hệ thống, trong đỏ cần kể đến phương pháp “Lest-driven System IDevelopment” là phương phấp xây dựng ca kiểm thứ trước khi phát triển hệ thống thực thí

« Kiểm thử huởng mô hình là một trong những phương pháp “Test-driven System

Development” vái việc kiếm thử được sinh ra dựa trên mô hình

«_ Kiểm thử hướng mỏ hình cho phép ta tự động hỏa quá trình kiểm thứ

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 23

Chương 2 SU DYNG CONG CY SPEC EXPLORER DE

CAC CA KIEM THU TU DONG

2.1 Đặt vấn dé

Trong phản trên ta da tim hiểu dược tổng quan và những kiến thức chung nhát

về kiểm thữ và kiếm thử hướng mỗ hình Sang phan nay ta sẽ đã vào Lm hiểu một công

cu (tool) cu thé dua trên kiểm thử hướng mô hình để tự động sinh ra các ca kiểm thử

(và có thế là cả Isst cođe, đẳng ngiữa với việc ta có thể thực thi quy trình kiểm thử

"hoàn toán tự động)

Công cụ mả đề tải lựa chọn lim hiểu là Spec Lixplorer đo Microsoft phát triển và

dược phái hành hoàn toàn min phi khi di kèm với visual studio Bộ công cụ này dược xây dựng, dựa trên ngân ngữ lập trình C# và Cord Scripting Language giup ta có thế xây dựng mô hình, liên kết với phản thực thì (SƯT) và smh ra các ca kiểm thứ Ở đây

ta sẽ tập trưng vào việc sinh ra các ca kiểm thử dụa trên mô hình một cách tự động

mặt bản chất, kiểm thử hướng mô hình cho phép ta có thể tự động hóa quá trình kiểm thử từ việc sinh ra ca kiểm thứ cho đến việc tự động chạy ủng dụng vả đưa

ra kết quả kiểm thứ khi chạy ứng dụng đó Tuy nhiên, đo đặc muốn kiểm thử ứng dụng, mệt cáo tự động đôi hỏi chúng ta phải xây dựng một bộ mã tương thích (adapter) hay

ri kiếm thit và dụa vào đó để xây dựng ứng đụng Với đác [hủ của ứng dụng di động, nên tảng của ứng dụng hoàn toàn khác với nên tăng phát triển nên việc tích bợp kiểm thử tự dông cã mã nguồn còn nhiều vấn để nan giải Vì vậy ở dây chúng ta sẽ chỉ tìm

tiểu vẻ cách sinh các ca kiếm thử tự động, một bước mà ta sẽ tiết kiệm được chỉ phí

sán xuất mnà đạt hiệu quá cao

Trước hết ta sẽ tìm hiểu về khái niêm cơ bản trong cơ sở lý thuyết ma spec

explorer đựa vào là chương trình mô hình (model propram) vả máy mỏ hình tự động

(model automata) củng những khái niệm liên quan khác

2.2 Cơ sở lý thuyết áp dụng trong spec explurer

Ta gợi lập hợp tất cả các khái niệm, các thuật ngữ được sử dụng để xây đựng,

niên cơ sở lý thuyết của speo explorer la tap bir vung 3 Trước hét ta sé di vao khai niém

trạng thái (state) la khai niém dau tién ta cân tìm hiểu trong E

2.2.1 Trang thai (state)

Một trạng thái s là một cần trúc bậc một trong 3 mà miễn giả trị của nó (được ký

hiệu là U) dược giả định là cổ định déi với tắt cả các trạng thải Các ký hiệu từ vựng tương ng là các ký hiệu chức răng (lmeion symbol), trong đỏ mỗi ký hiệu hàm đến

có một số lượng tham số (arity) và cách diễn giải trong ø Cách diễn giải của một số ký

Trang 24

liệu trong Ð đối với các trạng thái khác nhau cô thể khác nhau Những ký hiệu chức

xăng mà điển giải của chủng có thể thay đổi được gọi là các biển trang thai (state variablas) hoặc các hàm động (dynamie fuentiens) Tập hợp các biến trạng thái dược

*ý hiệu là V Bat kỳ phản từ cơ sở nào thuộc Ÿ — V déu có diễn giải giống nhau đối với

tất cả các trạng thái

Với một cấu trúu bậu một # Irong Ÿ và một bộ lừ vựng Ÿ € Ÿ, ta ký liệu s|Ÿ

biểu thị cho thể hiện của ø trong V Ta ký hiệu: S|V = {S|V: s € S} (tap hop tat ca s|V

sao cho 5 € S)

Một biểu thức phụ thuậc trạng thái (state based expression) B 1a một phan tử

thuộc 3 có thể (inét cách loại) chứa các biến Néu H không chứa biển nảo (một cách logie) tá nói T suy biến về mức đơn vị (sround) hoặc đồng, Nếu E chúa (at cả các

biến trong số các biến # = #j, ta ky hiệu lá E[x], và các phần tử dong v =

1ạ, ,ø„ ta viết F[] ký hiện cho biểu tức đóng sau khi thay thể từng z; trong Iš bởi »;

với toàn bộ £ € [1,n] Giả trị của liều thức đồng phụ thuộc trạng thái E trong tạng thái

z dược ký hiệu lả B(s) Ta viết E(S) = {E(S): s 6 5}

2.2.2, May tao mô hình tự dộng (model nufomata)

Đink nghĩa 16: Một máy tạo mô hình tự động (model automaton) M bao gồm các thành phần sau [7]

e Một tận hợp 3 các trạng thái trang 3, trong đó Ð chúa một tập từ vụng hitu

hạn V cửa các biến trạng thái và hàm động

ø- Một lập hợp con khong rong S”*“ của 8 được gọi là các trạng thái khởi tạo

e Một tập hợp conS“°* của 9 được gọi là các trạng thái chấp nhận (acocpting

states)

© Mél lap hop Acts của các hành động là những phan tr dom vi trong E — V

Acts duge chia thanh hai phan dộc lập là tập hợp các hành dộng có thể kiểm

soát được (controllable action) Cii và tập hợp các hành động có thế quan sat

được (observable action) Obs,

* Mét quan hé chuyén tiép 6 CS x Acts x $

MM duoc goi lA xáo định nêu bất kỳ trang thai s va hanh dong a cé it nhất một trạng thái ¿ thôa mãn (s,a,E) E 8, trong Irường hợp rảy ta viếLổ(s,ø) = £ Ở day ta chỉ xem xét các máy tạo mô hình xác định

Điếi với một trạng thải cho trước s E Š, ta có ⁄1cfs(sj biểu thị cho tập hợp tất cả

cde action @ € Acts sao cho (s,@,t) € 6, voi it ohat mội L não đó Ta nói rằng a đuợc

kích hoạt trong trang thai s ‘a cd Ctrl(s) = Acts(s) N Ctrl va Gbs(s) = Acts(s)N

Obs ‘Th6ng thudug ta s8 ky higu M bởi một bộ (S""", 5,8, Obs, Ctrl, 8)

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 25

Định nghĩa 17: Một mày tạo mô hình tự dộng MI là một máy tự động con của máy †ạa mô hình tự động N (ký hiệu là M Œ N) nếu các điền kiện sau đều được thỏa mãn [7]

Sự € Sự, SỬ” C SP, SP” & SHE, Clrly € Ctrly, Obsụ € Obsụ, ỗ, € ấy

Tế xảo định một thành phân của một model automaton M, ddi khi ta lập chỉ số các thành phần cña M, trừ khi M đã rõ rằng về mặt ngũ cảnh, Khi điều kiện cho phép, ta biểu diễn M bởi một bộ (Sinit, 3, Saco, Obs, Cbl, 8),

Định nghĩa 18: Cho một máy tự động M và một tập từ vựng V © Vy, ta vidt TỊV biểu thị cho một máy tự đông N, được gọi là suy biển của M trên V như sau [7]

® S = Sy|V,SỹE = SHV, Sgr = Serer

® Actsy là tập hợp của tất cá các hành động a thuộc Actsy sao cho a là một phần tử thuộc V

© ẩy= {@|V,a,t|V): (s,a,£) E ñy,a E Actsy}

Mi được gọi lá mở rộng của N

Một suy biển cửa một my tự động cho một lập con cũa tập hợp các biển trạng,

thái có thê rút gọn từ nhiều trạng thái thành một trạng thái Vì vậy phép chiếu này

không phải lúc nào cũng, dâm bảo tính xác định của máy tự động Do đó, dễ dâm bảo tính xác định cũa máy tự động, phép chiều này thường ít được sử đụng

2.2.3 Chương trình mô hình (model program)}

Môi chương trình mô hình Ð khai báo ruột tập hữn hạn MZ của các phương thức hanh dong (action method) va một tập hợp các biển trạng thái F: Một trạng thái của ?

được biểu thị bồi các giả uị (hoặc điễn giảu) của cáo ký hiệu từ vựng trạng thái trung Ÿ

xuất hiện trong chương trình mò hình Giá trị của biên trang thai trong V © Eco thd

thay đối đo kết quả của việc thực thị chương trình Treng đó 1a có thế đưa ra các ví dụ

gn sau: các ký hiệu chức năng có diễn giải không đổi ứng với những phép toán có

w trúc dữ liệu, một biển trạng thái không than số là một biển bình thường (hoặc biến tính — static) mà giá trì có thẻ được cập nhật, một biển trạng thái đơn tham

số (gò một tham số) có thể la một tham chiếu đến một trường bên trong cứa một lớp

hông qua đối tượng là thể hiện — imstanee của lớp đó đã được tạo ra trong quả Irình

chương trình vận hành)

Trong phương thức hành động zø, với các biến x dược coi lả tham số hình thức đầu vào của ru, được liên kết chặt chế với một biểu thức logic phụ thuộc vào trạng thái

Prem [x] (dược gọi là diều kiện tiên dễ của mm) Việc thực thị của m trong, xuệt trạng thái

s với mội bộ lam số thục tế v sẽ tạo ra một trạng thái tiếp (heo nơi mà một số biến

trạng thải có thể đã được thay đối Thông thường việc thực thi của ?z có thể đẳng thai thực hiện các công việc khác (ví dụ như gÌủ dữ liệu vào tập tin — Bile, hiển thị hộp thoại

cho người đùng) nhưng theo một các trừ tượng hóa ta xem xét + như một quy lắc cập

Trang 26

nhật (update rule) Tức là m là một chức năng, làm cho một trạng thái với các tham số

thực tế thỏa mãn điều kiện tiên đề cửa m sẽ tạo ra một trạng thái ¢ 1a trang thai ma moat

số biến trạng thái trong P đã được cập nhật

Một chương trình mô hình có thể được viết bằng, một ngồn ngữ đặc tả cáp cao

Thoặc trong một rên ngữ lập trình như Cứ Klủ đó mội quy tắc cập nhật trong P được

định nghĩa bằng cáo phương thức cùng với tham số của nó cùng giêng như ta viết một

phương thức cho ruột chương trình bình thường vậy Một quy cặp nhật được định

nghĩa bởi một phương thức ta gọi là phương thức hành động (aơtion method),

Một máy tạo mô hình tự động Mp được định nghĩa bới một chương trinh mô tỉnh P là một sự phân tách hoàn toàn của Ð được định nghữn sau dây T4 sử dụng ký

hiệu AZ thay cho Mp Tử chương trình mô hình với lượng lớn các cầu trúc dữ liệu, các

trạng thái không phải là các thành phần trừu lượng không có cầu trúc bên trong, ta dink nghĩa các hành động và các hảm chuyển tiếp trang thai dy, đại diện cho việc thực thú của các hành động Không giống như một hệ thông chuyển tiến cụ thể với lận hợp các nút và các cạnh, các trạng thái và sự chuyến tiếp của mật chương trình mô hình phải dược suy ra bằng cách thực thị tuân tự từng hành dộng và bất dâu từ trạng thải khởi tạo Vì lẽ đó, ta sự đụng một phần tử explaration (phản tử đò tim) để tham chiêu tới oáo

bước của việc tao ra by

Tập họp cáo trạng thái khởi tạo 9?" 1a tap hop duy nhất chứa các trạng thai với các giả trị khổi tạo của các biến trạng thái được khai báo trong P Tập hợp tắt

trạng thai § là tập hợp tối thiểu phải chứa 9“ và là tập đóng với quan hệ chuyển tiếp

3; (sẽ được định nghĩa sau)

2.2.4 Duyét trang thai (State exploration)

Các hành động không phải là các hãn trừu tương mà là cỏ câu trúc bên trong, Bộ

từ vụng không cỏ kỷ hiệu là các biến Ÿ — được chia thành hai bò từng vựng con rời nhau sau đây: một tập hợp Z của các ký hiệu chức năng cho các phép toán và các cầu trúc đữ liệu, vả một tập hợp Â# của các ký hiệu chức năng cho các phương thức,

Môi bánh đồng trong (M,F) là một bạng tử m(D,

số lượng tham số của m, và mỗi ø, là một hạng tử của T', Mỗi một tham số của zm hoặc

là tham số dâu vào hoặc lả tham số dầu ra Ta giá dinh rằng tắt cả các tham só dầu vào

đều được sắp xếp trước cáo tham số đầu ra trong danh sách các tham số của mm Khi đó

†a có thể ký hiệu m(0„ , zụ) thành ?Ð(Dạ, à , 4) /Ị tá, cá Up, VỚI Pụ, Oy (Í < K) là

các tham số đầu vào Tập hợp tất cả ác hành động trong (M,) được khí hiệu là Aetsw (để đơm giãn hơn 1a ký hiệu là Acts) Bất kỳ hai hạng tử nào của F được gọi là

bang hau néu và chỉ nếu chúng được biểu thị bởi cùng một giả lrị trong U, va gid trị

của một phân tử trong 2° giống nhau với mọi trạng thải trong S„ Kỷ hiệu trong M có

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 27

hạng tử diễn giai (vi da m(v), m'feJ) dược gọi là bằng nhau khi vả chỉ khi zø vam’ la cùng một kỷ hiện đồng thời v và w là bằng nhau

Cho mét hanh déng a = m(v)/w và mội trạng thái s, a được gọi là được kích

Thoại long # (ví dụ & E Acts,(5)) nêu các điện kiện sau duge thoa min:

© Pre»[v] = true

© Lời gợim(0) trong s trả về các tham số dầu ra w

Ta ky higu Acts (s) 1A tap hợp tất cả các hành động được kích hoạt với phương

thức 1u trong trạng thái s Tập hop Actsy(s) là tập hợp tất cả các hành dong được kích: hoạt trong trạng thái ø chính là tổ hợp của các tập hợp 4cs„ (x) tương ứng của tật cả

các phương thức za s được goi là diễm cuối (trang thải cuối) (terminal) nếu 4ets,y(s)

là tập hợp rỗng Tập hợp Acts„ chính là tổ hợp của tất cả các ActS,(s) với tất cả s

thuộc Sự

Với mệt bành động a = m(v)/w E Acts,,(s), ta có 8y (v, a) chính là trạng thái dịch của lời gọi m(ø) Thông thường một lời gọi phương thức sẽ lạo m miột lập hợp các cập nhật (pđates) các giá trị mới cho một số biên trạng thái, và khi áp đụng nó lên trạng thai s ta sẽ tạo ra được trạng thái đích với các giả trị đã được cập nhật Việc gọi

phương thức m có thể đuợc hình thức hóa bằng cách sử dụng lý thuyết ASM (Abstraet

state machine) Ly thuyét nay ta sé khéng dé cap dén trong khuôn khổ của luận văn

Trên đây là cơ số lý thuyết vẻ chương trình mô hình vả máy tạo mô hình tự

động Tiếp theo đây ta sẽ xem xét trên thực tế khi sứ dụng spec explorer †a áp dụng

chủng như thẻ nào Sau đây là các bước áp dụng kiếm thữ hướng mô hính bằng công

cụ spec explorer

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 28

Hình 2-L: Quy trình sử đụng spec explorer

(Các bước thể hiện bằng nét đứt là các buốc khi tích hợp trén dng dung che smart

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Trang 29

chương trình mô hình (model program) Với cỏng cụ spec explorer ta sử dụng ngôn

Trữ lập trình C# để tao ra chương trình mô hình

Việc xây dựng chương trình mô hinh không có nghĩa là la phải viết ứng dụng

hai lẫn mà ta chỉ tập trung váo việc mô tả hệ thông, một cách dơn giản, nhỏ gọn hơn rất

nhiều nhằm phục vụ cho việc phân tích và kiểm thử hệ thông

Sau khi xây đựng được chương trình mô hình ta sẽ thiết lập các cấu hinh dé sinh

Ta các ca kiểm thứ Việc thiết lập cấu hình nảy nhằm giới hạn cũng như thông báo cho

bộ sinh ca kiếm thử biết được các thông số dâm bảo việc sinh các ca kiểm thir cho ta kết quá như mong đợi Nhờ các cầu bình kiểm thứ này và chương trình mô hình, công

ca spee explorer sẽ sinh ra các ca kiểm thử môi cách tự động Ta sẽ dhựa và cóc ca kiểm

thử này đề tiến hãnh kiếm thử SUT

Sau day ta sẽ đi vào một ví đạ mẫu để làm rõ các bước cản thực hiện

2.3.1 Tóm lược yêu cầu của ứng dụng ví dụ mẫu

Trước hết, ta sẽ tôm lược yêu cầu của ứng dụng để có cái nhìn chung về ứng

dụng sẽ như thế nào, từ đó ta sẽ xem xét việc xây dụng chương trinh mỏ bình sẽ ra sao

«_ Ứng đụng gồm 2 màn hình:

eo Một màn hình 2D thể hiện map (ban độ) vị trí các vật phẩm

6 Một màn hình 3D thể hiện hình ảnh 3D của map 2D

«Cáo chức năng

e_ Kéo thả các item trang màn hình map 2D

© Di chuyển qua lại giữa hai mắn bình 2D vả 3D

© Load’Save dit ligu dang kéo thả

© Load dit ligu có sẵn (partern)

Qua quá trình phân tích sơ bộ, thu được các yếu tỏ san

« Hành động:

©_ Kéo thả em: itemIDrag(mt _itemIÐD, bool _isDragIn)

ó- Dịch chuyển giữa hai màn hình: sceneMove(_ AppScene _targeLScene)

©_ Lưutrữ dữ liệu: savel2ataQ

©_ Lấy lại dữ liệu: loadData(strina _fileName) (Lim ý rằng việc load dữ liệu mặc định cũng có thể sự đụng aetion loađData)

* Cac con đường mẫu (sample traces)

© Kéo tha vat pham thong thong: ilemDrag, saveData, sceneMove

Ngô Hoàng Thành Tuớp 12BCNTT2 — Khóa 2012B

Ngày đăng: 09/06/2025, 13:01

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1. AIDA NIKNEJAD, 4 Quality Evaluation of an Android Smartphone Application, 2011. Master thesi Sách, tạp chí
Tiêu đề: Quality Evaluation of an Android Smartphone Application
Tác giả: AIDA NIKNEJAD
Năm: 2011
2. James H Andrews, Tionel C Briand, Yvan Labiche. 7x mufafion an appropyriaie tool for testing experiments? New York : ACM New York, 2005 Sách, tạp chí
Tiêu đề: 7x mufafion an appropyriaie tool for testing experiments
Tác giả: James H Andrews, Tionel C Briand, Yvan Labiche
Nhà XB: ACM New York
Năm: 2005
3, Kent Beet. Test Driven Development: By Example. 1st Edition. s.1 : Addison Wesley Professional, 2002 Sách, tạp chí
Tiêu đề: Test Driven Development: By Example
Tác giả: Kent Beet
Nhà XB: Addison Wesley Professional
Năm: 2002
4, Wang Linzhang, Yuan Jiesong, Yu Xiaofeng, Hu Jun, 1.i Xuandong and Zheng Guoliang. Generating Test Cases from UME Actwity Diagram based on Gray-Box Method. 2004, Technical Report Sách, tạp chí
Tiêu đề: Generating Test Cases from UME Actwity Diagram based on Gray-Box Method
Tác giả: Wang Linzhang, Yuan Jiesong, Yu Xiaofeng, Hu Jun, Xuandong, Zheng Guoliang
Nhà XB: Technical Report
Năm: 2004
5. Mark Utting and Bruno Legeard. Practical Model-Rased Testing - A Tools Approach, San Francisco : Morgan Kaufmann Publishers Inc., 2006 Sách, tạp chí
Tiêu đề: Practical Model-Rased Testing - A Tools Approach
Tác giả: Mark Utting, Bruno Legeard
Nhà XB: Morgan Kaufmann Publishers Inc.
Năm: 2006
9, Patrick Cousot, Radhia Cousot. Basic Concepts of Abstract Interpretation. 3.1. ; Khawer Academic Publishers, 2004, pp. 359-366 Sách, tạp chí
Tiêu đề: Basic Concepts of Abstract Interpretation
Tác giả: Patrick Cousot, Radhia Cousot
Nhà XB: Khawer Academic Publishers
Năm: 2004
11. Stephan WelBleder. TestÀfodels and Coverage Criteria for Automatic Model- Based Test Generation with UML State Machines. Berlin: s.n., 2010 Sách, tạp chí
Tiêu đề: TestÀfodels and Coverage Criteria for Automatic Model- Based Test Generation with UML State Machines
Tác giả: Stephan WelBleder
Nhà XB: s.n.
Năm: 2010
6. spec explorer tutorial [Online] hitp://rasmus.selsmark dk/post/2013/09/1 6/Spec- Explorer-Tutorial-for- Visual-Studio-2012. aspx Khác
10. msdn. [Online] Microsoft. https://msdn microsoft. com/en- +us/1ibrary/co620489.nspx Khác
13. TorX Test Tool Information. TorX Test Too! website. [Online] University of Twente, hitp-//tmt.cs-utwente,nl/tools/torv/introduction html Khác

HÌNH ẢNH LIÊN QUAN

Hình  1-2:  Mô  hình  chữ  V - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 1-2: Mô hình chữ V (Trang 13)
Hình  1-3:  Ba  phương  pháp  cơ  bản  tích  hợp  kiểm  thử  vào  kỹ  nghệ  hệ  thống - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 1-3: Ba phương pháp cơ bản tích hợp kiểm thử vào kỹ nghệ hệ thống (Trang 14)
Hình  2-L:  Quy  trình  sử  đụng  spec  explorer - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 2-L: Quy trình sử đụng spec explorer (Trang 28)
Hình  2-2:  Normal  Trace  Sample - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 2-2: Normal Trace Sample (Trang 32)
Hình  2-4:  ShowOldMap  Trace  Sample - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 2-4: ShowOldMap Trace Sample (Trang 33)
Hình  ảnh  mình  họa: - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh ảnh mình họa: (Trang 36)
Hình  2-8:  Hình  ảnh  minh  họa  state  trong  ca  kiểm  thử  (S65) - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 2-8: Hình ảnh minh họa state trong ca kiểm thử (S65) (Trang 38)
Hình  3-1:  Scene  Flow  của  Turtle  Ran - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-1: Scene Flow của Turtle Ran (Trang 40)
Bảng  1:  Ca  kiểm  thử  của  Turtle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
ng 1: Ca kiểm thử của Turtle Run (Trang 42)
Hình  3-4:  Mô  hình  và  ca  kiểm  thử  TopScene  của  Turtle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-4: Mô hình và ca kiểm thử TopScene của Turtle Run (Trang 45)
Hình  3-6:  Mô  hình  và  ca  kiểm  thử  How  To  Sccne  của  Turfle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-6: Mô hình và ca kiểm thử How To Sccne của Turfle Run (Trang 47)
Hình  sinh  ra  day  đủ  hơn,  chính  xác  hơn  so  với  các  ca  kiếm  thử  được  viết  một  cách  thủ - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh sinh ra day đủ hơn, chính xác hơn so với các ca kiếm thử được viết một cách thủ (Trang 48)
Hình  3-7:  Mô  hình  và  ca  kiểm  thử  GameOver  Scene  cia  Turtle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-7: Mô hình và ca kiểm thử GameOver Scene cia Turtle Run (Trang 48)
Hình  3-8:  Mô  hình  vào  ca  kiểm  thử  Game5cene  -  Story  cda  Turtle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-8: Mô hình vào ca kiểm thử Game5cene - Story cda Turtle Run (Trang 50)
Hình  3-9:  Mô  hình  và  ca  kiểm  thứ  GameScene  -  gameplay  cia  Turtle  Run - Luận văn kiểm thử hướng mô hình và Ứng dụng trong phát triển Ứng dụng cho Điện thoại di Động thông minh
nh 3-9: Mô hình và ca kiểm thứ GameScene - gameplay cia Turtle Run (Trang 51)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm