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

Nhiệm vụ trong luận văn Với mục đích ứng dụng đượ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 di động thông minh smart phone, luận văn tập trung nghiên cứu c

MỤC LỤC

LỜI CAM ĐOAN 3

Danh mục các từ viết tắt và thuật ngữ 4

Danh mục các bảng 5

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

MỞ ĐẦU 7

Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ HƯỚNG MÔ HÌNH 9

1.1 Tổng quan về kiểm thử 9

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

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

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

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

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

1.2.3 Ưu thế của kiểm thử hướng mô hình 17

1.2.4 So sánh kiểm thử hướng mô hình và kiểm thử thông thường 17

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 di động thông minh 18

1.2.6 Giới thiệu một số công cụ miễn phí hỗ trợ kiểm thử hướng mô hình 20

1.3 Kết chương 21

Chương 2 SỬ DỤNG CÔNG CỤ SPEC EXPLORER ĐỂ SINH CÁC CA KIỂM THỬ TỰ ĐỘNG 23

2.1 Đặt vấn đề 23

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

2.2.1 Trạng thái (state) 23

2.2.2 Máy tạo mô hình tự động (model automata) 24

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

2.2.4 Duyệt trạng thái (State exploration) 26

2.3 Các bước xây dựng chương trình mô hình và sinh các ca kiểm thử tự động bằng spec explorer 27

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

2.3.2 Các bước tạo ra chương trình mô hình 30

2.3.3 Cấu hình kiểm thử để sinh ca kiểm thử 34

2.4 Kết luận 38

Chương 3 THỬ NGHIỆM ỨNG DỤNG THỰC TẾ 39

3.1 Đặt vấn đề 39

3.1.1 Thông tin chung về dự án 39

3.1.2 Mô tả về ứng dụng (đặc tả hệ thống) 39

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

3.2 Ứng dụng kỹ thuật sinh kiểm thử tự động hướng mô hình vào dự án 42

3.2.1 Phân tích ban đầu 42

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

3.2.3 Đánh giá kết quả 52

3.3 Kết chương 53

3.3.1 Ưu điểm của kiểm thử hướng mô hình với Spec Explorer 53

3.3.2 Nhược điểm của kiểm thử hướng mô hình với Spec Explorer 53

KẾT LUẬN VÀ KIẾN NGHỊ 54

A Kết luận 54

Các kết quả chính đạt được trong đề tài: 54

Những khó khăn và hướng giải quyết 55

B Kiến nghị 56

C Hướng phát triển của đề tài 57

Tài liệu tham khảo 58

LỜI CAM ĐOAN

Tôi xin cam đoan: Luận văn "Kiểm thử hướng mô hình và ứng ụng trong phát triển ứng dụng cho điện thoại di động thông minh" là do bản thân tôi tự thực hiện dướ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; các thông tin số liệu và kết quả trong Luận văn có nguồn gốc rõ ràng, nội dung của Luận văn chưa từng được công bố trong bất kỳ một công trình nghiên cứu nào ở trong nước

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

Tác giả Luận văn

Ngô Hoàng Thành

Danh mục các từ viết tắt và thuật ngữ

Từ viết tắt,

AAL Adapter Action Language Ngôn ngữ mô hình hóa được sử dụng

trong fMBT IUT Impementation Under Test Bộ phần thực thi cần kiểm thử

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

OTC Intel Open Source

Danh mục các bảng

Bảng 1: Ca kiểm thử của Turtle Run 42 Bảng 2: Ca kiểm thử đã dùng với HowTo Scene của Turtle Run 48

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

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

Hình 1-2: Mô hình chữ V 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 14

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

Hình 2-1: Quy trình sử dụng spec explorer 28

Hình 2-2: Normal Trace Sample 32

Hình 2-3: LoadAndSave Trace Sample 32

Hình 2-4: ShowOldMap Trace Sample 33

Hình 2-5: Hỉnh ảnh về model program 35

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

Hình 2-7: Hình ảnh minh họa state trong ca kiểm thử (S32) 37

Hình 2-8: Hình ảnh minh họa state trong ca kiểm thử (S65) 38

Hình 3-1: Scene Flow của Turtle Run 40

Hình 3-2: Mô hình SceneFlow của Turtle Run 44

Hình 3-3: Ca kiểm thử SceneFlow của Turtle Rune 44

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

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

Hình 3-6: Mô hình và ca kiểm thử HowTo Scene của Turtle Run 47

Hình 3-7: Mô hình và ca kiểm thử GameOver Scene của Turtle Run 48

Hình 3-8: Mô hình vào ca kiểm thử GameScene - Story của Turtle Run 50

