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

Нижегородский государственный университет
им. Н.И. Лобачевского
Факультет вычислительной математики и кибернетики
Проект ТЭЛМА
Процесс тестирования
программного продукта
Выполнили:
Ильичева Н.Н.
Шибаева В.И.
Смирнова Л.В.
1 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Что такое тестирование?
• Тестирование — процесс, подтверждающий
правильность программы и демонстрирующий,
что ошибок в программе нет
• Тестирование — процесс выполнения
программы (или части программы) с
намерением (или целью) найти ошибки
Цель тестирования – найти ошибки в программе и
тем самым повысить ее надежность, а
следовательно, ценность.
2 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Философия тестирования
Тестирование
программного
обеспечения
охватывает целый ряд видов деятельности:
• постановка задачи для теста
• проектирование, написание тестов
• тестирование тестов
• выполнение тестов
• изучение результатов тестирования.
Возможен целый спектр подходов к выработке
стратегии проектирования тестов.
3 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Тестирование “черным ящиком”
Программе подаются некоторые данные на вход и
проверяются результаты, в надежде найти
несоответствия. При этом как именно работает
программа считается несущественным.
Цель – проверить все возможные комбинации и
значения на входе.
4 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Тестирование “белым ящиком”
Этот метод изучает не только внешнее поведение
программы, но и ее внутреннее устройство
(исходные тексты). Проектирование тестов основано
на изучении логики программы.
Тесты проектируются таким образом, чтобы каждая
команда условного перехода выполнялась в каждом
направлении хотя бы один раз.
Цель — проверить каждый путь, каждую ветвь
алгоритма.
5 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Недостатки методов
Метод “черного ящика” имеет следующие
недостатки:
– невозможно найти взаимоуничтожающихся ошибок
– некоторые ошибки возникают достаточно редко (ошибки
работы с памятью) и потому их трудно найти и
воспроизвести.
Метод “белого ящика” имеет следующие недостатки:
– даже для средних по сложности программ числом
всевозможных путей может достигать десятков тысяч.
6 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Некоторые выводы:
– ни один из этих методов не является хорошей
стратегией;
– эти методы дополняют друг друга, т.к.находят
разные ошибки.
Наиболее эффективные процессы разработки
программного обеспечения используют некоторую
комбинацию методик "черного ящика" и "белого
ящика".
7 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Интеграция модулей
Последовательность слияния всех модулей в систему или
программу является вторым по важности аспектом
тестирования (после проектирования тестов).
Выбор этой последовательности является одним из самых
жизненно важных решений, принимаемых на этапе
тестирования, поскольку он определяет форму, в которой
записываются тесты, типы необходимых инструментов
тестирования,
последовательность
программирования
модулей, а также тщательность и экономичность всего этапа
тестирования.
8 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Модульное тестирование
В тестирование многомодульных программ можно выделить
четыре этапа:
1) тестирование отдельных модулей;
2) совместное тестирование модулей;
3) тестирование спецификации программы;
4) тестирование всего комплекса в целом.
На первых двух этапах используются методы структурного
тестирования, последующие этапы тестирования
ориентированы на обнаружение ошибок различного типа,
которые не обязательно связаны с логикой программы.
Известны два подхода к тестированию модулей:
Монолитное
Пошаговое тестирование.
9 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Монолитное тестирование
При монолитном тестировании сначала по
отдельности тестируются все модули программного
комплекса, а затем все они объединяются в рабочую
программу для комплексного тестирования. Для
автономного тестирования каждого модуля требуется
модуль - драйвер и несколько модулей - заглушек
(имитирующих работу модулей, вызываемых из
тестируемого).
10 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Пошаговое тестирование
При пошаговом тестировании каждый модуль для
своего тестирования подключается к набору уже
проверенных модулей. Модули проверяются не
изолированно друг от друга, поэтому требуются
либо только драйверы, либо только заглушки.
При пошаговом тестировании возможны две
стратегии подключения модулей:
Нисходящая
Восходящая.
11 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Нисходящее тестирование
При нисходящем подходе программа собирается и
тестируется сверху вниз. Изолировано тестируется только
головной модуль. После того как тестирование этого
модуля завершено, с ним соединяются один за другим
модули, непосредственно вызываемые им, и тестируется
полученная комбинация. Процесс повторяется до тех пор,
пока не будут собраны и проверены все модули.
12 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Достоинства и недостатки
нисходящего метода
+ уже на ранней стадии тестирования есть возможность
получить работающий вариант разрабатываемой
программы;
+ быстро могут быть выявлены ошибки, связанные с
организацией взаимодействия с пользователем;
– одна из основных проблем, возникающих
нисходящем тестировании, - создание заглушек.
13 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
при
Преимущества и недостатки
восходящего метода
+ Поскольку нет промежуточных модулей, нет проблем,
связанных с трудностью задания тестов;
+ нет трудностей, вызывающих желание перейти к
тестированию следующего модуля, не завершив проверки
предыдущего.
– Недостатком восходящего тестирования является то , что
проверка всей структуры разрабатываемого программного
комплекса возможна только на завершающей стадии
тестирования.
15 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Другие методы модульного
тестирования
Имеется большой выбор возможных методов, которые
могут быть использованы для слияния модулей в более
крупные единицы. В большинстве своем они могут
рассматриваться как варианты описанных ранее двух
методов (восходящее и нисходящее тестирование) и
следующих четырех основных методов:
Модифицированный нисходящий метод
Метод большого скачка
Метод Сандвича
Модифицированный метод Сандвича
16 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Модифицированный нисходящий
метод
Применяя нисходящее тестирование часто невозможно
тестировать определенные логические условия, например
ошибочные и исключительные ситуации или защитные
проверки. Даже если тестирование таких ситуаций в принципе
осуществимо, часто бывает трудно определить, какие именно
нужны тесты, если они вводятся в точке программы, удаленной
от места проверки соответствующего условия.
Модифицированным нисходящим метод, решает эти проблемы:
требуется, чтобы каждый модуль прошел автономное
тестирование перед подключением к программе. Однако здесь
требуются и драйверы, и заглушки для каждого модуля.
17 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Метод большого скачка
В соответствии с этим методом каждый модуль
тестируется автономно. По окончании тестирования
модулей они интегрируются в систему все сразу.
Метод большого скачка по сравнению с другими
подходами имеет много недостатков и мало достоинств:
– заглушки и драйверы необходимы для каждого модуля;
– модули не интегрируются до самого последнего
момента;
– метод большого скачка значительно усложняет отладку.
Если программа мала и хорошо спроектирована, он может
оказаться приемлемым. Однако для крупных программ
метод большого скачка обычно губителен.
18 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Метод Сандвича
При использовании этого метода одновременно начинают
восходящее и нисходящее тестирование, собирая программу
как снизу, так и сверху и встречаясь в конце концов где-то в
середине. Точка встречи зависит от конкретной тестируемой
программы и должна быть заранее определена при изучении
ее структуры.
Метод Сандвича сохраняет такое достоинство нисходящего
и восходящего подходов, как начало интеграции системы на
самом раннем этапе. Поскольку нижние уровни программы
создаются восходящим методом, снимаются проблемы
нисходящего
метода,
которые
были
связаны
с
невозможностью тестировать некоторые условия в глубине
программы.
19 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Модифицированный метод
Сандвича
В модифицированном методе Сандвича нижние уровни
тестируются строго снизу вверх. А модули верхних уровней
сначала тестируются изолированно, а затем собираются
нисходящим методом. Таким образом, модифицированный
метод Сандвича представляет собой компромисс между
восходящим и нисходящим подходами.
20 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Сравнительная характеристика
методов тестирования
С точки зрения надежности программного обеспечения эти
методы можно оценить по следующим восьми критериям:
1. Время до момента сборки модулей
2. Время до момента создания первых работающих
“скелетных” версий программы
3. Необходимость драйверов и других инструментов
тестирования
4. Необходимость заглушек
5. Мера параллелизма
6. Возможность тестировать отдельные пути
7. Возможность планировать и контролировать
последовательность
21 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Сравнительная характеристика
1
2
3
4
5
6
7
Восходящий
Нисхо- Модиф. больш.
дящий Нисх.
скачка
Сандвича
Модиф.
Cандв.
Рано
Поздно
Да
Нет
Средний
Легко
Легко
Рано
Рано
Нет
Да
Слабый
Трудно
Трудно
Рано
Рано
Частично
Частично
Средний
Средне
Трудно
Рано
Рано
Да
Частично
Высокий
Легко
Трудно
22 проект Тэлма, ННГУ, ВМК, 2004г
Рано
Рано
Да
Да
Средний
Легко
Трудно
Поздно
Поздно
Да
Да
Высокий
Трудно
Легко
Процесс тестирования программного продукта
Оценка подходов
Оценка подходов зависит от конкретного проекта. Рассмотрим
вариант очень грубой оценки. Прежде всего, следует взвесить
относительное влияние каждого из семи критериев на
надежность программного обеспечения. Ранняя сборка и
раннее получение работающего каркаса программы, а также
возможность тестировать любые конкретные условия
представляются наиболее важными, поэтому им дается
коэффициент 3. Сложность подготовки заглушек, а также
сложность планирования и управления последовательностью
тестов получают вес 2. Необходимость драйверов, вес 1 ввиду
доступности общих инструментов тестирования. Критерий,
связанный с параллелизмом работы имеет вес 1, потому что он
на надежность сильно не влияет.
23 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Результаты оценок
Вес Крит Восх.
Нисх.
3
1
Рано +
Рано +
Модиф.
Больш.
Метод
Нисх.
скачка
сандвича
Рано + Поздно - Рано +
3
1
2
1
2
3
4
5
Поздно Да
Нет
+
Средний
Рано +
Нет +
Да
Слабый -
Рано +
Да
Да
Средний
Рано +
Частично
Частично
Средний
3
2
6
7
+4
Средне
Трудно
+4
Поздно Да
Да
Высокий
+
Легко + Трудно - Легло + Легко +
Легко + Трудно - Трудно - Легко +
Итог +6
-1
-3
Модиф.
сандвича
Рано +
Рано +
Да
Частично
Высокий
+
Легко +
Трудно
+7
Модифицированный метод сандвича и восходящий метод
оказываются наилучшими подходами, а метод большого
скачка — наихудшим.
24 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Регрессионное тестирование
Под регрессионным тестированием понимают те виды
тестов, которые проводятся с каждой новой версией
программы. Цель проведения этих тестов – убедиться, что
новая версия программы не содержит ошибок в уже
протестированных участках кода.
По данным зарубежных авторов количество ошибок,
возникающих в процессе изменения кода (исправления багов,
внедрения новой функциональности и т.п.) колеблется от 50%
до 80%. Выявить эти ошибки и помогают тесты регрессии.
25 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Виды тестов регрессии
Различают несколько видов регрессионных тестов:
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.Тесты регрессии на "закрытых" багах.
26 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Тесты верификации багов
Представляют собой тесты проверки исправления багов.
Допустим, что тест с номером N выявил баг, что было
зафиксировано и передано разработчику для исправления.
Через определенное время разработчик предоставил новую
версию программы, с информацией о том, что описанный
баг исправлен. Необходимо тест с номером N провести
повторно, чтобы убедиться, что баг действительно больше
не проявляется. В случае успешного прохождения теста
такой баг помечается как Verified, в противном случае - как
re-do, о чем сообщается разработчику и передается на
доработку. Проведение таких тестов является обязательным.
27 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Тесты верификации версий
Представляют собой набор тестов для проверки сохранности
основной функциональности в каждой новой версии
программы. Это краткое тестирование всех основных
функций разрабатываемого ПО, цель которого - убедится,
что программа «работает нормально» и основная
функциональность программы не нарушена. Если хотя бы
один из тестов верификации версии выявляет баг, то тестер
возвращается к предыдущей (последней «рабочей» версии).
Дальнейшей тестирование новой версии не проводится, а
информация об ошибке вносится в базу и отправляется
разработчику. Т.о. тесты верификации версии представляют
собой краткий набор основных тестов функциональности.
28 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Собственно Тесты Регрессии
Под этим понятием объединяют те тесты, которые уже
проводились с предыдущими версиями программы, притом
успешно, т.е. не выявили багов и были отмечены как pass
(passed). Среди Собственно Тестов Регрессии можно выделить
две группы:
– тесты, входящие в набор (т.н. Regression Test Pass with
Regression Test Suit). Они вносятся в базу и описываются, для
них могут и должны быть созданы скрипты, которые позволяют
автоматизировать процесс тестирования
– тесты не входящие в набор (т.н. Regression Test Pass without
Regression Test Suit). Они существуют только "в голове"
тестировщика и проводятся в ручную. Причин этого может
быть много - от малых сроков тестирования, до отсутствия
необходимого ПО, для автоматизации процесса.
29 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Тесты регрессии на "закрытых"
багах.
Допустим, что тест № N, выявивший баг, после исправления
этого бага разработчиком был проведен повторно, при том
успешно. Тест был отмечен как pass, а баг - как Verified. Такой
баг и будет "закрытым". Допустим теперь, что в ходе
разработки, участок кода, где был исправлен этот баг был
изменен, или сменился разработчик, который случайно удалил
"нашлепку" в коде исправлявшую этот баг и показавшуюся
ему лишней и т.п. В этом случае баг проявится снова. Чтобы не
допустить подобного, тестеру время от времени необходимо
проводить тесты, выявлявшие ранее баги в измененном
участке кода, исправление которых уже было проведено ранее
и зафиксировано в базе. Это и есть Тесты регрессии на
"закрытых" багах.
30 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Когда и как проводить
регрессионное тестирование
Все определяется видом разрабатываемого ПО, продолжительностью
жизненного цикла, сроками тестирования, количеством членов
команды.
Далее описаны лишь общие положения:
1. Регрессионное тестирование проводится в каждой новой версии.
2. Начинают регрессионное тестирование с Тестов верификации
версии. Если программа приходит от разработчика в виде
полноценной инсталляции, то Тесты верификации начинаются с
проверки инсталляции, после чего проводится краткий набор тестов
функциональности. Если хотя бы один из тестов failed, версия
передается на доработку, регрессионное тестирование прекращается, а
тестер возвращается к тестированию последней "рабочей" версии.
31 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Когда и как проводить
регрессионное тестирование
3. После успешного прохождения тестов верификации версии,
проводят серию Тестов верификации багов.
4. Из Собственно тестов регрессии проводят лишь те, которые
сопряжены с измененным в новой версии участком кода.
5. Аналогичным образом (см. пункт 4) отбираются тесты в
группу регрессии на "закрытых" багах.
6. Тесты регрессии, выполненные успешно (pass) дважды
считаются "закрытыми". Дальнейшее их использование
производится, так как описано в пункте 4.
7. Для тестов регрессии, которые предполагается проводить
более 3-5 раз рекомендуется писать скрипты для автоматизации
процесса. Это относится ко всем группам тестов регрессии.
32 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта
Когда и как проводить
регрессионное тестирование
8. Отбор тестов для финального регрессионного
тестирования осуществляется по следующим принципам:

В первую очередь отбирают тесты забракованные
(failed) два и более раз. В том числе и те, которые
выявляли баги, требующие доработки (re-do).

Во вторую очередь отбираются тесты,
забракованные один раз, и успешно пройденные повторно.

Далее отбираются все тесты, которые были
пройдены успешно (pass), но проводились только один раз.

Затем проводятся все остальные тесты, в
зависимости от поставленной задачи.
33 проект Тэлма, ННГУ, ВМК, 2004г
Процесс тестирования программного продукта