Автоматизированное тестирование

Программирование
#1

Привет. Может, кто-то делал для себя, может кто-то работает тестером-автоматизатором или знает таких. Че-т не совсем понимаю эту шнягу.

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

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

Ну и главный вопрос: что это за зоопарк JUnit, TestNG, NUnit, Selenium, TOSCA Testsuite, UniTESK. Да, в вики написано очень в общем. Но я лично своими глазоньками видела, как моя соседка писала тесты для джава-приложения в той же ИДЕ, что и само приложение. Или эти штуки помогают быстрее/понятнее писать? Или зачем они вообще?

1 лайк
#2

Куда ж без него )
В вебе почти во всех нормальных проектах есть. Но часто без всяких Селениумов, просто через HTTP API (выполнил запрос, проверил результат или содержимое БД), или вызов функций если это что-то типа библиотеки.

Вот хорошая статья:

Зависит от проекта, языка. В C++, .NET обычно отдельный проект.
Приватные методы обычно не надо тестить, на то они и приватные.

Обычно он сам и собирает, и тесты, лингеры прогоняет при пуше в Гит репозиторий. (или другая Continous Integration система, я например Дженкинсом почти не пользовался, Travis, GitHub Actions)
Но это больше для уверенности что всё ок, или чтобы прогонять на разных ОС/компиляторах, или деплоить куда-то если всё успешно. Обычно разработчики всегда и у себя их запускают из ИДЕ и т.п.

Первые два примерно одно и то же с немного разными фичами/удобствами (второй не пробовал), а NUnit для .NET, а не Джавы.

Обычно разработчики берут просто любую xUnit-библиотеку для своего ЯП, может быть еще что-нибудь типа Faker для генерации данных, что-нибудь про Mock’и (Mockito, …) если нужно.
В конце списка хз что это, ни разу не пробовал, видимо для случаев когда сильно загоняются по автотестам, берут отдельных писателей тестов и т.д.

Для тестов с помощью браузера, автоматизации браузера.
Например, открыть сайт, нажать кнопку (по CSS или XPath селектору) и проверить что на странице есть что-то.

1 лайк
Автоматизированное функциональное тестирование WEB-сайтов
Что можно написать в этой задаче по этим под-главам курсовой?
Шифр Цезаря, нужна помощь
Re: Для каких целей использовать JavaScript, а для каких PHP? PHP vs SPA vs статические сайты
Как в Awesomium повесить event на каждый клик на ссылку?
Изучение программирования, как учиться, искать работу, и прочие полезные материалы
Ключевые слова тестирования
#3

Спасибо, теперь стало понятнее.

Я человек каменного века, все по старинке: ручками, глазками, дебаггером.

#4

У всех разные подходы.

Есть проект bin, scr, lib создаёте папку tests где и создаете новый тестовый проект.
В основном проекте весь код переносите в отдельный модуль, что бы его можно было подключить в тесте.

JUnit, TestNG, NUnit, TOSCA Testsuite, UniTESK

Это фреймворки для вывода xml с результатами. Потом результаты можно красиво отобразить. Плюс навести красоту с оформлением тестового кода.

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

тогда как он вызывает всякие приватные методы основного) или прям в том же (хотя вопрос тот же

В книге искусство автономного тестирования правят основной проект вводят прослойки. Через них и вытаскивают приватные поля. А тесты в папке с тестами.
Ошероув Рой.-Искусство автономного тестирования с примерами на С_(2014)

Юнит тест должны писать программисты. Тестировщики настраивают систему тестирования. И пишут тесты более высокого уровня.

image
image719×601 44.1 KB

Никто не делает 100% покрытие. Потому что переделывать тесты долго писать ещё дольше. А ошибки в них тоже хватает. Да и время сборки могут увеличивать с минут до часов. При этом все они положительные и не имеют смысла.

К примеру wine использует тесты, что-то похожее на TDD и дымовые-тесты. И раз в год убирают стабильные тесты.

#5

Спасибо, стало еще понятнее.

Да, меня интересует вопрос и с точки зрения тестировщика. Они какие тесты пишут?

#6

По-разному бывает.

На текущей работе Юнит и интеграция - на разработчиках (пишут по ТДД)
ЮАй и Акцептанс - на тестировщиках
Запуск тестов - на ДевОпс

На предыдущей работе я был один тестировщик и писал всю пирамиду от Unit-тестов до UI и Acceptance + встраивание запуска тестов в Дженкинс

Тесты более высокого уровня можно писать, используя, например, BDD (Cucumber для Java, SpecFlow для Net) - но нужно учитывать, что это дополнительный слой в архитектуре тестов, который тоже нужно поддерживать в актуальном состоянии.
Я предпочитаю этот подход выносить как раз в те 10% наверху пирамиды - чтобы любой менеджер или тестер, незнакомый с автоматизацией, мог кейсы править. Ну и 10% от всего объёма - это имхо достаточно оптимальный вариант недорогой поддержки автотестов.

#7

Не уверен, что все они именно XML генерируют. Скорее фреймворки для упрощения написания и запуска тестов )

Вообще с точки зрения юзера (разработчика) запуск обычно выглядит как просто вывод в консоль типа такого:

> phpunit
PHPUnit 7.5.20 by Sebastian Bergmann and contributors.

..............................                                    30 / 30 (100%)

Time: 1.13 seconds, Memory: 14.00 MB

OK (30 tests, 44 assertions)

> phpunit
PHPUnit 7.5.20 by Sebastian Bergmann and contributors.

...................F...........                                   31 / 31 (100%)

Time: 1.57 seconds, Memory: 18.00 MB

There was 1 failure:

1) .....SomeClassTest::testDiff with data set #5 (
array('not_monitored_setting' => 8, 'setting_1' => 123, 'setting_2' => 'qwe'), 
array('not_monitored_setting' => 42, 'setting_1' => 456, 'setting_2' => 'asd'), 
array('setting_1', 'setting_2')
)
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'setting_1'
+    0 => 'not_monitored_setting'
     1 => 'setting_2'
 )
.../tests/php/Unit/SomeClassTest.php:69

FAILURES!
Tests: 31, Assertions: 106, Failures: 1.

Или аналогично в IDE
https://www.jetbrains.com/help/phpstorm/using-phpunit-framework.html#phpunit_monitor_test_results

image
image1434×458 29.3 KB

Еще IDE и прочие штуки могут показывать Coverage: какие строки кода выполнились во время теста, % и в некоторых IDE прямо в файле с кодом пометка цветом.
https://blog.jetbrains.com/phpstorm/2012/02/new-in-4-0-code-coverage-for-phpunit/
image

Рекомендация про 70% юнит тестов спорная, хотя зависит от определения.
Часто лучше больше интеграционных (то есть то, что между юнит и е2е) тестов, меньше юнит.

Ссылка по ссылке из первого ответа:

Те, что обычно называются acceptance или end-to-end (e2e).
Для веба обычно через всякие Селениумы и обертки над ним.

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

У них там еще всякие слова типа BDD (не TDD, это у разработчиков) мелькают.

#8

Эм. Я же пирамидку тестирования привёл. accepting - приёмосдаточное тестирование. То что указано в техническом задании всё тестируем. Эти тесты пишут тестировщик.

Я больше теоретик. Написание начинается с составления тестового плана, на какие вопросы надо ответить дано в статье

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

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Так же часто выделяют, что основное что тестируется это интерфейс пользователя. Проверка реакции на кнопки.

Как профессионал Вы наверно уже знаете чего стоит написание фронт энда. И как это делается ручками. К примеру форма регистрации пользователя или ввод IP.

  • Вы должны проверить что старый IP показывается.
  • Валидация IP адреса. Что API при приеме строки с IP-адресом фильтрует и отбрасывает всё что не соответствует шаблону.
  • Убедиться что IP применяется
  • Что IP сохраняется в конфиге.
  • Что работает восстановление в случае отсутствия подключения в 60 секунд.
  • То что IP применяется на нужном интерфейсе и не перескакивает интерфейса на интерфейс.
  • что шлюз по умолчанию присвоен одному интерфейсу.

Всё это можно сделать через тестирование интерфейса. Это автоматизированные тесты а есть ещё и автоматические.


Через API для слабо видящих MSAA можно получить структуру приложения в том числе и для браузеров(там надо включить). Получив координаты кнопок их названия и дополнительные данные можно понажимать на все кнопки и проверить еcть реакция или нет. Для всего этого есть библиотеки(фреймворки).

Смысла в использовании MSAA я не вижу так как если вы пишите тестовое приложение то у вас в раза будет больше возможностей. А вот идея генерация скриптов на основе SpecFlow мне понравилась.

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

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

Ответ прост интеграционное тестирование.

#9

Наткнулся на еще две свежие статьи с похожими идеями:

В первой еще одна забавная иллюстрация не интеграционных тестов:

А в комментах на хабре ко второй — очередной пример того, что многие люди называют все автоматические тесты “юнит-тестами” (видимо это идет от названий библиотек типа PHPUnit, которые несмотря на название используются для разных видов тестов).
Огромная ветка с заплюсованным первым комментом и как минимум одним “подписавшимся под каждым словом”, где автор коммента не знает что такое юнит-тесты, и в итоге оказывается пишет не их, но бросился их защищать :revolutionparrot: