Цели и задачи. Основные определения.




 

«Тестирование – процесс выполнения программы с намерением найти ошибки.» (Майерс)

«Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» (Дейкстра, 1970 г)

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

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

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

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

Тестирование программного обеспечения — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем.

Задачи тестирования программного обеспечения – снизить стоимость разработки путем раннего обнаружения дефектов.

 

Методологии тестирования

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

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

Рис. 11. Метод белого ящика

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

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

 

Рис. 12. Метод черного ящика

 

 

 


Тестирование черного ящика, нацеленное на проверку требований. Тесты для него и критерий полноты тестирования строятся на основе требований и ограничений, четко зафиксированных в спецификациях, стандартах, внутренних нормативных документах. Часто такое тестирование называется тестированием на соответствие (conformance testing). Частным случаем его является функциональное тестирование — тесты для него, а также используемые критерии полноты проведенного тестирования определяют на основе требований к функциональности.

Помимо методов тестирования «белый ящик» и «черный ящик» различают тестирование методом «серого ящика».

Рис. 13. Метод серого ящика

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

Уровни тестирования

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

Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика». В современных проектах модульное тестирование («юнит-тестинг») осуществляется разработчиками.

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

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

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

Интеграционное тестирование (Integration testing) – уровень тестирования, на котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования (юнит-тесты для модулей должны быть выполнены и найденные ошибки исправлены).

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

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

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

Системное тестирование (System testing) - это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы.

Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Системное тестирование выполняется инженерами по тестированию.

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

 

 

Рис.14. Уровни тестирования

Unit Testing
Integration Testing
System Testing
Acceptance Testing

Статическое тестирование (Static testing) – тестирование, в ходе которого тестируемая программа (код) не выполняется (запускается). Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами.

Примеры статического тестирования:

Обзоры (Reviews)

Инспекции (Inspections)

Сквозные просмотры (Walkthroughs)

Аудиты (Audits)

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Динамическое тестирование (Dynamic testing)– тестирование, в ходе которого тестируемая программа (код) выполняется (запускается).

Альфа-тестирование — тестирование в процессе разработки

Бета-тестирование — тестирование выполняется пользователями (end-users)

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

Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения.

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

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

Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.

«Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

***История.

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

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

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

Функциональное тестирование (functional testing)

– каждое функциональное требование транслируется в тест-кейсы (используя техники «черного ящика») для того, чтобы проверить, что система функционирует в точности, как и описано в спецификации (функциональных требованиях к системе)

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

Тестирование производительности (perfomance testing)

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

– продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях

– измерить, какая часть системы является причиной «плохой» производительности системы

– измерить время реакции на действие пользователя, время отклика на запрос, и т.д.

Стрессовое тестирование (stress testing)

– тестирование операционных характеристик приложения в условиях ограниченных ресурсов (например, скорость, память, место на диске и т.д.)

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

Нагрузочное тестирование (load testing)

– применяется для анализа работы информационных систем на различных уровнях нагрузки.

– основным понятием нагрузочного тестирования является "виртуальный пользователь". Управляя числом виртуальных пользователей, тестировщик управляет нагрузкой на систему.

– определяем, при какой максимальной нагрузке (максимальном количестве пользователей) система способна функционирвать в соответствии с требованиями к производительности

– HP LoadRunner

Тестирование удобства использования (usability testing)

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

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

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

Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства — с целью последующего более детального анализа.

Если юзабилити-тестирование выявляет какие-либо трудности (например сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование.

Наблюдение за тем, как люди взаимодействуют с продуктом, нередко позволяет найти для него более оптимальные решения. Если при тестировании используется модератор, то его задача — держать респондента сфокусированным на задачах (но при этом не „помогать“ ему решать эти задачи).

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

1. Речь модератора и респондента;

2. Выражение лица респондента (снимается на видеокамеру);

3. Изображение экрана компьютера, с которым работает респондент;

4. Различные события, происходящие на компьютере, связанные с действиями пользователя:

 

o Перемещение курсора и нажатия на клавиши мыши;

o Использование клавиатуры;

o Переходы между экранами (браузера или другой программы).

Все эти потоки данных должны быть синхронизированы по тайм-кодам, чтобы при анализе их можно было бы соотносить между собой.

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

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

Тестирование интерфейса пользователя (UI testing)

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

– проверяем, как приложение обрабатывает ввод с клавиатуры и «мышки» и как отображаются элементы графического интерфейса (текст, кнопки, меню, списки и прочие элементы).

Тестирование безопасности (security testing)

- оценка уязвимости программного обеспечения к различным атакам.

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

· попытки узнать пароль с помощью внешних средств;

· атака системы с помощью специальных утилит, анализирующих защиты;

· подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

· целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

· просмотр несекретных данных в надежде найти ключ для входа в систему.

Тестирование локализации (localization testing)

– проверяем функционирует ли система как ожидается под разными языковыми локализациями операционных систем

Тестирование совместимости (compatibility testing)

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

и др.

Процесс тестирования.

5.2.1 Этапы и задачи.

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

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

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

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

Рис. 15. Схема процесса тестирования

 

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

Организация тестирования программного обеспечения регулируется следующими стандартами:

  • IEEE 829-1998 Standard for Software Test Documentation.

Описывает виды документов, служащих для подготовки тестов.

  • IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing.

Описывает организацию модульного тестирования (см. ниже).

  • ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 и ГОСТ Р-2000, также принят IEEE под номером IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing.

Описывает требования к процедурам тестирования программных систем.

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

 

5.2.2 Принципы организации тестирования

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

Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.

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

Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, которые кажутся необычным или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».

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

 

1) людские ресурсы разработки, как правило, недостаточны;

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

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

 

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

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

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

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

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

В дополнение к этой психологической проблеме следует отметить

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

Тестирование можно уподобить работе корректора или рецензента

над статьей или книгой. Многие авторы представляют себе трудности,

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

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

 

Выделяются следующие организационные принципы управления тестированием:

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

• Необходимо досконально изучать результаты применения каждого теста.

• Тесты для неправильных и непредусмотренных входных данных

• следует разрабатывать так же тщательно, как для правильных и предусмотренных

• Необходимо проверять не только, делает ли программа то, для

• чего она предназначена, но и не делает ли она то, что не должна делать

• Не следует выбрасывать тесты, даже если программа уже не нужна

• Нельзя планировать тестирование в предположении, что ошибки

• не будут обнаружены

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

• Тестирование — процесс творческий.

 

 

Разъяснение организационных принципов тестирования:

1. Программирующая организация не должна сама тестировать

разработанные ею программы.

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

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

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

 

2. Необходимо досконально изучать результаты применения каждого теста.

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

 

3. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных.

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

 

4. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна

делать:

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

 

5. Не следует выбрасывать тесты, даже если программа уже не нужна.

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

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

 

6. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.

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

 

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

Этот принцип не согласуются с интуитивным представлением. На первый взгляд он лишен смысла, но, тем не менее, подтверждается многими программами. Например, допустим, что некоторая программа состоит из модулей или подпрограмм A и B. К определен-

ному сроку в модуле A обнаружено пять ошибок, а в модуле B –только одна, причем модуль A не подвергался более тщательному тестированию.

Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле В. Справедливость этого принципа подтверждается еще и тем, что для ошибок свойственно располагаться в программе в виде неких скоплений. В качестве примера можно рассмотреть операционные системы IBM S/370. В одной из версий операционной системы 47 % ошибок, обнаруженных пользователями, приходилось на 4 % модулей системы.

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

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



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-13 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: