Brainscape's Knowledge GenomeTM

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


See full index

qa > 1 > Flashcards

1 Flashcards

1
Q

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

A

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

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

Тест план.

A

Документ описывающий весь объем работ по тестированию, начиная с описания объекта тестирования, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе тестирования оборудования, спец. Знаний, а также оценки рисков с вариантами их разрешения.
Структура:
1) Введение (что делаем, зачем, для кого)
2) Объем работ (что тестировать, что нет)
3) Критерии качества и приемлемости
4) Критические факторы успеха
5) Оценка рисков
6) Ресурсы
7) Тестовая документация
8) Стратегия тестирования (входные критерии, методы/типы/уровни тестирования)
9) График тестирования

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

Тест кейс

A

Набор хорошо понятных и продуманных шагов, выполняемых для проверки конкретной функции или функциональности ПО.
Структура:
1. Идентификатор
2. Приоритет
3. Ссылка на требования
4. Название модуля
5. Заглавие
6. Предусловия
7. Шаги
8. Ожидаемый результат

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

Чек лист

A

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

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

Когда использовать Чек лист, а когда Тест кейс?

A
  • Зависит от желания заказчика (например, с тест кейсами проект более прозрачен)
    Сложный проект - ТК Легкий – Чек лист
    Длительный – ТК Короткий – Чек лист
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Баг

A

Несоответствие производимого продукта требованиям прямым или косвенным.
Прямые – ТЗ, спецификации, макеты.
Косвенные – неописанное, на основе опыта, конкурентов)

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

Баг репорт. Локализация бага

A

1) Заголовок (что,где,при каких условиях)
2) Предусловия
3) Шаги
4) Ожидаемый результат
5) Фактический результат
6) Входные данные (логин, пароль и т.д.)
7) Серьезность и Приоритет
8) Вложения (скрины, видео, логи)
9) Данные об окружении (версия, сборка)
Локализация бага
1) Минимальные шаги для воспроизведения
2) Вызван бэкэнд или фронтэнд
3) Обширность влияния (одна кнопка или все)
4) Окружение, ОС, браузеры

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

Приоритет (priority)

A

Приоритет – бизнес

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

Серьезность (severity)

A

Серьезность – работоспособность приложения

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

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

A

Этап на котором создаются/проектируются тест сьюты/тест кейсы в соответствии с определенными ранее критериями качества и целями тестирования
1) Разделение на классы эквивалентности
2) Анализ граничных значений
3) Метод попарного тестирования
4) Таблица принятия решений
5) Диаграмма состояний и переходов
6) Диаграмма пользовательских ролей
7) Предугадывание ошибок
8) Исследовательское тестирование

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

Класс эквивалентности

A

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

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

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

A

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

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

Техника визуализации ТЗ. Показывает, как некий объект переходит из одного состояния в другое.

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

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

-Уроки, извлеченные из прошлых релизов
-Интуиция тестировщика
-Предыдущие дефекты
-Производственные проверки
-Контрольный список проверок
-Отчеты о рисках приложения
-Общие правила тестирования

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

Исследовательское тестирование

A

Его нужно применять в ситуациях:

Когда мы не знаем продукт. Мы изучаем его, как обычный пользователь. Например, нам дали новый проект и его нужно изучить: прокликать и узнать, какой там функционал.
Когда нам не нужна или у нас нет документации. Мы используем исследовательское тестирование, когда нет времени писать тест-кейсы или сроки горят, или нам приказали не писать документацию
Когда нет времени. Если дают сайт или программу и говорят (образно), что есть 15 минут, чтоб найти 100 багов и нет времени ни создавать тест-кейсы, ни писать репорты, тебе просто нужно срочно тестировать и проверять качество — это исследовательское тестирование.

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

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

A

-Функциональное
-Нефункциональное
-Связанные с изменениями
-По запуску
-По знанию о системе
-По степени автоматизации
-По времени проведения
-По позитивности
-По исполнению сценария

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

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

A

Главная цель это проверка реализуемости функциональных требований приложения, т.е. возможность приложения решать поставленные на него задачи (безопасность, взаимодействие, и функциональность)
Представлена на всех уровнях тестирования:
- Модульном (Unit)
- Интеграционном
- Системном
- Приемочном (клиент)

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

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

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

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

A

Проверка на соответствие нефункциональным требованиям:
- Удобство
- Масштабируемость
- Производительность (load, stress,recovery,volume)
- Безопасность
- Совместимость
- Надежность
- Юзер интерфейс
- Локализация/интернационализация

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

Тестирование связанное с изменениями

A

1.Smoke (запускается ли) – новый билд
2.Sanity (основная функциональность) – стабильный билд
3.Re-test (исправлен ли баг)
4.Regression (ничего не сломалось после исправления бага, добавления новой функциональности о всем приложении)

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

Виды тестирования по запуску

A
  • Динамическое
  • Статическое (без запуска кода – код ревью)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Виды тестирования по знанию о системе

A
  • Black box (без доступа к коду)
  • White box (с доступом)
  • Gray box (база данных)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Виды тестирования по степени автоматизации

A
  • Ручное
    -Авто
    -Полуавто
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

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

A

-Альфа
-Бета

28
Q

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

A

-Позитивные
-Негативные

29
Q

Виды тестирования по исполнению сценария

A
  • Сценарное (по предварительно написанным тест сценариям)
  • Исследовательское (exploratory) – менее формальное
  • Свободное (Ad-Hoc)
30
Q

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

A

Период времени, который начинается с момента принятия решения о создании ПО и заканчивается в момент полного изъятия ПО из эксплуатации
Обычно включает в себя:
1. Анализ требований
2. Проектирование
3. Кодирование
4. Тестирование и отладка
5. Эксплуатация и сопровождение

31
Q

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

A

1) Водопадная модель

2) V-образная модель

3) Итерационная модель

4) Agile

Scrum (фреймворк)

Kanban (фреймворк)

32
Q

Водопадная модель

A

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

33
Q

V-образная модель

A

Задачи разработки идут сверху вниз по левой стороне буквы V, задачи тестирования по правой.

34
Q

Итерационная модель

A

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

35
Q

Agile

A

Система идей и принципов гибкого управления проектами, на основе которой были разработаны -Kanban, SCRUM и др.
Ключевой принцип -разработка через короткие итерации, в конце каждой из которых заказчик получает готовый код или продукт.
Принципы:
- Люди и взаимодействие важнее процессов и изменений
- Рабочий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее условий согласования контракта
- Готовность к изменения важнее следования первоначальному плану

36
Q

Scrum

A

(фреймворк)
Спринты (1-2 недели)
Команда: product owner, scrum master, команда разработки.
Мероприятия: Daily scrum meeting, планирование спринты, ретроспектива спринта, итоги.

37
Q

Kanban

A

(фреймворк)
Доска: нужно сделать, аналитика, разработка, тестирование, сделано
- Можно следить за тем, как нагружена команда
- Метод управления создания продуктов с целью обеспечения непрерывной доставки (Continuos delivery)

38
Q

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

A
  • Обнаружен
  • Назначен
  • В работе
  • Исправлен
  • Проверен
  • Открыт заново
  • Отклонен
  • Отложен
  • Закрыт
39
Q

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

A
  • Обнаружен
  • Назначен
  • В работе
  • Исправлен
  • Проверен
  • Открыт заново
  • Отклонен
  • Отложен
  • Закрыт
40
Q

Cache

A

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

41
Q

Cookie

A

Небольшие фрагменты данных, отправленные веб сервером и хранимые на устройстве пользователя. При переходе на страницу сайта передаются в составе Http. Применяется для сохранения данных на стороне пользователя.
Используется для:
-Аутентификации
-Хранения настроек, персонализации
-Сбор статистики
-Корзина в инет магазине

42
Q

API (application programming interface)

A

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

43
Q

HTML

A

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

44
Q

