0

Мне нужно автоматизировать тестирование моего мобильного приложения для Windows. В моем приложении нет пользовательского интерфейса. Таким образом, обычные инструменты тестирования, которые работают со случайными нажатиями клавиш и щелчками мыши, не будут работать здесь. Существуют ли какие-либо инструменты для Windows Mobile для проверки только фоновой обработки?Windows Mobile - инструмент автоматизированного тестирования для приложения, отличного от UI

+2

Что делает приложение? Что вы пытаетесь проверить? Например, если вы выполняете регистрацию местоположения GPS в своем приложении, тогда автоматическое тестирование, по-видимому, потребует перемещения устройства! Как вы определяете автоматическое тестирование? Не могли бы вы просто использовать модульное тестирование? –

+0

. 1. Он должен иметь возможность наблюдать за приложением для определенных вещей. Как правильно ли перехватываются SMS, Журналы вызовов и передаются данные на сервер. 2. Если устройство выходит из определенной области, оно должно зарегистрировать его в базе данных. 3. Он должен иметь возможность общаться с сервером без проблем и т. Д. –

ответ

0

У вас есть несколько вариантов в зависимости от того, какой уровень тестирования вы хотите.

  • Комплексное тестирование

Комплексный тест направлен на тестирование приложения в реальном мире. Поэтому вы создадите все «реальные» вещи и напишите код, чтобы специально проверить, соблюдены ли ваши условия. Я бы поверила, однако, если вы пытаетесь проверить GPS, это было бы непрактично. Поскольку кому-то действительно нужно будет передвинуть устройство.

  • Test Unit насмехаясь над

Я сделал это раньше для тестирования GPS. Идея состоит в том, что вы SANDBOX проверяете объект. Вы гарантируете, что все внешние ссылки (например, все, что не является объектом) являются интерфейсами. Затем вы устанавливаете эти интерфейсы с реализацией «только для тестирования».

Например, я работал над тестом GPS, в котором мы использовали интерфейс под названием: INmeaInterpreter для запуска определенных событий, которые будут отобраны классом с именем PositioningService.
Реализация по умолчанию была сторонним компонентом. Однако, поскольку INmeaInterpreter был интерфейсом, мы могли бы создать реализацию, которая вместо использования данных REAL использует (например) файл NMEA для чтения. Это позволило нам проверить, как PositioningService работал в определенных (а иногда и странных) сценариях.

Тогда я предложил бы высмеивать другие внешние ссылки. Вызов базы данных может быть просто фиктивным объектом с счетчиком для вызова базы данных, который увеличивается, если он вызывается. Затем вы можете написать тест с файлом NMEA, который должен привести к вызову базы данных, а затем в конце проверки блока проверить, что этот фиктивный объект указывает, произошел ли этот вызов.

Мы сделали все вышеперечисленное с ужасным MSTest, но вы можете использовать любую тестовую среду (я рекомендую NUnit). Я не уверен, есть ли варианты тестирования на устройстве. Мы выполнили все наши тесты на рабочем столе, так как мы бы разделили код красиво, чтобы конкретный код устройства был изолирован и его можно было легко заменить эквивалентами рабочего стола.

Очевидно, что единственная проблема с модульными испытаниями заключается в том, что они не тестируют аппаратное обеспечение.


Я бы рекомендовал (в зависимости от размера проекта и команды), чтобы сделать оба типа тестирования, но поставить больший акцент на модульных тестов (так как они легче работать/управления).

Смежные вопросы