Nghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúng (Luận văn thạc sĩ)

Nghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúngNghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúng

PHẠM THỊ NGỌC

NGHIÊN CỨU KỸ THUẬT KIỂM THỬ TỰ ĐỘNG

DỰA TRÊN MÔ HÌNH, ÁP DỤNG TRONG HỆ THỐNG NHÚNG

Chuyên ngành: Hệ thống thông tin

Mã số: 8.48.01.04

NGƯỜI HƯỚNG DẪN KHOA HỌC : TS ĐỖ THỊ BÍCH NGỌC

HÀ NỘI - 2019

LỜI CAM ĐOAN

Tôi cam đoan luận văn thạc sĩ “Nghiên cứu kỹ thuật kiểm thử tự động dựa trên mô hình, áp dụng trong hệ thống nhúng” là công trình nghiên cứu của riêng tôi

Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác Tất cả những tham khảo và kế thừa đều được trích dẫn và tham chiếu đầy đủ

Tác giả luận văn

MỤC LỤC

LỜI CAM ĐOAN……… i

MỤC LỤC 1

DANH MỤC HÌNH VẼ iii

MỞ ĐẦU 1

Chương 1 – TỔNG QUAN VỀ HỆ THỐNG NHÚNG 3

VÀ KIỂM THỬ TRONG HỆ THỐNG NHÚNG 3

1.1 Hệ thống nhúng 3

1.2 Đặc điểm của hệ thống nhúng 4

1.2.1 Giao diện 4

1.2.2 Thiết bị ngoại vi 5

1.2.3 Công cụ phát triển 5

1.2.4 Độ tin cậy 6

1.2.5 Xu hướng phát triển của các hệ thống nhúng 6

1.2.6 Những thách thức và vấn đề còn tồn tại với hệ thống nhúng 7

1.3 Lý thuyết kiểm thử 8

1.3.1 Mục tiêu kiểm thử 8

1.3.2 Nguyên tắc kiểm thử 9

1.3.3 Nội dung các nhiệm vụ trong quá trình kiểm thử 10

1.4 Kiểm thử tự động 12

Kiểm thử tự động 12

Ưu điểm và nhược điểm 12

Tầm quan trọng của kiểm thử tự động 13

Chương 2-PHƯƠNG PHÁP KIỂM THỬ DỰA TRÊN MÔ HÌNH 15

2.1 Kiểm thử dựa trên mô hình 15

2.1.1 Kiểm thử dựa trên mô hình 15

2.1.2 Quy trình kiểm thử dựa trên mô hình 16

2.1.3 Thuận lợi và khó khăn của kiểm thử dựa trên mô hình 19

2.2 Các vấn đề của quá trình kiểm thử dựa trên mô hình 20

2.3 Lập mô hình cho hệ thống 31

2.3.1 Mô hình kiểm thử trong Simulink 32

2.3.2 Yêu cầu/ đặc tả của mô hình 33

2.3.3 Tạo ca kiểm thử từ mô hình 35

2.3.4 Đánh giá mức phủ của test case 35

Chương 3 - THỬ NGHIỆM VÀ ĐÁNH GIÁ 39

3.1 Cài đặt Matlab & Simulink toolbox 39

3.2 Áp dụng kiểm thử dựa trên mô hình vào bài toán kiểm thử mô hình điều khiển hành trình 40

3.2.1 Xây dựng mô hình trong Matlab 40

3.2.2 Sinh ca kiểm thử và thực thi và kết quả kiểm thử 45

Chương 4 – KẾT LUẬN 51

TÀI LIỆU THAM KHẢO 52

DANH MỤC HÌNH VẼ

Hình 1.1: Bản kế hoạch chính và bản kế hoạch chi tiết 11

Hình 2.1: Phân loại quá trình kiểm thử dựa trên mô hình 21

Hình 2.2: Ví dụ một mô hình cơ bản bao gồm các khối thử nghiệm tuần tự, kiểm tra dữ liệu và kiểm tra quản lý 33

Hình 2.3: Ví dụ sơ đồ khối hệ thống truyền lực 34

Hình 2.4: Sơ đồ mô hình hóa và kết quả mô phỏng động cơ truyền động 34

Hình 3.1: Sơ đồ khối của hệ thống điều khiển hành trình cho hệ thống ô tô 41

Hình 3.2: Mô hình lực cân bằng xe ô tô 42

Hình 3.3: Chi tiết khối Cruise control 45

Hình 3.4: Cơ sở dữ liệu kiểm thử 46

Hình 3.5: Nhập file dữ liệu đầu vào 47

Hình 3.6: Tạo file dữ liệu cơ sở từ 1 ca kiểm thử 48

Hình 3.7: So sánh kết quả với đường cơ sở baseline 48

Hình 3.8: Độ dốc của đường tăng giảm với biên độ nhỏ 49

Hình 3.9: Vận tốc của xe khi độ dốc thay đổi với biên độ nhỏ 49

Hình 3.10: Độ dốc của đường tăng giảm với biên độ lớn 50

Hình 3.11: Vận tốc của xe khi độ dốc đường lớn 50

MỞ ĐẦU

Xuất hiện từ những năm đầu thập niên 1960, hệ thống nhúng đang dần trở thành một ngành phát triển mạnh mẽ trong lĩnh vực công nghệ thông tin (CNTT), với những ứng dụng rộng rãi trong công nghiệp và đời sống

Sự tăng trưởng của hệ thống nhúng trong ngành công nghiệp dẫn tới một quá trình phát triển công nghệ dựa trên mô hình (model based), mang lại nhiều thuận lợi cho sự phát triển của công nghệ tự động Các kỹ thuật dựa trên mô hình như MATLAB/ Simulink, Statemate, MatrixX hoặc LabView là những công cụ cụ thể

và có cơ chế mạnh mẽ nhằm hỗ trợ xử lý các tín hiệu liên tục và các loại dữ liệu quan trọng nhất trong lĩnh vực điều khiển tự động Những công nghệ dựa trên mô hình này cho phép phát triển các mô hình một cách chi tiết và có thể được sử dụng

để mô phỏng các giai đoạn phát triển

Sự phát triển của hệ thống nhúng kéo theo những yêu cầu phát triển của hoạt động kiểm thử Thông thường, cách phổ biến để kiểm thử cho hệ thống nhúng nói chung là chạy giả lập phần cứng trên phần mềm mô phỏng Kiểm thử tự động là một giải pháp hữu hiệu nhằm nâng cao tính chính xác và hiệu quả, cũng như giảm kinh phí và rút ngắn thời gian trong quá trình kiểm thử các sản phẩm phần mềm nói chung và các hệ thống nhúng nói riêng Kiểm thử dựa trên mô hình đang được xem

