Организация тестирования ПО. Критерии завершения тестирования.

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

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

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

Соотношение между процессами разработки и тестирования.

Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.

Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры от­дельной программы.

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

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

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

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

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

Существует несколько категорий тестов, каждая из которых направле­на на проверку определенных целей. К ним относятся тестирование полно­ты реализации, тестирование на предельных объемах, тестирование на пре­дельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совмес­тимости, тестирование надежности, тестирование восстановления, тестиро­вание удобства обслуживания, тестирование удобства установки и тестиро­вание документации.

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

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

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

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

1. Можно ли приспособить разработанный интерфейс для информи­рования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
2. Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
3. Понятна ли диагностика ошибок?
4. Проявляет ли все множество пользовательских интерфейсов посто­янство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
5. Содержит ли система опции, число которых чрезмерно или исполь­зование которых маловероятно?
6. Выдает ли система какие-либо подтверждения на все входные со­общения?
7. Легко ли и приятно ли использовать ПО?

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

Тестирование конфигурации оборудования обусловлено тем, что опе­рационные системы, СУБД и коммуникационные системы должны поддер­живать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы прове­рить ПО на каждой из них. Однако программу следует тестировать по край­ней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необ­ходимо тестировать все возможные его конфигурации.

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

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

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

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

Цель тестирования удобства установки - показать, что не удовлетво­ряются цели по части настройки ПО на конкретные условия эксплуатации.

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

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

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

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

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

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

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

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

Зависимость количества ошибок от продолжительности тестирования.

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

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

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

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

Другой способ получения такой оценки основан на статических сред­них величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени заверше­ния кодирования (до проведения сквозного просмотра или инспекции) со­ставляет примерно 4 - 8 на 100 операторов программы.

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

Если в программу внесено случайным образом S ошибок, при проверке обнаружено n+V ошибок (n – число найденных собственных ошибок; V – число найденных внесенных ошибок), то предполагаемое число первона­чально находящихся в программе собственных ошибок может быть рассчитано по формуле: .

Например, при обнаружении 20 собственных и 10 привнесенных оши­бок, при общем числе первоначально внесенных ошибок, равном 25, значе­ние N=25*20/10 = 50; т.е. на данном этапе предполагается, что в про­грамме имелось 50 собственных ошибок и тестирование должно быть про­должено.

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

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

где k - предполагаемое число собственных ошибок, S - число внесенных ошибок, n - число обнаруженных собственных ошибок.

Например, если утверждать, что в программе нет ошибок (k=0), и при внесении в программу 6 ошибок все они были обнаружены, а собственные ошибки обнаружены не были, то C=6/(6 + 0 + 1)=0,86. С другой сто­роны, чтобы достичь уровня доверия в 0,98 в программу необходимо ввести 39 ошибок: C=39/(39 + 0 + 1)=0,98.

Модель Миллса не лишена ряда недостатков, самые существенные из которых - это необходимость внесения искусственных ошибок (этот про­цесс плохо формализуем) и достаточно вольное допущение величины k (число собственных ошибок), которое основывается исключительно на интуиции человека, проводящего оценку, т.е. допускает большое влияние субъективного фактора.

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

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

Получается, что первая группа обнаружила N₁ ошибок, вторая – N₂ ошибок, а N₁₂ - это ошибки, обнаруженные обеими группами.

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

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

В частности, можно допустить, что

Значение N₁₂ известно, а E₁ и Е₂ можно определить как N₁₂/N₁ и N₁₂/N₂ . Таким образом, неизвестное количество ошибок в про1рамме можно определить по формуле:

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

где P(_N12i) - вероятность обнаружения N₁₂ "общих" ошибок тестирования программы двумя независимыми группами.

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

Исходя из этого, рассмотрим пример. Допустим, что тестируется про­грамма размером 1000 операторов; число ошибок, остающихся после ин­спекции исходного текста, оценивается в 5 на 100 операторов. Цель тести­рования - обнаружить 98% ошибок кодирования и логики и 95% ошибок проектирования.

Общее число ошибок составляет 500. Предполагается, что 200 из них составляют ошибки кодирования и логики, а 300 - ошибки проектирования. Следовательно, требуется найти 196 ошибок кодирования и логики и 285 ошибок проектирования.

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

Процентное отношение найденных ошибок по этапам тестирования.

Исходя из этих чисел, можно определить следующие критерии.

1. На этапе тестирования модулей необходимо найти и исправить 130 ошибок (65% от оцененных 200 ошибок кодирования и логики).
2. На этапе тестирования системы необходимо найти и исправить 6 ошибок и 105 (3% от 200 и 35% от 300).

Другая очевидная проблема для этого вида критериев - это проблема переоценки. Что если в приведенном примере к моменту начала проверки функций остается менее 240 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возника­ет переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало оши­бок.

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