Обновлено: 13 октября 2026
Данные программного обеспечения тестируют, проверяя их точность, полноту, целостность и обработку в разных сценариях.
Такая проверка помогает выявить ошибки в вводе, хранении и передаче данных до того, как они повлияют на работу приложения. Разберём, какие проверки подходят для разных типов данных и как включить их в процесс тестирования.
| Сценарий | Что подать программе | Что зафиксировать |
|---|---|---|
| Обычная работа | Корректное ожидаемое значение | Ожидаемый результат |
| Граничный случай | Значение у границы допустимого диапазона | Допустима ли обработка |
| Нестандартный ввод | Новые или необычные данные | Реакцию программы |
| Некорректный ввод | Значение неподходящего типа или формата | Сообщение об ошибке или отказ |
- 07.07.2020 дата приказа Минздрава России № 686н
- 30.06.2020 дата приказа Минздрава России № 661н
- 01.01.2021 дата вступления в силу приказа № 661н
- 27.12.2012 дата Постановления Правительства РФ № 1416
Что называют данными программного обеспечения при тестировании?
Тестовые данные — это входные значения, которые передают программе во время проверки, чтобы увидеть, как она их обработает и какой результат выдаст. Их специально составляют для теста или подбирают с учётом среды, в которой запускают программу.
Вход и ожидаемый результат
В веб-форме тестовыми данными будет содержимое конкретного поля: например, текст в поле имени или адрес электронной почты. В расчётной программе входом служат значения, из которых она должна получить результат; проверка сопоставляет фактический ответ с ожидаемым.
Тестировать стоит не только обычный, заранее предусмотренный ввод: пустое поле, слишком длинная строка или символы неподходящего типа могут выявить ошибки логики и смысла. Например, форма может неверно обработать пустое поле имени, а расчёт — принять текст вместо числа; такие проверки показывают, насколько корректно программа реагирует на необычные данные.
Как составить набор тестовых данных?
Набор тестовых данных составляют из описания полей, корректных примеров, граничных и ошибочных значений и ожидаемого результата для каждой записи. Например, для формы оплаты укажите тип поля «сумма» и валюту, а для даты — допустимый формат и правила проверки календарной даты; конкретные ограничения должны совпадать с требованиями приложения.
Обычные и нестандартные случаи
Для каждого поля подготовьте обычный допустимый ввод и отдельные варианты, способные выявить ошибки: пустое значение, неверный тип, формат или значение за установленной границей. Если число должно быть целым от 1 до 100, проверьте 1 и 100, а также 0, 101 и текст вместо числа. Для даты полезно сопоставить корректную календарную дату с невозможной, например 31 февраля.
- Обычная запись: все обязательные поля заполнены значениями допустимого типа.
- Граничная запись: значение равно минимальному или максимальному разрешённому порогу, например 1 или 100.
- Ошибочная запись: отсутствует обязательное поле либо вместо числа передан текст.
Каждой записи назначьте ожидаемое поведение: сохранение результата, понятное сообщение об ошибке или отказ в обработке. Проверяйте набор в той же среде, где запускается тест: конфигурация и условия выполнения могут влиять на создаваемые данные и на поведение программы. Поэтому фиксируйте используемую тестовую среду вместе с набором, чтобы повторный запуск проверял те же сценарии.
Почему новая информация может сломать надёжную программу?
Новая информация может сломать надёжную программу, если в ней проявится логическая или семантическая ошибка, незаметная на привычных входных данных. Устойчивость здесь означает не отсутствие сбоев вообще, а способность корректно обрабатывать сценарии, которые не встречались при первоначальной проверке.
Например, приложение может верно принимать обычное значение поля, но иначе истолковать данные в неожиданном контексте: программа обработает вход без явной ошибки, однако выдаст неверный результат. Такой разрыв возникает, когда тесты проверяют ожидаемые варианты, но не проверяют смысл данных в новых сочетаниях.
Как заметить расхождение
После изменения входных данных повторно запустите набор проверок и сравните ожидаемое поведение с фактическим. Для каждого теста зафиксируйте конкретный вход и ожидаемый результат: например, что приложение должно сделать с новым значением поля. Если результат отличается, это сигнал для проверки логики обработки, даже когда программа завершилась без сбоя.
Как медицинские правила относятся к программному обеспечению?
Для программного обеспечения, являющегося медицинским изделием, отдельное разрешение на ввоз не требуется, но его регистрация регулируется правилами для медицинских изделий. Поэтому при проверке такого ПО важно различать ввоз продукта и его регистрацию: отсутствие требования о разрешении на ввоз не отменяет регистрации.
Ввоз и регистрация
Постановление Правительства РФ от 27.12.2012 № 1416 устанавливает правила регистрации медицинских изделий. Правило, обозначенное как пункт 20, введено Приказом Минздрава России от 07.07.2020 № 686н.
Приказ Минздрава России от 30.06.2020 № 661н вступил в силу 01.01.2021. При оценке медицинского ПО эти нормативные акты следует учитывать раздельно: № 1416 относится к регистрации медицинских изделий, а отдельное разрешение на ввоз ПО, которое само является медицинским изделием, не требуется.
Когда тестовые данные не дают надёжной проверки?
Тестовые данные не дают надёжной проверки, если проверяют только привычные корректные значения, не задают ожидаемый результат или не соответствуют среде запуска: в таких условиях нельзя уверенно оценить реакцию программы на нестандартный ввод.
Частые ошибки
Набор из корректных значений — например, нескольких обычных строк и положительных чисел — показывает работу программы лишь в знакомом сценарии. Чтобы проверить границы поведения, добавляют входы с пустым полем, необычным форматом или значением за допустимым пределом; иначе логические ошибки могут обнаружиться только при появлении новых данных.
Ожидаемый результат нужно записать рядом с каждым тестом: для входа «пустая строка» это может быть конкретное сообщение об ошибке или отказ принять значение. Без такого критерия результат запуска нельзя однозначно признать правильным. Также важно указывать среду выполнения: данные, подготовленные для одной конфигурации, могут вести себя иначе в другой из-за различий в настройках или способе запуска.
- Только обычные входы: добавьте пустые, нестандартно оформленные и граничные значения.
- Нет ожидаемого результата: заранее определите, что программа должна вывести или сделать для каждого входа.
- Другая тестовая среда: фиксируйте условия запуска и повторяйте проверку в целевой среде.
- Медицинское программное изделие: соответствие медицинским требованиям не заменяет тестирования поведения на конкретных входных данных; проверяйте оба аспекта отдельно.
Частые вопросы
Что такое тестовые данные?
Зачем проверять программу на нестандартных данных?
Нужно ли разрешение на ввоз ПО, которое является медицинским изделием?
Какой документ устанавливает правила регистрации медицинских изделий?
Источники
- guru99.com — «Что такое тестовые данные при тестировании программного обеспечения?»
- forinsightsconsultancy.com — «Рынок программного обеспечения для управления архитектурой предприятия»
- forinsightsconsultancy.com — «Размер рынка программного обеспечения для 3D-отслеживания глаз, тенденции, обзор 2025»
- kormed.ru — «Особенности регистрации программного обеспечения — Факультет Медицинского Права»
Путеводитель по теме: «Программное обеспечение»: полное руководство