là một phương pháp kiểm thử có khả năng tự động hóa cao

Kiểm thử dựa trên mô hình là một phương pháp kiểm thử, trong đó các ca kiểm thử được sinh ra từ mô hình đặc tả hành vi của hệ thống đang được kiểm thử Ngoài ra,việc đảm bảo chất lượng dựa trên phát triển mô hình, đặc biệt là thử nghiệm, vẫn còn ít được hỗ trợ Trong luận văn này, chúng ta thảo luận các đặc tính của quy trình phát triển dựa trên mô hình cho hệ thống nhúng, đánh giá sự cần thiết

và hiệu quả của việc kiểm thử trong thực tế

Đặc biệt hệ thống nhúng yêu cầu cao về chất lượng, cần kiểm thử ngay từ mô hình, việc mô hình hóa & mô phỏng hệ thống nhúng được sử dụng khi hệ vật lý không tồn tại, tốn thời gian hoặc chi phí để xây dựng, cho phép quan sát quá trình, đáp ứng động của hệ thống trước khi thực nghiệm trên thiết bị thực, đây chính là

công cụ hữu hiệu cho việc thiết kế, nghiên cứu, với chi phí thấp, có thể dễ dàng thay đổi

Các công cụ mô hình hoá (như Simulink) hay được dùng để thiết kế các hệ thống nhúng Simulink được tích hợp vào Matlab như một công cụ để mô phòng hệ thông, giúp người sử dụng phân tích và tổng hợp hệ thống một cách trực quan Trong Simulink, hệ thống được mô tả dưới dạng sơ đồ khối Với dạng sơ đồ khối này, ta có thể quan sát các đáp ứng thời gian của hệ thống với nhiều tín hiệu vào khác nhau như: tín hiệu bậc thang, tín hiệu sinus, xung chữ nhật, tín hiệu ngẫu nhiên, bằng cách thực hiện mô phỏng Kết quả mô phỏng có thể được xem theo thời gian thực trong môi trường Simulink hoặc Matlab Tất cả các hàm trong Matlab đều cố thể truy cập từ Simulink, và ngược lại, các kết quả tìm được trong Simulink đều có thể sử dụng và khái thác trong mô trường Matlab

Với mục đích tìm hiểu những kỹ thuật kiểm thử mới áp dụng vào hệ thống nhúng, tôi nhận thấy việc nghiên cứu các phương pháp kiểm thử tự động dựa trên

mô hình trong hệ thống nhúng là một vấn đề rất cần thiết hiện nay

Luận văn sẽ được cấu trúc với các chương như sau:

Chương 1 : Tổng quan về hệ thống nhúng và kiểm thử trong hệ thống nhúng Chương 2 : Phương pháp kiểm thử dựa trên mô hình hệ thống nhúng

Chương 3: Thử nghiệm và đánh giá

Luận văn sẽ khảo sát bài toán kiểm thử dựa trên mô hình áp dụng trong hệ thống nhúng, đề xuất một phương pháp, một mô hình kiểm thử phù hợp với quy trình hiện tại Đồng thời phương pháp đề xuất sẽ được phân tích và đánh giá bằng một số phương pháp đánh giá thông dụng trên tập dữ liệu đã có sẵn

Hệ thống nhúng (embedded system) được định nghĩa là một hệ thống chuyên dụng, thường có khả năng tự hành và được thiết kế tích hợp vào một hệ thống lớn hơn để thực hiện một chức năng chuyên biệt nào đó

Hệ thống nhúng là một thuật ngữ để chỉ một hệ thống có khả năng tự trị được nhúng vào trong một môi trường hay một hệ thống mẹ Đó là các hệ thống tích hợp

cả phần cứng và phần mềm phục vụ các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự động hoá điều khiển, quan trắc và truyền tin Đặc điểm của các hệ thống nhúng là hoạt động ổn định và có tính năng tự động hoá cao

Hệ thống nhúng thường được thiết kế để thực hiện một chức năng chuyên biệt Khác với các máy tính đa chức năng, chẳng hạn như máy tính cá nhân, một hệ thống nhúng chỉ thực hiện một hoặc một vài chức năng nhất định, thường đi kèm với những yêu cầu cụ thể và bao gồm một số thiết bị máy móc và phần cứng chuyên dụng mà ta không tìm thấy trong một máy tính đa năng nói chung Vì hệ thống chỉ được xây dựng cho một số nhiệm vụ nhất định nên các nhà thiết kế có thể tối ưu hóa

nó nhằm giảm thiểu kích thước và chi phí sản xuất Các hệ thống nhúng thường được sản xuất hàng loạt với số lượng lớn Hệ thống nhúng rất đa dạng, phong phú

về chủng loại Đó có thể là những thiết bị cầm tay nhỏ gọn như đồng hồ kĩ thuật số

và máy chơi nhạc MP3, hoặc những sản phẩm lớn như đèn giao thông, bộ kiểm soát trong nhà máy hoặc hệ thống kiểm soát các máy năng lượng hạt nhân Xét về độ phức tạp, hệ thống nhúng có thể rất đơn giản với một vi điều khiển hoặc rất phức tạp với nhiều đơn vị, các thiết bị ngoại vi và mạng lưới được nằm gọn trong một lớp

vỏ máy lớn

Các thiết bị PDA hoặc máy tính cầm tay cũng có một số đặc điểm tương tự

với hệ thống nhúng như các hệ điều hành hoặc vi xử lý điều khiển chúng nhưng các thiết bị này không phải là hệ thống nhúng thật sự bởi chúng là các thiết bị đa năng, cho phép sử dụng nhiều ứng dụng và kết nối đến nhiều thiết bị ngoại vi

1.2 Đặc điểm của hệ thống nhúng

Hệ thống nhúng thường có một số đặc điểm chung như sau:

 Các hệ thống nhúng được thiết kế để thực hiện một số nhiệm vụ chuyên dụng chứ không phải đóng vai trò là các hệ thống máy tính đa chức năng Một số hệ thống đòi hỏi ràng buộc về tính hoạt động thời gian thực để đảm bảo độ an toàn và tính ứng dụng; một số hệ thống không đòi hỏi hoặc ràng buộc chặt chẽ, cho phép đơn giản hóa hệ thống phần cứng để giảm thiểu chi phí sản xuất

 Một hệ thống nhúng thường không phải là một khối riêng biệt mà là một

hệ thống phức tạp nằm trong thiết bị mà nó điều khiển

 Phần mềm được viết cho các hệ thống nhúng được gọi là firmware và được lưu trữ trong các chip bộ nhớ ROM hoặc bộ nhớ flash chứ không phải là trong một ổ đĩa Phần mềm thường chạy với số tài nguyên phần cứng hạn chế: không có bàn phím, màn hình hoặc có nhưng với kích thước nhỏ, dung lượng bộ nhớ thấp

Với những đặc điểm như trên, việc thử nghiệm, xác định lỗi trong hệ thống nhúng gặp nhiều khó khăn Số lượng trường hợp thử nghiệm lớn, đòi hỏi phải có phương pháp và mô hình kiểm thử phù hợp

1.2.1 Giao diện

Các hệ thống nhúng có thể không có giao diện (đối với những hệ thống đơn nhiệm) hoặc có đầy đủ giao diện giao tiếp với người dùng tương tự như các hệ điều hành trong các thiết bị để bàn Đối với các hệ thống đơn giản, thiết bị nhúng sử dụng nút bấm, đèn LED và hiển thị chữ cỡ nhỏ hoặc chỉ hiển thị số, thường đi kèm với một hệ thống menu đơn giản

Còn trong một hệ thống phức tạp hơn, một màn hình đồ họa, cảm ứng hoặc

có các nút bấm ở lề màn hình cho phép thực hiện các thao tác phức tạp mà tối thiểu hóa được khoảng không gian cần sử dụng Ý nghĩa của các nút bấm có thể thay đổi theo màn hình và các lựa chọn Các hệ thống nhúng thường có một màn hình với

một nút bấm dạng cần điểu khiển (joystick button) Sự phát triển mạnh mẽ của mạng toàn cầu đã mang đến cho những nhà thiết kế hệ nhúng một lựa chọn mới là

sử dụng một giao diện web thông qua việc kết nối mạng Điều này có thể giúp tránh được chi phí cho những màn hình phức tạp nhưng đồng thời vẫn cung cấp khả năng hiển thị và nhập liệu phức tạp khi cần đến, thông qua một máy tính khác Điều này

là hết sức hữu dụng đối với các thiết bị điều khiển từ xa, cài đặt vĩnh viễn Ví dụ, các router là các thiết bị đã ứng dụng tiện ích này

1.2.2 Thiết bị ngoại vi

Hệ thống nhúng giao tiếp với bên ngoài thông qua các thiết bị ngoại vi, ví dụ như:

• Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485

• Universal Serial Bus (USB)

• Networks: Controller Area Network, LonWorks

• Bộ định thời: PLL(s), Capture/Compare và Time Processing Units

• Discrete IO: General Purpose Input/Output (GPIO)

1.2.3 Công cụ phát triển

Tương tự như các sản phẩm phần mềm khác, phần mềm hệ thống nhúng

cũng được phát triển nhờ việc sử dụng các trình biên dịch (compilers), chương trình dịch hợp ngữ (assembler) hoặc các công cụ gỡ rối (debuggers) Tuy nhiên, các nhà thiết kế hệ thống nhúng có thể sử dụng một số công cụ chuyên dụng như:

• Bộ gỡ rối mạch hoặc các chương trình mô phỏng (emulator)

• Tiện ích để thêm các giá trị checksum hoặc CRC vào chương trình, giúp hệ thống nhúng có thể kiểm tra tính hợp lệ của chương trình đó

• Đối với các hệ thống xử lý tín hiệu số, người phát triển hệ thống có thể sử dụng phần mềm workbench như MathCad/ Mathematica để mô phỏng phép toán

• Các trình biên dịch và trình liên kết (linker) chuyên dụng được sử dụng để tối ưu hóa một thiết bị phần cứng

• Một hệ thống nhúng có thể có ngôn ngữ lập trình và công cụ thiết kế riêng của nó hoặc sử dụng và cải tiến từ một ngôn ngữ đã có sẵn

Các công cụ phần mềm có thể được tạo ra bởi các công ty phần mềm chuyên dụng về hệ thống nhúng hoặc chuyển đổi từ các công cụ phát triển phần mềm GNU Đôi khi, các công cụ phát triển dành cho máy tính cá nhân cũng được sử dụng nếu

bộ xử lý của hệ thống nhúng đó gần giống với bộ xử lý của một máy PC thông dụng

hệ thống khi gặp lỗi có thể được thực hiện bằng cách sử dụng các kỹ thuật như watchdog timer – nếu phần mềm không đều đặn nhận được các tín hiệu watchdog định kì thì hệ thống sẽ bị khởi động lại

Một số vấn đề cụ thể về độ tin cậy như:

• Hệ thống không thể ngừng để sửa chữa một cách an toàn, ví dụ như ở các

hệ thống không gian, hệ thống dây cáp dưới đáy biển, các đèn hiệu dẫn đường…

Giải pháp đưa ra là chuyển sang sử dụng các hệ thống con dự trữ hoặc các phần mềm cung cấp một phần chức năng

• Hệ thống phải được chạy liên tục vì tính an toàn, ví dụ như các thiết bị dẫn đường máy bay, thiết bị kiểm soát độ an toàn trong các nhà máy hóa chất…

Giải pháp đưa ra là lựa chọn backup hệ thống, nếu hệ thống ngừng hoạt động

sẽ gây tổn thất rất nhiều tiền của ví dụ như các dịch vụ buôn bán tự động, hệ thống chuyển tiền, hệ thống kiểm soát trong các nhà máy …

1.2.5 Xu hướng phát triển của các hệ thống nhúng

Sau máy tính lớn (mainframe), PC và Internet thì hệ thống nhúng đang là làn sóng đổi mới thứ 3 trong công nghệ thông tin và truyền thông

Xu hướng phát triển của các hệ thống nhúng hiện nay là:

Phần mềm ngày càng chiếm tỷ trọng cao và đã trở thành một thành phần cấu tạo nên thiết bị bình đẳng như các phần cơ khí, linh kiện điện tử, linh kiện quang học…

• Các hệ nhúng ngày càng phức tạp hơn đáp ứng các yêu cầu khắt khe về thời gian thực, tiêu ít năng lượng và hoạt động tin cậy ổn định hơn

• Các hệ nhúng ngày càng có độ mềm dẻo cao đáp ứng các yêu cầu nhanh chóng đưa sản phẩm ra thương trường, có khả năng bảo trì từ xa, có tính cá nhân cao

• Các hệ nhúng ngày càng có tính thích nghi, tự tổ chức cao có khả năng tái cấu hình như một thực thể, một tác nhân

• Các hệ nhúng ngày càng có khả năng tiếp nhận năng lượng từ nhiều nguồn khác nhau (ánh sáng, rung động, điện từ trường, sinh học….) để tạo nên các hệ thống tự tiếp nhận năng lượng trong quá trình hoạt động

1.2.6 Những thách thức và vấn đề còn tồn tại với hệ thống nhúng

Hệ thống nhúng hiện nay còn phải đối mặt với các vấn đề sau:

• Độ phức tạp của sự liên kết đa ngành phối hợp cứng - mềm Độ phức tạp của hệ thống tăng cao do nó kết hợp nhiều lĩnh vực đa ngành, kết hợp phần cứng - mềm, trong khi các phương pháp thiết kế và kiểm tra chưa chín muồi Khoảng cách giữa lý thuyết và thực hành lớn và còn thiếu các phương pháp và lý thuyết hoàn chỉnh cho khảo sát phân tích toàn cục các hệ nhúng

• Thiếu phương pháp tích hợp tối ưu giữa các thành phần tạo nên hệ nhúng bao gồm lý thuyết điều khiển tự động, thiết kế máy, công nghệ phần mềm, điện tử,

vi xử lý, các công nghệ hỗ trợ khác

• Thách thức đối với độ tin cậy và tính mở của hệ thống: Do hệ thống nhúng thường phải hội thoại với môi trường xung quanh nên nhiều khi gặp những tình huống không được thiết kế trước dễ dẫn đến hệ thống bị loạn Trong quá trình hoạt động một số phần mềm thường phải chỉnh lại và thay đổi nên hệ thống phần mềm

có thể không kiểm soát được

Đối với hệ thống mở, các hãng thứ 3 đưa các module mới, thành phần mới vào cũng có thể gây nên sự hoạt động thiếu tin cậy

 Tìm và ngăn ngừa các lỗi

 Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng

 Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người

sử dụng

Kiểm thử sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản phẩm so với yêu cầu kinh doanh và người sử dụng Đây là giai đoạn rất quan trọng để đảm bảo

hệ thống hoạt động tốt và theo các thông số kỹ thuật

Việc xác định phạm vi kiểm tra các trường hợp kiểm thử nên được thiết kế tốt với khả năng tối đa của việc tìm kiếm các lỗi hiệu quả và được tính toán là số bug báo cáo cho mỗi trường hợp kiểm thử

Kiểm thử để chắc chắn hệ thống đang thực hiện đúng cách và đã sẵn sàng để

sử dụng Kiểm thử bao phủ các lĩnh vực khác nhau như: chức năng của các ứng dụng, khả năng tương thích của các ứng dụng với các hệ điều hành, phần cứng và các loại khác nhau của các trình duyệt, thực hiện kiểm thử để kiểm tra hiệu năng của các ứng dụng để đảm bảo rằng hệ thống đáng tin cậy và không có trục trặc hay không nên có bất kỳ vấn đề cản trở Xác định rằng các ứng dụng có thể được triển khai một cách dễ dàng với máy tính và không có bất kỳ sự cố Do đó các ứng dụng rất dễ dàng để cài đặt, tìm hiểu và sử dụng

Kiểm thử cho phép tạo ra những đánh giá khách quan về mức độ phù hợp của hệ thống các yêu cầu đã nêu và thông số kỹ thuật

Kiểm tra xác nhận rằng hệ thống đáp ứng các yêu cầu khác nhau bao gồm: chức năng, hiệu suất, độ tin cậy, an toàn, khả năng sử dụng và như vậy Việc xác nhận này được thực hiện để đảm bảo rằng đội ngũ kỹ sư đang xây dựng hệ thống phù hợp Ngoài việc giúp đưa ra quyết định, các thông tin từ các quá trình kiểm thử

sẽ giúp quản lý rủi ro

1.3.2 Nguyên tắc kiểm thử

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử hệ thống cần phải tuân thủ một số nguyên tắc sau:

 Nguyên tắc 1: Kiểm thử chỉ ra sự hiện diện của lỗi

Kiểm thử có thể chỉ ra có mặt của lỗi, nhưng không thể chứng minh rằng hệ thống không có lỗi Việc kiểm thử làm giảm xác suất các khuyết tật chưa được tìm thấy còn lại trong hệ thống hoặc phần mềm

 Nguyên tắc 2: Kiểm thử toàn bộ, đầy đủ là không thể

Kiểm thử toàn bộ (kết hợp tất cả các yếu tố đầu vào và điều kiện tiên quyết)

là không khả thi trừ những trường hợp nhỏ và đơn giản Thay vì kiểm thử đầy đủ, nên sử dụng những đánh giá rủi ro và nỗ lực để ưu tiên tập trung kiểm thử từng trường hợp

 Nguyên tắc 3: Cần bắt đầu giai đoạn kiểm thử càng sớm càng tốt

Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển

hệ thống và cần được tập trung vào các mục tiêu xác định

 Nguyên tắc 4: Phân nhóm lỗi để xác định một số module tập trung lỗi nhiều nhất

 Nguyên tắc 5: Kịch bản kiểm thử cần được cập nhật

Các bộ kịch bản kiểm thử phải được thường xuyên xem xét và cập nhật, phù hợp với từng thành phần khác nhau của hệ thống, mang lại khả năng tìm thấy lỗi lớn nhất

 Nguyên tắc 6: Kiểm thử được thực hiện khác nhau trong những bối cảnh khác nhau

1.3.3 Nội dung các nhiệm vụ trong quá trình kiểm thử

 Lập kế hoạch kiểm thử:

Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ

được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực

Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá

trình cũng như chất lượng kiểm tra Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu

Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện

việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra

Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần

cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra

Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chitiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra

Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch

chi tiết

Hình 1.1: Bản kế hoạch chính và bản kế hoạch chi tiết

Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người

có liên quan, kể cả trưởng dự án và có thể cả khách hàng Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sót trong các bản kế hoạch

 Chuẩn bị môi trường kiểm thử

Thiết kế hệ thống kiểm thử: Có những trường hợp máy được dùng cho các

vận hành nghiệp vụ phải được dùngcho chạy chương trình để kiểm thử Tuy nhiên nếu máy này lưu giữ các tệp hay cơ sở dữ liệu vẫn được truy nhập tới trong vận hành hàng ngày, hay 1 tải lượng lớn bị áp vào máy trong khi kiểm thử, thì việc sản xuất sẽ bị gây rối loạn Dó đó cần phải phát triển hay thiết kế cùng hệ điều hành, tệp

và cơ sở dữ liệu nhưng sẽ là đối tượng được dùng trong việc chạy sản xuất thực

Thiết kế chương trình kiểm thử và dữ liệu kiểm thử: Chương trình kiểm

thử phải được thiết kế, dữ liệu kiểm thử phải được chuẩn bị và các trường hợp kiểm thử phải được thiết kế bằng nhiều phương pháp

