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

Фотография

Как писать тест-кейсы для автотестов или как сделать так, чтобы они пи


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 5

#1 Evgenii163

Evgenii163

    Новый участник

  • Members
  • Pip
  • 31 сообщений
  • ФИО:Клочков Евгений Анатольевич
  • Город:Тольятти

Отправлено 15 июля 2019 - 14:41

Как писать тест-кейсы для автотестов или как сделать так, чтобы они писались автоматически (Извините за кривое название темы, что-то не найду как отредактировать)

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

2. Чтобы отдельно вручную не писать тест-кейсы.  сделать так, чтобы тест-кесы писались либо как-то автоматически, либо в процессе написания автотестов, как например  в  "behavior driven testing". 

 
Но возникает ряд проблем:
1. Вовсе отказаться от тест-кейсов как я думаю - невозможно, потому что как минимум их с нас требует заказчик, причем по своему шаблону в гугл-таблицах
2. Скорее всего отказ от документации (тест-кейсов) не лучшая идея, потому что документация в общем-то нужна (наверное)

3. Не все сценарии на проекте возможно автоматизировать, значит если нет автотестов, то нет и тест-кейсов

 

Вопрос:

У кого есть опыт решения данных проблем? Поделитесь своими мыслями и опытом. Как вы автоматизировали тест-кейсы. Может кто-то вообще их не использует?


  • 0

#2 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 15 июля 2019 - 16:14

  1. а. Вы не отказываетесь от тест-кейсов. В стандартном подходе автоматизация - это те же тест-кейсы, только в виде скрипта.
    б. С гуглотаблицами может быть проблема. Это не общепринятый формат, придется клепать свои адаптеры или договариваться с заказчиком, чтоб принял ваш формат.
  2. Наверное, вот именно. Даже на моем текущем сильно забюрократизированном проекте считается, что автоматические кейсы могут служить документацией сами для себя.
  3. Непонятно. Вы собрались делать 100% автоматизацию? Так обычно не делают, хотя зависит от специфики продукта.

Есть известные подходы, и это:

  • BDD (или keyword-driven, с использованием тех же инструментов)
  • Allure
  • Robot Framework

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

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


  • 0

#3 Evgenii163

Evgenii163

    Новый участник

  • Members
  • Pip
  • 31 сообщений
  • ФИО:Клочков Евгений Анатольевич
  • Город:Тольятти

Отправлено 15 июля 2019 - 16:23

 

  1. Непонятно. Вы собрались делать 100% автоматизацию? Так обычно не делают, хотя зависит от специфики продукта.

 

Я как раз это и имел ввиду. Что я физически не смогу автоматизировать 100% Проекта. Значит придется закрывать оставшуюся непокрытую автотестами часть - стандартными тест-кейсами. Ах их вот вообще не хочется ни писать ни поддерживать)


  • 0

#4 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 16 июля 2019 - 00:31

Прям чтобы писались сами по себе — такого не будет. На основе чего им писаться? Ситуаций? Параметров? Набора данных? Человек-дизайнер тестов  понадобится, и по клавиатуре ему придётся тарабанить (возможно, и своей башкой) при любом раскладе. Вообще отказаться не получится, надо копать в сторону оптимизации этого процесса.

 

Большой рефакторинг тест-кейсов всегда проблема — это почти всегда очень ресурсозатратная и в итоге неподъемная задача. Рассмотрите их скоростное написание с нуля.

 

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

 

Но это взлетит только если автоматизатор будет полностью в теме и будет понимать контекст.

 

Если тесты обыкновенные, то основой для их переезда в среду разработки может стать Gherkin и Фукидид (или более современный Allure). Старая технология, проверенные решения. Тесты будут. Качественные ли — неизвестно, нужно много таланта и интуиции для их перевода на "псевдоязык", и можно увлечься их скриптованием в ущерб их качеству.

 

Можно рассмотреть Fitnesse — требует отдельного подхода, там поначалу сложно, но потом может быть весело. Но нужен опыт.

 

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

 

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


  • 0

Software Testing Glossary - простыми словами о непростых словах.


#5 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 26 июля 2019 - 10:24

 

 

На проекте планируется большой рефакторинг тест-кейсов. 

вот и делайте его

 

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


  • 1

#6 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 01 августа 2019 - 04:37

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

 

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


  • 1


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных