Процесс тестирования программного продукта презентация

Нижегородский государственный университет
им. Н.И. Лобачевского
Факультет вычислительной математики и кибернетики

Проект ТЭЛМА

Процесс тестирования программного продукта


Выполнили:
Ильичева Н.Н.
Шибаева В.И.
Смирнова Л.В.

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

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

Цель тестирования – найти ошибки в программе и тем самым повысить ее надежность, а следовательно, ценность.

Философия тестирования

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

Возможен целый спектр подходов к выработке
стратегии проектирования тестов.

Тестирование “черным ящиком”

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

Цель – проверить все возможные комбинации и значения на входе.

Тестирование “белым ящиком”

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

Цель — проверить каждый путь, каждую ветвь алгоритма.

Недостатки методов

Метод “черного ящика” имеет следующие недостатки:
невозможно найти взаимоуничтожающихся ошибок
некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести.

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

Некоторые выводы:

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

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

Интеграция модулей

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

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

Модульное тестирование

В тестирование многомодульных программ можно выделить четыре этапа: 1) тестирование отдельных модулей; 2) совместное тестирование модулей; 3) тестирование спецификации программы; 4) тестирование всего комплекса в целом.

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

Известны два подхода к тестированию модулей:
Монолитное
Пошаговое тестирование.

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

Монолитное тестирование

Пошаговое тестирование

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

Нисходящее тестирование

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

Достоинства и недостатки нисходящего метода

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

Восходящее тестирование

При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня (“терминальные” модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина.

Преимущества и недостатки восходящего метода

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

Другие методы модульного тестирования

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

Модифицированный нисходящий метод

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

Метод большого скачка

В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу.
Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств:
– заглушки и драйверы необходимы для каждого модуля;
– модули не интегрируются до самого последнего момента;
– метод большого скачка значительно усложняет отладку.
Если программа мала и хорошо спроектирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен.

Метод Сандвича

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

Модифицированный метод Сандвича

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

Сравнительная характеристика методов тестирования

С точки зрения надежности программного обеспечения эти методы можно оценить по следующим восьми критериям:
1. Время до момента сборки модулей
2. Время до момента создания первых работающих “скелетных” версий программы
3. Необходимость драйверов и других инструментов тестирования
4. Необходимость заглушек
5. Мера параллелизма
6. Возможность тестировать отдельные пути
7. Возможность планировать и контролировать последовательность

Сравнительная характеристика

Оценка подходов

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

Результаты оценок

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

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

Под регрессионным тестированием понимают те виды тестов, которые проводятся с каждой новой версией программы. Цель проведения этих тестов – убедиться, что новая версия программы не содержит ошибок в уже протестированных участках кода.
По данным зарубежных авторов количество ошибок, возникающих в процессе изменения кода (исправления багов, внедрения новой функциональности и т.п.) колеблется от 50% до 80%. Выявить эти ошибки и помогают тесты регрессии.

Виды тестов регрессии

Различают несколько видов регрессионных тестов:
1. Верификационные тесты (Verification Test)
1.1Тесты верификация багов (Bug Verification Test)
1.2 Тесты верификации версии (Build Verification Test; Build Acceptance Test, smoke test, quick check).
2. Собственно Тесты Регрессии (или Regression Test Pass)
3.Тесты регрессии на "закрытых" багах.

Тесты верификации багов

Представляют собой тесты проверки исправления багов. Допустим, что тест с номером N выявил баг, что было зафиксировано и передано разработчику для исправления. Через определенное время разработчик предоставил новую версию программы, с информацией о том, что описанный баг исправлен. Необходимо тест с номером N провести повторно, чтобы убедиться, что баг действительно больше не проявляется. В случае успешного прохождения теста такой баг помечается как Verified, в противном случае - как re-do, о чем сообщается разработчику и передается на доработку. Проведение таких тестов является обязательным.

Тесты верификации версий

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

Собственно Тесты Регрессии

Под этим понятием объединяют те тесты, которые уже проводились с предыдущими версиями программы, притом успешно, т.е. не выявили багов и были отмечены как pass (passed). Среди Собственно Тестов Регрессии можно выделить две группы:
– тесты, входящие в набор (т.н. Regression Test Pass with Regression Test Suit). Они вносятся в базу и описываются, для них могут и должны быть созданы скрипты, которые позволяют автоматизировать процесс тестирования
– тесты не входящие в набор (т.н. Regression Test Pass without Regression Test Suit). Они существуют только "в голове" тестировщика и проводятся в ручную. Причин этого может быть много - от малых сроков тестирования, до отсутствия необходимого ПО, для автоматизации процесса.

Тесты регрессии на "закрытых" багах.

Допустим, что тест № N, выявивший баг, после исправления этого бага разработчиком был проведен повторно, при том успешно. Тест был отмечен как pass, а баг - как Verified. Такой баг и будет "закрытым". Допустим теперь, что в ходе разработки, участок кода, где был исправлен этот баг был изменен, или сменился разработчик, который случайно удалил "нашлепку" в коде исправлявшую этот баг и показавшуюся ему лишней и т.п. В этом случае баг проявится снова. Чтобы не допустить подобного, тестеру время от времени необходимо проводить тесты, выявлявшие ранее баги в измененном участке кода, исправление которых уже было проведено ранее и зафиксировано в базе. Это и есть Тесты регрессии на "закрытых" багах.

Когда и как проводить регрессионное тестирование

Все определяется видом разрабатываемого ПО, продолжительностью жизненного цикла, сроками тестирования, количеством членов команды.
Далее описаны лишь общие положения:
1. Регрессионное тестирование проводится в каждой новой версии.
2. Начинают регрессионное тестирование с Тестов верификации версии. Если программа приходит от разработчика в виде полноценной инсталляции, то Тесты верификации начинаются с проверки инсталляции, после чего проводится краткий набор тестов функциональности. Если хотя бы один из тестов failed, версия передается на доработку, регрессионное тестирование прекращается, а тестер возвращается к тестированию последней "рабочей" версии.

3. После успешного прохождения тестов верификации версии, проводят серию Тестов верификации багов.
4. Из Собственно тестов регрессии проводят лишь те, которые сопряжены с измененным в новой версии участком кода.
5. Аналогичным образом (см. пункт 4) отбираются тесты в группу регрессии на "закрытых" багах.
6. Тесты регрессии, выполненные успешно (pass) дважды считаются "закрытыми". Дальнейшее их использование производится, так как описано в пункте 4.
7. Для тестов регрессии, которые предполагается проводить более 3-5 раз рекомендуется писать скрипты для автоматизации процесса. Это относится ко всем группам тестов регрессии.

Когда и как проводить регрессионное тестирование

8. Отбор тестов для финального регрессионного тестирования осуществляется по следующим принципам: ∙ В первую очередь отбирают тесты забракованные (failed) два и более раз. В том числе и те, которые выявляли баги, требующие доработки (re-do).
∙ Во вторую очередь отбираются тесты, забракованные один раз, и успешно пройденные повторно.
∙ Далее отбираются все тесты, которые были пройдены успешно (pass), но проводились только один раз.
∙ Затем проводятся все остальные тесты, в зависимости от поставленной задачи.

Когда и как проводить регрессионное тестирование