Статическое и динамическое тестирование
Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет инженер по тестированию. В обоих случаях это динамическое тестирование.
При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL) [5].
На рисунке 3 представлена классификация техник тестирования программного обеспечения.
Рисунок 3 - Техники тестирования программного обеспечения
Также к статическому тестированию относят тестирование требований, спецификаций, документации.
Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет «над чем» производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий [6].
Модульное тестирование ( Unit testing ). Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 «Standard for Software Unit Testing», задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.
|
|
|
Интеграционное тестирование ( Integration testing ). Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
Системное тестирование ( System testing ). Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.
Рассмотрим подробнее каждый из уровней тестирования:
Модульное (unit) тестирование [1] – проверка функционирования первого компонента системы, самого элементарного. Обычно берется самый минимально возможный для тестирования компонент, например, одна функция программы.
В данном виде тестирования используется метод «белого ящика». Обычно модульное тестирование выполняется программистами.
|
|
|
Цель этого вида тестирования – изолировать отдельные части программы, протестироватьих и показать, что в отдельности они работоспособны.
Преимущество этого вида тестирования в том, что программисты довольно легко идут на изменение программы, не сопротивляясь нововведениям. Это объясняется тем, что протестировать отдельный модуль после изменения достаточно просто. В одном модуле получается достаточно маленький набор вариантов развития событий, и достаточно легко рассмотреть их все.
Этот вид тестирования помогает локализовать ошибку.
Локализовать ошибку – значит определить место, где содержится ошибка, т.е. в каком модуле, в какой функции она произошла. Когда мы находим ошибку, мы пытаемся установить, при каком наборе действий она возникает, и обобщить его. Затем пытаемся локализовать, т.е. определить в каком компоненте программы происходит сбой.
Юнит-тестирование не решит проблемы производительности, качества, безопасности, надежности. Поэтому остаётся еще целый ряд непроверенных параметров, для которых заданы определенные требования при разработке продукта. Проблемы взаимодействия компонентов этот вид тестирования также не решает.
|
|
|
Этот вид тестирования отдельно никогда не используют, только с другими видами тестирования.
На выходе этого вида тестирования мы получаем протестированные модули программы. Они в свою очередь подаются на вход следующего уровня тестирования – интеграционного тестирования.
Этот вид тестирования проверяет взаимодействие компонентов, взаимодействие модулей, которые общаются между собой. Модули передают информацию друг другу и каким-то образом связаны. Вот на этой стыковке и могут быть сбои в передаче этой информации. Либо она может передаваться не точно, либо вообще не передаваться, либо искажаться при передаче. Поэтому тестировать взаимосвязь компонентов нужно обязательно.
Таким образом, мы получаем на входе протестированные модули, затем объединяем их в группы, тестируем эти группы. И на выходе получаем протестированные группы модулей.
Этот вид тестирования проводится через интерфейс программы - методом «черного ящика».
Также с помощью метода «черного ящика» тестируется следующий уровень.
На вход системного тестирования мы подаем выходные данные интеграционного тестирования, т.е. протестированные группы модулей.
|
|
|
На выходе же системного тестирования мы получаем полностью протестированную программу.
В системном тестировании мы проверяем всю систему целиком.
Какие ошибки обычно выявляются на этом уровне тестирования?
Это ошибки надежности, безопасности, производительности. Также на этом уровне тестируется интерфейс для внешнего окружения, например, доступ к другим программам, доступ к операционной системе, доступ к «железу» компьютера. Знания внутреннего устройства работы программы не требуются.
Таким образом, модульное тестирование - проводим методом «белого ящика», обнаруживаем ошибки функциональности. Затем проводим интеграционное тестирование - методом «черного ящика», обнаруживаем ошибки взаимодействия модулей программы. И, наконец, системное тестирование – методом «черного ящика», выявляем ошибки производительности, надежности, безопасности и других параметров.
В системном тестировании можно выделить два этапа, которые будут являться стадиями разработки продукта: альфа-тестирование, бета-тестирование.
Выполнение задач процесса тестирования программных комплексов сопровождается разработкой различных артефактов (документов, моделей и других материалов проекта). Обычно разработка артефактов может проводиться в разной форме с разными требованиями к способу выполнения, рецензированию и качеству оформления.
Ниже представлены основные рабочие артефакты тестировщиков, в той или иной форме связанные со сценариями использования. Эти документы необходимо передавать заказчику или группе сопровождения и технической поддержки системы в случае необходимости.
План тестирования ( Test plan ). План тестирования определяется международным стандартом IEEE 829-1998. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания:
· что будет тестироваться (тестовые требования, тестовые варианты);
· какими методами и насколько подробно будет тестироваться система;
· план-график работ и требуемые ресурсы (персонал, техника) (Shedule).
Дополнительно описываются критерии удачного/неудачного завершения тестов, критерии окончания тестирования, риски, непредвиденные ситуации, приводятся ссылки на соответствующие разделы в основных документах проекта - план управления требованиями, план конфигурации [8].
Сценарий тестирования ( Test case , тест кейс). Это один из основных документов, с которыми имеет дело тестировщик. По сути, упрощенное описание теста. То есть входной информации, условий и последовательности выполнения действий и ожидаемого выходного результата. Учитывая, что даже успешно прошедшие тесты выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах. Одно дело, если вы собираетесь использовать тесты в ходе приемочных испытаний, проводимых заказчиком, и другое — в ходе внутреннего тестирования коробочного продукта.
Тест скрипт( Test script ).Обычно говорят о программной реализации теста, хотя скрипт может описывать и ручные действия, необходимые для выполнения конкретного тест кейса.
Набор тестов( Test set ). Как правило, сценарии тестирования объединяются в пакеты или наборы. Во-первых, это просто способ группирования тестов со сходными задачами, а, во-вторых, в такой набор можно включать зависимые тесты, которые должны выполняться в определенном порядке (поскольку последующие тесты используют данные, сформированные в ходе выполнения предыдущих).
Список идей тестов. Использование списка идей тестов для анализа и проектирования системы сценариев использования существенно упрощает задачу разработки необходимого набора тестов. Основной объем тестов строится как проверка различных вариантов выполнения каждого сценария использования. Однако тесты не сводятся к сценариям использования, как и задачи тестирования не сводятся только лишь к проверке функциональных требований к системе. Проверка нефункциональных требований может потребовать использования специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких ситуаций и создается список идей тестов. В него все желающие могут записать «что и как» стоит еще проверить. Этот список является внутренним рабочим документом группы тестирования. Наиболее разумная форма его ведения — электронный документ с минимальными формальными требованиями к оформлению.
Модель нагрузки.Сценарии использования, как правило, описывают взаимодействие с системой одного пользователя, часто этого бывает мало. При тестировании систем необходимо учитывать возможность параллельной работы большого числа пользователей, решающих различные задачи. Модель реальной нагрузки описывает характеристики типового «потока заявок», которые должны использоваться для нагрузочного тестирования, имитирующего работу системы в реальных условиях. Также могут быть созданы стрессовые модели нагрузки для тестирования отказоустойчивости системы.
Дефекты( Deffects ). Основополагающие артефакты процесса тестирования – описывают обнаруженные факты несоответствия системы предъявляемым требованиям [9]. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разработчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов.
Журнал тестирования. Каждое выполнение теста должно быть зарегистрировано в журнале тестирования. Журнал тестирования будет содержать записи о том, когда запускался каждый тест, итог выполнения каждого теста и может также содержать важные наблюдения, сделанные при выполнении теста. Зачастую журнал тестирования не ведут для нижних уровней тестирования (тестов компонент и интеграции ПО).
Отчеты о тестировании.Отчеты о тестированиимогут формироваться в различных точках в течение процесса тестирования. Отчеты о тестировании будут суммировать результаты тестирования и документировать любой анализ. Отчет о приемочном тестировании часто является договорным документом, подтверждающим приемку ПО.
Функциональность
Функциональное тестирование объекта-тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают диаграммы use-case, бизнес-функции и бизнес-правила. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям. В основе функционального тестирования лежит методика «черного ящика» [3]. Идея тестирования сводится к тому, что группа тестировщиков проводит тестирование, не имея доступа к исходным текстам тестируемого приложения. При этом во внимание принимается только входящие требования и соответствие им тестируемым приложением.
Цель тестирования:
Убедиться в надлежащем функционировании объекта тестирования. Тестируется правильность навигации по объекту, а также ввод, обработка и вывод данных.
Методика:
Необходимо исполнить (проиграть) каждый из use-case, используя как верные значения, так и заведомо ошибочные, для подтверждения правильного функционирования, по следующим критериям:
· продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные);
· продукт адекватно реагирует на неправильно вводимые данные (появляются соответствующие сообщения об ошибках);
· каждое бизнес-правило реализовано надлежащим (установленным) образом.
Критерии Завершения:
Все запланированные действия по тестированию выполнены.
Все найденные дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов).
Дата добавления: 2020-04-25; просмотров: 480; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!