Сбой системы выброс ошибка испытания верификация системы - Исправление ошибок и поиск оптимальных решений проблем

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.

Источник

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

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

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

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

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

Ошибка (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 не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

Источник

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

Время прочтения
15 мин

Просмотры 624K

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

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

Тестирование программного обеспечения (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. Есть варианты как для продвинутых, так и для начинающих пользователей.

Источник

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

В фундаментальную концепцию проектирования ПС входят базовые положения, стратегии, методы, которые применяются на процессах ЖЦ и обеспечивают тестирование (верификацию) на множестве тестовых наборов данных. К методам проектирования ПС относятся структурные, объектно-ориентированные и др. Их основу составляют теоретические, инструментальные и прикладные средства, которые влияют на процесс тестирования.

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см.
«Формальные спецификации,
доказательство и верификация программ»
), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО. Например, концепция » чистая комната » базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

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

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО. В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в
«Формальные спецификации,
доказательство и верификация программ»
, здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

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

7.1. Процессы ЖЦ верификация и валидация программ

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

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

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

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

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

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

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

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

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

На других процессах ЖЦ выполняются дополнительные действия:

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

Таким образом, основные задачи процессов верификации и валидации состоят в том, чтобы проверить и подтвердить, что конечный программный продукт отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы взаимосвязаны и определяются, как правило, одним общим термином «верификация и валидация» или «Verification and Validation» (V&V) [7.7].

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

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

7.2. Тестирование программ

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

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

Исторически первым видом тестирования была отладка.

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

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

7.2.1. Статические методы тестирования

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

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

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

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

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

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

7.2.2. Динамические методы тестирования

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

Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных показателей (число отказов, сбоев) тестирования для оценки характеристик качества, указанных в требованиях, посредством выполнения системы на ЭВМ. Тестирование основывается на систематических, статистических, (вероятностных) и имитационных методах.

Дадим краткую их характеристику.

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

Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы «черного ящика» обеспечивают:

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

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

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

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

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

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

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

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования.

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

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

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

Источник

Тестирование — это не точная наука. Тут нет чётких устоявшихся определений, которые можно собрать в словарь и выучить перед собеседованием. Каждый 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, тестирование черного ящика — это:
– тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
– тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.

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

Тест план (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).

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

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

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

Резюме

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

Источник

What is a Bug?

Reasons Why Bugs Occur?

Life Cycle of a Bug in Software Testing

Bug Report

Bug Tracking Tools

What is a Bug?

Reasons Why Bugs Occur?

Life Cycle of a Bug in Software Testing

Bug Report

Bug Tracking Tools

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

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

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

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

Требования

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

Severity vs Priority

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

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

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

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

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

Резюме

Определение

Цели

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

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

О качестве

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

Этапы

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

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

Виды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тесты сборок

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

Иные виды

О типах

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

7.1. Процессы ЖЦ верификация и валидация программ

7.2. Тестирование программ

7.2.1. Статические методы тестирования

7.2.2. Динамические методы тестирования

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

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

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

Требования

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

Severity vs Priority

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

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

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

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

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

Резюме

Читайте также: