Сбой системы выброс ошибка - Решение и исправление самых разных ошибок на TopOshibok.ru

1. Этапы
разработки программного обеспечения

Для управления
ходом разработки больших программных
систем выделяются шесть
этапов, составляющих цикл разработки
(цикл жизни) программного обеспечения:
1) анализ требований, предъявляемых к
системе; 2) определение спецификаций;
3) проектирование; 4) кодирование; 5)
тестирование; 6) эксплуатация и
сопровождение.

1) Анализ
требований, предъявляемых к системе
На этом этапе формулируется целевое
назначение и основные свойства
разрабатываемой программной системы.
В общем случае, анализ требований,
предъявляемых к системе, должен быть
сосредоточен на интерфейсе между
человеком (пользователем) и инструментом
(ЭВМ). При этом для программных систем
можно выделить лишь базовые требования:
— время обработки (работы) программы;
— стоимость обработки; — вероятность
ошибки; — реакция на непредсказуемые
действия оператора (защита от дурака)
и др.

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

Фактически, анализ
требований завершается составлением
развернутого технического задания
на систему, которое в терминологии
классического САПР называется
аван-проектом.

2) Определение
спецификаций
На этапе определения спецификаций
осуществляется:

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

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

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

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

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

Тестирование
подразумевает три стадии: автономное;
комплексное и системное.

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

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

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

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

2. могут
быть обнаружены ошибки, пропущенные
при тестировании;

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

4. сопровождение
многочисленных компонентов системы.

2.
Жизненный
цикл программного обеспечения

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

1) Анализ
требований, предъявляемых к системе
На этом
этапе формулируется целевое
назначение и основные свойства
разрабатываемой программной системы.
В общем случае, анализ требований,
предъявляемых к системе, должен быть
сосредоточен на интерфейсе между
человеком (пользователем) и инструментом
(ЭВМ). При этом для программных систем
можно выделить лишь базовые требования:
время обработки (работы) программы;
стоимость обработки; вероятность
ошибки; реакция на непредсказуемые
действия оператора (защита от дурака)
и др.

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

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

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

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

Тестирование
подразумевает три стадии: автономное;
комплексное и системное.

6) Эксплуатация
и сопровождение Ни
одна из вычислительных систем не
остается неизменной по мере ее
эксплуатации. Это объясняется
несколькими причинами, среди которых
можно выделить следующие:
1. Заказчик обычно не может четко
сформулировать свои требования, редко
бывает
удовлетворен созданной системой и
поэтому настаивает на внесении
изменений в готовую систему; 2. могут
быть обнаружены ошибки, пропущенные
при тестировании; 3. могут потребоваться
специальные модификации системы для
частных условий функционирования,
связанные с различными применениями;
4. сопровождение многочисленных
компонентов системы.

3.
Тестирование:
программное, системное, оценочное и
сравнительное тестирование

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

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

Подобную процедуру
называют программным тестированием,
а программу тестирования – UUT
(тестирующей
программой). Модуль, прошедший автономное
тестирование, подвергается комплексному
тестированию.

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

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

4. Правильность
и надежность программ

В процессе
тестирования, для определения
правильности выполнения программы
вводится ряд критериев:

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

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

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

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

В общем случае
не существует единого программного
критерия, определяющего «хорошо
проверенную» программу. Тесно связаны
с тестированием понятия «верификация»
и «испытание». Испытание
системы
осуществляется посредством тестирования.
Цель такой проверки – показать, что
система функционирует в соответствии
с разработанными на нее спецификациями.
Верификация
заключается в выполнении доказательств,
что программа удовлетворяет своим
спецификациям. Современный процесс
разработки программ не позволяет
реализовать обе указанные концепции.
Общий процесс создания правильных
программ с помощью процедур испытания
и верификации называется аттестацией.
Различаются три вида отклонения от
нормальной работы системы.

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

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

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

5.
Организация
интерфейса между модулями, написанными
разными программистами

Обычно наибольшие
трудности возникают при построении
интерфейса между модулями, написанными
различными программистами. Поскольку
количество таких интерфейсов при N
исполнителях соответствует N(N–1)/2
и возрастает пропорционально квадрату
числа исполнителей, проблема становится
довольно сложной при разработке
проекта группой из 4 и более человек.

Пример.
Программист может написать в течение
года программу, включающую 5000 строк,
а проектируемая система должна
содержать 500000 строк, и ее разработка
должна быть завершена в течение двух
лет. Очевидно, что для создания такой
системы достаточно пяти программистов.
Однако, эти пять программистов должны
взаимодействовать друг с другом, а
это требует времени и в определенной
степени снижает производительность
труда, поскольку взаимное непонимание
приводит к дополнительным затратам
на тестирование. Пусть каждый из путей
взаимодействия обходится программисту
в 250 строк/год. В этом случае каждый
программист может составить лишь 4000
строк/год, а в течение двух лет будет
составлено лишь 40000 строк. Это означает,
что для написания программы из 50000
строк нужно 8 программистов, каждый
из которых пишет 3250 строк/год. Для
управления их работой нужен руководитель.

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

6.
Методика
оценки затрат. Методика инженерно-технической
оценки затрат

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

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

Шаг 2.
Собирается аналогичная информация,
например данные о подобных системах.

Шаг 3.
Отбираются основные релевантные
данные.

Шаг 4.
Проводится предварительная оценка.

Шаг 5.
Проводится окончательная оценка
системы.

Основной этап
этой работы – шаг 4. При его выполнении
проводятся следующие действия.

Шаг 4а.
Сравнение проектируемой системы с
подобными уже разработанными системами.

Шаг 4б.
Разбиение системы на части и сравнение
каждой из этих частей с подобными ей
частями других систем.

Шаг 4в.
Планирование работ и оценка затрат
на каждый месяц.

Шаг 4г.
Разработка соглашений, которые могут
быть использованы при работе.

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

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

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

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

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

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

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

7.
Оценка
длительности разработки на основе
распределения Рэлея

Зависимость
суммарных затрат от времени при
разработке больших систем (свыше 50
человеко-лет) хорошо отображается
следующим уравнением:
,
где

— суммарные затраты к моменту времени
t;
К –
общая стоимость системы; a
– характеристика максимальных затрат
на единичном отрезке времени.

Такая
зависимость, выраженная в дифференциальной
форме, отображается кривой Рэлея

,
где

— плотность затрат или ежегодные
затраты (рис.)

Возможность
использования кривой Рэлея вытекает
из следующих соображений:

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

Кривая
Рэлея имеет два параметра

и
.
В начале работы

можно оценить используя величину
планируемых затрат, а

можно определить исходя из состава
исполнителей. Дату завершения работ
определяют по достижению максимума
расходов (максимум кривой Рэлея).

8.
Язык
определения задач и анализатор
определения задач (PSL/PSA)

Среди
таких методов следует отметить
разработку Мичиганского университета
ISDOS,
в состав которой входят две базовые
составляющие:

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

Язык
PSL
имеет
простой синтаксис и ориентирован на
использование ключевых слов. Основными
операторами этого языка являются:

PROCESS <имя>	<имя> определяется как новый процесс;
DISCRIPTION <текст>	<текст> представляет описание функции, реализуемой процессом, средствами английского языка;
SUBPARTS ARE <имя>	процесс <имя> связан с текущим процессом и расположен ниже его на дереве иерархии;
PART OF <имя>	процесс <имя> вызывает текущий процесс;
DERIVE <файл>	файл <файл> является выходным для текущего процесса;
USING <файл>	файл <файл> является входным для текущего процесса;
PROCEDURE <текст >	<текст > представляет описание на языке PDL алгоритма, реализуемого процессом.

Пример:
если процесс Y
содержит
предложение PART
OF
X;
то процесс X
должен
включать предложение SUBPARTS
ARE
Y;

Система PSL/PSA
обладает следующими характеристиками:

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

Третья составляющая
часть ISDOS
— язык
проектирования программ PDL.

9.
Система
структурного проектирования SADT

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

Подсистема.
Большая функциональная часть системы.

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

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

Модуль.
Это программный компонент, являющийся
частью работы. Модулю присваивается
имя, состоящее из 6 символов. Например,
ABC123
– это имя модуля 123 в процессе BC
подсистемы A.

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

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

Структура системы:

Задача A

(Задача
B или C) и
Задача D

Задача F

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

Авторы.
Разработчики,
занятые изучением требований и
ограничений системы и их описаний с
помощью системы SADT.

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

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

Технический
комитет.
Группа опытных технических специалистов,
анализирующих проект на высших уровнях
его описания.

Библиотекарь
проекта.
Лицо, отвечающее за ведение файлов
проекта.

Руководитель
проекта.
Лицо, несущее основную ответственность
за техническую разработку проекта.

Главный аналитик.
Основной консультант по использованию
SADT.
Он хорошо понимает особенности
использования системы SADT
и выдает рекомендации по ее применению.

Инструктор.
Лицо, обучающее исследователей
пользованию SADT.

К основным
достоинствам SADT
можно
отнести:

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

2) письменные
отчеты технических комитетов позволяют
проводить непрерывный контрольный
анализ системы, что немаловажно при
осуществлении испытаний системы;

3) эффективным
средством получения специальной
информации являются доклады экспертов;

4) система
позволяет на ранних этапах принять
основные решения высокого уровня, что
создает прочный фундамент для
вырабатывания последующих решений
более низкого уровня;

5) использование
SADT
дает возможность осмыслить разрабатываемую
систему лицам, не являющимся специалистами
по программному обеспечению;

6) предусмотрены
легкодоступные средства контроля
хода проектирования;

Основным и главным
недостатком этой системы является
тот факт, что она не автоматизирована.

10.
Структурное
проектирование. Методика Джексона

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

Элемент.
Функция, которая не может быть разбита
на более простые функции.

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

Выборка.
Одна из возможных последовательностей.

Итерация.
Функция, выполняемая заданное число
раз, включая нулевое.

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

11.
Стратегия
объединения различных методов
проектирования

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

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

2) выполнение
испытаний. На
каждом шаге совершенствования модуля
осуществляется его аттестация;

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

4) использование
всего диапазона средств
структурного
программирования. По
возможности желательно применять
языки, позволяющие реализовать удобные
структуры управления и данных. Для
описания процессов желательно
использовать технику пошагового
совершенствования;

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

6) использование
немногочисленного штата, укомплектованного
квалифицированными работниками.
Хорошие
результаты работы дает использование
принципа организации бригады главного
программиста;

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

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

12.
Язык
проектирования программ PDL.
Операторы выбора. Операторы цикла.
Операторы описания данных. Операторы
ввода-вывода и вызова процедур

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

Язык PDL
включает
шесть групп операторов.

Оператор
выбора.

а) if
выражение;

then
оператор₁;

else
оператор₂;

Оба оператора
могут быть последовательностью
операторов, входящих в группу do
– end.

б) do
case
(выражение);

/индекс₁/
оператор₁;

……………………………..

/индекс_n/
оператор_n;

else
оператор_n₊₁;

end;

Оператор case
используется для выбора из многих
вариантов. Оператор case
вычисляет
выражение и выполняет тот оператор,
у которого индекс равен значению
выражения. Если никакой из индексов
не равен значению выражения, то
выполняется оператор else
(если он,
имеется). Каждый из этих операторов
может входить в группу do
– end.

Оператор
цикла.

а) do
while
(выражение);

набор операторов;

end;

Набор операторов
выполняется до тех пор, пока значение
выражения остается истинным.

б) do
переменная
= выраж₁
to
выраж₂
by
выраж₃;

набор операторов;

end;

При
вхождении в цикл в первый раз вычисляются
значения выраж₁,
выраж₂
и выраж₃;.
Приращение (выраж₃
может быть положительным, отрицательным
или опущено (по умолчанию предполагается
равным +1). Цикл выполняется любое число
раз.

Оператор
описания данных.

declare
имя атрибуты;

Имена
объявляются для переменных со списками
атрибутов. Атрибуты могут быть
стандартными типами данных языка
программирования (real,
float,
integer,
и др.) или структурами данных высокого
уровня (рис. 4.1.).

Для
определения сложных структур данных
используются структуры типа:

declare
1
A, 2 B, 3 C, 3 D, 2 E, 2 F;

Это соответствует
структуре дерева. Для ссылки на элементы
подобных структур используется система
уточненных имен. Таким образом, на
узел С можно ссылаться как на A.B.C,
хотя к С можно обращаться и непосредственно,
если это имя используется однозначно.

Другие
операторы.

а) Переменная =
выражение;

б) call
имя процедуры
(список аргументов);

в) return
(значение);

г) имя procedure
(список параметров);

список операторов;

end;

д) get
(список
данных для ввода);

е) put
(список
данных для вывода);

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

Оператор
leave.

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

13.
Пошаговое
совершенствование (нисходящее
проектирование). Восходящее
проектирование.

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

Суть нисходящего
проектирования можно объяснить
следующей схемой.

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

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

DRIVER:
procedure;

Выполнить
задачу A;

do
while (условие
истинно);

Выполнить
задачу B;

end;

Выполнить
задачу C;

end
DRIVER;

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

Затем, таким же
образом, можно определить процедуры
A,
B
и C.
Очевидно, что язык PDL
хорошо подходит для нисходящего
проектирования.

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

Рис.
4. – Восходящее кодирование и тестирование

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

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

Когда задача
хорошо определена, пользоваться этим
подходом очень удобно.

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

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

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

14.
Подыгрывающие
программы (заглушки)

Когда задача
хорошо определена, пользоваться этим
подходом очень удобно. Однако,
если решаемая задача не понятна или
детально не определена, то тестирование
снизу вверх может вызвать серьезные
проблемы. Например, пользователь не
может убедиться в правильности
функционирования системы согласно
спецификациям, пока не будет проверен
модуль верхнего уровня. Однако этого
нельзя сделать до тех пор, пока не
будет проверена вся иерархическая
структура системы, т.е. до завершения
проекта. А внесение изменений на этом
этапе сопряжено со значительными
затратами и обходится дорого. Чтобы
избежать этого, можно использовать
нисходящее кодирование. В этом случае
в первую очередь проверяют модули
управляющей программы, а также модули
A,
B,
C.
Пользователь системы проверяет
функционирование верхнего уровня на
начальном этапе разработки, поэтому
сделать любые необходимые изменения
в спецификациях гораздо легче.
Единственное неудобство при таком
методе кодирования заключается в том,
что для проверки модулей A,
B,
C
требуются также модули АА, АВ, АС, ВА,
ВВ и СА. Для этих целей служат
подыгрывающие
программы – заглушки.
Это короткие программы, которые
составляются специально для того,
чтобы моделировать ненаписанные
модули и передавать управляющим
программам необходимые тестовые
данные. Подобные средства оказываются
полезными, если ими пользоваться
достаточно осторожно, так как
корректность системы не может быть
доказана, пока не убрана последняя
заглушка.

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

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

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

