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

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

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

для теста
проектирование, написание тестов
тестирование тестов
выполнение тестов
изучение результатов тестирования.

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

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

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

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

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

некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести.

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

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

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

по важности аспектом тестирования (после проектирования тестов).

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

модулей; 2) совместное тестирование модулей; 3) тестирование спецификации программы; 4) тестирование всего комплекса в целом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

метод большого скачка — наихудшим.

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

1.1Тесты верификация багов ( (Bug (Bug (Bug Verification (Bug Verification (Bug Verification Test (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). Они существуют только "в голове" тестировщика и проводятся в ручную. Причин этого может быть много - от малых сроков тестирования, до отсутствия необходимого ПО, для автоматизации процесса.

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

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

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

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

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

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