Предисловие
Вы когда -нибудь чувствовали, что в мире были призраки, когда вы настраиваете определенный кусок кода?
У вас когда-нибудь была проблема в регулировании API, вы всегда чувствуете, что это проблема при вызове сторонних интерфейсов, или документация неверна?
Вы когда -нибудь чувствовали, что источником проблемы был неправильный способ использовать ее?
Вы всегда чувствовали, что документация или среда не совпадают при установке услуги?
Верю в процесс и метод, и никогда не вводятся в заблуждение результатами .........
Обзор
Модульный код часто похож на исследование дела, но важность результата отличается. Полиция расследует дело, чтобы люди были в безопасности, в то время как наш модульный код предназначен для стабильности системы. Таким образом, мы не должны ошибочно обвинять какую -либо часть кода и программы, чтобы не быть наказанным необоснованным.
Следующие методы процесса поступают из личного резюме. С личной точки зрения, некоторые из методов предыдущих поколений были накапливаются с помощью долгосрочного опыта, и, конечно, они высоко ссылаются и теоретические. Как личные методы, они могут быть более подходящими для DS, таких как мы.
Метод испытаний
Процедурный режим кода
Первое, на что можно обратить внимание на режим кодирования, - это процесс. Вы должны прояснить идею конечного результата, то есть процесс совершения преступления и выполнять шаг за шагом в процессе преступления, чтобы получить результат преступления. Во время анализа процесса преступления все сомнения должны быть помечены (то есть информация о журнале, упомянутая в коде). После такого процесса анализа выполняется тест черного ящика, добавляется вход, и результаты подтверждаются. Наконец, проверьте свое суждение на основе маркировки каждого шага, чтобы найти причину.
Приведенное выше решение является процедурным режимом. Преимущества этого метода являются самоочевидными. Вы можете напрямую проанализировать весь процесс с помощью теста, но этот метод занимает много времени, и можно уточнить свою собственную логику кода, но трудно понять логический код других людей.
Модульный тестовый режим
Основная цель единичного тестирования состоит в том, чтобы обеспечить нормальную работу функции, класса или функционального модуля, включая тестирование и проверку его ненормальных ситуаций. Как программисты, наиболее любимым методом проверки является «накапливание» (значение вождения с ворсом заключается в предоставлении фальшивых данных по умолчанию). Этот метод очень удобен для корректировки, но один недостаток заключается в том, что его нельзя использовать снова, потому что после нашей проверки нормальная, многие разработчики будут комментировать или удалять его. Поэтому, если мы закончим развитие в среде разработки, но мы надеемся, что при тестировании проверки окружающей среды мы должны переписать другую логику вождения. Тогда, таким образом, это будет еще более хлопотно, когда мы находимся в Интернете. Поскольку есть так много неудобств, вы можете попробовать следующие методы.
Добавьте класс модульного тестирования. Этот класс должен контролировать свои разрешения и может быть выполнен только через фона или командную строку. Функция этого класса состоит в том, чтобы обнаружить логику ключей системы и сделать соответствующие результаты результатов тестового выхода. Вы должны верить, что все классы интерфейса могут быть проверены через классы модульных испытаний. Много раз программисты спрашивают, должны ли мы это сделать? На самом деле, нам действительно нужно это сделать. В конце концов, многие тесты теперь проведены в тестах черного ящика.
Этот модульный метод подходит в процессе разработки и может гарантировать, что наш текущий сетевой код работает нормально после его выпуска. Я надеюсь, что все также передадут этот процесс на стадию разработки при планировании времени разработки.
Метод быстрого позиционирования
Первые два столь сложных процесса слишком идеальны? Мой код составляет всего 100 строк, и система не сложна. Если это так, то быстро выполните анализ позиционирования. Много раз я сталкиваюсь с этим
1. Вход нормальный, выход ненормальный;
2. Вход нормальный, логика является ненормальной, а выход ненормальный;
3. Вход ненормальный, логика нормальная, а выход норм;
4. Входное исключение, логическое исключение, вывод Нет.
Во время моего личного процесса развития я часто сталкиваюсь с некоторыми проблемами выше. Например, в процессе разработки node.js я встретил string.length и сказал, что для строки нет никакого метода длины. В то время я был озадачен и спросил себя, почему у других струн есть методы длины, и почему такого метода нет? Многие студенты, вероятно, знают, что проблема в том, что эта строка вообще не является строкой, а просто в том, что вы идеализировали ее как строку самостоятельно, что означает, что есть проблема с тем, что вы вводите. Тогда лучший способ найти эту проблему - это распечатать ввод и распечатать вывод.
Возможно, другие программы не так просты, но самая основная вещь - сделать входные и выходные суждения по функциям, которые сталкиваются с исключениями в основной функции, чтобы они могли быстро найти.
Помните: не выбирайте это из контекста и будьте самодовольными.
Вышеуказанные методы и процедуры суммированы только на основе PHP или узла. Там могут быть сходства или различия в C & C ++. Если вам это не нравится, пожалуйста, берегите это.