15. Скалярные и
агрегативные виды данных. Массивы.
Структуры. Списки. Очереди. Стеки.
Множества. Графы. Деревья.

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

Массивы
–
упорядоченный набор данных одного
типа

declare
A(10)
FIXED
BINARY;
Объявлен массив А из десяти двоичных
переменных с фиксированной точкой с
именами A(1),
A(2),
A(3),.
. . , A(9)
A(10).
Аналогично

declare
B(5:10)
FIXED
BINARY;
Объявлен массив В из шести элементов
с именами B(5),
B(6),
. . , B(10).
Массивы могут быть как одномерными,
так и многомерными.

Структуры
—
поименованная совокупность различных
типов данных.

declare
1
X,

2
Y FIXED BINARY,

2
Z
BIT(12);

объявляется
структура с именем Х, состоящая из
двоичной переменной с фиксированной
точкой с именем X.Y
и строки длиной 12 бит с именем X.Z.

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

declare

1 LIST(N),

DATA_ENTRIES
TYPE
(некоторый тип данных),

SIZE;
/* текущий размер списка*/

Элементами
списка являются DATA_ENTRIES(1),
DATA_ENTRIES(2),
. . . . ., DATA_ENTRIES(SIZE).

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

ADD
– поместить новый элемент в список;
DELETE
– удалить элемент из списка;
SEARCH
– проверить наличие элемента в списке.

Очереди
— упорядоченный список, в один конец
которого элементы добавляются, а из
другого изымаются. Очередь называют
списком FIFO
– Fist
In,
Fist
Out
(поступивший первым обслуживается
первым). Для обслуживания очереди
необходимо две операции:

INSERT
– добавить элемент в очередь;
DELETE
– удалить элемент из очереди.

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

PUSH
– поместить элемент в стек;
POP
– извлечь элемент из стека;
EMPTY
– функция, принимающая значение
ИСТИННО, если стек не заполнен.

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

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

INSERT
– добавить новый элемент во множество;
DELETE
– удалить элемент из множества;
MEMBER
– функция, которая принимает значение
ИСТИННО, если данная переменная
находится во множестве.

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

declare
1
GRAPH BASED,

2 DATA_ENTPIES TYPE (некоторый
тип
данных),

2
EDGES(N)
POINTER;

Для
ненаправленных
графов
дугам соответствуют два направления
– вперед и назад:

declare
1
GRAPH BASED,

2 DATA_ENTPIES TYPE (некоторый
тип
данных),

2 FORWARD_EDGES(N) POINTER,

2 BACKWARD_EDGES(N) POINTER;

Операторы для
работы с графами и деревьями:

ADD
– поместить новый элемент;
DELETE
– удалить элемент;
SEARCH
– проверить наличие элемента.

Деревья
– направленный граф, обладающий
следующими свойствами:

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

16. Абстрактные
конструкции. Фиксированные данные
абстрактного типа. Размещение
указателей. Фиксированные типы данных
абстрактного типа

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

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

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

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

17. Аксиомы.
Правила следствия, аксиома присвоения,
аксиома следования, аксиома цикла,
аксиома выбора. Правила целочисленной
арифметики.

Правила
следствия
формулируются следующим образом:

1) если

и
,
то
;
2) если

и
,
то
.

Первое правило
заключается в следующем: «Если
P
— предусловие для Q
и если

является
теоремой исчисления предикатов, то
P
— предусловие дляR».
Таким образом, если P
истинно и
выполняется S,
то R
(так же, как
и Q)
истинно.

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

;
2).

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

Аксиома
присвоения
формулируется следующим образом:

В соответствии
с этой аксиомой устанавливается, что
если P
утверждение, содержащее переменную
x,
истинно, то P
должно быть
истинно и до выполнения оператора
присвоения, если x
изменяется
expr.

Аксиома
следования.

Два оператора
программы могут быть объединены.
Если после выполнения S₁
предикат Q
остается истинным, и Q
есть предусловие для оператора S₂,
то P
является предусловием для операторов
S₁;S₂.

Аксиома цикла.

Утверждается,
что если истинность P
не изменяется оператором S
(т.е. является инвариантом), то P
инвариантно относительно цикла,
содержащего S.
Кроме того, при выходе из цикла значение
выражения B
ложно.

Аксиома выбора.

а)
;
б)
.

Эти аксиомы
устанавливают простые соотношения
для оператора if.

Правила
преобразования данных

Коммутативность

Ассоциативность

Дистрибутивность

Вычитание

Обработка
констант

18. Стратегия
тестирования. Имена переменных.
Константы. Входные данные. Списки
параметров. Проверка спецификаций.

При разработке
тестов целесообразно руководствоваться
следующими рекомендациями.

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

Поиск ошибок
должен вестись по следующей стратегии.

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

Константы.
Не помещайте
в программу «магические числа». Для
обозначения таких величин используйте
идентификаторы.

if
PTR<=63
then
PTR=PTR+1;
else
PTR=PTR-63;
declare
LineLength
initial
(64);

if
PRT<=(
LineLength-1) then
PTR=PTR+1;
else
PTR=PTR-
LineLength;

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

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

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

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

19. Поиск с
возвратом. Алгоритм выбора из конечного
числа состояний.

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

Алгоритм:

Вызвать первую
часть;

do
while
(не окончится);

вызвать следующую
часть;

do
while
(нет
возможности продолжить);

Вернуться на
предыдущий уровень;

Проверить
возможность альтернативного решения
для этого уровня;

end;

Алгоритм
выбора из конечного состояния

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

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

20. Стратегия
распределения памяти. Сопрограммы.

Стратегия
распределения памяти.

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

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

Сопрягаемые
области памяти.
Областями памяти являются N
цепочек размером

каждая. Если область размером

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

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

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

Сопрограмма,
возвращающая управление в процедуру
X,
определяется как resume
X.
Каждая сопрограмма вызывает другую
сопрограмму. Таким образом, программа
обработки данных вызывает программу
обработки формата до следующего
элемента формата.

К сожалению,
сопрограммы отсутствуют в широко
распространенных языках программирования.

Software testing is the process of testing and verifying that a software product or application is doing what it is supposed to do. The benefits of testing include preventing distractions, reducing development costs, and improving performance. There are many different types of software testing, each with specific goals and strategies. Some of them are below:

Acceptance Testing: Ensuring that the whole system works as intended.
Integration Testing: Ensuring that software components or functions work together.
Unit Testing: To ensure that each software unit is operating as expected. The unit is a testable component of the application.
Functional Testing: Evaluating activities by imitating business conditions, based on operational requirements. Checking the black box is a common way to confirm tasks.
Performance Testing: A test of how the software works under various operating loads. Load testing, for example, is used to assess performance under real-life load conditions.
Re-Testing: To test whether new features are broken or degraded. Hygiene checks can be used to verify menus, functions, and commands at the highest level when there is no time for a full reversal test.

What is a Bug?

A malfunction in the software/system is an error that may cause components or the system to fail to perform its required functions. In other words, if an error is encountered during the test it can cause malfunction. For example, incorrect data description, statements, input data, design, etc.

Reasons Why Bugs Occur?

1. Lack of Communication: This is a key factor contributing to the development of software bug fixes. Thus, a lack of clarity in communication can lead to misunderstandings of what the software should or should not do. In many cases, the customer may not fully understand how the product should ultimately work. This is especially true if the software is designed for a completely new product. Such situations often lead to many misinterpretations from both sides.

2. Repeated Definitions Required: Constantly changing software requirements creates confusion and pressure in both software development and testing teams. Usually, adding a new feature or deleting an existing feature can be linked to other modules or software components. Observing such problems causes software interruptions.

3. Policy Framework Does Not Exist: Also, debugging a software component/software component may appear in a different or similar component. Lack of foresight can cause serious problems and increase the number of distractions. This is one of the biggest problems because of what interruptions occur as engineers are often under pressure related to timelines; constantly changing needs, increasing the number of distractions, etc. Addition, Design and redesign, UI integration, module integration, database management all add to the complexity of the software and the system as a whole.

4. Performance Errors: Significant problems with software design and architecture can cause problems for systems. Improved software tends to make mistakes as programmers can also make mistakes. As a test tester, data/announcement reference errors, control flow errors, parameter errors, input/output errors, etc.

5. Lots of Recycling: Resetting resources, redoing or discarding a finished work, changes in hardware/software requirements may also affect the software. Assigning a new developer to a project in the middle of nowhere can cause software interruptions. This can happen if proper coding standards are not followed, incorrect coding, inaccurate data transfer, etc. Discarding part of existing code may leave traces on other parts of the software; Ignoring or deleting that code may cause software interruptions. In addition, critical bugs can occur especially with large projects, as it becomes difficult to pinpoint the location of the problem.

Life Cycle of a Bug in Software Testing

Below are the steps in the lifecycle of the bug in software testing:

Open: The editor begins the process of analyzing bugs here, where possible, and works to fix them. If the editor thinks the error is not enough, the error for some reason can be transferred to the next four regions, Reject or No, i.e. Repeat.
New: This is the first stage of the distortion of distractions in the life cycle of the disorder. In the later stages of the bug’s life cycle, confirmation and testing are performed on these bugs when a new feature is discovered.
Shared: The engineering team has been provided with a new bug fixer recently built at this level. This will be sent to the designer by the project leader or team manager.
Pending Review: When fixing an error, the designer will give the inspector an error check and the feature status will remain pending ‘review’ until the tester is working on the error check.
Fixed: If the Developer completes the debugging task by making the necessary changes, the feature status can be called “Fixed.”
Confirmed: If the tester had no problem with the feature after the designer was given the feature on the test device and thought that if it was properly adjusted, the feature status was given “verified”.
Open again / Reopen: If there is still an error, the editor will then be instructed to check and the feature status will be re-opened.
Closed: If the error is not present, the tester changes the status of the feature to ‘Off’.
Check Again: The inspector then begins the process of reviewing the error to check that the error has been corrected by the engineer as required.
Repeat: If the engineer is considering a factor similar to another factor. If the developer considers a feature similar to another feature, or if the definition of malfunction coincides with any other malfunction, the status of the feature is changed by the developer to ‘duplicate’.

Few more stages to add here are:

Rejected: If a feature can be considered a real factor the developer will mean “Rejected” developer.
Duplicate: If the engineer finds a feature similar to any other feature or if the concept of the malfunction is similar to any other feature the status of the feature is changed to ‘Duplicate’ by the developer.
Postponed: If the developer feels that the feature is not very important and can be corrected in the next release, however, in that case, he can change the status of the feature such as ‘Postponed’.
Not a Bug: If the feature does not affect the performance of the application, the corrupt state is changed to “Not a Bug”.

Fig 1.1 Diagram of Bug Life Cycle

Bug Report

Defect/ Bug Name: A short headline describing the defect. It should be specific and accurate.
Defect/Bug ID: Unique identification number for the defect.
Defect Description: Detailed description of the bug including the information of the module in which it was detected. It contains a detailed summary including the severity, priority, expected results vs actual output, etc.
Severity: This describes the impact of the defect on the application under test.
Priority: This is related to how urgent it is to fix the defect. Priority can be High/ Medium/ Low based on the impact urgency at which the defect should be fixed.
Reported By: Name/ ID of the tester who reported the bug.
Reported On: Date when the defect is raised.
Steps: These include detailed steps along with the screenshots with which the developer can reproduce the same defect.
Status: New/ Open/ Active
Fixed By: Name/ ID of the developer who fixed the defect.
Data Closed: Date when the defect is closed.

Factors to be Considered while Reporting a Bug:

The whole team should clearly understand the different conditions of the trauma before starting research on the life cycle of the disability.
To prevent future confusion, a flawed life cycle should be well documented.
Make sure everyone who has any work related to the Default Life Cycle understands his or her best results work very clearly.
Everyone who changes the status quo should be aware of the situation which should provide sufficient information about the nature of the feature and the reason for it so that everyone working on that feature can easily see the reason for that feature.
A feature tracking tool should be carefully handled in the course of a defective life cycle work to ensure consistency between errors.

Bug Tracking Tools

Below are some of the bug tracking tools–

1. KATALON TESTOPS: Katalon TestOps is a free, powerful orchestration platform that helps with your process of tracking bugs. TestOps provides testing teams and DevOps teams with a clear, linked picture of their testing, resources, and locations to launch the right test, in the right place, at the right time.

Features:

Applies to Cloud, Desktop: Window and Linux program.
Compatible with almost all test frames available: Jasmine, JUnit, Pytest, Mocha, etc .; CI / CD tools: Jenkins, CircleCI, and management platforms: Jira, Slack.
Track real-time data for error correction, and for accuracy.
Live and complete performance test reports to determine the cause of any problems.
Plan well with Smart Scheduling to prepare for the test cycle while maintaining high quality.
Rate release readiness to improve release confidence.
Improve collaboration and enhance transparency with comments, dashboards, KPI tracking, possible details – all in one place.

2. KUALITEE: Collection of specific results and analysis with solid failure analysis in any framework. The Kualitee is for development and QA teams look beyond the allocation and tracking of bugs. It allows you to build high-quality software using tiny bugs, fast QA cycles, and better control of your build. The comprehensive suite combines all the functions of a good error management tool and has a test case and flow of test work built into it seamlessly. You would not need to combine and match different tools; instead, you can manage all your tests in one place.

Features:

Create, assign, and track errors.
Tracing between disability, needs, and testing.
Easy-to-use errors, test cases, and test cycles.
Custom permissions, fields, and reporting.
Interactive and informative dashboard.
Integration of external companies and REST API.
An intuitive and easy-to-use interface.

3. QA Coverage: QACoverage is the place to go for successfully managing all your testing processes so that you can produce high-quality and trouble-free products. It has a disability control module that will allow you to manage errors from the first diagnostic phase until closed. The error tracking process can be customized and tailored to the needs of each client. In addition to negative tracking, QACoverage has the ability to track risks, issues, enhancements, suggestions, and recommendations. It also has full capabilities for complex test management solutions that include needs management, test case design, test case issuance, and reporting.

Features:

Control the overall workflow of a variety of Tickets including risk, issues, tasks, and development management.
Produce complete metrics to identify the causes and levels of difficulty.
Support a variety of information that supports the feature with email attachments.
Create and set up a workflow for enhanced test visibility with automatic notifications.
Photo reports based on difficulty, importance, type of malfunction, disability category, expected correction date, and much more.

4. BUG HERD: BugHerd is an easy way to track bugs, collect and manage webpage responses. Your team and customers search for feedback on web pages, so they can find the exact problem. BugHerd also scans the information you need to replicate and resolve bugs quickly, such as browser, CSS selector data, operating system, and screenshot. Distractions and feedback, as well as technical information, are submitted to the Kanban Style Task Board, where distractions can be assigned and managed until they are eliminated. BugHerd can also integrate with your existing project management tools, helping to keep your team on the same page with bug fixes.

Acceptance Testing: Ensuring that the whole system works as intended.
Integration Testing: Ensuring that software components or functions work together.
Unit Testing: To ensure that each software unit is operating as expected. The unit is a testable component of the application.
Functional Testing: Evaluating activities by imitating business conditions, based on operational requirements. Checking the black box is a common way to confirm tasks.
Performance Testing: A test of how the software works under various operating loads. Load testing, for example, is used to assess performance under real-life load conditions.
Re-Testing: To test whether new features are broken or degraded. Hygiene checks can be used to verify menus, functions, and commands at the highest level when there is no time for a full reversal test.

What is a Bug?

Reasons Why Bugs Occur?

Life Cycle of a Bug in Software Testing

Below are the steps in the lifecycle of the bug in software testing:

Open: The editor begins the process of analyzing bugs here, where possible, and works to fix them. If the editor thinks the error is not enough, the error for some reason can be transferred to the next four regions, Reject or No, i.e. Repeat.
New: This is the first stage of the distortion of distractions in the life cycle of the disorder. In the later stages of the bug’s life cycle, confirmation and testing are performed on these bugs when a new feature is discovered.
Shared: The engineering team has been provided with a new bug fixer recently built at this level. This will be sent to the designer by the project leader or team manager.
Pending Review: When fixing an error, the designer will give the inspector an error check and the feature status will remain pending ‘review’ until the tester is working on the error check.
Fixed: If the Developer completes the debugging task by making the necessary changes, the feature status can be called “Fixed.”
Confirmed: If the tester had no problem with the feature after the designer was given the feature on the test device and thought that if it was properly adjusted, the feature status was given “verified”.
Open again / Reopen: If there is still an error, the editor will then be instructed to check and the feature status will be re-opened.
Closed: If the error is not present, the tester changes the status of the feature to ‘Off’.
Check Again: The inspector then begins the process of reviewing the error to check that the error has been corrected by the engineer as required.
Repeat: If the engineer is considering a factor similar to another factor. If the developer considers a feature similar to another feature, or if the definition of malfunction coincides with any other malfunction, the status of the feature is changed by the developer to ‘duplicate’.

Few more stages to add here are:

Rejected: If a feature can be considered a real factor the developer will mean “Rejected” developer.
Duplicate: If the engineer finds a feature similar to any other feature or if the concept of the malfunction is similar to any other feature the status of the feature is changed to ‘Duplicate’ by the developer.
Postponed: If the developer feels that the feature is not very important and can be corrected in the next release, however, in that case, he can change the status of the feature such as ‘Postponed’.
Not a Bug: If the feature does not affect the performance of the application, the corrupt state is changed to “Not a Bug”.

Fig 1.1 Diagram of Bug Life Cycle

Bug Report

Defect/ Bug Name: A short headline describing the defect. It should be specific and accurate.
Defect/Bug ID: Unique identification number for the defect.
Defect Description: Detailed description of the bug including the information of the module in which it was detected. It contains a detailed summary including the severity, priority, expected results vs actual output, etc.
Severity: This describes the impact of the defect on the application under test.
Priority: This is related to how urgent it is to fix the defect. Priority can be High/ Medium/ Low based on the impact urgency at which the defect should be fixed.
Reported By: Name/ ID of the tester who reported the bug.
Reported On: Date when the defect is raised.
Steps: These include detailed steps along with the screenshots with which the developer can reproduce the same defect.
Status: New/ Open/ Active
Fixed By: Name/ ID of the developer who fixed the defect.
Data Closed: Date when the defect is closed.

Factors to be Considered while Reporting a Bug:

The whole team should clearly understand the different conditions of the trauma before starting research on the life cycle of the disability.
To prevent future confusion, a flawed life cycle should be well documented.
Make sure everyone who has any work related to the Default Life Cycle understands his or her best results work very clearly.
Everyone who changes the status quo should be aware of the situation which should provide sufficient information about the nature of the feature and the reason for it so that everyone working on that feature can easily see the reason for that feature.
A feature tracking tool should be carefully handled in the course of a defective life cycle work to ensure consistency between errors.

Bug Tracking Tools

Below are some of the bug tracking tools–

Features:

Applies to Cloud, Desktop: Window and Linux program.
Compatible with almost all test frames available: Jasmine, JUnit, Pytest, Mocha, etc .; CI / CD tools: Jenkins, CircleCI, and management platforms: Jira, Slack.
Track real-time data for error correction, and for accuracy.
Live and complete performance test reports to determine the cause of any problems.
Plan well with Smart Scheduling to prepare for the test cycle while maintaining high quality.
Rate release readiness to improve release confidence.
Improve collaboration and enhance transparency with comments, dashboards, KPI tracking, possible details – all in one place.

Features:

Create, assign, and track errors.
Tracing between disability, needs, and testing.
Easy-to-use errors, test cases, and test cycles.
Custom permissions, fields, and reporting.
Interactive and informative dashboard.
Integration of external companies and REST API.
An intuitive and easy-to-use interface.

Features:

Control the overall workflow of a variety of Tickets including risk, issues, tasks, and development management.
Produce complete metrics to identify the causes and levels of difficulty.
Support a variety of information that supports the feature with email attachments.
Create and set up a workflow for enhanced test visibility with automatic notifications.
Photo reports based on difficulty, importance, type of malfunction, disability category, expected correction date, and much more.

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

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

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

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

проверка готовности ПО к релизу;
проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

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

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

Этапы тестирования:

Анализ продукта
Работа с требованиями
Разработка стратегии тестирования и планирование процедур контроля качества
Создание тестовой документации
Тестирование прототипа
Основное тестирование
Стабилизация
Эксплуатация

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

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

анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.

Требования

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

Атрибуты требований:

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
Вложения (Attachments) — скриншоты, видео или лог-файлы.
Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
Задача (task) — техническая задача, которую делает один из членов команды.
Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
Продакшн среда (Production Env) – среда, в которой работают пользователи.

Основные фазы тестирования

Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
  1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
  2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
  3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
  4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
  5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
  6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
  7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
  8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
  9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
  10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
  11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
  12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
  13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

тестирование, основанное на анализе внутренней структуры компонента или системы;
тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

Согласно ISTQB, тестирование черного ящика — это:

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

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

Что необходимо протестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана:

Идентификатор тест плана (Test plan identifier);
Введение (Introduction);
Объект тестирования (Test items);
Функции, которые будут протестированы (Features to be tested;)
Функции, которые не будут протестированы (Features not to be tested);
Тестовые подходы (Approach);
Критерии прохождения тестирования (Item pass/fail criteria);
Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
Результаты тестирования (Test deliverables);
Задачи тестирования (Testing tasks);
Ресурсы системы (Environmental needs);
Обязанности (Responsibilities);
Роли и ответственность (Staffing and training needs);
Расписание (Schedule);
Оценка рисков (Risks and contingencies);
Согласования (Approvals).

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

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

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

Атрибуты тест кейса:

Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

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

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

Определение

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

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

Цели

Тестирование преследует определенные цели. К ним относят:

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

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

Для чего необходим

Тест – процесс проверки чего-либо. В разработке систем он очень важен. Помогает:

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

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

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

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

Немного терминологии

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

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

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

О качестве

Что собой представляет качество ПО, понятно. Данный процесс имеет несколько «видов» контроля (проверок). Каждый предусматривает свои ключевые особенности:

QC – контроль качества продукта (системы). Представляет собой анализ результатов тестирования и качества новых версия проекта. К его задачам относят проверку: готовности приложения к релизу, соответствие требований и качества.
QA – это обеспечение качества продукта. Отражает процесс изучения возможностей по внесению изменений и улучшению разработки. Позволяет делать связи в команде программистов лучше. Это помогает повысить эффективность тестирования. Среди своих задач выделяет: непосредственное тестирование, проверку технических характеристики, оценку возможных рисков, планирование задач для улучшения (ускорения) выпуска продукта. Предусматривает анализ полученных в ходе тестов результатов. За счет QA удается составить отчеты и другие документы по системе.

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

Принципы организации

Рассматривая основы тестирования ПО и систем, нужно разобраться в принципах изучаемых комплексов мероприятий:

Тестирование указывает на наличие дефектов. Оно может указать на то, что в процессе разработки присутствует тот или иной дефект. А вот доказать отсутствие таких неполадок – нет. Проверка ПО снижает вероятность наличия дефектов, но вот то, что их нет, гарантировать никак не может.
Исчерпывающие проверки системе недостижимы. Полное тестирование с использованием всех комбинаций вводов и предусловий выполнить физически не получится. Исключение – нетривиальные задачи. Вместо исчерпывающего «анализа» нужно использовать оценивание рисков и расстановку приоритетов. Такой подход позволяет сконцентрироваться на более точном получении итогового результата.
Раннее тестирование. Проверки должны начинаться как можно раньше в жизненном цикле программного обеспечения. Это помогает быстрее обнаружить неполадки. Фокусироваться такие тесты должны на конкретных целях.
Скопление дефектов. Разные системные модули содержат различные дефекты – не только по типу, но и по количеству. Плотность скопления неполадок и сбоев в разных частых кода может варьироваться. Условия по тестированию систем должны распределяться пропорционально плотности обнаруженных дефектов. Основная часть критических ошибок приходится на ограниченное число модулей системы.
«Пестицидный» парадокс. При прогоне одних и тех же тестов несколько раз, в конечном итоге набор тестовых сценарием перестанет находить новые дефекты. Чтобы избавиться от этого парадокса, сценарии должны регулярно рецензироваться и изменяться. Новые тесты, формируемые специалистами, обязательно становятся разносторонними. Это помогает охватить все компоненты системы с целью обнаружения большего количества дефектов.
Зависимость от контекста. Тесты выполняются по-разному. Все зависит от того, какой контекст изначально заложен. Пример – программный продукт, для которого на передовой находится безопасность, будет проверяться на работоспособность иначе, чем обычный информационно-новостной портал.
Заблуждение об отсутствии неполадок. При тестировании не всегда обнаруживаются неполадки и ошибки. Это не значит, что система подготовлена на все 100% к релизу. Может получиться так, что дефекты будут критическими и скрытыми. Проект должен не только не иметь неполадок (особенно если речь идет о масштабной разработке), но и быть удобным для использования потребителями.

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

Этапы

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

Анализ имеющегося продукта. Это – первоначальная идея (задумка) проекта.
Работа с требованиями. На предыдущем этапе происходит формирование технического задания. Теперь предстоит изучить его и доработать, если это необходимо.
Разработка стратегий тестирования и планирование процедур по контролю качества.
Создание тестовой документации. Это – этап, на котором формируется «отчетность» для тестировщиков. Вспомогательные документы, опираясь на которые, специалисты будут грамотно выстраивать процессы.
Тестирование прототипов.
Основной этап проверок. Здесь выявляется полноценная работоспособность приложения, а также соответствие первоначальным требованиям заказчика.
Стабилизация и отладка.
Релиз и эксплуатация.

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

Жизненный цикл

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

Жизненный цикл можно представить похожим на этапы тестирования. Он обычно включает в себя:

непосредственный анализ требований к приложению или системе;
проектирование;
реализацию;
тестирование;
внедрение и поддержку.

Каждая стадия получает свое «имя» или порядковый номер: пре-альфа, альфа, бета, релиз-кандидат, релиз, а также пост-релиз.

Основные требования

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

Сюда можно отнести следующие критерии:

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

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

Виды

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

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

Функциональное тестирование

Рассматривает заранее указанное поведение. Базируется на анализе спецификаций функциональности компонентом или систем. Позволяет проверить ключевые задачи проекта.

Проверка пользовательского интерфейса

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

Тестирование безопасности

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

Проверка работоспособности

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

Нагрузочные проверки

Нагрузочное тестирование. Базируется на автоматизации. Позволяет проверить автоматически, как бизнес-пользователи будут работать на том или ином ресурсе. Это – имитация поведения потенциальной целевой аудитории.

Стрессовые тесты

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

Объемное тестирование

Это – получение оценки производительности. В основе заложено увеличение объемов обрабатываемой в БД информации программы.

Тест надежности

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

Проверка установок

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

Удобство пользования

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

Отказ и восстановление

Проверяет:

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

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

Конфигурационные проверки

Специальный вид «анализа». Он направлен на проверку работы системы при применении разного рода настроек системы. Пример – разнообразные ОС или драйверах.

Дымовые тесты

Это с точки зрения «анализа процессов» — короткие циклы тестов. Они помогают удостовериться в том, что после сборки код будет работать и выполнять заданные функции. В основном используется при обновлениях и доработках.

Регрессионные тесты

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

Повторные тесты

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

Тесты сборок

Направлены на соответствие выпущенной версии критериям качества в начале тестирования. Это – аналог «дымового» подхода.

Санитарное тестирование

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

Иные виды

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

Статическое тестирование. Код не будет выполняться. Все проверки осуществляются вручную. Направлено на повышение качества итогового продукта.
Динамическое. Это – выполнение кода. Нацелено на функциональное поведение системы, использование памяти, общую производительность. Позволяет подтвердить то, что проект работает согласно задумке.
Ручное тестирование систем. Начинать и организовывать анализ проекта придется вручную. Долгий и затратный процесс.
Автоматизированный вариант. Хотя ручное тестирование до сих пор есть, на передовую выходить автоматизация. Это – проверка работоспособности ПО при помощи специальных приложений и функций.
Позитивные тесты. Здесь применяются только корректные электронные материалы.
Негативные тесты. Проверка системы, при которой используются некорректные данные. Выполнять будут «неправильные» операции.
Модульный подход. Проверка логически выделенного и изолированного компонента системы.
Интеграционный вариант. Проверяет, насколько несколько модулей системы хорошо взаимодействуют друг с другом и иными частями ПО.

Основы тестов изучены. Перед тем, как начать проверку работоспособности, нужно обратить внимание на типы «анализа». Без них специалисту не обойтись.

О типах

Существует тестирование белого ящика. Это – метод, который предполагает, что внутренняя структура, устройство и реализация известны специалисту. Сюда можно отнести проверки, базирующиеся на анализе внутренней структуры элемента/системы, а также тест-дизайн.

