Поскольку мы все больше и больше полагаемся на вычисления, включая очень важные задачи повседневной жизни, мне было просто интересно, как тестируются эти жизненно важные компоненты.
С технической точки зрения, как тестируются компиляторы и ассемблеры? (Я полагаю, это связано с проблемой остановки !!)
programming-practices
compiler
theory
Судип Бхандари
источник
источник
Ответы:
Вы не можете быть уверены, но вы просто предполагаете, что это так, пока не обнаружите, что это не так. За эти годы было много ошибок в компиляторах и оборудовании.
Способ их тестирования, например, компилятором, заключается в том, что они очень узко и жестко определены, тщательно написаны, а затем протестированы с помощью огромного набора тестов для проверки правильности. Добавьте к этому широкую пользовательскую базу компилятора, и будут обнаружены и обнаружены дополнительные ошибки. Сравнительно, у приложения планирования назначения стоматолога намного меньше пользователей, и еще меньше, которые способны обнаруживать дефекты.
SQLite содержит около 73 тысяч строк кода, а набор тестов - около 91378 тысяч строк кода, что в 1250 раз больше, чем самого SQLite. Я ожидаю, что компиляторы и другие основные инструменты имеют аналогичные соотношения. Современные процессоры в основном разработаны с использованием программного обеспечения, с использованием языков описания аппаратного обеспечения, таких как Verilog или VHDL, и на них также выполняются тесты программного обеспечения, а также специализированные выводы ввода-вывода для проведения самотестирования на месте производства.
В конечном счете, это игра с вероятностью, и повторное и широко охватывающее тестирование позволяет снизить вероятность появления дефектов до приемлемо низкого уровня, как и в случае другого программного проекта.
источник
С точки зрения непрофессионала:
Нижняя линия:
Я бы сказал, пойти на ООП ( O ld, O pen и P opular). Я только что составил эту аббревиатуру.
источник
Это черепахи все время вниз.
Нет ничего определенного У вас нет выбора, кроме как рассчитывать на рейтинг доверия.
Вы можете думать об этом как о стеке: Math> Physics> Hardware> Firmware> Operating System> Assembler / Compiler / etc
На каждом уровне у вас есть тесты, которые вы можете выполнить, чтобы улучшить свой рейтинг доверия. Некоторые из этих тестов имеют качество формальных доказательств, некоторые из них основаны на наблюдениях, большинство из них являются комбинацией обоих.
Сложная часть - это распутывание рекурсии в некоторых из этих тестов, потому что мы используем программы, чтобы делать доказательства и анализ наблюдений сейчас, когда это стало слишком трудно сделать это вручную.
В конечном счете, хотя ответ заключается в том, что вы пробуете все, что можете придумать. Статический анализ, фаззинг, симуляция, работа с целенаправленно выбранными экстремальными или случайными входами, запуск / отображение каждого пути управления, формальные доказательства и т. Д. По сути, ваша цель в тестировании всегда должна заключаться в том, чтобы сделать все возможное, чтобы доказать, что ваш продукт (например, теория / чип / программа) не работает как задумано. Если вы прилагаете искренние усилия и по-прежнему терпите неудачу, то вам разрешается повысить рейтинг уверенности в правильности вашего продукта.
В лучшем случае, тестирование - это процесс принятия полурешений, означающий, что при наличии ошибки вы в конечном итоге найдете ее, но никогда не сможете быть уверены, что нашли ее все. Даже с формально проверенным программным обеспечением вы все еще полагаетесь на физику, инструменты, используемые для формальных доказательств, и на то, что то, что вы доказали, необходимо и достаточно для того, чтобы ваша программа делала то, что (часто субъективно) «предназначено». Это не говоря уже о всех других компонентах, которые вы используете, которые не имеют формальных доказательств.
источник
Это «опасный» вопрос для новых разработчиков, потому что они начнут обвинять свои инструменты вместо своего кода (был там, сделал это, видел, что слишком многие делают это). Несмотря на наличие ошибок в компиляторах, средах выполнения, ОС и т. Д., Разработчики должны быть реалистичными и помнить, что до тех пор, пока не появятся свидетельства и модульные тесты, демонстрирующие обратное, ошибка присутствует в вашем коде .
За 25 с лишним лет программирования на C, C ++ и Java я обнаружил:
Все остальные ошибки напрямую связаны с ошибкой или, чаще, с отсутствием понимания того, как работает библиотека. Иногда то, что кажется ошибкой, происходит из-за несовместимости, например, как изменилась структура класса Java, что сломало некоторые библиотеки AOP.
источник
Я думаю, что интересным моментом здесь является то, что в подавляющем большинстве коммерческих лицензий на программное обеспечение (и, действительно, программного обеспечения с открытым исходным кодом) конкретно указано, что вы не можете доверять программному обеспечению.
Из лицензионного соглашения Microsoft Word
По сути, это предложение в лицензии почти для каждого программного обеспечения, которое вы используете, специально говорит вам, что вы не можете доверять программному обеспечению, не говоря уже о используемом компиляторе.
Программное обеспечение похоже на научную теорию, и считается, что оно работает так, как указано, пока оно не работает.
источник
Как автор компилятора для математического языка *, из моего опыта я могу сказать, что теоретически вы не можете. И некоторые из ошибок просто дают неправильные результаты, такие как (из моего списка позора), вычисление
6/3*2
справа6/(3*2)
и вывод 1 без сбоев или бессмысленные ошибки компиляции.Но IMHO, многие компиляторы не имеют столько ошибок, как другие программы, потому что:
test_unit("2+(-2)*(-2+1)*3+1",9);
Для сборщиков, машинных инструкций и т. Д. Вышеизложенное также имеет место; с другой стороны, проверка и валидация при разработке и производстве микросхем имеют гораздо более строгие процессы, поскольку это огромный бизнес: автоматизация электронного проектирования .
Прежде чем приступить к производству, каждый процессор должен быть тщательно протестирован, потому что каждая ошибка стоит почти пару миллионов долларов: при производстве чипов возникают огромные неповторяющиеся производственные затраты. Таким образом, компании тратят много денег и пишут много кода моделирования для своего дизайна перед началом производства, хотя это не дает 100% гарантии, например: ошибка Pentium FDIV.
Короче говоря, очень маловероятно, что в компиляторах, машинных кодах и т. Д. Будут серьезные ошибки.
Мой скромный математический язык *
источник
Безупречный? Они не. Недавно я установил некоторые «обновления», и прошло несколько месяцев (и несколько перепрограммированных разделов кода), прежде чем мой сайт ASP.NET снова заработал должным образом из-за необъяснимых изменений в том, как различные базовые вещи работали или не работали.
Тем не менее, они тестируются, а затем используются многими очень умными, ориентированными на детали, людьми, которые склонны замечать, сообщать и исправлять большинство вещей. Stack Exchange является отличным примером (и улучшением) того, как все люди, использующие эти инструменты, помогают тестировать и анализировать, как работают эти поразительно сложные и низкоуровневые инструменты, по крайней мере, до практического использования.
Но безупречно, нет. Хотя вы также можете увидеть, как люди в Stack Exchange получают впечатляющее представление о деталях производительности, о соответствии стандартам и их причудах, всегда есть недостатки и недостатки, особенно когда разные люди по-разному оценивают недостатки.
источник
Чтобы показать, что основные системы безупречны, вы либо
а) Нужно доказать, что они безупречны
б) сделать исчерпывающий тест
В тестировании программного обеспечения исчерпывающий тест используется только в модульном тестировании некоторых простых функций.
Пример: вы хотите протестировать 8-символьный ввод utf-8 в какое-то поле, вы делаете выбор, чтобы обрезать ввод в 8 раз по сравнению с максимальной длиной 6 utf-8 в байтах, что дает 8 * 6 = 48 байтов, чтобы фактически иметь конечное количество возможностей.
Теперь вы можете подумать, что вам нужно только протестировать 1,112,064 действительных кодовых точек каждого из 8 символов, т.е. 1,112,064 ^ 8 (скажем, 10 ^ 48) тестов (что уже вряд ли возможно), но на самом деле вы должны проверить каждое значение каждого из 48 байтов или 256 ^ 48, что составляет около 10 ^ 120, что является такой же сложностью, что и шахматы по сравнению с общим числом атомов во вселенной примерно 10 ^ 80.
Вместо этого вы можете использовать в порядке возрастания усилий, и каждый тест должен охватывать все предыдущие:
а) проверить хороший и плохой образец.
б) покрытие кода, т.е. Попробуйте проверить каждую строку кода, которая относительно проста для большинства кода. Теперь вы можете задаться вопросом, что там за последний 1% кода, который вы не можете протестировать ... ошибки, мертвый код, аппаратные исключения и т. Д.
c) охват пути, тестируются все результаты всех ветвей во всех комбинациях. Теперь вы знаете, почему отдел тестирования ненавидит вас, когда ваши функции содержат более 10 условий. Также вы удивляетесь, почему последние 1% не могут быть протестированы ... некоторые ветки зависят от предыдущих веток.
d) проверка данных, проверка числа образцов с граничным значением, общими проблемными значениями и магическими числами, ноль, -1, 1, мин +/- 1, макс +/- 1, 42, rnd значения. Если это не дает вам покрытия пути, вы знаете, что вы не уловили все значения в своем анализе.
Если вы уже делаете это, вы должны быть готовы к экзамену ISTQB Foundation.
источник