Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

QA Theory (Rus) > Theory > Flashcards

Theory Flashcards

Learn qa theory

1
Q

Тестирование ПО

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Качество программного обеспечения

A

Это степень, в которой ПО обладает требуемой комбинацией свойств.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Разница Quality Assurance и Quality Control

A
  • QA – это проактивный процесс, направленный на предотвращение возможных дефектов. Он выполняется во время разработки продукта. Основное внимание уделяется предотвращению появления дефектов в процессе разработки продукта.
  • QC – это реактивный процесс, целью которого является подтверждение качества конкретного продукта посредством тестирования, выявления и устранения неисправностей. Он проводится после того, как продукт был разработан. Основное внимание уделяется тестированию готового продукта, выявлению и устранению дефектов.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Модели разработки ПО

A

Водопадная
V-образная
Итерационная инкрементальная
Гибкая модель (Agile)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Жизненный цикл разработки ПО

A
  1. Идея
  2. Сбор и анализ требований
  3. Проектирование. Дизайн и архитектура
  4. Разработка
  5. Тестирование
  6. Внедрение и сопровождение
  7. Вывод из эксплуатации
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Жизненный цикл тестирования

A
  1. Анализ требований
  2. Уточнение критериев приемки
  3. Уточнение стратегии тестирования
  4. Разработка тест-кейсов
  5. Выполнение тест-кейсов
  6. Фиксация найденных багов
  7. Отчет с результатами тестирования
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Тест план

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Разделы тест-плана

A
  1. Цель (purpose)
  2. Области, подвергаемые тестированию (features to be tested)
  3. Области, не подвергаемые тестированию (features not to be tested)
  4. Тестовая стратегия (test strategy) и подходы (test approach)
  5. Критерии (criteria)
  6. Приемочные критерии, критерии качества (acceptance criteria)
    a. Критерии начала тестирования (entry criteria)
    b. Критерии приостановки тестирования (suspension criteria)
    c. Критерии возобновления тестирования (resumption criteria)
    d. Критерии завершения тестирования (exit criteria)
  7. Ресурсы (resources) (необходимое ПО, аппаратные ресурсы, человеческие ресурсы, временные ресурсы, финансовые ресурсы)
  8. Расписание (test schedule)
  9. Роли и ответственность (roles and responsibility)
  10. Оценка рисков (risk evaluation)
  11. Документация (documentation)
  12. Метрики (metrics)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

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

A
  • Тест-план
  • Чек-лист
  • Тест кейс
  • Тест репорт
  • Requirement Traceability Matrix
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Требование

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Свойства качественных требований

A
  • Завершённость (completeness)
  • Корректность (correctness)
  • Непротиворечивость (consistency)
  • Недвусмысленность (ambiguousness)
  • Проверяемость (verifiability)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Как анализировать требования?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Чек-лист

A

Список, содержащий ряд необходимых проверок во время тестирования программного продукта

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Тест-кейс

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

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

A
  1. Тестирование показывает наличие дефектов.
  2. Исчерпывающее тестирование невозможно.
  3. Раннее тестирование.
  4. Скопление дефектов.
  5. Парадокс пестицида.
  6. Тестирование зависит от контекста.
  7. Заблуждение об отсутствии ошибок.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Верификация и Валидация

A

Процесс верификации. Это статическая практика проверки документов, дизайна, архитектуры, кода и так далее. Это значит, что
процесс верификации проходит без запуска кода. Верификация всегда отвечает на вопрос “делаем ли мы
продукт правильно?”. Эта проверка связана с тем, что мы убеждаемся в том, что система хорошо
спроектирована и безошибочно. Верификация всегда происходит ДО валидации.
Процесс валидации - это процесс оценки конечного продукта, когда необходимо проверить:
соответствует ли программное обеспечение ожиданиям и требованиям клиента. Это динамический процесс, в
отличии от верификации. Этот процесс всегда включает в себя запуск кода программы и отвечает на вопрос
“делаем ли мы правильный продукт?”. Процесс валидации всегда происходит ПОСЛЕ верификации, поэтому на
этапе валидации можно уловить ошибки, которые процесс верификации не позволил нам найти.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Классификация тестирования по уровням

A
  • Unit тестирование (компонентное, модульное)
  • Интеграционное тестирование
  • Системное тестирование
  • Приёмочное тестирование
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Разновидности интеграционного тестирования

A
  1. Тестирование интеграции компонентов, т.е. как отдельные модули одного приложения
    взаимодействуют между собой.
  2. Системное интеграционное тестирование, под которым понимают тестирование
    взаимодействия между всеми компонентами системы, либо взаимодействия разных систем
    между собой, либо тестирование интерфейсов с помощью которых взаимодействуют системы.
    Именно об интерфейсах я хочу поговорить более подробно. Существует три вида интерфейсов:
    ● Интерфейс программирования приложений, либо API. Этот набор методов можно
    использовать для доступа к функциональности другой программы. Например, API используется
    для того, чтобы наладить какую-то платежную систему для того или иного ресурса. Например,
    интернет-магазин, для него разработчик налаживает интеграцию с системой посредством
    данного интерфейса. Ему не нужно разрабатывать свою платежную систему, таких систем
    существует огромное количество. Самые известные из них это API взаимодействия с
    социальными сетями той же в Facebook или ВКонтакте.

● CLI (command line interface), интерфейс командной строки, там, где инструкция компьютеру
даётся путем ввода с клавиатуры текстовых строк, по-простому - это обычная командная строка
в системе Windows.
● GUI (graphical User Interface). В нём программные функции предоставляются графическими
элементами экрана. Например, это то, что мы видим в окне браузера, когда открываем страницу
в интернете.

19
Q

Альфа-тестирование / Бета-тестирование

A

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

20
Q

Классификация тестирования по позитивности

A

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

21
Q

Классификация тестирования по степени важности тестируемых функций

A

Smoke testing (дымное, дымовое) тестирование направлено на проверку готовности разработанного продукта к
проведению расширенного тестирования и определение общего состояния качества продукта.
Тест критического пути (critical path test) - основной тип тестовых испытаний, во время которого
значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном использовании.
Расширенный тест (extended test) - проверка
нестандартного использования программного продукта.

22
Q

Классификация тестирования по цели тестирования

A

New feature test (тестирование новой функциональности) - это проверка качества новой
функциональности, поставленной на тестирование.
Регрессионное тестирование (Regression testing) - это тестирование ранее проверенной функциональности, с целью удостовериться, что
изменения в коде, например добавление новой функциональности, либо же исправления какого-либо дефекта,
не повлияли на работу старой функциональности.
Re-test - это проверка результата работы над дефектом, проверка правильности исправления дефекта.

23
Q

Классификация тестирования по степени автоматизации

A

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

24
Q

Классификация тестирования по знанию кода

A

Тестирование черного ящика (black box)
White box testing (тестирование белого ящика)
Gray box test (серый ящик)

25
Q

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

A

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

26
Q

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

A
  1. Тестирование на отказ и восстановление
  2. Тестирование производительности.
  3. Тестирование удобства использования
  4. Тестирование безопасности
  5. Тестирование установки
  6. Конфигурационное тестирование
  7. Тестирование локализации (l10n)
  8. Тестирование интернационализации (i18n)
  9. Тестирование GUI (графического интерфейса)
27
Q

Виды тестирования производительности

A
  1. Нагрузочное
  2. Стресс-тестирование
  3. Стабильности
  4. Объемное тестирование
28
Q

Виды конфигурационного тестирования

A
  1. Кроссплатформенное - значит, что мы тестируем наш продукта на различных типах и версиях
    оперативных систем. Например, мобилки – android, либо ios.
  2. Кроссбраузерное тестирование - мы используем наше приложение на различных браузерах. Chrome, Mozilla, Opera.
29
Q

Классификация тестирования по исполнению сценария

A

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

30
Q

Классификация тестирования по запуску кода

A

Статическое

Динамическое

31
Q

Что должно быть в хорошем чек-листе?

A

● Версия нашей сборки (Build, билд). Окружение (Environment, инвайранмент), на котором проводилось тестирование.
● Дата проведения нашего теста.
● Тестировщик, который проводил данное тестирование.
● Тип тестов, который был использован для тех или иных проверок.
● Название самих проверок.
● Результат нашего тестирования, т.е. прошла эта проверка или нет.

32
Q

Тест-suite

A

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

33
Q

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

