Alex Compass

Ум разработчика Практика дзен в мире Java - Часть I. Учись видеть

alexbrin — Tue, 04 Aug 2026 15:46:27 GMT

Предисловие

«Пока ты смотришь на свои идеи, ты не видишь программу.»

Когда человек только начинает изучать программирование, ему кажется, что главная задача разработчика состоит в том, чтобы писать код. Со временем приходит другое понимание: писать код относительно просто. Гораздо сложнее увидеть, что происходит на самом деле.

Большинство ошибок рождается не из-за незнания синтаксиса. Они появляются в тот момент, когда мы начинаем заменять наблюдение предположениями.

«Наверное, переменная уже изменилась.»

«Скорее всего, этот метод уже выполнился.»

«Должно работать.»

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

Разработка начинается с простого, но непривычного навыка: перестать гадать.

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

Дзадзен (от японских слов дза — «сидеть» и дзен — «медитация») — это базовая практика «сидячей медитации» в дзен-буддизме.
Краткая суть: Практикующий принимает устойчивую сидячую позу (обычно со скрещенными ногами и прямой спиной), концентрируется на дыхании и беспристрастно наблюдает за потоком мыслей, не цепляясь за них и не оценивая их. В дзен это называют принципом «просто сидения».
Главная цель: Остановить бесконечный внутренний диалог, отбросить эго и напрямую осознать свою истинную природу.

В разработке происходит нечто похожее.

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

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

Каждый из этих инструментов предлагает разработчику отказаться от фантазий и встретиться с реальностью. Именно поэтому эта часть посвящена не Java и даже не отладке. Она посвящена умению видеть. Без этого навыка невозможно глубоко понять язык программирования. Невозможно проектировать сложные системы. Невозможно уверенно исправлять ошибки. Можно лишь надеяться, что код работает.

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

Глава 1. Компилятор никогда не ошибается

Молодой разработчик и его первая ошибка компиляции

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

А потому, что впервые увидел красную строку с ошибкой и подумал:

«Почему программа не работает? Я же всё написал правильно.»

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

Сегодня он пишет свою первую небольшую программу самостоятельно.

public class Main {
    public static void main(String[] args) {
        String name = "Alex";
        System.out.println("Hello, " + name)
    }
}

Он нажимает кнопку Run.

Но вместо привычного окна с результатом появляется сообщение:

error: ';' expected

Недоумение.

«Какой ещё ;?»

Он несколько раз перечитывает код. Всё кажется правильным. Переменная объявлена. Строка выводится. Скобки на месте. Он снова нажимает Run. Та же ошибка.

Начинается поиск виноватого. Может быть, проблема в IntelliJ IDEA? Может быть, что-то неправильно установлено? Может быть, Java работает не так, как объясняли в видео?

Через несколько минут он замечает, что в конце строки действительно отсутствует точка с запятой. Он добавляет её.

System.out.println("Hello, " + name);

Программа запускается. На экране появляется: Hello, Alex

Обычно на этом история заканчивается.

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

Разработчик был абсолютно уверен, что его программа написана правильно. Он доверял собственной памяти больше, чем тому, что происходило на экране. Вместо того чтобы внимательно прочитать сообщение компилятора, он начал искать объяснения в своей голове. Это очень человеческая реакция. Наш мозг не любит признавать, что ошибся. Ему проще предположить, что виноват редактор кода, неправильная настройка проекта или странное поведение языка программирования.

Но компьютер не умеет делать предположений.

Он не думает: «Наверное, разработчик просто устал.»

Он не говорит: «Почти правильно, попробую догадаться, что ты хотел написать.»

Он лишь сообщает факт. «Я не могу скомпилировать программу. В этом месте я ожидал увидеть точку с запятой.»

Ни больше, и меньше.

Именно здесь начинается мышление разработчика. Не тогда, когда человек запоминает синтаксис Java. Не тогда, когда впервые использует цикл или создаёт объект. А тогда, когда перестаёт спорить с обратной связью и начинает её изучать.

В дзен существует простая практика наблюдения. Когда возникает мысль, её не объявляют правильной или неправильной. Её не пытаются прогнать и не пытаются удержать. Её просто замечают такой, какая она есть.

Хороший разработчик постепенно учится делать то же самое с программой. Он перестаёт спрашивать: «Почему компьютер делает что-то странное?». И начинает спрашивать: «Что именно компьютер пытается мне показать?». На первый взгляд кажется, что это небольшая разница в формулировке. На самом деле именно она отделяет человека, который борется с ошибками, от человека, который понимает систему.

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

Почему мы не любим ошибки

Если попросить человека вспомнить школьные годы, то у многих вместе со знаниями всплывают и другие воспоминания:

Красная ручка учителя. Исправления на полях. Низкая оценка. Замечание вроде: «Опять неправильно».

С самого детства нас приучают к простой связи:

Ошибка = плохо.

Если ошибся, значит недостаточно старался. Если ошибся, значит плохо подготовился. Если ошибся, значит знаешь меньше других.

Со временем эта мысль становится настолько привычной, что мы перестаём её замечать. Она превращается в автоматическую реакцию. Именно поэтому, когда начинающий разработчик видит сообщение об ошибке компиляции, он редко воспринимает его спокойно. Вместо любопытства появляется раздражение. Иногда возникает и более неприятная мысль: «Наверное, программирование просто не для меня.»

Но давайте на минуту остановимся. Что такое ошибка компиляции? Это не двойка в дневнике. Не замечание преподавателя. Не оценка ваших способностей. Компилятор вообще ничего о вас не знает. Он не знает, сколько времени вы изучаете Java. Не знает, сколько книг вы прочитали. Не знает, устали ли вы сегодня после работы. Для него существует только исходный код. Он сравнивает написанную программу с правилами языка Java. Если программа соответствует этим правилам, компиляция продолжается. Если нет, он сообщает, в каком месте обнаружил несоответствие.

Всё.

Никаких эмоций. Никаких оценок. Никакого осуждения.

Представьте, что вы собираете шкаф по инструкции. Вы пытаетесь вставить деревянную полку в паз, который для неё не подходит. Полка не встаёт. Будет ли разумно обижаться на шкаф? Конечно нет. Шкаф не говорит: «Ты плохой сборщик мебели.». Он просто устроен определённым образом.

Язык программирования ничем не отличается. Если после имени переменной ожидается оператор, компилятор не может сделать вид, что его отсутствие не имеет значения. Если после строки требуется точка с запятой, он не станет угадывать ваши намерения. Он действует строго по правилам языка. И именно в этой строгости скрывается его главная ценность.

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

Строгость является формой уважения.

Компилятор относится одинаково и к человеку, который открыл Java вчера, и к инженеру с двадцатилетним опытом. Для всех существуют одни и те же правила. Именно поэтому опытные разработчики редко воспринимают ошибки компиляции как проблему. Они воспринимают их как обратную связь. Не как сообщение: «Ты ошибся.». А как сообщение: «Вот место, где твоё понимание языка сейчас расходится с его правилами.». Это очень важное различие. В первом случае ошибка становится поводом защищаться. Во втором случае она становится источником информации.

В дзен существует интересная мысль: Страдание часто возникает не из-за самой ситуации, а из-за сопротивления ей.

Мы хотим, чтобы реальность соответствовала нашим ожиданиям. Но реальность не обязана этого делать. В разработке происходит то же самое. Мы ожидаем, что программа должна компилироваться. Компилятор показывает, что это не так. Можно раздражаться. Можно спорить. Можно несколько раз нажимать кнопку Run, надеясь, что в этот раз всё получится.

А можно остановиться и задать другой вопрос: «Что именно программа пытается мне сообщить?»

С этого вопроса начинается обучение. Не только в программировании. Но и в любом деле, где человек хочет понять реальность, а не доказать собственную правоту.

Что такое компилятор на самом деле

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

Человек пишет:

System.out.println("Hello, world!");

Он видит понятные слова.

System.

out.

println.

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

Как программа, написанная человеком на Java, превращается в команды, понятные компьютеру?

Ответом является компилятор.

Переводчик между двумя мирами

Самое простое объяснение компилятора:

Компилятор — это программа, которая переводит код, написанный человеком, в форму, которую может выполнить компьютер.

Можно представить двух людей, которые говорят на разных языках. Один говорит по-русски. Другой понимает только японский. Между ними нужен переводчик. Но хороший переводчик делает больше, чем просто заменяет слова. Он проверяет смысл. Если человек сказал бессмысленную фразу, переводчик не сможет качественно её перевести. Компилятор делает примерно то же самое. Он не просто заменяет одни символы другими. Он пытается понять написанную программу.

Почему компьютер не может выполнить Java напрямую

Возьмём простой пример:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

Для человека здесь всё понятно. Создается класс. Есть главный метод. На экран выводится текст. Но компьютер не видит «класс» или «метод». Он не знает, что такое System.out.println. Для процессора существует только набор очень низкоуровневых команд.

Например:

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

Если бы каждый программист писал программы непосредственно в машинном коде, разработка была бы невероятно сложной. Поэтому появились языки программирования высокого уровня. Java, Python, C#, Kotlin и другие языки позволяют человеку описывать задачи понятным способом. А компилятор становится мостом между человеческой идеей и машинным исполнением.

Что происходит, когда мы нажимаем Run

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

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

происходит примерно следующее. Сначала компилятор получает наш исходный код. Это файл Main.java Затем он начинает его анализировать.

Он проверяет:

правильно ли написаны ключевые слова;
закрыты ли скобки;
существуют ли используемые методы;
соответствуют ли типы данных друг другу;
соблюдаются ли правила языка Java.

Если всё правильно, компилятор создает другой файл - Main.class. Внутри него находится байткод Java. Это уже не человеческий текст, но еще не машинный код процессора. Дальше в дело вступает JVM.

Здесь появляется одна из самых интересных особенностей Java.

Java-код --> Байткод --> JVM --> Машинный код --> Процессор

Это решение стало одной из главных причин популярности Java. Один и тот же файл .class может работать на разных системах. Неважно, какой процессор стоит внутри компьютера. Если есть подходящая JVM, программа может выполняться. Именно отсюда появился знаменитый принцип Java: «Напиши один раз, запускай где угодно.»

Компилятор не думает за программиста

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

Например, int age = -500;

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

Компилятор как первый собеседник программы

Когда разработчик пишет код, он создает определённую модель мира. Он говорит:

«Вот объект пользователя.»

«Вот список товаров.»

