Автоматизированное тестирование GUI [закрывается]
Вот один вариант с использованием data.table. Попробуйте:
df <- iris
df$Species <- as.character(df$Species)
# let's say that Species is the field to update and already exists,
# while Species2 is the field that would be newly created
library(data.table)
setDT(df)[Species == "setosa",
c("Species", "Species2") := list("Original added text",
"Species2")][]
6 ответов
Мы используем платформу SAFS для Рационального Робота (RRAFS). Существуют также реализации SAFS для WinRunner (WRAFS), и похоже, что у них есть новое "Основанное на изображении Тестирование" реализация, с которой я не знаком.
Эта платформа делает хорошее задание разделения реализации UI из сценариев тестирования. Я протестировал четыре релиза веб-приложения, разработанного двумя различными командами (одна команда, использующая классический ASP, одно использование ASP.NET), и я только должен был изменить карту приложения своих объектов пользовательского интерфейса, сами тесты не должны были изменяться.
Тем не менее язык платформы является громоздким и берет привыкание к. Это не очень устойчиво, с точки зрения конструкций языка, но с некоторым усилием можно сделать что-либо, что Вы должны. Это - вид подобного "программирования" на языке Windows Batch, но для тестов ;)
Удовлетворять Ваши отдельные требования выше:
1) Инструмент должен работать с (необоротным) MFC. Платформа SAFS использует сторонний инструмент "записи-считывания" для управления тестами, как Рациональный Робот или Mercury WinRunner. Если тот инструмент может взаимодействовать с приложениями MFC, то платформа может. Я не знаю, как "Основанное на изображении Тестирование" реализация управляет тестами, но я предположил бы, что это может также работать с MFC.
2) быть автоматизированным. Платформа SAFS интегрируется с платформой STAF, которая позволит Вам автоматизировать выполнение своих тестов. У меня есть тест подтверждения концепции, который использует STAF, чтобы запустить образ виртуальной машины с пула изображений, установить приложение под тестом, запустить тест RRAFS и поместить результаты на веб-сервер для других для достигания.
3) будьте scriptable. Да, но, как упомянуто, это не большая часть языка робастного программирования. Я записал дополнение Excel, которое наши тестеры используют для записи их тестов, который упрощает вещи немного.
4) работа с различными разрешениями экранов автоматически. Да, так как это смотрит "под покрытиями" на объекты пользовательского интерфейса а не экран. За исключением, возможно, опции "Image-based Testing"...
5) смогите 'шпионить' за отдельными полями статического текста, и т.д. Да, можно ожидать объекта пользовательского интерфейса, чтобы появиться, исчезнуть, иметь значение, чтобы значение было изменено и т.д.
6) достаточно интуитивный, таким образом, непрограммисты могут создать сценарии. С некоторым обучением. Мы имели ограниченный успех. Некоторые люди QA могут записать тесты, некоторую борьбу.
7) имейте инструменты создания отчетов, включая электронную почту отдельных пользователей. Да, с помощью платформы STAF можно отправить результаты на веб-сервер, послать электронные письма и т.д.
Много хороших ответов здесь, но я хотел обратиться к этому оператору цели, конкретно:
- достаточно интуитивный, таким образом, непрограммисты могут создать сценарии
Я могу понять, почему Вы хотели бы это, но это намного более твердо, чем Вы могли бы думать. В то время как можно найти любое количество инструментов там, это будет утверждать, что сделало сценарии записи легкими, на практике, Вы испытываете необходимость по крайней мере в некоторых людях в своих командах автоматизации, которые понимают программирование. Запись сценариев, которые довольно устойчивы, собирается включить один или несколько из цикличного выполнения, if/then/else, и вызовы подпрограммы. Не вид вещи, которую непрограммисты собираются найти интуитивным.
Особенно опасайтесь идеи, что можно "записать" человека, использующего инструмент, затем воспроизведите его для тестирования. Такая "автоматизация" является часто столь хрупкой, что Вы закончите тем, что изменили или повторно записали сценарий почти для каждого изменения в программном обеспечении.
Происходя из сильной среды Меркурия/HP, я настоятельно рекомендовал бы использованию Профессионала QuickTest для Вашего тестирования GUI. Это имеет большую ту же функциональность как WinRunner, но без большого количества кода. Простые проверки GUI могут быть сделаны через интерфейс QTP с минимальным, если таковые имеются, пользовательским кодом VB. Проверки на текст рядом с полями могут быть, покончили простые, сравнивает использование таблицы данных в QTP.
Если Вы привыкли к WinRunner и знаете VBScript (не так много TSL), то я был бы взгляд definantly на QTP.
До Ваших других требований QTP также имеет функцию Spy, как WinRunner, который перечислит все свойства и действия, которые можно выполнить на объектах. И что касается простоты использования, в моем старом задании, у нас был бы бизнес, или системные тестеры создают простые сценарии дыма, затем я взял бы их и кодировал бы их для большего количества всестороннего тестирования (несколько значений данных, проверки ошибок, и т.д.). И что касается создания отчетов, QTP сделает простое создание отчетов передачи/сбоя/предупреждения на тегах, что Вы вставляете, наряду с пользовательскими данными, которые можно ввести. Таким образом, Вы могли использовать оператор выбора для заполнения выходных значений на основе результатов. Это не сделает электронной почты naitevly, но если Вы интегрируетесь с TestDirector/QualityCenter, можно установить через там, наряду с автоматизацией начала сценариев и параметризации данных прямо оттуда (который хорош передать обратно тестерам, чтобы иметь, заполняют данные, не будучи вовлеченным в сценарий itseld).
Кусочек
Посмотрите, что пользовательский интерфейс тестирует.
Настольные приложения или веб-приложения одинаково имеют тот же шаблон тестирования здесь (я работал в обоих).
Место как можно меньше логики в UI и тесте все ниже его. Таким образом, Вы говорите, но что, если я хочу протестировать, это такой и такой происходит, когда кнопка нажата? Метод, который называют, когда та кнопка нажата, должен обратиться к другому классу, который на самом деле делает взгляды.
Вы могли бы сказать, но я использую некоторые статические классы/методы, которые могут только существовать в моем UI, перенести тех, которые имеют адаптер и используют тот интерфейс для создания кода тестируемым.
Части Ваших тестов GUI, которые Вы хотите автоматизировать, должны быть автоматизированы ниже UI. Существуют части Вашего GUI, который Вы не можете автоматизировать. При проверке для проверки вещи "выглядят правильными", или тестирование, что Вы видите определенные элементы и т.д. Весь из того, именно это должны делать Ваши люди. Обеспечение, что события правильно стреляют, и что значения соответственно возвращаются от Ваших бизнес-объектов, это - все модульные тесты.
Я вижу от Вашего вопроса, что Вы уже в значительной степени решили необходимость в автоматизированном тестере GUI но это не правильный инструмент для этого задания. Если Вы решаете использовать это, Вы пытаетесь найти лучший способ сделать неправильную вещь.
Если Вы будете думать, что это не о поблочном тестировании, потому что Вы тестируете взаимодействия GUI, то я могу гарантировать, что Вы не поблочное тестирование достаточно близко к Вашему UI. Если бы Вы были, то Вы чувствовали бы себя подобно большей части того, что Вы протестировали бы, было избыточно.
Если Вы не соглашаетесь со мной, отправьте некоторые причины, и мы хешируем это.
Существуют альтернативы намного (более с открытым исходным кодом) при тестировании веб-продукта. Для десктопного решения, некоторых популярных настольных средств автоматизации GUI общего назначения ниже (без определенного порядка). Я работал со всеми ними лично, и они все сделали задание. Если Вы принимаете решение пойти с инструментом поставщика, получить POCs для тех, Вы рассматриваете и принимаете решение на основе того, какой инструмент является лучшим пригодным для компании в целом. Один инструмент может быть лучшим пригодным для конкретного приложения, но могут быть другие проекты/приложения рассмотреть.
- QuickTest Pro (преемник HP WinRunner)
- Рациональный Функциональный Тестер (преемник IBM Робота)
- TestPartner