Перейти к содержимому

Ole325

Регистрация: 07 ноя 2019
Offline Активность: 29 авг 2023 08:02
-----

#179031 Язык программирования для тестировщика

Написано Ole325 15 марта 2021 - 12:22

Если задача через пол-года уметь читать и чуть-чуть понимать код, то нужно выбирать именно то, что будет использоваться и тут варианты от Java до C#. Может "повезти" и с С++

 

Если задача программировать, то начинать с алгоритмов не обязательно с привязкой к языку, с нуля и может даже пригодиться потом это python. А так хоть ANSI C по книжке Кернигана и Ритчи. Язык программирования это инструмент, и важно что мы делаем.

 

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


  • 1


#179026 В чем разница между этими тестами ?

Написано Ole325 15 марта 2021 - 11:53

Интересные ответы, а тут портал нацелен на научить/подсказать, или на развитие усердности?

 

 

> End to End тест

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

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

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

 

> Тест критического пути

Один из случаев End to End тестирования, которые пользователи/клиенты выполняют чаще всего.

Например, есть разные способы оплаты, включая оплату картой, но известно, что 95% клиентов выбирает в данном магазине PayPal

 

Тестирование от входа до покупки с оплатой картой, это End to End сценарий

А вот от входа до покупки с оплатой PayPal это тестирование критического пути

 

> Smoke тестирование

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

 

>Системное тестирование

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

Из вики

Систе́мное тести́рование програ́ммного обеспече́ния — это тестирование программного обеспечения (ПО), выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям.

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

 

Все виды: Тест критического пути,  End to End тест,  Smoke тестирование можно по охвату объекта отнести к системному.


  • 1


#177556 Как сделать последовательную автоматизация UI, API, БД

Написано Ole325 20 сентября 2020 - 15:27

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

 

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

 

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

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

 

Немного про приложения десктоп.

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

Если инсталятор не поддерживает салйнт установку, то дешево и сердито - AutoIT, даже бесплатно.

 

Про системы GUI автоматизации, рассматривали testcomplete, ranorex studio и Squish froglogic. Разработчики топили за Squish, т.к. есть проект где Unix и win. 

Мое ИМХО по продуктам:

Squish - из режима записи получаем код автотеста, кто не кодил тяжко, нельзя ткнуть в строку и увидеть скриншот элемента. 

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

Так же можно брать данные хоть с excel, где каждая строчка это отдельный прогон теста.

testcomplete - во многом схож с ranorex, но с нашими приложениями на Delphi 7 справляется хуже, вообще такое старье сложно тестировать автотестами, часто это просто картинка.

Еще важно на каком языке скрипты, если все знают С++, то лучше testcomplete, Ranorex поддерживает VB и C#.

В результате купили Ranorex, еще летом на акцию попали две лицензии по цене одной. Цена конечно не маленькая.

 

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

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

 

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

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

 

Пример не правильных:

1. ставим приложение;

2. создаем БД;

3. наполняем БД в UI;

4. проверяем работу базы.

Любая ошибка, и мы лишь знаем что все плохо на этапе Х, а что работает не известно. По этой причине

 

Альтернативный вариант:

тест 1

скачать приложение.

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

 

тест 2

скачать приложение, поставить через сайлент режим, либо вообще копированием файлов с TC (на случай если сломался инсталятор)

создать БД

 

тест 3

поднимаем готовую БД из бекапа и с ней работаем.

 

и т.д.

 

Удачных вам pass


  • 1