Файл: Тестирование и отладка программного обеспечения..pdf

1. Главная функция тестирования производительности - выявить, насколько система корректна работает при одновременном использовании данного продукта многими пользователями. В ходе тестирования выявляются потери данных пользователей, максимальное количество одновременный пользователей [11].

2. Тестирование установки призвано выполнить проверку, насколько корректно программа устанавливается на рабочую машину пользователя и удаляется с нее [11]. В настоящее время получила установка программ с помощью специальных программных модулей – инсталляторов. Если инсталлятор не предусмотрен, установка производится самостоятельно согласно инструкциям и спецификациям, либо специальному плану установки [18].

3. Тестирование удобства пользования характеризует усилия, необходимые для использования программного продукта, и индивидуальную оценку результатов его использования. Программа признается удобной в использовании тогда, когда обладает следующими свойствами: полезность, эффективность, производительность, осваиваемость, удовлетворенность, доступность [1]. Тестирование удобства может проводить не только тестировщик, но и группа конечных пользователей в тестовых режимах продукта. Это помогает собрать нужную и общую информацию о том, насколько конечным клиентам будет удобно пользоваться продуктом [19].

4. Тестирование на отказ и восстановление выполняет проверку программного продукта на возможность восстановиться после сбоя. В рамках тестирования специалисты занимаются рассмотрением всех возможных вариантов отказа системы и проверяют программу на адекватную реакцию на эти отказы [10]. Тестировщиками проверяются системы отката и восстановления, обеспечивающие целостность и сохранность данных ПО в случае сбоя в нормальной работе программы или окружения. Данное тестирование необходимо при проектировании продуктов, так как следствием потери данных является уход клиентов и снижение репутации компании [18].

5. Конфигурационное тестирование производит проверку работоспособности программы в разных конфигурациях системы, платформах, средах, устройствах и т.д. Цель тестирования - определить набор конфигураций, которые будут достаточны для работы системы на конкретном устройстве [10]. В качестве самого популярного примера такого тестирования можно назвать минимальные и подходящие системные требования для игр [19].

Последняя группа – тестирование, связанное с изменениями. Его функция – проверить систему после каких-либо внесенных изменений в ней. Это наиболее распространенное на практике тестирование, так как любое внесение изменений в программу может привести к ошибкам, которых не было до изменений [19]. Ф. Брукс в своей книге «Мифический человеко-месяц» писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечёт появление новой» [4, с. 70]. Связанные с изменениями виды тестирования применяются внесения необходимых изменений и корректировки в продукт. Программа должна быть заново протестирована, чтобы подтвердить, что ошибка была устранена [8].

Основными видами этого тестирования являются дымовое тестирование, регрессионное тестирование, тестирование сборки, санитарное тестирование.

1. Понятие «дымовое тестирование» пришло в тестирование из инженерной среды. При вводе в эксплуатацию нового оборудования считалось, что тестирование прошло удачно, если из установки не пошел дым. В области же тестирования программного обеспечения оно направлено на поверхностную проверку всех модулей приложения на предмет работоспособности и наличие быстро находимых критических и блокирующих дефектов. Результатом дымового тестирования является заключение о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику. Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования [20].

2. Регрессионное тестирование представляет собой полное тестирование продукта [11]. Это тестирование считается самым длительным и трудозатратным. На его этапе обнаруживается большинство багов и несоответствий системы и технического задания. Трудность заключается в том, что при обнаружении бага на финальном этапе тестирования и его устранения необходим повторный цикл тестирования [19].

3. Тестирование сборки служит для определения соответствия, выпущенной версии, критериям качества для начала тестирования. По цели оно схоже с дымовым тестированием, так как направленно на приемку новой версии в дальнейшее тестирование или эксплуатацию [20].

4. Санитарное тестирование применяется при проверке работы конкретной функции или блока. Относится к подмножествам регрессионного тестирования и определяет работоспособность части продукта после изменения. Следует различать дымовое и санитарное тестирование: дымовое тестирование – это больше тестирование основного функционала «вширь», для проверок «вширь», при санитарном же тестировании происходить проверка одной конкретной функции или модуля «вглубь» [19].

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

1.3 Парадигмы тестирования

На современном этапе развития тестирования сформировались две противоположные парадигмы – поведенческое и структурное тестирование [3].

Рассмотрим стратегию поведенческого тестирования. Она основана на технических требованиях к программному обеспечению. Другое название парадигмы - тестирование «черного ящика» (black-box testing). Подход заключается в том, что проведении процедуры тестирования не обязательно знать, как программа сконструирована внутри, известна только информация о его входах и выходах. При этом нет никаких данных о том, как именно программа преобразует входные данные в выходные. В связи с этим парадигма и получила свое название.

В рамках проведения тестирования «черного ящика» в соответствии с требованиями к программному продукту определяется набор тестовых входных данных и предсказывается корректное поведение программы. После этого программа выполняется на подготовленном наборе и результат сравнивается с предсказанным [2].

Критерием исчерпывающего входного тестирования является обнаружение всех ошибок в программе. Критерий может быть достигнут, если в качестве тестовых наборов использовать все возможные наборы входных данных. Однако построение исчерпывающего входного теста невозможно. Это объясняется двумя причинами: отсутствует возможность создания теста, гарантирующего отсутствие ошибок; разработка таких тестов противоречит экономическим требованиям [20].

С. В. Бирюков выделяет такие методы поведенческого тестирования, как тестирование потока управления, тестирование потоков данных, тестирование доменов, синтаксическое тестирование, тестирование систем с конечным числом состояний, тестирование циклов [3].

Перейдем к рассмотрению стратегии структурного тестирования. Она определяется структурой исследуемого программного обеспечения. Второе название парадигмы - тестирование «белого ящика» (white-box testing) или тестирование «прозрачного ящика». Как и в предыдущем случае, название происходит из структуры тестирования. В данном случае тестировщик исходит из знания того, как программный продукт сконструирован внутри. Нам известна не только информация о его входах и выходах, но, прежде всего, известен механизм преобразования входных данных в выходные [18].

Набор тестовых входных данных определяется исходя из ряда параметров. К ним относится структура программы, наличие и взаимное расположение в коде определенных конструкций языка программирования – циклов, условных операторов и т.п. Набор данных определяется с одной целью – обеспечить необходимое (в зависимости от выбранного метода структурного тестирования) покрытие программного кода. Предсказание результатов заключается в указании правильного направления потока управления и корректного состояния внутренних переменных на каждом шаге выполнения программы [3].

Основные методы структурного тестирования - покрытие операторов программы, покрытие ветвей программы, покрытие условий [3].

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

У данного подхода есть достоинства и недостатки. Одним из главных достоинств данного метода является то, что он включает в себя положительные черты тестирования «белого ящика» и тестирования «черного ящика». К достоинствам подхода можно отнести то, что человек, тестирующий программу, видит программу со стороны «черного ящика», а анализирует данные с позиции тестирования «белого ящика». Изначально при данном методе тестировщик и разработчик работают вместе, что позволяет избежать избыточные наборы тестовых данных, но и увеличивает время для исправления выявленных ошибок. Выделяются и недостатки, такие как отсутствие возможности протестировать все возможные тестовые наборы данных и ограниченность в анализе тестового покрытия, так как доступ к программному коду закрыт [23].

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

1.4 Отладка ошибок. Их виды

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

Отладка не является разновидностью тестирования. Тестирование ставит задачу определения наличия ошибок [21; 27], в то время как отладка служит для определения местоположения выявленных тестированием ошибок в исходном коде и их устранения [20]. Если цели этих двух этапов разработки программ различны, то, соответственно, используются различные методика и инструментарий. Важно разделять процесс тестирования и процесс отладки на два различных этапа работы над программой. Важно отметить, что эти два вида деятельности связаны: результаты тестирования являются исходными данными для отладки.

В настоящее время выделяется несколько способов отладки [6]. Перечислим их:

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

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

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

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

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

• нелогичный пользовательский интерфейс;
• неудовлетворенные ожидания;
• низкая производительность;
• аварийные завершения или разрушение данных [24].

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

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

В случае проектирования интерфейса Web-приложения, эта задача существенно усложняется. Здесь уже нет конкретных стандартов на пользовательский интерфейс. Самое главное, что надо учитывать при разработке интерфейса для Web-клиента, — это возможную низкую скорость трафика, поэтому следует создавать пользовательский интерфейс максимально простым и загружать с сервера только необходимые ресурсы чтобы максимально снизить время загрузки и ожидания пользователя. К примеру, простые решения, подобные CNN.com, нравятся практически всем пользователям. Использование простого набора ссылок выглядит куда лучше и работает быстрее, чем перегруженный различными функциями и графическими материалами интерфейс. Подобный перегруженный интерфейс легко может вызывать неудобство или даже отпугивать пользователя [8].