Навчання розслідувати помилки [закрито]

Я навіть не впевнений, як визначити цю складність. Це нагадує мені тест, який пару потенційних співробітників зробили на мені, перш ніж я влаштувався на роботу. Вони виберуть предмет у кімнаті, і тоді мені дозволять задавати питання, щоб допомогти собі визначити, що це за об’єкт (приблизно як 20 запитань). Я був смішно хороший у цьому (ні, я ніколи не отримував високих балів за смиренність), тому я припускав, що я справді добрий у вирішенні несправностей ...

Але ось те, що я з’ясував нещодавно. Мені дуже добре в цій ситуації, тому що реально легко бачити все, що знаходиться в кімнаті, тому я можу підійти до своєї проблеми з деякою концепцією її складових частин. По суті я "знаю те, чого не знаю". Але з програмуванням я стикаюся з безліччю ситуацій, коли проблема мені зовсім невідома. Я знаю, що це зламано, але я не маю поняття, як воно може бути зламане. Я дотримувався всіх інструкцій, технологію досить добре знаю ...

Якщо я чесний, я відчуваю, що мені просто важко уявити речі, які можуть бути неправильними, щоб я міг їх перевірити і, сподіваюся, знайти рішення.

Як мені займатися розвитком цієї навички? Що мені потрібно зробити, щоб допомогти моїй, мабуть, обмеженій уяві придумати способи, які мій проект міг би бути порушений? Чи є вправи (можливо, пазли?), Які можуть зробити мене кращим у цьому? Я усвідомлюю, що, мабуть, найбільшим лікуванням є лише досвід ... але я сподіваюся допомогти прискорити процес, якщо зможу. Неочікувано дивитись на екран мого комп’ютера за кілька годин - це навіть не таке задоволення ...

Кожен дефект програмного забезпечення, в кінцевому рахунку, обумовлений невідповідністю між припущеннями та реальністю. Підступні помилки - це просто розбіжності між особливо глибокими припущеннями та реальністю. Здатність діагностувати помилки залежить від вашої здатності ставити під сумнів власні припущення, а це дійсно вимагає усвідомлення того, що ви не знаєте певних речей, ви просто припускали їх і раніше були правильними.

Очевидно, інструменти торгівлі, файли журналів, налагоджувачі тощо корисні для розкриття таких припущень та повторного узгодження вашої світової моделі з реальною системою. Але поки ви не будете готові ставити під сумнів важливе припущення, наприклад, "Це не може бути поганим введенням, тому що ми всебічно перевіряємо вхід", ви витратите весь свій час на перевірку неправильних частин системи, або просто не знаючи, де ще шукати. на першому місці.

Що мені потрібно зробити, щоб допомогти моїй, мабуть, обмеженій уяві придумати способи, які мій проект міг би бути порушений?

У більшості випадків я б сказав абсолютно нічого. Не слід намагатися придумати речі, які можуть спричинити розрив програми. Ви повинні систематично визначити , що є причиною його розірвати.

Ви повинні перейти до налагодження з наступними відомостями:

• кроки, які були вжиті, та значення, які були введені для створення помилки;
• що програма повинна робити при наданні цих кроків та входів;
• що програма буде робити , коли з урахуванням цих кроків і входів.

Якщо є повідомлення про помилку, отримайте всю інформацію про нього. Якщо повідомлення про помилку саме по собі не зрозуміло, і ви не знаєте, що це означає на практиці (деякі повідомлення про помилки не завжди є особливо корисними), використовуйте Google, StackOverflow або будь-який інший інтернет-ресурс, щоб знайти інформацію про нього .

Якщо на передньому кінці не відображається повідомлення про помилку, перевірте будь-які журнали, на які записує програма, чи з’являються повідомлення про помилки протягом періоду відтворення помилки. Код, можливо, виконується до завершення, але зіткнувся з винятком, який обробляється по шляху, який скидає кінцевий результат і створює запис у журналах. Шукайте тих, зробіть те саме вище та визначте, що саме вони означають.

Якщо є стек-треки з винятками, кинутими вашим кодом (і вони повинні бути), подивіться згадані рядки коду. Сама лінія може бути не тією, яка насправді створює проблему. Якщо ви отримаєте NullPointerException у фрагменті коду Java, стек-трек підкаже вам, де ви намагалися використовувати те, що було недійсним, коли ви очікували, що цього не буде. Це не точно вказує на рядок, що викликає проблему, але він, як правило, говорить вам, яка змінна не має значення, яке ви очікуєте, тому ви можете переглянути будь-які посилання / призначення на цю змінну, щоб визначити, що значення не встановлено або що значення встановлено неправильно.

Якщо нічого з цього не допомогло, запустіть налагоджувача. Якщо ви звузили його до розділу коду, який, на вашу думку, спричиняє проблему - але ви не знаєте точно, який рядок (и) - тоді перейдіть через це. Якщо ні, просто перегляньте всю річ. Тут потрібно точно знати, що програма повинна робити із заданими входами, тому що потрібно переглянути кожне значення після кожного рядка і точно визначити, де воно відхиляється від того, що ви очікуєте від нього.

Все ще не маєте поняття, в чому проблема? Попросіть когось про допомогу . Співробітник, друг, інтернет-спільнота. Покажіть їм всю роботу, яку ви тільки що зробили. Покажіть їм повідомлення про помилки, стеки, поясніть, що програма робить у загальних рисах (якщо вони ще не знають), що вона повинна робити в цьому конкретному випадку (наприклад, повернення значення 4), що вона насправді робить (наприклад повернення значення 5). Якщо ви обмежили його на кілька рядків коду у відладчику, скажіть: «Я знаю, що проблема викликана цими рядками в коді, вона встановлює значення X, коли воно повинно бути Y, але я не бачу чому це відбувається ".

Витратити кілька годин беззрибно дивлячись на ваш екран, безумовно, не цікаво, але немає причин, щоб ви цим займалися. Якщо у вас є проблеми з вашим кодом, вам потрібно прочитати чи переглядати код.

Певною мірою це як розслідування кримінальної справи, або загадкова загадка.

По-перше, ви отримали жертву. Викопавши деякий час у справі, ви визначили кількох підозрюваних, а також розробили робочу гіпотезу про те, як саме жертву можна було вбити. Ви продовжуєте розслідувати, шукаючи кориснішу інформацію, наближаючись до реального джерела проблеми.

Буває, що час від часу ви заходите в глухий кут (каламбур призначений). Це частина цього, і в цьому немає нічого поганого, якщо вам вдасться якомога швидше повернути себе на трек. Головне - завжди думати про те, яку інформацію вам потрібно далі, яка або надає вашу гіпотезу (і надає вам додаткову інформацію), або доводить її неправильно. Тоді знайдіть спосіб ефективно отримати цю інформацію, зробіть свої висновки та рухайтеся далі, поки нарешті не зможете засудити винних.

І часом ти розумієш, що всі факти та вказівки, необхідні для того, щоб визначити винуватця, вже чекали перед тобою півгодини тому. Хоча це дратує, це одна з найцікавіших частин, тому що якщо ви критично переглянете свої дії та помилки, ви, можливо, зможете навчитися та покращитись . Задайте собі такі питання, як:

• Як я міг уникнути цієї трати часу?
• Що я в першу чергу не помітив і чому?
• На які невиправдані та / або неправильні припущення я покладався?

Це тренуватиме ваші здібності. Це також розвине ваш інстинкт кишечника , тому з часом ви навчитесь автоматично помічати всі ті незначні речі, які занадто легко не помічаються, приводячи вас швидше до правильної відповіді. Врешті-решт, це все про навмисну ​​практику .

І останнє не завжди пам’ятайте, чого навчив нас Шерлок Холмс: Коли ви усунули неможливе, все, що залишається, як би мало й було мало, має бути правдою.

Що мені потрібно зробити, щоб допомогти моїй, мабуть, обмеженій уяві придумати способи, які мій проект міг би бути порушений?

Нехай історія буде вашим путівником. Якщо ваш проект добре керується, ви повинні мати базу даних про кожну помилку, яка коли-небудь була виправлена ​​у продукті, а також аналіз того, як виявлена ​​помилка, як вона була відтворена, як вона була проаналізована та як її виправлено. Це не база даних лише для запису. Прочитайте базу даних , і дуже скоро таксономії помилок почнуть виникати у вас.

Це дасть вам хороший огляд того, що у вашому продукті йде не так. Якщо вас загалом цікавить, що не так у всіх видах програмного забезпечення, особливо з акцентом на дефекти, що впливають на безпеку, пропоную прочитати список CWE: http://cwe.mitre.org/data/index.html

Тому замість того, щоб намагатися відтворити та виправити конкретний дефект, я вважаю, що ви запитуєте про придумування нових тестів, які ви могли б використати для дослідження продукту, щоб побачити, чи працює продукт за таких обставин, наприклад: що трапиться, якщо я введу спеціальних символів у наш зареєструвати поданий пароль на сторінці, або що станеться, якщо я насильно закриваю програму, поки вона пише в базу даних. Ці справи справді важко придумати.

Розробка програмного забезпечення протягом останніх 10 років (Agile / XP / TDD тощо) оцінила задоволення лише явних вимог, а потім оголосив функцію закінченою, і не знаходити всіх можливих способів зламати щось (можливі винятки, якщо ви працюючи в NASA або займаючись захистом білого капелюха, але навіть тоді є необхідний виклик таких випадків за критеріями прийняття історії користувача).

Отже, якщо ваші функції явно перераховують як критерії прийняття те, що потрібно робити системам, наприклад, як обробляти вхідні дані, характеристики його продуктивності, дії робочого процесу користувача тощо, то у вас є повний перелік того, для чого потрібно перевіряти тести. Тестування повинно бути проведено для підтвердження того, що вимоги були дотримані, і найкращий спосіб зробити це - чітко перерахувати всі ваші вимоги. Погляньте на Agile Test Quadrants .

Деякі люди виступають за те, щоб ці тести були чіткою декларацією вимог, яку потрібно написати перед кодом, тобто Test First (або Test Driven Development).

Однак я вдячний, що ти не схожий на те, що ти задумуєшся над новим проектом, де ти можеш встановити свої власні найкращі практики перед початком роботи, а замість цього прийдеш після написання програмного забезпечення та просять "протестувати його". Це справді складніше, але застосовуються ті самі принципи, ви можете протестувати його лише після того, як дізнаєтесь, що він повинен був робити. Якщо не існує вичерпного переліку вимог, яким відповідав би команда розробників, щоб ви працювали, тоді задавати питання - це найкращий шлях вперед. Залежно від вашої команди це може знадобитися робити делікатно, оскільки людям, які не перераховували явно свої вимоги перед створенням програмної системи, не подобається нагадувати про те, що вони пропустили, але важливо добре виконувати це завдання.

Як тільки ви знайдете вимогу - вона повинна бути надійною / вона повинна бути захищеною, тоді спробуйте копати глибше і з’ясувати, наскільки вона повинна бути захищеною, або наскільки відмова прийнятна, завжди існує межа, не багато людей мають доказ НСА рівень безпеки як вимога їх застосування або хотів би заплатити за це. Чим більше ви копаєте, тим чіткіше має бути питання про те, які типи атак безпеки потрібно захищати від або простого використання, на яке ви прагнете. Потім деякі знання про домен корисні, в галузі безпеки, дизайну, продуктивності тощо. Тут ви ставите ще більше питань у експертів, яких ви можете знайти у вашій команді, або тут, в SE, або Google / книгах.