Học cách điều tra lỗi [đã đóng]

Tôi thậm chí không chắc chắn làm thế nào để xác định khó khăn này. Nó làm tôi nhớ đến bài kiểm tra mà một vài nhân viên tương lai đã làm với tôi trước khi tôi có việc làm. Họ sẽ chọn một đối tượng trong phòng và sau đó tôi được phép đặt câu hỏi để giúp bản thân xác định đối tượng đó là gì (giống như 20 câu hỏi). Tôi rất giỏi về điều này (không, tôi chưa bao giờ đạt điểm cao về sự khiêm tốn), vì vậy tôi cho rằng tôi thực sự giỏi trong việc khắc phục lỗi ...

Nhưng đây là điều tôi đã tìm ra gần đây. Tôi thực sự rất tốt trong tình huống đó bởi vì thật dễ dàng để nhìn thấy mọi thứ trong phòng, do đó tôi có thể tiếp cận vấn đề của mình với một số khái niệm về các bộ phận cấu thành của nó. Về bản chất tôi "biết những gì tôi không biết". Nhưng với lập trình, tôi gặp rất nhiều tình huống mà vấn đề là một ẩn số hoàn toàn đối với tôi. Tôi biết nó bị hỏng, nhưng tôi không có khái niệm làm thế nào nó có thể bị phá vỡ. Tôi đã làm theo tất cả các hướng dẫn, tôi biết công nghệ khá tốt ...

Nếu tôi trung thực, tôi cảm thấy như mình chỉ gặp khó khăn khi tưởng tượng những điều có thể sai để tôi có thể kiểm tra chúng và, hy vọng, tìm ra giải pháp.

Làm thế nào để tôi phát triển kỹ năng đó? Tôi cần phải làm gì để giúp trí tưởng tượng hạn chế của tôi tìm ra những cách mà dự án của tôi có thể bị phá vỡ? Có những bài tập (câu đố có lẽ?) Có thể làm cho tôi tốt hơn ở đây? Tôi biết rằng có lẽ phương pháp chữa trị lớn nhất chỉ là kinh nghiệm ... nhưng tôi hy vọng sẽ giúp đẩy nhanh quá trình nếu tôi có thể. Nhìn chằm chằm vào màn hình máy tính của tôi trong vài giờ liền không phải là một trò vui ...

Mọi khiếm khuyết trong phần mềm cuối cùng là do sự khác biệt giữa các giả định và thực tế. Lỗi sâu sắc chỉ đơn giản là sự khác biệt giữa các giả định đặc biệt sâu sắc và thực tế. Khả năng chẩn đoán lỗi phụ thuộc vào khả năng của bạn để đặt câu hỏi cho các giả định của riêng bạn và điều đó thực sự đòi hỏi một nhận thức rằng bạn không biết một số điều nhất định, bạn chỉ giả định chúng và sử dụng cho đến bây giờ.

Rõ ràng các công cụ giao dịch, tệp nhật ký, trình gỡ lỗi, v.v ... rất hữu ích trong việc khám phá các giả định đó và sắp xếp lại mô hình thế giới của bạn với hệ thống thực tế. Nhưng cho đến khi bạn sẵn sàng đặt câu hỏi về giả định quan trọng, ví dụ: "Không thể là đầu vào xấu vì chúng tôi đã kiểm tra đầu vào toàn diện", bạn sẽ dành toàn bộ thời gian để kiểm tra các phần sai của hệ thống hoặc đơn giản là không biết tìm ở đâu khác ở nơi đầu tiên

Tôi cần phải làm gì để giúp trí tưởng tượng hạn chế của tôi tìm ra những cách mà dự án của tôi có thể bị phá vỡ?

Trong hầu hết các trường hợp, tôi hoàn toàn không nói gì. Bạn không nên cố gắng mơ những thứ có thể khiến chương trình bị phá vỡ. Bạn nên xác định một cách hệ thống những gì đang gây ra nó để phá vỡ.

Bạn nên tham gia vào quá trình gỡ lỗi với các thông tin sau:

• các bước đã được thực hiện và các giá trị được nhập để tạo ra lỗi;
• chương trình nên làm gì khi được cung cấp các bước và đầu vào đó;
• những gì chương trình đang làm khi được đưa ra các bước và đầu vào.

Nếu có thông báo lỗi, hãy lấy tất cả thông tin bạn có thể về nó. Nếu bản thân thông báo lỗi không rõ ràng và bạn không biết ý nghĩa của nó trong thực tế (một số thông báo lỗi không phải lúc nào cũng đặc biệt hữu ích), thì hãy sử dụng Google hoặc StackOverflow hoặc bất kỳ tài nguyên trực tuyến nào khác để tìm thông tin về nó. .

Nếu không có thông báo lỗi được hiển thị ở mặt trước, hãy kiểm tra bất kỳ nhật ký nào mà ứng dụng ghi vào thông báo lỗi trong khoảng thời gian bạn tái tạo lỗi. Mã có thể đã được thực thi để hoàn thành, nhưng đã gặp phải một ngoại lệ được xử lý dọc theo đường dẫn đến kết quả cuối cùng và tạo ra một mục trong nhật ký. Hãy tìm những thứ đó, làm tương tự ở trên và xác định chính xác ý nghĩa của chúng.

Nếu có stacktraces được cung cấp ngoại lệ được ném bởi mã của bạn (và nên có), hãy xem các dòng mã được đề cập. Dòng chính nó có thể không phải là một trong đó thực sự tạo ra vấn đề. Nếu bạn nhận được một NullPulumException trong một đoạn mã Java, stacktrace sẽ cho bạn biết nơi bạn đã cố gắng sử dụng thứ gì đó không có giá trị khi bạn mong đợi nó không tồn tại. Điều đó không chính xác chỉ ra bạn gây ra sự cố, nhưng nó thường cho bạn biết biến nào không có giá trị mà bạn mong đợi, vì vậy bạn có thể xem bất kỳ tham chiếu / bài tập nào cho biến đó để xác định giá trị đó không được đặt hoặc giá trị được đặt không chính xác.

Nếu không có cái nào giúp được, hãy khởi động trình gỡ lỗi của bạn. Nếu bạn đã thu hẹp nó xuống một phần của mã mà bạn biết đang gây ra sự cố - nhưng bạn không biết chính xác (các) dòng nào - thì hãy chuyển qua đó. Nếu không, chỉ cần bước qua toàn bộ. Đây là nơi bạn cần biết chính xác chương trình nên làm gì với các đầu vào đã cho, bởi vì bạn cần xem xét từng giá trị sau mỗi dòng và xác định chính xác nơi nó đi lệch khỏi những gì bạn mong đợi.

Vẫn không có manh mối vấn đề là gì? Nhờ ai đó giúp đỡ . Một đồng nghiệp, một người bạn, một cộng đồng trực tuyến. Cho họ thấy tất cả những công việc bạn vừa làm. Chỉ cho họ các thông báo lỗi, stacktraces, giải thích những gì chương trình nói chung (nếu họ chưa biết), những gì nó nên làm trong trường hợp cụ thể này (ví dụ trả về giá trị 4), thực tế nó đang làm gì (ví dụ trả về giá trị 5). Nếu bạn đã thu hẹp nó xuống một vài dòng mã trong trình gỡ lỗi, hãy nói "Tôi biết vấn đề là do các dòng này trong mã gây ra, nó sẽ đặt giá trị thành X khi nó phải là Y, nhưng tôi không thể thấy tại sao điều đó xảy ra ".

Dành vài giờ nhìn chằm chằm vào màn hình của bạn chắc chắn không vui, nhưng không có lý do gì bạn nên làm điều đó. Nếu có vấn đề với mã của bạn thì bạn cần phải đọc hoặc xem qua mã.

Ở một mức độ nào đó, nó giống như điều tra một vụ án hình sự, hoặc một câu đố khó hiểu.

Đầu tiên, bạn có nạn nhân. Sau khi đào sâu một lúc vào vụ án, bạn đã xác định được một vài nghi phạm và bạn cũng đã phát triển một giả thuyết công việc về việc chính xác nạn nhân có thể bị giết như thế nào. Bạn tiếp tục điều tra, tìm kiếm thêm thông tin hữu ích, giúp bạn ngày càng gần hơn với nguồn gốc thực sự của vấn đề.

Nó xảy ra rằng theo thời gian bạn đi vào một ngõ cụt (ý định chơi chữ). Đó là một phần của nó, và không có gì sai với nó, miễn là bạn xoay sở để đưa mình trở lại đúng hướng càng nhanh càng tốt. Điều quan trọng là, luôn luôn nghĩ về phần thông tin nào bạn cần tiếp theo, cung cấp giả thuyết của bạn (và cung cấp cho bạn thêm thông tin), hoặc chứng minh nó sai. Sau đó tìm cách để có được thông tin đó một cách hiệu quả, đưa ra kết luận của bạn và tiếp tục, cho đến khi bạn cuối cùng có thể kết án tội lỗi.

Và đôi khi bạn nhận ra rằng tất cả các sự thật và chỉ dẫn cần thiết để phát hiện ra thủ phạm đã chờ sẵn trước mặt bạn nửa giờ trước. Mặc dù gây phiền nhiễu, đó là một trong những phần thú vị nhất, bởi vì nếu bạn đánh giá nghiêm túc về hành động và sai lầm của mình, bạn có thể học hỏi và trở nên tốt hơn . Tự hỏi bản thân những câu hỏi như:

• Làm thế nào tôi có thể tránh lãng phí thời gian này?
• Tôi đã bỏ qua những gì ở nơi đầu tiên, và tại sao?
• Tôi đã dựa vào những giả định không có giá trị và / hoặc sai?

Điều này sẽ đào tạo khả năng của bạn. Nó cũng sẽ phát triển bản năng ruột của bạn , vì vậy theo thời gian, bạn học cách tự động nhận thấy tất cả những điều nhỏ nhặt quá dễ bị bỏ qua, dẫn bạn nhanh hơn đến câu trả lời đúng. Cuối cùng, tất cả là về thực hành có chủ ý .

Cuối cùng, luôn luôn nhớ những gì Sherlock Holmes đã dạy chúng tôi: Khi bạn đã loại bỏ những điều không thể, bất cứ điều gì còn lại, dù không thể xảy ra, đều phải là sự thật.

Tôi cần phải làm gì để giúp trí tưởng tượng hạn chế của tôi tìm ra những cách mà dự án của tôi có thể bị phá vỡ?

Hãy để lịch sử là hướng dẫn của bạn. Nếu dự án của bạn được quản lý tốt thì bạn nên có cơ sở dữ liệu về mọi lỗi đã được sửa trong sản phẩm cùng với phân tích về cách tìm thấy lỗi, cách tái tạo, cách phân tích và cách khắc phục. Đó không phải là một cơ sở dữ liệu chỉ viết. Đọc cơ sở dữ liệu và rất sớm các nguyên tắc phân loại lỗi sẽ bắt đầu xảy ra với bạn.

Điều đó sẽ cung cấp cho bạn một cái nhìn tổng quan tốt về các loại sai trong sản phẩm của bạn. Nếu bạn quan tâm nhiều hơn đến những gì sai trong tất cả các loại phần mềm, đặc biệt chú trọng đến các khiếm khuyết ảnh hưởng đến bảo mật, tôi khuyên bạn nên đọc danh sách CWE: http://cwe.mitre.org/data/index.html

