Создание компании : в 2003 году компания была сформирована в результате...
Прежде чем переходить к описанию работ, следует разобраться с принятой...
Очень часто путают два понятия валидация и верификация. Кроме того, часто путают валидацию требований к системе с валидацией самой системы. Я предлагаю разобраться в этом вопросе.
В статье я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.
Пусть у нас есть проектируемый функциональный объект. Пусть этот объект рассматривается нами как часть конструкции другого функционального Объекта. Пусть есть описание конструкции Объекта, такое, что в нем присутствует описание объекта. В таком описании объект имеет описание как целого, то есть, описаны его интерфейсы взаимодействия с другими объектами в рамках конструкции Объекта. Пусть дано описание объекта как конструкции. Пусть есть информационный объект, содержащий требования к оформлению описания объекта как конструкции. Пусть есть свод знаний, который содержит правила вывода, на основании которых из описания объекта как целого получается описание объекта как конструкции. Свод знаний – это то, чему учат конструкторов в институтах – много, очень много знаний. Они позволяют на основе знанию об объекте спроектировать его конструкцию.
Итак, можно начинать. Мы можем утверждать, что если правильно описан объект как целое, если свод знаний верен, и если правила вывода были соблюдены, то полученное описание конструкции объекта, будет верным. То есть, на основе этого описания будет построен функциональный объект, соответствующий реальным условиям эксплуатации. Какие могут возникнуть риски:
1. Использование неправильных знаний об Объекте. Модель Объекта в головах у людей может не соответствовать реальности. Не знали реальной опасности землетрясений, например. Соответственно, могут быть неправильно сформулированы требования к объекту.
2. Неполная запись знаний об Объекте – что-то пропущено, сделаны ошибки. Например, знали о ветрах, но забыли упомянуть. Это может привести к недостаточно полному описанию требований к объекту.
3. Неверный свод знаний. Нас учили приоритету массы над остальными параметрами, а оказалось, что надо было наращивать скорость.
4. Неправильное применение правил вывода к описанию объекта. Логические ошибки, что-то пропущено в требованиях к конструкции объекта, нарушена трассировка требований.
5. Неполная запись полученных выводов о конструкции системы. Все учли, все рассчитали, но забыли написать.
6. Созданная система не соответствует описанию.
Понятно, что все артефакты проекта появляются, как правило, в завершенном своем виде только к концу проекта и то не всегда. Но, если предположить, что разработка водопадная, то риски такие, как я описал. Проверка каждого риска – это определенная операция, которой можно дать название. Если кому интересно, можно попытаться придумать и озвучить эти термины.
Что такое верификация? По-русски, верификация – это проверка на соответствие правилам. Правила оформляются в виде документа. То есть, должен быть документ с требованиями к документации. Если документация соответствует требованиям этого документа, то она прошла верификацию.
Что есть валидация? По-русски валидация – это проверка правильности выводов. То есть, должен быть свод знаний, в котором описано, как получить описание конструкции на основе данных об объекте. Проверка правильности применения этих выводов – есть валидация. Валидация - это в том числе проверка описания на непротиворечивость, полноту и понятность.
Часто валидацию требований путают с валидацией продукта, построенного на основе этих требований. Так делать не стоит.
Дадим несколько определений, определяющих общую структуру процесса сертификации программного обеспечения:
Сертификация ПО – процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие Заявителя, Сертифицирующего органа и Наблюдательного органа
Заявитель - организация, подающая заявку в соответствующий Сертифицирующий орган на получения сертификата (соответствия, качества, годности и т.п.) изделия.
Сертифицирующий орган – организация, рассматривающая заявку Заявителя о проведении Сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производящая набор процедур направленных на проведение процесса Сертификации ПО Заявителя .
Наблюдательный орган – комиссия специалистов, наблюдающих за процессами разработки Заявителем сертифицируемой информационной системы и дающих заключение, о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в Сертифицирующий орган .
Сертификация может быть направлена на получение сертификата соответствия, либо сертификата качества.
В первом случае результатом сертификации является признание соответствия процессов разработки определенным критериям, а функциональности системы определенным требованиям. Примером таких требований могут служить руководящие документы Федеральной службы по техническому и экспортному контролю в области безопасности программных систем .
Во втором случае результатом является признание соответствия процессов разработки определенным критериям, гарантирующим соответствующий уровень качества выпускаемой продукции и его пригодности для эксплуатации в определенных условиях. Примером таких стандартов может служить серия международных стандартов качества ISO 9000:2000 (ГОСТ Р ИСО 9000-2001) или авиационные стандарты DO-178B , AS9100 , AS9006 .
Тестирование сертифицируемого программного обеспечения имеет две взаимодополняющие цели:
· Первая цель - продемонстрировать, что программное обеспечение удовлетворяет требованиям на него.
· Вторая цель - продемонстрировать с высоким уровнем доверительности, что ошибки, которые могут привести к неприемлемым отказным ситуациям, как они определены процессом, оценки отказобезопасности системы, выявлены в процессе тестирования.
Например, согласно требованиям стандарта DO-178B, для того, чтобы удовлетворить целям тестирования программного обеспечения, необходимо следующее:
· Тесты, в первую очередь, должны основываться на требованиях к программному обеспечению;
· Тесты должны разрабатываться для проверки правильности функционирования и создания условий для выявления потенциальных ошибок.
· Анализ полноты тестов, основанных на требованиях на программное обеспечение, должен определить, какие требования не протестированы.
· Анализ полноты тестов, основанных на структуре программного кода, должен определить, какие структуры не исполнялись при тестировании.
Также в этом стандарте говорится о тестировании, основанном на требованиях. Установлено, что эта стратегия наиболее эффективна при выявлении ошибок. Руководящие указания для выбора тестовых примеров, основанных на требованиях, включают следующее:
· Для достижения целей тестирования программного обеспечения должны быть проведены две категории тестов: тесты для нормальных ситуаций и тесты для ненормальных (не отраженных в требованиях, робастных) ситуаций.
· Должны быть разработаны специальные тестовые примеры для требований на программное обеспечение и источников ошибок, присущих процессу разработки программного обеспечения.
Целью тестов для нормальных ситуаций является демонстрация способности программного обеспечения давать отклик на нормальные входы и условия в соответствии с требованиями.
Целью тестов для ненормальных ситуаций является демонстрация способности программного обеспечения адекватно реагировать на ненормальные входы и условия, иными словами, это не должно вызывать отказ системы.
Категории отказных ситуаций для системы устанавливаются путем определения опасности отказной ситуации для самолета и тех, кто в нем находится. Любая ошибка в программном обеспечении может вызвать отказ, который внесет свой вклад в отказную ситуацию. Таким образом, уровень целостности программного обеспечения, необходимый для безопасной эксплуатации, связан с отказными ситуациями для системы.
Существует 5 уровней отказных ситуаций от несущественной до критически опасной. Согласно этим уровням вводится понятие уровня критичности программного обеспечения. От уровня критичности зависит состав документации, предоставляемой в сертифицирующий орган, а значит и глубина процессов разработки и верификации системы. Например, количество типов документов и объем работ по разработке системы, необходимых для сертификации по самому низкому уровню критичности DO-178B могут отличаться на один-два порядка от количества и объемов, необходимых для сертификации по самому высокому уровню. Конкретные требования определяет стандарт, по которому планируется вести сертификацию.
20. Верификация и аттестация программного обеспечения
Верификацией и аттестацией называют процессы проверки и анализа, в ходе которых проверяется соответствие программного обеспечения своей спецификации и требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы.
Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом:
Верификация отвечает на вопрос, правильно ли создана система;
Аттестация отвечает на вопрос, правильно ли работает система.
Согласно этим определениям, верификация проверяет соответствие ПО системной спецификации, в частности функциональным и нефункциональным требованиям. Аттестация– более общий процесс. Во время аттестации необходимо убедиться, что программный продукт соответствует ожиданиям заказчика. Аттестация проводится после верификации, для того чтобы определить, насколько система соответствует не только спецификации, но и ожиданиям заказчика.
Как уже отмечалось ранее, на ранних этапах разработки ПО очень важна аттестация системных требований. В требованиях часто встречаются ошибки и упущения; в таких случаях конечный продукт, вероятно, не будет соответствовать ожиданиям заказчика. Но, конечно, аттестация требований не может выявить все проблемы в спецификации требований. Иногда недоработки и ошибки в требованиях обнаруживаются только после завершения реализации системы.
В процессах верификации и аттестации используются две основные методики проверки и анализа систем.
1. Инспектирование ПО. Анализ и проверка различных представлений системы, например документации спецификации требований, архитектурных схем или исходного кода программ. Инспектирование выполняется на всех этапах процесса разработки программной системы. Параллельно с инспектированием может выполняться автоматический анализ исходного кода программ и соответствующих документов. Инспектирование и автоматический анализ – это статические методы верификации и аттестации, поскольку им не требуется исполняемая система.
2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.
На рис. 20.1 показано место инспектирования и тестирования в процессе разработки ПО. Стрелки указывают на те этапы процесса разработки, на которых можно применять данные методы. Согласно этой схеме, инспектирование можно выполнять на всех этапах процесса разработки системы, а тестирование – в тех случаях, когда создан прототип или исполняемая программа.
К методам инспектирования относятся: инспектирование программ, автоматический анализ исходного кода и формальная верификация. Но статические методы могут проверить только соответствие программ спецификации, с их помощью невозможно проверить правильность функционирования системы. Кроме того, статическими методами нельзя проверить такие нефункциональные характеристики, как производительность и надежность. Поэтому для оценивания нефункциональных характеристик проводится тестирование системы.
Рис. 20.1. Статическая и динамическая верификация и аттестация
Несмотря на широкое применение инспектирования ПО, преобладающим методом верификации и аттестации все еще остается тестирование. Тестирование – это проверка работы программ с данными, подобными реальным, которые будут обрабатываться в процессе эксплуатации системы. Наличие в программе дефектов и несоответствий требованиям обнаруживается путем исследования выходных данных и выявления среди них аномальных. Тестирование выполняется на этапе реализации системы (для проверки соответствия системы ожиданиям разработчиков) и после завершения ее реализации.
На разных этапах процесса разработки ПО применяют различные виды тестирования.
1. Тестирование дефектов проводится для обнаружения несоответствий между программой и ее спецификацией, которые обусловлены ошибками или дефектами в программах. Такие тесты разрабатываются для выявления ошибок в системе, а не для имитации ее работы.
2. Статистическое тестирование оценивает производительность и надежность программ, а также работу системы в различных режимах эксплуатации. Тесты разрабатываются так, чтобы имитировать реальную работу системы с реальными входными данными. Надежность функционирования системы оценивается по количеству сбоев, отмеченных в работе программ. Производительность оценивается по результатам измерения полного времени выполнения операций и времени отклика системы при обработке тестовых данных.
Главная цель верификации и аттестации – удостовериться в том, что система "соответствует своему назначению". Соответствие программной системы своему назначению отнюдь не предполагает, что в ней совершенно не должно быть ошибок. Скорее, система должна достаточно хорошо соответствовать тем целям, для которых планировалась. Уровень необходимой достоверности соответствия зависит от назначения системы, ожиданий пользователей и условий на рынке программных продуктов.
1. Назначение ПО. Уровень достоверности соответствия зависит от того, насколько критическим является разрабатываемое программное обеспечение по тем или иным критериям. Например, уровень достоверности для систем, критическим по обеспечению безопасности, должен быть значительно выше аналогичного уровня достоверности для опытных образцов программных систем, разрабатываемых для демонстрации некоторых новых идей.
2. Ожидания пользователей. Следует с грустью отметить, что в настоящее время у большинства пользователей невысокие требования к программному обеспечению. Пользователи настолько привыкли к отказам, происходящим во время работы программ, что не удивляются этому. Они согласны терпеть сбои в работе системы, если преимущества ее использования компенсируют недостатки. Вместе с тем с начала 1990-х годов терпимость пользователей к отказам в работе программных систем постепенно снижается. В последнее время создание ненадежных систем стало практически неприемлемым, поэтому компаниям, занимающимся разработкой программных продуктов, необходимо все больше внимания уделять верификации и аттестации программного обеспечения.
3. Условия рынка программных продуктов. При оценке программной системы продавец должен знать конкурирующие системы, цену, которую покупатель согласен заплатить за систему, и назначенный срок выхода этой системы на рынок. Если у компании-разработчика несколько конкурентов, необходимо определить дату выхода системы на рынок до окончания полного тестирования и отладки, иначе первыми на рынке могут оказаться конкуренты. Если покупатели не желают приобретать ПО по высокой цене, возможно, они согласны терпеть большее количество отказов в работе системы. При определении расходов на процесс верификации и аттестации необходимо учитывать все эти факторы.
Как правило, в ходе верификации и аттестации в системе обнаруживаются ошибки. Для исправления ошибок в систему вносятся изменения. Этот процесс отладки обычно интегрирован с другими процессами верификации и аттестации. Вместе с тем тестирование (или более обобщенно – верификация и аттестация) и отладка являются разными процессами, которые имеют различные цели.
1. Верификация и аттестация – процесс обнаружения дефектов в программной системе.
2. Отладка – процесс локализации дефектов (ошибок) и их исправления (рис. 20.2).
Рис. 20.2. Процесс отладки
Простых методов отладки программ не существует. Опытные отладчики обнаруживают ошибки путем сравнения шаблонов тестовых выходных данных с выходными данными тестируемых систем. Чтобы определить местоположение ошибки, необходимы знания о типах ошибок, шаблонах выходных данных, языке программирования и процессе программирования. Очень важны знания о процессе разработке ПО. Отладчикам известны наиболее распространенные ошибки программистов (например, связанные с пошаговым увеличением значения счетчика). Также учитываются ошибки, типичные для определенных языков программирования, например связанные с использованием указателей в языке С.
Определение местонахождения ошибок в программном коде не всегда простой процесс, поскольку ошибка необязательно находится возле того места в коде программы, где произошел сбой. Чтобы локализовать ошибки, программист-отладчик разрабатывает дополнительные программные тесты, которые помогают выявить источник ошибки в программе. Может возникнуть необходимость в ручной трассировке выполнения программы.
Интерактивные средства отладки являются частью набора средств поддержки языка, интегрированных с системой компиляции программного кода. Они обеспечивают специальную среду выполнения программ, посредством которой можно получить доступ к таблице идентификаторов, а оттуда к значениям переменных. Пользователи часто контролируют выполнение программы пошаговым способом, последовательно переходя от оператора к оператору. После выполнения каждого оператора проверяются значения переменных и выявляются возможные ошибки.
Обнаруженная в программе ошибка исправляется, после чего необходимо снова проверить программу. Для этого можно еще раз выполнить инспектирование программы или повторить предыдущее тестирование. Повторное тестирование используется для того, чтобы убедиться, что сделанные в программе изменения не внесли в систему новых ошибок, поскольку на практике высокий процент "исправления ошибок" либо не завершается полностью, либо вносит новые ошибки в программу.
В принципе во время повторного тестирования после каждого исправления необходимо еще раз запускать все тесты, однако на практике такой подход оказывается слишком дорогостоящим. Поэтому при планировании процесса тестирования определяются зависимости между частями системы и назначаются тесты для каждой части. Тогда можно трассировать программные элементы с помощью специальных контрольных примеров (контрольных данных), подобранных для этих элементов. Если результаты трассировки задокументированы, то для проверки измененного программного элемента и зависимых от него компонентов можно использовать только некоторое подмножество всего множества тестовых данных.
Верификация ПО Верификация является одной из форм тестирования. Она была разработана в 80-х гг. Кларком и Эмерсоном в США, а также независимо Квайлом и Сифакисом во Франции. Тестирование ПО – процесс выявления ошибок в ПО. Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно установить корректность функционирования анализируемой программы. Верификация (от лат. verus – истинный, facere - делать) – проверка, проверяемость, способ обоснования (подтверждения) каких-либо теоретических положений путем их сопоставления с опытными данными. Верификация – это подтверждение на основе предоставления объективных свидетельств того, что установленные требования были выполнены (по ГОСТ ИСО).
Формальная верификация Формальная верификацияКак правило, большинством разработчиков программных систем для проверки правильности проекта практикуются методы имитационного моделирования и тестирования. Они довольно эффективны на самых ранних стадиях отладки, когда проектируемая система всё ещё изобилует ошибками, но результативность этих методов быстро снижается, как только система становится чище. Достойной альтернативой имитационному моделированию и тестированию являются методы формальной верификации. При имитационном моделировании и тестировании исследуются только некоторые из возможных сценариев поведения проектируемой системы, поэтому остаётся открытым вопрос о том, не содержится ли фатальная ошибка в незадействованных траекториях. Формальная верификация же обеспечивает исчерпывающий анализ всех возможных вариантов поведения системы.
Методы формальной верификации Автоматическое доказательство теорем – доказательство теорем, реализуемое программно. В основе лежит аппарат математической логики. Также использует идеи теории искусственного интеллекта. Процесс доказательства основывается на логике высказываний и предикатов. Проверка моделей. Метод автоматической верификации параллельных систем с конечным числом состояний. Символьное выполнение (графы). Абстрактная интерпретация.
Этапы формальной верификации на модели Этапы формальной верификации на модели Моделирование. Для проектируемой системы необходимо построить её абстрактную модель (например, конечную систему переходов), приемлемую для инструментальных средств верификации моделей программы. Спецификация. Эта задача состоит в формулировании свойств, которыми должна обладать проектируемая система. Определить, охватывает ли заданная спецификация все свойства, которыми должна обладать система, невозможно. Для аппаратуры и программного обеспечения, как правило, применяют динамические логики, временные логики и их варианты с неподвижными точками. Вычисления алгоритмов. Результатом вычислений алгоритма глобальной проверки на модели является множество состояний модели, в которых спецификация выполняется, а алгоритм локальной проверки на модели строит в качестве контрпримера некоторое вычисление (ошибочную трассу), которое показывает, почему формула не выполняется. Контрпример особенно важен для поиска тонких ошибок в сложных системах переходов.
Метод проверки на модели По сравнению с другими подходами в формальной верификации программ, метод проверки на модели обладает двумя замечательными преимуществами: Он полностью автоматический, и его применение не требует от пользователя никаких особых знаний в таких математических дисциплинах, как логика и теория доказательства теорем. Всякий, кто может провести моделирование проектируемой системы, вполне способен осуществить и проверку этой системы. Если проектируемая система не обладает желаемым свойством, то результатом проверки на модели будет контрпример, который демонстрирует поведение системы, опровергающее это свойство. Эта ошибочная трасса даёт бесценную информацию для понимания причины ошибки, равно как и важный ключ к решению возникшей проблемы. Основной недостаток метода проверки на модели это "комбинаторный взрыв", который возникает, когда в системе переходы в некоторых компонентах выполняются параллельно. В 1987 г. К.МакМиллан показал, что, используя, символьное представление графа переходов, можно верифицировать очень сложные системы. Новое символьное представление было основано на упорядоченных двоичных разрешающих диаграммах (OBDD) Бриана.
Понятие верификации ПО БКУ В РКК «Энергия» нельзя использовать понятие верификация в полном объеме, так как при создании очень сложных систем невозможна реализация полной проверки, так как существуют временные и стоимостные ограничения. Показатель качества отработки и испытаний ПО БКУ КА
Отработка и испытания ПО БКУ. На предприятии РКК «Энергия» для отработки ПО БКУ используются НКО, работающие в реальном масштабе времени. Комплексная отработка и испытания ПО осуществляются группой интеграции и тестирования по специально разработанным программам и методикам испытаний (ПМИ) (тестовым сценариям). НКО-1 НКО-2 (реальная машина БЦВС) Используется для интеграции и последующей отладки ПО БКУ в объеме: выборочные проверки магистральных путей наиболее вероятных нештатных ситуаций; контроль интерфейса,т.е. проверка ПО в рамках: обмен массивами и словами данных; передача командных массивов; передача ТМ-данных; проверка распределения ресурсов (памяти, процессорного времени, каналов I/O). Используется для испытаний, по- другому верификации, ПО БКУ в объеме: отработка ПО БКУ в соответствии с планом полета (ПП) и режимами КА; проверка на соответствие ПО спецификации.
Программа методика испытаний Для проведения проверки ПО разрабатываются программы методики испытаний (ПМИ). ПМИ для каждого сценария должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Тестовый сценарий Тестовый сценарий комплексной отладки строится на основе логической схемы процессов отладки. Сценарий должен отражать во времени возникновение событий и взаимосвязей между ними. Выбор дискретных моментов времени, в которые проводится оценка и принимаются управляющие воздействия, осуществляется в зависимости от специфики ПО и хода процесса реализации отладки. Тестовые сценарии пишут на языках, разработанных на предприятии. К таким языкам относятся: Д Диполь (использовался при создании СМ, ТГК и КА спутниковой системы связи «Ямал», также используется в КИС- контрольный испытательный стенд); L Lua (используется сейчас для МИМ1- малый исследовательский модуль); в внутренние тестовые языки.
Матрица прослеживаемости требований (НКО2) В матрице прослеживаемости требований представлен перечень всех требований, идентификатор программной единицы, наименование программной единицы, номер требований вышестоящего ТЗ и идентификатор теста, подтверждающего данные требования.
Протокол испытаний Протокол испытаний – это текстовый файл, содержащий в хронологическом порядке отклики системы на входные воздействия в ходе проведения испытаний. Протокол содержит московское время события, время относительно начала теста, значения устанавливаемых параметров и примечания, содержащие комментарии о событиях.
ТМ-архив Архив телеметрии – это файл, содержащий в закодированном виде набор телеметрических сообщений, полученных от системы в ходе проведения испытаний. Архив содержит бортовое время событий и значения телеметрических параметров. Программа Telemet2 позволяет представить архив телеметрии в виде текстового файла с комментариями и значениями параметров в десятичном и шестнадцатеричном виде.
Критерии приемки ПМИ для каждого теста должна содержать требования, определяющие критерий приемки. Объем и глубина проверок считаются достаточными, при условии выполнения следующих требований полноты тестирования: ПО БКУ должно функционировать во всех возможных полетных конфигурациях; проверены все функциональные альтернативы в соответствии с внешней спецификацией; отработаны основные нештатные ситуации; проверены граничные значения. ПМИ для каждого теста в разделе "Критерий оценки" должна содержать сведения, позволяющие установить соответствие между фактическими результатами теста и планируемыми результатами теста, а также допуски на каждый контролируемый параметр.
Тестирование белого ящика
Тестирование удобства использования
A) Нагрузочное тестирование
Тестирование производительности
Функциональное тестирование
Тестирование программного обеспечения
Под тестированием понимается процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки.
Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие признаки:
I) По объекту тестирования :
(определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе)
б) Стресс-тестирование
(оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования.)
в) Тестирование стабильности
4) Тестирование интерфейса пользователя
5) Тестирование безопасности
6) Тестирование локализации
7) Тестирование совместимости
II) По знанию системы :
1) Тестирование чёрного ящика
(тестируется объект, внутреннее устройство которого неизвестно)
(проверяется внутренняя структура программы, тестовые данные получают путем анализа логики программы)
III) По степени автоматизированности :
1) Ручное тестирование
2) Автоматизированное тестирование
3) Полуавтоматизированное тестирование
IV) По степени изолированности компонентов :
1) Компонентное (модульное) тестирование
2) Интеграционное тестирование
3) Системное тестирование
V) По времени проведения тестирования :
1) Альфа тестирование – закрытый процесс тестирования программы штатными разработчиками или тестировщиками. Альфа продукт чаще всего завершен только на 50%, присутствует программный код, но отсутствие значительная часть оформления.
2) Бета тестирование – интенсивное использование почти готовой версии программы с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом на рынок, к массовому потребителю. Для тестирования привлекаются добровольцы из числа обычных будущих пользователей.
Верификация программного обеспечения – это более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам (ISO 9000-2000 ). Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации.
