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

[Margarita_Sh]

Успех автоматизации тестирования во многом зависит от выбранного инструмента автоматизации. Какой же инструмент выбрать: дорогой и многофункциональный, с хорошими возможностями записи тестов и редактирования или бесплатный и узконаправленный? В нашем проекте мы имели возможность попробовать и то, и другое и остановили свой выбор на бесплатной библиотеке White, служащей для автоматизации функционального тестирования приложений, основанных на Win32, WinForms, WPF, Silverlight и SWT.
В докладе я расскажу об организации автоматизированного тестирования пользовательского интерфейса в нашем проекте – об опыте использования White.

Доступна Презентация
Доступна Аудио запись

[owasp]

Очень интересно.
Генерация xml-описания форм приложения, для последующего тестирования этих форм. Вот это надо будет сделать на работе. Поискал сейчас по связке слов "dfm xml" - уже и реализации есть, правда делается это не для последующего тестирования, но всё же.
А также framework для тестирования - тоже неплохо. В проекте с которым я работаю используются функции (получить что-либо, создать что-либо). Нет такого разделения на Entities, Services, View Accessors. Руководствуясь одним из правил (шуточных) - "работает - не трогай" эти функции разработались и параметризировались. И каждый новый параметр добавляет новую серию условных переходов в функцию. Сейчас этих условных переходов уже слишком много, код автотеста стал сложным. А как со сложностью (ветвлениями) при использовании подобного фреймворка с разделением на сущности, сервисы и методы доступа к представлениям?

Вопрос про AutamationID у контрола - что это? Надо приложение собрать особым образом, чтобы такой атрибут контрола стал доступен?

Ещё вопрос про контроль выполнения теста. Когда становится понятно, что что-то пошло не так, что сбой теста? Как реализуется проверка в контрольных точках? Автоматизированное тестирование предполагает то, что тестировщик не следит на ходом выполнения автотеста. И вот пример, выполняется автотест создания пользователя. По каким-то причинам пользователь не создался: контрол недоступен, форма не открылась (потому что ошибка, или потому-что форма заблокировалась модальным окном другой ошибки), нет прав на создание пользователей. Есть ли в White возможность отследить все эти "потому что"?

Если этих проверок нет, то о том что пользователь не создан или создан но неверно, можно будет узнать только при ошибке во время входа в систему от имени этого пользователя. И потом надо будет разбираться - что произошло, зависла ли форма или это ошибка логики, почему она форма зависла, ошибка на тесте входа или она наведённая. То ещё приключение.

Так то ставить целью GUI-автотеста "найти ошибки" - очень сложная затея, особенно ошибки логики.
1. Или придётся добавлять много параметров в функции (при функциональном походе) автотеста, чтобы сообщать функции что на предыдущем шаге было сделано то-то (документ зашифрован), и ты функция, сейчас должна вести себя так-то (расшифровать документ, прежде чем конвертировать его в PDF).
2. Или создавать некий класс/объект, который будет запоминать состояние системы и при этом прогнозировать её будущее состояние (ожидаемый результат) - это не искусственный интеллект, но что-то похожее на мозг.
3. Или жёстко прописывать действия и проверки в коде - быстрый подход, но он лишен гибкости и не вяжется с иеей использования сущностей и сервсисов.
4. Или жёстко заранее прописывать какие будут действия и какой должен быть ожидаемый результат (тут предполагется, что есть непогрешимые методы проверки этого ожидаемого результата, а сами проверки и результаты описывают в XML-документе или базе данных), а далее тест проглатывает это высокоуровневое описание (план тестирования) и делает свою работу.

В моём случае используется вариант 3, смешанный с вариантом 1. Надеюсь, что в Lanit-Tercom используется что-то похожее на 4-й вариант. Или может есть и другие способы. Или может перед GUI-автотестом стоят другие задачи (нагрузочные: подсчитать число SQL-запросов и показания других счетчиков)?

[ame421]

Маргарита, скажите пожалуйста, чем white отличается от AutoIT? Лучше\хуже? Больше возможностей? Каких?

[Margarita_Sh]

owasp, ame421, прошу прощения, сейчас нет возможности ответить на ваши вопросы.. обязательно сделаю это до конца недели

[owasp]

Маргарита, я на свои вопросы придумал ответы. Думаю не надо ставить целью автотеста - поиск ошибок. Это усложняет автотест, можт усложнить его так, что он станет сложнее самого тестируемого приложения.
Простой пример - в тестируемом приложении заложена некая логика, но мы допускаем, что она заложена плохо или вообще её нет. Поэтому создаётся автотест, в котором эта логика точно заложена + есть проверки на её существование. А такой автотест ничуть не проще самого приложения, значит ошибки в автотесте даже более вероятны, чем ошибки в программе. Получается, что разрабатывать автотест ищущий ошибки логики в одной конкретной программе - невыгодно.

Максимум что можно - автотест на одну трудоёмкую операцию, которая важна, но которую сложно уложить в голове человеку. Например, создание финансовых документов разными способами, и последующая проверка остатков (проверка, что дебет сходится с кредитом). И это надо автоматизировать через GUI-автотест если нет API, если же есть API, то можно и без GUI обойтись.

[iFomin]

Маргарита, я на свои вопросы придумал ответы. Думаю не надо ставить целью автотеста - поиск ошибок. Это усложняет автотест, можт усложнить его так, что он станет сложнее самого тестируемого приложения.

Автотесты бывают разные. Большинство проходят по регрессионным сценариям и проверяют, что ничего не сломалось, но, например, crawler'ы как раз созданы для того, чтобы находить неожиданные ощибки, а логику не проверяют никак. Здесь что важнее, на том и стоит концентрироваться. Регрессию обычно делают первой.

[Margarita_Sh]

Маргарита, скажите пожалуйста, чем white отличается от AutoIT? Лучше\хуже? Больше возможностей? Каких?

Еще раз прошу прощения, что не ответила оперативно.. может, мой ответ уже не актуален, но напишу все равно =)

White по сути является библиотекой, которая может быть использована для написания GUI-тестов, это в принципе набор функций, обеспечивающих доступ к различным контролам, сам же тест пишется на языке C#. Большим плюсом White (для нашего проекта) является его открытый код, мы, таким образом, добавили много своих собственных функций и оберток к имеющимся. То есть White дает достаточно большие возможности, но при этом требует знаний С#.
AutoIT я, честно говоря, не пробовала, но по описанию у меня не появилось уверенности, что AutoIT работает с WPF-приложениями (мы именно такие и тестируем).
У меня сложилось впечатление, что с помощью AutoIT удобно создавать небольшие скрипты для запуска приложений, тесты для несложных приложений с простыми контролами и т.д. В принципе, интересно попробовать для таких целей.

[barancev]

AutoIT работает с Win32-контролами, поддержка WPF вблизи нуля.

Что касается размера скриптов -- во-первых, AutoIT предоставляет полноценный язык программирования (разновидность VB)
А во-вторых имеется COM-компонент AutoItX, который можно использовать с любым другим языком -- .Net. Ruby, Python, даже с Java (имеется "переходник").
Поэтому писать тесты можно сколь угодно сложные, с этим проблем нет.