Что такое тест и тестирование?

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

Тест – это выполнение определенных условий и действий, необходимых для проверки работы тестируемой функции или её части.

Сколько нужно тестов?

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

• хранятся в Testlink – для ручного тестирования;
• или программируются в специальных фреймворках (SeleniumWebDriver) – для автоматизированного.

Схема тестирования

В общих чертах, тестирование проходит так:

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

Тестирование в контексте общего процесса разработки

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

1. Юзабилити-тестирование(проверка эргономичности) помогает определить: удобен ли сайт или пользовательский интерфейс для его предполагаемого применения.
2. Создание чек-листа – подготовка набора тестов, внесение необходимых предложений в разрабатываемые требования (с точки зрения качества).
3. Тестирование. Получив готовую для проверки программу или её часть, специалист проверяет её соответствие требованиям на выбранном наборе тестов. В случае обнаружения дефектов – передаёт разработчикам набор задач, необходимых для улучшения продукта до состояния соответствия требованиям.
4. Верификация – проверка, которая показывает: были ли исправлены ошибки, обнаруженные в результате тестов. Обычно тесно связана с регрессионным тестированием. Регрессионное тестирование(regression testing) направлено на обнаружение дефектов в участках кода, которые уже были протестированы. Позволяет отловить регрессионные ошибки (когда после внесения изменений в программу перестаёт работать то, что раньше работало). Хотя подобные тесты могут быть выполнены вручную, чаще для этого используются специализированные программы для автоматизированного тестирования.
5. Тест производительности(performance testing) проводится на стендах, где в дальнейшем будет эксплуатироваться софт. Цель – выявление проблем стенда (не софта), имитация работы пользователей, проверка на стрессоустойчивость. Позволяет убедиться, что приложение/система справится с реальной нагрузкой в будущем.

Польза тестирования

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

Существует два принципа тестирования программного обеспечения — функциональное тестирование ( тестирование “чёрного ящика”) и структурноетестирование ( тестирование “белого ящика”).

Функциональное тестирование («чёрного ящика»).

При тестировании “чёрного ящика” рассматриваются системные характеристики программ, а их внутренняя логическая структура не рассматривается. Таким образом, функции программы считаются известными и целью тестирования является исследование работы каждой функции на всей области ее определения. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 1010 тестовых вариантов. Отметим также, что тестирование “чёрного ящика” не реагирует на многие особенности программных ошибок.

Как показано на рис. 2.12, основное место приложения тестов «черного ящика» — интерфейс ПО, то есть тестирование входов и выходов программы.

Рис. 2.12. Тестирование «черного ящика»

Эти тесты демонстрируют:

· как выполняются функции программ;

· как принимаются исходные данные;

· как вырабатываются результаты;

· как сохраняется целостность внешней информации.

Структурное тестирование («белого ящика»).

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

Таким образом, при структурном тестировании по известной структуре программы (тексту) исследуются связи между ее отдельными элементами (рис. 2.13).

Рис. 2.13. Схема тестирования «белого ящика»

Обычно тестирование “белого ящика” основано на анализе управляющей структуры программы.

Что такое тестирование программного обеспечения?

Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.

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

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

При п = 5 и k = 20 количество маршрутов т = 1014.

Кроме этого, исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

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

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

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

Пройти гигиеническое обучение и аттестацию

При дистанционной форме  обучения — заказчик  самостоятельно, используя дома компьютер,    изучает  методический  материал (лекции)  и проходит, не выходя из дома,  на компьютере  тест — контроль на знание санитарных требований (сдает экзамен). При успешном прохождении тест — контроля специалист ФБУЗ оформляет заказчику личную  медицинскую  книжку.

III. Технология поиска необходимых для обучения материалов.

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

Перечень групп работников, подлежащих гигиеническому обучению и аттестации:

1. Гигиеническое обучение  заведующих и воспитателей детских дошкольных учреждений
2. Гигиеническое обучение  помощников воспитателей детских дошкольных учреждений
3. Гигиеническое обучение начальников, воспитателей, вожатых детских оздоровительных лагерей
4. Гигиеническое обучение технического персонала образовательных учреждений
5. Гигиеническое обучение педагогических работников образовательных учреждений
6. Гигиеническое обучение работников пищеблоков  детских оздоровительных лагерей
7. Гигиеническое обучение работников пищеблоков детских дошкольных учреждений
8. Гигиеническое  обучение инженерно-технических работников работающих с пестицидами и агрохимикатами
9. Гигиеническое обучение рабочих профессий работающих с пестицидами и агрохимикатами
10. Гигиеническое обучение работников кондитерских производств
11. Гигиеническое обучение работников молокоперерабатывающей промышленности
12. Гигиеническое обучение работников мясо- и птицеперерабатывающей промышленности
13. Гигиеническое обучение работников общественного питания
14. Гигиеническое обучение работников продовольственной торговли
15. Гигиеническое обучение работников хлебопекарной и макаронной промышленности
16. Гигиеническое обучение преподавателей ВУЗов
17. Гигиеническое обучение студентов ВУЗов
18. Гигиеническое обучение учащихся и студентов  образовательных учреждений начального проф. образования  и средних специальных учебных заведений
19. Гигиеническое обучение работников парикмахерских
20. Гигиеническое обучение работников фармацевтических  и аптечных учреждений
21. Гигиеническое обучение медицинских работников, кроме младшего мед. персонала
22. Гигиеническое обучение горничных и уборщиц гостиниц и общежитий
23. Гигиеническое обучение младшего медперсонала, организаций, осуществляющих медицинскую деятельность
24. Гигиеническое обучение работников бань и прачечных
25. Гигиеническое обучение работников водопроводно-канализационного хозяйства
26. Гигиеническое обучение работников системы коммунально — бытового обслуживания
27. Гигиеническое обучение работников торговли промышленными товарами
28. Гигиеническое обучение работников плавательных бассейнов
29. Гигиеническое обучение работников рыбообрабатывающих предприятий
30. Гигиеническое обучение работников производств пивоваренной и безалкогольной продукции

Для прохождения тест — контроля на знание санитарных требований (при дистанционной форме обучения), пожалуйста, перейдите по ссылке:

Пройти контрольное тестирование

Статическое тестирование – тестирование, при котором код программы не выполняется. Мы проверяем не работу программы, а сам код.

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

Когда говорят «тестирование», то это термин обычно употребляют применимо к динамическому тестированию.

Динамическое тестирование – это тестирование, при котором выполняется код программы. Оно делится на несколько подтипов. Например, тестирование «ящиков»: тестирование белого ящика, тестирование черного ящика, а иногда выделяют и тестирование серого ящика. Эта классификация уже относится к способам тестирования, т.е. как именно тестируют программу.

Стратегия тестирования по принципу «Белого ящика» (англ.black box) – также называемая стратегией тестирования управляемой логикой программы позволяет проверить внутреннюю структуру программы. Исходя из этой стратегии, тестировщик получает тестовые данные путем анализалогики работы программы.

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

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

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

Тестирование черного ящика – тестирование, при котором тестировщик имеет доступ к программе только через интерфейс.

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

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

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

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

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

Тестирование серого ящика – находится в пограничном состоянии между белым ящиком и черным, поэтому его и называют серым. Сочетание происходит таким образом: снаружи на продукт смотрим как на черный ящик, но выбор тестов основываем на знании внутреннего устройства программы, знании ее кода. Этот метод часто используется для тестирования Web Internet приложений.

Уровни тестирования:

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

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

— Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

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

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

Раздел: Тестирование > Тестовые Артефакты > Тест План (План тестирования)

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

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

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

1. Test Plan Template RUP
2. Test Plan Template IEEE 829

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

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

1. Что надо тестировать?
   • описание объекта тестирования: системы, приложения, оборудования
2. Что будете тестировать?
   • список функций и описание тестируемой системы и её компонент в отдельности
3. Как будете тестировать?
   • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
4. Когда будете тестировать?
   • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
5. Критерии начала тестирования:
   • готовность тестовой платформы (тестового стенда)
   • законченность разработки требуемого функционала
   • наличие всей необходимой документации
   • …
6. Критерии окончания тестирования:

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

• Окружение тестируемой системы (описание программно-аппаратных средств)
• Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
• Риски и пути их разрешения

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

1. Мастер Тест План (Master Plan or Master Test Plan)
2. Тест План (Test Plan), назовем его детальный тест план)
3. План Приемочных Испытаний (Product Acceptance Plan) — документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

Рецензия и Утверждение

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

• Ведущий тестировщик
• Тест менеджер (менеджер по качеству)
• Руководитель разработки
• Менеджер Проекта

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

Вывод

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

Наверх

Тестирование программного обеспечения — основные понятия и определения

Тестирование программного обеспечения (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (Verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е.

выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (Validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

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

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

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

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

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

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

Время Прохождения Тест Кейса (Test Case Pass Time) — это время от начала прохождения шагов тест кейса до получения результата теста.