Изучить ошибки кодирования информационной системы

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

Журнал отслеживания дефектов.

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

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

Описание проявления дефекта и способа его воспроизведения, возможно, со снимками экрана (обязательное поле).

Соответствует дефекту №» — указание на родственный дефект, проявлением или частным случаем которого является (обязательное поле). Если поле не заполнено, дефект считается уникальным.

Оценка важности (приоритета) в виде P1(высокий приоритет) — P5 (низкий приоритет) (обязательное поле). Эта оценка дается экспертным образом исходя из следующих соображений: наивысший приоритет получают дефекты, без устранения которых эксплуатация системы является в принципе невозможной, низший – дефекты, которые не являются принципиальными для работы системы, например, недостатки стилевого оформления.

Ответственный за исправление (обязательное поле). Это поле указывает, кто из разработчиков будет заниматься исправлением дефекта.

Ожидаемое время исправления (EFT) (обязательное поле). Это поле выражает ожидаемые трудозатраты исполнителя на исправление дефекта.

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

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

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

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

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

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

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

Литература

1. Канер, Фолк, Нгуен, Тестирование программного обеспечения. (Перевод с английского) (2000, издательство ДиаСофт, ISBN 966-7393-87-9)

2. Бахтизин В. В., Глухова Л. А. Стандартизация и сертификация программного обеспечения: Учеб. пособие/ В. В. Бахтизин, Л. А. Глухова — Мн.: БГУИР, 2006. — 200с.:ил.

3. Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование: Издательский дом «Вильямс» /Серия института качества программного обеспечения — 374с.:ил.

4. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. М.:БИНОМ, 2008, 368c. ISBN 978-5-94774-825-3

5. Интернет-ресурс http://www.intuit.ru/department/se/testing/

При разработке
кодов применяются разные системы и
методы кодирования (их построение).

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

Порядковая
— порядковая нумерация всех позиций
номенклатуры, без пропуска свободных
номеров.

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

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

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

Комбинированная
— объединение в одном коде нескольких
признаков.

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

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

Стадии преобразования экономической информации

1. Сбор
   и регистрация информации.

На
предприятии сбор и регистрация информации
происходит при выполнении различных
хозяйственных операций (прием готовой
продукции, получение и отпуск материалов,
…), в банках – при совершении
финансово-кредитных операций с
юридическими и физическими лицами. В
процессе сбора фактической информации
производится измерение, подсчет,
взвешивание материальных объектов,
подсчет денежных купюр, получение
временных и количественных характеристик
работы отдельных исполнителей. Сбор
информации регистрируется на материальном
носителе (документе, машинном
носителе).Запись в первичные документы
в основном осуществляется вручную,
поэтому процедуры сбора и регистрации
остаются наиболее трудоемкими и требуют
автоматизации.

Технические
средства:

1. персональные
   компьютеры для ввода информации
   документов и запись на машинный носитель;

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

3. считыватели
   пластиковых карточек;

1. Передача
   информации.

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

Комплекс
средств передачи информации:

1. локальные
   вычислительные сети;

2. региональные
   вычислительные сети расширенного
   масштаба;

3. глобальные
   вычислительные сети (Интернет);

Технические
средства:
модемы, факс-модемы, сетевой коммуникационное
оборудование.

1. Хранение
   и накопление информации.

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

Технические
средства:

Базы данных
хранятся на серверах БД, локальных
компьютерах.

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

1. Обработка
   информации.

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

Технические
средства:

Обработка
информации в ИС выполняется с помощью
компьютеров, которые делятся на классы:

1. микрокомпьютеры
   – используются автономно в виде ПК,
   либо в сети в качестве рабочих станций,
   оснащенные современными микропроцессорами
   (Intel?
   AMD
   и др.), имеют различную архитектуру
   (ряд IBM
   PC?
   Macintosh
   и др.). В эту группу входят портативные
   компьютеры.

2. Мини-компьютеры
   – машины среднего уровня по
   производительности и серверным
   возможностям.

