Методы и стандарты тестирования программного обеспечения

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ 

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ

 

Факультет инновационных  технологий (ФИТ)

 

Кафедра информационного  обеспечения инновационной деятельности (ИОИД)

 

 

 

 

Методы и стандарты  тестирования программного обеспечения

Реферат по дисциплине «Программная инженерия»

 

 

 

 

 

 

Выполнила студентка группы 18101 _____________А.А.Серикова «_____» ______________ 2013 г.   Принял заведующий кафедрой ИОИД ______________С.Л.Миньков «_____» ______________ 2013 г.

 

 

 

 

 

 

 

 

Томск 2013

ВВЕДЕНИЕ 3

1. ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ (ПО) 5

1.1. ПРИНЦИПЫ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПО 5

1.2. ЭТАПЫ ТЕСТИРОВАНИЯ ПО 5

1.3. ЦЕЛИ И ЗАДАЧИ ТЕСТИРОВАНИЯ ПО 7

2. МЕТОД ТЕСТИРОВАНИЯ И ОТЛАДКИ ПО 9

2.1. МЕТОДЫ ТЕСТИРОВАНИЯ ЧЕРНОГО И БЛОГО ЯЩИКА 9

2.2. МЕТОДЫ ОТЛАДКИ ПО 10

3. СТАНДАРТЫ ТЕСТИРОВАНИЯ ПО 13

3.1. СТАНДАРТ ГОСТ Р 12119-2000 «ИТ. ПАКЕТЫ ПРОГРАММ. ТРЕБОВАНИЯ К КАЧЕСТВУ И ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИ» 13

3.2. СТАНДАРТ ГОСТ Р ИСО/МЭК 12207-2012 «ИТ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» 14

ЗАКЛЮЧЕНИЕ 15

СПИСОК ЛИТЕРАТУРЫ 15

 

ВВЕДЕНИЕ

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

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

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

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

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

 

1. ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ (ПО)

1. ПРИНЦИПЫ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПО

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

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

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

2. ЭТАПЫ ТЕСТИРОВАНИЯ ПО

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

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

Существуют следующие подходы  к формулированию стратегии тестирования:

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

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

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

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

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

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

3. ЦЕЛИ И ЗАДАЧИ ТЕСТИРОВАНИЯ ПО

Цели тестирования:

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

Задачи тестирования:

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

 

2. МЕТОД ТЕСТИРОВАНИЯ И ОТЛАДКИ ПО

1. МЕТОДЫ ТЕСТИРОВАНИЯ ЧЕРНОГО И БЛОГО ЯЩИКА

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

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

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

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

Если «альфа-»  и «бета-тестирование» относятся  к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого  ящика» и «чёрного ящика» имеет отношение  к способам, которыми тестировщик  достигает цели.

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