«Вот операция оплаты.»

Компилятор смотрит на эту модель и задаёт первый вопрос: «Эта модель вообще соответствует правилам языка?». Если нет, он сообщает об этом. Не потому что хочет остановить разработчика. А потому что обнаружил несоответствие раньше, чем это сделает программа во время работы. Это огромная ценность. Чем раньше обнаружена проблема, тем дешевле её исправить. Ошибка в момент написания кода исправляется за минуту. Ошибка у пользователя в работающем приложении может стоить компании денег, времени и доверия.

Новый взгляд на компилятор

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

Компилятор — это первая линия защиты программы. Он не пытается доказать, что разработчик неправ. Он показывает место, где возникло противоречие. И чем лучше разработчик умеет понимать этот диалог, тем быстрее он развивается. Потому что программирование — это не процесс написания правильного кода с первого раза. Это процесс постоянного получения обратной связи, анализа и улучшения. А компилятор является первым и самым честным источником этой обратной связи.

Как компилятор читает программу

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

Например: «Разработчик исправил ошибку в программе.»/ Человеку не нужно отдельно анализировать каждую букву. Мозг сразу собирает символы в слова, слова в предложения, а предложения в смысл.

Компьютер работает иначе. Для него программа начинается не с смысла. Она начинается с символов. Когда компилятор получает Java-файл, перед ним лежит просто текст:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

Для человека это программа. Для компилятора это последовательность символов, которую нужно постепенно понять. Именно поэтому компиляция похожа не на простое копирование текста, а на процесс чтения и анализа. Компилятор задает программе несколько вопросов.

Сначала: «Эти символы вообще образуют понятные слова?»

Потом: «Эти слова стоят в правильном порядке?»

Потом: «Имеет ли смысл то, что написано?»

И только после этого: «Можно ли превратить это в программу, которую сможет выполнить компьютер?»

Первый этап. Лексический анализ: поиск слов

Представим, что мы открыли книгу на незнакомом языке. Мы видим буквы, но пока не понимаем отдельных слов. Первое, что нужно сделать, — разделить поток символов на отдельные элементы. Компилятор делает примерно то же самое. Этот этап называется лексическим анализом. Его задача — превратить набор символов в понятные части программы.

Например: int age = 35;. Для человека это одна строка.

Для компилятора это несколько элементов:

int
age
=
35
;

Каждый элемент имеет свое значение.

int — ключевое слово языка Java.
age — имя переменной.
= — оператор присваивания.
35 — числовое значение.
; — завершение инструкции.

Компилятор еще не пытается понять всю программу. Он только говорит: «Я вижу такие элементы.»

Теперь представим ошибку: int age = ;. Человек может понять, что здесь хотел написать разработчик. Возможно, int age = 35;. Но компилятор не работает с догадками. После знака = он ожидает значение. А значения нет. Поэтому появляется ошибка. Не потому что компилятор «не понял человека». А потому что в программе отсутствует обязательная часть конструкции языка.

Второй этап. Синтаксический анализ: правильное ли предложение

Когда мы знаем слова, нужно проверить, можно ли из них составить предложение. Например: «Моя сегодня программа писать.». Формально все слова существуют. Но предложение звучит неправильно.

В программировании происходит похожий процесс. Компилятор проверяет структуру программы. Например:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

Компилятор видит:

Класс.
Внутри класса метод.
Внутри метода команда вывода.
Все элементы расположены там, где должны находиться.

Теперь изменим код:

public class Main {
    public static void main(String[] args)
        System.out.println("Hello");
}

Человеку понятно, что пропущена фигурная скобка. Но для компилятора структура нарушена. Метод объявлен, но его тело не определено. Он не может продолжить анализ. Это похоже на чтение предложения: «Когда я пришел домой потому что». Мы понимаем, что мысль не закончена. Компилятор тоже видит незавершенную конструкцию.

Третий этап. Проверка типов: имеет ли смысл операция

После того как программа построена правильно, компилятор начинает проверять смысл отдельных действий. Один из важнейших принципов Java — строгая типизация. Каждое значение имеет свой тип. Например: int age = 35;, String name = "Alex";

Переменная age хранит число. Переменная name хранит текст.

Теперь: int result = age + name;

Что здесь происходит? Мы пытаемся сложить число и текст. Человек может сказать: «Наверное, разработчик ошибся.»

Компилятор говорит: «Я вижу операцию сложения. Но не знаю, как сложить эти два типа.»

Поэтому он сообщает об ошибке. Это не наказание. Это предупреждение: «Твоя модель данных сейчас противоречит правилам языка.»

Четвертый этап. Поиск существующих элементов

Java-программа состоит не только из правил языка. Она использует классы, методы и библиотеки. Например: System.out.println("Hello");

Компилятор должен проверить:

Существует ли класс System?
Есть ли у него поле out?
Есть ли у него метод println?
Можно ли передать туда строку?

Если написать System.out.printl("Hello"); компилятор остановится. Для человека ошибка очевидна. Пропущена буква n. Но для программы существует только то, что определено. Метода printl нет. Поэтому компилятор сообщает: «Я не нашёл такой элемент.»

Почему ошибки иногда показываются не там, где проблема

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

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello")
        System.out.println("World");
    }
}

Ошибка будет показана возле второй строки вывода. Но проблема находится в предыдущей строке. Там отсутствует ;.

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

Это похоже на человека, который читает предложение: «Сегодня утром я пошел в магазин купил хлеб и встретил». Он может понять, что что-то не так, только когда дошел до конца. Проблема появилась раньше, но стала очевидной позже.

Компилятор не понимает намерения. Он понимает правила.

Это, пожалуй, самая важная мысль этого раздела. Компилятор не знает, что вы хотели написать. Он не читает ваши мысли. Он не видит вашу задачу. Он видит только код. И это его сила. Если бы компилятор пытался угадывать намерения, он иногда помогал бы нам, а иногда создавал бы незаметные ошибки. Строгие правила делают программу предсказуемой. Когда компилятор говорит: «Это невозможно выполнить» - он не утверждает: «Ты плохой разработчик.»

Он говорит: «В твоём описании программы есть противоречие.»

И чем быстрее разработчик учится воспринимать это сообщение именно так, тем быстрее он растёт.

Учиться читать, а не бояться

Начинающий разработчик часто пытается избавиться от ошибок. Опытный разработчик учится понимать их. Это большая разница. Ошибка компиляции — это не конец процесса написания программы. Это часть процесса. Ты написал. Компилятор проверил. Он показал несоответствие. Ты изменил код. Получил новую обратную связь. И постепенно программа становится точнее. В этом процессе нет борьбы между человеком и компьютером. Есть диалог. Компилятор задает вопросы. Разработчик отвечает изменением кода. И именно через этот диалог человек начинает по-настоящему видеть программу.

Почему компилятор никогда не ошибается

Название может показаться странным. Разве компиляторы никогда не содержат ошибок? Конечно, содержат.

Компилятор — это тоже программа. А программы пишут люди. В истории развития языков программирования находили ошибки в компиляторах, исправляли их, выпускали новые версии. Но когда мы говорим: «Компилятор никогда не ошибается» - мы говорим не о внутренних ошибках самого компилятора. Мы говорим о другом. Мы говорим о его главной функции. Если компилятор сообщает: «Этот код нарушает правила языка Java» - то в рамках этих правил он не ошибается. Он выполняет именно ту работу, для которой был создан.

Ошибка или несоответствие?

Есть важное различие между двумя вещами.

Первое: «Программа работает не так, как ожидалось.»

Второе: «Программа не соответствует правилам языка.»

Это разные проблемы. Например: int age = -10;

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

Теперь другой пример: int age = ;

Здесь программа не скомпилируется. Почему? Не потому что компилятору не понравилось значение. Не потому что он считает вашу идею плохой. А потому что конструкция нарушает правила языка. После знака присваивания должно находиться значение. Это не мнение. Это правило.

Компилятор работает внутри определенной системы

Чтобы понять, почему компилятор не ошибается, нужно понять его границы.

Представим судью футбольного матча. Его задача — следить за соблюдением правил игры. Если игрок взял мяч руками, судья фиксирует нарушение. Но судья не может сказать: «Мне кажется, эта команда сегодня играет некрасиво.». Это уже не его задача. Он работает внутри определенной системы правил. То же самое делает компилятор.

У Java есть правила:

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

Компилятор проверяет именно это.

Он не оценивает:

хорошая ли архитектура;
понятны ли имена переменных;
удобно ли будет поддерживать этот код через год;
правильно ли вы выбрали структуру приложения.

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

Почему нам кажется, что ошибается компилятор

Интересно, что проблема чаще всего находится не в компиляторе, а в наших ожиданиях. Мы думаем: «Я хотел написать одно, а компилятор понял другое.». Но компилятор вообще не пытался понять наше намерение. Он анализировал только то, что мы написали. Рассмотрим пример:

public class User {
    private String name;
    public void setName(String name) {
        name = name;
    }
}

Начинающий разработчик может думать: «Я передал значение в поле объекта.»

Но на самом деле код делает другое. Локальная переменная name получает значение самой себя. Компилятор не сообщает ошибку.

Почему? Потому что с точки зрения Java этот код абсолютно допустим. Язык не нарушен. Проблема находится между ожиданием разработчика и реальным поведением программы. И это очень важный момент. Компилятор не обязан исправлять наше мышление. Он показывает только то, что может проверить.

Компилятор как зеркало

Есть интересная особенность зеркала. Оно не делает человека красивее или некрасивее. Оно просто показывает отражение. Если на лице грязь, зеркало не создает её. Оно только позволяет её увидеть. Компилятор работает похожим образом.

Он не создает ошибки. Он делает видимыми несоответствия, которые уже существуют в коде. Когда он показывает: cannot find symbol, это означает: «Ты обращаешься к тому, чего система не знает.»

Когда он показывает: incompatible types, это означает: «Ты пытаешься соединить вещи, которые не соответствуют друг другу.»

Когда он показывает: ';' expected, это означает: «Структура программы нарушена.»

Компилятор не говорит: «Ты плохой программист.»

Он говорит: «Посмотри сюда. Здесь есть противоречие.»

Ошибка как момент обучения

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

Гораздо полезнее задать вопрос: «Почему компилятор считает это неправильным?»

Например, ошибка: String cannot be converted to int

Можно быстро исправить.

Но можно остановиться и понять:

что такое типы данных;
почему Java строго проверяет типы;
почему некоторые преобразования опасны.

Тогда ошибка превращается из препятствия в урок.

Доверие к обратной связи

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

Разница только в отношении. Новичок думает: «Почему система мешает мне написать код?»

Опытный разработчик думает: «Что система пытается мне показать?»

Это изменение мышления является одним из самых важных переходов в профессии.

Компилятор не против разработчика

Иногда кажется, что между человеком и компьютером существует борьба. Разработчик пытается заставить программу работать. Компилятор мешает. Но это неправильный взгляд. Компилятор находится на стороне разработчика. Он первый, кто говорит: «Здесь есть проблема.»

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

Главный урок

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

Обратная связь как главный инструмент обучения

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

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

Именно этот цикл превращает новичка в специалиста. В программировании происходит то же самое.

Написать код — это только начало

Начинающие разработчики часто представляют процесс создания программы так:

Подумать.
Написать правильный код.
Запустить программу.
Получить результат.

Как будто хороший разработчик сразу видит правильное решение. Но реальная разработка выглядит иначе:

Предположить.
Написать код.
Получить обратную связь.
Найти несоответствие.
Исправить.
Повторить.

Программирование — это не процесс угадывания правильного ответа. Это процесс постоянного уточнения своего понимания.

Компилятор как первый учитель

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

Представьте другой вариант. Вы написали программу. Она выглядит правильно. Вы отправили её пользователям. Через неделю кто-то сообщает: «При определённых условиях приложение падает.»

Вы начинаете искать проблему. Оказывается, ошибка была в одной строке.

Но за это время:

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

Теперь сравним. Та же самая ошибка, но обнаруженная компилятором: int age = ; - исправляется за несколько секунд. Одна и та же проблема может иметь совершенно разную цену в зависимости от того, когда она обнаружена. Поэтому хороший инженер стремится получать обратную связь как можно раньше.

Быстрая обратная связь ускоряет обучение

Есть простой принцип:

Чем короче промежуток между действием и результатом, тем быстрее обучение.

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

В программировании так же.

Цикл:

Написал код --> Компилятор проверил --> Получил ошибку --> Исправил - может занимать несколько секунд. За день разработчик проходит этот цикл десятки и сотни раз. Каждый такой цикл немного изменяет его понимание языка.

Почему опытные разработчики любят ошибки

Это кажется странным. Почему человек с большим опытом может спокойно смотреть на ошибку, которая расстроила бы новичка? Потому что опытный разработчик видит в ней информацию. Ошибка сообщает: «Вот граница твоего текущего понимания.»

Например:

Новичок видит: incompatible types - и думает: «Java сложная.»

Опытный разработчик видит: «Я передал значение одного типа туда, где ожидается другой. Нужно проверить модель данных.»

Разница не в знаниях. Разница в отношении к обратной связи. Один человек воспринимает ошибку как препятствие. Другой — как подсказку.

Ошибка показывает карту неизвестного

Когда человек изучает новую область, перед ним существует большая территория неизвестного. В начале она выглядит как белое пятно.

Он знает: «Я не понимаю, почему это работает.», «Я не знаю, почему появляется эта ошибка.», «Я не понимаю, как связаны эти классы.»

Каждая ошибка немного уменьшает эту область. Она показывает: «Вот здесь есть место, которое тебе нужно изучить.»

В этом смысле ошибки являются не врагами обучения. Они являются указателями. Без них человек может долго двигаться в неправильном направлении.

Разница между оценкой и обратной связью

Очень важно разделять две вещи. Оценка говорит: «Ты сделал плохо.»

Обратная связь говорит: «Вот что произошло. Вот где есть несоответствие.»

Первая направлена на человека. Вторая направлена на действие. И именно вторая помогает развиваться. Компилятор никогда не говорит: «Ты плохой программист.»

Он говорит: «В строке 5 ожидается выражение типа String, но получено значение другого типа.»

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

Дзен и искусство наблюдать результат

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

Не: «Моя программа должна работать.»

А: «Что показывает мне программа сейчас?»

Не: «Компилятор мешает.»

А: «Какую информацию он мне дает?»

Такой подход меняет отношение к разработке. Ты перестаешь защищать свой код. Ты начинаешь его исследовать.

Разработчик растет через диалог

Хороший разработчик не тот, кто пишет код без ошибок. Таких людей не существует. Хороший разработчик — это человек, который умеет быстро получать информацию о своих ошибках и использовать её. Он вступает в постоянный диалог с системой:

Разработчик пишет.
Компилятор отвечает.
Разработчик анализирует.
Программа меняется.

И постепенно между человеком и компьютером появляется понимание.

Главный урок

Компилятор — это не стена между человеком и программой. Это первый собеседник. Он первым сообщает: «Здесь что-то не совпадает.»

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

Учимся читать сообщения компилятора

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

error: cannot find symbol
symbol: variable username
location: class Main

И первая мысль: «Что это вообще значит?»

Мозг пытается воспринимать сообщение целиком. Но это неправильный подход. Ошибка компилятора — это не текст, который нужно просто понять от начала до конца. Это отчет. В нем есть конкретная информация:

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

Задача разработчика — научиться извлекать эту информацию.

Ошибка как сообщение, а не как приговор

Начинающий разработчик часто смотрит на ошибку так: «Программа не работает.»

Но это слишком общее утверждение. На самом деле компилятор сообщает гораздо меньше: «Я не могу продолжить обработку программы, потому что встретил ситуацию, которая нарушает правила Java.»

Это совсем другое. Компилятор не говорит, что вся программа плохая. Он указывает конкретное место, где возникло противоречие. Поэтому первое правило:

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

Структура сообщения компилятора

Рассмотрим простой пример. Код:

public class Main {
    public static void main(String[] args) {
        System.out.println(message);
    }
}

Запускаем компиляцию. Получаем:

Main.java:5: error: cannot find symbol
        System.out.println(message);
                           ^
  symbol:   variable message
  location: class Main

На первый взгляд выглядит страшно. Но разберем его по частям.

Первая часть: где произошла ошибка

Main.java:5

Это самое первое, на что нужно смотреть.

Компилятор говорит:

Файл: Main.java. Строка: 5

Именно там он обнаружил проблему. Но важно помнить: Место обнаружения ошибки не всегда является местом её возникновения.

Иногда причина находится несколькими строками выше.

Вторая часть: описание проблемы

cannot find symbol

Это одна из самых частых ошибок Java. Дословно: «Не могу найти символ.»

Но что такое символ? Для компилятора символ — это любой элемент программы:

переменная;
класс;
метод;
поле.

В нашем случае он не нашел переменную: message

Третья часть: детали

symbol: variable message

Компилятор уточняет: «Я искал переменную с именем message.»

А ниже: location: class Main - говорит: «Я искал её внутри класса Main.»

Теперь проблема становится очевидной. Мы написали: System.out.println(message);. Но нигде не создали: String message = "Hello";

Исправленный вариант:

public class Main {
    public static void main(String[] args) {
        String message = "Hello";
        System.out.println(message);
    }
}

Компиляция пройдет успешно.

Ошибка №1. Пропущена точка с запятой

Одна из первых ошибок каждого Java-разработчика. Код:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello")
    }
}

Сообщение: error: ';' expected

Компилятор говорит: «Я ожидал увидеть точку с запятой.»

Новичок может подумать: «Но почему он показывает ошибку возле закрывающей скобки?»

Потому что компилятор читает код последовательно. Он увидел: System.out.println("Hello") - и ожидает: ;

Но вместо этого получил: }

То есть закрытие блока. Компилятор сообщает не: «Ошибка в фигурной скобке.». Он сообщает: «К этому моменту я ожидал завершение предыдущей команды.». Исправление: System.out.println("Hello");

Ошибка №2. Неправильный тип данных

Код:

public class Main {
    public static void main(String[] args) {
        int age = "35";
    }
}

Ошибка: incompatible types: String cannot be converted to int

Разберем.

incompatible types означает: «Типы не совместимы.»

Дальше: String cannot be converted to int - означает: «Текст нельзя автоматически превратить в число.»

Почему? Потому что: "35" и 35 для Java разные вещи.

Первое: String - это текст. Второе: int - это число. Для человека они похожи. Для программы это разные типы данных. Правильный вариант: int age = 35;

Ошибка №3. Метод не существует

Код:

public class Main {
    public static void main(String[] args) {
        System.out.printl("Hello");
    }
}

Ошибка: cannot find symbol symbol: method printl(String)

Что произошло?

Мы написали: printl. Но в классе System.out такого метода нет. Есть println. Одна маленькая буква изменила смысл. Компилятор не может сказать: «Наверное, вы имели в виду println.»

Почему? Потому что иногда похожие имена означают разные вещи. Если бы Java постоянно угадывала, ошибки становились бы непредсказуемыми. Поэтому компилятор строго сообщает: «Такого метода я не знаю.»

Ошибка №4. Класс не найден

Код:

ArrayList names = new ArrayList<>();

Ошибка: cannot find symbol. symbol: class ArrayList

Компилятор говорит: «Я не знаю, что такое ArrayList.»

Почему? Потому что этот класс находится в другой части Java и требует импорта.

Нужно добавить:

import java.util.ArrayList;

Теперь компилятор понимает: «Хорошо, этот класс существует.»

Как правильно читать ошибки

Есть простой алгоритм. Когда появилась ошибка компиляции:

1. Найди первую ошибку

Если ошибок несколько, исправляй первую. Одна ошибка может создавать десятки последующих.

2. Посмотри строку

Например: Main.java:10. Открой именно это место.

3. Прочитай ключевые слова

Не пытайся понять всё сразу. Ищи главное:

cannot find symbol - что-то не найдено.
incompatible types - несовместимые типы.
';' expected - пропущен символ.
method does not exist - такого метода нет.

4. Проверь ожидания

Задай себе вопрос: «Что я думал, что произойдет?»

И второй: «Что реально написано в коде?»

Очень часто ошибка находится именно между этими двумя вещами.

Ошибки как разговор

Со временем сообщения компилятора перестают выглядеть как угрозы. Они превращаются в диалог. Компилятор говорит: «Я не нашел этот класс.». Разработчик отвечает: «Точно, я забыл импорт.»

Компилятор говорит: «Типы не совпадают.». Разработчик отвечает: «Я перепутал строку и число.»

Компилятор говорит: «Ожидался символ.». Разработчик отвечает: «Я пропустил часть конструкции.»

Это не борьба. Это совместная работа.

