Сообщений в теме: 10

[Puankare]

При обдумывании структуры своего тестового фреймворка столкнулся с проблемой выбора хранилища данных.
Структура фреймворка у меня предполагает разделение данных(ну или классов, отвечающих только за извлечение\подготовку данных), логики и тестов.
Из хранилища данных будут извлекаться поля для передачи их тестам (например какое поле чем заполнить).
У меня есть несколько вариантов:
— База данных (так же можно туда записывать логи выполнения тестов)
— Много XML файлов (не очень хочется с ними возиться, но, как вариант, можно использовать для указания например ссылки на сборку, на которой нужно крутить автотесты)
— Текстовый файл (самый печальный для меня, ибо нужно писать парсер который будет считывать данные, а знаний в программировании не очень хватает)

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

[vmaximv]

Вам это нужно для Data-driven testing? Если да - excel. Если нет, советую подумать, стоит ли отделять данные от тестов.

[vitorg]

А почему не хотите генерировать данные на лету? В таком случае заморочек с БД меньше, а покрытие больше. Единственным недостатком можно считать некоторое снижение воспроизводимости результатов.

[Petrov.Sergey]

При обдумывании структуры своего тестового фреймворка столкнулся с проблемой выбора хранилища данных.
Структура фреймворка у меня предполагает разделение данных(ну или классов, отвечающих только за извлечение\подготовку данных), логики и тестов.
Из хранилища данных будут извлекаться поля для передачи их тестам (например какое поле чем заполнить).
У меня есть несколько вариантов:
— База данных (так же можно туда записывать логи выполнения тестов)
— Много XML файлов (не очень хочется с ними возиться, но, как вариант, можно использовать для указания например ссылки на сборку, на которой нужно крутить автотесты)
— Текстовый файл (самый печальный для меня, ибо нужно писать парсер который будет считывать данные, а знаний в программировании не очень хватает)

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

У меня точно такая же ситуация.

Я реализовал так:

1) Все справочные данные запихал в БД (например, пул типов договоров)
2) Все "поля для теста" у меня объединены в XML, т.к. по сути я иксэмэльки и тестирую :)

• Поэтому я создал через jaxb на основе XSD JAVA-модель.
• Написал свой класс-генератор полностью корректного и полностью рандомного объекта, являющегося отражением будущей XML в JAVA-модели.
  Для рандомизации написал соотвествующие функции: getRandomDateFromDateToDate(Date dateFrom, Date dateTo), getRandomWord(int length, String alphabet), getRandomNumber(int length)
• Я никогда наперёд не знаю, что сгенерится - знаю только, что все данные будут 100% согласованы и корректны.
• После генерации корректного объекта я меняю данные под нужный тест.
• Через jaxb конверчу в XML и далее скармливаю системе.

3) Для проверки БД (как легло то, что я послал в XML) я создал свою JAVA-модель (к сожалению, наполовину вручную) по 1 классу на каждую тестируемую таблицу.

• В каждом классе-таблице набор приватных переменных полностью совпадает с полями соответствующей таблицы в БД (за исключением ID).
• В каждом классе-таблице имеется свой конструктор, принимающий на вход нужный кусок объекта-"XML".
• Для каждого объекта-таблицы существует свой метод в общем утилитном классе по проверке данных.
• Теперь для проверки БД мне достаточно только вызвать соответствующий конструктор и соответствующий глобальный метод.
  

  ClifFio clifFio = new ClifFio(replaced, clif_id_new, clif_uid_new, rec_id_file_create); // replaced - java-объект, остальное - ключевые поля для селекта.
  checkClifFio(clifFio); // таблица clif_fio состоит из 44 полей, 2 из которых предопределены ключевыми полями, участвующими в поиске.

• Метод проверяет каждое поле в найденной строке (если найдёт; если не найдёт - обрабатываемое исключение) на соответствие с моим сгенерённым объектом-таблицей.
• Каждое несоответствие - фейл. То есть если из 44 полей в БД не совпали 5, то будет 5 фейлов.

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

Почему так реализовано?
1) Почему рандомизация - чтобы отловить случайности, которые в голову могут не прийти.
2) Почему JAXB - потому что это самый удобный и быстрый JAVA-конвертер из java-объекта в XML любой сложности и обратно.
3) Почему так проверяю БД - мне надо проверять каждое поле, а не просто наличие ошибки где-то в записи. И не хочу проверять каждое поле в отдельности: вместо 44 селектов использую один.

4) Как можно организовать описал.
5) Где почитать?
- Про JAXB в интернете по ключевому слову. Генератор модельных классов на основе XSD = XJC (один из модулей JAXB) либо через Maven / Ant. Будут проблемы с XJC - обращайтесь.
- Про такую модель БД, наверное, нигде, т.к. это собственная "разработка", не претендующая на самую правильную. Меня её качество устраивает на 146% :)

[Petrov.Sergey]

При обдумывании структуры своего тестового фреймворка столкнулся с проблемой выбора хранилища данных.
Структура фреймворка у меня предполагает разделение данных(ну или классов, отвечающих только за извлечение\подготовку данных), логики и тестов.
Из хранилища данных будут извлекаться поля для передачи их тестам (например какое поле чем заполнить).
У меня есть несколько вариантов:
— База данных (так же можно туда записывать логи выполнения тестов)
— Много XML файлов (не очень хочется с ними возиться, но, как вариант, можно использовать для указания например ссылки на сборку, на которой нужно крутить автотесты)
— Текстовый файл (самый печальный для меня, ибо нужно писать парсер который будет считывать данные, а знаний в программировании не очень хватает)

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

Если Вы хотите продумать файловое хранилище конфигураций тестов, чтобы пополнять их мог любой, имеющий доступ к этому хранилищу, то вариантов несколько:
1) XML. Мощно. Надёжно. Можно настроить проект так, что невалидные конфигурации просто не пройдут (если поле должно содержать число, а содержит слово, выдаст фейл и тест с этой конфигурацией выполнять не будет). Но несведущему "левому человеку" будет сложно заполнить его нужными данными в нужных полях.
2) Текстовый файл с табуляцией. Если используете JAVA, то

Scanner in = new Scanner(new File(fullPathToYourFileInString));
String line = in.nextLine();
String[] arr = line.cplit("\t"); // получаем массив того, что было в строке по разделителю "TAB"

Минус этого метода - полная свобода заполняющего конфиг. Вплоть до возможности существования параметра без значения (даже без empty_string).
3) CSV (один из форматов Excel) с разделителем ";". По сути это тот же текстовый файл, который вручную можно открыть в удобном табличном режиме Excel.
Все минусы текстового файла за исключением удобства редактирования и отсутствия возмжоности существования параметра без значения (уж empty_string будет точно!)

[Puankare]

Всем большое спасибо за ответы! Генерить данные на лету это не вариант, ибо возможные значения полей предопределены в системе (справочники имён клиентов\городов\типов аккаунтов и т. д.), рандомным может быть например сумма транзакции между двумя клиентами, поэтому я склоняюсь больше в сторону БД.

Собственно говоря, подумав ещё у меня возникли вопросы опять.
Например мне нужно проверить корректность прохождения транзакции между двумя клиентами (т.е. провести транзакцию и проверить, что счета клиентов изменились на сумму, указанную в транзакции)
Первый способ:
Step1) Все данные для тестов я могу брать напрямую через GUI (заходить в справочник клиентов, фильровать клиентов для типа транзакции который собираюсь провести, запоминать какая сумма сейчас)
Step2) Проводить транзакцию через GUI с рандомно сгенеренной суммой транзакции
Step3) Опять через GUI заходить в справочник клиентов, находить тех, для которой проводил транзакцию и проверять изменение их балансов

Второй способ
Step1) Напрямую из БД приложения фильтровать клиентов и запоминать их баланс из БД
Step2) Проводить транзакцию через GUI
Step3) Проверять изменение баланса напрямую в БД приложения\или через GUI

Первый способ более сложен в реализации и он затрагивает функционал системы который проверять пока не надо(это шаг step1 например).

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

[Petrov.Sergey]

Всем большое спасибо за ответы! Генерить данные на лету это не вариант, ибо возможные значения полей предопределены в системе (справочники имён клиентов\городов\типов аккаунтов и т. д.), рандомным может быть например сумма транзакции между двумя клиентами, поэтому я склоняюсь больше в сторону БД.

Собственно говоря, подумав ещё у меня возникли вопросы опять.
Например мне нужно проверить корректность прохождения транзакции между двумя клиентами (т.е. провести транзакцию и проверить, что счета клиентов изменились на сумму, указанную в транзакции)
Первый способ:
Step1) Все данные для тестов я могу брать напрямую через GUI (заходить в справочник клиентов, фильровать клиентов для типа транзакции который собираюсь провести, запоминать какая сумма сейчас)
Step2) Проводить транзакцию через GUI с рандомно сгенеренной суммой транзакции
Step3) Опять через GUI заходить в справочник клиентов, находить тех, для которой проводил транзакцию и проверять изменение их балансов

Второй способ
Step1) Напрямую из БД приложения фильтровать клиентов и запоминать их баланс из БД
Step2) Проводить транзакцию через GUI
Step3) Проверять изменение баланса напрямую в БД приложения\или через GUI

Первый способ более сложен в реализации и он затрагивает функционал системы который проверять пока не надо(это шаг step1 например).

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

Я такое делаю вторым способом.
Корректность отображения данных на гуях проверяется одним тестом - нет необходимости каждый раз лезть в гуи, чтобы посмотреть изменения. Можно проверить соответствующее изменение в БД.

Совет: запоминать баланс всех клиентов нет необходимости. Можно рандомно выбрать двух, запомнить их балансы, использовать обоих в своей транзакции, проверить изменение баланса у обоих.
Для надёжности можно рандомно взять третьего клиента и удостовериться, что у него баланс не изменился.
Рандомизация понизит количество тестов.
Естественно, если между клиентами есть какая-то связь, то связанных клиентов нужно проверять в первую очередь. Но если основная масса никак не связана между собой, то к ним можно применить рандомизацию.

[barancev]

Те, кто хочет, чтобы было так же мощно, как XML, но так же просто, как "простой текст с разделителями" -- посмотрите на YAML

[Petrov.Sergey]

Те, кто хочет, чтобы было так же мощно, как XML, но так же просто, как "простой текст с разделителями" -- посмотрите на YAML

Ой, бяка!
Не знал, что такое. Глянул - чур меня!

JSON и то покрасивше будет.
А в надёжности пару XML+XSD никто не обойдёт.

[barancev]

JSON тоже неплох, да.
YAML является надмножеством JSON, то есть позволяет писать "со скобочками", но дополнительно есть возможность писать "без скобочек, но с отступами".
Пример сравнения "читаемости" XML и YAML например вот -- http://www.codinghor...racket-tax.html

А что Вы подразумеваете под "надёжностью"?
И какая такая "надёжность" требуется для хранения тестовых данных?

[Petrov.Sergey]

А что Вы подразумеваете под "надёжностью"?
И какая такая "надёжность" требуется для хранения тестовых данных?

Если этот текстовый файл использовать в качестве набора параметров для проведения тестов, то эти параметры просто берутся тестом и используются.
В случае с TXT в общем случае значение параметра может быть произвольным. При том, что на самом деле параметр "тип договора" (например) может быть лишь одним из множества.
Если человек, придумывающий конфигурации для тестов, введёт некорректное значение параметра, тест упадёт. XSD же такое не пропустит.
А негативные тесты (по невалидным значениям) составляют гораздо меньшее множество.

То есть не проверять в каждом тесте валидность значений входных параметров, а доверить это XSD.
Защита от дурака.

YAML является надмножеством JSON....

Да, я читал.
Скорее всего, такое первое впечатление из-за привычки видеть массивы в чём-нибудь ограничивающем (скобки, теги).
JSON тяжелее YAML при парсинге, но удобнее в плане "человекочитаемости".