Из Википедии, бесплатной энциклопедии
  (Перенаправлено из теста на работоспособность )
Перейти к навигации Перейти к поиску

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

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

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

Математический [ править ]

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

  • Если попытаться возвести в квадрат 738 и вычислить 54 464, быстрая проверка работоспособности могла бы показать, что этот результат не может быть правдой. Считают, что700 <738, еще 700 2 = 7 2 × 100 2 = 490 000> 54 464.Поскольку возведение в квадрат положительных целых чисел сохраняет их неравенство , результат не может быть истинным, и поэтому вычисленный результат неверен. Правильный ответ,738 2 = 544 644, более чем в 10 раз превышает 54 464 человека.
  • В умножении, 918 × 155не 142 135, так как 918 делится на три, а 142 135 - нет (цифры в сумме дают 16, а не делятся на три ). Кроме того, продукт должен заканчиваться той же цифрой, что и произведение конечных цифр:8 × 5 = 40, но 142 135 не оканчивается на «0», как «40», в то время как правильный ответ: 918 × 155 = 142290. Еще более быстрая проверка состоит в том, что произведение четных и нечетных чисел является четным, а 142 135 - нечетным.

Физический [ править ]

Разработка программного обеспечения [ править ]

При разработке программного обеспечения проверка работоспособности (форма тестирования программного обеспечения, которая предлагает «быстрое, широкое и поверхностное тестирование» [1] ) оценивает результат подмножества функциональных возможностей приложения, чтобы определить, возможно ли и целесообразно продолжить дальнейшее тестирование. всего приложения. [2] Тесты на вменяемость могут иногда использоваться как взаимозаменяемые с тестами на дым [3], поскольку оба термина обозначают тесты, которые определяют, возможно ли и разумно ли это.чтобы продолжить тестирование дальше. С другой стороны, иногда делается различие, что дымовой тест - это неполный тест, который устанавливает, работают ли наиболее важные функции программы, прежде чем приступить к дальнейшему тестированию, тогда как тест на работоспособность относится к тому, есть ли конкретная функция, такая как конкретная ошибка fix работает, как ожидалось, без тестирования более широкой функциональности программного обеспечения. [ необходима цитата ] Другими словами, тест на работоспособность определяет, правильно ли работает предполагаемый результат изменения кода, в то время как дымовой тест гарантирует, что в процессе ничего важного не было нарушено. Тестирование работоспособности и дымовое тестирование позволяют избежать потери времени и усилий, быстро определяя, является ли приложение слишком некорректным, чтобы заслужить более тщательное тестирование QA., но требует дополнительной отладки разработчика .

Группы здравомыслия испытаний часто поставляются вместе автоматизированного модульное тестирование функций, библиотеки или приложений до начала слияния коды разработки в тестировании или магистральное управление версиями филиала , [4] для автоматизированного здания , [5] или для непрерывной интеграции и непрерывного развертывания . [6]

Другое распространенное использование проверки работоспособности - это обозначение проверок, которые выполняются в программном коде, обычно для аргументов функций или возвращаемых от них данных, чтобы увидеть, можно ли считать ответы правильными. Чем сложнее процедура, тем важнее проверить ее реакцию. Тривиальный случай - это проверка, показывает ли возвращаемое значение функции успех или неудачу, и, следовательно, прекращение дальнейшей обработки в случае неудачи. Это возвращаемое значение на самом деле часто является результатом проверки работоспособности. Например, если функция попыталась открыть файл, записать в него или закрыть файл, можно использовать проверку работоспособности, чтобы убедиться, что она не завершилась ошибкой ни при одном из этих действий - это проверка работоспособности, которую программисты часто игнорируют. [7]

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

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

"Hello, World!" Программа часто используется аналогичным образом как проверка работоспособности среды разработки. Если эта простая программа не может быть скомпилирована или выполнена, вместо сложного сценария, запускающего набор модульных тестов, это доказывает, что поддерживающая среда, скорее всего, имеет проблему конфигурации, которая препятствует компиляции или выполнению любого кода. Но если выполняется «Hello world», то любые проблемы, возникающие с другими программами, скорее всего, могут быть связаны с ошибками в коде этого приложения, а не в среде.

См. Также [ править ]

  • Доказательство концепции
  • Расчет на обратной стороне конверта
  • Тестирование программного обеспечения
  • Мысленный расчет
  • Порядок величины
  • Проблема Ферми
  • Контрольная сумма
  • Алгоритм сертификации

Ссылки [ править ]

  1. ^ Fecko, Mariusz A .; Лотт, Кристофер М. (октябрь 2002 г.). «Уроки, извлеченные из автоматизации тестов для системы поддержки операций» (PDF) . Программное обеспечение - практика и опыт . 32 (15): 1485–1506. DOI : 10.1002 / spe.491 . S2CID  16820529 . Архивировано из оригинального (PDF) 17 июля 2003 года.
  2. ^ Самми, Рабиа; Масуд, Ирам; Джабин, Шунаила (2011). Заин, Ясни Мохамад; Ван Мохд, Ван Масери bt; Эль-Кавасме, Эйас (ред.). «Рамки для обеспечения качества процесса проверки на вменяемость». Программная инженерия и компьютерные системы . Коммуникации в компьютерных и информационных науках. Берлин, Гейдельберг: Springer. 181 : 143–150. DOI : 10.1007 / 978-3-642-22203-0_13 . ISBN 978-3-642-22203-0.
  3. ^ ISTQB® Glossary for the International Software Testing Qualification Board® квалификационная схема тестирования программного обеспечения, ISTQB Glossary International Software Testing Qualification Board
  4. ^ http://webhotel4.ruc.dk/~nielsj/research/publications/freebsd.pdf
  5. ^ Хасан, А.Е. и Чжан, К. 2006. Использование деревьев решений для прогнозирования результатов сертификации сборки . В материалах 21-й международной конференции IEEE / ACM по автоматизированной разработке программного обеспечения (18–22 сентября 2006 г.). Автоматизированная разработка программного обеспечения. Компьютерное общество IEEE, Вашингтон, округ Колумбия, 189–198.
  6. ^ http://jitm.ubalt.edu/XXIX-2/article4.pdf
  7. ↑ Дарвин, Ян Ф. (январь 1991 г.). Проверка программ на языке C с помощью линта (1-е изд., С незначительными правками. Ред.). Ньютон, Массачусетс: O'Reilly & Associates. п. 19. ISBN 0-937175-30-7. Проверено 7 октября 2014 года . Распространенная привычка программирования - игнорировать возвращаемое значение из fprintf (stderr, ...