Презентация на тему Процесс тестирования программного продукта Выполнили: Ильичева Н.Н. Шибаева В.И. Смирнова Л.В.

Презентация на тему Процесс тестирования программного продукта Выполнили: Ильичева Н.Н. Шибаева В.И. Смирнова Л.В., предмет презентации: Разное. Этот материал содержит 33 слайдов. Красочные слайды и илюстрации помогут Вам заинтересовать свою аудиторию. Для просмотра воспользуйтесь проигрывателем, если материал оказался полезным для Вас - поделитесь им с друзьями с помощью социальных кнопок и добавьте наш сайт презентаций ThePresentation.ru в закладки!

Слайды и текст этой презентации

Слайд 1
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

Проект ТЭЛМА

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


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


Слайд 2
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


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


Слайд 3
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


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


Слайд 4
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


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


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


Слайд 5
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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




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

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


Слайд 6
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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

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


Слайд 7
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


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


Слайд 8
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



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


Слайд 9
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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

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

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



Слайд 10
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 11
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 12
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 13
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 14
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 15
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 16
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 17
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


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


Слайд 18
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


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


Слайд 19
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


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


Слайд 20
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


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


Слайд 21
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 22
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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


Слайд 23
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 24
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 25
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 26
Текст слайда:

проект Тэлма, ННГУ, ВМК, 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.Тесты регрессии на "закрытых" багах.



Слайд 27
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 28
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 29
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 30
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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



Слайд 31
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта

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

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


Слайд 32
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта


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

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


Слайд 33
Текст слайда:

проект Тэлма, ННГУ, ВМК, 2004г Процесс тестирования программного продукта


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

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


Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

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


Для правообладателей

Яндекс.Метрика