CSS

A

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

45
Q

JS

A

Язык, с помощью которого придается интерактивность вэб страницам

46
Q

HTTP

A

Протокол передачи гипертекста. Протокол передачи данных лежащий в основе клиент-серверной архитектуры.

47
Q

HTTPS

A

Безопасный протокол передачи гипертекста. Протокол передачи данных лежащий в основе клиент-серверной архитектуры.
Безопасная передача данных (шифрование SSL/TLS)

48
Q

Методы тестирования вэб приложений (методы запросов)

A

Это типы запроса http указывающие серверу какое действие мы хотим произвести с ресурсом
-GET(r)
-POST(c,u,d)
-PUT(c,u)
-DELETE(d)
CRUD – create, read, update, delete

49
Q

GET

A

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

50
Q

POST

A

CREATE/UPDATE/DELETE
– отправить данные
Служит для добавления информации на ресурс (загрузка картинки, ввод логина/пароля). Данные показываются в теле запроса.

51
Q

PUT

A

CREATE/UPDATE
– изменение данных

52
Q

DELETE

A

DELETE
– удаление данных

53
Q

Коды состояний HTTP

A

1xx – информационные сообщения
100 – continue
2хх – сообщение об успехе операции
200 – ок
201 – created
3хх – сообщение об перенаправлении
301 – документ был перемещен навсегда а новый URL
4хх – ошибки на стороне клиента
400 – запрос составлен неверно
404 – ресурса нет на сервере
5хх – ошибки на стороне сервера
500 – ошибка на стороне сервера
503 – сервер не доступен

54
Q

Отличие GET и POST

A

GET – в URL, POST – в теле запроса
GET – не для конфиденциальных действий
POST – для конфиденциальных
Количество символов в URL ограничено 2048 символов

55
Q

REST

A

Архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Поддерживает различные форматы. Самый распространенный json. Нет строгих правил. Работает по протоколам http/https.

56
Q

SOAP

A

Протокол обмена сообщениями (формат .xml). Может использоваться с любым протоколом http, ftp, ssh и др. Строгие правила (описаны в файле .wsdl)

57
Q

SQL

A

Структурированный язык запросов. Служит для получения из базы данных необходимой информации.
СУБД – система управлениями базами данных.

58
Q

Верификация

A

Проверки выполняемые в процессе разработки ПО для ответа на вопрос: Делаем ли мы продукт правильно? В соответствии с ТЗ. Выполняются задачи, цели и сроки.

59
Q

Валидация

A

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

60
Q

Tester

A

Проверка создаваемого ТО на соответствие требованиям. Тестирует, дает обратную связь.

61
Q

QC (quality control)

A

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

62
Q

QA (quality assurance – обеспечение качества)

A

QA (quality assurance – обеспечение качества)

63
Q

Клиент-Серверная архитектура

A

Архитектура, в которой сетевая нагрузка распределяется между поставщиками услуг (серверами) и заказчиками услуг (клиентами)
Клиент-сервер-БД
Архитектура вэб приложений:
Клиент – пользовательский интерфейс, формирует запросы к серверу и обрабатывает ответы от него.
Сервер – получает запрос от клиента, выполняет вычисления/запрашивает данные у БД, формирует вэб страницу и отправляет её клиенту.
Взаимодействие происходит через сетевые протоколы (распространен http)
2х-уровневая система: клиент-сервер
3х: клиент-сервер-БД
Тонкий клиент – клиент (ПО), отправляющий запросы на сервер (пример – браузер)
Толстый клиент – 1С бухгалтерия, клиент онлайн игр.

64
Q

Тонкий клиент

A

клиент (ПО), отправляющий запросы на сервер (пример – браузер)

65
Q

Толстый клиент

A

1С бухгалтерия, клиент онлайн игр.

66
Q

Эмуляция

A

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

67
Q

Симуляция

A

Воспроизведение работы системы или программы сугубо виртуально. Лишь эмулирует выполнение кода.

qa (1 decks)

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