ГОСТ Р 56920—2016
4.95 объемное тестирование (volume testing): Тип тестирования уровня производительности,
проводимогодля оценки способности элемента тестирования обработать определенные объемы дан
ных (обычно равных или близких к максимальным указанным потенциальным возможностям) с точки
зрения потенциальных возможностей пропускной способности, емкости памяти или того и другого.
4.96 тестирование методом «белого ящика» (white box testing): См. термин «тестирование на
основе структуры» согласно 4.45.
5 Понятия тестирования программного обеспечения
5.1 Введение в тестирование программного обеспечения
Необходимость тестирования программного обеспечения может быть продиктована следующи
ми условиями:
- лица, принимающие решения, запрашивают информацию о показателях качества элемента(ов)
тестирования;
- проверяемый(ые) элемент(ы) тестирования не всегда делает то, что от него (них) ожидается:
- необходимо произвести верификацию лроверяемого(ых) элемента(ов) тестирования;
- необходимо произвести валидацию проверяемого(ых) элемента(ов) тестирования и/или
- необходимо провести оценкуэлемента(ов)тестирования по всемужизненному циклу разработ
ки программного обеспечения и систем.
Общеизвестно, что создать совершенное программное обеспечение невозможно. Поэтому прежде
чем программное обеспечение будет передано пользователям, его необходимо протестировать, что
бы в производстве программногообеспечения снизить рискошибок, оказывающих негативное влияние
на его функционирование. В равной степени необходимо обеспечить качественное выполнение тести
рования программного обеспечения.
Ошибки или допущенные дефекты обычно имеют место и неизбежны. Опечатка или ошибка, сде
ланная человеком, приводит к возникновению дефекта в продукте, над которым человек работает
(например, спецификация требований или компонент программногообеспечения). Дефект неоказыва
ет влияния на функционирование программного обеспечения до тех пор. пока он не будет обнаружен
при эксплуатации программного обеспечения. Однако если дефект обнаружен в реальных условиях,
когда продукт уже сдан в эксплуатацию, то это может привести к тому, что продукт не будет удовлетво
рять законным потребностям пользователя. Последствия программной ошибки для пользователя
могут быть серьезны. Например, дефект может поставить под угрозу бизнес-репутацию, государствен
ную безопасность, бизнес-экономическую жизнеспособность, бизнес или безопасность пользователей
и/или окружающую среду.
Динамическое тестирование является необходимым, но не достаточным условием, чтобы обес
печить приемлемую уверенность в том. что программное обеспечение будет функционировать, как
задумано. В сочетании с эффективными действиями динамического тестирования необходимо произ
вести дополнительные действия статического тестирования, такие как экспертная оценка и статичес
кий анализ.
Основными целями тестирования являются: предоставление информации о качестве элемента
тестирования и любых остаточных рисках относительно того, до какой степени элемент тестирования
был проверен; обнаружениедефектов вэлементе тестированиядо его передачи в эксплуатацию; смяг
чение рисков получения продукта низкого качества заинтересованными сторонами.
Вышеупомянутая информация может использоваться в нескольких целях, включая:
- улучшение элемента тестирования путем устранения дефектов;
- улучшение управленческих решений, предоставляя как основание для решений информацию о
качестве и рисках;
- улучшение процессов в организации, особо выделяя процессы, которые позволяют дефектам
возникать н/или оставаться скрытыми там, где они могут быть обнаружены.
Качество продукта имеет много аспектов, включая соответствие спецификациям, отсутствие
дефектов и удовлетворение продукта требованиям пользователей. В ИСО/МЭК 25010 «Модели качест ва
систем и программного обеспечения» определено восемь показателей качества, которые могут быть
измерены или оценены путем тестирования (см. 5.5.3).
Тестирование программного обеспечения должно быть направлено на предоставление инфор
мации о программном продукте и нахождение максимально возможного числа дефектов на возможно
ранних этапах процесса разработки при заданных ограничениях стоимости и графика разработки.
9