Автоматизированное тестирование GUI: встреча нас на полпути
Я не знаком с Юникодом Linux. Но я могу дать вам несколько указаний.
-
Согласно Wiki , санскритские символы принадлежат к деванагари-юникодскому блоку.
-
Блок деванагари Unicode включен
A8E0— A8FF. Вы можете найти здесь .Вам может понадобиться инструмент для конвертации в UTF8, например , этот инструмент .
-
Установите условие Regex, исключая блок Unicode Devanagari.
\S+[^\s\xA8E0-\xA8FF.]+.*
Regex demo
Это будет легче найти английские предложения.
6 ответов
Основной руководящий принцип: если они хотят, чтобы вы что-то протестировали, тестировщикам нужен способ перевести приложение в это состояние, а в этом состоянии - способ проверить правильность состояния.
Итак, первое, что нужно сделать, это убедиться, что они понимают, что автоматизация - это программирование, а пользовательский интерфейс - это ваш API.
Согласие не изменять пользовательский интерфейс произвольно - если тестировщик Боб видит, что компонент изменился с кнопки на ссылку, и он соответствует спецификации, щелкает и продолжается. Хотя изменение кода в автоматизации относительно простое, это изменение может потребоваться в нескольких местах. (ваша задача как тестировщика - понимать, что изменения происходят, и минимизировать затраты на обслуживание; их задача - только вносить важные изменения и понимать влияние)
Способ определить, на какой странице вы находитесь .... Боб может отличить логин от входа в систему, но откуда автоматизация? Если поле ввода с меткой «Имя пользователя», страница входа. Если поле ввода с номером заказа, поле заказа.
Плохо - лучшая практика - это согласованный элемент пользовательского интерфейса для идентификации страницы - заголовок страницы, скрытый компонент и т. Д.
Способ однозначной идентификации каждого элемента, с которым вам нужно взаимодействовать (щелкните, введите, verify и т. д.) А не INPUT_42 ....
Спросите разработчиков, какую информацию тестеры могут предоставить им для ускорения отладки, и попросите их записать ее в файл журнала.
Возможность сбросить состояние программы
Последовательная обработка ошибок и создание отчетов (также просто хороший дизайн пользовательского интерфейса)
Один совет: сохраняйте свой тестовый код в минимум двух уровнях абстракции :
- верхний уровень : это должен быть своего рода фасад, ориентированный на терминологию / действия вашего конкретного приложения и т. Д. Этот слой не напрямую не использует библиотеку Selenium RC. В фоновом режиме используется нижний уровень ...
- ... : библиотека с некоторыми общими шаблонами тестирования (пример: " утверждает, что выбрано значение X элемента управления переключателем "), которая использует библиотеку Selenium RC.
Таким образом, ваши тесты будут более понятными и понятными с точки зрения того, что тестируется. Мы даже попробовали трехслойный подход, третий (самый верхний) уровень является тестами, указанными с использованием XML . Это было сделано для того, чтобы наши тестеры, не занимающиеся программированием, могли указывать приемочные тесты, не углубляясь в код C #.
Как и в большинстве вопросов, это зависит. Главным образом о том, как выглядит ваш сайт и какие элементы управления на страницах - много ли повторяющихся элементов и т. Д.?
Я имел большой успех, используя Selenium RC и Selenium IDE. Главное - привыкнуть к использованию Selenium и его команд. Также полезно привыкнуть к поиску объектов на странице (XPath и CSS-селекторы, а также функция «содержит»). Чего вы не хотите, так это множества элементов, имеющих одинаковый путь выбора. Если приведенные ниже таблицы и элементы div не содержат уникальной части, это может добавить дополнительную сложность вашим тестам.
<html>
<body>
<table>
<tr>
<td>
<div></div>
<div></div>
<div></div>
</td>
</tr>
</table>
<table>
<tr>
<td>
<div></div>
<div></div>
<div></div>
</td>
</tr>
</table>
</body>
</html>
Для тестирования изображений приятно иметь возможность проверять их существование на основе чего-то другого, кроме файла изображения. имя, поэтому вам не нужно менять свои тесты при обновлении изображения. Если вам нужно протестировать объекты Flash, посетите этот сайт .
Кроме того, я заметил, что не так много всего можно включить в разработку. Как только вы начнете настраивать тесты и размещать элементы на странице, вы, вероятно, довольно быстро увидите, что разработчики должны сделать, чтобы помочь вам.
Добавление к комментариям McWafflestix и s_hewitt - элементы GUI должны быть правильно помечены, уникальны и предсказуемы для успеха с помощью автоматизации GUI. Если идентификаторы элементов непредсказуемы, у вас возникнут проблемы. Предсказуемый не обязательно означает статический. Для статических элементов страницы, таких как поле имени пользователя или кнопка входа в систему, я ожидал бы, что имя / идентификатор для них будет статическим от сборки к сборке и запуска к запуску. Для флажков, переключателей, динамического контента, я бы ожидал, что они будут динамическими, но предсказуемыми. Например, у вас может быть div с class = "contentdetail" и id = "12345". Пока вы можете создать свой xpath, чтобы найти объект, с которым вам нужно надежно взаимодействовать, у вас все получится.
РЕДАКТИРОВАТЬ: Отличный способ для разработчиков автоматизировать тестирование - это настройка теста. В зависимости от вашего приложения, автоматическая настройка теста и демонтаж могут быть проблематичными. Например, в приложении рабочего процесса на складе тесты в начале рабочего процесса (прием товаров на склад) просты в настройке, но тесты в конце рабочего процесса (доставка товара со склада клиенту) много зависимостей (товар должен быть на складе, с достаточным количеством, в правильном месте на складе и т. д.), что большая часть вашего кода автоматизации может иметь дело только с навигацией и вводом вашего пути через приложение, чтобы добраться до точки, где вы можете выполнить тест. В этих случаях может быть полезно иметь какую-то внешнюю утилиту (вне приложения, поэтому основной интерфейс не затрагивается) для внедрения зависимостей или сброса базы данных до некоторого известного состояния. На моем складе пример,
Я достаточно зеленый для (правильного) модульного тестирования, но натолкнулся на несколько упоминаний о том, что вам следует избегать тестирования вашего GUI. Обычно в них не указаны конкретные причины, поэтому я не могу их подтвердить.
Подход, который я использую (и я думаю, что подход, предложенный Ювалом Лоуи в "Программировании компонентов .NET"), состоит в том, чтобы попытаться абстрагировать реальный код от GUI через интерфейс, который позволяет мне писать модульные тесты для всей бизнес-логики, запускаемой GUI, без фактического тестирования самого GUI.
Он работает довольно хорошо и привел к намного более чистому коду с большим отделением бизнес-логики от GUI а также делает модификации GUI намного менее стрессовыми.
There is very little that the devs can add to the code to help.
The issue is that if you want to test the execution of code paths and the validity of those code paths, that should be done in Unit Tests, and those should be completely divorced from your GUI. But if you really want to test your GUI, then you've just got to simulate user input. The one thing that can help with this is to have your objects and controls properly tagged so that they can be properly detected by your test framework and be exercised. Other than that, there's just not a lot that can be done (although that can help quite a bit in itself).