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

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

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

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

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

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

ящиком”

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

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

ящиком”

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

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

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

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

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

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

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

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

тестирование многомодульных программ можно выделить четыре этапа: 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, версия передается на доработку, регрессионное тестирование прекращается, а тестер возвращается к тестированию последней "рабочей" версии.

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

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