Có bảo hiểm đường dẫn đảm bảo tìm thấy tất cả các lỗi?

Nếu mọi đường dẫn thông qua một chương trình được kiểm tra, điều đó có đảm bảo tìm thấy tất cả các lỗi không?

Nếu không, tai sao không? Làm thế nào bạn có thể đi qua mọi sự kết hợp có thể của dòng chương trình và không tìm thấy vấn đề nếu tồn tại?

Tôi ngần ngại đề xuất rằng "tất cả các lỗi" có thể được tìm thấy, nhưng có lẽ đó là do phạm vi bảo hiểm đường dẫn không thực tế (vì nó là tổ hợp) nên nó chưa từng có kinh nghiệm?

Lưu ý: bài viết này cung cấp một bản tóm tắt nhanh chóng về các loại bảo hiểm như tôi nghĩ về chúng.

Nếu mọi đường dẫn thông qua một chương trình được kiểm tra, điều đó có đảm bảo tìm thấy tất cả các lỗi không?

Không

Nếu không, tai sao không? Làm thế nào bạn có thể đi qua mọi sự kết hợp có thể của dòng chương trình và không tìm thấy vấn đề nếu tồn tại?

Bởi vì ngay cả khi bạn kiểm tra tất cả các đường dẫn có thể , bạn vẫn chưa kiểm tra chúng với tất cả các giá trị có thể hoặc tất cả các kết hợp giá trị có thể . Ví dụ (mã giả):

def Add(x as Int32, y as Int32) as Int32:
   return x + y

Test.Assert(Add(2, 2) == 4) //100% test coverage
Add(MAXINT, 5) //Throws an exception, despite 100% test coverage

Bây giờ là hai thập kỷ kể từ khi chỉ ra rằng thử nghiệm chương trình có thể chứng minh một cách thuyết phục sự hiện diện của lỗi, nhưng không bao giờ có thể chứng minh sự vắng mặt của chúng. Sau khi trích dẫn lời nhận xét được công bố rộng rãi này, kỹ sư phần mềm trở lại trật tự trong ngày và tiếp tục hoàn thiện các chiến lược thử nghiệm của mình, giống như nhà giả kim của yore, người tiếp tục tinh chỉnh các tinh chế chrysocosmic của mình.

- EW Dijkstra (Nhấn mạnh thêm. Được viết vào năm 1988. Đã hơn 2 thập kỷ rồi.)

Ngoài câu trả lời của Mason , còn có một vấn đề khác: phạm vi bảo hiểm không cho bạn biết mã nào đã được kiểm tra, nó cho bạn biết mã nào đã được thực thi .

Hãy tưởng tượng bạn có một testsuite với phạm vi bảo hiểm 100% đường dẫn. Bây giờ loại bỏ tất cả các xác nhận và chạy lại testsuite. Voilà, testsuite vẫn có phạm vi bảo hiểm 100% đường dẫn, nhưng nó kiểm tra hoàn toàn không có gì.

Đây là một ví dụ đơn giản hơn để làm tròn mọi thứ. Hãy xem xét thuật toán sắp xếp sau (trong Java):

int[] sort(int[] x) { return new int[] { x[0] }; }

Bây giờ, hãy kiểm tra:

sort(new int[] { 0xCAFEBABE });

Bây giờ, hãy xem xét rằng (A) lệnh gọi cụ thể này để sorttrả về kết quả chính xác, (B) tất cả các đường dẫn mã đã được kiểm tra này.

Nhưng, rõ ràng, chương trình không thực sự sắp xếp.

Theo sau đó, phạm vi bảo hiểm của tất cả các đường dẫn mã là không đủ để đảm bảo rằng chương trình không có lỗi.

Hãy xem xét abshàm, trả về giá trị tuyệt đối của một số. Đây là một bài kiểm tra (Python, hãy tưởng tượng một số khung kiểm tra):

def test_abs_of_neg_number_returns_positive():
    assert abs(-3) == 3

Cách thực hiện này là chính xác, nhưng nó chỉ được bảo hiểm mã 60%:

def abs(x):
    if x < 0:
        return -x
    else:
        return x

Việc triển khai này là sai, nhưng nó được bảo hiểm 100% mã:

def abs(x):
    return -x

Một bổ sung khác cho câu trả lời của Mason , hành vi của một chương trình có thể phụ thuộc vào môi trường thời gian chạy.

Đoạn mã sau có chứa Sử dụng sau khi miễn phí:

int main(void)
{
    int* a = malloc(sizeof(a));
    int* b = a;
    *a = 0;
    free(a);
    *b = 12; /* UAF */
    return 0;
}

Mã này là Hành vi không xác định, tùy thuộc vào cấu hình (phát hành | gỡ lỗi), HĐH và trình biên dịch, nó sẽ mang lại các hành vi khác nhau. Không chỉ phạm vi bảo hiểm đường dẫn sẽ không đảm bảo rằng bạn sẽ tìm thấy UAF, mà bộ kiểm tra của bạn thường sẽ không bao gồm các hành vi có thể khác nhau của UAF phụ thuộc vào cấu hình.

Một lưu ý khác, ngay cả khi phạm vi bảo hiểm đường dẫn là để đảm bảo tìm thấy tất cả các lỗi, không chắc là nó có thể đạt được trong thực tế trên bất kỳ chương trình nào. Hãy xem xét một trong những điều sau đây:

int main(int a, int b)
{
    if (a != b) {
        if (cryptohash(a) == cryptohash(b)) {
            return ERROR;
        }
    }
    return 0;
} 

Nếu bộ thử nghiệm của bạn có thể tạo ra tất cả các đường dẫn cho việc này, thì xin chúc mừng bạn là một nhà mật mã học.

Rõ ràng từ các câu trả lời khác rằng độ bao phủ mã 100% trong các thử nghiệm không có nghĩa là độ chính xác của mã 100% hoặc thậm chí tất cả các lỗi có thể tìm thấy bằng thử nghiệm sẽ được tìm thấy (không bao giờ để ý các lỗi mà không thử nghiệm nào có thể bắt được).

Một cách khác để trả lời câu hỏi này là một từ thực tiễn:

Trong thế giới thực và trên máy tính của bạn, có rất nhiều phần mềm được phát triển bằng một bộ kiểm tra có độ bao phủ 100% và vẫn còn lỗi, bao gồm cả các lỗi mà kiểm tra tốt hơn sẽ xác định.

Do đó, một câu hỏi đòi hỏi là:

Điểm của các công cụ bảo hiểm mã là gì?

Các công cụ bảo hiểm mã giúp xác định các khu vực mà người ta đã bỏ qua để kiểm tra. Điều đó có thể ổn (mã hoàn toàn chính xác ngay cả khi không kiểm tra) không thể giải quyết (vì lý do nào đó đường dẫn không thể bị tấn công) hoặc có thể là vị trí của một lỗi hôi thối tuyệt vời ngay bây giờ hoặc sau các sửa đổi trong tương lai.

Trong một số cách, kiểm tra chính tả có thể so sánh được: Một cái gì đó có thể "vượt qua" kiểm tra chính tả và bị sai chính tả theo cách khớp với một từ trong từ điển. Hoặc nó có thể "thất bại" vì các từ chính xác không có trong từ điển. Hoặc nó có thể vượt qua và vô nghĩa. Kiểm tra chính tả là một công cụ giúp bạn xác định các địa điểm mà bạn có thể đã bỏ lỡ trong quá trình đọc bằng chứng của mình, nhưng cũng như nó không thể đảm bảo việc đọc bằng chứng hoàn chỉnh và chính xác, do đó, phạm vi bảo hiểm mã không thể đảm bảo kiểm tra đầy đủ và chính xác.

Và tất nhiên, cách sử dụng kiểm tra chính tả không chính xác là nổi tiếng với mọi gợi ý về biển mà nó gợi ý để điều vịt trở nên tồi tệ hơn sau đó nếu chúng tôi cho nó mượn.

Với phạm vi bảo hiểm mã, nó có thể hấp dẫn, đặc biệt là nếu bạn đã hoàn thành 98%, để điền vào các trường hợp để các đường dẫn còn lại bị tấn công.

Đó là tương đương với quyền với kiểm tra chính tả rằng tất cả các từ thời tiết hoặc thắt nút đó là tất cả các từ thích hợp. Kết quả là một mớ hỗn độn vịt.

Tuy nhiên, nếu bạn xem xét những gì kiểm tra các đường dẫn không được bảo hiểm thực sự cần, công cụ bao phủ mã sẽ thực hiện công việc của nó; không phải trong việc hứa hẹn cho bạn sự đúng đắn, nhưng nó chỉ ra một số công việc cần phải làm.

Bảo hiểm đường dẫn không thể cho bạn biết liệu tất cả các tính năng cần thiết đã được triển khai chưa. Rời khỏi một tính năng là một lỗi, nhưng phạm vi bảo hiểm đường dẫn sẽ không phát hiện ra nó.

Một phần của vấn đề là phạm vi bảo hiểm 100% chỉ đảm bảo rằng mã sẽ hoạt động chính xác sau một lần thực thi . Một số lỗi như rò rỉ bộ nhớ có thể không rõ ràng hoặc gây ra sự cố sau một lần thực thi, nhưng theo thời gian sẽ gây ra sự cố cho ứng dụng.

Ví dụ: giả sử bạn có một ứng dụng kết nối với cơ sở dữ liệu. Có lẽ trong một phương thức, lập trình viên quên đóng kết nối với cơ sở dữ liệu khi chúng được thực hiện với truy vấn của họ. Bạn có thể chạy một số thử nghiệm qua phương pháp này và không tìm thấy lỗi nào với chức năng của nó, nhưng máy chủ cơ sở dữ liệu của bạn có thể gặp phải tình huống không có kết nối khả dụng vì phương thức cụ thể này không đóng kết nối khi hoàn thành và các kết nối mở phải bây giờ đã hết thời gian

Nếu mọi đường dẫn thông qua một chương trình được kiểm tra, điều đó có đảm bảo tìm thấy tất cả các lỗi không?

Như đã nói, câu trả lời là KHÔNG.

Nếu không, tai sao không?

Bên cạnh những gì đang được nói, có những lỗi xuất hiện ở các cấp độ khác nhau, không thể được kiểm tra bằng các bài kiểm tra đơn vị. Chỉ cần đề cập đến một vài:

• lỗi bắt gặp với kiểm tra tích hợp (xét nghiệm đơn vị không nên sử dụng tài nguyên thực sự)
• lỗi trong yêu cầu
• lỗi trong thiết kế và kiến ​​trúc

Nó có ý nghĩa gì đối với mọi con đường được thử nghiệm?

Các câu trả lời khác là rất tốt, nhưng tôi chỉ muốn thêm rằng điều kiện "mọi con đường thông qua một chương trình được kiểm tra" là rất mơ hồ.

Hãy xem xét phương pháp này:

def add(num1, num2)
  foo = "bar"  # useless statement
  $global += 1 # side effect
  num1 + num2  # actual work
end

Nếu bạn viết một bài kiểm tra khẳng định add(1, 2) == 3, một công cụ bao phủ mã sẽ cho bạn biết rằng mọi dòng đều được thực hiện. Nhưng bạn chưa thực sự khẳng định bất cứ điều gì về tác dụng phụ toàn cầu hoặc nhiệm vụ vô ích. Những dòng đó được thực thi, nhưng chưa thực sự được thử nghiệm.

Thử nghiệm đột biến sẽ giúp tìm ra các vấn đề như thế này. Một công cụ kiểm tra đột biến sẽ có một danh sách các cách được xác định trước để "biến đổi" mã và xem các kiểm tra có còn vượt qua hay không. Ví dụ:

• Một đột biến có thể thay đổi +=thành -=. Đột biến đó sẽ không gây ra lỗi thử nghiệm, vì vậy nó sẽ chứng minh rằng thử nghiệm của bạn không khẳng định bất cứ điều gì có ý nghĩa về tác dụng phụ toàn cầu.
• Một đột biến khác có thể xóa dòng đầu tiên. Đột biến đó sẽ không gây ra lỗi kiểm tra, vì vậy nó sẽ chứng minh rằng bài kiểm tra của bạn không khẳng định bất cứ điều gì có ý nghĩa về bài tập.
• Vẫn còn một đột biến khác có thể xóa dòng thứ ba. Điều đó sẽ gây ra lỗi thử nghiệm, trong trường hợp này, cho thấy thử nghiệm của bạn không khẳng định điều gì về dòng đó.

Trong essense, kiểm tra đột biến là một cách để kiểm tra bài kiểm tra của bạn . Nhưng giống như bạn sẽ không bao giờ kiểm tra chức năng thực tế với mọi bộ đầu vào có thể, bạn sẽ không bao giờ chạy mọi đột biến có thể xảy ra, do đó, điều này lại bị hạn chế.

Mỗi thử nghiệm chúng tôi có thể làm là một heuristic để tiến tới các chương trình không có lỗi. Không có gì là hoàn hảo.

Chà ... đúng vậy , nếu mọi đường dẫn thông qua chương trình được thử nghiệm. Nhưng điều đó có nghĩa là, mọi con đường có thể đi qua toàn bộ không gian của tất cả các trạng thái có thể mà chương trình có thể có, bao gồm tất cả các biến. Ngay cả đối với một chương trình được biên dịch tĩnh rất đơn giản - giả sử, một cruncher số Fortran cũ - không khả thi, mặc dù ít nhất có thể tưởng tượng được: nếu bạn chỉ có hai biến số nguyên, về cơ bản bạn đang xử lý tất cả các cách có thể để kết nối các điểm trên lưới hai chiều; nó thực sự trông rất giống nhân viên bán hàng du lịch. Đối với n biến như vậy, bạn đang làm việc với một n không gian ba chiều, vì vậy đối với bất kỳ chương trình thực tế, nhiệm vụ là hoàn toàn untractable.

Tồi tệ hơn: đối với những thứ nghiêm trọng, bạn không chỉ có một số biến số nguyên thủy cố định mà còn tạo ra các biến số trong các lệnh gọi hàm hoặc có các biến có kích thước biến ... hoặc bất cứ thứ gì tương tự, bằng ngôn ngữ hoàn chỉnh Turing. Điều đó làm cho không gian nhà nước trở nên vô tận, phá tan mọi hy vọng về phạm vi bảo hiểm đầy đủ, thậm chí còn được cung cấp thiết bị thử nghiệm mạnh mẽ vô lý.

Điều đó nói rằng ... thực sự mọi thứ không quá ảm đạm. Nó là thể proove toàn bộ chương trình là đúng, nhưng bạn sẽ phải từ bỏ một vài ý tưởng.

Đầu tiên: rất nên chuyển sang một ngôn ngữ khai báo. Vì một số lý do, ngôn ngữ bắt buộc luôn luôn trở nên phổ biến nhất, nhưng cách chúng kết hợp các thuật toán với các tương tác trong thế giới thực khiến cho việc nói những gì bạn muốn nói là đúng là khó khăn .

Dễ dàng hơn nhiều trong các ngôn ngữ lập trình chức năng thuần túy : chúng có sự phân biệt rõ ràng giữa các tính chất thú vị thực sự của các hàm toán học và các tương tác trong thế giới thực mờ mà bạn không thể thực sự nói gì. Đối với các hàm, rất dễ dàng chỉ định hành vi đúng chính xác, nếu: đối với tất cả các đầu vào có thể (từ các loại đối số), kết quả mong muốn tương ứng xuất hiện, thì hàm sẽ hoạt động chính xác.

Bây giờ, bạn nói rằng điều đó vẫn còn khó hiểu ... xét cho cùng, không gian của tất cả các đối số có thể nói chung cũng là vô hạn. Đúng - mặc dù đối với một chức năng duy nhất, ngay cả thử nghiệm bảo hiểm ngây thơ dẫn bạn đi xa hơn bạn có thể hy vọng trong một chương trình bắt buộc! Tuy nhiên, có một công cụ mạnh mẽ đáng kinh ngạc làm thay đổi trò chơi: định lượng phổ / đa hình tham số . Về cơ bản, điều này cho phép bạn viết các hàm trên các loại dữ liệu rất chung chung, với đảm bảo rằng nếu nó hoạt động với một ví dụ đơn giản về dữ liệu, nó sẽ hoạt động cho mọi đầu vào có thể.

Ít nhất là về mặt lý thuyết. Thật không dễ để tìm đúng loại thực sự quá chung chung đến nỗi bạn hoàn toàn có thể đưa ra điều này - thông thường, bạn cần một ngôn ngữ được gõ phụ thuộc và chúng có xu hướng khá khó sử dụng. Nhưng viết theo kiểu chức năng chỉ với đa hình tham số đã tăng mức độ bảo mật của bạn rất cao - bạn không nhất thiết phải tìm thấy tất cả các lỗi, nhưng bạn sẽ phải che giấu chúng khá tốt để trình biên dịch không phát hiện ra chúng!