1. Формирование
   результатной информации.

В ходе решения
задач на компьютере формируются
результатные документы, сводки, которые
печатаются или представляются в
электронном виде и предоставляются
пользователям.

Технические
средства:

для отображения
информации на экране используются
видеомониторы;

для вывода информации
используются принтеры, графопостроители.

Методы
доступа к БД. Системы управления базами
данных. Понятие данных и баз данных.
Структура файла БД, ее описание.

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

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

Например:
Программа Суперкалк обрабатывает данные
(таблицы) с расширением .cal;
программа EXEL
– с.xls;
ППП Clipper
— .dbf.

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

СУБД

Для
создания внутримашинного информационного
обеспечения (БД) используются СУБД –
системы управления и манипулирования
данными в базе данных (БД).

База
данных (БД) – это поименованная
совокупность специальным образом
организованных наборов данных, хранящихся
на диске.

Управление
БД включает в себя ввод данных, их
корректировку и манипулирование данными,
т.е. добавления, извлечения, обновления.

Развитые
СУБД обеспечивают независимость
прикладных программ, работающих с ними,
от конкретной организации информации
в базах данных. В зависимости от способа
организации данных различают: сетевые,
иерархические, распределенные, реляционные
СУБД.

Из
имеющихся СУБД наибольшее распространение
получили СУБД DBase
III,
Dbase
IV,
СУБД «Rebus»,
FOXPRO,
Microsoft
ACCESS,
Paradox,
а также СУБД компании Oracle
Informix,
Sybase,
Progress.

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

Из имеющихся пакетов
можно выделить следующие:

Frame work, Microsoft Offic

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

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

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

Структура
файла БД, ее описание.

Каждый
справочник в базе данных имеет свой
идентификатор (имя файла БД). В качестве
образца справочника предложен «Справочник
постоянных удержаний из заработной
платы»,
его идентификатор Zrp_Uder.dbf,
где ZRP_Uder
— имя (условное обозначение) справочного
массива, .dbf
— расширение файла базы данных (расширение
.dbf
соответствует всем исходным файлам
базы данных).

Файлы
отчетов (результатные файлы) имеют
расширение .frm
В таблице 1
приведен а структура справочника системы
ПРОНАР.

Структура
справочника постоянных удержаний из
заработной платы Zrp_Uder.dbf

_______________________________________________________________________Таблица1____

№ Наименование
Условное обоз Тип Длина Точ-
Назначение

п.п
показателя начение поля
ность показателя
__________________________________________________________________________

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

следующей
структуры:

1.
Квартплата KV_PLATA
число 6 2 сумма
квартпл.

2.
В сбербанк BANK_SUM
число 6 2 сумма
отчислен.

в
сбербанк

3.
Ссуда SSUDA
_MAX
число 6 2 сумма выданной

работнику
ссуды

4.
Ссуда ежемесяч. SSUDA_SUM
число 6 2 сумма
ежемесяч.

отчислений
по

ссуде
из з.пл.

____________________________________________________________________________

 Пример:
«Справочник постоянных удержаний
из ЗРП» используется
при начислении удержаний из заработной
платы работников предприятия.

Данные
в справочник закладываются один раз
на определенный длительный период.
Например, выданная работнику ссуда
вводится в поле SSUDA,
а сумма ежемесячных отчислений по
ссуде в поле SSUDA_SUM
— эта сумма

в
дальнейшем отражается в
«Расчетно-платежной ведомости»
и «Расчетном
листке» в
графе «Ссуда»,
используется
для контроля
отчислений в сбербанк, по ссуде и
квартплате из начисленной суммы ЗРП
работнику. По мере ежемесячных
отчислений по ссуде при начислении
удержаний из ЗРП работника, значение
поля SSUDA
контролируется программой, чтобы не
была превышена выданная работнику
сумма ссуды. Аналогично дать описание
остальным значениям полей данного
справочника.

Образец
заполнения справочника удержаний:

На
каждого работника предприятия в базе
данных «Лицевые
счета» бухгалтер
по мере необходимости вводит данные
о постоянных ежемесячных удержаниях
из ЗРП в
соответствующий справочник, который
выглядит так:

Таблица
2

_____________Справочник
постоянных удержаний_____________

Работник
 Иванов
И.И. Таб.№ 153 Должность — бухгалтер

Ежемесячные
Сумма max

отчисления

Квартплата
 
120.00

В
сбербанк  
300.00

Ссуда
   
250.00

5000.00

____________________________________________________________________

Способы
размещения информации в ПД.

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

При линейной форме
размещения реквизиты располагаются
построчно один за другим. Для каждого
реквизита предусматривается место для
записи его наименования (сверху) и
значения (снизу).

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Курсовая работа

Тестирование информационных систем

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ОСНОВЫ ТЕСТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. Понятие «тестирования информационных систем»

1.2. Критерии тестирования

1.3. Принципы тестирования

ГЛАВА 2. МЕТОДЫ ТЕСТИРОВАНИЯ

2.1. Тестирование «белого ящика»

2.2. Тестирование «черного ящика»

ГЛАВА 3. ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

ЗАКЛЮЧЕНИЕ

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

ПРИЛОЖЕНИЕ. ПРИМЕНЕНИЕ СТАНДАРТА IEEE STD 829 ПРИ ПЛАНИРОВАНИИ И ВЫПОЛНЕНИИ ФУНКЦИОНАЛЬНОГО И НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ВВЕДЕНИЕ

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

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

Современный персональный компьютер имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

· аппаратная сложность опережает наше умение строить ПО, использующие потенциальные возможности аппаратуры;

· наше умение строить программы отстает от требований к новым программам;

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

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

· управление проектом в виде координации усилий проектной команды, направленных на достижение целей проекта оптимальным путем;

· постановка задачи в виде определения требований и последующих работ с ними;

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

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

· тестирование ПО – процесс, решающий задачу верификации соответствия требований выдвинутых к ИС и их программной реализации;

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

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

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

В соответствии с целью были поставлены следующие задачи:

1. проанализировать литературу по теме курсовой работы;

2. рассмотреть и изучить понятие «тестирование программного обеспечения»;

3. выделить виды тестирования программного обеспечения;

4. изучить основные принципы и критерии, предъявляемые к тестированию программного обеспечения;

5. изучить основные методы тестирования программного обеспечения;

6. протестировать на основе изученного материала информационную систему «Учебно-методический ресурс».

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

Первая глава посвящена изучению такого понятия, как «тестирование программного обеспечения».

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

В третьей главе рассматривается процесс тестирования фрагмента информационной системы «Учебно-методический ресурс».

1.1. Понятие «тестирования информационных систем».

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

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

Программа – это аналог обычной формулы в математике.

Формула для функции f, полученной суперпозицией f1, f2, … fn – выражение, описывающее эту суперпозицию.

f=f1*f2*f3*…*fn

Если аналог f1, f2, … fn — операторы языка программирования, то их формула – программа.

Существует два метода обоснования истинности формул:

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

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

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

Применение интерпретационного подхода в форме экспериментов над исполняемой программой составляет суть отладки и тестирования.

Отладка(debug, debugging) – процесс поиска, локализации и исправления ошибок в программе. [6, c. 215]

Термин «отладка» в отечественной литературе используется двояко: для обозначения активности по поиску ошибок (собственно тестирование), по нахождению причин их появления и исправлению, или активности по локализации и исправлению ошибок.

Тестирование – это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. [11, c. 5]

Тестирование – это процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. [2, с. 13]

Тестирование – это контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок. [7, c. 27]

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

Шаги процесса задаются тестами.

Каждый тест определяет:

· Свой набор исходных данных и условий для запуска программы.

· Набор ожидаемых результатов работы программы.

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

^
На этапе кодирования программист пишет программы и сам их тестирует. Технология тестирования на этом этапе называется тестированием «стеклянного ящика» (glass box). Иногда ее называют тестированием «белого ящика» (white box) в противо­положность классическому понятию «черного ящика» (black box).

При тестировании «черного ящика» программа рассматри­вается как объект, внутренняя структура которого неизвестна.

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

При тестировании «стеклянного ящика» ситуация совер­шенно иная. Тестировщик (как правило, это программист) раз­рабатывает тесты, основываясь на знании исходного кода, к ко­торому он имеет полный доступ. В результате он получает сле­дующие преимущества:

• направленность тестирования. Программист может тес­тировать программу по частям, разработать специальные тестовые подпрограммки, которые вызывают тестируемый модуль и пере­дают ему интересующие программиста данные. Отдельный модуль легче протестировать именно как «стеклянный ящик»;

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

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

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

• использование внутренних граничных точек. В исходном коде видны те граничные точки программы, которые скрыты от взгляда «извне». Например, для выполнения определенного дей­ствия может быть использовано несколько совершенно различ­ных алгоритмов, и, не заглянув в код, невозможно определить, какой из них выбрал программист. Еще одним типичным приме­ром может быть проблема переполнения буфера, используемого для временного хранения входных данных. Программист сразу может сказать, при каком количестве данных буфер переполнит­ся, и ему не нужно при этом проводить тысячи тестов;

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

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

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

Второй пример применения регрессионного тестирования. После выявления и и

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

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

^
5.4.1 Полный цикл тестирования разработанного программного продукта

Когда кодирование завершено, программа передается группе тестирования. Тестировщик ищет ошибки, составляет о них отче­ты, затем получает новую версию программы и снова ищет ошиб­ки. При этом находятся старые ошибки, не замеченные на первом этапе, и новые, появившиеся после доработки. В [15] подытожены данные об эффективности исправления найденных ошибок.

Если для исправления ошибки нужно изменить не более де­сяти операторов, вероятность того, что это будет сделано пра­вильно с первого раза, составляет 50 %. Если для исправления ошибки нужно изменить около пятидесяти операторов, вероят­ность того, что это будет сделано правильно с первого раза, со­ставляет 20 %.

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

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

Руководители проектов часто рассчитывают ограничиться двумя циклами тестирования: в первом выявить все ошибки, а во втором убедиться, что все они исправлены. Реально для тес­тирования может понадобиться порядка восьми циклов, а если на каждом из них тестировать программу менее тщательно — тогда от 20 до 30.
^

В этом разделе описывается стандартная последователь­ность событий, свойственная тестированию информационной системы как «черного ящика».

1. Планирование

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

2. Приемочное тестирование

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

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

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

Во многих компаниях приемочные тесты частично автома­тизированы с помощью специального программного обеспече­ния, выполняющего тестирование «черного ящика».

3. Проверка стабильности системы

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

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

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

Таким образом, реально оценивая трудоемкость тестирова­ния, можно прийти к выводу, что не стоит рассчитывать на то, что разобраться с системой удастся, например, за неделю, если только она не элементарна и если это не очередная версия про­дукта, который был уже несколько раз протестирован.
^

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

При тестировании производительности системы применя­ются следующие тесты [21]:

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

• сравнительное тестирование — применение тестов, ис­пользующих стандартные, рекомендованные нагрузки для изме­рения производительности системы и ее сравнения с рекомен­дованной производительностью системы (или измерениями);

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

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

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

• тестирование объемов — проверка и анализ возможно­стей системы оперировать большими объемами данных. Прове­ряется как работа с большими объемами данных на входевыходе системы, так и работа с внутренними данными системы;

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

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

Затем программа сверяется с опубликованной печатной до­кументацией: сверка с пользовательскими требованиями — тестирование целостности; сверка с системными требова­ниями — системное тестирование. Эти две процедуры пред­ставляют собой так называемое аттестационное тестирование.

Бета-тестирование

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

