Краевой случай

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

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

Некоторые распространенные причины крайних случаев ^[1] являются:

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

Некоторые основные примеры крайних случаев включают в себя:

Длинное имя пользователя в приложении переполняется и отображается неправильно.
Система бронирования неправильно обрабатывает бронирование в високосный день (29 февраля).

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

Программная инженерия

В программировании крайний случай обычно включает входные значения, которые требуют специальной обработки в алгоритме компьютерной программы. В качестве меры проверки поведения компьютерных программ в таких случаях модульные тесты обычно создаются ; они проверяют граничные условия алгоритма, функции или метода . Ряд краевых случаев вокруг каждой «границы» можно использовать для обеспечения разумного покрытия и уверенности, используя предположение, что, если он ведет себя правильно на краях, он должен вести себя и везде. ^[2]

Например, функцию деления двух чисел можно протестировать, используя как очень большие, так и очень маленькие числа. Это предполагает, что если это работает для обоих концов спектра магнитуд, то оно должно работать правильно и между ними. ^[3]

Программисты также могут создавать интеграционные тесты для решения крайних случаев, не охватываемых модульными тестами. ^[4] Эти тесты охватывают случаи, которые возникают только при тестировании системы в целом. Например, хотя модульный тест может гарантировать, что функция правильно вычисляет результат, интеграционный тест гарантирует, что эта функция работает правильно при интеграции с базой данных или внешним API . Эти тесты особенно актуальны с ростом сложности распределенных систем , микросервисов и устройств Интернета вещей (IoT) . В частности, тестирование микросервисов становится сложной задачей, поскольку интеграционные тесты могут не охватывать все конечные точки микросервисов, что приводит к нераскрытым крайним случаям. ^[5]

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

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

См. также

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

Ссылки

^ Берам, Шехаб (3 августа 2023 г.). «Что такое крайний случай? Имеются в виду примеры в разработке программного обеспечения» . Блог LogRocket . Проверено 24 октября 2023 г.
^ Циммерман, Джош (2012). «Модульное тестирование» (PDF) . Принципы императивных вычислений . cs.cmu.edu . Проверено 16 января 2014 г.
^ Чо, Шинил (октябрь 2018 г.), «Преобразование Фурье» , Преобразование Фурье и его приложения с использованием Microsoft EXCEL® , IOP Publishing, doi : 10.1088/978-1-64327-286-3ch2 , ISBN 978-1-64327-286-3 , S2CID 210754571 , получено 17 февраля 2022 г.
^ Хориков, Владимир (2019). Модульное тестирование: принципы, практика и шаблоны . Публикации Мэннинга. стр. 188–190. ISBN 978-1617296277 .
^ Хоссейн, штат Мэриленд Деловар; Султана, Тангина; Ахтер, Шармен; Хоссейн, штат Мэриленд Имтиаз; Чт, Нго Тьен; Хюинь, Луан НТ; Ли, Га-Вон; Ха, Ый-Нам (23 июня 2023 г.). «Роль микросервисного подхода в периферийных вычислениях: возможности, проблемы и направления исследований» . ИКТ Экспресс . дои : 10.1016/j.icte.2023.06.006 . ISSN 2405-9595 .

Эта статья по инженерной тематике незавершена . Вы можете помочь Википедии, расширив ее .

[1] Берам, Шехаб (3 августа 2023 г.). «Что такое крайний случай? Имеются в виду примеры в разработке программного обеспечения» . Блог LogRocket . Проверено 24 октября 2023 г.

[2] Циммерман, Джош (2012). «Модульное тестирование» (PDF) . Принципы императивных вычислений . cs.cmu.edu . Проверено 16 января 2014 г.

[3] Чо, Шинил (октябрь 2018 г.), «Преобразование Фурье» , Преобразование Фурье и его приложения с использованием Microsoft EXCEL® , IOP Publishing, doi : 10.1088/978-1-64327-286-3ch2 , ISBN 978-1-64327-286-3 , S2CID 210754571 , получено 17 февраля 2022 г.

[4] Хориков, Владимир (2019). Модульное тестирование: принципы, практика и шаблоны . Публикации Мэннинга. стр. 188–190. ISBN 978-1617296277 .

[5] Хоссейн, штат Мэриленд Деловар; Султана, Тангина; Ахтер, Шармен; Хоссейн, штат Мэриленд Имтиаз; Чт, Нго Тьен; Хюинь, Луан НТ; Ли, Га-Вон; Ха, Ый-Нам (23 июня 2023 г.). «Роль микросервисного подхода в периферийных вычислениях: возможности, проблемы и направления исследований» . ИКТ Экспресс . дои : 10.1016/j.icte.2023.06.006 . ISSN 2405-9595 .

[1]

[2]

[3]

[4]

[5]