10 базовых запросов в GIT. Про основы GIT для начинающего тестировщика. 2023
GIT, GIT куда же без него? На нем строится вся организация разработки по сути. Нет гита и беда. Шутка) Нужная вещь, которую необходимо знать, потому что может пригодиться в будущем, например при внесении новых схем валидации для клиента и других задач.
❤Поставь лайк и дочитай до конца.
Далее ты узнаешь про:
Про основы GIT.
GIT — это система контроля версий, которая позволяет отслеживать изменения в исходном коде программного обеспечения и сотрудничать с другими разработчиками. Вот некоторые основы GIT:
- Репозиторий: GIT хранит ваш код в репозитории, который может быть удаленным или локальным. Репозиторий содержит историю изменений вашего проекта.
- Коммиты: Коммиты в GIT являются фиксациями изменений в коде. Каждый коммит имеет уникальный идентификатор и содержит сообщение, описывающее внесенные изменения.
- Ветвление: В GIT вы можете создавать отдельные ветки для различных функций или задач, которые могут быть объединены позже.
- Объединение: Объединение — это процесс объединения двух или более ветвей в одну.
- Взаимодействие с удаленным репозиторием: Вы можете работать с удаленным репозиторием, чтобы совместно работать с другими разработчиками или размещать свой код в общедоступном месте.
- Ветвление и слияние в удаленных репозиториях: В GIT вы можете создавать ветви и объединять их в удаленном репозитории, чтобы совместно работать с другими разработчиками.
- Хуки: Хуки — это пользовательские сценарии, которые выполняются автоматически при определенных действиях в GIT, например, при создании коммита или объединении веток.
GIT имеет много возможностей и настроек, и это только некоторые из основных функций.
Вот несколько основных команд в Git, которые могут тебе помочь:
- git init — инициализирует новый репозиторий Git в текущей директории.
- git clone [url] — клонирует репозиторий из удаленного хранилища в локальный каталог.
- git add [file] — добавляет изменения в указанный файл в индекс.
- git commit -m «commit message» — сохраняет индексированные изменения в новый коммит в локальном репозитории.
- git status — показывает текущее состояние репозитория, включая неотслеживаемые файлы, изменения в индексе и т. д.
- git push — отправляет изменения в удаленный репозиторий.
- git pull — получает последние изменения из удаленного репозитория и объединяет их с локальными изменениями.
- git branch — показывает список всех локальных веток.
- git checkout [branch] — переключается на указанную ветку.
- git merge [branch] — объединяет указанную ветку с текущей веткой.
Это только несколько базовых команд, и Git имеет много других полезных команд и функций. Для решения мелких задач необходимо знать git и как минимум для понимания, как работает система разработки. Также если решите стать автотестировщиком, то каждый день будете с этим сталкиваться.
Зачем тестировщику Git?
Умение работать с Git — обязательное требование во многих вакансиях для тестировщиков.
Зачем он нужен ручному тестировщику? И нужен ли?
Зачем нужен автоматизатору?
- Вопрос задан более трёх лет назад
- 7414 просмотров
2 комментария
Простой 2 комментария
Чтобы пользоваться им по назначению. В 21 веке — удивительно, что есть ещё люди которые работают с кодом но не знают про Git
Вы не поверите, но не все используют гит. Про него можно знать, но не использовать.
По вопросу:
Как минимум для того, что-бы попытаться найти причину появления той или иной поломки. В зависимости от фирмы, тестировщики могут предлагать решения и нужны как минимум базовые знания для создания ветки/коммита
Решения вопроса 3
Еда — это святое
Если что-то работало в одной версии и перестало в другой — можно сделать бисекцию и проверить, в каком коммите оно отвалилось
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Айти или не айти?
— можешь составить список тестов и отслеживать его выполнение;
— можешь с разных устройств выполнять тесты кода, расположенного на удаленном репозитории git;
— возвращаться к работающей версии тестов;
— git популярен и нужен, смирись и выучи, это не сложно.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ерлан Ибраев @mad_nazgul
Как минимум для хранения различных настроек для приложения.
А так сейчас идет тенденция к автоматизации тестирования и отказ от ручного тестирования.
Т.е. тестировщики становятся программистами.
Поэтому без знания GIT никуда 🙂
Ответ написан более трёх лет назад
Чего то тенденции не наблюдаю даже спустя вот трёх лет. Да и полностью отказаться от мануального тестирования невозможно, факт. Все тестами не покрыть как минимум. А так QA и мануальщики в любом случае будут жить
Ответы на вопрос 2
Сергей @sabramovskikh
Как минимум хранить код тестов в гите
Ответ написан более трёх лет назад
Комментировать
Нравится 7 Комментировать
Все вышеперечисленные ответы годятся для Автоматизаторов, но для чего мануальщику git так никто и не ответил, и когда это автотесты полностью покрывали мануал тестирование, это два разных подхода к тестированию.
Ответ написан более трёх лет назад
Нравится 1 1 комментарий
Сергей Кузнецов @sergey-kuznetsov Куратор тега Git
Даже ручному тестировщику надо знать Git. Как минимум чтобы уметь вытащить из репозитория предмет тестирования.
double-trouble2 / QA Engineer
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address.
Learn more about clone URLs
Тестировщик
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| QA engineer/тестировщик |
| SCRUM |
| SCRUM-митинги |
| Делать по ходу спринта несколько версий сборок |
| у каждого члена команды не может одновременно находиться в работе, например, более двух задач, а общее число задач в тесте и готовых для проверки не может превышать (тоже например) шести в каждом случае, если в команде три разработчика. |
| Persistency |
| Баг-трекер |
| Stakeholders(тестовой группы заказчика ) |
| Test Management — планирование работ |
| Test Design — проектирование тестов |
| Test Execution — выполнение тестирования |
| Test Analysis — анализ полученных результатов |
| Verification — Верификация, это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. |
| Validation — Валидация, это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1]. |
| Test Plan – План Тестирования, это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. |
| Bug Report — Баг/Дефект Репорт |
| Виды Тестирования ПО (можно условно разделить на следующие группы) |
| 1. Функциональные |
| 2. Нефункциональные |
| 3. Связанные с изменениями |
| Тестировщик осуществляет контроль качества продукта после его разработки, в то время как задача QA тестера — обеспечение качества продукции на всех этапах разработки, выпуска и эксплуатации ПО. |
| Главные должностные обязанности тестировщика: |
| Контроль качества разрабатываемых продуктов. |
| • Выявление и анализ ошибок и проблем, возникающих у пользователей при работе с программными продуктами. |
| • Разработка автотестов и их регулярный прогон. |
| • Разработка сценариев тестирования. |
| • Документирование найденных дефектов. |
| Также должность тестировщика может предполагать составление технической документации на русском и иностранном (чаще английском) языках. |
| Требования к тестировщику |
| Главные требования к тестировщику: |
| • Опыт организации и проведения различных видов тестирования. |
| • Знание языков программирования. |
| • Знание инструментов и библиотек для автотестирования. |
| • Опыт написания автотестов. |
| • Высшее образование. |
| • Аналитические способности. |
| Дополнительные требования: |
| • Умение тестировать веб-приложения. |
| • Знание мобильных платформ (iOS, Android). |
| • Знание английского языка на уровне, достаточном для чтения и написания технических текстов. |
| Методика тестирования |
| Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, приемочное тестирование, и тестирование системы. Программное обеспечение подвергается этим испытаниям в определенном порядке. |
| 1) Модульное тестирование |
| 2) Интеграционное тестирование |
| 3) Системное тестирование |
| 4) Приемочные испытания |
| Модульное тестирование |
| В первую очередь проводится модульный тест. Как подсказывает название, это метод испытания на объектном уровне. Отдельные программные компоненты тестируются на наличие ошибок. Для этого теста требуется точное знание программы и каждого установленного модуля. Таким образом, эта проверка осуществляется программистами, а не тестерами. Для этого создаются тест-коды, которые проверяют, ведет ли программное обеспечение себя так, как задумывалось. |
| Интеграционное тестирование |
| Отдельные модули, которые уже были подвергнуты модульному тестированию, интегрируются друг с другом, и проверяются на наличие неисправностей. Такой тип тестирования в первую очередь выявляет ошибки интерфейса. Интеграционное тестирование можно осуществлять с помощью подхода «сверху вниз», следуя архитектурному сооружению системы. Другим подходом является подход «снизу вверх», который осуществляется из нижней части потока управления. |
| Системное тестирование |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Home
Для тестировщика, который только начал создавать тест-автоматизацию, использование системы контроля версий вроде Git может показаться опасным и запутанным. Однако способность получить свежайший код, обновить его и создать запрос на включение кода – это очень важно для любого командного проекта? Сегодня я расскажу об основах Git.
Что такое Git?
Git – это система контроля версий. Система контроля версий – это система, позволяющая группе людей совместно работать над кодом, не рискуя случайно перезаписать чужую работу. Она также позволяет группе отслеживать, кто менял код и когда это произошло, и поэтому можно легко докопаться до источника проблемы.
Зачем нужен Git?
Представьте себе редактирование файла без использования систеым контроля версий. Допустим, у вас есть рецепт шоколадного пирожного. Вы отправляете рецепт своему другу, и он решает изменить в нем количество какао. Когда он вносит свое изменение – оно отражается только в его версии файла, а не в вашей. Ваши файлы теперь различаются. Если вы внесете изменение количества ванили, расхождений между вашими версиями станет еще больше.
Можно легко увидеть, что для программного кода это недопустимо! В системе контроля версий есть одна «мастер-версия» – одобренная версия кода. Эта мастер-версия живет в GitHub (или другом сервисе контроля версий), и может быть «получена» любым пользователем. Если кто-то хочет внести изменения в код, они «вытягивают» мастер-версию кода, создают «ветку» – копию мастер-версии, вносят изменения в ветку, пушат ветку назад на GitHub, а затем создают запрос на включение кода – просьбу к кому-то провести ревью кода и слить его с веткой мастера.
Запутались? Не волнуйтесь, на примере все станет намного понятнее. Предположим, что у нас есть репозиторий исходного кода по имени «Гостевая книга думающего тестировщика». Давайте посмотрим, что произойдет, если Прюнелла Прюнвип хочет добавить свое имя в гостевую книгу.
Инструкции предполагают, что Прюнелла уже установила Git на свою машину, и создала учетную запись в GitHub.
Шаг первый: Прюнелла клонирует репозиторий исходного кода
Это часто называется «клонированием репозитория» или «выкачкой репозитория». Прюнелла делает это, переходя по URL в GitHub с исходным кодом, и нажимая на зеленую кнопку » Clone or download». Появляется выпадающее меню с URL, необходимым для клонирования кода. Она нажимает маленькую кнопку буфера обмена справа от URL, чтобы копировать его.
Затем Прюнелла открывает командную строку и переходит в папку, куда планирует положить исходный код. Оказавшись там, она вводит команду git clone и вставляет URL после этой команды. Репозиторий копируется из GitHub в новую папку.
Теперь, когда репозиторий находится в папке на ее машине, она может открыть эту папку в диспетчере файлов и посмотреть, что в ней находится. Она видит единственный текстовый файл «guestBook.txt». В нем написано следующее:
«Кристин Джеквони была здесь 11 мая 2019 года».
Шаг второй: Прюнелла создает новую ветку и добавляет в нее свои изменения
Прежде чем вносить какие-либо изменения в guestBook.txt, Прюнелла должна создать новую ветку и переключиться на нее. В командной строке она переходит в новую папку, клонированную ранее, вводя
Она может проверить, что она в мастер-ветке, введя команду git status – она получит ответ вроде этого:
On branch master.
Теперь она может создать новую ветку и переключиться на нее, вводя git checkout -b NewEntry. Команда «-b» говорит Git, что нужно создать новую ветку. «NewEntry» – это имя ветки, выбранное Прюнеллой. А команда checkout заставляет Git переключиться на новую ветку.
Если на этом этапе Прюнелла введет git status, она получит ответ «On branch NewEntry».
Теперь, когда Прюнелла находится в правильной ветке, она внесет изменения в файл guestBook.txt, добавив в него одну строчку. Теперь он выглядит так:
«Кристин Джеквони была здесь 11 мая 2019 года.
Прюнелла Прюнвип была здесь 13 мая 2019 года».
Шаг 3: Прюнелла коммитит свои изменения и пушит их в GitHub
Теперь, когда Прюнелла внесла нужные изменения, ей нужно закоммитить и запушить его. Для начала она может прогнать git status, получая следующий ответ:
On branch NewEntry
Он говорит о том, что файл guestBook.txt был изменен. Затем Прюнелле нужно добавить файл в коммит, введя git add guestBook.txt. Теперь, если она введет git status, она увидит ответ:
On branch NewEntry
Changes to be committed:
Затем Прюнелла коммитит свое изменения, вводя git commit -m «Adding a new entry». –m в этой команде означает «message», сообщение. Текст «Adding a new entry» – это сообщение, которое она добавляет, чтобы объяснить, что именно она коммитит. Командная строка ответит количеством файлов и строчек, которые были изменены.
Как только изменение закоммичено, Прюнелла может пушить его в репозиторий GitHub, вводя git push origin NewEntry. Значение NewEntry поясняет, что код должен попасть в ветку NewEntry, которая еще не существует в репозитории – по этой команде она будет создана. Origin относится к репозиторию GitHub (его также называют «удаленным»). Командная строка ответит несколькими строчками, последней из которых будет
* [new branch] NewEntry -> NewEntry
Эта строка показывает, что в оригинальном репозитории создана новая ветка NewEntry, скопированная с локальной ветки, созданной Прюнеллой, которая тоже называется NewEntry.
Шаг 4: Прюнелла создает запрос на включение кода (пулл-реквест) в GitHub
Теперь, когда новая ветка попала в GitHub, Прюнелла может создать пулл-запрос, чтобы попросить о слиянии своих изменений с мастер-веткой. Она делает это, перейдя в репозиторий GitHub и кликнув на кнопку «New Pull Request». Это перемещает ее на страницу «Compare». Она убеждается, что в левой части сравнения находится мастер-ветка, а затем выбирает ветку NewEntry из выпадающего меню. Она может видеть, как изменился файл guestBook.txt – новая добавленная строчка подсвечена зеленым, демонстрируя разницу между двумя файлами (если бы она что-то удалила, удаленная строка подсвечивалась бы красным). И, наконец, она нажимает на кнопку «Create Pull Request».
Шаг 5. Пулл-реквест Прюнеллы одобрен и объединен
Финальный шаг в процессе изменения файлов – это ревью изменения, его одобрение и слияние, которое проводит хозяин репозитория или члены команды, имеющие права на одобрение пулл-реквеста. Теперь, если Прюнелла переключится на мастер-ветку, введя git checkout master, выкачает изменения (git pull origin master) и посмотрит на файл guestBook.txt, она увидит, что в него добавлена новая запись:
«Кристин Джеквони была здесь 11 мая 2019 года.
Прюнелла Прюнвип была здесь 13 мая 2019 года».
Вот и все! В следующий раз я расскажу о полезных для Git штуках и фокусах, но этих шагов должно быть достаточно для коммита вашего собственного кода в репозиторий команды.