- •1)Объектно-ориентированный подход к разработке программного обеспечения: основные понятия, концепции и принципы.
- •3) Понятие нормальных форм в отношении. Особенности приведения отношений к 1nf, 2nf, 3nf.
- •2Нф (Вторая Нормальная Форма)
- •3Нф (Третья Нормальная Форма)
- •4)Надежность программного обеспечения.
- •3)Основные этапы проектирования баз данных.
- •4)Основные показатели надёжности программного обеспечения
- •2) История развития операционной системы Windows. Введение в операционную систему Windows. Особенности и различия версий операционной системы Windows. Архитектура операционной системы Windows nt
- •Специальные реляционные операторы
- •3) Операции над данными (включить, удалить, обновить, объединение, пересечение, вычитание, декартово произведение, выборка, проекция, соединение, деление).
- •Операции над множествами
- •4)Категории тестируемых требований к программному обеспечению.
- •2) Модели данных (сетевая, иерархическая, реляционная).
- •3) Критерии, используемые при тестировании требований.
- •Ненумерованные списки
- •Нумерованные списки
- •Раскрывающейся список
- •Переход внутри одного документа
- •Переход к другому документу или ссылки
- •2)Селекторы css: класса, id, тега. Способы подключения таблиц стилей.
- •Селекторк лассов
- •Селектор id
- •3)Уровни абстракции в субд.
- •4)Содержание плана тестирования.
- •2)Сервлеты. Жизненный цикл сервлета. Класс HttpServlet. Интерфейсы HttpServletRequest, HttpServletResponse.
- •Интерфейс Servlet и жизненный цикл сервлета
- •Класс HttpServlet
- •3)Субд в многопользовательских системах. Архитектура многопользовательских субд (с телеобработкой, файл-серверные, клиент-серверные).
- •2)Сервлеты. Обработка http-запросов get и post.
- •3)Основные функции субд. Типовая организация субд. Основные компоненты типичной субд.
- •4)Основные этапы проведения системных испытаний.
- •1)Библиотека stl: назначение, основные элементы.
- •2)Субд. Классификация субд. Технология использования субд
- •3)Стратегии «белого» ящика. Покрытие операторов. Покрытие решений.
- •4)Jsp. Архитектура jsp-страницы. Жизненный цикл jsp.
- •1)Диаграммы idef0: элементы, правила построения, демонстрационный пример.
- •2)Стили. Общий синтаксис. Назначение, возможности. Каскадность css.
- •3)Понятия базы данных, банка данных. Классификация баз данных.
- •4)Стратегии «белого» ящика. Покрытие условий. Покрытие решений/условий.
- •1)Диаграммы idef0: иерархия диаграмм, правила построения, стратегии декомпозиции и критерии завершения декомпозиции.
- •2)Формы в html. Назначение, теги, параметры, примеры.
- •3)Файловые системы и файловые базы данных. Особенности и основные характеристики.
- •5)Стратегии «белого» ящика. Комбинаторное покрытие условий.
- •1) Диаграммы idef1x: назначение, элементы, правила построения.
- •2)Теги таблиц. Назначение, примеры.
- •3)Язык sql (Structured Query Language). Интерактивный и встроенный sql. Составные части sql. Типы данных sql. Основные типы команд sql.
- •4)Тестирование приложения методом «черного» ящика.
- •1)Диаграмма вариантов использования uml 2: назначение, элементы и правила построения.
- •Понятие тега
- •3)Язык sql. Команды манипулирования данными.
- •1)Диаграмма классов uml 2: назначение, классы и их обозначение.
- •3)Архитектуры приложений. Основные различия между архитектурами приложений.
- •1)Диаграмма деятельности uml 2: назначение, действия и деятельности, объекты, дуги деятельности
- •2)Http-протокол. Идеология построения протокола http. Общая структура сообщений, методы доступа. Заголовок и данные http-запросов. Стандартные коды ответов.
- •4)Структуры данных, основанные на хеш-таблицах.
- •1)Создание и использование статических библиотек в операционной системе Windows. Создание и использование динамических библиотек в операционной системе Windows: раннее и позднее связывание.
- •2)Диаграмма развертывания uml 2: назначение, элементы и правила построения.
- •3)Понятие экспертной системы. Назначение и основные свойства экспертных систем, основные области применения и примеры экспертных систем.
- •4)Деревья двоичного поиска. Методы их реализации.
- •1)Логическая организация файловой системы: типы файлов, иерархическая структура файловой системы, имена файлов, адресация файлов.
- •2)Жизненный цикл программного обеспечения. Классическая модель жизненного цикла: основные этапы, принципы организации, преимущества и недостатки
- •3)Архитектура и особенности экспертных систем.
- •4)Алгоритм Хаффмена, структуры данных для его реализации. Пример построения кода.
- •1)Физическая организация файловой системы: диски, разделы, секторы, кластеры, адресация файла.
- •2)Классификация экспертных систем
- •4)Сбалансированные и несбалансированные деревья поиска.
- •1)Иерархия запоминающих устройств. Кэш-память. Способы отображения основной памяти на кэш. Схемы выполнения запросов в системах с кэш-памятью.
- •2)Жизненный цикл программного обеспечения. Эволюционная модель жизненного цикла: основные этапы, принципы организации, преимущества и недостатки.
- •3)Разработка экспертных систем. Этапы разработки экспертной системы. Человеческий фактор при разработке экспертной системы.
- •5)Алгоритмы быстрой сортировки
- •1) Страничное распределение памяти. Сегментное распределение памяти. Сегментно-страничное распределение памяти.
- •2)Диаграмма последовательностей uml 2: назначение, линия жизни и сообщения.
- •3)Модели представления знаний: продукционные модели, семантические сети, фреймы и формальные логические модели.
- •4)Алгоритмы внешней сортировки.
- •1)Понятие операционной системы. Иерархическая и многослойная структуры операционной системы. Многослойная структура ядра операционной системы.
- •2)Диаграмма последовательностей uml 2: назначение, комбинированные фрагменты взаимодействия и их применение.
- •3)Знания и данные. Глубинные и поверхностные знания. Интенсионал и экстенсионал понятия. Классификация моделей представления знаний.
- •4)Документирование результатов тестирования. Важность дефекта. Градации важности дефекта.
4)Документирование результатов тестирования. Важность дефекта. Градации важности дефекта.
Разные системы баг трекинга предлагают разные пути описания важности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый эти поля. Все знают такой баг- трекер, как Atlassian JIRA. В нем, начиная с какой- то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons... Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:
Важность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Градация Важности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказвающая никакого влияния на общее качество продукта.
Требовния к количеству открытых багов
Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества
Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований - это пункт Критерии окончания тестирования в плане тестирования.