Тема 2.6 Интеграционное тестирование. Системное тестирование. Тестирование пользовательского интерфейса.

Виды тестирования

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

Элементами модульного тестирование являются:

синтаксическая проверка — проверка с использованием неко­торого инструментального средства для выявления синтаксиче­ских ошибок в программном коде;

проверка соответствия стандартам кодирования — проверка кода на соответствие стандартам кодирования компании;

технический обзор программного кода.

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

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

Элементами интеграционного тестирования являются:

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

проверка промежуточных результатов -— проверка всех промежуточных результатов и файлов на наличие и корректность;

проверка интеграции — проверка того, что модули передают друг другу информацию корректно.

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

 Системное тестирование. Этот вид тестирования предназначен для проверки программной системы в целом, ее организации и функционирования на соответствие спецификациям требований заказчика. Его проводит независимый тестировщик после успешного завершения интеграционного тестирования.

Элементами системного тестирования являются:

граничное тестирование — тестирование в граничных условиях;

прогоночное тестирование — тестирование всех функциональных характеристик реальной работы системы;

целевое тестирование — тестирование на целевой платформе (по возможности);

проверка документации — проверка пользовательской документации на корректность;

другие тесты, определяемые тестировщиком.

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

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

проверка инсталляции — проверка на ясность и корректность инструкций по инсталляции;

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

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

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

3.Программные ошибки

Одними из распространенных определений программной ошибки являются следующие два:

программная ошибка — это расхождение между программой и ее спецификацией, причем тогда и только тогда, когда спецификация существует и она правильна;

программная ошибка — это ситуация, когда программа не делает того, чего пользователь от нее вполне обоснованно ожидает.

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

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

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

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

Некорректная обработка ошибок. Процедуры обработки ошибок — очень важная часть программы. Правильно определив ошибку, программа должна выдать о ней сообщение. Отсутствие такого сообщения является ошибкой в работе программы.

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

Ошибки вычислений. К ошибкам вычислений относятся ошибки, вызванные неправильным выбором алгоритма вычислений, неправильными формулами, формулами, неприменимыми к обрабатываемым данным. Самыми распространенными среди ошибок вычислений являются ошибки округления.

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

Ситуация гонок. Предположим, в системе ожидаются два события: А и Б. Если первым наступит событие А, то выполнение программы продолжится, а если событие Б, то в работе программы произойдет сбой. Разработчики предполагают, что первым всегда должно быть событие А, и не ожидают, что Б может выиграть гонки и наступить раньше. Такова классическая ситуация гонок.

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

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

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

4. Тестирование документации

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

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

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

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

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

 

Тема 2.7 Отладка ПО. Трансляция. Компоновка программы. Выполнение программы с целью определения логических ошибок

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

Отладка не является разновидностью тестирования, хотя слова «отладка» и «тестирование» часто используют как синонимы. Под ними подразумеваются разные виды деятельности:

— тестирование — деятельность, направленная на обнаружение ошибок;

— отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки;

— результаты тестирования являются исходными данными для отладки.

Эти два вида деятельности очень тесно связаны и поэтому они обычно рассматриваются совместно.

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

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

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

По оценкам специалистов, в общем времени разработки программного обеспечения, отладка занимает от 50 % до 90% (зависит от результатов проведения предыдущих этапов).

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

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

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

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

Статические методы включают:

— ручную прокрутку программы;

— прокрутку программы программными анализаторами (например, компилятором); автоматизированный анализ программы в этом случае проводится без выполнения ее на ЭВМ и поэтому попадает в категорию «статических»;

— коллективную проверку программ;

— проверку программы программистом-технологом с целью выявления и исправления в ней технологических ошибок.

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

Динамические методы связаны со значительным расходом машинного времени и, возможно, не меньшими затратами труда программиста. В этом случае отладка программ происходит совместно с их выполнением на ЭВМ. Динамические методы отладки программ, как правило, привязаны к конкретной ЭВМ и к конкретному транслятору (компилятору).

К динамическим методам относятся:

— тестирование;

— поиск ошибок с использованием системных средств;

— отладка программы в интерактивном режиме.

Важнейшее правило отладки: не делать следующего выхода на ЭВМ, пока не будет разобрана каждая найденная ошибка. Из этого правила существует единственное исключение: если найдены 5—6 ошибок, которые не дают эффекта, то можно сделать новый выход на машину (устранив эти ошибки), чтобы получить эффект в чистом виде (если он есть),поскольку наложение нескольких ошибок иногда может дать самый неожиданный результат.

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

Автономная отладка частей программы

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

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