Практика внимательного наблюдения

В дзен есть принцип: сначала увидеть, потом действовать.

В разработке это означает: не бросаться сразу менять код. Сначала посмотреть, прочитать, понять.

Ошибка уже содержит часть ответа. Она показывает место, где ваше представление о программе отличается от реального состояния. Компилятор не прячет проблему. Он подсвечивает её. Нужно только научиться смотреть.

Главный урок

Сообщение компилятора — это не препятствие на пути разработчика. Это карта. Она показывает неизвестную территорию. Каждая ошибка говорит: «Здесь есть место, которое нужно понять.» И каждый раз, когда разработчик спокойно читает ошибку вместо того, чтобы раздражаться, происходит маленькое изменение мышления. Он перестает бороться с программой. Он начинает её исследовать. А именно с этого начинается настоящее мастерство разработки.

Не с умения писать код без ошибок. А с умения видеть, понимать и исправлять их.

Что изменится в вашем мышлении после этой главы

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

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

Вы перестаете воспринимать ошибки как поражение

Самое первое изменение происходит внутри. Раньше ошибка могла вызывать раздражение: «Почему это опять не работает?»

Теперь появляется другой вопрос: «Что именно система пытается мне показать?»

Это небольшое изменение формулировки меняет весь процесс обучения. В первом случае вы боретесь с ошибкой. Во втором — исследуете её. Разработчик, который боится ошибок, старается их избегать. Разработчик, который понимает ошибки, использует их.

Вы начинаете доверять фактам больше, чем предположениям

Человек очень легко создает историю в своей голове. Мы предполагаем: «Переменная точно содержит это значение.», «Этот метод точно вызывается.», «Этот объект точно создан.»

Но программа не работает с предположениями. Она работает с конкретным состоянием. Компилятор становится первым учителем, который возвращает вас из мира догадок в мир фактов. Он напоминает: «Не думай о том, что должно происходить. Посмотри, что происходит на самом деле.»

Это один из важнейших навыков профессионального разработчика.

Вы начинаете читать программу глазами системы

Новичок смотрит на код и видит смысл, который хотел вложить автор.

Он читает: int age = "35"; и думает: «Ну понятно, возраст равен 35.»

Но компилятор видит другое: «Переменная типа int получает значение типа String. Эти вещи несовместимы.»

Постепенно разработчик учится переключаться между двумя взглядами.

Первый: Что я хотел выразить?
Второй: Что реально видит система?

Именно между этими двумя точками рождается профессиональное мышление.

Вы перестаете спорить с инструментами

У начинающего разработчика часто возникает желание доказать системе свою правоту.

«Но я же имел в виду другое.»

«Но это должно работать.»

«Почему Java такая сложная?»

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

Вы начинаете видеть программирование как диалог

Раньше процесс мог выглядеть так: написал код → получил результат.

Теперь появляется более точная картина: создал предположение → получил обратную связь → изменил понимание → улучшил решение.

Разработка становится разговором между человеком и системой. Вы задаете вопрос кодом. Компилятор отвечает. Вы анализируете ответ. Следующий вариант программы становится лучше.

Вы понимаете ценность маленьких ошибок

Большая ошибка редко появляется внезапно. Обычно она начинается с маленького несоответствия, которое осталось незамеченным: пропущенный символ, неверный тип, неправильное имя, ошибочное предположение. Компилятор позволяет увидеть эти моменты сразу. И это один из главных принципов инженерии:

Чем раньше обнаружена проблема, тем меньше цена её исправления.

Хороший разработчик не тот, у кого нет ошибок. Хороший разработчик тот, кто умеет обнаруживать их быстро.

Вы начинаете практиковать «ум разработчика»

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

В программировании это означает: Посмотреть на ошибку. Прочитать сообщение. Понять причину. Изменить код. Проверить результат. Снова посмотреть.

Это кажется простым. Но именно из таких маленьких действий формируется мастерство.

Главный вывод первой главы

Компилятор никогда не ошибается не потому, что он совершенен, а потому, что он честно показывает состояние вашей программы.

Он не враг, не препятствие. Не строгий учитель, который ставит оценки. Он зеркало.

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

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

Подготовка к собесу

alexbrin — Fri, 29 Mar 2024 10:16:23 GMT

ОСНОВНЫЕ ВИДЫ ТЕСТИРОВАНИЯ ПО

Все классификации тестирования:

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

Статическое тестирование
Динамическое тестирование

Классификация по доступу к коду и архитектуре:

Тестирование белого ящика
Тестирование серого ящика
Тестирование чёрного ящика

Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing)
Интеграционное тестирование (Integration testing)
Системное тестирование (System testing)
Приёмочное тестирование (acceptance test):
А) Пользовательское приемное тестирование
Б) Эксплуатационное
В) На соответствие контракту

Классификация по принципам работы с приложением

Позитивное тестирование
Негативное тестирование

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

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

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

Smoke test
Тестирование критического пути
Расширенное тестирование

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

Тестирование доступности
Тестирование локализации и интернетизации
Тестирование безопасности
Проверка удобства
Нагрузочное тестирование
Стресс-тестирование
Тестирование стабильности
Инсталляционное тестирование

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

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

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

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

Классификация по доступу к коду и архитектуре:

Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Модульное тестирование производят сами разработчики, не тестировщики.
Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей.
Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д

Классификация по принципам работы с приложением

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

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

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

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

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

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

Тестирование доступности - доступно ли людям с ограниченными возможностями.
Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика.
Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация).
Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию.
Проверка удобства - тестирование направленное на удобство пользования и дизайна.
Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд.
Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров.
Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу.
Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд).
Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.

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

Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.
Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
Регрессионное тестирование проводится: - после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки

ТЕСТИРОВАНИЕ И QA/QC, ЖИЗНЕННЫЕ ЦИКЛЫ

Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.

Что такое тестирование программного обеспечения?

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

Что такое контроль качества и обеспечение качества?

Контроль качества QC (Quality Control) — это тщательное тестирование программы на наличие дефектов, а также проверка того, что программное обеспечение соответствует всем требованиям, выдвинутым заказчиком.

Обеспечение качества QA (Quality assurance) – это подход, который помогает убедиться, что методы, технологии и процессы, используемые для создания качественных результатов, применяются правильно.

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

Принцип 1 — Тестирование демонстрирует наличие дефектов

Принцип 2 — Исчерпывающее тестирование невозможно

Принцип 3 — Раннее тестирование

Принцип 4 — Скопление дефектов

Принцип 5 — Парадокс пестицида

Принцип 6 — Тестирование зависит от контекста

Принцип 7 — Заблуждение об отсутствии ошибок

Что такое SDLC (Жизненный цикл разработки программного продукта)?

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

Этапы SDLC:

Требования
Проектирование
Разработка
Тестирование
Релиз
Поддержка

Что такое STLC Жизненный цикл тестирования программного продукта?

Жизненный цикл тестирования программного продукта (STLC – Software testing lifecycle) - процесс, направленный на тестирование программного продукта.

Этапы STLC

Анализ требований
Тестовое планирование
Написание тестовых сценариев
Подготовка тестовой среды
Выполнение тестов
Завершающая фаза

ВСЕ О ТЕСТ-ДИЗАЙНЕ

Что такое Тест-дизайн?

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Цели тест-дизайна:

Придумать тесты которые смогли бы обнаружить наиболее серьезные ошибки для ПО
Минимизация количества тестов

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

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

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

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

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

Сценарное тестирования - инструмент, подразумевающий прохождение пути пользователя.

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

Предугадывание ошибок - сценарий, подразумевающий предугадывание уязвимых мест в программе.

ДОКУМЕНТАЦИЯ (кейсы, листы, репорты)

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

Чек-лист

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

Чек-лист включает в себя следующие атрибуты:

Проект
Цель проверки
Идентификатор
Требования
Дата проведения
Исполнитель
Среда тестирования
Тип тестов
Название проверок
Результат проверки

Тест-кейс

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

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

Обязательные атрибуты тест-кейсов

Название проекта
ID
Требования
Модуль
Название
Приоритет
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Среда тестирования
Шаги-теста
Ожидаемый результат

Тестовый набор

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

Включает в себя те же атрибуты, которые и включает в себя тест-кейс.

Баг-репорт

Баг-репорт – это отчет об ошибках

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

Проект
Название документа
Ссылка на требования
Цель проверки
Дата проведения
Исполнитель
Среда тестирования
Шаги теста
Ожидаемый результат
Фактический результат
Статус бага
Серьезность бага
Приоритет устранения бага
Прикрепленный файл

Серьезность бага:

Серьезность (severity) – показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

У серьезности могут быть следующие статусы:

Blocker – блокировка, работа ПО невозможна
Critical –критический, приводит наш функционал в нерабочее состояние
Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.

Приоритет бага:

Приоритет - показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, team-lead или заказчиком.

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения.

КЛИЕНТ - СЕРВЕРНАЯ АРХИТЕКТУРА

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

2 вида клиент-серверной архитектуры:

С базами данных
Без баз данных

Что включает в себя КСА:

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

Существует 2 вида клиентов:

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

Плюсы и Минусы Монолитной Архитектуры:

Плюсы:

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

Минусы:

Масштабирование: Затруднено горизонтальное масштабирование из-за требований к целостности данных.
Сложность обновлений: Изменения в большом приложении могут быть сложными и опасными.
Гибкость: Недостаточно гибкая для больших и комплексных проектов.

Плюсы и Минусы Микросервисной Архитектуры:

Плюсы:

Гибкость: Легко масштабировать и обновлять отдельные микросервисы.
Распределенная разработка: Команды могут работать независимо друг от друга на разных сервисах.
Отказоустойчивость: Если один сервис падает, другие могут продолжать работу.

Минусы:

Сложность управления: Необходимо учитывать большое количество сервисов и их взаимодействие.
Сложнее отлаживать: Взаимодействие между микросервисами может быть сложным для отладки.
Затраты на инфраструктуру: Дополнительные расходы на поддержку и развертывание сервисов.

HTTP ПРОТОКОЛЫ

HTTP- «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML.

Протокол – набор правил передачи информации. Мы регламентируем то, как будет передаваться в сети интернет наша информация.

Метод HTTP

GET - запрос для получения статуса, получение какой либо информации от сервера

POST – отправка данных, файлов

PUT – изменение данных

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

Коды состояния запроса

100-е – это информационный код состояния, дает информационные сообщения.

200-е – информируют нас об успешной отработке запроса

