GIỚI THIỆU
Đặt vấn đề
Ngày nay, hệ thống nhúng đang phát triển mạnh mẽ với ứng dụng rộng rãi trong nhiều lĩnh vực công nghiệp và đời sống Kiến trúc phần cứng và phần mềm của các hệ thống này rất đa dạng và phong phú Kiểm thử phần mềm đóng vai trò quan trọng, quyết định sự thành công của sản phẩm, và đối với phần mềm nhúng, điều này cũng không ngoại lệ Sự phát triển của hệ thống nhúng đã dẫn đến những yêu cầu mới trong hoạt động kiểm thử phần mềm nhúng.
Một phương pháp phổ biến để kiểm thử phần mềm trong hệ thống nhúng là sử dụng chương trình giả lập phần cứng Chương trình giả lập này có thể là vi điều khiển ảo hoặc mô phỏng toàn bộ hệ thống mạch, bao gồm vi điều khiển và các thiết bị khác.
Hệ thống nhúng tại Việt Nam hiện đang phát triển khá khiêm tốn so với thế giới, đặc biệt là lĩnh vực kiểm thử nhúng Số lượng bài báo và tài liệu về kiểm thử nhúng rất hạn chế, cùng với đó là sự thiếu hụt công cụ hỗ trợ Do vậy, nghiên cứu và tìm hiểu các phương pháp, kỹ thuật kiểm thử cũng như công cụ cho phần mềm nhúng là vô cùng cần thiết Điều này sẽ thúc đẩy sự phát triển của lĩnh vực hệ thống nhúng, một lĩnh vực giàu tiềm năng nhưng vẫn đang ở giai đoạn đầu phát triển tại Việt Nam.
Trong bài viết này, tôi nghiên cứu về kiểm thử dựa trên mô hình sử dụng NModel trong phát triển phần mềm nhúng Cụ thể, tôi tập trung vào kiểm thử cho hệ thống Client/Server, với ứng dụng là thiết bị điều khiển từ xa tích hợp cảm biến nhiệt độ.
Nội dung nghiên cứu
Mục tiêu của luận văn này là nghiên cứu và phát triển phương pháp kiểm thử dựa trên mô hình, nhằm hỗ trợ hiệu quả cho việc phát triển hệ thống nhúng.
Nhiệm vụ của luận văn này là nghiên cứu ứng dụng cụ thể của NModel và áp dụng kiểm thử cho bài toán thiết bị điều khiển từ xa Client/Server.
Luận văn này nghiên cứu lý thuyết hệ thống nhúng và các phương pháp phân tích, kiểm thử phần mềm dựa trên mô hình Nó cũng khảo sát các chương trình mô hình trong NModel để kiểm thử thiết bị điều khiển từ xa Client/Server Bằng cách áp dụng quy trình kiểm thử ngoại tuyến và kiểm thử trực tuyến (on-the-fly), luận văn đã đưa ra những hiểu biết sâu sắc về phân tích và kiểm thử phần mềm trong bối cảnh cụ thể này.
Hệ thống Client/Server với thiết bị điều khiển từ xa là một ví dụ điển hình về hệ thống nhúng đơn giản, không cần sử dụng hệ điều hành nhúng Các chương trình trong hệ thống này được phát triển bằng ngôn ngữ C# và được kiểm thử thông qua mô phỏng bằng công cụ NModel.
Tầm quan trọng của kiểm thử dựa trên mô hình
Trong phát triển phần mềm, kiểm thử viên thường sử dụng phương pháp truyền thống, dẫn đến sự nhàm chán và tốn thời gian do tính lặp đi lặp lại của công việc Kiểm thử dựa trên mô hình sẽ giúp khắc phục những vấn đề này, mang lại hiệu quả cao hơn trong quá trình kiểm thử.
Quá trình sinh ca kiểm thử tự động giúp rút ngắn thời gian phát triển phần mềm, cải thiện chất lượng sản phẩm và tạo ra nhiều ca kiểm thử, từ đó phát hiện nhiều lỗi hơn.
Loại bỏ đƣợc sự nhàm chán và tính chủ quan khi làm việc nên giúp cho các kiểm thử viên hài lòng với công việc của mình
Tự động tạo và kiểm tra để tránh các ca kiểm thử trùng nhau hoặc không hữu hiệu
Khi có yêu cầu thay đổi hệ thống thì việc thay đổi các ca kiểm thử chỉ việc thay đổi mô hình của hệ thống.
Cấu trúc luận văn
Các phần còn lại của luận văn có cấu trúc nhƣ sau:
Chương 2 trình bày tổng quan về hệ thống nhúng và phần mềm nhúng
Chương 3 trình bày về lý thuyết phân tích và kiểm thử dựa trên mô hình, và hệ thống với các mô hình hữu hạn
Chương 4 giới thiệu về cách cài đặt và cách sử dụng công cụ NModel, trình bày về bài toán và kết quả thực nghiệm kiểm thử hệ thống Client/Server – thiết bị điều khiển từ xa
Cuối cùng là kết luận về quá trình nghiên cứu, đƣa ra các kết quả đạt đƣợc, và hướng nghiên cứu tiếp theo.
TỔNG QUAN VỀ HỆ THỐNG NHÚNG
Các khái niệm về hệ thống nhúng
Ngày nay, chúng ta gặp nhiều thiết bị liên quan đến hệ thống nhúng như đồng hồ kỹ thuật số, ô tô, đèn giao thông, máy giặt và hệ thống kiểm soát năng lượng hạt nhân Vậy hệ thống nhúng thực chất là gì? Theo định nghĩa, hệ thống nhúng là một hệ thống tự trị được tích hợp vào môi trường hoặc hệ thống mẹ, bao gồm cả phần cứng và phần mềm, phục vụ cho các ứng dụng chuyên dụng trong nhiều lĩnh vực như công nghiệp, tự động hóa điều khiển, quan trắc và truyền tin.
Hệ thống nhúng khác biệt so với máy tính đa chức năng vì nó được thiết kế để thực hiện một chức năng chuyên biệt Với đặc điểm hoạt động ổn định và khả năng tự động hóa cao, hệ thống này mang lại hiệu suất tối ưu cho các ứng dụng cụ thể.
Sau đây là một số ví dụ điển hình về hệ thống nhúng:
Các hệ thống dẫn đường trong không lưu, hệ thống định vị toàn cầu, vệ tinh
Các thiết bị gia dụng: tủ lạnh, lò vi sóng, lò nướng
Các thiết bị kết nối mạng: router, hub, gateway
Các thiết bị văn phòng: máy photocopy, máy fax, máy in, máy scan
Các thiết bị y tế: máy thẩm thấu, máy điều hòa nhịp tim
Các máy trả lời tự động
Dây chuyền sản xuất tự động trong công nghiệp, robots
Hình 2.1: Mẫu xe trong cuộc thi Micom Car Rally (chip Renesas H8)
Hình 2.2: Một số hệ thống nhúng thông dụng nhƣ robot, máy in và điện thoại
Thời gian thực là khái niệm khó định nghĩa chính xác, thường gặp trong các bài toán điều khiển Để hiểu đúng về thời gian thực, cần nhận thức rằng nó liên quan đến yêu cầu khắt khe về ràng buộc thời gian Cụ thể, các yêu cầu của hệ thống phải được thực hiện đúng trong một khung thời gian xác định, khung thời gian này được quy định bởi các yêu cầu của hệ thống.
Thời gian thực được chia thành hai loại chính: thời gian thực cứng (hard real-time) và thời gian thực mềm (soft real-time) Theo định nghĩa, thời gian thực cứng yêu cầu các nhiệm vụ phải hoàn thành trong một khoảng thời gian nhất định, trong khi thời gian thực mềm cho phép một số độ trễ nhất định mà không ảnh hưởng nghiêm trọng đến hệ thống.
Thời gian thực cứng là khái niệm trong đó hệ thống phải hoạt động theo các yêu cầu thời gian nghiêm ngặt Nếu các ràng buộc thời gian này không được đáp ứng, hậu quả có thể dẫn đến sự sai lệch hoặc thậm chí phá hủy toàn bộ hệ thống.
Thời gian thực mềm là một khái niệm trong đó hệ thống có khả năng hoạt động hiệu quả ngay cả khi các yêu cầu không được đáp ứng chính xác trong khoảng thời gian quy định Nếu có sự vi phạm nhưng nằm trong giới hạn cho phép, hệ thống vẫn có thể tiếp tục hoạt động và được coi là chấp nhận được.
Trong hệ thời gian thực cứng, máy hỗ trợ nhịp tim đóng vai trò quan trọng trong quá trình phẫu thuật, vì thuật toán điều khiển phải tuân thủ thời gian nhịp tim của bệnh nhân Bất kỳ sự chậm trễ nào trong thời gian này có thể đe dọa tính mạng của người bệnh.
Cây rút tiền tự động (ATM) là một ví dụ điển hình về hệ thời gian thực mềm Khi người dùng đưa thẻ ATM vào máy, có thể xảy ra tình trạng nghẽn mạng, dẫn đến việc rút tiền bị trễ vài giây hoặc thậm chí vài phút Tuy nhiên, người rút tiền vẫn có thể kiên nhẫn chờ đợi mà không gặp phải thiệt hại nào.
Hệ thống nhúng hiện đang được ứng dụng rộng rãi và dự kiến sẽ tiếp tục phát triển mạnh mẽ trong tương lai Các lĩnh vực và sản phẩm thị trường của hệ thống nhúng có thể được phân loại thành nhiều nhóm khác nhau.
Các thiết bị điều khiển
Hệ thống nhà thông minh
Cấu trúc phần cứng hệ thống nhúng
2.2.1.1 Đơn vị xử lý trung tâm (CPU)
CPU, viết tắt của "Central Processing Unit", là bộ xử lý trung tâm, đóng vai trò như bộ não của máy tính, thực hiện các phép tính và lệnh Đây là một mạch tích hợp phức tạp với hàng triệu transistor được bố trí trên một bảng mạch nhỏ.
Bộ xử lý trung tâm bao gồm đơn vị logic toán học ALU (Arthimetic Logic Unit), bộ giải mã (decoder), bộ tuần tự (sequencer) và các thanh ghi
Trong tài liệu [1], cơ chế làm việc của CPU đƣợc giải thích nhƣ sau:
Bộ giải mã chuyển đổi lệnh lưu trữ trong bộ mã chương trình thành mã mà ALU có thể hiểu và thực thi Bộ tuần tự quản lý dòng dữ liệu qua bus dữ liệu của vi xử lý Các thanh ghi lưu trữ tạm thời dữ liệu chính cho việc thực thi lệnh và có thể thay đổi nội dung trong quá trình hoạt động của ALU Hầu hết các thanh ghi của vi xử lý là bộ nhớ được tham chiếu và hội nhập với khu vực bộ nhớ, có thể sử dụng như bất kỳ khu vực nhớ nào khác.
Bộ nhớ là một tài nguyên thiết yếu không chỉ trong hệ thống nhúng mà còn trong mọi loại hệ thống khác, bao gồm cả hệ thống con người Kiến trúc bộ nhớ được phân chia thành hai loại chính: kiến trúc bộ nhớ Von Neumann và kiến trúc bộ nhớ Harvard.
Kiến trúc bộ nhớ von Neumann và Havard đƣợc biểu diễn nhƣ trong hình 2.4
Hình 2.4: Kiến trúc bộ nhớ Von Neumann và Havard
Kiến trúc Von Neumann không phân biệt giữa vùng chứa dữ liệu và mã chương trình, trong khi kiến trúc Harvard tách biệt hai vùng này Mã chương trình được lưu trữ trong ROM và dữ liệu trong RAM Hiện nay, kiến trúc bộ nhớ Harvard đang được ưa chuộng hơn trong các vi xử lý nhúng, như chip 8031, PIC và Atmel AVR90S Lý do chính là Harvard có ưu điểm nổi bật với hai kênh tách biệt cho phép truy cập đồng thời vào bộ nhớ dữ liệu và mã chương trình, từ đó tăng tốc độ trao đổi với bộ xử lý.
Máy tính và hệ vi xử lý giao tiếp với môi trường bên ngoài thông qua các thiết bị ngoại vi Những thiết bị này đóng vai trò quan trọng trong việc trao đổi dữ liệu.
Các thiết bị vào chuẩn nhƣ bàn phím, chuột
Các thiết bị ra chuẩn nhƣ màn hình, máy in
Các bộ nhớ ngoài chuẩn nhƣ ổ cứng, CD ROM
Các hệ đo lường, điều khiển
Cấu trúc ghép nối giữa máy vi tính và thiết bị ngoại vi đƣợc thể hiện trong hình 2.5
Bộ phối ghép là cầu nối giữa máy vi tính và các thiết bị ngoại vi, có nhiệm vụ nhận dữ liệu từ máy tính và cung cấp dữ liệu cho thiết bị ngoài Ngược lại, khi nhận dữ liệu từ thiết bị ngoại vi, bộ phối ghép sẽ chuyển tiếp thông tin đó đến máy tính Chức năng chính của bộ phối ghép là phối hợp trao đổi dữ liệu giữa máy tính và thiết bị ngoài, đảm bảo sự tương thích về mức công suất, dạng tín hiệu, tốc độ và phương thức trao đổi.
Hình 2.5: Cấu trúc ghép nối giữa máy tính và thiết bị ngoại vi
Phối hợp về mức và công suất tín hiệu: Máy tính thường có mức tín hiệu là
Các thiết bị điện tử thường sử dụng mức điện áp thấp (0V, 5V), trong khi các thiết bị bên ngoài yêu cầu điện áp cao (± 15V, ± 48V) hoặc rất thấp (dưới 1V) Do đó, bộ phối ghép cần điều chỉnh các mức tín hiệu cho phù hợp Hơn nữa, công suất tín hiệu trên bus dữ liệu rất nhỏ (vài chục mA), trong khi các thiết bị bên ngoài lại cần công suất lớn hơn nhiều Vì vậy, bộ phối ghép cũng phải biến đổi công suất để đáp ứng yêu cầu này.
Bộ phối ghép cần đảm bảo tính tương thích trong cơ chế trao đổi dữ liệu giữa máy tính và thiết bị ngoại vi, đặc biệt là về dạng dữ liệu tín hiệu.
Máy tính hoạt động với tốc độ cao trong khi các thiết bị ngoại vi thường có tốc độ chậm hơn Do đó, bộ phối ghép cần phải có khả năng truyền và nhận dữ liệu nhanh chóng với máy tính, đồng thời đảm bảo khả năng xử lý dữ liệu chậm hơn khi làm việc với các thiết bị ngoại vi.
Phối hợp về phương thức trao đổi dữ liệu
Khi máy tính yêu cầu trao đổi dữ liệu, quá trình bắt đầu bằng việc gửi lệnh điều khiển để khởi động bộ phối ghép hoặc thiết bị ngoại vi Máy tính sẽ đọc tín hiệu phản hồi; nếu có tín hiệu sẵn sàng, quá trình trao đổi tin sẽ diễn ra Nếu không có tín hiệu, máy tính sẽ thêm một chu kỳ chờ và kiểm tra lại trạng thái Chỉ khi trạng thái được xác nhận là sẵn sàng, máy tính mới tiến hành trao đổi thông tin.
Khi thiết bị ngoại vi yêu cầu trao đổi tin, nó sẽ gửi yêu cầu tới bộ xử lý ngắt của khối ghép nối (KGN) Nếu có nhiều thiết bị cùng gửi yêu cầu, KGN sẽ xử lý theo mức ưu tiên đã định trước và chuyển yêu cầu tới máy tính Sau khi nhận yêu cầu, máy tính sẽ chuẩn bị cho việc trao đổi và gửi tín hiệu xác nhận sẵn sàng KGN sẽ nhận tín hiệu xác nhận và truyền lại cho thiết bị ngoại vi Quá trình trao đổi tin sẽ diễn ra giữa thiết bị ngoại vi với KGN, và KGN sẽ trao đổi với máy tính, tùy thuộc vào việc gửi hoặc nhận dữ liệu.
2.2.1.4 Bus địa chỉ, bus dữ liệu và bus điều khiển
Bus địa chỉ là các đường dẫn tín hiệu logic một chiều, có chức năng truyền địa chỉ tham chiếu đến các khu vực nhớ và xác định vị trí lưu trữ dữ liệu trong không gian bộ nhớ Trong quá trình hoạt động, CPU điều khiển bus địa chỉ để truyền dữ liệu giữa CPU và bộ nhớ, với dữ liệu thường được lưu trữ ở định dạng 8 bít, 16 bít hoặc hơn.
Vi xử lý và vi điều khiển có cấu trúc 32 bít, với địa chỉ dữ liệu thường được đánh theo khối 8 bít CPU có khả năng truy cập trực tiếp các khu vực bộ nhớ thông qua địa chỉ tham chiếu Nếu vi xử lý có N bít địa chỉ, nó có thể đánh được 2^N địa chỉ khu vực mà CPU có thể tham chiếu Các khu vực được đánh địa chỉ bắt đầu từ 0 và tăng dần đến 2^N - 1 Độ rộng của bus dữ liệu thường là 16, 20, 24 hoặc 32 bít.
Bus dữ liệu là các kênh truyền tải thông tin hai chiều giữa CPU, bộ nhớ và các thiết bị ngoại vi CPU điều khiển bus dữ liệu để thực hiện việc đọc và ghi dữ liệu cũng như mã lệnh Độ rộng của bus dữ liệu xác định lượng dữ liệu có thể được truyền và trao đổi, trong khi tốc độ truyền dữ liệu được đo bằng đơn vị byte/s.
Bus điều khiển: Theo tài liệu [1], bus điều khiển đƣợc giải thích nhƣ sau:
Bus điều khiển là thành phần quan trọng trong việc truyền tải thông tin dữ liệu, giúp điều khiển hoạt động của hệ thống Nó thường chứa các tín hiệu chu kỳ, đảm bảo sự đồng bộ giữa các nhịp chuyển động và hoạt động của hệ thống CPU đóng vai trò chính trong việc điều khiển bus điều khiển, nhằm đồng bộ hóa nhịp hoạt động và dữ liệu trao đổi Đối với vi xử lý sử dụng bus dữ liệu và bus địa chỉ chung, cần có tín hiệu điều khiển để phân nhịp truy cập, cho phép lưu trữ thông tin địa chỉ khi bắt đầu chu kỳ truyền.
Kiến trúc phần mềm nhúng
Kiến trúc phần mềm đơn giản nhất được gọi là "round robin", trong đó không có ngắt và tổ chức phần mềm bao gồm một vòng lặp chính Bộ vi xử lý thực hiện việc thăm dò từng thiết bị theo thứ tự và cung cấp dịch vụ khi có yêu cầu Sau khi phục vụ tất cả các thiết bị, vòng lặp sẽ bắt đầu lại từ đầu Kiến trúc này được minh họa bằng đồ thị và đoạn giả mã.
Hình 2.8: Minh họa kiến trúc RR bằng giả mã và đồ thị
Kiến trúc round robin được áp dụng trong nhiều ứng dụng như máy bán hàng tự động, máy ATM và thiết bị gia dụng như lò vi sóng Phương pháp này có ưu điểm là đơn giản, chi phí phát triển thấp và chu kỳ phát triển ngắn Tuy nhiên, nhược điểm của round robin là không xử lý được các vấn đề phức tạp, gây lãng phí thời gian trong việc kiểm tra thiết bị không cần phục vụ, và không hiệu quả khi có quá nhiều thiết bị cần được phục vụ, dẫn đến chậm trễ.
2.3.2 Kiến trúc Round-Robin với ngắt (RRI)
Kiến trúc Round-Robin với ngắt (RRI) là một phương pháp quản lý tác vụ hiệu quả, cho phép xử lý các tác vụ cấp bách trong khi vẫn duy trì một chu trình hoạt động liên tục Trong kiến trúc này, các dịch vụ thường xuyên bị gián đoạn để ưu tiên các tác vụ quan trọng, với một bộ cờ theo dõi trong vòng lặp chính Khi không có tác vụ cấp bách nào, bộ vi xử lý sẽ tiếp tục thực hiện luân phiên các tác vụ khác Kiến trúc RRI có thể được minh họa bằng giả mã, cho thấy cách thức hoạt động của nó trong thực tế.
RRI mang lại lợi thế rõ ràng về thời gian đáp ứng cho các tác vụ ưu tiên cao Mặc dù ISR luôn có ưu tiên hơn vòng lặp chính, dẫn đến việc vòng lặp chính phải tạm dừng để phục vụ ngắt, nhưng điều này vẫn khá đơn giản Thời gian đáp ứng tồi tệ nhất cho tác vụ ưu tiên thấp bao gồm tổng thời gian thực hiện tất cả mã lệnh trong vòng lặp chính và các thủ tục gián đoạn dịch vụ Hơn nữa, sự xuất hiện của ngắt có thể gây ra vấn đề chia sẻ dữ liệu.
Hình 2.9: Minh họa kiến trúc RRI bằng giả mã
2.3.3 Kiến trúc lập lịch dòng chức năng (FQS)
Kiến trúc lập lịch dòng chức năng (Function-Queue Scheduling - FQS) là một mô hình cơ bản trong hệ điều hành cho máy tính đa năng, nơi tất cả các yêu cầu được xếp vào hàng đợi với mức độ ưu tiên nhất định Vi xử lý sẽ thực hiện các yêu cầu dựa trên cơ chế lập lịch đã được thiết lập FQS hỗ trợ nhiều cơ chế lập lịch khác nhau, bao gồm lập lịch ưu tiên theo thứ tự đến trước phục vụ trước, lập lịch theo độ ưu tiên cao hơn, lập lịch ưu tiên cho các yêu cầu đơn giản, và lập lịch giả song song, trong đó mỗi yêu cầu được phục vụ trong một khoảng thời gian ngắn trước khi quay lại phục vụ sau.
FQS có ưu điểm nổi bật là phục vụ đầy đủ tất cả các yêu cầu mà không bỏ sót bất kỳ yêu cầu nào Tuy nhiên, FQS lại gặp khó khăn trong việc đánh giá thời gian và tài nguyên cần thiết cho từng yêu cầu.
2.3.4 Kiến trúc hệ điều hành thời gian thực (RTOS)
Kiến trúc hệ điều hành thời gian thực (RTOS) có ba đặc điểm nổi bật: (1) Quá trình điều khiển giữa các chu trình ngắt và mã nguồn thực thi tác vụ được quản lý trực tiếp bởi RTOS, giúp loại bỏ sự cần thiết của biến chia sẻ (2) RTOS tự động lập lịch các tác vụ mà không cần sử dụng vòng lặp chính để quyết định tác vụ tiếp theo hoặc ngắt tiếp theo (3) RTOS có khả năng tạm dừng một tác vụ đang thực thi để chuyển sang thực thi tác vụ khác.
RTOS (Hệ điều hành thời gian thực) vượt trội so với các kiến trúc khác nhờ khả năng đáp ứng các yêu cầu ràng buộc về thời gian, khả năng chịu lỗi cao và hỗ trợ xử lý đa nhiệm Với RTOS, người dùng có thể thay đổi tác vụ trong chế độ Round Robin hoặc lập lịch theo hàng đợi mà không làm ảnh hưởng đến thời gian đáp ứng của các tác vụ có độ ưu tiên cao hơn RTOS được ứng dụng rộng rãi và trở thành giải pháp thiết yếu cho các hệ thống yêu cầu thời gian phản hồi nghiêm ngặt Tuy nhiên, RTOS cũng có nhược điểm như cần thêm thời gian để xử lý thông tin tác vụ, dẫn đến ảnh hưởng đến hiệu suất Ngoài ra, chi phí đầu tư cho các sản phẩm thương mại của RTOS thường cao.
Hệ điều hành thời gian thực
Hệ điều hành thời gian thực (RTOS) là phần mềm điều khiển chuyên dụng, thường được sử dụng trong các ứng dụng điện toán nhúng RTOS được thiết kế để hoạt động hiệu quả trong môi trường có tài nguyên bộ nhớ hạn chế, đồng thời yêu cầu thời gian đáp ứng nhanh, tính sẵn sàng cao và khả năng tự kiểm soát chính xác.
RTOS có khả năng tách biệt với ứng dụng, vì thế nếu có một chương trình bị
RTOS có khả năng cô lập nhanh chóng các chương trình gặp sự cố hoặc hoạt động không hợp lệ, kích hoạt cơ chế phục hồi để bảo vệ các chương trình khác và hệ điều hành khỏi các lệnh sai Bên cạnh đó, cơ chế bảo vệ cũng được áp dụng để ngăn chặn tình trạng tràn bộ nhớ do các chương trình gây ra.
Hệ điều hành thời gian thực là hệ điều hành hỗ trợ khả năng xây dựng các hệ thống thời gian thực
Hình 2.10: So sánh kiến trúc RTOS và OS chuẩn
Hệ điều hành với phần lõi là hạt nhân phải đảm bảo các tác vụ chính sau:
Xử lý ngắt bao gồm việc lưu trữ ngữ cảnh chương trình khi ngắt xảy ra, đồng thời nhận dạng và chọn bộ xử lý phù hợp để phục vụ cho dịch vụ ngắt.
Điều khiển quá trình hoạt động: Tạo và kết thúc quá trình/tác vụ Lập lịch và điều phối hoạt động hệ thống Định thời
Điều khiển ngoại vi: Xử lý ngắt Khởi tạo giao tiếp vào ra
Hình 2.11: Cấu trúc hệ điều hành thời gian thực
2.4.2 Tác vụ (Task) và trạng thái tác vụ
Tác vụ là một luồng thực thi độc lập có khả năng cạnh tranh để chiếm quyền thực thi Mỗi ứng dụng được chia thành nhiều tác vụ nhằm tối ưu khả năng đáp ứng vào ra trong luật thời gian Tác vụ được định nghĩa là một tập hợp các tham số và cấu trúc dữ liệu, bao gồm các thành phần như tên tác vụ, ID, độ ưu tiên, khối điều khiển tác vụ, ngăn xếp và các thủ tục thực thi Các thành phần này được thể hiện rõ ràng trong hình 2.12.
Các tác vụ trong hệ thống nhúng thời gian thực có ba trạng thái chính: sẵn sàng (Ready), đang thực thi (Running) và khóa (Blocked) Trong quá trình hoạt động, các tác vụ sẽ chuyển đổi giữa các trạng thái này theo quy luật của máy trạng thái hữu hạn (FSM) Các chuyển đổi trạng thái được minh họa rõ ràng trong hình 2.13.
Tất cả dữ liệu cần thiết đã được chuẩn bị sẵn sàng và các tác vụ sẽ được thực hiện ngay khi bộ vi xử lý có khả năng xử lý Nhiều tác vụ có thể được kích hoạt bất cứ lúc nào và sẽ được thực hiện theo thứ tự ưu tiên.
Chạy: Mã tác vụ đang được thực thi bởi bộ vi xử lý Tại bất kỳ thời điểm nào, chỉ có một tác vụ duy nhất có thể được chạy.
Một tác vụ có thể bị khóa và chờ đợi dữ liệu cho một sự kiện xảy ra Nếu không được ưu tiên, tác vụ sẽ bị khóa sau khi hoàn thành Trong cùng một thời điểm, có thể có nhiều nhiệm vụ bị khóa.
Hình 2.12: Cấu trúc của một Task cơ bản
Hình 2.13: Các trạng thái của task 2.4.3 Queue và các trạng thái của queue
Hàng đợi Queue là một công cụ quan trọng trong việc giao tiếp dữ liệu giữa các Task, hoạt động như một bộ nhớ đệm (Buffer) để gửi và nhận thông điệp (message) Nó cho phép các Task hoặc ISR giao tiếp và đồng bộ dữ liệu hiệu quả bằng cách giữ thông điệp tạm thời từ bên gửi (sender) cho đến khi bên nhận (intended receiver) sẵn sàng đọc dữ liệu.
Khi thông điệp Queue được khởi tạo, nó sẽ được gán vào một khối quản lý Queue, bao gồm tên thông điệp, ID, bộ nhớ đệm, chiều dài Queue, độ dài tối đa của mỗi thông điệp, cùng với một hoặc nhiều danh sách các task đang chờ xử lý.
Các trạng thái của Queue bao gồm rỗng (Empty), không rỗng (Not Empty) và đầy (Full), như thể hiện trong hình 2.15 Mỗi Queue chỉ có thể ở một trong những trạng thái này.
Hình 2.15: Trạng thái của Queue
2.4.4 Các phương pháp lập lịch
Lập lịch là quá trình phân bổ và gán quy trình thực thi các tác vụ cho bộ xử lý, đảm bảo rằng mỗi tác vụ được thực hiện một cách hoàn chỉnh.
Hình 2.16: Phân loại các phương pháp lập lịch
Tùy vào loại hình tác vụ mà người ta phân ra hai phương pháp lập lịch là có chu kỳ và không có chu kỳ
Lập lịch non-preemptive đảm bảo rằng các tác vụ được hoàn thành trong mỗi lần thực thi, dẫn đến thời gian phản hồi cho các sự kiện khác có thể kéo dài Ngược lại, lập lịch preemptive cho phép các tác vụ bị tạm dừng, giúp cải thiện thời gian phản hồi cho các sự kiện khác.
Phương pháp lập lịch này khắc phục nhược điểm của lập lịch non-preemptive khi thời gian thực thi các tác vụ kéo dài, cho phép các tác vụ được thực hiện và có thể bị ngắt để phục vụ các tác vụ khác Cơ chế này đảm bảo thời gian đáp ứng nhanh cho các sự kiện và tác vụ ngắn Lập lịch offline/tĩnh được thực hiện dựa trên dự báo về các sự kiện tác vụ, được quyết định trong giai đoạn thiết kế và áp dụng cố định trong suốt quá trình hoạt động Ngược lại, lập lịch online/động cho phép bộ xử lý thực hiện lập lịch dựa trên thông tin hoạt động hiện tại của hệ thống, với sơ đồ lập lịch không xác định trước và có khả năng thay đổi.
Lập lịch cho hệ thống đa nhiệm với hai tác vụ, trong đó tác vụ 1 thực hiện theo chu kỳ, còn tác vụ 2 thực hiện không theo chu kỳ với thời gian thực thi lớn hơn thời gian lặp lại của tác vụ 1, là một ví dụ điển hình.
Hình 2.17: Giản đồ thời gian thực hiện lịch của tác vụ
NGHIÊN CỨU VỀ KIỂM THỬ VÀ PHÂN TÍCH DỰA TRÊN MÔ HÌNH
Tổng quan
NModel là một khung làm việc kiểm thử và phân tích dựa trên mô hình dành cho các chương trình C# Kiểm thử dựa trên mô hình thường được sử dụng cho giao thức truyền tin, ứng dụng web, hệ thống điều khiển nhúng và giao diện người dùng đồ họa.
NModel bao gồm bốn công cụ kiểm thử: mpv (Model Program Viewer), mp2dot (Model Program to Dot), otg (Offline Test Generator) và ct (Conformance Tester) Để sử dụng NModel, chương trình mô hình cần được viết bằng ngôn ngữ C# Công cụ mpv giúp trực quan hóa và phân tích hành vi của chương trình, xác nhận tính đúng đắn và kiểm tra lỗi thiết kế Để thực hiện kiểm thử, cần sử dụng bộ chạy test ct và viết một bản khai thác kiểm thử bằng C#.
Cách cài đặt và cách sử dụng bộ công cụ NModel sẽ đƣợc trình bày chi tiết trong chương 4
3.1.2 Khái niệm chương trình mô hình
Chương trình mô hình là một chương trình đơn giản hơn được sử dụng để đặc tả những gì mà một chương trình khác sẽ thực hiện Theo tài liệu [4], "một chương trình mô hình mô tả hành vi của một chương trình hoặc hệ thống khác".
Chương trình mô hình (MP-Model Program) thường có cấu trúc nhỏ gọn và đơn giản hơn so với việc thực hiện (Impl - implementation) MP có thể được phân tích để phát hiện các lỗi thiết kế trong Impl và đồng thời tạo ra các ca kiểm thử cho Impl.
Trong NModel, có hai loại MP được sử dụng: MP hợp đồng (contract model program) và MP kịch bản (scenario model program) MP hợp đồng thể hiện tất cả các hành vi hợp lệ của Impl, trong khi MP kịch bản mô tả một tập hợp các lần chạy cho một trường hợp kiểm thử cụ thể.
Hiện nay, NModel hỗ trợ hai ngôn ngữ chính để viết chương trình mô hình, bao gồm C# và một biểu diễn giới hạn cho các máy trạng thái hữu hạn (FSMs) Các MP hợp đồng thường được phát triển bằng C#, trong khi các MP kịch bản thường được thể hiện qua FSMs.
Chương trình mô hình C# sử dụng thuộc tính và kiểu dữ liệu từ thư viện NModel, đồng thời tham chiếu đến NModel.dll Các không gian tên được sử dụng để tổ chức mã nguồn, trong khi các phương thức trong MP biểu diễn các hành động của Impl, tạo thành các đơn vị hành vi Các biến trong chương trình đóng vai trò quan trọng trong việc lưu trữ và quản lý dữ liệu.
MP biểu diễn trạng thái (thông tin được lưu trữ) của Impl
3.1.3 Khái niệm phân tích dựa trên mô hình
Phân tích dựa trên mô hình (MP) là phương pháp sử dụng để gỡ lỗi và cải thiện các đặc tả cùng thiết kế, bao gồm cả bản mô tả và giao thức kiến trúc MP có thể được viết bằng ngôn ngữ C# hoặc biểu diễn dưới dạng máy trạng thái hữu hạn (FSM).
MP hoàn toàn đƣợc phân tích tự động
MP có thể được phân tích sâu hơn thông qua kỹ thuật thăm dò, một phương pháp cơ bản và hiệu quả trong việc phân tích các MP Thăm dò cho phép thực hiện các phương thức của MP một cách tự động, mang lại kết quả tối ưu qua nhiều lần chạy mô phỏng.
Trong NModel, công cụ mpv (Model Program Viewer) được sử dụng để thăm dò và hiển thị kết quả dưới dạng sơ đồ chuyển trạng thái, trong đó các chuyển đổi trạng thái, hay còn gọi là lời gọi phương thức, được biểu diễn bằng các mũi tên.
3.1.4 Khái niệm kiểm thử dựa trên mô hình
Kiểm thử dựa trên mô hình (MBT - Model-based testing) là phương pháp kiểm thử sử dụng một mô hình để mô tả cách thức hoạt động của chương trình, từ đó tự động sinh ra các ca kiểm thử (test cases).
Kiểm thử dựa trên mô hình là một kỹ thuật kiểm thử trong đó các hoạt động của hệ thống được dự đoán và chạy thử trong một khoảng thời gian nhất định, dựa trên một đặc tả hình thức hoặc mô hình của hệ thống.
MBT, hay Model-Based Testing, là một phương pháp kiểm thử phần mềm dựa trên các đặc tả đầu vào, có vai trò quan trọng trong việc kiểm thử chức năng Kỹ thuật này thuộc loại kiểm thử hộp đen, với tiền đề rằng tính ổn định và độ tin cậy của quy trình kiểm thử sẽ đảm bảo chất lượng cao cho phần mềm.
Sơ đồ đơn giản cho thấy cách MBT hoạt động đƣợc mô tả trong hình 3.1:
3.1.5 Chương trình mô hình trong quy trình phần mềm
Các chương trình mô hình đang cách mạng hóa quy trình phát triển phần mềm bằng cách cho phép kiểm chứng và kiểm thử sản phẩm sớm hơn trong dự án Việc phân tích thông qua các chương trình mô hình giúp kiểm tra bản đặc tả và thiết kế tương tự như kiểm thử đơn vị cho mã lệnh, từ đó phát hiện và sửa chữa vấn đề ngay lập tức Giống như phát triển phần mềm theo phương pháp truyền thống, các chương trình mô hình cũng tuân thủ các bước trong quy trình theo mô hình chữ V.
Để thực hiện kiểm thử hiệu quả trong mô hình chữ V của phát triển phần mềm, kiểm thử viên cần xây dựng một bản "test harness" (khai thác kiểm thử) kết nối giữa phần triển khai (Impl) và mô hình thông qua các công cụ kiểm thử.
Hệ thống với các mô hình hữu hạn
Hành động (Actions) là các đơn vị của hành vi trong nhiều hệ thống, bao gồm cả hệ thống máy tính, nơi hành vi được cấu thành từ các bước rời rạc không liên tục Mỗi bước này được coi là một hành động, có thể bao gồm nhiều hành động nhỏ hơn Tuy nhiên, một hành động là nguyên tử, nghĩa là khi nó bắt đầu, nó sẽ hoàn thành mà không bị gián đoạn hoặc bị thay thế bởi một hành động khác Trong hệ thống Impl, mỗi loại hành động đều có một phương thức tương ứng.
MP Khi MP chạy, mỗi lời gọi phương thức biểu diễn một hành động trong Impl
Trạng thái trong một chương trình hoặc hệ thống được định nghĩa là thông tin được lưu trữ tại một thời điểm nhất định Trong ngữ cảnh của Impl, trạng thái được thể hiện qua các biến trong MP, với mỗi nhiệm vụ cụ thể đại diện cho một trạng thái cụ thể của Impl Những biến này, được gọi là biến trạng thái, khác với các biến địa phương hay tham số trong MP Đặc biệt, các biến trạng thái không nhất thiết phải tương ứng chính xác với các biến trong Impl, mà có thể phản ánh thông tin không được lưu trữ trong các biến của Impl, chẳng hạn như thông điệp chuyển tiếp.
Tất cả các chương trình hoặc hệ thống bắt đầu với một trạng thái khởi tạo, thường là trạng thái rỗng hoặc nhàn rỗi Hệ thống sẽ tiếp tục hoạt động cho đến khi đạt được trạng thái chấp nhận, nơi mục tiêu của chương trình được hoàn thành Tại trạng thái chấp nhận, hệ thống có thể dừng lại hoặc bắt đầu công việc mới Một chuỗi hành động từ trạng thái khởi tạo đến trạng thái chấp nhận được gọi là đường chạy hoặc dấu vết Đường chạy không thể kết thúc ở trạng thái chưa chấp nhận, trừ khi không có trạng thái chấp nhận nào được xác định, khi đó nó có thể kết thúc ở bất kỳ trạng thái nào Các đường chạy của một máy tính là chuỗi các lời gọi phương thức.
Hành vi của một chương trình hoặc hệ thống là tổng hợp tất cả các đường chạy mà nó có thể thực hiện Một MP hợp đồng là bản đặc tả chi tiết hành vi được phép của Impl, mô tả những gì Impl phải làm, có thể làm và không được làm Mỗi đường chạy mà MP hợp đồng có thể thực thi thể hiện khả năng thực thi của Impl Nếu một MP hợp đồng không thể thực thi bất kỳ đường chạy nào, Impl của nó sẽ bị cấm thực hiện Thông thường, một MP hợp đồng sở hữu bộ sưu tập đường chạy rất phong phú.
Một kịch bản là tập hợp các đường chạy phù hợp cho những tình huống hoặc mục đích cụ thể, tương tự như bộ kiểm thử (test suite) Một MP kịch bản định nghĩa và có khả năng thực hiện tất cả các đường chạy trong kịch bản đó Thông thường, một MP kịch bản chỉ bao gồm một bộ sưu tầm nhỏ các đường chạy, đôi khi chỉ có một đường MP thường mô hình hóa một tập con hoặc một lát (slice) tính năng của Impl, đại diện cho Impl ở mức độ trừu tượng với nhiều chi tiết bị bỏ qua hoặc đơn giản hóa.
3.2.1.3 Cấu trúc chương trình mô hình hợp đồng C#
Cấu trúc của một MP yêu cầu phải có các câu lệnh using để truy cập không gian tên từ thư viện NModel Tất cả các không gian tên này được cung cấp bởi thư viện NModel.dll Cuối cùng, một MP sẽ được biên dịch thành một thư viện.
Csc /t: library / r: “%DEVPATH% \NModel.dll” [Ten MP].cs
Trong đó DEVPATH là một biến môi trường mà lưu trữ đường dẫn tới thư mục chứa thƣ viện, VD: C: \Program Files\NModel\bin
Mỗi MP được mã hóa theo không gian tên riêng, bao gồm các hành động và biến đã được định nghĩa bởi các kiểu khai báo trong không gian tên đó Tên của không gian tên chính là tên của MP, và một MP có thể chứa nhiều lớp hoặc các kiểu khác nhau Cú pháp sử dụng là: using NModel; using NModel.Attributes; using NModel.Execution; namespace [tên MP].
{ Định nghĩa các biến Khai báo biến trạng thái
Trạng thái dữ liệu Các điều kiện cho kiểm thử (thường là điều kiện trạng thái chấp nhận) Chi tiết các hành động
Phương thức factory (là phương thức tạo đối tượng chương trình mô hình)
Các bước xây dựng một MP hợp đồng: Để xây dựng một MP thì chúng ta phải thực hiện qua các bước sau:
Bước 1: Phân tích sơ bộ để quyết định mục đích của MP
Bước 2: Chọn hành động, tính năng cần mô hình
Bước 3: Chọn các biến trạng thái
Bước 4: Lập trình MP theo cấu trúc
3.2.2 Thăm dò và phân tích chương trình mô hình hữu hạn 3.2.2.1 Máy trạng thái hữu hạn (FSM-Finite State Machines)
FSM, hay máy trạng thái hữu hạn, được định nghĩa là một tập hợp hữu hạn các phép chuyển trạng thái Các thành phần chính của FSM bao gồm trạng thái khởi tạo, danh sách các trạng thái chấp nhận và danh sách các phép chuyển trạng thái Mỗi phép chuyển trạng thái được cấu thành từ ba phần: trạng thái hiện tại, hành động (nhãn chuyển tiếp) và trạng thái tiếp theo.
Các đường chạy và các kịch bản (Runs and scenarios)
Mỗi FSM mô tả tất cả các đường chạy khả thi thông qua các nút và liên kết trong đồ thị của nó Thuật toán bắt đầu từ trạng thái khởi tạo, sau đó chọn bất kỳ trạng thái nào có chuyển tiếp đến các trạng thái tiếp theo Đường chạy sẽ kết thúc khi đạt đến trạng thái không còn chuyển tiếp hoặc khi đạt đến trạng thái chấp nhận đã được chỉ định.
Kịch bản là một tập hợp các đường chạy liên quan, được định nghĩa là toàn bộ bộ sưu tập các đường chạy có thể được sinh ra từ một FSM.
FSMs kịch bản và FSM đúng (the true FSM)
FSM kịch bản, theo tài liệu [4], được định nghĩa là một FSM nhằm mục đích xác định một kịch bản cụ thể Nó có khả năng định nghĩa nhiều FSMs kịch bản khác nhau cho bất kỳ MP nào, với mỗi FSM kịch bản tương ứng với một bộ sưu tập các đường chạy khác nhau Một FSM có thể tạo ra tất cả các đường chạy của một MP được coi là FSM đúng của nó Khi MP có số lượng trạng thái và hành động nhỏ, việc viết ra FSM đúng của nó trở nên khả thi.
Việc thăm dò tự động tạo ra một FSM từ chương trình mô hình, cho phép trực quan hóa, phân tích và tạo test ngoại tuyến Phần này sẽ giải thích cách thăm dò một MP bằng cách sử dụng thư viện và các công cụ liên quan.
Việc truy cập chương trình mô hình:
First, consider an example of the method and factory class for an MP NewsReader, as follows: public static class Factory { public static ModelProgram Create() { return new LibraryModelProgram(typeof(Factory).Assembly,
Để tương tác với thư viện hoặc các công cụ liên quan như mpv, otg, hoặc ct, một MP cần cung cấp một phương thức factory để tạo ra một đối tượng.
LibraryModelProgram từ chương trình mô hình được biên dịch Tất cả các công cụ truy cập MP gián tiếp bằng cách gọi các phương thức của đối tượng này
Phương thức factory nên được đặt trong một lớp factory riêng biệt, với cấu trúc đồng nhất nhưng có thể thay đổi một số định danh cho từng MP cụ thể Lớp factory cần được khai báo là public static, trong khi các lớp chứa biến trạng thái và phương thức hành động của MP không cần phải công khai, mà mặc định có quyền truy cập private Tên của lớp factory thường được đặt là Factory và phương thức factory được đặt theo quy ước phù hợp.
XÂY DỰNG DEMO VÀ KIỂM THỬ HỆ THỐNG VỚI NMODEL
Cài đặt NModel
Để cài đặt NModel, máy tính phải có NET và không cần thiết phải có Visual Studio
Phiên bản NET có thể hoạt động với Framework NET 3.5, và nếu có sẵn phiên bản 2 hoặc 3, cũng có thể sử dụng được Để cài đặt, hãy làm theo các bước hướng dẫn sau.
Bước 1 : Download Nmodel.msi Mở và cài đặt (chọn Typical Install)
Việc thực thi file msi để cài đặt thư viện Nmodel cùng với bốn chương trình mpv, mp2dot, otg và ct, cũng như trợ giúp trực tuyến, là tất cả những gì cần thiết để chạy chương trình và tạo ra các mô hình riêng của bạn.
Để chạy mpv, bạn cần cài đặt công cụ bố cục đồ họa GLEE, lưu ý rằng GLEE có giấy phép bản quyền ít hơn NModel Sau khi cài đặt NModel và GLEE, hãy sao chép các tệp DLL của GLEE vào thư mục bin của NModel Nếu cài đặt ở vị trí mặc định, bạn có thể thực hiện điều này theo đường dẫn đã chỉ định.
Cd C: \Program Files\Microsoft Research\GLEE\bin Copy *.dll…\ \ \Nmodel\bin
Ngoài mpv, bạn cũng có thể sử dụng mp2dot (Model Program to Dot) Chương trình mp2dot không cần GLEE và được phát hành dưới giấy phép bản quyền của NModel, mang lại sự thuận tiện hơn cho người dùng.
Bước 3: Sau khi cài đặt xong phải thiết lập biến môi trường bằng cách:
To configure the environment variables on your computer, right-click on the Computer icon and select Remote Settings Next, navigate to Advanced and click on Environment Variables Locate the Path variable, copy the following paths: C:\Windows\Microsoft.NET\Framework\v3.5 and C:\Program Files\NModel\bin from your C drive, and paste them into the Variable value field before clicking OK.
Cách sử dụng các công cụ mpv, otg, ct
Công cụ MPV được thiết kế để hình dung và phân tích hành vi của các chương trình, tạo ra máy trạng thái hữu hạn (FSM) từ một MP Nó hiển thị đồ thị của FSM và khảo sát các thành phần của tất cả các chương trình mô hình được chỉ định trên dòng lệnh, bao gồm MP C# và FSM MPV cung cấp nhiều tùy chọn để điều chỉnh đồ thị hiển thị, lưu trữ và khôi phục kết quả thăm dò Ngoài ra, nó cũng hỗ trợ kiểm tra các trạng thái của chương trình và khám phá các chương trình tương tác một cách chi tiết, cho phép người dùng làm việc chuyển tiếp từ những trạng thái quan tâm.
Thông qua việc tìm kiếm FSM, mpv có khả năng thực hiện phân tích an toàn nhằm xác định xem hệ thống có đạt các trạng thái bị cấm hay không, đồng thời tiến hành phân tích tính hoạt động để phát hiện các trạng thái chết.
Công cụ mpv đòi hỏi phần mềm GLEE phải đƣợc cài đặt Các công cụ còn lại không yêu cầu GLEE
Cách sử dụng (Usage) mpv: mpv [/reference:]*[/mp:]* /initialTransitions:]* [/transitionLabels:{None|ActionSymbol|Action}]*
[/stateShape:{Box|Circle|Diamond|Ellipse|Octagon|Plaintext}]*
[/direction:{TopToBottom|LeftToRight|RightToLeft|BottomToTop}]*
[/testSuite:]* [/fsm:]* [/startTestAction:]* [/group:]*
The command examples for using MPV include various arguments such as loading specific files and modules For instance, you can run MPV with the command `mpv @mpv args.txt` or specify multiple files like `mpv /fsm:M1.txt /fsm:M2.txt` Additionally, you can execute tests with `mpv /testSuite:ContractTest.txt` and load resources using `mpv /r:NewsReaderUI.dll NewsReader.Factory.Create` Other examples include invoking the NewsReader with `mpv /r:NewsReaderUI.dll /mp:NewsReader` and utilizing the Controller with safety checks using `mpv /r:Controller.dll Reactive.Factory.Create /safetyCheckIsOn+` Each command demonstrates how to effectively utilize MPV with different parameters and modules.
Công cụ otg
The OTG tool generates an offline test suite that achieves link coverage of a finite state machine (FSM) derived from a model program (MP) This test suite can subsequently be executed by the Conformance Tester (CT) tool.
Cách sử dụng otg: otg [/reference:]* [/mp:]* [/file:]* [/append[+|-]]* [/fsm:]* * @
The commands provided illustrate various usages of the "otg" tool, demonstrating how to run tests with specific parameters For example, using "otg @otg args.txt" initializes the process with arguments from a text file, while "otg /r:ClientServer.dll ClientServer.Factory.Create /fsm:Scenario.txt" executes a test scenario by referencing a specific DLL and factory method Additionally, "otg /r:ClientServer.dll /mp:ClientServer /fsm:Scenario.txt" runs a multi-process test with the same DLL, and "otg /r:ClientServer.dll ClientServer.Factory.Create /file:ContractTest.txt" specifies an output file for the test results The command "otg /r:ClientServer.dll /mp:ClientServer /file:ContractTest.txt" further emphasizes the integration of DLL references and output specifications in testing workflows.
4.1.2.3 Công cụ ct Để thực hiện các test bằng cách sử dụng test runner ct, một bản khai thác kiểm thử phải đƣợc viết bằng C# để kết nối thực hiện đến ct Một bộ kiểm thử đƣợc tạo ra từ một MP bởi công cụ otg, hoặc ct có thể tạo ra các ca kiểm thử trực tiếp từ một MP khi test run thực thi, và một chiến lƣợc tùy chỉnh có thể đƣợc viết bằng C# mà ct sử dụng để tối đa hóa độ bao phủ theo tiêu chí đƣợc xác định ct /iut: [/modelStepper:] /reference:+
[/coverage:]* [/steps:]* [/maxSteps:]*
[/timeout:]* [/continueOnFailure[+|-]]* [/logfile:]* [/randomSeed:]* [/overwriteLog[+|-]]* [/testSuite:]* [/fsm:]* [/startTestAction:]* * @
The command examples illustrate how to execute tests using specific DLL files and input parameters For instance, the command `ct @ct args.txt` initializes the test with arguments from a text file The command `ct /r:Stepper.dll /iut:ClientServerImpl.Stepper.Create /testSuite:ContractTest.txt` runs tests on the Stepper DLL while referencing a specific implementation and test suite Additionally, the command `ct /r:ClientServer.dll ClientServer.Factory.Create /r:Stepper.dll /iut:ClientServerImpl.Stepper.Create /fsm:Scenario.txt /runs:1` executes a single run of tests on both the ClientServer and Stepper DLLs, utilizing a defined scenario Overall, these commands are essential for structuring and running automated tests in a software development environment.
Xây dựng và thực nghiệm với demo hệ thống client/server
Trong luận văn này, tôi nghiên cứu bài toán hệ thống nhúng với NModel là thiết bị điều khiển từ xa trong cấu trúc client/server, được tham khảo từ tài liệu [4] Mục tiêu là phát triển một hệ thống thiết bị phòng thí nghiệm gồm cảm biến nhiệt độ kết nối với máy tính nhúng, mạng và máy tính lưu trữ, phân tích dữ liệu (hình 4.1) Trên máy tính nhúng (Server) cài đặt chương trình giám sát nhiệt độ, trong khi máy tính khác (Client) cài đặt chương trình khai thác dữ liệu Hai chương trình giao tiếp qua mạng bằng giao thức TCP/IP (hình 4.2), cho phép client kết nối đến server ở xa như nhà máy hoặc trạm thời tiết qua internet.
Hình 4.1 Thiết bị điều khiển từ xa – Hệ thống Client/Server
Trước khi kiểm thử và phân tích ứng dụng demo được mô tả, tôi sẽ giải thích một số vấn đề về cách mà chương trình làm việc
Hai chương trình thực hiện theo cùng một giao thức, tức là một thỏa thuận về cách thức hợp tác Giao thức này được xác định bởi các quy tắc hình thành thông điệp và các quy tắc quy định thứ tự của các thông điệp Trong phần demo này, chúng ta sẽ khám phá cách thức hoạt động của giao thức này.
Trong giao thức này, máy chủ khởi động trước và chờ kết nối từ máy khách Khi máy khách kết nối, nó gửi yêu cầu đo nhiệt độ, và máy chủ sẽ phản hồi bằng cách cung cấp nhiệt độ hiện tại Sau đó, máy khách có thể gửi thêm lệnh hoặc đóng kết nối Nếu máy khách chọn đóng, máy chủ có thể chờ kết nối từ máy khách khác hoặc tự thoát Lưu ý rằng máy chủ chỉ có thể xử lý một kết nối máy khách tại một thời điểm.
Hình 4.2: Giao thức client/server
Giao thức của demo được thực hiện thông qua các socket, sử dụng giao diện lập trình ứng dụng API cho giao tiếp qua mạng TCP/IP Socket API là một kỹ thuật cơ bản của Internet, quen thuộc với nhiều nhà phát triển Khung làm việc Net cung cấp một phiên bản thực hiện của API này trong lớp Socket thuộc không gian tên.
Để thiết lập một kết nối, cần thực hiện nhiều bước trong socket API Đầu tiên, Server tạo một socket nghe và liên kết nó với địa chỉ IP và số cổng thông qua phương thức Bind Sau đó, phương thức Listen được sử dụng để chuẩn bị cho việc kết nối Cuối cùng, phương thức Accept thực hiện kết nối và tạo một socket kết nối để sử dụng.
Trong Client, Socket tạo cổng và Connect thực hiện kết nối Khi kết nối thành công, cả hai bên sử dụng Send và Receive để trao đổi thông điệp, với client gửi trước Để kết thúc kết nối, cả hai bên gọi Close, trong đó client đóng trước, sau đó server gọi Close trên socket nghe của nó.
Chương trình “Monitor” và “Logger” sử dụng các thư viện thay vì gọi trực tiếp API socket Net, thông qua các lớp Client và Server được xây dựng làm hàm bao cho các socket Các lớp này cung cấp một API đơn giản hơn, chuyên ngành cho ứng dụng điều khiển từ xa Mỗi phương thức hàm bao như Socket và Bind gọi các phương thức tương ứng trong socket Net với ít tham số hơn, thuận tiện hơn Chẳng hạn, các phương thức Receive của client và Send của Server xử lý số dấu chấm phẩy động (mẫu nhiệt độ) thay vì mảng byte.
4.2.2 Kiểm thử demo bằng NModel 4.2.2.1 Kiểm thử ngoại tuyến (Offline)
Quy trình kiểm thử chương trình bằng NModel bao gồm các bước chính: xây dựng implementation, viết MP, sử dụng mpv để hình dung và phân tích, áp dụng otg để tạo bộ kiểm thử tự động, và cuối cùng, sử dụng công cụ ct để thực hiện bộ kiểm thử.
The first step involves creating two input models from the established client/server implementation: the ClientServer contract model (M1) and the scenario model (M2).
M1 nhằm mục đích biểu diễn hệ thống phân tán với các chương trình hoạt động trên hai máy tính kết nối mạng Client và Server thực hiện trong một chủ đề duy nhất, kết hợp các cuộc gọi phương thức theo thứ tự phù hợp với giao thức Hệ thống cũng tự động sinh ra và kiểm chứng các test run.
Các hành động giữa client và server là riêng biệt, với quá trình gửi và nhận của client khác với server Các hành động chính bao gồm: ClientSend, ServerSend, ClientReceive và ServerReceive.
Trong ví dụ này, có hai loại ràng buộc theo trình tự: Socket cần được tạo (Created), kết nối (Connected) và đóng theo giao thức Các hành động gửi và nhận phải thay thế lẫn nhau, bắt đầu với hành động gửi Do đó, có ba biến trạng thái cho điều khiển: ClientSocket, ServerSocket và Phase.
Trạng thái dữ liệu: là nhiệt độ được lưu trữ trong bộ đệm nhận dữ liệu của client clientBuffer
Giá trị mong đợi trả về đã được tính toán trước, với hai giới hạn nhiệt độ là 99.9 và 100.0 Mã nguồn được phát triển bằng ngôn ngữ C# theo cấu trúc MP, thông tin chi tiết có thể tham khảo trong phần phụ lục.
MP kịch bản M2: được biểu diễn bởi máy trạng thái hữu hạn, M2 được lưu trữ trong file scenario.txt:
Transitions( t(0,ServerSocket(),1), t(1,ServerBind(),2), t(2,ServerListen(),3), t(3,ClientSocket(),4), t(4,ClientConnect(),5), t(5,ServerAccept(),6), t(6,ClientClose(),7), t(7,ServerCloseConnection(),8), t(8,ServerClose(),9)))
Bước thứ hai, sau khi đã có các MP đầu vào thì tiến hành phân tích chúng bằng công cụ mpv theo trình tự sau:
Khởi động chương trình cmd.exe
Gõ lệnh >build.bat để xây dựng các chương trình thư viện
Gõ lệnh >mpv @mpv_contract.txt để hiển thị FSM đúng của MP Khi đó đƣợc kết quả nhƣ hình 4.3:
Hình 4.3: FSM đúng của MP hợp đồng
Hình 4.3 thể hiện tất cả các trạng thái và đường chạy (runs) của MP, trong đó các trạng thái kết thúc (trạng thái chấp nhận) được đánh dấu bằng đường viền đậm.
Để hiển thị FSM của MP kịch bản, bạn hãy gõ lệnh >mpv @mpv_scenario.txt Kết quả sẽ cho thấy FSM chỉ có một đường chạy duy nhất, như được minh họa trong hình 4.4.
Hình 4.4: FSM của MP kịch bản