Thiết đặt các công cụ kiểm thử: Các công cụ kiểm thử cần phải được thiết

đặt phù hợp với hệ điều hành để làm giảm chi phí phát triển và làm tăng tính hiệu quả, chất lượng của kiểm thử

 Tiến hành kiểm thử:

Nhiều loại kiểm thử phải được tiến hành trong điều kiện môi trường được chuẩn bị tốt

 Kiểm tra kết quả của kiểm thử:

Kiểm thử được tiến hành tương ứng với các kế hoạch kiểm thử và đặc tả kiểm thử, và kết quả của việc kiểm thử phải được kiểm tra lại

 Phân tích hỏng hóc, phân tích hiệu năng:

Các lỗi và các hỏng hóc bị phát hiện phải được phân tích chặt chẽ bằng việc dùng các công cụ và các kĩ thuật kiểm tra chất lượng đa dạng

 Sửa chữa và cải tiến tài liệu, chương trình gốc:

Nếu lỗi hay sai sót thiết kế được tìm thấy và nếu chúng có thể được sửa chữa ngay lập tức thì chương trình nguồn phải được sửa chữa hay cải tiến Phần của tài liệu thiết kế liên quan tới các lỗi hay sai sót thiết kế như vậy cũng phải được sửa chữa đảm bảo sự nhất quán giữa chương trình nguồn và tài liệu thiết kế

 Hoàn tất quá trình kiểm thử :

Sau khi 1 kiểm thử đã được hoàn tất và chương trình đã được sửa chữa, thì các hành động sau phải được tiến hành:

- Quản lý tiến trình kiểm thử và báo cáo: Sau khi kiểm thử được hoàn tất,

kiểm thử viên phải báo cáo kết quả của việc kiểm thử bằng việc dùng báo cáo hoàn thành kiểm thử

- Kiểm soát dữ liệu liên quan tới hỏng hóc: Dữ liệu về lỗi hay khiếm

khuyết được tìm ra trong khi kiểm thử, quá trình fix lỗi phải được tích lại phục vụ cho quá trình hoàn thiện và phát triển hệ thống

- Xem lại tài liệu vận hành ngược dòng: Để ngăn cản việc lặp lại các lỗi

gây ra bởi 1 sai lầm phạm phải trong quá trình sửa lỗi

1.4 Kiểm thử tự động

Kiểm thử tự động

Sử dụng một công cụ kiểm thử tự động để thực thi các ca kiểm thử thay cho con người được goi là kiểm thử tự động Công cụ kiểm thử tự động có thể lấy dự liệu từ file bên ngoài (excel, csv, …) nhập vào ứng dụng, so sánh kết quả mong đợi với kết quả thực tế và xuất ra báo cáo kết quả kiểm thử

Ưu điểm và nhược điểm

 Ưu điểm:

- Độ tin cậy cao (Reliability): Nhờ sự ổn định vượt trội của công cụ kiểm

thử tự động so với con người, đặc biệt trong trường hợp có quá nhiều test cases cần được thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ công

- Khả năng lặp (Repeatability): Với độ ổn định cao, chúng ta hoàn toàn

có thể tin tưởng vào kết quả thực thi của công cụ kiểm thử tự động

- Khả năng tái sử dụng (Reusability): Với một bộ kiểm thử tự động,

chúng ta có thể sử dụng cho nhiều phiển bản ứng dụng khác nhau, đây được gọi là tính tái sử dụng

- Nhanh (Fast): Thực thi các test case một cách tự động sẽ đáp ứng thời

gian rất nhanh

- Chi phí thấp (Cost Reduction): Nếu áp dụng kiểm thử tự động đúng

cách, chúng ta có thể tiết kiệm được rất nhiều chi phí, thời gian và nhân lực

 Nhược điểm :

- Khó mở rộng, khó bảo trì (Poor scalability and maintainability):

Trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động là khó hơn nhiều

so với kiểm thử cách thủ công Số lượng công việc phải làm để mở rộng phạm vi cho kiểm thử tự động là nhiều hơn và khó hơn kiểm thử thủ công

- Khả năng bao phủ thấp (Low coverage): Chính vì việc khó ứng dụng,

khó mở rộng, cũng như đòi hỏi quá nhiều kỹ năng lập trình nên độ bao phủ của kiểm thử tự động khá thấp (xét trên góc nhìn toàn dự án)

- Vấn đề công cụ và nhân lực (Technology vs people issues): Cho đến

nay công cụ hỗ trợ kiểm thử tự động đã có những bước phát triển mạnh mẽ, chúng

ta có các công cụ rất tốt như QTP, Selenium, Test Complete, LoadTest, Jmeter, Visual Studio, … Nhưng nhìn chung vẫn còn rất nhiều mặt hạn chế Ngoài ra nguồn nhân lực đạt yêu cầu cũng không nhiều

Tầm quan trọng của kiểm thử tự động

- Tiết kiệm tiền bạc và thời gian: Nhận định này đặc biệt đúng nếu xét trong

giai đoạn bảo trì của các dự án lớn Mỗi tuần chúng ta phải thực hiện regression test

từ 1 đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày Gần như không thể thực hiện cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể với nguồn nhân lực vô cùng khiêm tốn

- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các ca kiểm thử với độ chính xác cao hơn

- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta

có thể thực thi số lượng lớn các ca kiểm thử trong một thời gian ngắn Điều này giúp chúng ta tăng độ bao phủ trong giai đoạn kiểm thử hồi quy (một ví dụ điển hình)

- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất

Chương 2-PHƯƠNG PHÁP KIỂM THỬ DỰA TRÊN MÔ HÌNH 2.1 Kiểm thử dựa trên mô hình

2.1.1 Kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình là một dạng kiểm thử dựa trên hành vi của các

mô hình, nó mã hóa các hành vi dự tính của một hệ thống thử nghiệm và/hoặc hành

vi trong môi trường của nó Các trường hợp kiểm thử được tạo từ một trong các mô hình hoặc là sự kết hợp của chúng và được thực hiện trên hệ thống thử nghiệm Theo phương pháp truyền thống, quá trình kiểm thử bắt đầu bằng việc sử dụng các

mô hình thường không có cấu trúc, không tái sử dụng, không được tài liệu hóa, thiếu logic hợp lý cho thiết kế kiểm thử, và dựa trên kinh nghiệm, kỹ năng của các

kỹ sư Với ý tưởng các thực thể sẽ được mã hóa tường minh vào hệ thống thử nghiệm dự kiến và các hành vi môi trường khả dĩ có thể giúp giảm thiểu các vấn đề trên