Однако в определенных ситуациях бета-тестировщики ра­ботают с продуктом гораздо более основательно. Такие ситуа­ции возникают в следующих случаях:

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

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

• разработчик дает пользователю выгодную гарантию (на­пример, дается обещание, что в случае сбоя программы сотруд­ником компании-разработчика будут бесплатно введены поте­рянные данные).

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

Рис. 4.3. Структурная диаграмма программного комплекса

Структурная диаграмма является трехуровневой и состоит из шести программных модулей. Программный модуль первого уровня М1 (управляющий программных модулей) вызывает три программных модуля второго уровня М2, М3, М4. Программный модуль второго уровня М4 вызывает два программных модуля третьего уровня М5 и М6.

Проектирование и кодирование программного комплекса начинается с управляющего программного модуля М1. Для его тестирования и отладки необходимо иметь программные модули второго уровня, но, так как они еще не спроектированы и не закодированы, вместо них используются имитаторы этих программных модулей — заглушки ЗагМ2,ЗагМ3 и ЗагМ4. Назначение заглушек только в том, чтобы программный модуль верхнего уровня был выполнен, поэтому они могут быть простыми.

После того как главный программный модуль М1 будет оттестирован, вместо ЗагМ2 подключается программный модуль М2. Вместо программных модулей М3 И М4 установлены заглушки ЗагМ3 и ЗагМ4. Тестируется модуль М2.

Вместо ЗагМ3 подключается модуль М3, который тестируется.

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

Структурное кодирование

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

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

После разбиения программного комплекса на программные модули и подготовки спецификации на каждый программный модуль начинается работа по проектированию алгоритмов, реализующих спецификацию каждого программного модуля. Наиболее часто для описания алгоритмов используется словесная форма и графическая в виде схем алгоритмов. Словесная форма наиболее понятна и доступна, но не имеет определенных правил записи и поэтому неоднозначна. Графическая форма наглядна, информативна и однозначна, так как правила выполнения и условные обозначения определяются государственным стандартом ГОСТ 19.701-90 “Схемы алгоритмов, программ, данных и систем”. Каждый программный модуль изображается в графической форме на левой стороне листа, а на правой записывается программа на языке программирования.

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

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

Помните — “цена” ошибок возрастает при их обнаружении на более поздних этапах разработки программного обеспечения. Обычно считается, что “цена” ошибки возрастает на порядок при задержке обнаружения на этап.

Отладка программы

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

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

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

F4 — используется при отладке: начать или продолжить исполнение программы и остановиться перед исполнением той ее строки, на которой стоит курсор;

F7 — выполнить следующую строку программы; если в строке есть обращение к процедуре (функции), войти в эту процедуру и остановиться перед исполнением первого ее оператора;

F8 — выполнить следующую строку программы; если в строке есть обращение к процедуре (функции), исполнить ее и не прослеживать ее работу.

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

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

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

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

1. Нажмите клавишу F10 для перехода в режим выбора из главного меню.

2. Подведите указатель к опции Debug (отладка), нажмите клавишу Enter -на экране раскроется (выпадет) меню второго уровня.

3. Подведите указатель к пункту Output (вывод программы) и снова нажмите Enter. На экране вновь появится окно программы, но оно уже не будет исчезать при нажатии на любую клавишу — экран будет связан с этим окном постоянно.

4. Вновь нажмите клавишу F10, выберите Window, нажмите клавишу Enter.

5. В раскрывшемся меню подведите указатель к опции Tile (черепица) и нажмите клавишу Enter еще раз. Если все выполнено правильно, на экране будут одновременно присутствовать два меню.

Статьи к прочтению:

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

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

Похожие статьи:

• Тестирование и отладка программ

  Для проверки правильности функционирования программы выполняется тестирование. Тестирование – это исполнение программы с использованием некоторого набора…

• Тестирование, отладка и оптимизация

  (В литературе часто этот этап просто называют тестированием). На этом этапе производится всесторонняя проверка программ. По поводу того как должно…