Hình 3-9: Mô hình và ca kiểm thử GameScene - gameplay của Turtle Run 51

MỞ ĐẦU

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

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 trong thực tế tại Việt Nam rất ít công ty chú trọng đúng mức vào công đoạn kiểm thử này (do tiết kiệm chi phí, do trình độ nhân công hoặc lý do khác) trong khi đây là điều then chốt ảnh hưởng tớ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 mức mà có một từ thường được sử dụng là

“chấp nhận được”, do đó sản phẩm công ty nói riêng và có lẽ là cả ngành gia công phần mềm Việt Nam nói chung đều chưa có tiếng nói, chưa thể sánh ngang với các nước 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 đề nan giải

Do đó tôi chọn đề tài này như một hướng đi hứa hẹn giải quyết các vấn đề về chất lượng phần mềm nói chung và chất lượng ứng dụ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 đảm bảo chi phí sản xuất trong khoảng cạnh tranh

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

Như đã 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 phần mềm nói chung và phát triển ứng dụ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ìm 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 di động thông minh có những nguyên nhân chính sau:

 Quy trình kiểm thử mang nhiều tính chất chủ quan và lệ thuộc vào từng kiểm thử viên Tại các công ty phần mềm vừa và nhỏ, việc kiểm thử chưa có quy chuẩn rõ ràng dẫn đến việc xây dựng các ca kiểm thử cũng như việc tiế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 chi phí nên bỏ qua nhiều công đoạn kiểm thử Các công ty phần mềm ở Việt Nam phần lớn đều dựa trên lĩnh vực “outsource” (làm cho khách hàng) nước ngoài Để tăng lợi nhuận, giảm giá thành (tăng tính cạnh tranh), chi phí cho việc kiểm thử thường bị cắt giảm và xem nhẹ nhất là với các dự án nhỏ, chi phí thấp Rất nhiều dự án phát triển ứng dụng cho điện thoại di động thông minh rơi vào trường hợp này

 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à kiểm thử thủ công và phụ thuộc vào trình độ 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

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 khâu này cải thiện được chất lượng mà vẫn đảm bảo hợp lý về mặt chi phí Kiểm thử tự động – kiểm thử hướng mô hình chính là một hướng tiếp cận hứa hẹn đáp ứng được các điều kiện đã đề ra

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

Với mục đích ứng dụng đượ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 di động thông minh (smart phone), luận văn tập trung nghiên cứu các nội dung chính sau :

 Tìm hiểu về các kỹ thuật kiểm thử và tập trung vào kiểm thử hướng mô hình

 Tìm hiểu các công cụ, lựa chọn công cụ thích hợp

 Áp dụng công cụ vào quá trình phát triển ứng dụng cho điện thoại di động thông minh

 Đá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 1: 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ẽ trình bày về các khái niệm cũng như đặc điểm chung của kiểm thử hướng mô hình

Chương 2: Phương pháp sử dụ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 bằng cách sử dụng công cụ Spec 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

bày nội dung 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 Turtle Run), đư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á ưu, 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 động thông minh

Chương 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ

KIỂM THỬ HƯỚNG MÔ HÌNH

1.1 Tổng quan về kiểm thử

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

Ta sẽ đi tìm hiểu một vài thuật ngữ cơ bản trong kiểm thử Trong đề tài này ta sẽ

sử dụng thuật ngữ IUT (Implementation Under Test) hoặc SUT (System Under Test) đều mang ý nghĩa là phần thực thi hoặc hệ thống đang cần được kiểm thử Ta có thể hiểu đơn giản đấy là đối tượng ta đang muốn kiểm thử nó

1.1.1.1 Sai sót, Lỗi, Hỏng hóc

Đây là ba thuật ngữ cơ bản của việc kiểm thử mà ta cần phải làm rõ

Định nghĩa 1 – Sai sót(Fault): 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 (Failure): Là sự sai khác có thể thấy được trong thực

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

Sơ đồ sau thể hiện mối quan hệ giữa sai sót, lỗi và thất bại

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

Sơ đồ trên biểu thị quá trình phát sinh thất bại của hệ thống bắt đầ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ày, kỹ sư hệ thống đã 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à ta mong 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ệc phân tích yêu cầu

hệ thống

Sai sót

Kích hoạt

Thất bại Đối chiếu

Lỗi

Thứ hai, là 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 thi của hệ thống trong khi kiểm thử Sai sót này thường xảy ra do 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ể được phát hiện bằng kiểm thử chức năng

Thứ ba, là các sai sót phi chức năng Những sai sót này gắn liền với những đặc

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 ta 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 thi hệ thống để kiểm thử

Trên đây là ba khái niệm cơ bản trong kiểm thử, sau đây ta sẽ đưa ra khái niệm

về kiểm thử

1.1.1.2 Kiểm thử (testing) là gì?

Trong phần này ta sẽ làm rõ các khái niệm liên quan, từ đó đưa ra khái niệm đâu

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

Kiểm thử (testing) trong thực tế có thể vừa là thẩm định (Validation) vừa là kiểm chứng (Verification) [9] Trước hết ta cần hiểu thẩm định và kiểm chứng là gì

Định nghĩa 4 – Thẩm định (validation): Thẩm định là quá trình đánh giá một

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

Định nghĩa 5 – Kiểm chứng (verification): Kiểm chứng là quá trình xác minh

kết quả của một giai đoạn phát 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 tạ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 nhu cầu thực tế hay không, do đó

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

Định nghĩa 6 – Kiểm thử (Testing): 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ó [9]

Định nghĩa 7 – Gỡ lỗi (Debugging): Gỡ lỗi là quá trình tìm ra sai sót dẫn đến

thất bại của hệ thống [9]

Định nghĩa 6 cho ta thấy rõ rằng kiểm thử vừa có thể là thẩm định, vừa có thể là kiểm chứng Thô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 thì khi đó kiểm thử là việc ta xác minh lại kết quả thực thi của hệ thống đối với các ca kiểm thử này, lúc đó 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 tìm 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 đó

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ử: Một ca kiểm thử là một bộ các giá trị đầu vào và

hành vi mong muốn tương ứng của hệ thống Trong đề tài này ta sẽ sử dụng từ “ca kiểm thử” ứng với khái niệm này.[11]

Định nghĩa 9 – Ca 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 tin trừu tượng về đầu vào cũng như đầ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.[11]

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 được sử dụng để đưa ra ý tưởng về cấu trúc của ca kiểm thử hoặc thông tin về việ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ử

cụ thể