Есть тестирование серого ящика. Метод, предполагающий сочетание «черного» и «белого» ящиков. Внутреннее устройство программы будет известно лишь частично.

Тестирование черного ящика – тест, базирующийся на спецификации. Является тестированием поведения.

Как стать тестировщиком

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

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Есть варианты как для продвинутых, так и для начинающих пользователей.

Дефекты. Ошибки, сбои, отказы

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

Ожидаемый результат — поведение системы, описанное в требованиях.

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

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

Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

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

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

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

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями:

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

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

Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так (рисунок 2на следующем слайде):

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

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

Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

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

Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах:

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

В некоторых средствах одного из состояний нет (оно поглощается другим)

В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие:

«Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
«Дубликат» — данный дефект уже описан в другом отчёте.
«Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
«Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
«Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».

Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

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

— быть достаточно коротким, чтобы полностью помещаться на экране;

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

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

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

иного) языка, построенным по соответствующим правилам

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
Сформулировать подробное описание
3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

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

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

его, сократив длину (за счёт подбора синонимов, использования

общепринятых аббревиатур и сокращений). К слову, в английском языке

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

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

Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

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

Пример подробного описания :

Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.

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

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

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

Пример шагов воспроизведения :

Открыть http://testapplication/admin/login/.
Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

Воспроизводимость показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда или иногда. Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:

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

Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).

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

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

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

— Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

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

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

— Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

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

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

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

В качестве примера рассмотрим следующие значения симптомов дефекта.

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

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

Часто у одного дефекта может быть сразу несколько симптомов.

Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

Содержание

Основные понятия
Цели тестирования
Принципы тестирования
Этапы тестирования:
Жизненный цикл проекта
Требования
Уровни Тестирования
Типы тестирования
Виды Тестирования
- Функциональные виды тестирования
- Нефункциональные виды тестирования
- Связанные с изменениями виды тестирования
Тестовая документация
- Техники тест дизайна
Дефекты и репорты

Основные понятия

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [Quality management and quality assurance]

QA/QC/Test Engineer

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование — часть QC. QC — часть QA.

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Цели тестирования

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

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

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.

Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.

Принцип 3 — Раннее тестирование (Early testing)
Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.

Принцип 4 — Скопление дефектов (Defects clustering)
Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.

Принцип 5 — Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения,
или системы, и найти как можно больше дефектов.

Принцип 6 — Тестирование зависит от контекста (Testing is concept depending)
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования
и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Жизненный цикл проекта

Стадии разработки ПО (Подробнее) — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).

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

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

Жизненный цикл разработки ПО:
• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

Жизненный цикл бага

Требования

Требования разделяются на Функциональные и не функциональные.

Требования к требованиям:
1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.

Подробнее

Уровни Тестирования

1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию:
• Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
• Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
• Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

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

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

Типы тестирования

White/Black/Grey Box-тестирование

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

Black Box

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

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

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

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

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

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

White Box
Summary: Нам известны все детали реализации тестируемой программы.
Тестирование методом белого ящика (также: прозрачного, открытого, стеклянного ящика; основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутренне устройство системы, за пределы ее внешних интерфейсов.

Согласно ISTQB:
тестирование белого ящика – это:
– тестирование, основанное на анализе внутренней структуры компонента или системы.
– тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный ящик, содержимое которого он прекрасно видит.

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

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

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

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

Сравнение Black Box и White Box

Grey Box
Summary: Нам известны только некоторые особенности реализации тестируемой системы.
Тестирование методом серого ящика – метод тестирования программного обеспечения, который предполагает, комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ к внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.
Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.

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

Статические и Динамическое тестирование.

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

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

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

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

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

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

Зачастую, тестировщики придерживаются следующего порядка проверки приложения:

1. Дымное тестирование.
2. Позитивные тесты.
3. Негативные тесты.

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

Виды Тестирования

Функциональные виды тестирования

Функциональное тестирование (Functional testing)
Тестирование пользовательского интерфейса (GUI Testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования

Все виды тестирования производительности:
- нагрузочное тестирование (Performance and Load Testing)
- стрессовое тестирование (Stress Testing)
- тестирование стабильности или надежности (Stability / Reliability Testing)
- объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Повторное тестирование (Re-testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям — размер, шрифт, цвет, consistent behavior.

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

Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

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

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

Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

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

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

Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

Тестирование сборки или Build Verification Test — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

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

Тестовая документация

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

Основные пункты тест плана

В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

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

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям. (Состоит из действий (Actions) и ожидаемого результата (Expected Result))
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Сценариев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
• Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
• Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

Тест дизайн (test design)— это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

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

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей — получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол — мужской или женский; возраст — до 25, от 25 до 60, более 60; наличие детей — да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	детей нет
3	мужчина	25-60	детей нет
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	детей нет
7	мужчина	до 25	дети есть
8	женщина	до 25	дети есть
9	мужчина	25-60	дети есть
10	женщина	25-60	дети есть
11	мужчина	старше 60	дети есть
12	женщина	старше 60	дети есть

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	дети есть
3	мужчина	25-60	дети есть
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	дети есть

Такой подход примерно и составляет суть техники pairwise testing — мы не проверяем все сочетания всех значений, но проверяем все пары значений.

Матрица соответствия требований (traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

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

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

Дефекты и репорты

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

Bug (defect) — Изъян в компоненте или системе который ведет к отклонению фактического результата выполнения программы от ожидаемого (к сбою).

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

Состоит из:

Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение (Environment) — Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера (ОС / Сервис Пак и т.д. / Браузера + версия /)
Описание (Description)
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority — менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

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

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

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

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Оригинал статьи.

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

Перейдем к основным понятиям.

Почему требуется тестирование ПО?

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

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

Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible). Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
Принцип 3 — Раннее тестирование (Early testing). Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки ПО или системы, и должны быть сфокусированы на определенных целях.
Принцип 4 — Скопление дефектов (Defects clustering). Разные модули системы могут содержать разное количество дефектов – то есть плотность скопления дефектов в разных частях кода может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox). Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
Принцип 6 — Тестирование зависит от контекста (Testing is concept depending). Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:

проверка готовности ПО к релизу;
проверка соответствия требований и качества данного проекта.

К задачам обеспечения качества относятся:

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

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

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

Этапы тестирования:

Анализ продукта
Работа с требованиями
Разработка стратегии тестирования и планирование процедур контроля качества
Создание тестовой документации
Тестирование прототипа
Основное тестирование
Стабилизация
Эксплуатация

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

анализ требований к проекту;
проектирование;
реализация;
тестирование продукта;
внедрение и поддержка.

Требования

Требования к требованиям:

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

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

Атрибуты отчета о дефекте:

Уникальный идентификатор (ID) — присваивается автоматически, может содержать в себе данные о требовании, на которое ссылается дефект.
Тема (краткое описание, Summary) — кратко сформулированная суть дефекта по правилу «Что? Где? Когда?»
Подробное описание (Description) — более широкое описание сути дефекта (при необходимости).
Шаги для воспроизведения (Steps To Reproduce) — последовательное описание действий, которые привели к выявлению дефекта (которые нужно выполнить для воспроизведения дефекта). Описываются максимально подробно, с указанием конкретных вводимых значений.
Фактический результат (Actual result) — указывается, что не так работает, в каком месте продукта и при каких условиях. Описывая фактический результат, необходимо ответить на три вопроса: что? где? когда?
Ожидаемый результат (Expected result) — указывается, как именно должна работать система по мнению тестировщика, основанному на требованиях и прочей проектной документации.
Вложения (Attachments) — скриншоты, видео или лог-файлы.
Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект.
Статус (Status) — определяет текущее состояние дефекта. Отражает жизненный цикл дефекта от начального состояния до завершения. Названия статусов дефектов могут быть разными в разных баг-трекинговых системах.
Окружение (environment) – указывается окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Градация Серьезности дефекта (Severity):

Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация Приоритета дефекта (Priority):

P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критичным для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичным, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, но ее наличие не является критичным и не требует срочного решения.

Существует пять базовых типов задач:

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
Задача (task) — техническая задача, которую делает один из членов команды.
Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

Среда разработки (Development Env) – в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
Среда тестирования (Test Env) – в этой среде работают тестировщики. Тут тестируются новые билды. Здесь тестировщики проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования.
Интеграционная среда (Integration Env) – иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды – также, как и в случае со средой тестирования.
Превью среда (Preview, Preprod Env) – в идеале, это среда идентичная или максимально приближенная к продакшену: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят приемочное тестирование (User Acceptance Testing (UAT)), а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
Продакшн среда (Production Env) – среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3.

Основные фазы тестирования

Pre-Alpha: ПО является прототипом. Пользовательский интерфейс завершен. Но не все функции завершены. На данном этапе ПО не публикуется.
Alpha: является ранней версией программного продукта. Цель — вовлечь клиента в процесс разработки. Хороший Альфа-тест должен иметь четко определенный план тестирования с комплексными тестовыми примерами. Это дает лучшее представление о надежности программного обеспечения на ранних стадиях. В некоторых случаях тестирование может быть передано на аутсорс.
Beta: ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
Release Candidate (RC): основываясь на отзывах Beta Test, вы вносите изменения в ПО и хотите проверить исправления ошибок. На этом этапе вы не хотите вносить радикальные изменения в функциональность, а просто проверяете наличие ошибок. RC также может быть выпущен для общественности.
Release: все работает, ПО выпущено для общественности.

Основные виды тестирования ПО

Классификация по запуску кода на исполнение:
- Статическое тестирование — при статическом тестировании код не выполняется. Вы вручную проверяете код, документы требований и проектные документы на наличие ошибок. Отсюда и название «статичный». Основная цель этого тестирования — повысить качество программных продуктов путем выявления ошибок на ранних этапах цикла разработки.
- Динамическое тестирование — при динамическом тестировании выполняется код. Оно проверяет функциональное поведение ПО, использование памяти / процессора и общую производительность системы. Основная цель этого тестирования — подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Динамическое тестирование выполняется на всех уровнях тестирования, и это может быть либо тестирование черного, либо белого ящика.
Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
- Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
- Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения – техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Классификация по уровню детализации приложения:
- Модульное тестирование — модульные тесты используются для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками.
- Интеграционное тестирование — предназначено для проверки насколько хорошо два или более модулей ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
- Системное тестирование — процесс тестирования системы в целом, чтобы проверить, соответствует ли она установленным требованиям.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО стартует и выполняет основные функции без критических и блокирующих дефектов.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения (корректность реализации функциональных требований).
- Нефункциональное тестирование (non-functional testing) — анализ атрибутов качества компонента или системы, не относящихся к функциональности, то есть проверка, «как работает система».
  1. Тестирование производительности (performance testing) —определение работоспособности, стабильности, потребления ресурсов в условиях различных сценариев использования и нагрузок.
  2. Нагрузочное тестирование (load testing) — оценка поведения системы при возрастающей нагрузке, а также для определения нагрузки, которую способны выдержать компонент или система.
  3. Тестирование масштабируемости (scalability testing) — тестирование программного обеспечения для измерения возможностей масштабирования.
  4. Объёмное тестирование (volume testing) — тестирование, при котором система испытывается на больших объёмах данных.
  5. Стрессовое тестирование (stress testing) — вид тестирования производительности, оценивающий систему на граничных значениях рабочих нагрузок или за их пределами.
  6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
  7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
  8. Тестирование удобства использования (usability testing) — проверка того, насколько легко конечный пользователь системы может понять и освоить интерфейс.
  9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для нового места эксплуатации (например, при смене языка).
  10. Тестирование безопасности (security testing) — тестирование программного продукта, чтобы определить его защищённость.
  11. Тестирование надёжности (reliability testing) — тестирование способности приложения выполнять свои функции в заданных условиях на протяжении заданного времени.
  12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
  13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна:

Тестирование на основе классов эквивалентности (equivalence partitioning) — техника тест-дизайна на основе метода чёрного ящика. Помогает разрабатывать и выполнять меньше тест-кейсов, при этом сохраняя достаточное тестовое покрытие.
Техника анализа граничных значений (boundary value testing) — проверка поведения продукта на крайних значениях входных данных.
Попарное тестирование (pairwise testing) — разработка тестов методом чёрного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Тестирование на основе состояний и переходов (State-Transition Testing) применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
Исследовательское тестирование (Exploratory Testing) — это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя.

Типы тестирования

Согласно ISTQB, тестирование белого ящика — это:
– тестирование, основанное на анализе внутренней структуры компонента или системы;
– тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

Тестовая документация

Тест план должен отвечать на следующие вопросы:

Что надо тестировать?
Что будете тестировать?
Как будете тестировать?
Когда будете тестировать?
Критерии начала тестирования.
Критерии окончания тестирования.

Основные пункты тест плана:

В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:
a) Идентификатор тест плана (Test plan identifier);
b) Введение (Introduction);
c) Объект тестирования (Test items);
d) Функции, которые будут протестированы (Features to be tested;)
e) Функции, которые не будут протестированы (Features not to be tested);
f) Тестовые подходы (Approach);
g) Критерии прохождения тестирования (Item pass/fail criteria);
h) Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
i) Результаты тестирования (Test deliverables);
j) Задачи тестирования (Testing tasks);
k) Ресурсы системы (Environmental needs);
l) Обязанности (Responsibilities);
m) Роли и ответственность (Staffing and training needs);
n) Расписание (Schedule);
o) Оценка рисков (Risks and contingencies);
p) Согласования (Approvals).

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Атрибуты тест кейса:

Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Ожидаемый результат (PostConditions) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

Тестирование. Фундаментальная теория +13

Тестирование IT-систем

Рекомендация: подборка платных и бесплатных курсов создания сайтов — https://katalog-kursov.ru/

Доброго времени суток!

Хочу собрать всю самую необходимую теорию по тестирвоанию, которую спрашивают на собеседованиях у trainee, junior и немножко middle. Собственно, я собрал уже не мало. Цель сего поста в том, чтобы сообща добавить упущенное и исправить/перефразировать/добавить/сделатьЧтоТоЕщё с тем, что уже есть, чтобы стало хорошо и можно было взять всё это и повторить перед очередным собеседованием про всяк случай. Вообщем, коллеги, прошу под кат, кому почерпнуть что-то новое, кому систематизировать старое, а кому внести свою лепту.

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

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

В теме: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, tets case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

Поехали!

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

Этапы тестирования:
1. Анализ
2. Разработка стратегии тестирования
и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staf?ng and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — эта «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Traceability matrix — Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)
Виды Тестовых Случаев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
• Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
• Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

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

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
• S1 Блокирующий (Blocker)
• S2 Критический (Critical)
• S3 Значительный (Major)
• S4 Незначительный (Minor)
• S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
• P1 Высокий (High)
• P2 Средний (Medium)
• P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.
…
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.

Градация Серьезности дефекта (Severity)

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

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

Виды / типы тестирования

Функциональные виды тестирования
• Функциональное тестирование (Functional testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

Нефункциональные виды тестирования
• Все виды тестирования производительности:
o нагрузочное тестирование (Performance and Load Testing)
o стрессовое тестирование (Stress Testing)
o тестирование стабильности или надежности (Stability / Reliability Testing)
o объемное тестирование (Volume Testing)
• Тестирование установки (Installation testing)
• Тестирование удобства пользования (Usability Testing)
• Тестирование на отказ и восстановление (Failover and Recovery Testing)
• Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования
• Дымовое тестирование (Smoke Testing)
• Регрессионное тестирование (Regression Testing)
• Повторное тестирование (Re-testing)
• Тестирование сборки (Build Verification Test)
• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
Тестирование пользовательского интерфейса (англ. UI Testing) — это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.
User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.

Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

Подходы к интеграционному тестированию:

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

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

• Большой взрыв («Big Bang» Integration)
Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

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

Принцип 5 — Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.

Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

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

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

Требования к требованиям:
• Корректность
• Недвусмысленность
• Полнота набора требований
• Непротиворечивость набора требований
• Проверяемость (тестопригодность)
• Трассируемость
• Понимаемость

Жизненный цикл бага

Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).

Жизненный цикл разработки ПО:
• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

Источники: www.protesting.ru, www.bugscatcher.net, www.qalight.com.ua, www.thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, www.bugsclock.blogspot.com, www.zeelabs.com, www.devopswiki.net, www.hvorostovoz.blogspot.com.

проблемы. На этом этапе формулируется целевое назначение и основные свойства разрабатываемой программной системы.

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

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

Рис. 2.2 – Схема декомпозиции системы

Таким образом, создается иерархия связанных подсистем (обязательно непересекающихся).

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

время обработки (работы) программы;

стоимость обработки;

вероятность ошибки;

реакция на непредсказуемые действия оператора (защита от

дурака) и др.

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

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

К важнейшим требованиям относятся ресурсные требования и затраты на реализацию системы.

Фактически, анализ требований завершается составлением развернутого технического задания на систему, которое в терминологии классического САПР называется аван-проектом.

2.2. Определение спецификаций

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

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

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

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

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

Так как функциональные спецификации описывают принятые решения в целом, данный документ можно использовать для началь-

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

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

2.3. Проектирование

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

реализуемые функции;

размеры;

время выполнения и др.

Вцелом соотношения «требования – спецификация – проектирование» можно проиллюстрировать следующей схемой (рис. 2.3).

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

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

Реальный мир

Абстракция (формализация)

Требования (1) Спецификация (2)

Реализация (4) Проектирование (3)

Рис. 2.3 – Схема проектирования программных систем

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

В процессе проектирования системы, по мере выполнения спецификаций на определенные подмодули, последние представляются в виде древовидной схемы, показывающей вхождение элементов систе-

мы (рис. 2.4).

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

Управляющая

программа

	Синтаксический		Генератор
	анализатор		кода

Блок	Программа	Вывод на
сканирования	таблицы символа	печать

Чтение

Рис. 2.4 – Структурная схема компилятора

2.4. Кодирование

Данный этап является наиболее простым, а его реализация существенно облегчается при использовании алгоритмических языков высокого уровня. Кодирование – это этап разработки программного обеспечения, доставляющий наименьшее беспокойство разработчику. По имеющимся статистическим данным 64% всех ошибок вносятся на этапах проектирования и лишь 36% на этапе кодирования. Однако эти ошибки могут быть очень дорогостоящими (DO 4 I=1,5 и DO 4 I=1.5). В общем случае кодирование освоено лучше, чем другие этапы создания программ, и очень четко формализовано.

2.5. Тестирование

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

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

Тестирование подразумевает три стадии:

автономное;

комплексное и

системное.

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

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

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

Впроцессе тестирования, для определения правильности выполнения программы вводится ряд критериев:

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

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

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

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

Хотя критерии 1) и 2) кажутся схожими, в действительности

они сильно разнятся. Например, арифметический оператор IF в

Fortran:

IF (Выражение) N1, N2, N3.

Критерий 1) подразумевает, что IF должен быть выполнен, в то время как 2) подразумевает различные наборы данных, для того чтобы выполнились условия N1, N2, N3 (т.е. передачу на эти метки).

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

Тесно связаны с тестированием понятия «верификация» и «испытание».

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

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

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

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

Различаются три вида отклонения от нормальной работы систе-

мы.

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

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

Ошибка – это алгоритмический дефект, который создает выброс (программная ошибка).

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

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

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

2.6.Эксплуатация и сопровождение

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

(рис. 2.5):

1) анализ требований;

2) определение спецификаций;

3) проектирование;

4) кодирование;

5) автономное тестирование;

6) комплексное тестирование;

7) сопровождение.

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

1) Заказчик обычно не может четко сформулировать свои требования, редко бывает удовлетворен созданной системой и поэтому настаивает на внесении изменений в готовую систему;

2) могут быть обнаружены ошибки, пропущенные при тестировании;

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

4) сопровождение многочисленных компонентов системы. Рассмотрим затраты, оказывающие наибольшее влияние на про-

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

Определение спецификаций (3%)

Анализ требований (3%)

Проектирование (5%)

Кодирование

(7%)

Автономное

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

(8%)

Комплексное

тестирование Сопровождение (7%)

(67%)

Рис. 2.5 – Временные затраты на реализацию этапов жизненного цикла программного обеспечения

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

Пусть некоторая система содержит компоненты A, B, C и установлена у потребителей I, II, III (рис. 2.6).

A	A	A
B	B	B
C	C	C
I	II	III
	Рис. 2.6 – Исходные системы потребителей

В процессе эксплуатации системы потребитель I обнаружил ошибку и сообщил об этом разработчику. Последний корректирует ее и направляет исправленный модуль A’ всем пользователям системы. Опыт применения надежного программного обеспечения показывает, что большинство потребителей ведет себя осторожно в отношении внесенных изменений. Поэтому потребители II и III, не встречаясь с

задачами, решаемыми потребителем I, продолжают использовать первоначальный вариант системы, поддерживая принцип «если система работает, не вмешивайся». Спустя некоторое время потребители I и II обнаружили другую ошибку в модуле A. Разработчик должен определить, являются ли обе обнаруженные ошибки одной и той же, поскольку использовались различные версии модуля A. Исправление ошибки ведет к корректировке модуля A и A’, в результате чего в эксплуатацию вводятся модули A’’ и A’’’. Теперь функционируют уже три версии системы (рис. 2.7).

A’’	A’’’	A
B	B	B
C	C	C
I	II	III
	Рис. 2.7 – Система после исправления двух ошибок

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

ни, называемые периодами обновления.

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

Контрольные вопросы

1)Этапы разработки программного обеспечения.

2)Анализ требований, предъявляемых к системе.

3)Жизненный цикл программного обеспечения.

4)Функциональные спецификации. Определение спецификаций.

5)Проектирование. Кодирование.

6)Тестирование: программное, системное, оценочное и сравнительное.

7)Сбой системы, выброс, ошибка. Испытания. Верификация системы.

Правильность и надежность программ.

9)Эксплуатация и сопровождение. Периоды обновления.

Дефекты. Ошибки, сбои, отказы

Ожидаемый результат — поведение системы, описанное в требованиях.

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

Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями:

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

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

Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

В некоторых средствах одного из состояний нет (оно поглощается другим)

«Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
«Дубликат» — данный дефект уже описан в другом отчёте.
«Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
«Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
«Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».

Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

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

— быть достаточно коротким, чтобы полностью помещаться на экране;

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

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

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

иного) языка, построенным по соответствующим правилам

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
Сформулировать подробное описание
3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

его, сократив длину (за счёт подбора синонимов, использования

общепринятых аббревиатур и сокращений). К слову, в английском языке

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

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

Пример подробного описания :

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

Пример шагов воспроизведения :

Открыть http://testapplication/admin/login/.
Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

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

Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).

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

— Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

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

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

— Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

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

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

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

В качестве примера рассмотрим следующие значения симптомов дефекта.

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

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

Часто у одного дефекта может быть сразу несколько симптомов.

Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

ОГЛАВЛЕНИЕ

1 Введение. Проблемы современного программирования. 8
2 Этапы разработки программного обеспечения. 10
2.1 Анализ требований, предъявляемых к системе. 11
2.2 Определение спецификаций. 12
2.3 Проектирование. 13
2.4 Кодирование. 15
2.5 Тестирование. 16
2.6 Эксплуатация и сопровождение. 19
Контрольные вопросы.. 21
3 Методы разработки программного обеспечения как научная дисциплина 23
3.1 Методы управления разработкой. 23
3.1.1 Выполнение проекта. 25
3.1.2 Методика оценки затрат. 27
3.1.3 Контрольные точки. 32
3.1.4 Средства разработки. 33
3.1.5 Надежность. 34
3.2 Методы проведения разработки программного обеспечения 34
3.3 Развитие методов разработки программного обеспечения. 37
3.3.1 Язык определения задач и анализатор задач. 38
3.3.2 Система структурного анализа и проектирования SADT 40
3.3.3 Система SREM.. 42
3.3.4 Методика Джексона. 42
3.4 Выводы.. 43
Контрольные вопросы.. 44
4 Методы разработки программного обеспечения. 46
4.1 Язык проектирования программ.. 46
4.2 Стратегия проектирования. 50
4.2.1 Нисходящее проектирование и нисходящая разработка 50
4.2.2 Структурное проектирование. 54
4.3 Данные. 59
4.3.1 Обзор структур данных. 59
4.3.2 Абстрактные конструкции. 65
Контрольные вопросы.. 78
5 Правильность программ.. 80
5.1 Аксиомы.. 80
5.2 Правила преобразования данных. 83
5.3 Доказательства правильности программ.. 83
Контрольные вопросы.. 86
6 Тестирование. 87
6.1 Психология и экономика тестирования программ.. 87
6.2 Экономика тестирования. 90
6.2.1 Тестирование программы как черного ящика. 90
6.2.2 Тестирование программы как белого ящика. 91
6.2.3 Принципы тестирования. 94
6.3 Ручное тестирование. 100
6.3.1 Инспекции и сквозные просмотры.. 101
6.3.2 Инспекции исходного текста. 103
6.3.3 Список вопросов для выявления ошибок при инспекции 106
6.3.4 Сквозные просмотры.. 119
6.3.5 Оценка посредством просмотра. 120
6.4 Проектирование теста. 122
6.4.1 Тестирование путем покрытия логики программы.. 123
6.4.2 Эквивалентное разбиение. 132
6.4.3 Анализ граничных значений. 139
6.4.4 Применение функциональных диаграмм.. 146
6.4.5 Предположение об ошибке. 166
6.4.6 Стратегия. 168
Контрольные вопросы.. 169
7 Технология разработки программ.. 170
7.1 Разбиение задачи на независимые подзадачи. 170
7.2 Разбиение задачи на одинаковые по сложности части. 170
7.3 Рекурсия и динамическое программирование. 171
7.3.1 Рекурсия. 171
7.3.2 Динамическое программирование. 172
7.3.3 Моделирование. 172
7.4 Поиск. 172
7.4.1 Поиск в списках. 173
7.4.2 Деревья поиска. 175
7.4.3 Стратегия распределения памяти. 178
7.5 Сортировка. 179
7.6 Алгоритм выбора из конечного состояния. 181
7.7 Сопрограммы.. 181
Контрольные вопросы.. 183
8 Методы управления проектированием программных изделий 184
8.1 Организация управления проектированием программного изделия 184
8.1.1 Понятие изделия как средства общения. 184
8.1.2 Нисходящий анализ процесса управления проектированием программного изделия 185
8.1.3 Организация взаимодействия. 186
8.1.4 Установление целей, средства их достижения. 187
8.1.5 Подбор и обучение кадров. 189
8.2 Организация планирования разработок программного изделия 190
8.2.1 Виды планов. 191
8.2.2 Декомпозиция планов. 194
8.2.3 Организационная структура группы планирования. 195
8.2.4 Планы, связанные с созданием программных изделий. 197
8.2.5 Опытный образец изделия. 200
8.2.6 Организация планирования в фазе исследования. 200
8.2.7 Организация планирования в стадии анализа осуществимости 203
8.2.8 Организация планирования в фазах конструирования и кодирования 203
8.2.9 Организация планирования в фазах оценки и использования 204
8.2.10 Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия. 205
8.3 Организация разработки программного изделия. 208
8.3.1 Организация разработки программного изделия в фазе исследований 209
8.3.2 Организация разработки программного изделия в фазе анализа осуществимости 211
8.3.3 Организация разработки программного изделия в фазе конструирования (проектирования) 213
8.3.4 Организация разработки программного изделия в фазе программирования 214
8.3.5 Организация разработки программного изделия в фазе оценки 217
8.3.6 Окончание проекта. 219
8.3.7 Участие группы разработки в фазовых обзорах. 220
8.4 Организация обслуживания разработки программного изделия 222
8.4.1 Организационная структура группы обслуживания. 223
8.4.2 Организация обслуживания программного изделия в фазе исследования 223
8.4.3 Организация обслуживания в фазах анализа осуществимости и конструирования 224
8.4.4 Организация обслуживания в фазе программирования и оценки 226
8.4.5 Организация обслуживания в фазе использования. 228
8.4.6 Участие группы обслуживания в фазовых обзорах. 230
8.5 Организация выпуска документации. 231
8.5.1 Организационная структура группы выпуска документации 231
8.5.2 Стандарты и практические руководства. 233
8.5.3 Организация выпуска документации в фазах исследований и анализа осуществимости 235
8.5.4 Организация выпуска документации в фазах конструирования и программирования 236
8.5.5 Организация выпуска документации в фазах оценки и использования 238
8.5.6 Участие группы выпуска документации в фазовых обзорах 239
8.6 Организация испытаний программных изделий. 240
8.6.1 Современное состояние методов обеспечения качества программного изделия 241
8.6.2 Организационная структура группы испытаний. 246
8.6.3 Организация испытаний в фазах исследований и анализа осуществимости 249
8.6.4 Организация испытаний в фазах конструирования и программирования 250
8.6.5 Организация испытаний в фазе оценки. 251
8.6.6 Организация испытаний в фазе использования. 254
8.6.7 Участие группы испытаний в фазовых обзорах. 254
Контрольные вопросы.. 255
Список литературы.. 257

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

