Добавить материал и получить бесплатное свидетельство о публикации в СМИ
Эл. №ФС77-60625 от 20.01.2015
Инфоурок / Другое / Презентации / Презентация по ИСРПО "Процесс тестирования программного продукта"

Презентация по ИСРПО "Процесс тестирования программного продукта"


До 7 декабря продлён приём заявок на
Международный конкурс "Мириады открытий"
(конкурс сразу по 24 предметам за один оргвзнос)

  • Другое
Процесс тестирования программного продукта
Что такое тестирование? Тестирование — процесс, подтверждающий правильность п...
Философия тестирования Тестирование программного обеспечения охватывает целый...
Тестирование “черным ящиком” Программе подаются некоторые данные на вход и пр...
Тестирование “белым ящиком” Этот метод изучает не только внешнее поведение пр...
Недостатки методов Метод “черного ящика” имеет следующие недостатки: невозмож...
Некоторые выводы: ни один из этих методов не является хорошей стратегией; эти...
Интеграция модулей Последовательность слияния всех модулей в систему или прог...
Модульное тестирование В тестирование многомодульных программ можно выделить...
При монолитном тестировании сначала по отдельности тестируются все модули про...
Пошаговое тестирование При пошаговом тестировании каждый модуль для своего те...
Нисходящее тестирование При нисходящем подходе программа собирается и тестиру...
Достоинства и недостатки нисходящего метода + уже на ранней стадии тестирован...
Восходящее тестирование При восходящем подходе программа собирается и тестиру...
Преимущества и недостатки восходящего метода + Поскольку нет промежуточных мо...
Другие методы модульного тестирования Имеется большой выбор возможных методов...
Модифицированный нисходящий метод Применяя нисходящее тестирование часто нево...
Метод большого скачка В соответствии с этим методом каждый модуль тестируется...
Метод Сандвича При использовании этого метода одновременно начинают восходяще...
Модифицированный метод Сандвича В модифицированном методе Сандвича нижние уро...
Сравнительная характеристика методов тестирования С точки зрения надежности п...
Сравнительная характеристика
Оценка подходов Оценка подходов зависит от конкретного проекта. Рассмотрим ва...
Результаты оценок Модифицированный метод сандвича и восходящий метод оказываю...
Регрессионное тестирование Под регрессионным тестированием понимают те виды т...
Виды тестов регрессии Различают несколько видов регрессионных тестов: 1. Вери...
Тесты верификации багов Представляют собой тесты проверки исправления багов....
Тесты верификации версий Представляют собой набор тестов для проверки сохранн...
Собственно Тесты Регрессии Под этим понятием объединяют те тесты, которые уже...
Тесты регрессии на "закрытых" багах. Допустим, что тест № N, выявивший баг, п...
Когда и как проводить регрессионное тестирование Все определяется видом разра...
3. После успешного прохождения тестов верификации версии, проводят серию Тест...
8. Отбор тестов для финального регрессионного тестирования осуществляется по...
1 из 33

Описание презентации по отдельным слайдам:

№ слайда 1 Процесс тестирования программного продукта
Описание слайда:

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

№ слайда 2 Что такое тестирование? Тестирование — процесс, подтверждающий правильность п
Описание слайда:

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

№ слайда 3 Философия тестирования Тестирование программного обеспечения охватывает целый
Описание слайда:

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

№ слайда 4 Тестирование “черным ящиком” Программе подаются некоторые данные на вход и пр
Описание слайда:

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

№ слайда 5 Тестирование “белым ящиком” Этот метод изучает не только внешнее поведение пр
Описание слайда:

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

№ слайда 6 Недостатки методов Метод “черного ящика” имеет следующие недостатки: невозмож
Описание слайда:

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

№ слайда 7 Некоторые выводы: ни один из этих методов не является хорошей стратегией; эти
Описание слайда:

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

№ слайда 8 Интеграция модулей Последовательность слияния всех модулей в систему или прог
Описание слайда:

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

№ слайда 9 Модульное тестирование В тестирование многомодульных программ можно выделить
Описание слайда:

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

№ слайда 10 При монолитном тестировании сначала по отдельности тестируются все модули про
Описание слайда:

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

№ слайда 11 Пошаговое тестирование При пошаговом тестировании каждый модуль для своего те
Описание слайда:

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

№ слайда 12 Нисходящее тестирование При нисходящем подходе программа собирается и тестиру
Описание слайда:

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

№ слайда 13 Достоинства и недостатки нисходящего метода + уже на ранней стадии тестирован
Описание слайда:

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

№ слайда 14 Восходящее тестирование При восходящем подходе программа собирается и тестиру
Описание слайда:

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

№ слайда 15 Преимущества и недостатки восходящего метода + Поскольку нет промежуточных мо
Описание слайда:

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

№ слайда 16 Другие методы модульного тестирования Имеется большой выбор возможных методов
Описание слайда:

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

№ слайда 17 Модифицированный нисходящий метод Применяя нисходящее тестирование часто нево
Описание слайда:

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

№ слайда 18 Метод большого скачка В соответствии с этим методом каждый модуль тестируется
Описание слайда:

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

№ слайда 19 Метод Сандвича При использовании этого метода одновременно начинают восходяще
Описание слайда:

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

№ слайда 20 Модифицированный метод Сандвича В модифицированном методе Сандвича нижние уро
Описание слайда:

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

№ слайда 21 Сравнительная характеристика методов тестирования С точки зрения надежности п
Описание слайда:

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

№ слайда 22 Сравнительная характеристика
Описание слайда:

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

№ слайда 23 Оценка подходов Оценка подходов зависит от конкретного проекта. Рассмотрим ва
Описание слайда:

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

№ слайда 24 Результаты оценок Модифицированный метод сандвича и восходящий метод оказываю
Описание слайда:

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

№ слайда 25 Регрессионное тестирование Под регрессионным тестированием понимают те виды т
Описание слайда:

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

№ слайда 26 Виды тестов регрессии Различают несколько видов регрессионных тестов: 1. Вери
Описание слайда:

Виды тестов регрессии Различают несколько видов регрессионных тестов: 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 Тесты верификации багов Представляют собой тесты проверки исправления багов.
Описание слайда:

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

№ слайда 28 Тесты верификации версий Представляют собой набор тестов для проверки сохранн
Описание слайда:

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

№ слайда 29 Собственно Тесты Регрессии Под этим понятием объединяют те тесты, которые уже
Описание слайда:

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

№ слайда 30 Тесты регрессии на "закрытых" багах. Допустим, что тест № N, выявивший баг, п
Описание слайда:

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

№ слайда 31 Когда и как проводить регрессионное тестирование Все определяется видом разра
Описание слайда:

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

№ слайда 32 3. После успешного прохождения тестов верификации версии, проводят серию Тест
Описание слайда:

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

№ слайда 33 8. Отбор тестов для финального регрессионного тестирования осуществляется по
Описание слайда:

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


57 вебинаров для учителей на разные темы
ПЕРЕЙТИ к бесплатному просмотру
(заказ свидетельства о просмотре - только до 11 декабря)

Автор
Дата добавления 20.11.2016
Раздел Другое
Подраздел Презентации
Просмотров10
Номер материала ДБ-371170
Получить свидетельство о публикации
Похожие материалы

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