Các ý tưởng về kiểm thử dựa trên mô hình được gọi là kiểm thử dựa trên đặc

tả Trong thập kỷ vừa qua, ở lĩnh vực nghiên cứu và trong ngành công nghiệp,các phương pháp phát triển dựa trên mô hình và kiểm thử làm trung tâm, cũng như mức

độ phát triển của công nghệ từ lĩnh vực kiểm thử đã làm tăng sự quan tâm về chủ

đề Dias-Neto đã phân tích 271 tài liệu và xác định được 219 cách tiếp cận kiểm thử dựa trên mô hình Điều này cản trở việc áp dụng công nghệ kiểm thử dựa trên mô hình trong công nghiệp và hạn chế cải tiến các phương pháp tiếp cận kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình bao gồm các quá trình và các kỹ thuật nhằm: tạo các dẫn xuất tự động của các trường hợp kiểm thử trừu tượng từ các mô hình trừu tượng, tạo ra các bài kiểm thử cụ thể từ các kiểm thử trừu tượng,và thực thi thủ công hoặc tự động các trường hợp kiểm thử cụ thể

Theo Colin Campbell, kiểm thử dựa trên mô hình là một kỹ thuât kiểm thử

mà các hoạt động của hệ thống được chạy thử trong một thời gian sẽ được dự đoán trước, nó được thực hiện bởi một đặc tả hình thức hoặc một mô hình của hệ thống Các mẫu thiết kế hay mô hình là mô tả đơn giản của hệ thống dựa trên yêu cầu hệ

thống và chức năng xác định, giúp chúng ta có thể hiểu và dự đoán được hành vi của hệ thống

2.1.2 Quy trình kiểm thử dựa trên mô hình

Quá trình kiểm thử dựa trên mô hình được bắt đầu bằng việc xác định yêu cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ thống Việc xây dựng mô hình còn phải dựa trên các yếu tố dữ liệu đầu vào và đầu

ra Mô hình này được sử dụng để sinh ra các ca kiểm thử Chúng ta có thể biết kết quả đầu ra mong đợi từ mô hình hoặc từ quy định chuẩn Khi chạy kich bản và kết quả thu được sẽ so sánh với kết quả mong đợi từ đó quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử,…

Các bước để thực hiện kiểm thử dựa trên mô hình:

- Xây dựng mô hình dựa trên các yêu cầu và chức năng của hệ thống

- Tạo đầu ra dự kiến từ mô tả của bài toán

- Chạy kịch bản kiểm thử

- So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến

- Quyết định hành động tiếp theo (Sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lượng phần mềm)

Trong giới hạn luận văn, học viên sẽ giới thiệu các thuật ngữ và miêu tả chung quá trình của kiểm thử dựa trên mô hình

Một bộ kiểm thử (test suite) là một tập các ca kiểm thử (test case) Một ca

kiểm thử là một cấu trúc hữu hạn đầu vào và đầu ra mong muốn: một cặp đầu vào

và đầu ra của các hệ thống biến đổi xác định, một chuỗi đầu vào và đầu ra trong trường hợp của các hệ thống phản ứng xác định, và một cây hoặc đồ thị trong trường hợp của các hệ thống phản ứng không xác định Đầu vào của các ca kiểm thử gọi là đầu vào kiểm thử

Một tiến trình chung của kiểm thử dựa trên mô hình sẽ được thực hiện như hình đây:

Bước 1 Mô hình hệ thống kiểm thử được xây dựng từ các yêu cầu hoặc dựa

trên các tài liệu đặc tả Mô hình này được gọi là mô hình kiểm thử do nó vẫn trừu

tượng và mô hình phải tập trung liên kết trực tiếp tới các đối tượng kiểm thử Trong vài trường hợp, mô hình kiểm thử có thể là mô hình thiết kế của hệ thống thử nghiệm tuy nhiên vẫn có một vài sự khác nhau tương đối giữa mô hình sử dụng cho

bộ tạo kiểm thử và các mô hình phát triển, các lỗi xuất hiện trong mô hình phát triển

có thể không được đưa vào các bài thử nghiệm Do đó, nó thường được sử dụng để phát triển mô hình kiểm thử cụ thể từ các yêu cầu, hoặc để tái sử dụng một vài mặt của mô hình phát triển làm cơ sở cho mô hình thử nghiệm, sau đó sẽ được đối chiếu với các yêu cầu Việc đối chiếu mô hình trong đó các yêu cầu được xem xét kỹ lưỡng đáp ứng sự nhất quán và đầy đủ, và tìm thấy các lỗi

Trong kiểm thử dựa trên mô hình, việc xác thực mô hình đòi hỏi mô hình phải đơn giản hơn, trừu tượng hơn hệ thống thử nghiệm, hoặc ít nhất cũng dễ kiểm tra, thay đổi và quản lý Nếu không, việc xác thực mô hình sẽ bằng việc xác thực hệ thống thử nghiệm Điều này rất khó thực hiện Trong luận văn này, khái niệm “trừu tượng” có nghĩa sự thiếu sót có chủ ý về chi tiết trong mô hình và đóng gói của các chi tiết bằng các cấu trúc ngôn ngữ bậc cao Mô hình kiểm thử có thể nằm ở nhiều mức trừu tượng khác nhau Chuyển đổi trừu tượng chính là ánh xạ từng đầu vào với đầu ra “không có lỗi ngoại lệ” hoặc “không có sự cố” Nó cũng có thể trừu tượng ở việc bỏ qua một số chức năng, hoặc bỏ qua các thuộc tính về chất lượng dịch vụ như thời gian hoặc bảo mật

Mặt khác, mô hình phải đủ chính xác để làm cơ sở cho việc tạo ra các ca kiểm thử có ý nghĩa Các kiểm thử được tạo ra từ mô hình phải đảm bảo đầy đủ các tham số đầu vào và kết quả dự kiến để tạo ra hiệu quả thực sự Nếu không công việc thiết kế kiểm thử chỉ có thể thực hiện thủ công, và đem lại ít giá trị trong các kiểm thử được tạo ra từ mô hình

Bước 2 Lựa chọn tiêu chí kiểm thử, để việc tạo kiểm thử tự động sao cho đạt

được một bộ dữ liệu kiểm thử tốt - một bộ thỏa mãn các chính sách kiểm thử được xây dựng cho hệ thống thử nghiệm Việc xây dựng chính sách và các đối tượng kiểm thử cho một hệ thống phải rõ ràng và dự án phát triển hệ thống liên quan phải

là một phần của tất cả các phương pháp kiểm thử như TMapR hoặc các hướng dẫn

