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

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

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

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

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

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

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

Томск 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), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытие кода или мутационное тестирование.

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

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

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

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

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

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

- Ручное тестирование;

- Прологи;

- Снижения;

- Обратная трассировка.

• Метод ручного тестирования.

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

• Метод пролога.

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

• Метод снижения.

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

• Метод обратной трассировки.

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

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

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

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

Стандарт устанавливает:

- требования к пакетам  программ (требования к их качеству);

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

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

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

Пользователями настоящего стандарта являются:

a) поставщики, когда они:

1) определяют требования  к пакету программ;

2) проектируют формат  для описания продуктов;

3) оценивают собственные  продукты;

4) выпускают декларации  о соответствии (Руководство ИСО/МЭК  22 [1]);

5) обращаются за сертификатами  или знаками соответствия (Руководство  ИСО/МЭК 23 [2]);

b) органы по сертификации, которые хотят применять схему  сертификации третьей стороной (международные,  региональные или национальные) (Руководство ИСО/МЭК 16 [3], Руководство  ИСО/МЭК 28 [4] и Руководство ИСО/МЭК  44 [5]);

c) испытательные лаборатории,  которые желают соблюдать инструкции  по тестированию при проведении  тестирования для выдачи сертификата  или знака соответствия (Руководство  ИСО/МЭК 25 [6]);

d) аккредитующие органы, проводящие аккредитацию органов  по сертификации и испытательных  лабораторий (Руководство ИСО/МЭК 40 [7] и Руководство ИСО/МЭК 58 [8]);

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

Один из базовых стандартов в области ИТ – стандарт ISO/IEC 12207:2008 Systems and Software Engineering – Software Life Cycle Processes. Его российский аналог, ГОСТ Р ИСО/МЭК 12207:2010 «Системная и программная инженерия. Процессы жизненного цикла программных средств», введен в действие весной 2012 года.

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

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

Термины и определения  относящиеся к тестированию, выбранные из стандарта ИСО/МЭК 12207-2010

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

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

4.51 тестовое покрытие (test coverage): Степень, с которой данный тест проверяет требования для системы или программного продукта

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

Технические процессы

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

если он не используется при оказании услуги.

Технические процессы состоят из следующих процессов:

a) определение требований  правообладателей (специальный случай  процесса определения требований  правообладателей, приведенного в  [18]);

b) анализ системных  требований (специальный случай  процесса анализа требований);

c) проектирование архитектуры  системы (специальный случай процесса  проектирования архитектуры, приведенного  в [18]);

d) процесс реализации (специальный  случай процесса реализации элементов  системы, приведенного в [18] и  далее разработанного в разделе  7 настоящего стандарта как процесса  реализации программных средств);

e) процесс комплексирования  системы (специальный случай процесса  комплексирования, приведенного в  [18]);

f) процесс квалификационного  тестирования системы (процесс,  который способствует достижению  результатов процесса верификации,  приведенного в [18]);

g) процесс инсталляции  программных средств (процесс,  который способствует достижению  результатов процесса передачи, приведенного в [18]);

h) процесс поддержки  приемки программных средств  (процесс, который способствует  достижению результатов процесса  передачи, приведенного в [18]);

i) процесс функционирования  программных средств (специальный  случай процесса функционирования, приведенного в [18]);

j) процесс сопровождения  программных средств (специальный  случай процесса сопровождения,  приведенного в [18]);

k) процесс изъятия  из обращения программных средств  (специальный случай процесса  изъятия и списания, приведенного  в [18]). 
 В общем случае технические процессы, представленные в настоящем стандарте, ориентированы на программные средства специальными случаями или вкладами в результаты технических процессов, представленных в [18]. Большинство из них схожи с процессами реализации программных средств, но сохраняют важные различия, например, анализ системных требований и анализ требований к программным средствам начинаются с разных исходных позиций и имеют разные предназначения.

Далее представлены несколько пунктов выбранные из стандарта:

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

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

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

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

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

В результате успешного  осуществления анализа системных требований:

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

b) выполняются соответствующие  технические приемы оптимизации  предпочитаемого проектного решения;

c) системные требования  анализируются на корректность  и тестируемость;

d) осмысливается воздействие  системных требований на среду применения;

e) требования расставляются  по приоритетам, утверждаются и обновляются;

f) устанавливается согласованность  и прослеживаемость между системными требованиями и базовой линией требований заказчика;

g) оцениваются изменения  базовой линии по стоимости,  графикам работ и воздействию технических решений;

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

6.4.2.3.2.1 Системные требования  должны оцениваться на основе  перечисленных ниже критериев:

a) прослеживаемость потребностей по приобретению;

b) согласованность с  потребностями по приобретению;

c) тестируемость;

d) осуществимость архитектурного  проекта системы;

e) осуществимость функционирования  и сопровождения. 
 6.4.5.3.2 Готовность к тестированию. Данный вид деятельности состоит из решения следующих задач:

6.4.5.3.2.1 Для каждого квалификационного  требования системы должны быть  разработаны и документированы:  набор тестов, тестовые примеры  (входы, выходы, критерии тестирования) и процедуры тестирования. Разработчик  должен гарантировать готовность  комплексированной системы к квалификационному тестированию. Примечание - Следует разработать стратегию регрессии, которая будет применяться для повторного тестирования в случаях, если в системе проводятся изменения.