23)Тестовый план, разработка тест-кейсов. Понятие дефекта. Жизненный цикл дефекта.

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

Секции тестового плана:

• Перечень работ

• Критерии качества и оценка качества процесса

• Оценка рисков

• Документация и письма

• Тестовая стратегия

• Ресурсы

• Метрики

• Расписание и ключевые точки

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

Жизненный цикл дефекта:

• Обнаружен

• Назначен

• Исправлен

• Проверен

• Открыт заново

• Отклонён

• Отложен

Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонён (declined).

Открытые (open) баги. Открытыми являются баги в состояниях Обнаружен (submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и баги в состояниях Исправлен (fixed) и Отложен (deferred).

----------------------------------------------------------------

12) Модель потоков данных, dfd (Data Flow Diagrams).

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.

---------------------------------------------------------------

24) Характеристики качества по. Анализ требований.

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

Некоторые из факторов качества:

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

• полнота-Все необходимые части программы должны быть представлены и полностью реализованы.

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

• портируемость-Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

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

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

• тестируемость-Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.

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

• надёжность-отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок.

• структурированность

• эффективность-Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

• безопасность

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

Анализ требований включает три типа деятельности:

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

• Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

Типы требований:

• Требования клиентов

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

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

• Требования производительности

• Производные требования