Первый этап развития программирования в первую очередь был связан с накоплением опыта в приобретении технических (стандартных) навыков написания программ. Однако по мере развития средств вычислительной техники и накопления этих навыков существенно изменилось положение. Возникли естественные вопросы — продолжаем ли мы делать ошибки?; является ли сам процесс написания программ правильным?; не возникла ли необходимость в создании новых методов разработки программного обеспечения?
Ответом на эти вопросы и занимается научная дисциплина — методы (технология) разработки программного обеспечения. Круг вопросов, который рассматривает данная дисциплина, связан с классическими составляющими программирования:
— написанием спецификаций;
— проектированием;
— тестированием и
— функционированием программ.
Практическую значимость данной дисциплины можно проиллюстрировать путем сопоставления состояний дел по разработке технических систем и больших программных систем.
· В 1958 году в США приступили к строительству Веррацано-Нарроуского моста. По расчетам инженеров затраты на строительство определялись в размере 325 млн $, а работы планировалось завершить в 1965 году. Это самый большой подвесной мост в мире. Работы по нему завершились в ноябре 1964 года в соответствии с проектной сметой.
· Приблизительно в это же самое время производилась разработка операционной системы OS фирмы IBM. По планам разработчиков длительность разработки составляла 5000 человеко-лет. Но несмотря на все возможные принятые фирмой меры, завершилась на 4 года позже планируемого срока.
Возникает вопрос, почему в технических системах возможен достаточно точный прогноз, тогда как при разработке программных систем он оказывается несостоятельным?
Частично на этот вопрос можно ответить следующим образом — инженеру проще предусмотреть возрастающую сложность строительства, вызванную увеличением размеров моста, чем разработчику программного обеспечения определить сложность программы большого размера.
В настоящем курсе мы будем рассматривать методы и технические приемы, введение которых позволит уменьшить стоимость и повысить надежность программ.
В общем случае методы разработки программного обеспечения не есть программирование, хотя программирование составляет важную ее часть. Данный предмет также не сводится к проблеме изучения компиляторов и операционных систем, хотя они также играют существенную роль в рассматриваемой технологии. Точно так же проблемы электронной техники, структуры ЭВМ не являются предметом исследований, хотя и их знание в данном предмете необходимо.
Методы разработки программного обеспечения — это синтезированная дисциплина, в которой для составления алгоритмов используются математические методы, для оценки затрат и выбора компромиссных решений — методы инженерных расчетов, для определения требований к системе, учета ситуаций, связанных с потерями, организации работы исполнителей и прогнозирования — методы управления. Все это и будет предметом наших исследований.

Этапы разработки программного обеспечения

1) анализ требований, предъявляемых к системе;
2) определение спецификаций;
3) проектирование;

Анализ требований, предъявляемых к системе

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

Определение спецификаций

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

Проектирование

— реализуемые функции;
— размеры;
— время выполнения и др.

Кодирование

Тестирование

В процессе тестирования используются данные, характерные для системы в рабочем состоянии, т.е. данные для тестирования выбираются случайным образом.… Тестирование подразумевает три стадии:
— автономное;

Эксплуатация и сопровождение

1) анализ требований;
2) определение спецификаций;
3) проектирование;

Контрольные вопросы

1. Этапы разработки программного обеспечения.
2. Анализ требований, предъявляемых к системе.
3. Жизненный цикл программного обеспечения.
4. Функциональные спецификации. Определение спецификаций.
5. Проектирование. Кодирование.
6. Тестирование: программное, системное, оценочное и сравнительное.
7. Сбой системы, выброс, ошибка. Испытания. Верификация системы.
8. Правильность и надежность программ.
9. Эксплуатация и сопровождение. Периоды обновления.

Методы разработки программного обеспечения как научная дисциплина

1) разработка методов управления сложными системами;
2) повышение надежности и правильности программного обеспечения;
3) развитие методов более точного прогнозирования затрат на создание программного обеспечения.

Методы управления разработкой

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

Выполнение проекта

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

Методика оценки затрат

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

Методика инженерно-технической оценки затрат

Шаг 1. Формируются общие требования к системе исходя из существующего технического задания. Потенциальных разработчиков информируют о том, что… Шаг 2. Собирается аналогичная информация, например данные о подобных… Шаг 3. Отбираются основные релевантные данные.

Оценка на основе распределения Рэлея

где E(t) — суммарные затраты к моменту времени t;
К — общая стоимость системы;

Контрольные точки

Существует большое количество «стандартных» контрольных точек:
— выпуск функциональных спецификаций;
— завершение проектирования отдельных модулей;

Средства разработки

Среди таких средств следует особо выделить системы управления базами данных (СУБД), которые помогают управлять организацией разрабатываемого… Одной из первых систем управления базой данных с возможностью ведения…

Надежность

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

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

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

Развитие методов разработки программного обеспечения

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

Язык определения задач и анализатор задач

1) язык описания задач PSL, предназначенный для отображения функциональных требований и требований к ресурсам. Этот язык содержит набор средств… 2) анализатор определения задач PSA, представляющий собой процессор, с помощью… Язык PSL имеет простой синтаксис и ориентирован на использование ключевых слов. Основными операторами этого языка…

Система структурного анализа и проектирования SADT

Рис. 3.7 — Структура SADT (SA — формальный язык описания взаимосвязей между… Структура системы:

Система SREM

· Трансляция. Разрабатывается система требований, включающая описатели данных и этапы их обработки.
· Декомпозиция. Разрабатываются подробные проекты.
· Распределение. С помощью процессора REVS моделируются отдельные аспекты проектных решений с учетом принятых…

Методика Джексона

Элемент. Функция, которая не может быть разбита на более простые функции.
Последовательность. Ряд функций, реализуемых последовательно и однократно.
Выборка. Одна из возможных последовательностей.

Выводы

Проведенный обзор методов проектирования показал, что всем этим методам присущи общие черты. Хотя такие методы и способствуют получению рациональной структуры системы, тем не менее они не исключают необходимость в творческом процессе вырабатывания основополагающих на этапах анализа требований, определения спецификаций и проектирования. Благодаря использованию этих методов становится возможным уделять больше времени профессиональной стороне разработки программного обеспечения.
Существует ряд стратегий объединения различных методов в единую методологию. Наиболее эффективную стратегию создал Боэм, который сформулировал семь принципов разработки программного обеспечения:
1) управление разработкой на основе последовательной реализации отдельных этапов жизненного цикла программного обеспечения. Применение этого принципа позволяет на каждом этапе принимать обоснованные решения с учетом результатов, достигнутых на предыдущих этапах, и способствует использованию контрольных точек для оценки состояния разработки проекта;
2) выполнение испытаний. На каждом шаге совершенствования модуля осуществляется его аттестация;
3) осуществление строгого контроля над ходом разработки. Вся выходная документация — проекты программ, исходные программы, инструкции пользователю и т.д. — должна быть формально утверждена. Внесение любых изменений в документацию и библиотеки программ должно строго контролироваться и осуществляться лишь с разрешения соответствующих должностных лиц;
4) использование всего диапазона средств структурного программирования. По возможности желательно применять языки, позволяющие реализовать удобные структуры управления и данных. Для описания процессов желательно использовать технику пошагового совершенствования;
5) строгий учет. Для учета достигнутого прогресса в разработке системы необходимо использовать контрольные точки, а для проверки работы каждого исполнителя — системный журнал;
6) использование немногочисленного штата, укомплектованного квалифицированными работниками. Хорошие результаты работы дает использование принципа организации бригады главного программиста;
7) высокий уровень. Необходимо использовать имеющиеся достижения в области технологии и разработки программного обеспечения, не забывая при этом о надежности и возможности модификации программ.
Средства управления и контроля над разработкой программного обеспечения еще требуют совершенствования, однако сам процесс управления при этом приближается к уровню, свойственному другим техническим областям.

Контрольные вопросы

1. Методы разработки программного обеспечения как научная дисциплина.
2. Организация интерфейса между модулями, написанными разными программистами.
3. Выполнение проекта. Бригада главного программиста.
4. Методика оценки затрат. Методика инженерно-технической оценки затрат.
5. Методика экспертных оценок. Метод алгоритмического анализа. Пошаговый анализ. Закон Паркинсона.
6. Затраты на завершение разработки.
7. Оценка длительности разработки на основе распределения Рэлея.
8. Контрольные точки. Средства обработки. Надежность. Концептуальная целостность.
9. Верификация и испытания. Дамп. Трассировка. Анализ графов программ.
10. «Уровни правильности» программ.
11. Методы программирования. Эффективность программ.
12. Определение спецификаций. Язык определения задач и анализатор определения задач (PSL/PSA).
13. Система структурного проектирования SADT.
14. Структурное проектирование. Методика Джексона.
15. Стратегия объединения различных методов проектирования.

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

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

Язык проектирования программ

Для создания такой системы записи был разработан язык проектирования программ PDL. Этот язык строится по образу универсальных языков… Язык проектирования обычно состоит из двух частей:
— заданного набора операторов, построенных по образцу языков программирования;

Стратегия проектирования

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

Рис. 4.2 — Пример базисной схемы
На приведенной базисной схеме каждый блок — это модуль системы. При этом вызов каждого модуля производится модулем…

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

Вначале программист представляет задачу как набор задач:
do task A;
do task B;

Данные

Обзор структур данных

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

Массивы

Массивы — это простейшие агрегативные данные в языках программирования. Массивом называется упорядоченный набор данных одного типа
declare A(10) FIXED BINARY;
Объявлен массив A из десяти двоичных переменных с фиксированной точкой с именами A(1), A(2), A(3),…, A(9), A(10). Аналогично
declare B(5:10) FIXED BINARY;
объявлен массив B из шести элементов с именами B(5), B(6), …, B(10). Массивы могут быть как одномерными, так и многомерными.

Структуры

Самой сложной разновидностью данных в языках программирования являются структуры. Структурой называют поименованную совокупность различных типов данных.
declare 1 X,
2 Y FIXED BINARY,
2 Z BIT(12);
Объявляется структура с именем Х, состоящая из двоичной переменной с фиксированной точкой с именем X.Y и строки длиной 12 бит с именем X.Z.
Структуры могут использоваться для создания переменных нового типа.

Списки

Списком называют упорядоченный набор переменных одного типа. Список отличается от массива тем, что его размер обычно является переменной величиной, т.е. элементы могут добавляться в список и изыматься из него.
Список может быть объявлен как:
declare 1 LIST(N),
2 DATA_ENTRIES TYPE (некоторый тип данных),
SIZE; /* текущий размер списка */
Элементами списка являются DATA_ENTRIES(1), DATA_ENTRIES(2),… , DATA_ENTRIES(SIZE).
Если список может расти неограниченно, то такой способ описания не годится, поскольку SIZE может стать больше, чем N. Другой способ состоит в реализации совокупности базированных переменных.
declare 1 LIST BASED,
2 DATA_ENTRIES TYPE (некоторый тип данных);
2 FPTR POINTER /* указатель следующей записи
в списке */
LIST_HEAD POINTER; /* указатель первого
элемента в списке */
В первом случае элементами списка являются
LIST.DATA_ENTRIES(1),
LIST.DATA_ENTRIES(2),
LIST.DATA_ENTRIES(3),
…
LIST.DATA_ENTRIES(SIZE),
а во втором
LIST_HEAD ® DATA_ENTRIES
(LIST_HEAD ® FPTR) ® DATA_ENTRIES
((LIST_HEAD ® FPTR) ® FPTR) ® DATA_ENTRIES
…
Для работы со списками обычно используются следующие операторы (рис. 4.9, а):
1) ADD — поместить новый элемент в список;
2) DELETE — удалить элемент из списка;
3) SEARCH — проверить наличие элемента в списке.

Рис. 4.9 — Агрегативные структуры и соответствующие им операторы

Очереди

1) INSERT — добавить элемент в очередь;
2) DELETE — удалить элемент из очереди.

Стеки

Стек — это упорядоченный список, в один конец которого элементы добавляются и изымаются из этого же конца. Стек называют списком LIFO — Last In, Fist Out (поступивший последним обслуживается первым). Аналогично очереди, стек может быть организован любым из рассмотренных выше способов, однако использование массивов более эффективно. Для работы со стеком обычно используются три операции (рис. 4.9, в).
1) PUSH — поместить элемент в стек;
2) POP — извлечь элемент из стека;
3) EMPTY — функция, принимающая значение ИСТИННО, если стек не заполнен.

Множества

Множества обрабатываются с использованием следующих операторов (рис. 4.9, г):
1) INSERT — добавить новый элемент во множество;
2) DELETE — удалить элемент из множества;

Графы

Направленный граф — это структура, состоящая из узлов и дуг, причем каждая дуга направлена от одного узла к другому. Графы обычно организовываются с помощью базированных переменных, где дуги являются переменными типа указатель. Если из каждого узла выходит несколько дуг, то граф можно описать следующим образом:
declare 1 GRAPH BASED,
2 DATA_ENTPIES TYPE (некоторый тип данных),
2 EDGES(N) POINTER;
Для ненаправленных графов дугам соответствуют два направления — вперед и назад:
declare 1 GRAPH BASED,
2 DATA_ENTPIES TYPE (некоторый тип данных),
2 FORWARD_EDGES(N) POINTER,
2 BACKWARD_EDGES(N) POINTER;
Операторы для работы с графами представлены на рис. 4.9, д.

Деревья

Дерево — это направленный граф, обладающий следующими свойствами:
1) только один узел не имеет дуг, входящих в него (корневой узел);
2) в каждый узел входит не более одной дуги;
3) в каждый узел можно попасть из корневого узла за несколько шагов.

Абстрактные конструкции

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

Фиксированные типы данных абстрактного типа

Например, для того чтобы задать стек, программист должен добавить следующее объявление в каждую процедуру, которая содержит обращение к стеку.
declare 1 STACK,
2 ENTRIES(100) TYPE(INTEGER),

Размещение указателей

declare STACK POINTER;
call STACK_INITIALIZATION(STACK);
В этом случае процедура STACK_INITIALIZATION должна быть вызвана явным образом для того, чтобы разместить стек в…

Защита данных от несанкционированного доступа

declare X ENVIRONMENT(STACK);
Для пользователя Х — это стек, к которому можно обращаться из процедуры STACK… 1) обработка стека Х происходит в процедуре FUNCTION в модуле с именем STACK;

Контрольные вопросы

1. Язык проектирования программ PDL. Операторы выбора. Операторы цикла. Операторы описания данных. Операторы ввода/вывода и вызова процедур. Оператор leave. Предложения на естественном языке.
2. Нисходящее проектирование и нисходящая разработка.
3. Пошаговое совершенствование.
4. Восходящее проектирование.
5. Подыгрывающие программы (заглушки).
6. Структурное проектирование. Простая программа. Элементарная программа. Управляющие структуры, способы их описания.
7. Скалярные и агрегативные типы данных.
8. Массивы. Структуры. Списки. Очереди. Стеки. Множества. Графы. Деревья.
9. Абстрактные конструкции.
10. Фиксированные данные абстрактного типа.
11. Размещение указателей.
12. Защита данных от несанкционированного доступа.

Правильность программ

«Если P истинно и если выполняется оператор S, то Q истинно».
Предикат P является спецификацией правильного выполнения оператора S, а… Если это утверждение распространить на все операторы программы и если P является спецификацией первого оператора, а Q…

Аксиомы

1) если {P}S{Q} и Q Þ R, то {P}S{R};
2) если {Q}S{R} и P Þ Q, то {P}S{R}.
Первое правило заключается в следующем: «Если P — предусловие для Q и если Q Þ R является теоремой исчисления…

Правила преобразования данных

Коммутативность:

Ассоциативность:

Дистрибутивность:

Вычитание:

Обработка констант:

Доказательства правильности программ

1. MULTIPLY (R,A,B);
2. declare X;
3. declare R; /* R=A*B */

Контрольные вопросы

1. Правильность программ.
2. Правила следствия.
3. Аксиома присвоения.
4. Аксиома следования.
5. Аксиома цикла.
6. Аксиома выбора.
7. Правила целочисленной арифметики — коммутативность, ассоциативность, дистрибутивность, вычитание, обработка констант.
8. Доказательство правильности программ.

Тестирование

Психология и экономика тестирования программ

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

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

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

Тестирование программы как черного ящика

При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если… Если такое испытание представляется сложным, то еще сложнее создать… Из изложенного следует, что построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами:…

Тестирование программы как белого ящика

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

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

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

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

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

Инспекции и сквозные просмотры

Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Эти методы развиты из идей Вейнберга. Оба… Инспекции и сквозные просмотры широко практикуются в настоящее время, но… Эксперименты по применению этих методов показали, что с их помощью для типичных программ можно находить от 30 до 70 %…

Инспекции исходного текста

Инспектирующая группа включает обычно четыре человека, один из которых выполняет функции председателя. Председатель должен быть компетентным… Общая процедура заключается в следующем. Председатель заранее (например, за… 1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель…

Список вопросов для выявления ошибок при инспекции

Ошибки обращения к данным

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

Ошибки описания данных

2. Если не все атрибуты переменной явно присутствуют в описании, то понятно ли их отсутствие? Например, отсутствие атрибутов, считающееся… 3. Если начальные значения присваиваются переменным в операторах описания, то… 4. Правильно ли для каждой переменной определены длина, тип и класс памяти (например, STATIC, AUTOMATIC, BASED или…

Ошибки вычислений

2. Существуют ли вычисления, использующие данные разного вида? Например, сложение переменной с плавающей точкой и целой переменной. Такие случаи не… DECLARE A BIT(1);
A=1;

Ошибки при сравнениях

2. Сравниваются ли величины различных типов или величины различной длины? Если да, то проверьте, правильно ли интерпретируются (поняты) правила… 3. Корректны ли операторы сравнения? Программисты часто путают такие… 4. Каждое ли булевское выражение сформулировано так, как это предполагалось? Программисты часто делают ошибки при…

Ошибки в передачах управления

2. Будет ли каждый цикл, в конце концов, завершен? Придумайте неформальное доказательство или аргументы, подтверждающие их завершение.
3. Будут ли программа, модуль или подпрограмма, в конечном счете, завершены?
… 4. Возможно ли, что из-за входных условий цикл никогда не сможет выполняться? Если это так, то является ли это…

Ошибки интерфейса

2. Совпадают ли атрибуты (например, тип и размер) каждого параметра с атрибутами соответствующего ему аргумента?
3. Совпадают ли единицы измерения каждого параметра с единицами измерения… 4. Равно ли число аргументов, передаваемых из рассматриваемого модуля другому модулю, числу параметров, ожидаемых в…

Ошибки ввода-вывода

2. Являются ли правильными атрибуты оператора OPEN?
3. Согласуется ли спецификация формата с информацией в операторах…

Другие виды контроля

2. Если компилятор выдает список атрибутов, проверьте атрибуты каждой величины для обеспечения гарантии того, что в программе нет никаких… 3. Если программа оттранслирована успешно, но компилятор выдает одно или… 4. Является ли программа (или модуль) достаточно устойчивой? Иными словами, проверяет ли она правильность своих…

Сквозные просмотры

Подобно инспекции, сквозной просмотр проводится как непрерывное заседание, продолжающееся один или два часа. Группа по выполнению сквозного… 1) высококвалифицированный программист;
2) эксперт по языку программирования;

Оценка посредством просмотра

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

Проектирование теста

Если ввести ограничения на время, стоимость, машинное время и т.п., то ключевым вопросом тестирования становится следующий:
Какое подмножество всех возможных тестов имеет наивысшую вероятность… Изучение методологий проектирования тестов дает ответ на этот вопрос.

Тестирование путем покрытия логики программы

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

Покрытие операторов

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

Рис. 6.5 — Алгоритм тестируемой программы
Предположим, что на рис. 6.5 представлена небольшая программа, которая должна быть протестирована. Эквивалентная программа, написанная на языке PL/1, имеет вид:
М: PROCEDURE (A,В,Х);
IF ((А>1) & (В=0)) THEN DO;
Х=Х/А;
END;
IF ((A=2) | (Х>1)) THEN DO;
Х=Х+1;
END;
END;

Можно выполнить каждый оператор, записав один-единственный тест, который реализовал бы путь асе. Иными словами, если бы в точке a были установлены значения A = 2, B = 0 и X = 3, каждый оператор выполнялся бы один раз (в действительности X может принимать любое значение).
К сожалению, этот критерий хуже, чем он кажется на первый взгляд. Например, пусть первое решение записано как или, а не как и. При тестировании по данному критерию эта ошибка не будет обнаружена. Пусть второе решение записано в программе как X > 0; эта ошибка также не будет обнаружена. Кроме того, существует путь, в котором Х не изменяется (путь abd). Если здесь ошибка, то и она не будет обнаружена. Таким образом, критерий покрытия операторов является настолько слабым, что его обычно не используют.

Покрытие решений

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

Покрытие условий

DO К=0 ТО 50 WHILE (J+K<QUEST);
или его аналог на языке Си
for(K=0; K<=50 && J+K<QUEST; K++)

Комбинаторное покрытие условий

NOTFOUND = ’1’ В;
/* поиск в таблице */
DO I=1 ТО TABSIZE WHILE (NOTFOUND);

Эквивалентное разбиение

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

Выделение классов эквивалентности

Входные условия
Правильные классы эквивалентности
Неправильные классы эквивалентности

… Рис. 6.7 — Форма таблицы для перечисления классов эквивалентности
Заметим, что различают два типа классов эквивалентности: правильные классы эквивалентности, представляющие правильные…

Построение тестов

1. Назначение каждому классу эквивалентности уникального номера.
2. Проектирование новых тестов, каждый из которых покрывает как можно большее… 3. Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности,…

Анализ граничных значений

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

Применение функциональных диаграмм

Тестирование комбинаций входных условий — непростая задача, поскольку даже при построенном эквивалентном разбиении входных условий число комбинаций… Метод функциональных диаграмм или диаграмм причинно-следственных связей… Функциональная диаграмма представляет собой формальный язык, на который транслируется спецификация, написанная на…

Предположение об ошибке

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

Стратегия

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

Контрольные вопросы

1. Определение процесса тестирования. Определение хорошего теста. Определение хорошего прогона.
2. Тестирование программы как черного и белого ящика.
3. Принципы тестирования.
4. Технологии ручного тестирования. Инспекции исходного текста. Сквозные просмотры. Метод оценки программ посредством просмотра.
5. Принципы проектирования теста.
6. Технологии тестирования по принципу белого ящика. Покрытие операторов. Покрытие решений. Покрытие условий. Покрытие решений/условий. Комбинаторное покрытие условий.
7. Технологии тестирования по принципу черного ящика.
8. Эквивалентное разбиение. Способы формирования классов эквивалентности. Правила создания тестов по классам эквивалентности.
9. Анализ граничных значений.
10. Применение функциональных диаграмм. Способы задания ограничений на вход и выход. Технология построения функциональных диаграмм. Технология построения таблицы решений. Формирование тестов по таблице решений.
11. Предположение об ошибке.
12. Стратегия тестирования.

Технология разработки программ

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

Разбиение задачи на независимые подзадачи

Основным алгоритмом, используемым для решения задач, является алгоритм разбиения на независимые подзадачи. Для того, чтобы решить задачу A, ее первоначально необходимо разбить на независимые подзадачи B, C, D и т.д.
A: procedure;
Задача B;
Задача C;
Задача D;
end A;
Решение подзадач может производиться по любому алгоритму.

Разбиение задачи на одинаковые по сложности части

— проверить первый элемент;
— if заданный элемент не найден, then продолжить поиск среди оставшихся… Таким образом, задача разбивается на две части: проверку первого элемента и поиск среди оставшихся. Ясно, что такие…

Рекурсия и динамическое программирование

Рекурсия

Примером рекурсивного решения является вычисление факториала fact(N) = 1×2×…×N. Пусть неизвестно значение fact(460), если умножить… 1) F(N) = G(N, F(N – 1)) для некоторой известной функции G и
2) F(1) равно некоторому известному значению.

Динамическое программирование

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

Моделирование

Поиск

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

Поиск в списках

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

Деревья поиска

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

Стратегия распределения памяти

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

Сортировка

Обменная сортировка. При этом способе наименьший элемент выдвигается в начало списка, следующий по величине — на вторую позицию и т.д. Для списка N… Алгоритм:
EXCHANGE_SORT procedure(LIST,N);

Алгоритм выбора из конечного состояния

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

A
B
C
…
I
J
K
…
Y
Z
…

Сопрограммы

Рис. 7.4 — Организация сопрограмм
Использование сопрограмм может быть полезной управляющей структурой.

Контрольные вопросы

1. Стандартные методы проектирования.
2. Разбиение задачи на независимые подзадачи.
3. Разбиение задачи на одинаковые по сложности части.
4. Рекурсия.
5. Динамическое программирование.
6. Моделирование.
7. Поиск. Поиск в списках. Прямой поиск. Линейный поиск.
8. Поиск с возвратом.
9. Стратегия распределения памяти.
10. Алгоритм выбора из конечного состояния.
11. Сопрограммы.

Методы управления проектированием программных изделий

Основная цель управления — организовать и связать взаимодействие исполнителей при создании программного продукта.

Организация управления проектированием программного изделия

Понятие изделия как средства общения

Изделие
Программа
1. Изучение рынка
1. Изучение рынка
2. Планирование
2. …
То есть самые общие действия при создании изделия имеют аналоги при создании программного продукта, таким образом,…

Нисходящий анализ процесса управления проектированием программного изделия

— планирование;
— разработку;
— обслуживание;

Организация взаимодействия

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

Установление целей, средства их достижения

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

Подбор и обучение кадров

Руководство проектами надо поручать лишь тем специалистам, которые обладают подобным опытом. Здесь очень хорошо работает концепция бригады главного… Но ведь люди где-то должны начинать работать? Так как в настоящее время… С наибольшей вероятностью квалифицированный персонал можно найти среди поставщиков универсального программного…

Организация планирования разработок программного изделия

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

Виды планов

Рис. 8.2 — Иерархия планов

Декомпозиция планов

— план создания семейства программных изделий;
— план создания серии;
— план создания совокупности изделий;

Организационная структура группы планирования

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

Планы, связанные с созданием программных изделий

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

Опытный образец изделия

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

Организация планирования в фазе исследования

Рис. 8.5 — Жизненный цикл программного изделия
Деятельность группы планирования наиболее активна в фазе до начала анализа осуществимости, как только подтверждается…

Организация планирования в стадии анализа осуществимости

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

Организация планирования в фазах конструирования и кодирования

Организация планирования в фазах оценки и использования

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

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

Сначала определяются фазы и основные события в конце каждой из них. Затем проводится формальный обзор на основе, по крайней мере, одного документа… Таблица 8.2 — Документы обзоров

… IV. Программирование

Организация разработки программного изделия

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

Организация разработки программного изделия в фазе исследований

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

Организация разработки программного изделия в фазе анализа осуществимости

Полученные в ходе фазового обзора II предложения относительно внесения изменений в соглашение о требованиях дают возможность оценить недостатки…
Рис. 8.7 — Границы изменяемости проекта:

Организация разработки программного изделия в фазе конструирования (проектирования)

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

Организация разработки программного изделия в фазе программирования

Кодирование начинается на ранней стадии программирования. При этом используется так называемый «волновой эффект» (табл. 8.3), когда составление… Таблица 8.3 — Волновой эффект в разработке модулей изделия

…

Организация разработки программного изделия в фазе оценки

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

Окончание проекта

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

Участие группы разработки в фазовых обзорах

В фазовом обзоре II в центре внимания находится соглашение о требованиях.
Таблица 8.4 — Участие группы разработки в фазовых обзорах
Фаза
…

Организация обслуживания разработки программного изделия

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

Организационная структура группы обслуживания

Основной ошибкой в деятельности группы обслуживания является «локальная оптимизация» при потере целей глобальной оптимизации (одна ЭВМ вместо двух…

Организация обслуживания программного изделия в фазе исследования

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

Организация обслуживания в фазах анализа осуществимости и конструирования

Группа обслуживания обычно имеет в своем распоряжении вычислительный центр или исследовательскую лабораторию, располагающую соответственным… Соглашение о требованиях определяет характер испытаний класса C и необходимую… К этому времени следует принять решение относительно защиты прав собственности на программное изделие. Оно может быть…

Организация обслуживания в фазе программирования и оценки

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

Организация обслуживания в фазе использования

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

Участие группы обслуживания в фазовых обзорах

Таблица 8.5 — Участие группы обслуживания в фазовых обзорах
Фаза
Фазовый обзор
Форма участия при обсуждении документов
…
В фазовом обзоре II группа обслуживания ведет переговоры о приобретении оборудования и других материалов для…

Организация выпуска документации

Рекламные материалы предназначены преимущественно для административного персонала, в то время как справочные материалы используются операторами,…

Организационная структура группы выпуска документации

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

Стандарты и практические руководства

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

Организация выпуска документации в фазах исследований и анализа осуществимости

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

Организация выпуска документации в фазах конструирования и программирования

В фазе конструирования группа разработки передает внешние спецификации на рассмотрение другим группам. Группа выпуска документации убеждается в том,… Если для программного продукта предусмотрен выпуск справочного материала в… Максимальная нагрузка группы выпуска документации наступает в фазе программирования. Группа изучает план группы…

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

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

Участие группы выпуска документации в фазовых обзорах

В ходе фазового обзора II группа пересматривает свои исходные позиции в отношении соглашения о требованиях, руководствуясь окончательным бюджетом, и… Таблица 8.6 — Участие группы выпуска документации в фазовых обзорах
… До фазового обзора III группа участвует в работе над внешней спецификацией. Ко времени фазового обзора III она должна…

Организация испытаний программных изделий

Современное состояние методов обеспечения качества программного изделия

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

Виды испытаний программного изделия. Стадии испытаний

К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирования после того, как будут отлажены и включены в систему… Ко второй стадии относятся испытания класса B, когда осуществляется… Испытания класса C осуществляются после того, как группа испытаний рекомендует выпуск изделия и его распространение.…

Режимы испытаний программ

Режим I подразумевает полный цикл деятельности группы испытаний, включая планирование испытаний, разработку тестов, их прогон и анализ результатов.… Режим II позволяет проводить ускоренные испытания изделия, поскольку в этом… Режим III реализуется без участия группы испытаний. Этот режим используется лишь в случаях крайней необходимости,…

Категории испытания программного изделия

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

Организационная структура группы испытаний

Организуя испытания программного изделия, необходимо иметь четкий ответ на вопрос: «где кончается процесс оценки и начинается процесс отладки…
Рис. 8.9 — Организация взаимосвязи при проведении испытаний

Организация испытаний в фазах исследований и анализа осуществимости

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

Организация испытаний в фазах конструирования и программирования

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

Организация испытаний в фазе оценки

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

Организация испытаний в фазе использования

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

Участие группы испытаний в фазовых обзорах

Таблица 8.8 — Участие группы выпуска документации в фазовых обзорах
Фаза
Фазовый обзор
Форма участия при обсуждении…
В фазовом обзоре I группа испытаний дает предварительную оценку ресурсам, необходимым для обеспечения ее деятельности,…

Контрольные вопросы

1. Понятие изделия как средства общения.
2. Нисходящий анализ процесса управления созданием программного изделия.
3. Установление целей и средства их достижения.
4. Подбор и обучение кадров.
5. Организация планирования разработки программного изделия. Виды планов. Декомпозиция планов.
6. Организационная структура группы планирования.
7. Виды планов, связанных с созданием программного изделия.
8. Организация планирования разработки программного изделия.
9. Вопросы, рассматриваемые в фазовых обзорах группой планирования.
10. Управление проектом.
11. Организация работы группы разработки в фазах создания программного изделия.
12. Организация работы группы обслуживания в фазах создания программного изделия.
13. Организация работы группы выпуска документации в фазах создания программного изделия.
14. Организация испытаний программного изделия.

Список литературы

1. Зельковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения. — М.: Мир, 1982. — 368 с.
2. Гантер Р. Методы управления проектированием программного обеспечения. — М.: Мир, 1981. — 388 с.
3. Вольховер В.Т., Иванов Л.А. Производственные методы разработки программ. — М.: Финансы и статистика, 1983. — 236 с.
4. Гласс Р. Руководство по надежному программированию. — М.: Финансы и статистика, 1983. — 176 с.

Источник

Дефекты. Ошибки, сбои, отказы

Ожидаемый результат — поведение системы, описанное в требованиях.

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

Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями:

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

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

Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

В некоторых средствах одного из состояний нет (оно поглощается другим)

«Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
«Дубликат» — данный дефект уже описан в другом отчёте.
«Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
«Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
«Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».

Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

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

— быть достаточно коротким, чтобы полностью помещаться на экране;

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

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

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

иного) языка, построенным по соответствующим правилам

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
Сформулировать подробное описание
3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

его, сократив длину (за счёт подбора синонимов, использования

общепринятых аббревиатур и сокращений). К слову, в английском языке

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

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

Пример подробного описания :

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

Пример шагов воспроизведения :

Открыть http://testapplication/admin/login/.
Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

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

Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).

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

— Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

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

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

— Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

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

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

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

В качестве примера рассмотрим следующие значения симптомов дефекта.

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

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

Часто у одного дефекта может быть сразу несколько симптомов.

Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

Источник

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

Типология угроз

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

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

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

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

Стихийные бедствия и аварии – угрозы природного происхождения

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

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

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

Сбои и отказы технических средств

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

Сбои и отказы могут происходить:

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

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

Программные ошибки

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

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

Программные ошибки делятся на группы:

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

Возникновение таких ошибок, приводящих к утрате информации, часто связано с использованием нового программного обеспечения, не прошедшего апробацию на практике и не сертифицированного ФСТЭК РФ.

Ошибки пользователей и системных администраторов – угрозы субъективного характера

Это наиболее распространенный тип угроз информационной безопасности. Такие ошибки возникают более чем в 50% случаев.

Причины появления угроз сохранности информации:

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

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

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

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

Среди мер реагирования:

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

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

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

11.06.2020

Вопросы:

1. Непреднамеренные угрозы безопасности информации

2. Преднамеренные угрозы безопасности информации

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

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

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

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

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

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

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

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

Непреднамеренные
угрозы

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

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

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

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

Ошибки в комплексах
алгоритмов и программ обычно классифицируют
на:

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

Вероятность данных
ошибок изменяется на этапах жизненного
цикла АС

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

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

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

Преднамеренные
угрозы

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

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

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

К таким методам
относятся:

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

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

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

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

1) воздушные

2) вибрационные

3) электроакустические

4)
оптико-электронные

В
воздушных технических каналах утечки
информации средой распространения
акустических сигналов является воздух,
и для их перехвата используются
миниатюрные высокочувствительные
микрофоны и специальные направленные
микрофоны. Автономные устройства,
конструктивно объединяющие миниатюрные
микрофоны и передатчики, называют
закладными устройствами перехвата
речевой информации, или просто
акустическими закладками. Закладные
устройства делятся на проводные и
излучающие.
Проводные закладные устройства требуют
значительного времени на установку и
имеют существенный демаскирующий
признак — провода. Излучающие «закладки»
(«радиозакладки») быстро устанавливаются,
но также имеют демаскирующий признак
— излучение в радио или оптическом
диапазоне. «Радиозакладки» могут
использовать в качестве источника
электрические сигналы или акустические
сигналы. Примером
использования электрических сигналов
в качестве источника является применение
сигналов внутренней телефонной,
громкоговорящей связи. Наибольшее
распространение получили акустические
«радиозакладки». Они воспринимают
акустический сигнал, преобразуют его
в электрический и передают в виде
радиосигнала на определенные расстояния.
Из применяемых на практике «радиозакладок»
подавляющее большинство рассчитаны на
работу в диапазоне расстояний 50—800
метров.

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

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

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

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

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

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

В
зависимости от вида каналов связи
технические каналы перехвата информации
можно разделить на:

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

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

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

Корпоративная безопасность: 5 базовых угроз

Характеристики угроз

Источники агрессии могут быть внешними или внутренними. При выявлении угроз следует руководствоваться следующими признаками (сигналами):

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

После выявления угрозы наступает этап разработки мер по локализации или ее минимизации.

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

Причины возникновения внешних и внутренних угроз

Рассмотрим 17 распространенных причин возникновения внешних и внутренних угроз для компании. В реальности их гораздо больше.

Причины возникновения внешних угроз

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

Причины возникновения внутренних угроз

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

Классификация сотрудников

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

Пониженный риск

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

Допустимый риск

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

Высокий риск

Опасные преступники. Они будут создавать условия для хищения даже при жестких мерах контроля в компании. Их также 10%.

Базовые угрозы

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

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

Степень вероятности

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

Природа возникновения

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

Степени развития и этапы борьбы с угрозой

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

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

Система защиты от угроз

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

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

Управление безопасностью равно управлению рисками. Анализ рисков включает классификацию ресурсов (что надо защищать), анализ угроз (от чего надо защищать), анализ уязвимостей (как надо защищать). При этом формула риска такова:

Риск = возможный ущерб * вероятность реализации угрозы

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

Как обосновать бюджет на безопасность

Управлять проблемами предприятия поможет риск-менеджмент. Служба безопасности должна анализировать и рассчитывать риски, выстраивая всю систему работы на основе данных. Чтобы обосновать бюджет службы, директор по безопасности должен уметь оценивать риски и составлять карты рисков, в которых планируются мероприятия по их минимизации, а также закладываются средства на борьбу с ними.

Статья подготовлена на основе лекции Сергея Барбашева, преподавателя РШУ, эксперта по корпоративной безопасности.

Развивайтесь вместе с нами: в каталоге Русской Школы Управления более 700 онлайн-трансляций и 500 дистанционных курсов. Учитесь в удобном формате в любое время и в любом месте!

Любое использование материалов медиапортала РШУ возможно только с разрешения

редакции.

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

поделиться знаниями или
запомнить страничку

Все категории
экономические
43,606
гуманитарные
33,643
юридические
17,916
школьный раздел
611,332
разное
16,894

Популярное на сайте:

Как быстро выучить стихотворение наизусть? Запоминание стихов является стандартным заданием во многих школах.

Как научится читать по диагонали? Скорость чтения зависит от скорости восприятия каждого отдельного слова в тексте.

Как быстро и эффективно исправить почерк? Люди часто предполагают, что каллиграфия и почерк являются синонимами, но это не так.

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

Источник

3.6.1
ñáîé(fault):
Ненормальный режим, который может
вызвать уменьшение или потерю способности
функционального блока выполнять
требуемую функцию.

Примечание
— МЭС 191-05-01 определяет «сбой» как
состояние, характеризуемое неспособностью
выполнить необходимую функцию, исключая
неспособности, возникающие во время
профилактического ухода или других
плановых мероприятий, либо в результате
недостатка внешних ресурсов. Иллюстрация
к этим двум точкам зрения показана на
рисунке 4 [ИСО/МЭК 2382-14-01-10].

(L
— уровень;
1,
2, 3, …; FU — функциональный блок)

а)
конфигурация функционального блока

b)
обобщенный вид

с)
с точки зрения МЭК 61508 и ИСО/МЭК 2382-14

d)
с точки зрения МЭК 60050 (191)

Примечания

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

2
В этой причинно-следственной цепочке
один и тот же элемент («объект
«)
может рассматриваться как состояниефункционального
блока уровня,
в которое он попадает в результате
отказа, а также как причина отказа
функционального блока уровня1.
Данный «объект»
объединяет концепцию «отказа» в
МЭК 61508 и ИСО/МЭК 2382-14, в которой внимание
акцентируется на причинном аспекте,
как показано на рисунке 4с), и концепцию
«отказа» из МЭС 60050 (191), в которой
основное внимание уделено аспекту
состояния, как показано на рисунке 4d).
В МЭС 60050 (191) состояниеназывается
отказом, а в МЭК 61508 и ИСО/МЭК 2382-14 оно не
определено.

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

Рисунок
4 — Модель отказа

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

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

Примечание
— Определение, приведенное в МЭС 191-15-05,
относится только к отказам подкомпонентов.
См. примечание к 3.6.1 [ИСО/МЭК 2382-14-04-06].

3.6.4
отказ(failure):
Прекращение способности функционального
блока выполнять необходимую функцию.

Примечания

1
Определение в МЭС 191-04-01 является
идентичным, с дополнительными комментариями
[ИСО/МЭК 2382-14-01-11].

2
Соотношение между сбоями и отказами в
МЭК 61508 и МЭС 60050 (191) см. на рисунке 4.

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

4
Отказы являются либо случайными (в
аппаратуре), либо систематическими (в
аппаратуре или в программном обеспечении),
см. 3.6.5 и 3.6.6.

3.6.5
случайный
отказ аппаратуры(random
hardware failure): Отказ, возникающий в случайный
момент времени, который является
результатом одного или нескольких
возможных механизмов ухудшения
характеристик аппаратных средств.

Примечания

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

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

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

Примечания

1
Корректирующее сопровождение без
модификации обычно не устраняет причину
отказа.

2
Систематический отказ может быть
воспроизведен имитацией причины отказа
[МЭС 191-04-19].

3
Примерами причин систематических
отказов являются ошибки человека:

—
в спецификации требований к безопасности;

—
при проектировании, изготовлении,
установке или эксплуатации аппаратных
средств;

—
при проектировании, реализации и т.п.
программного обеспечения.

4
В настоящем стандарте отказы в системах,
связанных с безопасностью, разделяются
на случайные отказы аппаратуры и
систематические отказы (см. 3.6.4 и 3.6.5).

3.6.7
опасный
отказ(dangerous
failure): Отказ, который может привести к
тому, что система, связанная с безопасностью,
перейдет в опасное состояние или в
состояние ошибки при выполнении функции.

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

3.6.8
безопасный
отказ(safe
failure): Отказ, который не переводит систему,
связанную с безопасностью, в опасное
состояние или в состояние отказа при
выполнении функции.

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

3.6.9
зависимый
отказ(dependent
failure): Отказ, вероятность которого не
может быть выражена в виде простого
произведения безусловных вероятностей
отдельных событий, являющихся причиной
отказа.

Примечание
— Пусть P(z) вероятность события z. Два
события А и В будут зависимы только
тогда, когда Р(А+В)>Р(А)хР(В).

3.6.10
отказ
с общей причиной(common
cause failure): Отказ, который является
результатом одного или нескольких
событий, вызвавших одновременные отказы
двух и более отдельных каналов в
многоканальной системе, ведущие к отказу
системы.

3.6.11
ошибка(error):
Расхождение между вычисленным, наблюденным
или измеренным значением или условием
и истинным, специфицированным или
теоретически правильным значением или
условием.

Примечание
— Адаптировано из МЭС 191-05-24 путем
исключения примечаний.

3.6.12
ошибка
человека(human
error, mistake): Действие или бездействие
человека, которое может привести к
непредусмотренному результату [ИСО/МЭК
2382-14-01-09].

Примечание
— Адаптировано из МЭС 191-05-25 путем
добавления слов «или бездействие».

Соседние файлы в папке Архив WinRAR

Источник

Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!

В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника ISTQB, но предпочел рассказать историю. Три года прошло! Я помню историю до сих пор и могу назвать отличия без подглядывания в гугл

Вступление от Алексея — придумал историю не сам. На одном из тренингов я задал этот вопрос. Девочки посовещались между собой и сказали: «Мы не можем объяснить это с точки зрения ПО, но можем на примере шитья». Я удивился и сказал: «Давайте!».

Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья.

Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.

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

Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! Произошелсбой в системе — проявился ранее скрытый дефект.

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

Официальное определение

А под конец немножко официоза — версия из ISTQB:

A human being can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it souldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

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

Источник