Билет 1, 17 Стандарты еспд гост 19. 00177 Общие положения

• Название: Билет 1, 17 Стандарты еспд гост 19. 00177 Общие положения
• Дата: 20.05.2022
• Размер: 259.58 Kb.
• Имя файла: ekzamen_1.docx
• Тип: Документы; #540652
• страница: 2 из 3

Руководство 2 ИСО/МЭК, обобщая международный опыт стандартизации, представляет следующие возможные виды стандартов.

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

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

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

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

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

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

Нормативные документы по стандартизации в РФ установлены законом РФ «О стандартизации». К ним относятся:

• 
  - Государственные стандарты РФ (ГОСТ Р);
  
• 
  - применяемые в соответствии с правовыми нормами международные, региональные стандарты, а также правила, нормы и рекомендации по стандартизации;
  
• 
  - общероссийские классификаторы технико-экономической информации;
  
• 
  - стандарты отраслей;
  
• 
  - стандарты предприятий;
  
• 
  - стандарты научно-технических, инженерных обществ и других общественных объединений.
  
• 
  До настоящего времени действуют еще и стандарты СССР, если они не противоречат законодательству РФ.
  
• 
  – тестирование и отладка отдельных программных компонентов в реальном времени во взаимодействии с другими функциональными компонентами и с основными компонентами операционной системы и базы данных.
  
  
  

БИЛЕТ 11,19

Задание 1

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

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

• 
  1) функциональная пригодность, которая характеризует пригодность для применения, защищенность и точность,
  
• 
  2) надежность - характеризуется уровнем завершенности, т.е. отсутствием ошибок, устойчивостью к ошибкам и перезапускаемостью,
  
• 
  3) применимость -понятность в работе, обучаемость, простота использования,
  
• 
  4) эффективность - характеризуется ресурсной и временной экономичностью,
  
• 
  5) сопровождаемость - характеризуется удобством для анализа, стабильностью и тестированию,
  
• 
  6) переносимость - характеризуется адаптивностью и внедряемостью. Характеристика, которая отражает набор атрибутов, определяющих назначение программы в соответствии с техническим заданием - функциональная пригодность. Надежная программа должна отражать низкую вероятность отказа программы в процессе функционирования. Нарушения работы программы: сбои, отказы. Они отличаются временем восстановления работы программы. Если длительность восстановления работы программы меньше порогового значения, то это сбой, если больше - отказ. Надежность работы ПС характеризуется устойчивостью и восстанавливаемостью после сбоя или отказа. Чтобы определить надежность работы системы проводят ее тестирование. Устойчивость определяется при ресурсном тестировании (определяется время наработки на отказ) В реальных программируемых системах наработка на отказ должна быть соизмерима с наработкой на отказ аппаратуры.
  

Задание 2

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

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

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

Обязательное подтверждение соответствия осуществляется в формах:

·принятия декларации о соответствии;

·обязательной сертификации.

Не подлежит обязательному подтверждению соответствия:

·продукция, на которую не распространяется действие технических регламентов (далее – ТР);

·и которая при этом не включена ни в один из перечней, утверждаемых Правительством РФ.

Объектом обязательного подтверждения соответствия может быть только продукция, выпускаемая в обращение на территории РФ.

Декларация о соответствии и сертификат соответствия имеют равную юридическую силу и действуют на всей территории РФ в отношении каждой единицы продукции, выпускаемой в обращение на территории РФ:

·во время действия декларации о соответствии или сертификата соответствия;

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

БИЛЕТ 15,23

Задание 1

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

· • ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;

· • ГОСТ 34.201-89 Информационная технология, комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначения документов при создании автоматизированных систем;

· • РД 50-34.698-90 Информационная технология. Комплекс стандартов и руководящих указаний на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов;

· • ГОСТ 24.101-80 Система технической документации на АСУ. Виды и комплектность документов;

· • ГОСТ 24.102-80 Система технической документации на АСУ. Обозначение документов;

· • ГОСТ 24.103-84 Единая система стандартов автоматизированных систем управления. Автоматизированные системы управления. Основные положения;

И другие.

В свою очередь, международные стандарты регламентируют главным образом, документирование ПО. К ним относятся:

· • ISO 6592:1986. ОИ. Руководство по документации для вычислительных систем;

· • ISO 9294:1990-ТО. ИТ. Руководство по управлению документированием программного обеспечения;

· • ISO 9127. ИТ. Пользовательская и рекламная документация на пакеты программ.

По своему назначению и ориентации на определенные задачи и группы пользователей, документацию на ПО можно разделить на три типа:

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

· • эксплуатационную документацию, создаваемую для конечных пользователей ПО и позволяющую им осваивать и квалифицированно применять эти средства для решения конкретных функциональных задач;

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

Задание 2

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

· временная избыточность,

· информационная избыточность,

· программная избыточность.

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

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

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

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

Билет 20 задание 1

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

Восходящее тестирование

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

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

Нисходящее тестирование (нисходящая разработка)

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

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

Как подаются тестовые данные?

Плюсы метода

Метод совмещает тестирование модулей, тестирование сопряжений и частично тестирование внешних функций.

Когда модули ввода/вывода уже подключены тесты можно готовить в удобном виде.

Минусы метода

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

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

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

Оценочное тестирование, которое также называют «тестированием системы в целом», включает следующие виды:

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

• тестирование на предельных объемах - проверка работоспособности программы на максимально больших объемах данных, например, объемах текстов, таблиц, большом количестве файлов и т. п.;

• тестирование на предельных нагрузках - проверка выполнения программы на возможность обработки большого объема данных, поступивших в течение короткого времени;

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

• тестирование защиты - проверка защиты, например, от несанкционированного доступа к информации и др.

Задание 2

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

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



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

Для чего проводится сертификация услуг

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

Цели и задачи сертификации

Рассмотрим основные цели проверки услуги на соответствие установленным требованиям:

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

Билет 21

задание 1

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

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

Грамотно составленный (точнее, созданный) пакет программной документации избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно, просто отослав пользователя к документации. Это касается, прежде всего, важнейшего документа — ТЗ

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

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

В состав ЕСПД входят:

· основополагающие и организационно-методические стандарты;

· стандарты, определяющие формы и содержание программных

документов, применяемых при обработке данных;

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

Большая часть стандартов ЕСПД морально устарела. ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС.

Тем не менее, до пересмотра всего комплекса многие стандарты могут с пользой применяться в практике документирования ПС.

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

Международный стандарт ISO/IEC 12207:1995 на организацию ЖЦ продуктов программного обеспечения (ПО), казалось бы, весьма неконкретный, но вполне новый и отчасти «модный» стандарт.

Задание 2

Организация и этапы тестирования при испытаниях надежности сложных программных средств.



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

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

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

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

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

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

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

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

• 
  – объект испытаний, его назначение и перечень основных документов, определивших его разработку;
  
• 
  – цель испытаний с указанием всех требований технического задания, подлежащих проверке, и ограничений на проведение испытаний;
  
• 
  – собственно программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствии с тexническим заданием, и план тестирования для проверки по всем разделам технического задания и дополнительным требoвaниям, формализованным отдельными решениями разработчиков и заказчика;
  
• 
  – методики испытаний, однозначно определяющие все понятия проверяемых характеристик, условия и сценарии тестирования, средства, используемые для испытаний;
  
• 
  – методики обработки и оценки результатов тестирования по каждому разделу программы испытаний.
  

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

Билет 22. Задание 1

технологические особенности разработки больших программных комплексов

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

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

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

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

Задание 2.

Автоматизация тестирования. Термины и определения. Экономика тестирования.

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

В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).

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

Применение автоматизированного тестирования

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

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

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

Функциональное тестирование. Ясно, что здесь речь идёт о проверке нового функционала. Иногда бывает, что без автоматизации никак не обойтись. Даже если нужно выполнить тестирование только один раз. Обычно, впоследствии эти тесты и используются для регресса.

Установочное тестирование, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика.

Как автоматизировать тестирование?

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

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

Экономика тестирования

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

БИЛЕТ 31

Задание 1

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

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

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

Различают три типа форматирования текстовых документов:

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

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

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

• 
  поля страниц;
  
• 
  размер печатного листа и ориентация текста на нем;
  
• 
  расположение колонтитулов и отступ от основного текста;
  
• 
  число колонок текста (газетный стиль).
  

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

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

Задание 2

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

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

В состав ЕСПД входят:

• 
  § основополагающие и организационно-методические стандарты;
  
• 
  § стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;
  
• 
  § стандарты, обеспечивающие автоматизацию разработки программных документов.
  

Перечень документов ЕСПД обширен. Одним из основных стандартов является ГОСТ 19.101-77ЕСПД. Виды программ и программных документов.

В Российской Федерации действует ряд стандартов на документирование программного обеспечения, разработанных на основе прямого применения международных стандартов ИСО и МЭК.

• 
  ГОСТ Р ИСО/МЭК ТО 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения
  
• 
  ГОСТ Р ИСО/МЭК 12119-2000. Информационная технология. Пакеты программ. Требования к качеству и тестирование.
  

• 
  ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов
  

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

БИЛЕТ 32

Задание 1
Описание должно было в себя включать:

• 
  Планы разработки ПО
  
• 
  Требования к ПО
  
• 
  Описание реализации требований к ПО
  
• 
  Таблицы трассируемости(соответствия) требований к ПО и реализации
  
• 
  Описание тестов на ПО (Примеры и процедуры верификации ПО)
  
• 
  Таблицы трассируемости(соответствия) требований к ПО и тестов
  
• 
  Отчет об обнаруженных проблемах
  
• 
  Указатель конфигурации(описание версии ПО и совместимости со сторонним ПО и оборудованием)
  

Задание 2

Техническое задание должно содержать следующие разделы:

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

В разделе "Основание для разработки" должны быть указаны:

• 
  документ (документы), на основании которых ведется разработка;
  
• 
  организация, утвердившая этот документ, и дата его утверждения;
  
• 
  наименование и (или) условное обозначение темы разработки.
  
  
  

В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.