Báo cáo hệ điều hành thời gian thực

Báo cáo nhóm môn học Hệ điều hành thời gian thực - chương trình đào tạo bậc đại học - ngành công nghệ thông tin

GVHD: NGUYỄN VĂN THỌ SVTH: NGUYỄN MINH QUỲNH

PHẠM VĂN ĐỨC

BÁO CÁO NHÓM

TRƯỜNG ĐẠI HỌC DUY TÂN

KHOA ĐIỆN TỬ VIỄN THÔNG

LỖI, LỖ HỎNG, NHIỄU

NỘI DUNG

Vai trò c a vi c ki m th ủa việc kiểm thử ệc kiểm thử ểm thử ử

K thu t ki m tra ỹ thuật kiểm tra ật kiểm tra ểm thử

i m

ảo kế hoạch thử nghiệm ế hoạch thử nghiệm ạch thử nghiệm ử ệc kiểm thử

Ki m th c p h th ng ểm thử ử ấp hệ thống ệc kiểm thử ống

8.2 Khái ni m l i, l h ng và nhi u ệc kiểm thử ỗi, lỗ hỏng và nhiễu ỗi, lỗ hỏng và nhiễu ỏng và nhiễu ễu

 Lỗi thâm nhập vào chương trình không cần thông qua một thao tác nào cả, là “error” hoặc “defect” (“lỗi” hoặc “khuyết điểm”) gọi là “Bug” (“nhiễu”)

 Sự biểu thị của một khuyết điểm diễn ra trong quá trình hoạt động của hệ thống phần mềm được gọi là một “faults” (“lỗi”)

 Một lỗi nào đó làm cho hệ thống phần mềm không chạy được một yêu cầu nào đó của hệ thống thì gọi là một “failure” (“lỗ hỏng ”)

8.2.1 Vai trò c a vi c ki m th ủa việc kiểm thử ệc kiểm thử ểm thử ử

 Đưa ra các lỗi của chương trình: Ví dụ: Từ 1985 đến 1987, sai sót của phần mềm trong một hệ thống chiếu xạ Therac-25 Do thiếu viêc kiểm thử, dẫn đến việc tử vong của một số bệnh nhân bị ung thư do tần số bức xạ vượt quá giới hạn

 Tăng tính tin cậy của hệ thống: ta không thể kiểm soát tất cả các lỗi trong hệ thống, thay vào đó cần đảm bảo độ tin cậy của hệ thống để có thể đảm bảo các yêu cầu đặt ra

8.2.2 K thu t ki m tra ỹ thuật kiểm tra ật kiểm tra ểm thử

 Có một phạm vị rộng cho các kỹ thuật kiểm tra cho các cấp đơn vị và hệ thống kiểm nghiệm, kiểm tra dữ liệu, và kiểm tra tích hợp

 Một số kỹ thuật thường được hoán đổi cho nhau, trong khi một số khác thì không

 Bất kỳ một kỹ thuật nào trong số những kỹ thuật này cũng có thể là thử nghiệm không hoàn chỉnh hoặc không khả thi trong tính toán cho các

hệ thống thời gian thực Do đó, Kết hợp của các

kỹ thuật kiểm tra là gần như luôn luôn là việc cần làm

Ki m th c p đ n v ểm thử ử ấp hệ thống ơn vị ị

 Một số phương pháp kiểm tra có thể được sử dụng để kiểm tra độc lập các modules hoặc là các đơn vị Những kỹ thuật này có thể được sử dụng cho các kỹ thuật viên kiểm tra độc lập để thử

nghiệm cho mỗi đơn vị trong hệ thống

 Những kỹ thuật này cũng có thể được áp dụng cho các hệ thống con (hoặc các module liên quan đến các chức năng tương tự)

Ki m th c p đ n v - Ki m th h p đen ểm thử ử ấp hệ thống ơn vị ị ểm thử ử ộp đen

 Chỉ có đầu vào và đầu ra của đơn vị được xem xét

 Việc kiểm tra độc lập được thực hiện cho một module, có thể được áp dụng cho một số lượng lớn các module với các chức năng tương tự

 Mốt số sử dụng rỗng rãi của kỹ thuật kiểm tra hộp đen bao gồm:

◦ Thử nghiệm toàn diện

◦ Thử nghiệm giới hạn

◦ Thử nghiệm ngẫu nhiên

◦ Thử nghiệm các trường hợp xấu nhất

Ki m th h p đen – Th nghi m toàn di n ểm thử ử ộp đen ử ệc kiểm thử ệc kiểm thử

 Brute-force hoặc thử nghiệm toàn diện liên

quan đến việc trình bày đoạn mã code với mỗi sự kết hợp đầu vào có thể Thử nghiệm Brute-force

có thể làm việc tốt trong trường hợp có một số ít các đầu vào, mỗi lần với một loạt các đầu vào

hạn chế

 Tuy nhiên, một vấn đề lớn với thử nghiệm

Brute-force là sự bùng nổ tổ hợp trong một số

trường hợp thử nghiệm Ví dụ, đối với các mã xử

lý tốc độ dữ liệu 3*216, các trường hợp kiểm tra sẽ được yeu cầu dừng lại

Ki m th h p đen – Th nghi m gi i h n ểm thử ử ộp đen ử ệc kiểm thử ới hạn ạch thử nghiệm

 Giá trị ranh giới thử nghiệm hoặc kiểm tra góc hợp để giải quyết vấn đề của sự bùng nổ tổ hợp gây ra bởi tập hợp một vài thử nghiệm rất nhỏ

của việc kết hợp các đầu vào được hiểu như

“ranh giới” của đầu vào Ví dụ: 5 đầu vào 16bit ta

có 216 *216* 216* 216* 216 = 280 trường hợp

 Việc kiểm tra đầu vào được giới hạn cho mỗi

sự kết hợp của giá trị max, min, và các giá trị

trung bình mỗi đầu vào, sau đó tập thử nghiệm sẽ bao gồm 35= 243 trường hợp thử nghiệm nên

được xử lý dễ dàng hơn

Ki m th h p đen – Th nghi m ng u nhiên ểm thử ử ộp đen ử ệc kiểm thử ẫu nhiên

 Liên quan đến các kiểu thử nghiệm đoạn code đơn vị trong trường hợp thử ngẫu nhiên trong một khoảng thời gian Việc kiểm tra độc lập được thực hiện cho một module, có thể được áp dụng cho một số lượng lớn các module với các chức năng tương tự

 Các trường hợp thử ngẫu nhiên được tạo ra

dựa trên việc xác định các số liệu thống kê cơ

bản của các đầu vào dự kiến

 Hạn chế lớn của kỹ thuật này là các chức năng

phân loại xác suất cơ bản cho các biến đầu vào

có thể không có sẵn hoặc không chính xác, và có khả năng bỏ lỡ các với xác suất xảy ra thấp

Ki m th h p đen – Th nghi m tr ểm thử ử ộp đen ử ệc kiểm thử ường hợp xấu nhất ng h p x u nh t ợp xấu nhất ấp hệ thống ấp hệ thống

 Kiểm tra các kịch bản có thể được xem là rất hiếm và khó xảy ra:Thường thì những trường hợp

đó là những trường hợp đặc biệt và được biết

chính xác như những đoạn mã có khả năng được thiết kế kém và do đó dễ thất bại

 Ví dụ, trong các phép đo quán tính hệ thống, trong khi nó được mong đợi là sẽ không xảy ra thì

hệ thống sẽ hoạt động với gia tốc tối đa, có thể

biểu diễn với 16bit ký tự, trường hơp xấu nhất

này vẫn cần được thử nghiệm

Ki m th h p tr ng ểm thử ử ộp đen ắng

 Được điều khiển logic:được thiết kế để thực hành trên tất cả các đường dẫn trong code đơn vị

 Có thể phát hiện ra những đường dẫn không hoạt động

 Thử nghiệm với:

◦ Phương pháp chính thức trong thử nghiệm.

◦ Thử nghiệm phần mềm hướng đối tượng

◦ Thử nghiệm mã đầu tiên

Xác đ nh gi i h n v s tr ị ới hạn ạch thử nghiệm ề số trường hợp kiểm thử ống ường hợp xấu nhất ng h p ki m th ợp xấu nhất ểm thử ử

 McCabe đã phát triển một quy trình thuật toán (gọi là phương pháp cơ bản) để xác định một tập hợp các đường cơ sở

 ( Tham khảo giáo trình )

Quá trình g l i “Debugging” ỡ lỗi “Debugging” ỗi, lỗ hỏng và nhiễu

 Việc tách các điều kiện có ảnh hưởng đến sự tính toán về mặt thời gian và có thể được đưa vào các vấn đề khó ước tính về thời gian.

 Một số mẹo để gỡ lỗi “Debugging”:

- Giữ tài liệu về các chương trình một cách cẩn thẩn.

- Gỡ lỗi biểu tượng có sẵn các bước sử dụng: phác

họa, điểm dừng, bỏ qua, để cô lập các lỗi logic.

- Sử dụng kiểm thử tự động nếu có thể.

- Môi trường của những dòng lệnh (như Unix / Linux):

sử dụng in khai báo đầu ra là kết quả trung gian tại các trạm kiểm soát trong các code.

- Chú thích trong các phần của code có lỗi cho đến khi chương trình biên dịch và chạy

8.2.3 Ki m th c p h th ng ểm thử ử ấp hệ thống ệc kiểm thử ống

 Một khi các module độc lập đã được kiểm thử thì sau đó hệ thống con hoặc toàn bộ hệ thống cần phải được kiểm thử Trong các hệ thống lớn hơn, quá trình này có thể được chia thành một loạt các kiểm thử hệ thống con, và sau đó mới là kiểm thử tổng thể hệ thống.

 Việc kiểm thử cấp hệ thống luôn luôn xảy ra các module thành phần của nó đã vượt qua các bài kiểm thử

 Nếu có lỗi xảy ra trong kiểm thử cấp hệ thống, các lỗi phải được sửa chữa, sau đó mỗi trường hợp kiểm thử liên quan đến các module thay đổi phải được chạy lại và tất cả hệ thống các cấp kiểm thử trước đây phải được thông qua trong bài kiểm thử tiếp theo

Th nghi m phòng s ch “ cleaning test” ử ệc kiểm thử ạch thử nghiệm

 Trong phương pháp này, nhóm phát triển là không được phép kiểm thử code như nó đang được phát triển Thay vào đó, người ta kiểm thử

cú pháp, code walkthrough , kiểm tra nhóm, và xác minh chính xác những gì được sử dụng để đảm bảo tính toàn vẹn code

 Người ta sử dụng kỹ thuật này giống như một làn da hình hành, lớp chức năng mới được thêm vào hệ thống phần mềm cho đến khi nó đã hoàn toàn đáp ứng yêu cầu

Th nghi m s căng th ng (“stress”) ử ệc kiểm thử ự căng thẳng (“stress”) ẳng (“stress”)

 Kiểm thử bằng cách nào hệ thống bị lỗi trong trường hợp nó chịu sự xáo trộn của một số lượng lớn các yếu tố đầu vào tiếp theo là rối loạn nhỏ trải rộng trên một khoảng thời gian dài.

 Kiểm thử này cũng có thể sử dụng trong các trường hợp và điều kiện mà hệ thống phải tải nặng

Th nghi m vi c th c hi n 1ph n c a h th ng ử ệc kiểm thử ệc kiểm thử ự căng thẳng (“stress”) ệc kiểm thử ần của hệ thống ủa việc kiểm thử ệc kiểm thử ống

 Thách thức để có thể phân chia các chức năng cho các phần của hệ thống trong việc thử nghiệm

hệ thống thời gian thực

 Nhiều vấn đề phát sinh tương tự cũng được

tìm thấy trong mối liên quan của các nguyên

mẫu phần cứng

 Có rất nhiều chiến lược đơn giản liên quan

đến việc tạo ra và các trình điều khiển khai để đối phó với các phần thiếu ở giao diện Thử nghiệm

mã nguồn mở về thương mại và các máy móc có thể hữu ích trong những trường hợp này

8.2.4 Phác th o k ho ch ki m th ảo kế hoạch thử nghiệm ế hoạch thử nghiệm ạch thử nghiệm ểm thử ử

 Kế hoạch của việc thử nghiệm phải thực hiện theo các khoản mục của tài liệu yêu cầu, việc cung cấp các tiêu chuẩn để sử dụng cho việc đánh giá các yêu tố yêu cầu đã được đáp ứng

 Một tập hợp các trường hợp thử nghiệm được chuyển thành bằng văn bản sau đó sẽ được sử dụng để đo các chỉ tiêu đề ra trong kế hoạch kiểm thử

 Kế hoạch thử nghiệm bao gồm các tiêu chí để thử nghiệm các phần mềm trên modules theo cấp

độ module hay units (đơn vị) trên một hệ thống hoặc cấp hệ thống con, cả hai nên được kết hợp trong một chương trình thử nghiệm tốt