Тестирование программ что это

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

Цели и этапы тестирования ПО

Цели тестирования:

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

Этапы тестирования:

1. Анализ
2. Разработка стратегии тестирования и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Градации дефектов и типы тестирования ПО

Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).

Тестировщик (QA) — кто это? Какие бывают типы тестирования?

Жизненный цикл разработки ПО:

• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

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

Градация cерьезности дефекта (Severity):

• Блокирующая (Blocker) — Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
• Критическая (Critical) — Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
• Значительная (Major) — Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
• Незначительная (Minor) — Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
• Тривиальная (Trivial) — Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация приоритета дефекта (Priority):

Тестировщик с нуля / Урок 1 / Что такое тестирование по

• Высокий (High) — Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
• Средний (Medium) — Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
• Низкий (Low) — Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Типы тестирования ПО:

• Тестирование типа «белый ящик» проверяет внутренние структуры и модули, игнорирует ожидаемую функциональность для конечных пользователей. Это может быть тестирование API, внесение неисправностей (fault injection), модульное тестирование, интеграционное тестирование.
• Тестирование типа «чёрный ящик» больше интересуется тем, что делает ПО, а не как делает. Это означает, что тестировщики не обязаны ни разбираться в объекте тестирования, ни понимать, как он работает под капотом. Такой тип тестирования нацелен на конечных пользователей, их опыт взаимодействия с видимым интерфейсом. К «чёрным ящикам» относится тестирование на основе моделей, тестирование способов использования, таблицы переходов состояний, спецификационное тестирование и т. д.
• Тестирование типа «серый ящик» проектируется со знанием программных алгоритмов и структур данных (белый ящик), но выполняется на пользовательском уровне (чёрный ящик). Сюда относится регрессионное тестирование и шаблонное тестирование (pattern testing).

Документация и планирование тестирования ПО

Тест план (Test plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Отвечает на вопросы:

• Что надо тестировать?
• Что будете тестировать?
• Как будете тестировать?
• Когда будете тестировать?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию. Для того, чтобы убедиться, что требование полностью удовлетворяется, может понадобиться несколько тест-кейсов.

Для полного тестирования всех требований, предъявляемых к приложению, должен быть создан/выполнен по меньшей мере один тест-кейс для каждого требования. Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс. Некоторые методологии (например, RUP) рекомендуют создавать по меньшей мере два тест-кейса для каждого требования. Один из них должен выполнять позитивное тестирование, другой — негативное.

Чек-лист (Check list) — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.
Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании.

Тест дизайн (Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Таблица принятия решений (Decision table) — великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.

Виды тестирования ПО

Модульное тестирование (Unit testing)

— это тестирование отдельных компонентов приложения.

В приложениях это реализуются в виде Unit тестов отдельных фрагментов кода: функций и классов.

Функциональное тестирование (Functional testing)

— это тип тестирования рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Функциональные тесты немного сходны с приемочными. Но в отличие от последних — не требуется запускать веб-сервер. На данном этапе происходит эмуляция переменных запроса (GET, POST и т.д.) к веб-приложению. Функциональное тестирование широко применяется для тестирования Restfull API сервисов.

Приемочное тестирование (Acceptance testing)

— это формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приёмки.

В веб-приложениях обычно эммулируется работа пользователя с сайтом через веб-браузер. При приемочном автоматизированном тестировании используют инструмент Selenium (Selenium — это инструмент для тестирования Web-приложений.) с WebDriver (WebDriver — это набор «биндингов» к разным языкам (C#, Java), позволяющий отдавать различные команды Selenium).

Тестирование безопасности

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

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

Нагрузочное тестирование

— это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

Для нагрузочно тестирования обычно использьют различное ПО которое может эмулировать высокую нагрузку на приложение, а так же может эмулировать поведение пользователя в приложении.

Регрессионное тестирование

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

Источник: blog-programmista.ru

Виды и типы тестирования: подробный разбор

Какой была ваша первая зарплата в QA и как вы искали первую работу? Мега-обсуждение в нашем телеграм-канале.

• Функциональные виды
• Нефункциональные виды
• Общий список

Сначала картинки

Важнейшие типы и виды тестирования, в простой форме:

Еще более сложная классификация (кликабельно):

Виды тестирования удобно делить на две группы: функциональное и нефункциональное.

(В некоторых классификациях встречается еще третий тип — эксплуатационное тестирование, выполняемое при сопровождении уже работающего продукта).

Функциональное тестирование — виды

Быстрое определение: это тестирование основных, «рабочих» функций приложения/сайта; ради этих функций приложение, собственно, создавалось.

Более общее определение, с точки зрения QA: проверка выполнения функциональных требований к приложению, зафиксированных ранее.

Тестируется работоспособность в целом и каждая функция отдельно: выполнены ли требования, достигнут ли целевой результат?

В «функциональную группу» входят такие виды (типы):

• Юнит-тестирование (модульное)
• Интеграционное
• Сквозное (E2E, end-to-end)
• Smoke (смок-тестирование)
• Санитарное (sanity)
• Регрессионное
• Приемочное (приемка пользователями)
• Системное
• Тестирование интерфейса

Функциональные тесты могут выполняться вручную, или могут вполне успешно автоматизироваться.

Часто применяемые инструменты функционального тестирования, с которые тестировщик должен уметь работать (или хотя бы ознакомиться поверхностно):

Selenium — инструмент тестировщика №1, овладеть им — кажется, решающий момент в трудоустройстве, по крайней мере сейчас, в 2023 году. Стремящийся стать QA-джуном должен знать (как минимум), о чем спрашивают на собеседовании по Selenium.

Далее рассмотрим типы нефункционального тестирования.

Нефункциональное тестирование — виды

Это типы тестирования, проверяющие нефункциональные аспекты приложения, а именно производителность, надежность, безопасность, юзабельность (то есть удобство пользования).

Обычно такое тестирование делают после функционального, как менее приоритетное (но тоже важное). Оно может значительно улучшить качество приложения, объективно и субъективно, возвысить его над конкурентами, а не только «отполировать внешний вид», как было принято в предыдущие десятилетия. Нефункциональное — это не о том, работает ли софт или нет, это о том, КАК он работает и как он выглядит.

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

Виды (типы) нефункционального тестирования:

• Тестирование производительности
• Нагрузочное
• Безопасности
• Тестирование на отказ
• Совместимости
• Юзабилити-тестирование
• Масштабируемости
• Объемное тестирование
• Стресс-тестирование
• Удобства сопровождения
• Совместимости
• Общей эффективности
• Надежности
• Выносливости
• Тестирование восстановления после катастрофического отказа
• Тестирование локализации и интернационализации

Далее перечислены основные типы (виды) тестирования (без деления на функциональные/нефункциональные).

Типы тестирования: общий список

Юнит-тестирование

Другое название, менее распространенное, но более интуитивное — «модульное тестирование». Также встречается название «компонентное тестирование».

Проверка по отдельности каждого модуля (юнита). Она требует знания языка программирования, на котором написан код приложения, а также хорошего знания его архитектуры, «внутренностей». По этой причине, в большинстве случаев юнит-тесты пишут разработчики — создатели приложения.

Интеграционное тестирование

После интеграции модулей наступает черед интеграционного тестирования. Это проверка, как интегрированные, то есть уже соединенные в целостное приложение модули «сработались вместе». Таких тестов уже меньше, чем модульных (подробнее о пирамиде тестирования — здесь).

Часто используемые инструменты юнит- и интеграционного тестирования:

Сквозное тестирование

E2E-тестирование это подтип функционального, проверка всей системы «из конца в конец», end-to-end, поэтому такое название. Таких тестов еще меньше количественно, но они еще сложнее чем интеграционные и тем более модульные (и требуют больше опыта от тестировщика).

Инструменты, которые нужно освоить, чтобы претендовать на позицию E2E-QA:

Тестирование интерфейса

Тестирование GUI — проверка, отвечает ли интерфейс требованиям, изложенным в спецификациях; а также специальным гайдам владельца платформы — например, для мобильных приложений существуют специальные гайды, злостное несоблюдение которых грозит недопуском в магазин приложений, или исключением, если приложение уже там.

Тестирование доступности

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

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

Более подробно о таком специфическом типе тестирования — отдельный материал.

Альфа-тестирование

Поиск всех ошибок и проблем в приложении в целом. Проводится на последнем этапе разработки, и внутри компании (в этом отличие от бета-тестирования). Проводится перед запуском продукта (передачей его заказчику). Цель: удостовериться, что юзер/клиент получит продукт, не содержащий багов.

Альфа-тестирование проводят в девелоперском окружении (а не в реальном пользовательском). Для имитации пользовательского окружения создается виртуальное окружение.

Бета-тестирование

Бета-тестирование проводится после альфа-, и перед запуском продукта. Для бета-тестирования нужно реальное пользовательское окружение. Выбирается ограниченное количество реальных пользователей-«добровольцев» (клиентов), которые, не будучи специалистами в QA, тестируют продукт на свое усмотрение. Затем они дают фидбек, и конструктивную критику, после чего разработчики, при необходимости, вносят изменения в так называемую бета-версию продукта. Далее исправленный и доработанный продукт поступает на релиз, то есть становится доступен всем пользователям.

Ad-hoc-тестирование

Еще называемое интуитивным, поскольку проводится в «интуитивной» манере, на усмотрение тестировщика, без тест-кейсов, планов и другой оформляемой документации. Несистематичность — отличающий признак ад-хок-тестирования.

Хотя искать баги без тест-кейсов может быть сложно, опытный тестировщик легко находит баги таким «свободным поиском», и нередко быстрее, чем «формализованным» способом.

Тестирование совместимости

Направлено на проверку совместимости продукта с операционными системами, браузерами, сетевыми окружениями, аппаратными конфигурациями, и т.п. Приложение должно работать во всех предусмотренных в его документации окружениях.

Например, Windows-приложение должно быть совместимым со всеми распространенными версиями ОС Windows. Если это веб-приложение, оно должно без проблем открываться во всех распространенных браузерах. Android-приложение нужно протестировать во всех распространенных в данный момент версиях ОС Android.

Тестирование обратной совместимости

Проверка того, что новая (обновленная) версия приложения совместима с предыдущими версиями окружения, например операционными системами, в которых работает (или браузерами, в которых открывается веб-приложение).

Часто приложения обновляют, чтобы соответствовать изменившимся стандартам нового окружения, или чтобы «осовременить» общий стиль и вид приложения. Теперь нужно провести тестирование обратной совместимости — ведь пользователи «старой» версии этого окружения, которых может быть очень много, не должны терять возможность пользоваться приложением.

Кроссбраузерное тестирование

Или тестирование совместимости браузеров. Проверка, может ли веб-приложение (сайт) без проблем открываться во всех распространенных версиях браузеров.

Такое тестирование, ввиду его трудоемкости, автоматизируют, применяя такие инструменты:

Тестирование производительности

Оценка общей производительности (продуктивности) приложения, выполняемая как правило при помощи специализированных инструментов, выявляющих проблемы в этой сфере:

Нагрузочное тестирование

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

Часто применяемые нагрузочные инструменты:

Подробный обзор бесплатных инструментов нагрузочного тестирования — здесь.

Тестирование восстановления

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

Регрессионное тестирование

Если система корректируется в процессе создания (что неизбежно), если в ее модули/функции вносятся изменения, то обязательно проверяют, не повлияли ли эти правки на функционирование системы.

Статья о проблемах с «регрессами» — здесь.

Agile-тестирование

Специфический тип QA-тестирования командой, работающей «по эджайлу», то есть с соблюдением так называемого манифеста Agile, и с учетом точки зрения пользователей в первую очередь.

Инструменты Agile QA:

Тестирование API

Как и юнит-тестирование, этот тип относится к так называемому «code level testing», то есть имеет дело непосредственно с исходным кодом приложения. Разница с юнит- в том, что юнит-тесты обычно делают разработчики, а API тестирует QA-команда.

Тестирование черного ящика

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

Тестирование белого ящика

Проверка приложения со знанием его исходного кода и архитектуры.

О черном и белом ящиках, которые ждут Junior QA — здесь.

Тестирование безопасности

Как понятно из названия, такие тесты гарантируют безопасность приложения/сайта; выявляют и предотвращают «дыры» в его подсистеме безопасности. Тестировщики, специализирующиеся на таком тестировании, работают как вручную, так и инструментами:

Юзабилити-тестирование

Оценка (и последующая коррекция) общего удобства пользования приложением/сайтом. Насколько приложение юзабельно, то есть «дружественно к пользователю»?

Разумеется, на это нужно смотреть в первую очередь с точки зрения пользователя, а не члена ИТ-команды, и именно массового, «среднего пользователя»; поэтому к тестированию часто привлекают обычных людей-пользователей, «добровольцев» или за оплату.

Как это делается, и много дополнительной информации по юзабилити, например чеклисты — в нашем большом гайде; Артем Русов одобряет.

Инструменты проверки юзабилити:

Тестирование масштабируемости

Легко ли масштабировать приложение? То есть, легко ли, и быстро ли, расширяются его возможности в программном и аппаратном измерении? Что произойдет, если количество пользователей, объемы данных, количество транзакций — возрастут в разы? Или десятки, сотни раз.

Тестирование надежности

Насколько приложение надёжное, «выносливое»? Сколько времени оно сумеет проработать «без единого отказа», и при каких условиях происходит отказ? Что провоцирует ошибки в приложении?

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

Приемочное тестирование

Компания-клиент, получая готовый программный продукт, проводит приемочное тестирование (User Acceptance Testing = UAT). Оценивает, можно ли принимать софт, исходя из пользовательских требований и предпочтений. Если они не удовлетворены, или если просто клиенту не нравится что-либо в приложении, команде, работавшей над софтом, будет подан запрос на изменения.

Подробнее об основных инструментах автоматизации тестирования можно почитать здесь — а также оценить «портрет среднего тестировщика» в 2022-2023.

Бесплатная подписка на телеграм-канал, посвященный только и исключительно автоматизации — здесь. А официальный канал TestEngineer — здесь.

Источник: testengineer.ru

Лекция 10. Тестирование программных продуктов

Тестироваться могут самые разные представления знаний о разрабатываемой или сопровождаемой программе на любой фазе ее жизненного цикла. Это могут быть требования к программному продукту, cпецификации проекта или структур данных, фрагменты программного кода.

В литературе имеется несколько различных определений понятия “тестирование”. Будем использовать следующее:

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

Часто тестирование программы в соответствии с этим определением называют динамическим тестированием, а статический анализ, не требующий выполнения программы (просмотр, инспекция), – статическим тестированием.

Принято выделять методы тестирования и критерии тестирования программного продукта.

Определение. Методы тестирования – это совокупность правил, регламентирующих последовательность шагов по тестированию.

Определение. Критерии тестирования – соображения, позволяющие судить о достаточности проведенного тестирования.

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

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

Результативным (удачным) считается тест, прогон которого привел к обнаружению ошибки. Из данного свойства теста вытекает важное следствие: тестирование – процесс деструктивный (обратный созидательному, конструктивному). Именно этим объясняется, почему многие считают его трудным. Большинство людей склонны к конструктивному процессу созидания объектов и в меньшей степени – к деструктивному процессу.

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

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

Программный продукт, как объект тестирования, имеет ряд особенностей, которые отличают процесс тестирования программного обеспечения от традиционного, исторически ранее появившегося “аппаратного” тестирования:

отсутствие полностью определенного единого эталона, которому должны соответствовать все результаты тестирования проверяемой программы;

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

высокая сложность программ и принципиальная невозможность построения тестовых наборов, достаточных для исчерпывающего тестирования;

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

наличие в программах вычислительных и логических компонент, а также компонент, характеризующихся стохастическим и динамическим поведением;

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

относительно невысокая степень формализации критериев завершения процесса тестирования и оценки качества тестирования.

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

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

На практике приходится применять ряд значительно различающихся методов и критериев тестирования. Каждая категория тестов отличается целевыми задачами тестирования, проверяемыми компонентами программ и методами оценки результатов. Только совместное и систематическое применение различных методов тестирования и категорий тестов, базирующихся на различных критериях тестирования, позволяет достичь высокого качества функционирования средних и сложных программных комплексов со средней или большой длительностью эксплуатации, имеющих большой размер исходного кода (10 5 — 10 7 строк в программе).

Сформулируем основные принципы тестирования:

Описание предполагаемых значений выходных данных или результатов должно быть неотъемлемой частью теста.

Следует избегать тестирования программы ее автором; тестирование является более эффективным, если оно выполняется не автором программы, но отладка программы обычно более эффективно выполняется авторами.

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

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

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

Необходимо проверять программу на нежелательные побочные эффекты.

Не следует выбрасывать тесты, даже если программа уже не нужна.

Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.

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

Источник: studfile.net