A 
● Идентификатор
● Приоритет
● Ссылка на требования с которыми связан наш тест-кейс
● Название модуля
● Заглавие, в котором будет отражаться основная суть нашего тест-кейса
● Шаги по воспроизведению тест-кейса
● Ожидаемый результат
● Фактический результат
● Дефект
34
Q

Test design

A

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

35
Q

Класс эквивалентности и правила эквивалентного разбиения

A

Это входные данные, которые обрабатываются приложением: одинаково, либо же обработка которых приводит к одному и тому же результату.
Правила эквивалентного разбиения:
● первое правило - это определение классов эквивалентности;
● второе правило - проведение хотя бы одного теста для одного класса.

36
Q

Правила анализа граничных значений

A

Первое правило - определение классов эквивалентности.
Второе правило - определение границ этих диапазонов.
Третье правило - проведение трёх тестов: для границ на самой границе, на значение выше этой
границы и на значение меньше этой границы.

37
Q

Что такое баг (дефект)?

A

Дефект (баг) - это несоответствие фактического результата выполнения программы ожидаемому
результату.

38
Q

Атрибуты баг-репорта

A
  • Описание
  • Шаги по воспроизведению
  • Компонент, в котором непосредственно был обнаружен данный дефект.
  • Версия билда
  • Серьезность (severity)
  • Приоритет (priority)
  • Статус
  • Автор
  • Назначение
  • Окружение
  • Прикрепленные файлы
39
Q

Классификация Severity

A

● Blocker - такой тип ошибки, который приводит нашу программу в нерабочее состояние. Если мы
обнаруживаем такой дефект, то дальнейшие работы с программой или её функциями попросту невозможны.
● Critical - это критические дефекты. Они приводят наш ключевой функционал в нерабочее состояние. Также это могут быть существенные отклонения от бизнес-логики нашего приложения, либо же какая-то неправильная реализация требуемых функций. Возможна потеря пользовательских данных, в отличие от blocker, наше приложение не приходит в абсолютно нерабочее состояние, и в принципе другие функции могут работать
нормально, поэтому есть такая градация, как critical.
● Major (мажорные) - это какие-то серьёзные ошибки, которые свидетельствуют об отклонении от бизнес логики или нарушающие работу программы, но в то же время они не имеют физическое воздействие на наше приложение, возможно есть некоторый обходной путь, либо его еще могут называть workaround.
● Minor (минорные) - это какой-то незначительный дефект, не нарушающий функционал нашего
приложения, но который является несоответствием ожидаемого результата. Например, это может быть ошибка нашего дизайна.
● Trivial - какие-то тривиальные баги, которые
не имеют влияния на функционал или работу нашей программы, но который может быть обнаружен визуально.

40
Q

Классификация Priority

A

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

41
Q

Виды окружения

A

● DEV окружение - обычно работают разработчики, т.е. они туда заливают какие-то фичи, возможно также подключаются тестировщики к тестированию каких-то отдельных фич на DEV окружении, и также могут заводить дефекты. Если мы обнаруживаем такие дефекты на этом окружении, мы прописываем в этом
поле DEV.
● STAGE окружение - на него попадает уже какая-то стабильная версия нашего приложения, на нем чаще всего работают тестировщики и именно на stage доводят это приложение до определенного
предрелизного состояния.
● PROD окружение - если на stage не остаётся дефектов, то такое приложение переводится на стадию прод, где у нас работают наши конечные пользователи.

42
Q

Правил названия бага

A

В заголовке ответить на три вопроса: ГДЕ? ЧТО?
КОГДА?
Где? - это может быть название вашего модуля, в котором вы обнаружили ваш баг.
Что? - это непосредственно что происходит, когда вы обнаруживаете ваш баг, т.е. то, к чему привёл дефект.
Когда? - при каких условиях это происходит.
Например: «login page: The button ‘Sign In’ is displaced after clicking on the page»

43
Q

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

A
  • Обнаружен (submitted) (иногда называется «Новый» (new))
  • Назначен (assigned)
  • Исправлен (fixed)
  • Проверен (verified)
  • Закрыт (closed)
  • Открыт заново (reopened)
  • Рекомендован к отклонению (to be declined)
  • Отклонён (declined)
  • Отложен (deferred)
44
Q

&

A

Амперсанд / Ampersand

QA Theory (Rus) (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions