Язык, чтобы учиться перемещаться из ручного тестирования к автоматизировал/программировал [закрытый]

Что касается «промышленного преимущества», это зависит от того, что вы под этим подразумеваете.

Для крупных компаний широко используется QTP. На самом деле с QTP нужно изучать не язык, а сам инструмент. Для меня преодолеть специфику инструмента было труднее, чем изучать VBscript. Если вы думаете о тестировании производительности, то, вероятно, вам подойдет PerformanceCenter. Здесь у вас C как язык, но опять же, здесь больше проблем с инструментом, чем с языком. В некоторых компаниях есть стек от IBM, поэтому в игру вступает программное обеспечение Rational (FunctionalTester, Robot, PerformanceTester). Также необходимо преодолеть небольшую сложность инструментов (может помочь IBM Redbobks).

В небольших компаниях Java / C # может оказаться полезным. Здесь вы можете познакомиться с junit / nunit / TestNG / MSTest. Для веб-приложений стоит обратить внимание на такие вещи, как Selenium / Watij / Watin / Fit / Fitness / Concordian. Если у вас есть минутка, посмотрите на AutoIT, PowerShell, Python, Fiddler, Jmeter, Abbot, Watir / Cucumber, Sikuli.

Существует также множество других инструментов, таких как WebAii, TestComplete, Twist ... некоторые другие коммерческие инструменты. Обычно вы можете получить для них испытания, чтобы поиграть с ним в течение недели или двух.

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

Тем не менее, на мой взгляд, до некоторой степени достаточно изучить Java / C #. Вам не нужно быть ниндзя C # / Java, знать каждую библиотеку и усердно изучать данный язык. Вы видите, что разработка программного обеспечения - это больше, чем знание языка программирования, а автоматизация тестирования - это больше, чем знание инструмента / языка (М. Фьюстер и Д. Грэм), так что не зацикливайтесь на этом.Если вы можете запрограммировать сценарий в QTP ( не запись, а программа , используя описательное программирование, разложив логику на библиотеки, имея полный контроль над TestResults с помощью соответствующих методов и т. Д.), То другие инструменты не будут проблемой. Вам может понадобиться неделя или две, чтобы изучить основы данного языка, но это все для автоматизации тестирования (по крайней мере, для начала). Вам нужно больше, чтобы иметь некоторый опыт, знать инструменты, знать концепции, знать плюсы и минусы различных подходов, иметь более широкую картину в голове, чем просто «как мне написать это на этом языке» (у вас есть ТАК для этого : D).

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

Я нашел следующее полезным при создании средств тестирования с использованием сценариев / автоматических тестов:

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

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

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

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

В зависимости от того, что вы тестируете, вы также можете иметь какие-то инструменты тестирования, встроенные в код, который вы тестируете. Код Java иногда пишется с помощью тестов JUnit, код Ruby может использовать среду Test :: Unit и т. Д. Здесь приведен список сред модульного тестирования для большого количества языков. Если код, который вы тестируете, был построен с учетом модульного тестирования, вы захотите изучить язык, на котором был написан код, чтобы вы могли воспользоваться преимуществами этих модульных тестов.

Для веб-тестирования вы можете проверить fitnesse . Кроме того, автоматизированная среда тестирования, построенная на Python, - это среда роботов .

1. Selenium очень популярен для автоматизированного тестирования на уровне QA.
2. Независимо от того, что вы делаете, будет некоторая кривая обучения, связанная с вашим решением
3. Суть Selenium в том, чтобы обеспечить основу для тестирования веб-приложений - вы используете Selenium для манипулирования элементами DOM в браузере, без запущенной версии вашего приложения.

4. Selenium представляет собой модель клиент/сервер (вы запускаете сервер, который имеет доступ к вашему экземпляру QA-приложения; вы пишете тесты, используя клиентские библиотеки), которая предоставляет клиентов на нескольких языках (java, ruby и т.д.)

5. Этот тип тестирования является хорошей идеей, если у вас есть выделенные ресурсы QA, которые могут писать код. Он обеспечивает некоторый высокий уровень регрессионного тестирования. Однако он не лишен недостатков: (1) для выполнения тестов может потребоваться некоторое время, (2) вам может понадобиться внести некоторые изменения в элементы dom вашего веб-приложения, чтобы легко использовать фреймворк, (3) изменение веб-приложения потребует изменения кода тестирования, что может быть нетривиальным.

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