Định nghĩa 10 – Ca kiểm thử cụ thể: Một ca kiểm thử cụ thể là một ca kiểm

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

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á trình kiểm thử toàn bộ hệ thống Do đó 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 – Bộ kiểm thử (test suite): 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 vi mong muốn của SUT.[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 thực tế với hành vi mong muốn của SUT Nế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 của người dùng, các sản phẩm khác để so sánh, phiên bản trước đây của chính hệ thống, những suy đoán về mục đích sử dụng, các tiêu chuẩn liên quan đến luật pháp hoặc thông số đặc tả kiểm thử…

Định nghĩa 13 – Đặc tả kiểm thử (test specification): Một đặc tả 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 hành vi mong muốn và hành vị quan sát được của hệ thống [11]

Đặc tả kiểm thử được dùng để tạo ra các bộ kiểm thử Hai đặc tả có thể khác nhau ở một số khía cạnh như khía cạnh trừu tượng hoặc hình 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 ít quan trọng hơn sẽ đượ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ẽ

dựa trên mong muốn của khách hàng hoặc 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 thử

Định nghĩa 14 – Công cụ kiểm thử (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ử Phổ 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 – Bộ khung kiểm thử (test framework): Bộ khung kiểm thử là

một bộ khung (framework) với mục đích tự động hóa quá trình kiểm thử, thực thi các

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

Các framework thường cung cấp khả năng tự động hóa ở một mức nhất định nào đó Ví dụ: JUnit (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 thi ở mức unit test

1.1.2 Quy trình kiểm thử (Test 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 hiện ở tất cả các cấp độ trừu tượng này Do đó chúng ta cần xem xét các cấp độ kiểm thử khác nhau dự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ô hình 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ô hình chữ V (V-model) V-model là viết tắt của Verification software development model (mô hình phát triển phần 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 đưa ra các giai đoạn chính trong quá trình phát triển phần mềm Trong V-model ứng với từng giai đoạn phát triển phần 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

Kiểm thử tích hợp: Trong kiểm thử tích hợp đặc tả kiểm thử được xây dựng dựa trên thiết kế hệ thống Mục đích của kiểm thử tích hợp giống như tên gọi là tìm 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ét toàn bộ hệ thống đã được xây dựng nên có thực hiện đúng theo đặc tả hệ thống được đưa ra từ ban đầu hay không

Yêu cầu

Đặc tả hệ thống

Kiểm thử chấp nhận

Kiểm thử hệ thống

Thiết kế hệ thống

Thiết kế chi tiết

Thực thi

Kiểm thử tích hợp

Kiểm thử đơn vị

Trình tự xử lý Ảnh hưởng của kết quả kiểm thử

Kiểm thử chấp nhận: Mục tiêu của kiểm thử chấp nhận là xác minh lại tính đúng đắn của hệ thống so với nhu cầu thực tế Ngoài ra kiểm thử chấp nhận còn đánh giá xem hệ thống có sẵn sàng để đưa vào triển khai và sử dụng hay không

Ta có thể nhận thấy rằng kiểm thử chấp nhận chính là quá trình thẩm định (validation) còn kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống là quá trình kiểm chứng (verification) ứng với định nghĩa đã nêu trên

1.1.2.2 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ệ

thống Đó là: (a) Kiểm thử sau khi phát triển, (b) thực hiện kiểm thử và phát triển hệ thống song song với nhau, và (c) bắt đầu bằng việc kiểm thử (test-driven development)

Hình sau sẽ thể hiện ba cách thức này

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

Kiểm thử sau phát triển hệ thống: Phương pháp này chính là công việc thường

ngày của kiểm thử viên Người phát triển hệ thống tạo ra hoặc chỉnh sửa các thành phần, sau đó thì kiểm thử viên sẽ thẩm định SUT Với phương pháp này, kiểm thử được tiến hành sau khi SUT được tạo ra và SUT phải được điều chỉnh lại nếu kiểm thử phát hiện ra thất bại trong SUT Những thất bại này thường do việc thiếu đầy đủ hoặc sai khác so với yêu cầu Đối với phương pháp này thì việc thay đổi yêu cầu sau giai đoạn triển khai sẽ dẫn đến việc tăng cao về chi phí [3]

Kiểm thử hệ thống

(b) Phương pháp song

song

Kiểm thử hệ thống

Phát triển hệ thống Yêu cầu

(c) Phương kháp kiểm thử trước phát triển

Kiểm thử và phát 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 thườ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 dựng các bộ kiểm thử và SUT đồng thời nhằm phục vụ cho mục đích: hệ thống được kiểm thử ngay khi có thể Với phương pháp này, sai sót được phát hiện sớm hơn, kéo theo người quản lý dự án có thể đưa ra được xử lý sớm hơn phương pháp (a), tuy nhiên vấn đề 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 này vẫn đòi hỏi chi phí lớn [3]

Phát 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 Do đó ca kiểm thử sẽ thất bại trước tiên, và nhiệm vụ của việc phát triể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 thay đổi cần 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 tiê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ả kiểm thử được đựa trên một mô hình kiểm thử Mô hì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ử phi chức năng Trong kiểm thử hướng mô hình, các bộ kiểm thử được đưa ra một cách tự động (hoặc bán tự động) từ các mô hình kiểm thử Kiểm thử hướng mô hình có thể được áp dụng tại tất cả các cấp độ kiểm thử từ kiểm thử đơn vị đến kiểm thử hệ thống

Kiểm thử hướng mô hình được coi là một phương pháp hình thức gọn nhẹ để 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 vì nó tạo ra các đặc tả

kỹ thuật (hoặc mô hình) của SUT theo một cách thức xác định (có nghĩ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 minh rằng phần thực thi 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

ra một bộ kiểm thử từ mô hình một cách có hệ thống, sau đó thực thi kiểm thử trên SUT với việc tin rằng SUT 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 vận 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à được chứng minh bằng các lý thuyết toán học) ta đều đã kiểm soát được Trong thực tế chi phí cần thiết cho sự đảm bảo hoàn toàn

thường rất đắt (đôi khi là cực kỳ đắt), vì vậy kiểm thử hướng mô hình sẽ là một phương pháp linh hoạt hơn, thích hợp áp dụng cho các dự án chi 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ử trước khi xây dựng phần thực thi

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ể đánh giá lại được tính đúng đắn của mô hình cũng như của yêu cầu đầu vào và có những điều chỉnh phù hợp trong khi xây dựng phần thực thi Hì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]

Hì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 dựng lên mô hình tương ứng Từ mô hình này ta sẽ sinh ra các ca 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ể tự động hóa Việc sinh ra các ca kiểm thử ngay tại giai đ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 được ta có thể đưa lại các phản hồi, các điểm bất hợp lý đến các yêu cầu của hệ thống để có những điều chỉnh hợp lý

Từ các ca 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ể đưa ra các phản

Phản hồi Sinh ra

Các ca kiểm thử

hồi đến cả mô hình, yêu cầu ban đầu cũng như phần thực thi (bộ phận trực tiếp phát 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 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 mô hình như sau:

 Thứ nhất, mô hình kiểm thử được sử dụng thường xuyên thường khá nhỏ, dễ hiểu, dễ 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 (test-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 ta 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 ta tìm ra được các sai sót và mâu thuẫn trong yêu cầu

 Thứ tư, cũng chính là ưu điểm mà đề tài tập trung vào: có thể sinh kiểm thử tự động (automatic test generation) từ các mô hình Tức là mô 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 ứng một cách tự động Điều này cho phép ta tạo ra đồng thời các bộ kiểm thử nhỏ, thực hiệ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 hơn

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

Trước tiên, kiểm thử thông thường (conventional testing) ở đây ta ngầm hiểu là

hai phương pháp: tạo kiểm thử thủ công hoặc tạo kiểm thử tự động dựa trên mã nguồn (code-based test 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 triển, cả hai cách này đều có ưu – nhược điểm của nó Tuy nhiên một nhược điểm chung là chúng ta cần có một lượng chi 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, điều này tạo ra một lượng chi phí lớ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 chi phí cao, tuy nhiên ngược lại với kiểm thử thủ công, chi phí cho việc duy trì kiểm thử trong kiểm thử hướng mô hình lại thấp hơn nhiều do: Mô hình kiểm thử được tạo ra mộ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 dễ hiểu hơn là bộ kiểm thử

Trong phương pháp sinh kiểm thử tự động dựa trên mã nguồn, mã nguồn của hệ 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 kiểm tra

để chạy mã 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 vi không mong muốn của hệ thống – ví dụ như hệ 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ử hướng mã nguồn không phát hiện đượ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 chi phí cho việc kiểm thử sẽ tăng dần theo mức độ hoàn thành của SUT Việc sinh kiểm thử theo cách thủ công sẽ tốn nhiều chi phí, trong khi 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 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 trước khâu phát triể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 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 di động thông minh

1.2.5.1 Đặc trưng của việc phát triển ứng dụng trên điện thoại di động thông minh

Qua quá trình làm việc thực tế của tác giả trong lĩnh vực phát triển ứng dụng nói chung và trò chơi nói riêng cho điện thoại di động thông minh, 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 minh tại Việt Nam có những đặc trưng sau:

 Môi trường phát triển và môi trường ứng dụng là hoàn toàn khác nhau: Đây là đặc điểm chung của việc phát triển ứng dụng cho điện thoại di dộng thông minh, khi

mà môi trường phát triển ứng dụng là máy tí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 minh (hệ điều hành phổ biến hiện nay là Android và iOS) Vì vậy việc kiểm thử thực tế đề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át triển ứng dụng trên điện thoại di động hiện nay, ngôn ngữ sử dụng phổ biến trên Android là Java, trên iOS là ObjC và 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 điện thoại di động thông minh 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# với Unity, Xamarin), tuy nhiên trong nhiều trường hợp ta vẫn cần sử dụng Java với Android (hoặc ObjC, Swift với iOS) để có thể thực hiện được các chức năng cần thiết và tích hợp vào trong công cụ phát triển đã nêu

 Thời gian phát triển ngắn (2 đến 6 tháng): Trên thực tế các ứng dụng trên điện thoại di động thông minh cũng có thể chia ra nhiều mức độ phụ thuộc vào chi phí, quy

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 dụng phát triển trong thời gian ngắn (từ 2 đến 6 tháng) chiếm đa số Kéo theo đó chi phí cho việc phát triển các ứng dụng này thường hạn chế và điều này khiến công đoạn kiểm thử thường bị coi nhẹ để đảm bảo lợi nhuận

1.2.5.2 Khả năng áp dụng kiểm thử hướng mô hình trong phát triển ứng dụng cho

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

Mứ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 trung 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 minh thì việc đảm bảo hoàn toàn gần như là không khả thi Trái lại, tính chất “gọn nhẹ” của kiểm thử hướng mô hình lại hoàn toàn thích hợp với đặc điểm trên Xét trên một khía cạnh nào đó, khi phát triển ứng dụng cho điện thoại di động thông minh, ta 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 ứng dụng là tương đồng nhau

Kiểm thử hướng mô hình đòi hỏi việc xây dựng mô hình theo một cách thức xác định (để máy tính có thể đọc được) Điều này rất dễ áp dụng vào phát triển ứng dụng cho điện thoại di động thông minh khi ngôn ngữ lập trình cho các ứng dụng này là cố định (Java, ObjC, Swift, hoặc C# đối với công cụ không phụ thuộc nền tảng)

Ngoài ra, do tính “gọn nhẹ” của kiểm thử hướng mô hình đem lại cho chúng ta một phương pháp kiểm thử hứa hẹn tiết kiệm chi phí, điều này phù hợp với đặc điểm

đa phần các ứng dụng trên điện thoại di động thông minh là những ứng dụng phát triển trong thời gian ngắn, chi phí thấp

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 cụ nào cũng

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

1.2.6 Giới thiệu một số công cụ miễn phí hỗ trợ kiểm thử hướng mô hình

1.2.6.1 fMBT

Đây là công cụ do OTC (Intel Open Source Technology Center) nghiên cứu và phát triển Công cụ này sử dụng AAL (Adapter Action Language) kết hợp cùng với một ngôn ngữ lập trình khác (hiện tại hỗ trợ hai ngôn ngữ lập trình chính là C++, Python) để xây dựng mô hình cũng như phát triển ứng dụng.[11]

1.2.6.2 TorX

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 thức (Formal Methods and Tools) tại trường UT (University of Twente) của Hà Lan đưa ra Công cụ này hỗ trợ rất nhiều ngôn ngữ mô hình hóa (ngôn ngữ để mô tả mô hình) khác nhau để xây dựng mô hình Ngôn ngữ lập trình được hỗ trợ chính là C++ và Java [12]

 Ngôn ngữ mô hình hóa độc lập với ngôn ngữ lập trình nên khó nắm bắt hơn đối với lập trình viên

1.2.6.3 Spec Explorer

Spec Explorer là công cụ hỗ trợ kiểm thử hướng mô hình do Microsoft phát triển

và tích hợp vào trong Visual studio Công cụ này sử dụng Cord Scripting Language kết hợp với C# để xây dựng mô hình Ngôn ngữ lập trình được hỗ trợ là C# [6]

 Giao diện đồ họa trực quan, dễ sử dụng

Nhược điểm:

 Chỉ cài đặt được trên window và đi cùng với Visual studio

 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 nền tảng điện thoại di động thông minh 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 điểm dễ sử dụng, dễ tiếp cận đối với lập trình viên đồng thời hứa hẹn khả năng kết hợp cùng các công cụ phát triển không phụ thuộc nền tả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 triển ứng dụng cho điện thoại di động thông minh

1.3 Kết chương

Chương 1 đã trình bày được:

 Về kiểm thử nói chung

 Các định nghĩa cơ bản về kiểm thử nói chung

 Một số quy trình kiểm thử cơ bản

 Về 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

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

 So sánh kiểm thử hướng mô hình với kiểm thử thông thường

 Đánh giá 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 di động thông minh

 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 dụng trong bất kỳ khâu nào của quá trình phát triển hệ thống

 Có nhiều phương pháp áp dụ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 “Test-driven System Development” 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 thi

 Kiểm thử hướ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ử

Chương 2 SỬ DỤNG CÔNG CỤ SPEC EXPLORER ĐỂ SINH

CÁC CA KIỂM THỬ TỰ ĐỘNG

2.1 Đặt vấn đề

Trong phần trên ta đã tìm hiểu đượ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 phần này ta sẽ đi vào tìm hiểu một công

cụ (tool) cụ thể dựa 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ả test code, đồng nghĩ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 tìm hiểu là Spec Explorer do Microsoft phát triển và được phát hành hoàn toàn miễn phí khi đi kèm với visual studio Bộ công cụ này được xây dựng dựa trên ngôn ngữ lập trình C# và Cord Scripting Language giúp ta có thể xây dựng mô hình, liên kết với phần thực thi (SUT) và sinh ra các ca kiểm thử Ở đây

ta sẽ tập trung 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

Về 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, do đặc muốn kiểm thử ứng dụng một các tự động đòi hỏi chúng ta phải xây dựng một bộ mã tương thích (adapter) hay

mã kiểm thử và dựa vào đó để xây dựng ứng dụng Với đặc thù 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 hợp kiểm thử tự động cả mã nguồn còn nhiều vấn đề nan giải Vì vậy, ở đây chúng ta sẽ chỉ tìm hiể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 chi phí sản xuất mà đạ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 mà spec explorer dựa vào là chương trình mô hình (model program) 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 explorer

Ta gọi tập hợp tất cả các khái niệm, các thuật ngữ được sử dụng để xây dựng nên cơ sở lý thuyết của spec explorer là tập từ vựng Trước hết ta sẽ đi vào khái niệm trạng thái (state) là khái niệm đầu tiên ta cần tìm hiểu trong

2.2.1 Trạng thái (state)

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

hiệu là U) được giả định là cố định đố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 năng (funcion symbol), trong đó mỗi ký hiệu hàm đều

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

hiệ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 năng mà diễn giải của chúng có thể thay đổi được gọi là các biến trạng thái (state variables) hoặc các hàm động (dynamic fucntions) Tập hợp các biến trạng thái được

ký hiệu là V Bất kỳ phần tử cơ sở nào thuộc đề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úc bậc một s trong và một bộ từ vựng , ta ký hiệu biểu thị cho thể hiện của s trong V Ta ký hiệu: { } (tập hợp tất cả s|V

sao cho )

Một biểu thức phụ thuộc trạng thái (state based expression) E là một phần tử thuộc có thể (một cách logic) chứa các biến Nếu E không chứa biến nào (một cách logic) ta nói E suy biến về mức đơn vị (ground) hoặc E đóng Nếu E chứa tất cả các biến trong số các biến , ta ký hiệu là [ ], và các phần tử đóng

ta viết [ ] ký hiệu cho biểu tức đóng sau khi thay thế từng trong E bởi với toàn bộ [ ] Giá trị của biểu thức đóng phụ thuộc trạng thái E trong trạng thái

s được ký hiệu là E(s) Ta viết { }

2.2.2 Máy tạo mô hình tự động (model automata)

Định 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]:

 Một tập hợp S các trạng thái trong , trong đó chứa một tập từ vựng hữu hạn V của các biến trạng thái và hàm động

 Một tập hợp con không rỗng của S được gọi là các trạng thái khởi tạo

 Một tập hợp con của S được gọi là các trạng thái chấp nhận (accepting states)

 Một tập hợp Acts của các hành động là những phần tử đơn vị trong

Acts được chia thành hai phần độc lập là tập hợp các hành động có thể kiểm soát được (controllable action) Ctrl và tập hợp các hành động có thể quan sát được (observable action) Obs

 Một quan hệ chuyển tiếp

M được gọi là xác định nếu bất kỳ trạng thái s và hành động a có ít nhất một trạng thái t thỏa mãn , trong trường hợp này ta viết Ở đây ta

chỉ xem xét các máy tạo mô hình xác định

Đối với một trạng thái cho trước , ta có Acts(s) biểu thị cho tập hợp tất cả các action sao cho , với ít nhất một t nào đó Ta nói rằng a được kích hoạt trong trạng thái s Ta có và Thông thường ta sẽ ký hiệu M bởi một bộ

Định nghĩa 17: Một máy tạo mô hình tự động M là một máy tự động con của

máy tạo mô hình tự động N (ký hiệu là ) nếu các điều kiện sau đều được thỏa mãn [7]:

, , , , ,

Để xác định một thành phần của một model automaton M, đôi 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, S, Sacc, Obs, Ctrl, δ)

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

 | |

 là tập hợp của tất cả các hành động a thuộc sao cho a là một

phần tử thuộc V

 { }

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

Một suy biến của một máy tự động cho một tậ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 đảm bảo tính xác định của máy tự động Do đó, để đả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ử dụng

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

Một chương trình mô hình P khai báo một tập hữu hạn M của các phương thức hành động (action method) và một tập hợp các biến trạng thái V Một trạng thái của P

được biểu thị bởi các giá trị (hoặc diễn giải) của các ký hiệu từ vựng trạng thái trong xuất hiện trong chương trình mô hình Giá trị của biến trạng thái trong có thể thay dổi do kết quả của việc thực thi chương trình Trong đó ta có thể đưa ra các ví dụ đại diện 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ó sẵn, các cấu trúc dữ liệu; một biến trạng thái không tham 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ố (có một tham số) có thể là một tham chiếu đến một trường bên trong của một lớp (thông qua đối tượng là thể hiện – instance của lớp đó đã được tạo ra trong quá trình chương trình vận hành)

Trong phương thức hành động m, với các biến x được coi là tham số hình thức

đầu vào của m, đượ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 [ ] (được gọi là điều kiện tiền dề của m) Việc thực thi của m trong một trạng thái

s với một bộ tham số thực tế v sẽ tạo ra một trạng thái tiếp theo 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 m có thể đồng thời

thực hiện các công việc khác (ví dụ như ghi dữ liệu vào tập tin – file, hiển thị hộp thoại

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

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 t là trạng thái mà một

số biến trạng thái trong V đã đượ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

hoặc trong một ngôn ngữ lập trình như C# Khi đó một quy tắc cập nhật trong P được

định nghĩa bằng các 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 một chương trình bình thường vậy Một quy tắc 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 (action method)

Một máy tạo mô hình tự động được định nghĩa bởi một chương trình mô

hình P là một sự phân tách hoàn toàn của P được định nghĩa sau đây Ta sử dụng ký hiệu M thay cho 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 tượng không có cấu trúc bên trong, ta định nghĩa các hành động và các hàm chuyển tiếp trạng thái đại diện cho việc thực thi của các hành động Không giống như một hệ thống chuyển tiếp cụ thể với tập 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 được suy ra bằng cách thực thi tuần tự từng hành động và bắt đầu từ trạng thái khởi

tạo Vì lẽ đó, ta sự dụng một phần tử exploration (phần tử dò tìm) để tham chiếu tới các

bước của việc tạo ra

Tập hợp các trạng thái khởi tạo là tập hợp duy nhất chứa các trạng thái 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 cả các

trạng thái S là tập hợp tối thiểu phải chứa và là tập đóng với quan hệ chuyển tiếp (sẽ được định nghĩa sau)

2.2.4 Duyệt trạng thái (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 F 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 dữ liệu, và một tập hợp M của các ký hiệu chức năng cho các phương thức

Một hành động trong là một hạng tử với là

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

là tham số đầu vào hoặc là tham số đầu ra Ta giả định rằng tất cả các tham số đầu vào

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

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

bằng nhau nếu và chỉ nếu chúng được biểu thị bởi cùng một giá trị trong U, và giá trị của một phần tử trong F giống nhau với mọi trạng thái trong Ký hiệu trong M có

hạng tử diễn giải (ví dụ m(v), m’(w)) được gọi là bằng nhau khi và chi khi m và m’ là cùng một ký hiệu đồng thời v và w là bằng nhau

Cho một hành động và một trạng thái s, a được gọi là được kích hoạt trong s (ví dụ ) nếu các điều kiện sau được thỏa mãn:

 [ ]

 Lời gọi trong s trả về các tham số đầu ra w

Ta ký hiệu là tập hợp tất cả các hành động được kích hoạt với phương thức m trong trạng thái s Tập hợp là tập hợp tất cả các hành động được kích

hoạt trong trạng thái s chính là tổ hợp của các tập hợp tương ứng của tất cả

các phương thức m s được gọi là điểm cuối (trạng thái cuối) (terminal) nếu

là tập hợp rỗng Tập hợp chính là tổ hợp của tất cả các với tất cả s thuộc

Với một hành động , ta có chính là trạng thái địch của lời gọi Thông thường một lời gọi phương thức sẽ tạo ra một tập hợp các cập nhật (updates) các giá trị mới cho một số biến trạng thái, và khi áp dụng nó lên

trạng thái 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ể được hình thức hóa bằng cách sử dụng lý thuyết ASM (Abstract state machine) Lý thuyết này ta sẽ không đề cập đến trong khuôn khổ của luận văn

2.3 Các bước xây dựng chương trình mô hình và sinh các ca kiểm thử tự động bằng spec explorer

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 ta á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

Hình 2-1: Quy trình sử dụng spec explorer

(Các bước thể hiện bằng nét đứt là các bước khi tích hợp trên ứng dụng cho smart

Đặc tả

yêu cầu (1) Xây dựng Mô hình (C#)

mô hình(Thủ công)

(2) Thiết lập cấu hình kiểm thử(Thủ công)

(3) Sinh các

ca kiểm thử(Tự động)

Cấu hình kiểm thử (Cord Scripting Language)

Ca kiểm thử(4) Kiểm thử

(Thủ công hoặc

tự động)

Sinh code kiểm thử (Tự động)

Xây dựng ứng dụng (implement)(Thủ công)

SUT

chương trình mô hình (model program) Với công cụ spec explorer ta sử dụng ngôn ngữ lập trình C# để tạo ra chương trình mô hình

Việc xây dựng chương trình mô hình không có nghĩa là ta 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 đơ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 dựng được chương trình mô hình ta sẽ thiết lập các cấu hình để sinh

ra 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ố đảm bảo việc sinh các ca kiểm thử cho ta kết quả như mong đợi Nhờ các cấu hình kiểm thử này và chương trình mô hình, công

cụ spec explorer sẽ sinh ra các ca kiểm thử một cách tự động Ta sẽ dựa và các ca kiểm thử này để tiến hành kiểm thử SUT

Sau đây ta sẽ đi vào một ví dụ 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 trình mô hình sẽ ra sao

 Ứng dụng gồm 2 màn hình:

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

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

 Các chức năng:

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

o Di chuyển qua lại giữa hai màn hình 2D và 3D

o Load/Save dữ liệu đang kéo thả

o Load dữ liệu có sẵn (partern)

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

 Hành động:

o Kéo thả item: itemDrag(int _itemID, bool _isDragIn)

o Dịch chuyển giữa hai màn hình: sceneMove(_AppScene _targetScene)

o Lưu trữ dữ liệu: saveData()

o Lấy lại dữ liệu: loadData(string _fileName)

(Lưu ý rằng việc load dữ liệu mặc định cũng có thể sự dụng action loadData)

 Các con đường mẫu (sample traces)

o Kéo thả vật phẩm thông thường: itemDrag, saveData, sceneMove