ISTQB được sử dụng rộng rãi trong công nghiệp Trong các phương pháp, chính sách kiểm thử và các đối tượng kiểm thử được xây dựng từ các tài liệu kế hoạch kiểm thử, nó xác định phạm vi kiểm thử và các chiến lược cũng như kỹ thuật kiểm thử khác nhau sẽ được sử dụng trong dự án cho từng mức độ kiểm thử (ví dụ đối tượng kiểm thử, kiểm thử tích hợp, hệ thống kiểm thử, )

Các tiêu chí lựa chọn kiểm thử có thể liên quan đến một chức năng nhất định của hệ thống (tiêu chí lựa chọn kiểm tra dựa trên yêu cầu), đến cấu trúc của mô hình kiểm thử (vùng bao phủ, vùng chuyển tiếp…), đến các đặc tính ngẫu nhiên như ngẫu nhiên thuần túy hoặc các hồ sơ người dùng, đến các thuộc tính của môi trường

và chúng cũng có thể liên quan đến một bộ lỗi đã được xác định rõ ràng

Bước 3 Tiêu chí lựa chọn kiểm thử sẽ được chuyển thành các đặc tả trường

hợp kiểm thử Các đặc tả trường hợp kiểm thử hiện thực hóa ý tưởng về tiêu chí lựa chọn kiểm thử và đưa chúng vào hoạt động như: đưa ra mô hình và đặc tả trường hợp kiểm thử Một số bộ tạo kiểm thử tự động phải có khả năng chuyển đổi bộ kiểm thử (xem Bước 4) Ví dụ, “độ bao phủ” của một máy trạng thái hữu hạn (FSM) có

thể được chuyển đổi thành một tập hợp các đặc tả trường hợp kiểm thử như {reach

s0, reach s1, reach s2, .}, trong đó s0, s1, s2, .là tất cả các trạng thái của FSM

Đặc tả trường hợp kiểm thử là một mô tả mức cao của một trường hợp kiểm thử mong muốn

Bước 4 Khi mô hình và các đặc tả của trường hợp kiểm thử đã được xác

định, một tập hợp các trường hợp kiểm thử sẽ được tạo ra, với mục đích đáp ứng được tất cả các đặc tả của trường hợp thử nghiệm Tập hợp các trường hợp kiểm thử đáp ứng một đặc tả của kiểm thử liên quan tới mô hình có thể rỗng, trong trường hợp đó đặc tả trường hợp kiểm thử được cho là không thỏa mãn Tuy nhiên, thường

có một vài hoặc nhiều trường hợp kiểm thử thỏa mãn, và bộ tạo trường hợp kiểm thử sẽ chỉ chọn một trong các trường hợp kiểm thử đó Một số bộ tạo kiểm thử có thể tối ưu hóa bộ kiểm thử, sao cho số các trường hợp kiểm thử được tạo ra ít nhất nhưng kiểm tra được nhiều các đặc tả trường hợp kiểm thử nhất

Bước 5 Khi bộ kiểm thử đã được tạo, các trường hợp kiểm thử sẽ được thực

thi Quá trình kiểm thử có thể thực hiện thủ công bởi con người hoặc tự động bởi môi trường thực thi kiểm thử, nó cung cấp các cơ sở để tự động hóa quá trình kiểm thử và ghi lại quyết định kiểm tra Đôi khi, đặc biệt với các hệ thống không xác định, quá trình tạo và thực thi các kiểm thử được ghép lại cùng nhau, chúng sẽ được gọi là kiểm thử trực tuyến (online testing) Thực hiện một trường hợp kiểm thử bao gồm một vài bước Mô hình và hệ thống thử nghiệm nằm ở các mức trừu tượng khác nhau, và các mức khác nhau này phải được liên kết

Một kịch bản kiểm thử là mã thực thi thực hiện một trường hợp kiểm thử, lấy

ra đầu ra của hệ thống kiểm thử, và sau đó xây dựng quyết định Một bộ điều hợp là khái niệm và không nhất thiết phải là một thành phần phần mềm riêng biệt - nó có thể được tích hợp trong các kịch bản kiểm thử Tóm lại, kiểm thử dựa trên mô hình bao gồm các hoạt động chính sau đây: xây dựng mô hình, xác định các tiêu chí lựa chọn kiểm tra và chuyển chúng thành các đặc tả cho trường hợp kiểm thử, tạo các kiểm thử, nhận và thiết lập thành phần bộ điều hợp (nếu các kiểm thử được tạo ra được thực hiện tự động , bộ điều hợp thường chiếm một tỷ trọng đáng kể trong tổng khối lượng công việc) và thực hiện các kiểm tra trên hệ thống thử nghiệm Mô hình của hệ thống thử nghiệm được sử dụng làm cơ sở cho việc tạo kiểm thử, nhưng cũng phục vụ để xác nhận các yêu cầu và kiểm tra sự nhất quán của chúng

2.1.3 Thuận lợi và khó khăn của kiểm thử dựa trên mô hình

 Thuận lợi

Trong quá trình phát triển hệ thống các kiểm thử viên thường thực hiện công việc của mình bằng phương pháp truyền thống nên thường thiếu thời gian để thực hiện kiểm thử, hoặc giá thành sản phẩm khi hoàn thành thường cao Kiểm thử mô hình sẽ khắc phục được một số nhược điểm đó:

- Do quá trình sinh ca kiểm thử là tự động vì vậy mà rút ngắn thời gian

phát triển hệ thống

- Đặc biệt tuy chi phí cho việc xây dựng mô hình lớn nhưng điều này sẽ được khấu trừ do chi phí bảo dưỡng thấp hơn nhiều khi hệ thống được hoạt động

- Quá trình sinh các ca kiểm thử được thực hiện một cách tự động nên sinh

ra nhiều ca kiểm thử và phát hiện nhiều lỗi

- Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết

kế vì vậy sẽ tăng thời gian giải quyết vấn đề trong kiêm thử

- Tự động tạo và kiểm tra các ca kiểm thử trùng nhau hoặc không hữu hiệu

- Khi một yêu cầu của hệ thống thay đổi thì việc thay đôi các ca kiểm thử đơn giản hơn, vì chỉ cần thay đổi mô hình của hệ thống

- Trong kiêm thử dựa trên mô hình công việc quan trọng nhất là xây dựng

mô hình Việc xây dựng mô hình cần được đầu tư thời gian, trí óc và tiền bạc

2.2 Các vấn đề của quá trình kiểm thử dựa trên mô hình

Các phương pháp kiểm thử dựa trên mô hình thường bao gồm 6 vấn đề Các vấn đề phần lớn không hoàn toàn độc lập với nhau: ví dụ, nếu kiểm thử liên quan với hệ thống liên tục chứ không phải là một hệ thống rời rạc thì sẽ hạn chế lựa chọn

mô hình hóa mô hình, tiêu chí lựa chọn kiểm tra và công nghệ tạo trường hợp kiểm thử

Hình 2.1: Phân loại quá trình kiểm thử dựa trên mô hình

(Nguồn: A Taxonomy of model- based tesing approaches- Mark Utting 2010)

Hình 2.3 giới thiệu tổng quan về các vấn đề của kiểm thử dựa trên mô hình Các giải pháp thay thế “A/B” ở các lá cho thấy các lựa chọn thay thế lẫn nhau, trong khi các đường cong chỉ ra các lựa chọn thay thế không nhất thiết loại trừ lẫn nhau (ví dụ, một số công cụ có thể sử dụng nhiều hơn một công nghệ để tạo kiểm thử, việc này khá phổ biến và để hỗ trợ một số loại tiêu chí lựa chọn kiểm thử)

Bước 1 (xây dựng mô hình) được thể hiện qua ba tham số trong danh mục

đặc tả mô hình: phạm vi, các đặc điểm và mô hình hóa mô hình

Bước 2 và 3 (lựa chọn tiêu chí kiểm thử và xây dựng đặc tả các trường

hợp kiểm thử) được phản ánh qua khối lựa chọn tiêu chí kiểm tra trong mục tạo

kiểm thử

Bước 4 (tạo kiểm thử) được thể hiện qua khối công nghệ trong mục tạo

kiểm thử

Bước 5 (thực hiện kiểm thử) được thể hiện bởi khối on/offline của mục

thực thi kiểm thử

Các quan điểm khác nhau dẫn đến việc phân loại kiểm thử dựa trên mô hình

mà không bắt đầu từ phương pháp, tất nhiên nó vẫn được chứng minh là đúng đắn

Ví dụ, có thể phân loại dựa trên các đối tượng khác nhau được phát triển hoặc sử dụng trong quá trình như: các mô hình, các đặc tả kiểm thử, các trình điều khiển thử nghiệm, thuộc tính, kiểm thử, Nguyên nhân cho quyết định sử dụng phương pháp như cơ sở vì dễ dàng phù hợp với các hoạt động của phương pháp và do đó nó không phải là khái niệm phân loại đầy đủ Tất nhiên, không có nghĩa là phân loại khác cũng không có giá trị

 Phạm vi mô hình

Phạm vi là mặt đầu tiên của mô hình, được phân loại thành một quyết định:

mô hình có xác định các đầu vào cho hệ thống thử nghiệm hay không, hoặc nó có xác định hành vi vào/ra mong muốn của hệ thống thử nghiệm không? Các mô hình chỉ có đầu vào thường dễ xác định hơn, nhưng chúng có bất lợi là các kiểm thử được tạo ra sẽ không thể hoạt động như dự đoán Các kiểm thử được tạo ra có thể thực hiện một dự đoán độ bền, chẳng hạn như kiểm tra hệ thống thử nghiệm không

bị ngừng hoạt động đột ngột hoặc tạo ra các lỗi ngoại lệ, nhưng chúng không thể kiểm tra tính chính xác của các giá trị đầu ra hệ thống thử nghiệm thực tế, do mô hình không xác định giá trị đầu ra mong đợi Vì vậy, các mô hình chỉ có đầu vào tạo

ra các dự đoán yếu không có khả năng xác minh tính đúng đắn của hành vi chức năng hệ thống thử nghiệm

Các mô hình vào/ra của hệ thống thử nghiệm không chỉ mô hình hóa các đầu vào được phép gửi tới hệ thống thử nghiệm, mà còn phải nắm bắt một số hành vi dự kiến của hệ thống thử nghiệm Tức là, mô hình phải có khả năng dự đoán trước các đầu ra dự kiến của hệ thống thử nghiệm cho mỗi đầu vào, hoặc ít nhất có thể kiểm tra xem đầu ra được tạo ra bởi hệ thống thử nghiệm có được mô hình cho phép hay không

Các mô hình đầu vào có thể được xem như các mô hình của thực tế Ví dụ: các mô hình tấn công trong kiểm thử bảo mật; chuỗi Markov được sử dụng để kiểm tra thống kê Hầu hết các mô hình trừu tượng của môi trường bất kỳ đều không xác định được tất cả các đầu vào có thể cho hệ thống thử nghiệm Một mô hình tấn công sẽ mã hóa một số hành vi có thể có của môi trường, vì vậy ít trừu tượng hơn; các chức năng cụ thể cũng có thể được mã hóa theo cách này Mô hình môi trường

cụ thể nhất, hoặc ít trừu tượng nhất sẽ xác định chính xác các đầu vào có thể được gửi tới hệ thống thử nghiệm, nhưng các mô hình môi trường cụ thể như vậy rất hiếm khi xảy ra trong thực tế

Tương tự, mô hình của hệ thống thử nghiệm có thể được cung cấp ở các mức trừu tượng khác nhau Mô hình trừu tượng nhất được tìm thấy trong kiểm tra độ bền

và không cần phải được chỉ định rõ ràng: mô hình phản ứng với bất kỳ đầu vào nào không tạo ra lỗi ngoại lệ Các mô hình cụ thể hơn sẽ xác định một số hành vi cần kiểm thử, và các mô hình rõ ràng trong triển khai cũng có thể hiểu được, mặc dù khá hiếm vì chi phí phát triển và xác nhận chúng

Trong thực tế, một mô hình kiểm thử dựa trên mô hình có phạm vi vào/ra, nó chỉ xác định một số khía cạnh của môi trường và có một số khía cạnh của hệ thống thử nghiệm, có thể ở các mức trừu tượng khác nhau

 Các đặc điểm mô hình

Các đặc điểm của mô hình liên quan đến việc kết hợp các vấn đề về thời gian, tính không xác định, và tính chất liên tục hoặc sự kiện rời rạc của mô hình Các đặc tính của mô hình thường được chọn dựa trên loại hệ thống thử nghiệm đang được thử nghiệm

Các vấn đề về thời gian đặc biệt có liên quan các hệ thống thời gian thực Bởi

vì mức độ bổ sung, các hệ thống này nổi tiếng là khó kiểm tra Áp dụng các ý tưởng kiểm thử dựa trên mô hình vào các hệ thống thời gian thực là chủ đề của các hoạt động nghiên cứu hiện nay

Tính không xác định có thể xảy ra trong mô hình và/hoặc hệ thống thử nghiệm Nếu hệ thống thử nghiệm thể hiện jitter trong các miền thời gian hoặc miền