Учимся исследовать ошибки [закрыто]

Я даже не уверен, как определить эту трудность. Это напоминает мне о тесте, который несколько предполагаемых сотрудников сделали на меня, прежде чем я получил работу. Они выбирали предмет в комнате, и тогда мне позволяли задавать вопросы, чтобы я сам мог определить, что это за предмет (например, 20 вопросов). Я был смехотворно хорош в этом (нет, я никогда не получал высоких баллов за смирение), поэтому я предположил, что буду действительно хорош в устранении ошибок ...

Но вот что я понял недавно. Я действительно хорош в этой ситуации, потому что действительно легко увидеть все, что находится в комнате, поэтому я могу подойти к своей проблеме с некоторой концепцией ее составных частей. По сути, я «знаю, чего не знаю». Но с программированием я сталкиваюсь с множеством ситуаций, когда эта проблема мне совершенно неизвестна. Я знаю, что он сломан, но понятия не имею, как он может быть сломан. Я выполнил все инструкции, хорошо знаю технологию ...

Если честно, я чувствую, что мне просто трудно представить, что может быть неправильно, поэтому я могу проверить их и, надеюсь, найти решение.

Как мне развить этот навык? Что мне нужно сделать, чтобы помочь моему, по-видимому, ограниченному воображению придумать способы, которыми мой проект мог быть сломан? Существуют ли упражнения (возможно, загадки?), Которые могут помочь мне в этом? Я знаю, что, вероятно, самое большое лекарство - это просто опыт ... но я надеюсь помочь ускорить процесс, если смогу. Бессмысленно смотреть на экран моего компьютера несколько часов подряд - это даже не весело ...

Каждый дефект в программном обеспечении в конечном счете связан с несоответствием между предположениями и реальностью. Коварные ошибки - это просто несоответствия между глубоко укоренившимися предположениями и реальностью. Способность диагностировать ошибки зависит от вашей способности подвергать сомнению ваши собственные предположения, и это действительно требует осознания того, что вы не знаете определенных вещей, вы просто предполагали их и привыкли быть правы до сих пор.

Очевидно, что инструменты торговли, файлы журналов, отладчики и т. Д. Полезны для выявления таких предположений и повторного согласования вашей модели мира с реальной системой. Но до тех пор, пока вы не будете готовы поставить под сомнение важнейшее предположение, например, «Это не может быть плохим вводом, потому что у нас есть всесторонняя проверка ввода», вы будете тратить все свое время на проверку неправильных частей системы или просто не зная, где еще искать. в первую очередь.

Что мне нужно сделать, чтобы помочь моему, по-видимому, ограниченному воображению придумать способы, которыми мой проект мог быть сломан?

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

Вы должны войти в процесс отладки со следующей информацией:

• предпринятые шаги и значения, которые были введены для создания ошибки;
• что должна делать программа, учитывая эти шаги и вклады;
• что программа будет делать , когда с учетом этих шагов и входов.

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

Если в интерфейсе не отображается сообщение об ошибке, проверьте все журналы, в которые приложение записывает сообщения об ошибках в течение периода времени, когда вы воспроизвели ошибку. Код, возможно, был выполнен до конца, но обнаружил исключение, которое обрабатывается по пути, который отбрасывает конечный результат и создает запись в журналах. Ищите их, делайте то же самое выше и точно определите, что они значат.

Если есть трассировки стека, предоставленные с исключениями, сгенерированными вашим кодом (и должны быть), посмотрите на упомянутые строки кода. Сама линия не может быть той, которая на самом деле вызывает проблему. Если вы получите исключение NullPointerException в части кода Java, трассировка стека скажет вам, где вы пытались использовать что-то, что было нулевым, когда вы ожидали, что этого не будет. Это точно не указывает на строку, вызывающую проблему, но, как правило, говорит вам, какая переменная не имеет значения, которого вы ожидаете, поэтому вы можете посмотреть на любые ссылки / присваивания этой переменной, чтобы определить, что значение не устанавливается или что значение устанавливается неправильно.

Если ничего из этого не помогло, запустите ваш отладчик. Если вы сузили его до фрагмента кода, который, как вы знаете, вызывает проблему, - но вы не знаете точно, какие строки (строки), - тогда выполните это. Если нет, просто перебери все это. Здесь вам нужно точно знать, что программа должна делать с заданными входными данными, потому что вам нужно смотреть на каждое значение после каждой строки и точно определять, где оно отклоняется от ожидаемого.

Все еще не знаете, в чем проблема? Попросите кого-нибудь о помощи . Сотрудник, друг, интернет-сообщество. Покажите им всю ту работу, которую вы только что сделали. Покажите им сообщения об ошибках, трассировки стека, объясните, что программа делает в общих чертах (если они еще не знают), что она должна делать в данном конкретном случае (например, возвращая значение 4), что она фактически делает (например, возвращая значение 5). Если вы сузили его до нескольких строк кода в отладчике, скажите: «Я знаю, что проблема вызвана этими строками в коде, он устанавливает значение X, когда оно должно быть Y, но я не вижу почему это происходит ".

Тратить несколько часов, уставившись в тупик на экране, определенно не весело, но нет причин, по которым вам следует это делать. Если есть проблема с вашим кодом, то вам нужно прочитать или пройтись по коду.

В какой-то степени это похоже на расследование уголовного дела или невероятную загадку.

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

Бывает, что время от времени вы заходите в тупик (каламбур). Это часть этого, и в этом нет ничего плохого, если вам удастся как можно быстрее вернуться на правильный путь. Ключ в том, чтобы всегда думать о том, какая часть информации вам нужна дальше, которая либо подкрепляет вашу гипотезу (и предоставляет вам дополнительную информацию), либо доказывает, что она неверна. Затем найдите способ получить эту информацию эффективным образом, сделайте выводы и двигайтесь дальше, пока, наконец, вы не сможете осудить виновного.

И иногда вы понимаете, что все факты и признаки, необходимые для выявления виновного, уже ждали вас перед вами полчаса назад. Хотя это и раздражает, это одна из самых интересных частей, потому что если вы критически оцените свои действия и ошибки, вы сможете учиться и становиться лучше . Задайте себе такие вопросы, как:

• Как я мог избежать этой пустой траты времени?
• Что я упустил в первую очередь и почему?
• На какие непроверенные и / или неправильные предположения я опирался?

Это будет тренировать ваши способности. Это также разовьет ваш инстинкт инстинкта , так что со временем вы научитесь автоматически замечать все те незначительные вещи, которые слишком легко упускать из виду, что приведет вас к правильному ответу. В конце концов, это все о преднамеренной практике .

Не в последнюю очередь всегда помните, чему нас учил Шерлок Холмс: когда вы устраняете невозможное, все, что остается, каким бы невероятным оно ни было, должно быть правдой.

Что мне нужно сделать, чтобы помочь моему, по-видимому, ограниченному воображению придумать способы, которыми мой проект мог быть сломан?

Пусть история будет вашим проводником. Если ваш проект хорошо управляется, у вас должна быть база данных каждой ошибки, которая когда-либо была исправлена ​​в продукте, вместе с анализом того, как ошибка была обнаружена, как она была воспроизведена, как она была проанализирована и как она была исправлена. Это не база данных только для записи. Прочитайте базу данных , и очень скоро ошибки таксономии начнут происходить с вами.

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

Поэтому вместо того, чтобы пытаться воспроизвести и исправить конкретный дефект, я полагаю, что вы спрашиваете о том, чтобы придумать новые тесты, которые вы могли бы использовать для исследования продукта, например, чтобы выяснить, работает ли продукт в таких условиях: что произойдет, если я введу специальные символы в нашу зарегистрируйте пароль страницы, или что произойдет, если я принудительно закрою программу во время ее записи в базу данных. Эти случаи действительно трудно придумать.

За последние 10 лет разработка программного обеспечения (Agile / XP / TDD и т. Д.) Пришла к выводу, что он отвечает только явным требованиям, а затем объявляет, что функция завершена, и не находит всевозможных способов что-то сломать (возможны исключения, если вы работая на НАСА или занимаясь защитой белой шляпы, но даже в этом случае необходимо предусмотреть такие условия в критериях приемлемости пользовательской истории).

Поэтому, если ваши функции явно указывают в качестве критериев приемлемости то, что нужно делать системе, например, как обрабатывать ввод, его характеристики производительности, действия рабочего процесса пользователя и т. Д., У вас есть полный список того, что тесты должны проверять. Тестирование должно быть выполнено, чтобы проверить, что требования были выполнены, и лучший способ сделать это - явно перечислить все ваши требования. Взгляните на Agile Test Quadrants .

Некоторые люди рекомендуют, чтобы эти тесты были явным заявлением о требованиях, которые должны быть написаны перед кодом, т.е. Test First (или Test Driven Development).

Тем не менее, я ценю, что вы не похожи на то, что вы рассматриваете новый проект, в котором вы можете установить свои собственные лучшие практики разработки до того, как вы начнете, и вместо этого вы приходите после того, как программное обеспечение написано, и вас просят «протестировать». Это действительно более сложная задача, но применяются те же принципы, что вы можете протестировать ее, только если знаете, что она должна была делать. Если нет исчерпывающего списка требований, которые были выполнены командой разработчиков, чтобы задавать вопросы, то лучший способ - это задавать вопросы. В зависимости от вашей команды это может потребоваться сделать деликатно, поскольку люди, которые явно не указали свои требования перед созданием программной системы, не любят напоминать о том, что они упустили, но это важно для хорошего выполнения этой задачи.

Как только вы найдете требование - оно должно быть надежным / оно должно быть безопасным, затем попытайтесь копать глубже и выяснить, насколько оно должно быть безопасным или насколько допустим сбой, всегда есть предел, не у многих людей есть подтверждение АНБ. уровень безопасности в качестве требования для их применения или хотел бы заплатить за это. Чем больше вы копаете, тем яснее должны быть данные о том, от каких типов атак безопасности вам нужно защищаться или от которых вы легко пользуетесь. Некоторые знания предметной области будут полезны в области безопасности, дизайна, производительности и т. Д., Где вы можете задать еще больше вопросов экспертам, которых вы можете найти в вашей команде, или здесь, на SE, или в google / books.