300-е – это перенаправление, то есть, к примеру, когда был изменен url и нужно идти на другой.

400-е – обозначают что на стороне клиента есть ошибка.

500-е – это ошибка на стороне сервера.

Передача протокола осуществляется по Модели TCP/IP.

Уровни TCP/IP:

сетевые интерфейсы – передаются физические импульсы (оптоволокно) (протокол Ethernet)
сетевой – происходит передача физических сигналов, основной протокол –IP
транспортный – транспортные взаимодействия в нашей сети:

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

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

SOAP И REST

SOAP (Simple Object Access Protocol) — стандартный протокол. Четко структурирован и задокументирован.

REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети, основанный на методах протокола HTTP.

SOAP

Любое сообщение в протоколе SOAP — это XML документ

REST

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол.

Управление данными происходит с помощью методов HTTP: GET, POST, PUT, DELETE.

Разница между архитектурным стилем и протоколом в том что к АС не применяются какие-то жесткие правила

REST (Representational State Transfer) и SOAP (Simple Object Access Protocol) - это два различных способа построения архитектуры для веб-сервисов. Вот основные различия между ними:

Принципы дизайна:
REST базируется на принципах архитектуры веб, таких как использование HTTP методов (GET, POST, PUT, DELETE), представление ресурсов через URL
SOAP основывается на строгих стандартах и предполагает использование XML для обмена сообщениями
Формат сообщений:
REST использует различные форматы для обмена данными, такие как JSON, XML, HTML, и другие.
SOAP использует только XML в качестве формата сообщений.
Простота и гибкость:
REST считается более простым и гибким для использования.
SOAP предлагает большую степень стандартизации
Производительность:
REST обычно обеспечивает более высокую производительность благодаря более легковесным форматам данных и возможности кэширования.
SOAP зачастую требует большего объема данных из-за использования XML, что может негативно отразиться на производительности.

Что выбрать SOAP или REST?

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

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается действиями: чтение, добавление, изменение и удаление данных (те самые наши 4 метода get, post, put, delete ) — смело выбирайте REST. Он наиболее популярен и быстр.

POSTMAN И API

API – интерфейс, который определяет, как одна программа должна взаимодействовать с другой программой.

Типы API:

Локальные API - то, что позволяет компонентам одной системы взаимодействовать между собой (микросервисная архитектура)
Удаленные API - позволяет связывать между собой несколько систем (SOAP и REST).

API появляется раньше GUI поэтому API тестируется раньше.

Как работает API:

Вызов операции (GET, POST, PUT, DELETE)
Входные данные (HTTP Request)
Выходные данные (РЕЕЗ Response)

Способы вызова API:

Вызов функции системой (прямой вызов)
Вызов метода другой системой (прямой вызов)
Вызов метода человеком (прямой вызов)
GUI -> API. (косвенный)

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

Вот несколько основных целей использования коллекций в Postman:

Организация запросов:

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

Совместная работа:

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

Использование переменных и сред:

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

Управление тестами:

Коллекции позволяют легко настраивать и управлять тестами для ваших API-запросов, что помогает обеспечить качество и надежность вашего API.

Сценарии и потоки работы:

Postman позволяет создавать сценарии и потоки работы с помощью коллекций, что полезно для тестирования API и взаимодействия с ними в различных сценариях использования.

МОБИЛЬНОЕ ТЕСТИРОВАНИЕ

Типы мобильных приложений:

Нативными - написаны на родном (с англ. native – родной) для определённой платформы языке программирования.

Web – веб-сайт, адаптированный для нашего мобильного приложения.
Веб-приложение, представляет собой сайт, который адаптирован и оптимизирован под любой смартфон.

Гибридные приложения представляют собой сочетание веб и нативных приложений. Они могут быть загружены из маркетов вроде Google Play и App Store. Для их работы необходимо интернет-подключение.
Так же часто гибридные приложения являются кроссплатформенными, что ускоряет и облегчает процесс разработки.

Тестирование и особенности тестирования мобильных приложений

Зависимости мобильного тестирования:

1. Интернет:

- тип соединения

- изменение типа соединения

- качество соединения

- потеря связи

2.Проверки на прерывание:

- исходящие/входящие вызовы

- всплывающие окна/уведомления

- прерывания при разрядке/подзарядке

- сворачивание/разворачивание приложения

3.Тестирование установки

Установка.

Удаление и переустановка.

Обновление.

4.Работа с функциями телефона:

- GPS

- видео/фото

- размер экрана, разрешение, ориентация

- работа с жестами

- отпечаток пальца, узнавание лица, пароль, графический ключ

- клавиатура

- Bluetooеh

- работа со съемными картами памяти

- нажатие

- комбинации кнопок

- динамики, микрофоны, гнездо для гарнитуры

5.Тестирование производительности:

- загрузка оперативной памяти

- зависимость от заряда батареи

- запуск с внутренней памяти/ с накопителя

6. Тестирование на соответствие гайдлайнам и мокапам

ЛОКАЛИЗАЦИЯ БАГА

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

Локализация - это поиск первопричины возникновения ошибки.

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

Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:

Выявить причины возникновения дефекта
Проанализировать возможность влияния найденного дефекта на другие области
Отклонение от ожидаемого результата
Исследовать окружение
Проверить на разных устройствах
Проверить в разных версиях ПО
Проанализировать ресурсы системы

Локализация бага на интеграционном уровне

Локализация бага (дефекта) включает в себя процесс анализа проблемы с целью выявления максимальной детализации причины ее возникновения. Чем больше информации о проблеме собрано, тем быстрее ее решит команда.

DEVTOOLS

Консоль - прописываются действия и ошибка JS. Так же в этой консоли можно исполнять JS. Ошибки, предупреждения о возможных ошибках. Все эти ошибки копируются (текст из консоли) и отправляется в баг репорт.
Источники - здесь содержится информация о серверах, к которым общается клиент.
Сеть - информация об общении сервера и клиента. Показывает запросы, которые отправляет клиент и ответы, которые отправляет сервер.
Производительность - для оценки быстродействия сайта.
Защита - проверка на безопасность протоколов.

СНИФФЕРЫ

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

Самые популярные инструменты: Charles и Fiddler.

Charles

При работе в браузере все запросы и ответы будут отображаться в программе.

Можно выбирать запрос и нажать на Focus. И тогда можно отслеживать именно этот запрос. Так же, как и в devtools.

Что можно посмотреть в запросах: header, body, служебную информацию, статус коды, методы (http).

Так же можно с помощью Charles отслеживать трафик с телефона или эмулятора. Для этого в настройках WiFi нужно выбрать сеть, к которой подключен компьютер с Charles на борту и подключится к той же WiFi сети, а так же настроить прокси для этой сети. В прокси нужно вписать ip адрес компьютера. Порт - 8888. Так же на телефоне нужно установить сертификат чтобы перехватывать трафик.

Что можно тестировать в Charles:

Переадресация (Tools - Map Remote). Можно выставить поведение при переадресации. Например, чтобы с сайта google.com происходила переадресация на ya.ru.
Подмена (Tools - Rewrite). Используется чаще всего. Можно подменить запросы, URL, ответы, отдельные параметры, отдельные header.
Подмена ответа сервера в целом (Tools - Map Local). Например, работаем на сайте и загружаем определенную картинку или заказчик что то загрузил на сайт и появилась ошибка. Нужно запросить у заказчика материал и попробовать повторить его путь. Берем эту картинку, добавляем ее в body и смотрим, что происходит. Тогда могут пригодится ответы сервера.
Занижать скорость интернета (Tools - Enable Trottling).
Работа с breakpoint (Proxy - Breakpointing Settings). Можно ставить как для ответа, так и для запроса.

SQL

Первичный и внешний ключи:

Первичный ключ (PRIMARY KEY) - это уникальный идентификатор для каждой строки в таблице. Он используется для определения единственности данных и обеспечения быстрого доступа к ним.
Код: PRIMARY KEY

Внешний ключ (FOREIGN KEY) - это отношение между двумя таблицами, которое устанавливает связь между ними. Внешний ключ используется для ограничения взаимосвязи между таблицами и предотвращения несоответствий данных. Внешний ключ ссылается на первичный ключ другой таблицы.
Код: band_id INTEGER REFERENCES band(band_id)

Типы взаимосвязи таблиц SQL

1. Связь один ко многим (one-to-many): Это тип взаимосвязи, когда одна запись в одной таблице может относиться к нескольким записям в другой таблице.

2. Связь многие ко одному (many-to-one): Это тип взаимосвязи, когда несколько записей в одной таблице могут относиться только к одной записи в другой таблице.

3. Связь один к одному (one-to-one) - это тип взаимосвязи между двумя таблицами в базе данных, когда каждая запись в одной таблице связана с только одной записью в другой таблице.

4. Связь многие ко многим (many-to-many) - это тип взаимосвязи между двумя таблицами в базе данных, когда каждая запись в одной таблице может быть связана с несколькими записями в другой таблице, и наоборот.

Inner Join и Outer Join

INNER JOIN - способ соединения таблиц, при котором остаются те строки, где значения ключа совпадают в обеих таблицах.

LEFT OUTER JOIN - способ соединения таблиц, при котором возвращаются все строки из левой таблицы и соответствующие строки из правой таблицы. Если в правой таблице нет соответствующих строк, тогда возвращает NULL

FULL OUTER JOIN - способ соединения таблиц, при котором возвращаются строки из обеих таблиц. Если в левой или правой таблице нет соответствующих данных для второй таблицы - тогда подставляется NULL

Основные запросы:

CREATE - Создает новую таблицу, представление таблицы или другой объект в БД

DROP - Удаляет существующую таблицу

SELECT - Извлекает записи из одной или нескольких таблиц

INSERT - Создает записи

UPDATE - Модифицирует записи

DELETE - Удаляет записи

AND - Объединяет условия

BETWEEN - Проверяет вхождение значения в диапазон от минимального до максимального

IN - Выполняет поиск значения в списке значений

LIKE - Сравнивает значение с похожими

NOT - Инвертирует (меняет на противоположное) смысл других логических операторов

OR - Комбинирует условия (одно из условий должно совпадать)

IS NULL - Определяет, является ли значение нулевым

UNIQUE - Определяет уникальность строки

KAFKA, СИНХРОННОЕ И АСИНХРОННОЕ ВЗАИМОДЕЙСТВИЕ

Kafka

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

Главное отличие Кафки от большинства брокеров в том, что Кафка добавляет сообщения в журнал (в топик), а консьюмер сам забирает из этого журнала данные. Кафку часто используют для сбора и агрегации из большого количества источников.

Плюсы Кафки:

Более высокая производительность.
Все сообщения после прочтения не удаляются и могут быть прочитаны консьюмерами повторно. Удаление задается вручную.
Из Кафки нельзя удалить конкретное сообщение (партицию), а только удалить топик целиком.
При перезапуске консьюмера в брокере сохраняется коммит (снимок состояния), и тем самым происходит фиксация и консьюмер продолжает читать.

Синхронное взаимодействие:

Определение: В синхронном взаимодействии одна часть программы ждет завершения другой части программы, прежде чем продолжить свое выполнение.

Асинхронное взаимодействие:

Определение: В асинхронном взаимодействии части программы могут работать параллельно без ожидания завершения друг друга.

Шпаргалка для собеса тестировщика

alexbrin — Wed, 20 Mar 2024 21:16:54 GMT

1. Что такое тестирование программного обеспечения?

2. Что такое контроль качества и обеспечение качества?

3. Что такое SDLC (Жизненный цикл разработки программного продукта)?

Этапы SDLC:

Требования
Проектирование
Разработка
Тестирование
Релиз
Поддержка

4. Что такое STLC Жизненный цикл тестирования программного продукта?

Этапы STLC

Анализ требований
Тестовое планирование
Написание тестовых сценариев
Подготовка тестовой среды
Выполнение тестов
Завершающая фаза

5. Что такое тест-кейс?

6. Атрибуты тест-кейсов, что в себя включает тест-кейс?

Название проекта – здесь указывается название проекта, для которого мы пишем сценарии проверки
ID – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов, это необходимо для того чтоб мы могли всегда корректно ссылаться на наш документ, при общении с другими коллегами, указанием в других системах и т.д.
Требования – ссылка на документ, на основании которого составлен данный документ
Модуль – название модуля к которому относится данный функционал
Название - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте
Приоритет - показывает, на сколько важно проведение данного теста
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Тестировщик самостоятельно выставляет данный приоритет, основываясь на своем опыте.
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Шаги-теста – самый главный атрибут нашего документа, в котором мы подробно расписываем все шаги прохождения нашего теста
Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем получить, после того как мы выполним данный шаг, очень важно писать результат по каждому шагу, а не один для всех шагов. Это позволит любому члену команды повторить данный тест.

7. Что такое тестовый набор?

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

8. Атрибуты тестового набора, что в себя включает тестовый набор?

Они дублируют с атрибутами тест-кейсов.

ID тест-кейса
Название проекта
Модуль
Описание теста
Ожидаемый результат
Приоритет - показывает, на сколько важно проведение данного теста:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Дата проведения теста
Исполнитель
Среда тестирования
Статус

9. Что такое чек-лист?

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

10. Атрибуты чек-листа, что включает в себя чек-лист?

Проект – здесь указывается название проекта, для которого мы пишем сценарии проверки;
Цель проверки - здесь идет название модуля который будет проверять в данном документе;
Идентификатор -это уникальный Идентификатор документа;
Требования - ссылка на документ, на основании которого составлен данный документ;
Дата проведения;
Исполнитель;
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Тип тестов;
Название проверок - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
Результат проверки

11. Что такое план тестирования?

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

12. Для чего проводится тестирование ПО?

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

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

Принцип 1 — Тестирование демонстрирует наличие дефектов
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Принцип 4 — Скопление дефектов
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста
Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок
Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

14. В чем разница между верификацией и валидацией?

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

15. Что такое требования?

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

16. Что такое баг и баг-репорт?

Баг – это дефект – это отклонение ожидаемого поведения работы программного продукта от фактического.

Баг-репорт – это отчет об ошибках.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

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

Проект
Название документа
Ссылка на требования
Цель проверки
Дата проведения
Исполнитель
Среда тестирования
Шаги теста
Ожидаемый результат
Фактический результат
Статус бага
Серьезность бага
Приоритет устранения бага
Прикрепленный файл

18. Приоритет устранения и серьезность бага

У серьезности могут быть следующие статусы:

Blocker – блокировка, работа ПО невозможна
Critical –критический, приводит наш функционал в нерабочее состояние, отклонение от БЛ ПО, не реализация функций, потеря пользовательских данных
Major-серьезные ошибки, которые свидетельствуют об отклонении работы от БЛ или нарушающие работу программы, но не имеют критическое воздействие на ПО
Minor – незначительный дефект не нарушающий функционал нашего приложения, который является несоответствием ожидаемого результата (ошибка дизайна, пример)
Trivial –не имеет влияния на функционал и работу нашей программы, но может быть обнаружен визуально.

P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения.
P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

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

19. Классификация по запуску кода на исполнение:

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

20. Классификация по доступу к коду и архитектуре:

Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

21. Классификация по уровню детализации приложения (Пирамида тестирования):

Модульное тестирование или юнит-тестирование (англ. unit testing) — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Модульное тестирование производят сами разработчики, не тестировщики.
Интеграционное тестирование (Integration testing) — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Взаимодействие компонентов, модулей и иных систем между собой. Тестирование части системы, состоящей из 2-х и более модулей.
Системное тестирование (System testing) — тестирование взаимодействия между всеми компонентами системы или разных систем между собой или тестирование интерфейсов, между которыми взаимодействует система. Полная проверка приложения, всех модулей, можно ли пройти весь бизнес путь.
Приёмочное тестирование (acceptance test) — тестирование на сдаче приемки всего программного продукта или его части Заказчику
А) Пользовательское приемное тестирование (User Acceptance Testing) – перед релизом собирается группа конечных пользователей, тестируется основной функционал, при наличии дефектов-устраняются.
Б) Эксплуатационное (Operational acceptance testing) – производится пользователем или администратором в среде, которая имитирует реальные условия эксплуатации ПО, производится тестирование резервного копирования, аварийное восстановление системы, безопасность ПО.
В) На соответствие контракту – на соответствие гостов, нормативных актов и т.д

22. Классификация по принципам работы с приложением

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

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

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

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

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

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

Тестирование доступности - доступно ли людям с ограниченными возможностями.
Пример: Может ли человек, получив голосовое, прослушать его из верхнего динамика.
Тестирование локализации и интернетизации - тестирование с целью проверки адаптации ПО к любой культуре или особенностям языка другой страны.
Пример: Можно ли писать сообщения иероглифами (поддерживает ли кодировку)(локализация) или есть ли функция в мессенджере для оповещения о молитвенном времени (интернационализация).
Тестирование безопасности - тестирование направленное на проверку безопасности конфиденциальных данных и защиту от хакерских атак, вирусов и тд.
Пример: Отправить файл, зараженный вирусом и проверить, пропустит ли его мессенджер. Или встроить в картинку инъекцию.
Проверка удобства - тестирование направленное на удобство пользования и дизайна.
Пример: Проверить, удобно ли будет пользоваться одной рукой, не режет ли глаз цвета, не маленькая ли кнопка отправить и тд.
Нагрузочное тестирование - проводимое тестирование использования в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, и им пользуются 10 человек, отправляя сообщения и допустимые файлы допустимых размеров.
Стресс-тестирование - нагрузка, превышающая норму в несколько раз.
Пример: Сервер мессенджера рассчитан на 10 человек, а им одновременно пользуются 30 человек, активно отправляя сообщения, фото и файлы друг другу.
Тестирование стабильности - тестирование, направленное на продолжительное испытание в пределах нормы.
Пример: Сервер мессенджера рассчитан на 10 человек, им пользуются 10 человек в рамках стандартного использования в течении месяца (переписываются, отправляют картинки и тд).
Инсталляционное тестирование - тестирование, направленное на проверку установки, обновления и удаления приложения.
Пример: Скачать приложение, установить его, удалить, установить еще раз и после обновить.

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

Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.
То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.
Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.
Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
Регрессионное тестирование проводится:
- после появления нового билда (новой версии нашего продукта)
- тестирование того функционала в котором часто обнаруживаются дефекты
- плановое тестирование
- того функционала, который часто меняется в ходе разработки

26. Что такое Тест-дизайн?

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

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

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, при которой мы разделяем диапазон возможных вводимых значений на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на граничных значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

f-строки (очень удобно)

alexbrin — Thu, 07 Mar 2024 21:14:08 GMT

Код внутри скобок

Когда вы указываете перед стройкой f python воспринимает её как необычную строку и каждое содержимое фигурных скобок он будет воспринимать как выражение на языке программирования. В фигурных скобках вы можете писать свои какие-либо выражения и никто не запрещает вам воспользоваться математическими операциями.

Вы можете пользоваться всеми возможностями ваших объектов. В нашем случае переменная name является строкой и мы знаем что у каждой строки есть метод lower. Давайте мы применим метод lower делает все буквы строки маленькими.

В скобках вы можете вообще не использовать переменные. То есть вы можете просто написать здесь какие-либо числа и это выражение также посчитается и будет выведен его результат.

Внутри скобок вы можете также вызвать другие функции. Например, мы можем вызвать функцию abs() от отрицательного числа

Вывод переменных

С обозначением переменных

Начиная с версии Python 3.8 функционал f-строк был дополнен новой возможностью по выводу имён переменных и их значений. Посмотрите как теперь это можно сделать:

Вам достаточно указать название переменной и знак равно. Будет выведено автоматически и имя переменной и ее значение. При этом и знаки пробелов, если они указаны, будут учтены.

Формат вывода дробной части числа

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

Ответ простой - форматировать. F-строки поддерживают функционал форматирования. Мы указываем специальным образом после имени переменной сколько символов ожидаем увидеть.

Запись c:.3f говорит, что переменную c нужно представить в вещественном виде (это знак f) и отобразить три символа после запятой. Если у переменной c не хватает символов для трех знаков, проставятся нули. Если символов в избытке, произойдет округление до третьего символа после запятой.

Над целыми числами тоже можно так издеваться)

Формат вывода целых чисел

Пробелы перед числом (выравнивание)

При помощи f-строк мы можем влиять и на отображение целых чисел.

Запись n:7d говорит, что переменную n нужно представить в виде целого числа (это знак d ) и на отображение всего числа выделить 7 знаков. Если у переменной n не хватает разрядов до семи, то впереди отображения появятся знаки пробелов.

Выравнивание с помощью нулей (добавление в начало нулей)

Можно вместо пробелов добавить незначащие нули, для этого нужно подписать 0 перед количеством разрядов

Разделение разрядов числа (например, вместо 1000000 - 1_000_000)

Можно также влиять на знак разделителя между группами чисел, посмотрите пример ниже

Выравнивание

Существует несколько способов выравнивания переменных в f-строках. Различные варианты выравнивания следует:

< - Выравнивает выражение в фигурных скобках по левому краю. У строк такое поведение по умолчанию

> - Выравнивает выражение в фигурных скобках по правому краю. У чисел такое поведение по умолчанию

^ - Выравнивает выражение в фигурных скобках по центру

Ниже приведен пример использования выравнивания как для чисел, так и для строк.

Символы "|" используются в f-строке, чтобы помочь очертить интервал. Число после «:» указывает на количество символов в ширину.

По умолчанию символом заполнителем является пробел, но можно его заменить на другое значение

Практический пример выравнивания

Давайте с вами смоделируем чек покупки. Пример ниже

14.5 Создание запросов в ручную

alexbrin — Wed, 21 Feb 2024 16:15:56 GMT

Создаем первый тестовый сценарий

Сымитируем следующую деятельность пользователя:

1. Пользователь открыл Википедию для того, чтобы открыть какую либо статью.

2. Далее ему нужно нажать кнопку поиска либо ввести какие то данные в поле "Искать в Википедии". Но в нашей ситуации он нажал кнопку "Поиск".

3. Перешли на поисковую страницу с полем для запроса и фильтрами.

4. Пользователь вводит в поле поиска слово "Париж" и нажимает кнопку "Найти". Ему выдаются результаты поиска.

5. В результатах поиска ему нужно выбрать ту статью, которую он хочет почитать. Допустим, он хочет почитать про город Париж.

Мы обозначили тот тестовый сценарий, который мы выполнили.

Теперь запишем по запросам все шаги:

Jmeter - это не браузер, не Selenium. В процессе работы мы не обращаемся к браузеру, а работаем только с конечными точками (с ссылками). А на основании расположения запросов создаем сценарий.

Если запустить тест с 5 пользователями, то нарушается порядок прохождения тестов

13.4 Методика нагрузочного тестирования

alexbrin — Wed, 21 Feb 2024 14:55:56 GMT

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

Давайте более подробней пройдемся по каждому пункту:

1. Цели тестирования, их разделяют:

Технические цели – например, тестирование надежности, отказоустойчивости и т.д.

Бизнес цели – к примеру, изменение информационной инфраструктуры или системы, то есть проверка нового ПО и его функционала.

2. Объект тестирования – данный раздел включает в себя архитектуры системы, то есть ее характеристики, ее компоненты и взаимосвязь компонентов между собой.

3. Стратегия тестирования - он включает в себя описание проводимых испытаний для каждой цели тестирования.

Давайте рассмотрим пример:

Тестирование надежности

Тест надежности выполняется на уровне нагрузки:

1. Нагрузка системы в количестве 70-90 % от уровня найденной максимальной производительности.

2. При повторном тестировании и тестировании нового функционала нагружаем на 100-120% от пиковой производительности нашей системы. Что это значит, мы анализируем нагрузку, которая поступает на наш сервер в течении всей недели, отбираем к примеру день, когда у нас максимальная нагрузка, отбираем час, когда у нас максимальная нагрузка (например это 11 часов дня, в это время у нас самое большое количество пользователей на нашем сайте, они совершают максимальную нагрузку нашего сервера) мы берем либо этот час, либо среднее по всем часам, например, суммируем всю нагрузку с 11-12:00 и делим на 7. Это наш показатель, от которого мы отталкиваемся и нагружаем нашу систему на 100-120%, если система выдерживает данную нагрузку, значит и с остальной она справится.

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

И так по каждой цели тестирования, то есть данный раздел очень объемным.

Мы обязательно должны указать в данном разделе критерии успешного завершения нагрузочного тестирования являются:

1)выполнение всех запланированных тестов

2)получение данных с мониторинга

4. Тестовый стенд

Здесь указывается:

1)архитектура тестового стенда – описание самого стенда, описание смежных систем

2)требования к оборудованию тестового стенда, его характеристики

3)очень важны пункт – сравнение тестового и пользовательского, так как нам очень важно, чтобы они были равны

5. Моделирование нагрузки - описанием процессов, операций, которые проводят пользователи в нашей системе.

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

Так же здесь у нас указывается профиль нагрузки, где у нас идут данные за весь месяц 24 на 7.

6. Описание заглушек и эмуляторов, в которых мы описываем их характеристики и что они выполняют

7. Базы данных

В нем описываются характеристики БД, ее наполнение, то есть количество данных в ней

8. Мониторинг

Мониторинг необходим для сбора характеристик производительности компонент системы. В данном разделе описывается вспомогательное ПО для проведения мониторинга

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

13.3 Этапы нагрузочного тестирования

alexbrin — Wed, 21 Feb 2024 14:36:49 GMT

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

Основные этапы проведения нагрузочного тестирования:

Определение и постановка задач.
Подготовка тестового стенда и средства тестирования.
Подготовка тестового плана (методики НТ).
Настройка тестового стенда и вспомогательного ПО.
Проведение нагрузочных тестов.
Подготовка отчетов и анализ результатов тестирования.

1. Определение и постановка задачи

На данном этапе:

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

2. Подготовка тестового стенда и средств тестирования

На данном этапе:

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

3. Подготовка тестового плана или как его еще называют методики Нагрузочного Тестирования

На данном этапе:

Написание тест-кейсов.
Согласование сроков.
Согласование участников тестирования.
Частота проведения тестов.

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

4. Настройка тестового стенда и вспомогательного ПО

Окончательная настройка нашего стенда, вспомогательного ПО, подготовка эмуляторов и заглушек для нашей системы.

Заглушка – это часть нашей системы, которая всегда отвечает одинаково, то есть когда мы отправляем в нее запрос, она всегда отвечает однотипно.

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

5. Проведение нагрузочного тестирования

Дымовое тестирование: В первую очередь мы проводим smoke тестирование, то есть прогоняем небольшие тесты, для того чтоб проверить что наша система вообще работает и выполняет свою основную бизнес-логику. Это обязательное условие перед полноценным тестированием, это можно сравнить с разведкой обстановки.
Определение максимальной производительности системы: Определение максимальной производительности, то есть мы хотим узнать предельные способности нашей системы, этот показатель очень важен для нас и будет в дальнейшем использоваться и сравниваться с другими показателями нашей системы.
90% от максимальной производительности системы: Нам необходимо повторно произвести определение максимальной производительности, процентов 90 от предыдущего значения, для того, чтоб убедиться что мы получили верные данные.
Тестирование надежности.

6. Подготовка отчета и анализ результата тестирования

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

13.2 Когда необходимо проводить нагрузочное тестирование

alexbrin — Wed, 21 Feb 2024 13:01:07 GMT

Когда проводится нагрузочное тестирование:

1. Выпуск нового ПО - мы только выпустили наше программное обеспечение и мы хотим выяснить, соответствует ли оно заявленным требованиям или нет, проводим определение максимальной производительности, выявляем узкие места, стресс тестирование и осуществляем проверку отказоустойчивости;

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

3. Регрессионное тестирование или плановое тестирование - то есть тестирование, которое производится после разработки нового функционала или по плану( у вас есть определённое расписание, когда вы производите нагрузочное тестирование Вашего продукта);

4. Исследовательское - это тестирование когда мы хотим выяснить максимальные возможности нашей системы, то есть мы проводим определение максимальной производительности, нагружаем нашу систему в течении длительного времени, производим стрессовое тестирование и т.д.;

5. Смена технологий - когда наша система переходит с одной базы данных на другую, меняется оборудование и мощности. Мы нагружаем нашу систему и смотрим, чтоб она работала в соответствии с требованиями, предъявленными к ней;

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

13.1 Введение в Нагрузочное тестирование. Цели нагрузочного тестирова

alexbrin — Wed, 21 Feb 2024 12:44:58 GMT

От любой системы требуется быстро и правильно отвечать на запросы пользователей, то есть выполнять те команды и задачи, которые требует от нее пользователь. Например, выдавать результат поиска на поисковых сайтах, например Яндекс или Google, или отправка сообщения в социальных сетях и т.д.

Для чего нужно нагрузочное тестирование?

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

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

Для чего же необходимо производить нагрузочное тестирование, давайте разберем пример:

Все мы знаем про черную пятницу, это день скидок, когда мы можем купить товар с большой скидкой. Представим, что у нас есть интернет-магазин по продаже электроники, и для него норма производительности, скажем 1000 пользователей, одновременно находящихся на сайте и выполняющие определенные действия -регистрация, поиск товара, оформление товара, покупка.
Наступает черная пятница, и вместо 1000 человек, на нашем сайте одновременно находится 10000 человек, что же произойдет? Норма превышена в 10 раз и в лучшем случае сайт будет работать медленней, часть операций не будет проходить, а в худшем случае наш сервер вовсе выйдет из строя и хозяева данного ресурса понесут большие убытки.

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

Нагрузочное тестирование

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

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

Цели нагрузочного тестирования

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

2. Выявление проблемных участков или как их еще называют- «узких мест»;

3. Проверка стабильности (в некоторых источниках вы можете встретить название надежности) – длительная нагрузка нашей системы при нормальных условиях 70-80 % от максимума(который указан в требованиях и который должна выдерживать наша система);

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

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

5. Re-test, то есть проверка исправления ошибки - когда мы обнаружили проблемный участок в нашей системе, разработчики его поправили и мы производим повторную проверку;

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

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

7. Воспроизведение проблем промышленной среды - представим что на Проде, на нашем боевом сервере, обнаружилась ошибка и мы пытаемся ее воспроизвести на нашем тестовом стенде. Тестовый стенд всегда отличается от Прода, даже если установлена одна версия ПО. Если мы на Проде получили проблему, ее нужно постараться воспроизвести на тестовом стенде максимально похоже.

Работа над ошибками в коммитах

alexbrin — Mon, 19 Feb 2024 14:38:52 GMT

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

Например, в выводе команды git log --oneline умещается максимум 7272 первых символа сообщения, поэтому многие правила включают пункт: «Сообщение не должно быть длиннее 7272 символов».

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

Зачем вообще писать сообщения

У каждого коммита в Git есть сообщение — то, что передаётся после параметра -m. Например: git commit -m "Добавить урок про оформление сообщений коммитов".

Сообщения коммитов можно сравнить с надписями на коробках в кладовке. Если надписей нет, то нужную коробку будет сложно найти: придётся заглянуть в каждую, чтобы понять, что там. А если надписи есть, то нужная найдётся сразу.

Как и надпись на коробке, сообщение коммита должно помочь определить, что внутри. Например, надпись на коробке «всякое разное» не очень полезная. Сообщение коммита «небольшие исправления» тоже: непонятно, что было исправлено в таком коммите и зачем.

Есть общие рекомендации по тому, как правильно составить сообщение. Оно должно быть:

относительно коротким, чтобы его было легко прочитать;
информативным.

Вот пример полезного сообщения в репозитории новостного сайта: Исправление опечатки в заголовке главной страницы на хорватском. Такое сообщение даёт много информации:

Исправление опечатки значит, что исправлена ошибка, которая была допущена при наборе. Такое исправление не меняет смысл. То есть, например, главному редактору не нужно перепроверять этот заголовок.
На хорватском говорит о том, что переводчикам на другие языки этот коммит можно смело пропускать.
В заголовке главной страницы указывает, где произошли изменения. Если, например, кто-то зайдёт на сайт и ему не понравится новый заголовок, он легко найдёт по истории (git log) автора этого коммита и спросит у него, почему заголовок теперь такой.

Пример плохого сообщения для того же коммита: Исправлена опечатка. Это сообщение даёт мало информации. В такой коммит придётся «заглядывать» — разбираться, что именно поменялось и зачем.

Стили оформления

Все люди разные и у всех есть предпочтения — в том числе, как формулировать сообщения коммитов. Кто-то использует инфинитивы: Исправить сообщение об ошибке E123, кто-то — глаголы в прошедшем времени: Исправил…, кто-то — существительные: Исправление….

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

Чтобы упростить работу, команды или даже целые компании часто договариваются об определённом стиле (то есть о правилах) оформления сообщений коммитов.

Например, правила могут быть такие:

длина сообщения от 3030 до 7272 символов;
первое слово — глагол в инфинитиве («исправить», «дополнить», «добавить» и другие);
и так далее.

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

Корпоративный

Во многих компаниях применяется Jira — система для организации проектов и задач. У каждой задачи в Jira есть идентификатор из нескольких заглавных латинских букв и номера. Например, LGS-239 значит, что это 239239-я задача в проекте LGS (сокращение от англ. logistics — «логистика»).

В корпоративном стиле в начале сообщения обычно указывают Jira-ID, а после — текст сообщения.

$ git commit -m "LGS-239: Дополнить список пасхалок новыми числами"

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

Conventional Commits

Стандарт Conventional Commits (англ. «соглашение о коммитах») отличается качественной документацией и подробной проработкой. Он подходит для репозиториев с исходным кодом программ. Использовать его для других типов проектов (например, для перевода книги) было бы неудобно.Conventional Commits предлагает такой формат коммита: : <сообщение>. Первая часть type — это тип изменений. Таких типов достаточно много. Вот два примера:

feat (сокращение от англ. feature) — для новой функциональности;
fix (от англ. «исправить», «устранить») — для исправленных ошибок.

Более подробный список можно увидеть на сайте с описанием этого стиля.

Например, сообщение может быть таким.

git commit -m "feat: добавить подсчёт суммы заказов за неделю"

GitHub-стиль

GitHub можно использовать не только для хранения файлов проекта, но и для ведения списка задач (англ. issue) этого проекта. Если коммит «закрывает» или «решает» какую-то задачу, то в его сообщении удобно указывать ссылку на неё. Для этого в любом месте сообщения нужно указать #<номер задачи>. Например, вот так.

$ git commit -m "Исправить #334, добавить график температуры"

В таком случае GitHub свяжет коммит и задачу.

Как исправить коммит

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

В таком случае можно внести правки в уже сделанный коммит с помощью опции --amend (от англ. amend — «исправить», «дополнить») у команды commit: git commit --amend. Разберём, как она работает.

💡 Важно: опция --amend работает только с последним коммитом (HEAD). Для исправления более ранних коммитов есть другие команды. Мы рассмотрим их в следующих модулях курса.

Подготавливаем репозиторий

Создайте тренировочный репозиторий для отработки команды.

$ mkdir ~/dev/commit-amend-fun
$ cd ~/dev/commit-amend-fun
$ git init
# пропустим вывод git init

Дополнить коммит новыми файлами — `git commit --amend --no-edit`

Представьте, что делаете небольшой сайт и для этого создали файл-страницу main.html, а также файл со стилями common.css.

$ touch main.html 
$ touch common.css 
# дальше отредактировали оба файла

В какой-то момент вы забыли о файле common.css и добавили в коммит только main.html.

$ git add main.html 
$ git commit -m "Добавить главную страницу" 
$ git log --oneline 
777fec3 Добавить главную страницу

Файл common.css так и остался «висеть» в untracked. В этом легко убедиться, если вызвать git status.

Дополните последний коммит забытым файлом common.css с помощью опции --amend.

$ git add common.css 
# добавили файл common.css в список на коммит как обычно 

# но вместо команды commit -m '...' 
# будет: 
$ git commit --amend --no-edit 

$ git log --oneline 
8340eb2 Добавить главную страницу 
# коммит в истории всё ещё один (но у него новый хеш)

С опцией --amend команда commit не создаст новый коммит, а дополнит последний, просто добавив в него файл common.css. При этом хеш последнего коммита изменится, потому что изменился список файлов в коммите.Обратите внимание на опцию --no-edit. Она сообщает команде commit, что сообщение коммита нужно оставить как было.

Точно так же можно добавить не новый файл, а дополнительные изменения в уже добавленном в коммит файле.

# ещё раз отредактировали main.html

$ git add main.html # добавили в список на коммит
$ git commit --amend --no-edit

💡 Что же выбрать: новый коммит или --amend?
В нашем примере вместо изменения последнего коммита можно было также выполнить новый коммит с одним файлом common.css. Кажется, что так проще, но добавить изменения в уже существующий коммит может быть правильнее.
Например, через месяц кто-то захочет просмотреть историю изменений. Намного проще понять, что изменилось, если оба файла находятся в одном коммите. Иначе коммит со второй порцией изменений придётся искать.

Изменить сообщение коммита — `git commit --amend -m "Новое сообщение"`

Может быть и так, что добавлять новые файлы в коммит не нужно, зато понадобилось изменить сообщение.

Допустим, хочется заменить сообщение Добавить главную страницу на Добавить главную страницу и стили. Сделать это можно через commit --amend с флагом -m.

$ git commit --amend -m "Добавить главную страницу и стили"
$ git log --oneline
a31fa24 Добавить главную страницу и стили

Хеш коммита снова поменялся, потому что изменились сообщение и время коммита. При этом файлы в коммите остались те же: main.html и common.css.

Как откатиться назад, если «всё сломалось»

На разных этапах работы с Git могут происходить похожие ситуации:

В список на коммит попал лишний файл (например, временный). Нужно «вынуть» его из списка.
Последние несколько коммитов ошибочные: например, сделали не то, что было нужно, или нарушили логику. Хочется «откатить» сразу несколько коммитов, вернуть «как было вчера».
Случайно изменился файл, который вообще не должен был меняться. Например, вы открыли не тот файл в редакторе и начали его исправлять.

В этом уроке рассмотрим такие случаи и научим вас «откатывать» нежелательные изменения.

Выполнить unstage изменений — `git restore --staged`

Допустим, вы создали или изменили какой-то файл и добавили его в список «на коммит» (staging area) с помощью git add, но потом передумали включать его туда. Убрать файл из staging поможет команда git restore --staged (от англ. restore — «восстановить»).

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

$ touch example.txt # создали ненужный файл
$ git add example.txt # добавили его в staged

$ git status # проверили статус
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        new file:   example.txt

$ git restore --staged example.txt
$ git status # проверили статус

Untracked files:
  (use "git add ..." to include in what will be committed)
        example.txt

no changes added to commit (use "git add" and/or "git commit -a")
# файл example.txt из staged вернулся обратно в untracked

Вызов git restore --staged example.txt перевёл example.txt из staged обратно в untracked.

Чтобы «сбросить» все файлы из staged обратно в untracked/modified, можно воспользоваться командой git restore --staged .: она сбросит всю текущую папку (.).

«Откатить» коммит — `git reset --hard`

Иногда нужно «откатить» то, что уже было закоммичено, то есть вернуть состояние репозитория к более раннему. Для этого используют команду git reset --hard (от англ. reset — «сброс», «обнуление» и hard — «суровый»).

$ git log --oneline # хеш можно найти в истории
7b972f5 (HEAD -> master) style: добавить комментарии, расставить отступы
b576d89 feat: добавить массив Expenses и цикл для добавления трат # вот сюда и вернёмся
4b58962 refactor: разделить analyzeExpenses() на countSum() и saveExpenses()

$ git reset --hard b576d89
# теперь мы на этом коммите
HEAD is now at b576d89 feat: добавить массив Expenses и цикл для добавления трат

Теперь коммит b576d89 стал последним: вся дальнейшая разработка будет вестись от него. Файл также вернулся к тому состоянию, в котором был в момент этого коммита. А коммит 7b972f5 Git просто удалил. Это можно проверить, снова запросив лог. Он покажет следующее.

$ git log --oneline
b576d89 (HEAD -> master) feat: добавить массив Expenses и цикл для добавления трат
4b58962 refactor: разделить analyzeExpenses() на countSum() и saveExpenses()

Вот так схематично выглядит весь процесс «отката» с помощью git reset --hard .

«Откатить» изменения, которые не попали ни в staging, ни в коммит, — `git restore`

Может быть так, что вы случайно изменили файл, который не планировали. Теперь он отображается в Changes not staged for commit (modified). Чтобы вернуть всё «как было», можно выполнить команду git restore .

# случайно изменили файл example.txt
$ git status
On branch main
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
          modified:   example.txt

$ git restore example.txt
$ git status
On branch main
nothing to commit, working tree clean

Изменения в файле «откатятся» до последней версии, которая была сохранена через git commit или git add.

Вот о чём мы рассказали:

Команда git restore --staged переведёт файл из staged обратно в modified или untracked.
Команда git reset --hard «откатит» историю до коммита с хешем . Более поздние коммиты потеряются!
Команда git restore «откатит» изменения в файле до последней сохранённой (в коммите или в staging) версии.