Vì vậy, thay vì cố gắng tái tạo và sửa một lỗi cụ thể, tôi tin rằng bạn đang hỏi về việc nghĩ ra các thử nghiệm mới mà bạn có thể sử dụng để điều tra sản phẩm để xem sản phẩm có hoạt động trong những trường hợp đó không, ví dụ: điều gì xảy ra nếu tôi nhập các ký tự đặc biệt vào đăng ký mật khẩu của trang, hoặc điều gì xảy ra nếu tôi mạnh mẽ đóng chương trình trong khi nó đang ghi vào cơ sở dữ liệu. Những trường hợp này thực sự khó nghĩ lên.

Phát triển phần mềm trong 10 năm qua (Agile / XP / TDD, v.v.) đã đạt được giá trị chỉ đáp ứng các yêu cầu rõ ràng và sau đó tuyên bố tính năng đã hoàn thành và không tìm mọi cách có thể để phá vỡ một cái gì đó (có thể có ngoại lệ, nếu bạn là làm việc cho NASA hoặc thực hiện bảo mật mũ trắng nhưng ngay cả sau đó cũng có trường hợp được thực hiện để gọi những điều đó ra trong tiêu chí chấp nhận của câu chuyện người dùng).

Vì vậy, nếu các tính năng của bạn liệt kê rõ ràng là tiêu chí chấp nhận những gì hệ thống cần làm như cách xử lý đầu vào, đặc điểm hiệu suất của nó, hành động dòng công việc của người dùng, v.v. thì bạn có một danh sách đầy đủ về những gì các bài kiểm tra cần kiểm tra. Kiểm tra nên được thực hiện để xác nhận rằng các yêu cầu đã được đáp ứng, và cách tốt nhất để làm điều đó là liệt kê rõ ràng tất cả các yêu cầu của bạn. Hãy nhìn vào Quadrant Test Quadrant .

Một số người ủng hộ các thử nghiệm này là tuyên bố rõ ràng về các yêu cầu, cần phải được viết trước mã, tức là Thử nghiệm đầu tiên (hoặc Phát triển theo hướng thử nghiệm).

Tuy nhiên, tôi đánh giá cao rằng bạn không có vẻ như bạn đang dự tính một dự án mới, nơi bạn có thể thiết lập các thực tiễn tốt nhất cho sự phát triển của riêng mình trước khi bạn bắt đầu và thay vào đó sau khi phần mềm đã được viết và được yêu cầu 'kiểm tra nó'. Điều này thực sự khó khăn hơn nhưng các nguyên tắc tương tự được áp dụng, bạn chỉ có thể kiểm tra nó một khi bạn biết nó phải làm gì. Nếu không có một danh sách đầy đủ các yêu cầu đã được nhóm phát triển đáp ứng để bạn làm việc từ đó thì đặt câu hỏi là cách tốt nhất về phía trước. Tùy thuộc vào nhóm của bạn, điều này có thể cần được thực hiện một cách tinh tế vì những người không liệt kê rõ ràng các yêu cầu của họ trước khi xây dựng một hệ thống phần mềm không muốn được nhắc nhở về những gì họ đã bỏ lỡ nhưng điều cần thiết là phải thực hiện tốt nhiệm vụ này.

Khi bạn tìm thấy một yêu cầu - nó phải mạnh mẽ / nó phải an toàn, sau đó cố gắng đào sâu hơn và tìm hiểu mức độ an toàn của nó, hoặc mức độ thất bại có thể chấp nhận được, luôn có một giới hạn, không nhiều người có bằng chứng NSA mức độ bảo mật như một yêu cầu cho ứng dụng của họ hoặc muốn trả tiền cho điều đó. Bạn càng đào sâu thì càng rõ ràng về loại tấn công bảo mật nào bạn cần để chống lại hoặc dễ sử dụng mà bạn đang hướng tới. Một số kiến ​​thức tên miền sau đó hữu ích, về bảo mật, thiết kế, hiệu suất, v.v. đó là nơi bạn đặt nhiều câu hỏi hơn từ các chuyên gia bạn có thể tìm thấy trong nhóm của mình hoặc ở đây trên SE hoặc google / sách.