Добавлен: 25.04.2023
Просмотров: 440
Скачиваний: 2
Цели тестов:
Увеличить вероятность того, что приложение, предназначенное для тестирования, будет работать корректно в любой ситуации.
Увеличить вероятность того, что приложение, предназначенное для тестирования, будет выполнять все необходимые требования.
Выполнить максимально полное тестирование приложения за короткий срок.
Задачи тестов:
Удостовериться, что система выполняет временные условия отклика клиента и сервера.
Удостовериться, что наиболее важные последовательности действий с системой конечного пользователя продукта выполняются правильно.
Удостовериться, что перемены в базах данных не влияют негативно на уже существующие программные модули.
Удостовериться в правильной работе интерфейса пользователя
На момент проекта теста минимизировать его переработку если намечаются изменения в приложении.
Пользоваться инструментами автоматизированного тестирования лишь там, где это может быть целесообразно.
Проводить тесты так, чтобы можно было не только находить, но и предотвращать дефекты.
На стадии проектирования автоматизированных тестов можно воспользоваться стандартами разработки так, чтобы создать более универсальные и многогранные скрипты.
1.4 Комплексный тест ПО
Комплексное тестирование необходимо для того, чтобы все модули программного продукта правильно согласовались друг с другом. При комплексном тесте можно использовать технологию обрабатывания снизу-вверх и сверху-вниз, при которой любой модуль является одной из веток в дереве системы, интегрирующийся с последующим модулем более высокого или низшего уровня, пока не получится единое дерево программного продукта. Такая технология тестирования в первую очередь направлена не только на проверку тех параметров, которые передаются меж двумя компонентами и проверку глобальных параметров, но также, в ситуации объектно-ориентированного приложения, абсолютно всех классов верхнего уровня.
Каждый процесс комплексного тестинга составляется из скриптов верхнего уровня, которые моделируют исполнение пользователем конкретной задачи, используя модульные тесты нижних уровней с необходимыми настройками для проверки интерфейса.
После принятия решений по всем отчетам о ошибках модульного тестирования, все модули соединяются инкрементно и уже затем тестируются вместе на основе заданной управляющей логики. Из-за того, что модули способны состоять из других модулей, кусок работы по комплексному тестингу можно провести во время модульного тестирования.
Если скрипты для модульного тестирования созданы при помощи инструментов автоматизированного тестирования, их возможно соединить и добавить свежие скрипты для теста связей между модулями.
Таким образом, процессы комплексного теста исполняются и правильно уточняются, отчеты об ошибках каталогируются и наблюдаются. Отчеты об ошибках, обычно классифицируют по степени их серьезности в порядке от одного до четырех (где единица — это критическая ошибка, а четверка незначительная). После обработки всех этих отчетов тестирующий должен провести регрессионное тест на проверку того, что все ошибки полностью устранены.
1.5 Восходящее и нисходящее, а также целостное тестирование
Восходящие тесты – замечательный способ отсечения и локализации ошибок в коде. Обнаруженная лишь в одном модуле ошибка, указывает что проблема конкретно в нем, ради нахождения истока этой ошибки вам не придется обыскивать весь код. И раз уж ошибка появляется именно при совместной работе двух заранее протестированных модулей, значит, дело именно в их интерфейсе. Еще одним из преимуществ восходящего тестирования является то, что программист, который выполняет такое тестирование сосредотачивается на конкретной области (одном-единственном модуле, обмене или передаче информации между парой конкретных модулей и так далее). Благодаря такому способу само тестирование проходит куда более тщательно и чаще выявляет ошибки.
Основным минусом восходящего тестирования является необходимость написания особого кода, так называемой оболочки, вызывающей сам тестируемый модуль. Ну а если он еще и вызывает другой модуль, для него необходимо написать «заглушку». Заглушка - это просто имитация вызываемой функции, которая вернет те же самые данные.
Очевидно, что процесс написания заглушек и оболочек в некоторой степени замедляет процесс работы, и для финального продукта они полностью бесполезны. Но один раз написанные, эти элементы можно использовать повторно при каждом изменении программы, и солидный их набор превращается в крайне эффективный инструмент для тестирования.
В пику восходящему тестированию, стратегия целостного тестирования позволяет не тестировать особенно тщательно отдельные модули системы, до её полной интеграции.
Одним из главных плюсов этой стратегии является то, что необходимость в написании «лишнего» кода отпадает. Во многом из-за этого часть руководители выбирают такой способ в надежде сэкономить временной ресурс - они думают, что проще будет спрограммировать один большой набор тестов и одним лишь им (набором) проверить систему полностью за один раз. Конечно, такое рассуждение ошибочно, и сейчас я объясню почему же.
• Достаточно сложно обнаружить исток ошибки. И это основная проблема. Из-за того, что ни один модуль не проверен комплексно, большая часть из них имеет дефекты. Получается, вопрос даже не в том, в каком конкретно из модулей случилась найденная ошибка, а в том, какая из многообразия ошибок во всех вовлеченных в процесс модулях довела до полученного результата. А когда на это накладываются еще и ошибки нескольких модулей, необходимую ситуацию становится куда труднее выцепить и повторить.
Помимо этого, одна ошибка в модуле может заблокировать тест другого. Как же тестировать функцию, если и сам вызывающий ее модуль не работоспособен? А если не писать для функции программу-оболочку, придется ждать отладки проблемного модуля, а это значительная трата времени.
• Тяжело организовывать надлежащий «ремонт» ошибок. Если самим написанием программы заняты несколько программистов (Зачастую так и бывает в крупных системах), но при этом еще и непонятно, в каком же модуле ошибка, кто будет искать её, и править? Один из программистов будет показывать на другого, тот в свою очередь, выяснив, что конкретно его код здесь ни при чем, снова полезет к первому, и в итоге весь процесс заметно замедлится, если вовсе не остановится из-за неразберихи.
• Сам процесс тестирования скверно автоматизирован. То, что в начале кажется заметным плюсом целостного тестирования - отсутствие потребности в написании оболочек и заглушек, в сочетании с человеческим фактором оборачивается довольно существенным недостатком. Во время изготовления сама программа постоянно изменяется, и необходимо тестировать её вновь и вновь. Оболочки же и заглушки оказывают помощь в автоматизации этого однообразного труда, и в некоторой мере исключают влияние человеческого фактора.
Нисходящее тестирование (еще называемое нисходящей доработкой) нельзя назвать такой уж противоположностью восходящему тесту, но если через чур не всматриваться, то его можно назвать таким.
При нисходящем тестировании полностью пропадает нужда в оболочках, заглушки же остаются. Сам подход заключается в том, что программа собирается и тестируется «сверху вниз». Отдельно отрезается и тестируется лишь головной модуль. Когда тест этого модуля заканчивается, к нему подсоединяются один за другим прочие модули, вызываемые именно им, после чего тестируется полученная комбинация. Сам процесс повторяется пока не будут собраны протестированы абсолютно все модули.
При использовании такого подхода возникают несколько сложностей.
Первая, когда тестируемый модуль вызывает модуль более низкоуровневый.
Решается это достаточно просто, для имитации функций пока еще отсутствующих модулей необходимы те самые «заглушки», которые и берут на себя эту роль, моделируя недостающие функции.
Вторая сложность, возникающая у тех, кто использует нисходящую доработку, это подача данных тестирования. И вот с этим уже возникают проблемы.
Так как головной модуль не содержит все нужные операции для вывода и ввода, и соответственно, информация о тестировании не записывается в виде стандартных для пользователей внешних данных, передаваясь программе через предназначенные для неё устройства ввода, приходится исхитряться.
Обычно в хорошо запроектированной программе физические операции ввода и вывода – абстракция достаточно низкого уровня. Из-за чего, чтобы разрешить проблему достаточно эффективно, добавка модулей происходит не в строго нисходящей последовательности (сначала модули первого горизонтального уровня, затем следующего) а так, чтобы обеспечить операцию ввод-вывод как можно более быстро. При устранении этой сложности нисходящий тест обретает значительные плюсы, ведь последующие тесты готовятся по той-же форме, что рассчитана на пользователя.
Мнения профессионалов по поводу того, какая же из инкрементальных стратегий теста лучше, заметно отличаются. Обычно же решение выбора стратегии теста разрешается достаточно просто: каждый отдельный модуль стараются тестировать сразу же после написания, получая в итоге последовательность тестирования, в котором одни части программы могут быть нисходящими, а другие - восходящими.
2. Стратегии тестирования ПО
2.1 Стратегия Сэндвича
Тест при помощи метода Сэндвича (sandwich – бутерброд, англ.) заключает в себе объединение нисходящего и восходящего подходов. Сам метод заключается в попытке совместить плюсы от работы обоих подходов, избегая при этом их недостатков. Использование этого метода подразумевает то, что начинается одновременно и восходящий тест, и нисходящий, сверху и снизу соответственно. В итоге чего оба подхода «встречаются» где-то в середине, в точке, которая заранее зависит от выбранной тестовой программы, и которую необходимо определить. К примеру, если разработчик представит эту систему в виде нескольких уровней, необходимых для применения нисходящего метода, то все прочее он может выполнить с помощью восходящего.
Так как метод Сэндвича сохраняет достоинства обоих подходов, у него присутствует свойство начинать интеграцию системы в самом начальном этапе. А так как вершина программы приступает к действию в начале, то, как и в нисходящем методе мы можем воспользоваться работающим каркасом самой программы на начальных этапах. Из-за того, нижние уровни самой программы создаются с помощью восходящего подхода, снимаются те трудности нисходящего подхода, связанные с неспособностью тестировать к тестам определенных условий в глубине программы.
Тестирование при помощи метода Сэндвича является хорошим способом для интеграции крупномасштабных программ, к примеру операционных систем, или прикладных программных пакетов.
Модифицированный метод сэндвича.
При всех бесспорных качествах метода Сэндвича у него все-таки остается такой же минус, что у нисходящего метода, а именно – проблематичность досконального тестирования отдельных модулей. Восходящая часть тестирования с помощью этого метода решает вопрос для модулей нижних уровней, но для верхней части проблема все также остается. Модифицированный вариант метода Сэндвича предлагает нам сначала изолированное тестирование верхних уровней, а затем их сбор с помощью нисходящего метода.
2.2 Стратегия «белой коробки»
Термин «белая коробка» обозначает, что, создавая тестовые случаи, тестирующие пользуются любыми свободными данными о структуре кода. Технологические процессы, использующиеся при тестировании "белой коробки", называют статическим тестированием.
Данный метод не подразумевает выявление синтаксических ошибок, потому что такие огрехи обычно обнаруживает компилятор. Методы белого ящика сфокусированы на локализации ошибок, более тяжелых для выявления и которые труднее отыскать и зафиксировать. С помощью этих методов можно выявить логические ошибки, а также проверить степень тестирующего покрытия.
Тестовые методы, относящиеся к использованию стратегии белого ящика, пользуются управляющей логикой процедур. Они открывают ряд возможностей, таких как:
1. Гарантия того, что все независимые пути в модуле проверены как минимум один раз.
2. Проверка всех логических решений на то, истинны они или же ложны.
3. Исполнение абсолютно всех циклов, находящихся внутри операционных границ с использованием граничных значений.