Git и Github Шпаргалка

Статья так же доступна тут:
vk.com/@vladilen.minin-git-and-github

JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML)
Корректные значения JSON:
JSON-объект — неупорядоченное множество пар «ключ:значение», заключённое в фигурные скобки «{ }».
Массив — упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].
Число (целое или вещественное).
Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null.
Строка

Комментариев в JSON, увы, нет.

Правила well formed JSON:

Данные в объекте написаны в виде пар «ключ:значение»

Данные в объекте или массиве разделены запятыми

Объект находится внутри фигурных скобок {}

Массив — внутри квадратных []

Ключ описывается строкой, между ним и значением стоит символ «:». Пары ключ-значение отделяются друг от друга запятыми.

Значения ключа могут быть любыми:
число
строка
массив
другой объект
И только строку мы берем в кавычки!

#теория
#полезнаяинформация

#Тестплан (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

👍Хороший тест план включает в себя следующие разделы и вопросы:
(Собрала все возможные пункты из разных источников.)
🔹Цель тестирования
🔹Объект тестирования: системы, приложения, устройства
🔹Перечень функций и подсистем (функции, которые будут протестированы; функции, которые не будут протестированы)
🔹Тестовая стратегия
🔹Критерии начала тестирования
🔹Критерии приостановления и возобновления тестирования
🔹Критерии завершения тестирования
🔹Результаты тестирования
🔹Тестовые Ресурсы
🔹Окружение тестируемой системы
🔹Расписание тестовых циклов
🔹Команда: роли и ответственность
🔹Оценка рисков и пути их разрешения

🔹Тестовая конфигурация
🔹Документация
🔹Метрики
🔹Согласования
🔹Типы тестирования по виду подсистемы или продукта
🔹Типы тестирования по способу выбора входных значений
❓
🖍Что необходимо тестировать? (Объект тестирования)
🖍Что будет тестироваться? (Список функций, система в целом и ее компоненты в отдельности)
🖍Как будет проходить тестирование? (Тестовая стратегия: виды тестирования)
🖍Когда будет проходить тестирование? (Подготовка, планирование, тестирование, результаты и их анализ)
🖍Каковы начальные критерии тестирования? (Готовность тестового окружения, наличие необходимой документации, завершение цикла разработки)
🖍Каковы критерии окончания и результаты тестирования? (Результаты цикла тестирования удовлетворяют требованиям и критериям качества продукта, отчётность по открытым и закрытым дефектам)

О структуре тест плана будет отдельный пост.

Планирую также составить шаблон, как для отчёта о тестировании.

Категория дефекта.
Предлагается для классификации использовать следующие 8 категорий («симптомов») дефектов:
1) Крах Системы – падение операционной системы (синий экран), падение серверов, зависание системы или иная проблема, приводящая к необходимости перезагрузки операционной системы клиентской машины или сервера.
2) Крах Приложения – некорректное завершение работы приложения, зависание приложения или иная проблема, приводящая к необходимости перезагрузки приложения, а также когда при работе с отдельным компонентом приложения нарушается его работоспособность в целом.
3) Сбой Безопасности – система позволяет неавторизированный вход или предоставляет не полагающиеся пользователю права, неверное разрешение конфликтов при многопользовательском доступе к объекту приложения.
4) Искажение Данных – потеря данных или их искажение
5) Дефект Функциональности – неработоспособность функции объекта тестирования, функция работает не так, как ожидается или не так, как была спроектирована, функция не соответствует стандартам и соглашениям; экранный объект ведёт себя не так, как следует из его внешнего вида.
6) Дефекты Производительности – дефекты, вызванные перегруженностью сервера, превышением времени ожидания отклика (выход по таймауту); нерациональное использование времени пользователя, приложение работает медленнее, чем ожидалось.
7) Избыточные Шаги – для достижения требуемой функциональности пользователь должен использовать обходные пути или выполнять неочевидные действия.
8) Дефекты Интерфейса (взаимодействия с пользователем) – грамматические ошибки в интерфейсе, наличие избыточных сообщений, неясные и сбивающие с толку предупреждения, отсутствие средств навигации на странице (в WEB-приложениях), неудовлетворительный пользовательский интерфейс (непродуманная структура, разнородность страниц, отсутствие необходимой вспомогательной информации на странице ввода).

#дефект #теория

#пример
Категории и серьезность дефекта

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

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

#напоминалка

Кто впервые на канале, проверьте свои знания по хэштегу

#тестыдлязакреплениязнаний

Формат оформления тест планов бывает разным и зависит от проекта.
Привожу пример структуры плана тестирования 😉

🔹Титульный лист (Название, Дата, Версия, Статус, Заказчик, Исполнитель, название и адрес компании)
☺️Содержание
1. История (список) изменений (в виде таблицы: Версия, Дата, Изменение, Автор)
2. Введение (Общая информация)
2.1. Область тестирования (область действия)
2.2. Цель
2.3. Цели тестирования
2.4. Подход к тестированию
2.5. Исходные данные
3. Условия для тестирования
3.1. Вычислительная среда и специальные условия для тестирования
3.2. Инструментальные средства и методы тестирования
3.3. Критерии начала тестирования
3.4. Критерии завершения тестирования
4. Стратегия тестирования и подходы
4.1. Типы тестирования
4.1.1. Тестирование целостности данных и базы данных
4.1.2. Функциональное тестирование
4.1.3. Тестирование пользовательского интерфейса
4.1.4. Тестирование надежности
4.1.5. Тестирование кроссбраузерности

#теория #тестплан

4.1.6. Тестирование производительности
4.1.7. Нагрузочное тестирование
4.1.8. Стресс-тестирование
4.1.9. Объемное тестирование
4.1.10. Тестирование безопасности и контроля доступа
4.1.11. Конфигурационное тестирование
4.1.12. Тестирование установки
4.1.13. Тестирование верстки
4.1.14. Тестирование восстановления после сбоев
4.1.15. Тестирование на мобильных устройствах
4.1.16. … и другие виды тестирования
4.2. Тесты интеграционного тестирования
4.3. Тесты приемочного тестирования
4.4. Инструменты тестирования
5. Ресурсы
5.1. Программные ресурсы
5.2. Аппаратные ресурсы
5.3. Человеческие ресурсы
5.4. Временные ресурсы
5.5. Финансовые ресурсы
6. Расписание
7. Команда: роли, обязанности и ответственность
8. Другие вопросы
8.1. Риски тестирования
8.2. Описание свойств и процедур
8.3. Документация, ссылки на стандарты
8.4. Метрики
9. Результаты
9.1. Тестовая модель
9.2. Протоколы испытаний
9.3. Отчеты о дефектах. Статистика по всем дефектам
Выводы и рекомендации
Приложение А. Задачи проекта
Приложение B. Словарь основных аббревиатур и терминов

😉Пример описания Функционального тестирования в тест плане:
📌Цель:
Убедиться в надлежащем функционировании объекта тестирования.
📌Методика:
Ввод допустимых данных
Ввод недопустимых данных
Проверка каждого сценария использования
Проверка навигации
📌Критерии завершения:
Все запланированные тестовые действия завершены
Все найденные дефекты были соответствующим образом обработаны (документированы и помещены в базу дефектов).

🔥Характеристики хорошего плана тестирования
Обоснованная вероятность выявления ошибок
Набор тестов не должен быть избыточным
Тест должен быть наилучшем в своей категории (при прочих равных условиях приносить больше пользы)
Не должен быть слишком простым или слишком сложным.
Некорректное поведение программы должно проявляться с достаточной очевидностью

#теория #тестплан