Альфа-тестирование

Лекция 11 Стандарты в области обеспечения качества программных
систем
Прежде чем рассматривать стандарты, регламентирующие аспекты качества
программного обеспечения, необходимо сначала обсудить общие вопросы,
касающиеся качества любого вида продукции. К общим вопросам относятся
определения и терминология в данной области, основные концепции качества,
роль документации в обеспечении качества продукции, а также выбор и
применение международных стандартов качества. Безусловно, основными
стандартами в области качества стали международные стандарты серии ИСО
9000, разработанный Международной организацией по стандартизации.
Следующий
подраздел
посвящен
рассмотрению
общих
вопросов,
перечисленным выше, в свете стандартов серии ИСО 9000.
1 Основные положения стандартов серии ИСО 9000
Во-первых, под стандартами серии ИСО 9000 понимаются все международные
стандарты, разработанные Техническим комитетом 176 Административное
управление качеством и обеспечении качества. Международной организации
по стандартизации (ИСО). В настоящее время серия содержит все
международные стандарты с номерами от 9000 до 9004 (включая все части
ИСО 9000 и ИСО 9004), от 10001 до 10020 (включая все части), а также ИСО
8402. Ниже приведены названия основных стандартов, составляющих данную
серию.
ИСО 9000-1-94 Стандарты в области административного управления
качеством и обеспечения качества. Часть 1. Руководящие положения по
выбору
к
применению.
ИСО 9000-2-93 Стандарты в области административного управления
качеством и обеспечения качества. Часть 2. Общие руководящие положения
по
применению
ИСО
9001,ИСО
9002
и
ИСО
9003.
ИСО 9000-3-91 Стандарты в области административного управления
качеством и обеспечения качества. Часть 3. Руководящие положения по
применению
ИСО
9001
при
разработке,
поставке
и
техническом
обслуживании
ПО.
ИСО 9000-4-93 Стандарты в области административного управления
качеством и обеспечения качества. Часть 4. Руководящие положения по
административному
управлению
программой
общей
надежности.
ИСО 9001-94 Системы качества. Модель для обеспечения качества при
проектирование, разработке, производстве, монтаже и обслуживании.
ИСО 9002-94 Системы качества. Модель для обеспечения качества при
производстве,
монтаже
и
обслуживании.
ИСО 9003-94 Системы качества. Модель для обеспечения качества при
контроле
готовой
продукции
и
заключительных
испытаниях.
ИСO 9004-1-94 Административное управление качеством и элементы системы
качества.
Часть
1.
Руководящие
положения.
ИСО 9004-2-91 Административное управление качеством и элементы системы
качества.
Часть
2.
Руководящие
положения
по
услугам.
ИСО 9004-3-93 Административное управление качеством и элементы системы
качества. Часть 3. Руководящие положения по обработанным материалам.
ИСО 9004-4-93 Административное управление качеством и элементы системы
качества. Часть 4. Руководящие положения по повышению качества.
ИСО 10011-1-90 Системы качества. Руководящие положения по проверкам.
Часть
1.
Проверки.
ИСО 10011-2-91 Системы качества. Руководящие положения по проверкам.
Часть 2. Критерии квалификации экспертов-аудиторов систем качества.
ИСО 10011-3-91 Системы качества. Руководящие положения по проверкам.
Часть
3.
Административное
управление
программами
проверок.
ИСО 10012-1-92 Обеспечение качества измерительного оборудования.
Требования. Часть 1. Системы метрологического обеспечения измерительного
оборудования.
ИСО 10013 Руководства по качеству. Положения по разработке. (На стадии
издания).
ИСО 8402-94 Управление качеством и обеспечение качества. Словарь.
Увеличившаяся в настоящее время конкуренция между организациями,
производителями продукции, в том числе и программного обеспечения,
приводит к установлению более жестких требований к качеству это
продукции. Для того чтобы быть конкурентоспособными, организации
должны применять эффективные системы, ведущие к повышению качества
продукции и более совершенному удовлетворению требований своих
заказчиков. Правильно сформулированные и полные требования заказчика,
включенные в технические условия, еще не гарантирует того, что эти
требования будут полностью удовлетворены, так как в системе поставок и
обеспечения организации имеются недостатки. Это соображение обусловило
разработку стандартов, относящихся к системам качества и дополняющих
требования заказчика к продукции. Межународные стандарты серии ИСО
9000 предназначены для создания общей основы стандартов на системы
качества. Под системой качества понимается, согласно ИСО 8402,
совокупность организационной структуры, методик, процессов и ресурсов,
необходимых для осуществления общего руководства качеством продукции,
производимой
качеством
организацией.
организации
-
те
Система
аспекты
административного
общей
функции
управления
управления,
используемой организацией, которые определяют политику в области
качества выпускаемой продукции, цели организации и ее ответственность, а
также осуществляют их с помощью средств планирования, управления,
обеспечения и улучшения качества в рамках системы качества. Кроме цели
организации, на систему административного управления качеством влияют
выпускаемая ей продукция и характерные для этой организации методы
производства. В силу того, что методы производства организаций,
работающих даже в одной сфере, различны, да и цели организации не всегда
едины, системы качеств этих организаций не совпадает. Основной задачей
системы
административного
управления
качеством
является
усовершенствование систем и процессов для повышения качества продукции.
Стандарты серии ИСО 9000 устанавливают, какие именно элементы должны
быть включены в систему качества, тогда как организация сама должна
реализовать их с учетом конкретных целей, продукции и процессов, а также
специфических
методов,
используемых
данной
организацией.
Кроме того, руководящие положения и требования стандартов серии ИСО
9000 выражены в терминах целей системы качества, которые должны быть
достигнуты, и не предписывают способы достижения этих целей, оставляя
право выбора этих способов руководству организации.
2 Тестируемость программных средств
ПС следует проверять на качество функционирования в конкретном
окружении ИС путем повторных испытаний или отдельными проверками,
подтверждающими
зарубежные
сертификат
и
эксплуатационную
документацию. Обеспечение надежности на этапе кодирования и компиляции
программного обеспечения. Разработка любого программного средства может
быть представлена как процесс, состоящий из ряда последовательных
преобразований одного описания решаемой задачи в другое, начиная от
постановки задачи и заканчивая программой, реализованной в кодах
конкретной ЭВМ. Все время существования программного средства от
зарождения идеи по его созданию, до завершения его эксплуатации, обычно
определяют как жизненный цикл. Укрупнено можно выделить пять наиболее
важных этапов жизненного цикла программного средства (ЖЦ ПС):
спецификацию (10%), проектирование (10%), кодирование (10%), отладку
(20%) и сопровождение (50%). В скобках записаны относительные затраты
ресурсов на создание ПС. По затратам времени, человеческих и машинных
ресурсов все эти этапы не одинаковы. Наиболее “дорогими”, в этом смысле,
являются этапы, связанные с поиском ошибок в программах. Затраты ресурсов
на них могут быть равными, или даже превосходить совокупные затраты
ресурсов на остальных этапах. В стандарте DOD-S D-2167-A около 30%
требований, документов и соответствующих им процессов непосредственно
связаны с отладкой, тестированием и испытаниями программ. Эти затраты
быстро увеличиваются при возрастании требований к качеству ПС. По
оценкам, приведенным в работе, на долю устранения ошибок и сопровождение
ПС приходится почти 75% всех затрат. Следует учитывать, что значительная
часть работ, выполняемых на этапе сопровождения, связана с поиском и
устранением оставшихся в программе ошибок. Ретроспектива развития
методов и средств автоматизации программирования в этом отношении
говорит сама за себя. В модульном программировании акцент делается на
разбиение
программы
на
модули
таким
образом,
чтобы
данные
(обрабатываемые модулем) были спрятаны в нем. Эта доктрина, известная как
“принцип ограничения доступа к данным”, в значительной степени повысила
модифицируемость и эффективность порождаемого кода. Эволюция техники
модульного
программирования
ориентированного
стиля
привела
к
программирования,
появлению
который
объектново
многом
унифицировал процесс создания ПС. К достоинствам этого метода относится
то, что
в нем более полно
реализуется технология
структурного
программирования, облегчается процесс создания сложных иерархических
систем,
появляется
удобная
возможность
создания
пользовательских
библиотек объектов в различных областях применения. В 80-х годах
исследование причин неудач при реализации больших программных проектов
показало, что число ошибок в спецификациях на программы значительно
превышает их количество в программных кодах. Так около 56% ошибок
допускаются на этапе формулировки требований к программе при этом
расходуется в среднем 82% всех усилий, затраченных коллективом на
устранение ошибок проекта.
Комплексное
тестирование
является
процессом
контроля,
если
оно
выполняется в моделируемой среде, и процессом испытания, если
выполняется в среде реальной, жизненной. Тестирование приемлемости (accep
a ce es i g) — проверка соответствия программы требованиям пользователя.
Тестирование настройки (i s alla io es i g) — проверка соответствия каждого
конкретного варианта установки системы с целью выявить любые ошибки,
возникшие в процессе настройки Бета - тестирование программного
обеспечения. Другой способ проверки - бета-тестирование. В этом случае
разработчики
программного
обеспечения
разрешают
пользователям
попробовать предварительные версии продуктов. Однако большинство
разработчиков, с утверждают, что внешние бета-тестеры не выявляют такого
большого количества ошибок. Выводы. Быстрое увеличение сложности и
размеров современных комплексов программ при одновременном повышении
ответственности выполняемых функций резко повысило требования со
стороны пользователей к их качеству, надежности функционирования и
безопасности применения. Для каждого проекта ПС, выполняющего
ответственные функции, должны разрабатываться и применяться система
качества, специальные планы и программа, методология и инструментальные
средства, обеспечивающие требуемые качество, надежность и безопасность
функционирования.
Для
удовлетворения
высоких
требований
к
функционированию необходимы выделение из ЖЦ ПС задач и работ по
обеспечению качества программ, а также обучение и концентрация усилий
разработчиков на анализе и обосновании рентабельности выбранной
методологии и методов разработки комплексов программ. Широкий спектр
требований к качеству, в зависимости от назначения и области применения
ПС, приводит к необходимости адаптации стандартов, регламентирующих
системы качества предприятий-разработчиков. Последовательная детализация
рекомендаций базовых стандартов должна доводиться до формирования
должностных
инструкций
специалистам,
образуя
в
совокупности
иерархический комплекс нормативных документов системы качества
предприятия, обеспечивающий жизненный цикл сложных программных
средств. Только скоординированное, комплексное применение в проектах ПС
с начала проектирования современных методов и стандартов позволяет
достигать высокого качества, необходимого для использования ПС в
распределенных критических и сложных системах обработки информации.
Необходимо убедить руководителей проектов, заказчиков и разработчиков в
том, что тщательно регламентированное и достаточно полное системное
проектирование ПС и БД на основе современных методов и международных
стандартов выгодно с позиции сокращения ошибок и повышения качества
сложных комплексов программ.
3. Классификация тестирования программ
Существует несколько признаков, по которым принято производить
классификацию видов тестирования. Обычно выделяют следующие:
По объекту тестирования
Функциональное тестирование
 Тестирование производительности
 Нагрузочное тестирование
 Стресс-тестирование
 Тестирование стабильности
 Конфигурационное тестирование
 Юзабилити-тестирование
 Тестирование интерфейса пользователя
 Тестирование безопасности
 Тестирование локализации
 Тестирование совместимости
По знанию системы

Тестирование чёрного ящика
 Тестирование белого ящика
 Тестирование серого ящика
По степени автоматизации

Ручное тестирование
 Автоматизированное тестирование
 Полуавтоматизированное тестирование
По степени изолированности компонентов



Модульное тестирование
Интеграционное тестирование
Системное тестирование
По времени проведения тестирования
Альфа-тестирование

Дымовое тестирование (англ. smoke testing)
 Тестирование новой функции (new feature testing)
 Подтверждающее тестирование
 Регрессионное тестирование
 Приёмочное тестирование
 Бета-тестирование
По признаку позитивности сценариев

Позитивное тестирование
 Негативное тестирование
По степени подготовленности к тестированию

Тестирование по документации (формальное тестирование)
 Интуитивное тестирование (англ. ad hoc testing)
Уровни тестирования

Модульное тестирование — тестируется минимально возможный для
тестирования компонент, например, отдельный класс или функция. Часто
модульное
тестирование
осуществляется разработчиками программного
обеспечения.

Интеграционное
тестирование —
тестируются
интерфейсы
между
компонентами, подсистемами или системами. При наличии резерва
времени на данной стадии тестирование ведётся итерационно, с
постепенным подключением последующих подсистем.

Системное тестирование — тестируется интегрированная система на её
соответствие требованиям.

Альфа-тестирование —
имитация
штатными разработчиками,
либо
реальной
работы
с
системой
реальная
работа
с
системой
потенциальными пользователями/заказчиком. Чаще всего альфатестирование проводится на ранней стадии разработки продукта, но в
некоторых случаях может применяться для законченного продукта в
качестве внутреннего приёмочного тестирования. Иногда альфатестирование выполняется под отладчиком или с использованием
окружения, которое помогает быстро выявлять найденные ошибки.
Обнаруженные ошибки могут быть переданы тестировщикам для
дополнительного исследования в окружении, подобном тому, в котором
будет использоваться программа.

Бета-тестирование —
в
некоторых
случаях
выполняется
распространение предварительной версии (в случае проприетарного
программного
обеспечения
иногда
с
ограничениями
по
функциональности или времени работы) для некоторой большей
группы лиц с тем, чтобы убедиться, что продукт содержит достаточно
мало ошибок. Иногда бета-тестирование выполняется для того, чтобы
получить обратную связь о продукте от его будущих пользователей.
Часто для свободного и открытого программного обеспечения стадия альфатестирования характеризует
функциональное
наполнение
кода,
а бета-
тестирования — стадию исправления ошибок. При этом как правило на
каждом этапе разработки промежуточные результаты работы доступны
конечным пользователям.
Статическое и динамическое тестирование
Описанные ниже техники — тестирование белого ящика и тестирование
чёрного ящика — предполагают, что код исполняется, и разница состоит лишь
в той информации, которой владеет тестировщик. В обоих случаях
это динамическое тестирование.
При статическом тестировании программный код не выполняется — анализ
программы происходит на основе исходного кода, который вычитывается
вручную, либо анализируется специальными инструментами. В некоторых
случаях анализируется не исходный, а промежуточный код (такой как байткод или код на MSIL).
Также
к
статическому
тестированию
тестирование требований, спецификаций, документации.
относят
Регрессионное тестирование
После внесения изменений в очередную версию программы, регрессионные
тесты
подтверждают,
что
сделанные
изменения
не
повлияли
на
работоспособность остальной функциональности приложения. Регрессионное
тестирование
может
выполняться
как
вручную,
так
и
средствами автоматизации тестирования.
Тестовые сценарии
Тестировщики используют тестовые сценарии на разных уровнях: как в
модульном, так и в интеграционном и системном тестировании. Тестовые
сценарии, как правило, пишутся для проверки компонентов, в которых
наиболее высока вероятность появления отказов или вовремя не найденная
ошибка может быть дорогостоящей.
Тестирование «белого ящика» и «чёрного ящика»
В зависимости от доступа разработчика тестов к исходному коду тестируемой
программы различают «тестирование (по стратегии) белого ящика» и
«тестирование (по стратегии) чёрного ящика».
При тестировании белого ящика (также говорят — прозрачного ящика),
разработчик теста имеет доступ к исходному коду программ и может писать
код,
который
связан
с
библиотеками
тестируемого
программного
обеспечения. Это типично для модульного тестирования, при котором
тестируются только отдельные части системы. Оно обеспечивает то, что
компоненты конструкции — работоспособны и устойчивы, до определённой
степени. При тестировании белого ящика используются метрики покрытия
кода или мутационное тестирование.
При тестировании чёрного ящика, тестировщик имеет доступ к программе
только через те же интерфейсы, что и заказчик или пользователь, либо через
внешние интерфейсы, позволяющие другому компьютеру либо другому
процессу подключиться к системе для тестирования. Например, тестирующий
модуль может виртуально нажимать клавиши или кнопки мыши в
тестируемой программе с помощью механизма взаимодействия процессов, с
уверенностью в том, все ли идёт правильно, что эти события вызывают тот же
отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило,
тестирование чёрного ящика ведётся с использованием спецификаций или
иных документов, описывающих требования к системе. Обычно в данном виде
тестирования критерий покрытия складывается из покрытия структуры
входных данных, покрытия требований и покрытия модели (в тестировании
на основе моделей).
При тестировании серого ящика разработчик теста имеет доступ к исходному
коду, но при непосредственном выполнении тестов доступ к коду, как
правило, не требуется.
Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска
продукта (а также, неявно, к объёму тестирующего сообщества и
ограничениям на методы тестирования), тестирование «белого ящика» и
«чёрного ящика» имеет отношение к способам, которыми тестировщик
достигает цели.
Бета-тестирование в целом ограничено техникой чёрного ящика (хотя
постоянная часть тестировщиков обычно продолжает тестирование белого
ящика параллельно бета-тестированию). Таким образом, термин «бетатестирование» может указывать на состояние программы (ближе к выпуску
чем «альфа»), или может указывать на некоторую группу тестировщиков и
процесс, выполняемый этой группой. То есть, тестировщик может продолжать
работу по тестированию белого ящика, хотя программа уже «бета-стадии», но
в этом случае он не является частью «бета-тестирования».
Покрытие кода, по своей сути, является тестированием методом белого ящика.
Тестируемое программное обеспечение собирается
со
специальными
настройками или библиотеками или запускается в особом окружении, в
результате чего для каждой используемой (выполняемой) функции программы
определяется местонахождение этой функции в исходном коде. Этот процесс
позволяет
разработчикам и
специалистам по
обеспечению качества
определить части системы, которые при нормальной работе используются
очень редко или никогда не используются (такие как код обработки ошибок
и т. п.). Это позволяет сориентировать тестировщиков на тестирование
наиболее важных режимов.
Тестировщики могут использовать результаты теста покрытия кода для
разработки тестов или тестовых данных, которые расширят покрытие кода на
важные функции.
Как правило, инструменты и библиотеки, используемые для получения
покрытия кода, требуют значительных затрат производительности и/или
памяти, недопустимых при нормальном функционировании ПО. Поэтому они
могут использоваться только в лабораторных условиях.