Chẩn đoán an toàn phần mềm — Chẩn đoán tính chính xác của hoạt động chức năng
1. Tổng quan
A. Khái niệm
Chẩn đoán an toàn phần mềm là hoạt động, theo «Hướng dẫn chẩn đoán an toàn phần mềm» (của Hàn Quốc), chẩn đoán một cách có hệ thống xem SW có hoạt động an toàn trong cả tình huống dự kiến lẫn tình huống bất thường hay không. Trong đó, chẩn đoán tính chính xác của hoạt động chức năng là hạng mục cốt lõi kiểm chứng xem SW có thực hiện chính xác các chức năng được yêu cầu hay không, và có xử lý an toàn mà không có hành vi ngoài ý muốn ngay cả trong tình huống ngoại lệ và biên hay không.
Lý do chẩn đoán tính chính xác của hoạt động chức năng quan trọng nằm ở chỗ "SW tham gia sâu vào công nghiệp và an toàn, và hoạt động sai trực tiếp dẫn đến tai nạn vật lý". Khi phần mềm được sử dụng rộng rãi trong các lĩnh vực an toàn trọng yếu (safety-critical) như ô tô, y tế, phát điện, đường sắt, giao thông, việc xác nhận SW hoạt động chính xác và an toàn không chỉ trong tình huống bình thường mà cả với đầu vào ngoại lệ, bất thường đã trở thành bắt buộc. Nếu chức năng không được thực hiện chính xác như yêu cầu (hoạt động sai, hành vi ngoài ý muốn, không phản hồi), hậu quả không dừng ở lỗi hiển thị mà có thể dẫn thẳng đến thiệt hại về người và tài sản như phanh thất bại, sai liều thuốc, thiết bị chạy mất kiểm soát.
Ở đây cần hiểu rằng "tính chính xác của hoạt động chức năng" chứa đựng đồng thời yêu cầu theo hai hướng. Một là chức năng dự định có được thực hiện đúng như yêu cầu không (should-do, tính chính xác của chức năng bình thường), hai là có phát sinh hành vi ngoài ý muốn hay không (should-not-do, bảo đảm thuộc tính an toàn). Từ góc độ an toàn, hướng thứ hai đặc biệt quan trọng. Dù hoạt động tốt với đầu vào bình thường, nếu xuất hiện hành vi nguy hiểm bất ngờ với đầu vào bất thường, điều kiện biên hay tình huống hỏng hóc thì an toàn sẽ sụp đổ. Vì vậy, chẩn đoán được thiết kế để chủ ý bao gồm không chỉ kịch bản bình thường mà cả tình huống ngoại lệ, biên và lỗi.
Để phòng ngừa điều này, hướng dẫn chẩn đoán an toàn chia tính an toàn của SW thành nhiều hạng mục chẩn đoán để kiểm tra, trong đó tính chính xác của hoạt động chức năng là trục cốt lõi. Chẩn đoán xác nhận theo từng giai đoạn xem yêu cầu có rõ ràng và đầy đủ không, thiết kế có phản ánh chính xác yêu cầu không, cài đặt có hoạt động đúng thiết kế không, và kiểm thử đã kiểm chứng đầy đủ đến cả điều kiện bình thường, bất thường, biên hay chưa. Nói cách khác, xác nhận tính chính xác ở mỗi giai đoạn yêu cầu → thiết kế → cài đặt → kiểm thử để ngăn khiếm khuyết của giai đoạn trước lan sang giai đoạn sau và cuối cùng biến thành tai nạn.
B. Sự cần thiết
Khi SW lan rộng trong toàn xã hội, tác động của hoạt động sai ngày càng lớn, khiến cách tiếp cận hậu kiểm chỉ xác nhận chất lượng ở giai đoạn kiểm thử khó bảo đảm được an toàn. Nếu khiếm khuyết đã hình thành từ giai đoạn yêu cầu hay thiết kế, thì dù phát hiện ở giai đoạn sau, chi phí sửa chữa cũng tăng lên hàng chục lần và nguy cơ bỏ sót cũng cao. Do đó cần cách tiếp cận "an toàn phòng ngừa", chẩn đoán và bảo đảm tính chính xác một cách có hệ thống trong toàn bộ quá trình phát triển.
2. Cấu trúc tổng thể — Tính chính xác của hoạt động chức năng trong các hạng mục chẩn đoán an toàn
Để hiểu vị trí của chẩn đoán tính chính xác của hoạt động chức năng, trước hết cần xem cấu trúc tổng thể: chẩn đoán an toàn là tập hợp của nhiều góc nhìn. Sơ đồ cấu trúc dưới đây cho thấy chẩn đoán an toàn lấy tính chính xác của hoạt động chức năng làm trung tâm, cùng với các góc nhìn lân cận như tính vững chắc, tài nguyên, giao diện tạo thành một hệ thống thống nhất.
flowchart TB
SAFE["Chẩn đoán an toàn SW"] --> FUNC["Tính chính xác của hoạt động chức năng"]
SAFE --> ROB["Tính vững chắc (xử lý ngoại lệ·bất thường)"]
SAFE --> RES["An toàn tài nguyên·hiệu năng"]
SAFE --> IF["An toàn giao diện·liên kết"]
FUNC --> R["Tính chính xác của yêu cầu"]
FUNC --> D["Tính chính xác của thiết kế"]
FUNC --> I["Tính chính xác của cài đặt"]
FUNC --> T["Tính chính xác của kiểm thử·kiểm chứng"]
style FUNC fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
Tính chính xác của hoạt động chức năng là trung tâm của hệ thống này, xem xét "chức năng được yêu cầu có được truyền đạt, cài đặt và kiểm chứng chính xác, không bị méo mó ở mỗi giai đoạn phát triển hay không". Góc nhìn tính vững chắc xử lý việc phòng thủ trước đầu vào sai và tình huống hỏng hóc, an toàn tài nguyên/hiệu năng xử lý việc tuân thủ ngân sách bộ nhớ và thời gian, an toàn giao diện xử lý tính chính xác của liên kết giữa các mô-đun và hệ thống bên ngoài. Các góc nhìn này chồng lấn và bổ trợ nhau. Ví dụ, chức năng có chính xác nhưng không có phòng thủ trước đầu vào ngoại lệ thì an toàn vẫn bị phá vỡ, vì vậy chẩn đoán tính chính xác của hoạt động chức năng tự nhiên được thực hiện gắn với chẩn đoán tính vững chắc.
Cấu trúc như vậy là cần thiết vì an toàn là "sản phẩm của toàn bộ quá trình", không thể chứng minh chỉ bằng một lần kiểm thử. Nếu yêu cầu mơ hồ thì dù kiểm thử nhiều đến đâu, chính tiêu chí phán định thế nào là hành vi đúng cũng bị lung lay. Vì vậy, chẩn đoán không chỉ nhìn vào kết quả kiểm thử mà xem xét đồng thời tính chính xác của các giai đoạn trước và sự kết nối giữa các giai đoạn (khả năng truy vết).
3. Quy trình từng giai đoạn của chẩn đoán tính chính xác của hoạt động chức năng
Sơ đồ quy trình dưới đây thể hiện cách tính chính xác được xác nhận ở mỗi giai đoạn phát triển và nối tiếp sang giai đoạn sau. Điểm cốt lõi là các giai đoạn không được kiểm tra độc lập mà được liên kết trước sau bằng khả năng truy vết (traceability).
flowchart LR
R["Tính chính xác của yêu cầu<br/>(đầy đủ·nhất quán·rõ ràng)"] --> D["Tính chính xác của thiết kế<br/>(phản ánh yêu cầu·truy vết)"]
D --> I["Tính chính xác của cài đặt<br/>(tuân thủ thiết kế·tiêu chuẩn)"]
I --> T["Tính chính xác của kiểm thử·kiểm chứng<br/>(bình thường·bất thường·biên)"]
T -. Phản hồi khiếm khuyết .-> R
style T fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
Giai đoạn tính chính xác của yêu cầu là điểm xuất phát của mọi tính chính xác. Nếu yêu cầu không đầy đủ (bỏ sót), không nhất quán (mâu thuẫn) hoặc mơ hồ, thì mọi thiết kế, cài đặt, kiểm thử xây dựng trên đó đều lung lay. Ở giai đoạn này cần rà soát xem các yêu cầu an toàn đã được xác định đầy đủ chưa, mỗi yêu cầu có được mô tả ở dạng có thể kiểm chứng không, và có các yêu cầu xung đột nhau không. Ví dụ, yêu cầu "trong tình huống nguy hiểm, hệ thống chuyển sang trạng thái an toàn" chỉ trở thành tiêu chí chẩn đoán khi đã làm rõ tình huống nào là nguy hiểm, trạng thái an toàn là gì và ràng buộc thời gian chuyển đổi là bao nhiêu.
Giai đoạn tính chính xác của thiết kế xem xét yêu cầu có được phản ánh chính xác vào thiết kế không, thiết kế có vượt quá hay bỏ sót yêu cầu không. Ở đây, ma trận truy vết là công cụ cốt lõi. Ánh xạ hai chiều mỗi yêu cầu được hiện thực bằng phần tử thiết kế nào và ngược lại mỗi phần tử thiết kế bắt nguồn từ yêu cầu nào, để tìm ra thiết kế không có căn cứ (chức năng không có yêu cầu) hoặc yêu cầu chưa được hiện thực (yêu cầu không có thiết kế). Việc yêu cầu an toàn được hiện thực bằng kiến trúc cụ thể nào (dự phòng, giám sát, trạng thái an toàn) cũng được xác nhận ở giai đoạn này.
Giai đoạn tính chính xác của cài đặt kiểm tra mã có được cài đặt đúng thiết kế không và có tuân thủ quy tắc lập trình không. Phân tích tĩnh tự động phát hiện vi phạm tiêu chuẩn và khiếm khuyết tiềm ẩn (tham chiếu null, vượt biên, chưa khởi tạo, mã chết), còn review mã xác nhận sự phù hợp với ý đồ thiết kế. Với mã an toàn trọng yếu, áp dụng kèm tiêu chuẩn lập trình hạn chế các tính năng ngôn ngữ nguy hiểm (ví dụ: MISRA C) để chặn tận gốc hành vi không xác định hoặc cấu trúc mơ hồ.
Giai đoạn tính chính xác của kiểm thử/kiểm chứng xác nhận hành vi bằng thực thi thực tế. Khi đó nhất thiết phải bao gồm không chỉ đầu vào bình thường mà cả đầu vào bất thường, giá trị biên, tình huống lỗi. Dùng phân tích giá trị biên và phân hoạch tương đương để chia không gian đầu vào một cách có hệ thống, dùng tiêm lỗi (fault injection) để kích hoạt các đường ngoại lệ, và dùng độ bao phủ (câu lệnh, nhánh, MC/DC) để định lượng mức đầy đủ của kiểm chứng. Các khiếm khuyết phát hiện trong kết quả kiểm thử được phản hồi, truy ngược lên đến khiếm khuyết của yêu cầu và thiết kế để khắc phục.
| Giai đoạn | Hoạt động chính | Sản phẩm, căn cứ |
|---|---|---|
| Tính chính xác của yêu cầu | Kiểm tra tính đầy đủ, nhất quán, mơ hồ; xác định yêu cầu an toàn | Kết quả rà soát yêu cầu, danh sách yêu cầu an toàn |
| Tính chính xác của thiết kế | Xác nhận phản ánh yêu cầu vào thiết kế và khả năng truy vết | Ma trận truy vết |
| Tính chính xác của cài đặt | Tuân thủ thiết kế, tiêu chuẩn lập trình, phân tích tĩnh | Báo cáo phân tích tĩnh, biên bản review |
| Tính chính xác của kiểm thử/kiểm chứng | Kiểm thử bình thường, bất thường, biên; độ bao phủ | Ca kiểm thử, báo cáo độ bao phủ |
4. Các kỹ thuật chẩn đoán chính — So sánh và hàm ý thực tiễn
Các kỹ thuật chẩn đoán không tự hoàn chỉnh khi đứng riêng mà được kết hợp theo cách bù đắp giới hạn của nhau. Dưới đây so sánh nguyên lý và giới hạn của các kỹ thuật tiêu biểu.
Rà soát yêu cầu (review/inspection) là cách rẻ nhất để bắt khiếm khuyết ở giai đoạn trước khi thực thi. Con người kiểm tra tính đầy đủ, nhất quán và khả năng kiểm chứng của yêu cầu; nếu dùng inspection hình thức (danh sách kiểm tra, phân vai) thì tính tái lập sẽ cao hơn. Tuy nhiên, review phụ thuộc vào phán đoán của con người nên có giới hạn là khi đặc tả quá đồ sộ sẽ xảy ra bỏ sót.
Phân tích tĩnh tự động phát hiện khiếm khuyết và vi phạm tiêu chuẩn mà không cần thực thi mã. Ưu điểm là bắt được sớm và trên diện rộng các khiếm khuyết như tham chiếu null, vượt biên, chưa khởi tạo. Ngược lại, do không thể biết đầy đủ ngữ cảnh thực thi nên phát sinh dương tính giả (false positive), và không bắt được các vấn đề phụ thuộc thời gian hay môi trường khi thực thi thực tế.
Kiểm thử động xác nhận hành vi bằng thực thi thực tế. Tạo và chạy các ca cho điều kiện bình thường, bất thường, biên rồi đo độ bao phủ. Nó có điểm mạnh là quan sát trực tiếp hành vi thực tế, nhưng có giới hạn căn bản là khi không gian đầu vào rộng thì vẫn còn "đường chưa được thực thi". Vì vậy dùng phân tích tĩnh để bổ sung "tính chất của mọi đường", và dùng độ bao phủ để định lượng "đã thực thi được bao nhiêu".
Phân tích truy vết ánh xạ hai chiều yêu cầu – thiết kế – cài đặt – kiểm thử, làm lộ ra yêu cầu nào chưa được kiểm chứng và mã nào không có căn cứ. Đây là công cụ đặc thù của chẩn đoán an toàn, bắt được "sự bỏ sót giữa các giai đoạn" mà từng kỹ thuật riêng lẻ bỏ qua.
Nguyên lý kết hợp các kỹ thuật này là "điểm mù của kỹ thuật này được kỹ thuật khác che phủ". Chỉ khi dùng đồng thời review (con người, ngữ nghĩa) + phân tích tĩnh (tự động, mọi đường) + kiểm thử động (hành vi thực tế) + truy vết (liên kết giai đoạn) thì chẩn đoán tính chính xác mới có hiệu quả thực chất.
Ở đây, chỉ số độ bao phủ được dùng làm thước đo chung để định lượng "đã kiểm chứng đến mức nào". Độ bao phủ câu lệnh là tiêu chuẩn tối thiểu, tiếp đến là độ bao phủ nhánh, điều kiện, và với mã có mức toàn vẹn an toàn cao thì yêu cầu tới MC/DC. Tuy nhiên cần lưu ý rằng độ bao phủ chỉ cho biết "cận dưới của mức đầy đủ" chứ không bảo đảm tính chính xác. Dù độ bao phủ 100%, nếu phán định bằng giá trị kỳ vọng vốn đã sai thì khiếm khuyết vẫn lọt qua. Vì vậy, việc rà soát đồng thời con số độ bao phủ với tính hợp lý của kết quả kỳ vọng (vấn đề oracle) và tính đại diện của kịch bản mới là điều phân định mức trưởng thành của chẩn đoán.
| Kỹ thuật | Điểm mạnh | Giới hạn | Bổ sung |
|---|---|---|---|
| Rà soát yêu cầu | Sớm, chi phí thấp | Phụ thuộc con người, bỏ sót | Danh sách kiểm tra, inspection |
| Phân tích tĩnh | Diện rộng, mọi đường | Dương tính giả, không phản ánh môi trường | Xác nhận bằng kiểm thử động |
| Kiểm thử động | Quan sát hành vi thực tế | Còn đường chưa thực thi | Độ bao phủ, phân tích tĩnh |
| Phân tích truy vết | Phát hiện bỏ sót giữa các giai đoạn | Gánh nặng quản lý | Tự động hóa bằng công cụ |
Phán định kết quả chẩn đoán và vòng lặp làm lại
Chẩn đoán không kết thúc ở việc tìm ra khiếm khuyết. Khiếm khuyết được phát hiện phải được truy ngược đến giai đoạn gốc để khắc phục. Ví dụ, nếu lỗi giá trị biên xuất hiện lặp lại ở giai đoạn kiểm thử, cần phân định nguyên nhân là do sai sót khi cài đặt, do thiết kế bỏ sót xử lý biên, hay do ngay từ đầu yêu cầu đã không quy định hành vi tại biên. Nếu nguyên nhân nằm ở giai đoạn yêu cầu thì chỉ sửa mã vẫn sẽ tái phát. Vì vậy, như đường "phản hồi khiếm khuyết" trong sơ đồ quy trình, kết quả chẩn đoán được xử lý như một vòng kín quay ngược lại đến yêu cầu và thiết kế.
Hiệu quả của vòng lặp làm lại này rốt cuộc phụ thuộc vào chất lượng truy vết. Nếu yêu cầu – thiết kế – cài đặt – kiểm thử được ánh xạ chính xác, có thể nhanh chóng nắm được một khiếm khuyết bắt nguồn từ giai đoạn nào và ảnh hưởng đến những sản phẩm khác nào. Ngược lại, nếu truy vết yếu kém, cùng một khiếm khuyết sẽ sống lại ở nhiều nơi và việc sửa chữa lại gây ra khiếm khuyết mới, rơi vào vòng luẩn quẩn. Đây chính là lý do chẩn đoán an toàn phải là "một hệ thống liên tục" chứ không phải "một lần kiểm thử".
5. Chuyên sâu — Liên kết với tiêu chuẩn an toàn chức năng và áp dụng thực tiễn
Chẩn đoán tính chính xác của hoạt động chức năng có hiệu quả thực chất khi được liên kết với các tiêu chuẩn an toàn chức năng theo từng lĩnh vực. ISO 26262 trong lĩnh vực ô tô gán cấp ASIL (AD) theo mức độ rủi ro, và cấp càng cao thì yêu cầu kiểm chứng càng mạnh (ví dụ: độ bao phủ MC/DC ở cấp cao, khuyến nghị kiểm chứng hình thức). IEC 61508 cho công nghiệp nói chung định nghĩa mức toàn vẹn an toàn bằng SIL (14) và khuyến nghị/yêu cầu kỹ thuật phù hợp cho từng mức. Thiết bị y tế (IEC 62304) thay đổi mức nghiêm ngặt của yêu cầu, thiết kế, kiểm chứng theo cấp an toàn SW (A~C). Các tiêu chuẩn này yêu cầu bằng chứng về việc "đã kiểm chứng cái gì và chính xác đến mức nào", vì vậy chẩn đoán tính chính xác của hoạt động chức năng chính là quá trình tạo ra tài liệu căn cứ cho chứng nhận an toàn.
Ví dụ cụ thể, các tổ chức phát triển an toàn trọng yếu tự động chạy phân tích tĩnh và kiểm thử đơn vị ở mỗi commit, và đặt cổng (gate) chặn việc merge nếu độ bao phủ không đạt mục tiêu (ví dụ: MC/DC 100% ở cấp cao). Ngoài ra, họ liên kết công cụ quản lý yêu cầu với công cụ quản lý kiểm thử để tự động cập nhật truy vết, nhờ đó khi yêu cầu thay đổi có thể xác định ngay thiết kế và kiểm thử bị ảnh hưởng. Bằng cách này, ngay cả với SW quy mô lớn, có thể vượt qua giới hạn của chẩn đoán thủ công và liên tục xác nhận lại tính chính xác sau mỗi thay đổi.
Một ví dụ khác, với SW thiết bị y tế (IEC 62304 cấp C), đối với logic điều khiển lưu lượng của bơm truyền thuốc, không chỉ kiểm thử đơn thuốc bình thường mà còn dùng tiêm lỗi để kiểm thử các tình huống bất thường như cảm biến lỗi, mất điện tức thời, trễ truyền thông, rồi dùng truy vết để xác nhận kết quả có thỏa mãn yêu cầu "chuyển sang trạng thái dừng an toàn" hay không. Như vậy, chẩn đoán tính chính xác của hoạt động chức năng được áp dụng theo hình thức cụ thể hóa "hành vi nguy hiểm là gì" cho từng lĩnh vực, và truy vết đến cùng xem các yêu cầu tránh rủi ro đó có thực sự được cài đặt và kiểm chứng hay không.
Về xu hướng mới nhất, có ba điểm đáng chú ý. Thứ nhất, nâng cao phân tích tĩnh và kiểm chứng hình thức: cách tiếp cận dùng phương pháp toán học để chứng minh sự vắng mặt của các lỗi cụ thể (ngoại lệ runtime, tràn số nguyên) đang mở rộng trong các lĩnh vực an toàn trọng yếu. Thứ hai, kiểm chứng liên tục trong pipeline phát triển: chẩn đoán không còn là một giai đoạn riêng mà được tích hợp vào CI và thực hiện thường xuyên. Thứ ba, vấn đề chẩn đoán tính chính xác của SW dựa trên AI: với thành phần dựa trên học máy, đặc tả bị ẩn trong dữ liệu nên chẩn đoán truyền thống dựa trên yêu cầu – truy vết khó áp dụng nguyên vẹn, đòi hỏi tiêu chí chẩn đoán mới theo góc nhìn chất lượng dữ liệu, phân phối và độ bao phủ kịch bản. Điều này cho thấy đối tượng và phương pháp của chẩn đoán tính chính xác của hoạt động chức năng đang được mở rộng.
6. Các lưu ý và hàm ý
- Bảo đảm tính chính xác trong toàn bộ quá trình phát triển là cốt lõi. An toàn không thể bảo đảm chỉ bằng kiểm thử; phải xác nhận tính chính xác ở từng giai đoạn yêu cầu, thiết kế, cài đặt thì mới ngăn được khiếm khuyết lan sang giai đoạn sau. Đặc biệt, việc loại bỏ sự mơ hồ ở giai đoạn yêu cầu quyết định tiêu chí phán định của mọi chẩn đoán sau đó nên cần được đầu tư trước tiên.
- Lấy khả năng truy vết làm xương sống của chẩn đoán. Phải duy trì bằng công cụ ánh xạ hai chiều yêu cầu – thiết kế – cài đặt – kiểm thử để làm lộ ra yêu cầu chưa được kiểm chứng và mã không có căn cứ. Với SW quy mô lớn thay đổi thường xuyên, truy vết là nền tảng cho phân tích ảnh hưởng và chẩn đoán hồi quy.
- Liên kết với tiêu chuẩn an toàn chức năng để bảo đảm hiệu quả thực chất. Phải lập kế hoạch chẩn đoán gắn với yêu cầu theo cấp (độ bao phủ, quy trình kiểm chứng) của các tiêu chuẩn lĩnh vực như ISO 26262, IEC 61508, IEC 62304 thì mới tự nhiên tạo ra căn cứ chứng nhận và giảm làm lại. [[software-safety-analysis]]
- Kết hợp tĩnh, động, review và truy vết để xóa điểm mù. Không kỹ thuật đơn lẻ nào hoàn hảo, vì vậy cần kết hợp bổ trợ lẫn nhau giữa review sớm và chi phí thấp, phân tích tĩnh trên mọi đường, kiểm thử động với hành vi thực tế và truy vết kết nối các giai đoạn.
- Chuẩn bị cho tự động hóa, chẩn đoán liên tục và tiêu chí mới của thời đại AI. Với SW quy mô lớn, chẩn đoán thủ công có giới hạn, vì vậy cần tích hợp chẩn đoán vào CI để thực hiện thường xuyên, và xây dựng tiêu chí phán định tính chính xác mới như độ bao phủ dữ liệu và kịch bản cho các thành phần dựa trên học máy.
Tài liệu tham khảo
- ISO 26262 Road vehicles — Functional safety, https://www.iso.org/standard/68383.html
- IEC 61508 Functional safety of E/E/PE safety-related systems, https://www.iec.ch/functional-safety
- IEC 62304 Medical device software — Software life cycle processes, https://www.iso.org/standard/38421.html
Tóm tắt một câu: Chẩn đoán tính chính xác của hoạt động chức năng trong chẩn đoán an toàn SW là hoạt động phòng ngừa kiểm chứng tính chính xác ở từng giai đoạn yêu cầu → thiết kế → cài đặt → kiểm thử dựa trên khả năng truy vết, xác nhận đồng thời "hành vi phải làm" và "hành vi không được làm" bao gồm cả điều kiện bất thường và biên chứ không chỉ bình thường, và tạo căn cứ cho chứng nhận an toàn khi liên kết với các tiêu chuẩn an toàn chức năng như ISO 26262, IEC 61508.