Простому тестировщику — незачем. А вот тестировщику мобильных приложений очень даже пригодятся!
GPX пути — это XML-файлы с последовательными координатами. Их можно загружать в эмуляторы мобильных, чтобы телефон думал, что он перемещается в пространстве с какой-то скоростью.
Полезно, если приложение считывает GPS-координаты для каких-то своих целей. Так оно само определяет, идешь ты, бежишь или едешь. А можно не бегать, просто скормить приложению координаты, выставить коэффициент их прохождения и тестировать, сидя в офисе.
Зачем тестировать? Приложения обычно сами расчитывают скорость — и потому могут падать. Например, карта в самолете может крашиться, потому что разработчики думали, что скорость максимум 120, а тут БАЦ, самолетик...
Просто задали координаты и эмулятор делает вид, что мы по ним передвигаемся. Даже если мы сидим себе в офисе и пьем чай
Обычное позитивное тестирование. Скажем, приложение расчитывает, где находится ближайший Старбакс. Можно ходить по улице и проверять, какие варианты он подсказывает. А можно начать с эмулятора, так будет быстрее.
Конечно, реальное тестирование ничего не заменит, но вдруг смена вашей позиции вообще никак не влияет на приложение, оно считывает координаты только при запуске? Зачем тратить время на прогулку, если такой баг можно было найти в офисе?
Тут самая соль и баги. Как обычно при поиске границ сверху, впрочем =)
Коллега рассказывал такие случаи из жизни:
Самолет
Запустил в самолете карту — приложение сразу свалилось. Потому что разработчики не предполагали, что скорость может быть выше 120.
Казалось бы, зачем запускать карту в самолете? А что мешает? Может, мне хочется посмотреть, где я лечу. Если не хочется обрабатывать такую ситуацию, всегда можно поставить в коде обходной вариант: если скорость выше допустимой, то считываем координаты на старте приложения и по кнопке «обновить».
Это всяко лучше краша приложения ))) Падающее приложение — это вообще фейл, я считаю. В мои временатрава была зеленее это был самый страшный и приоритетный баг.
Скорость 120 на трассе
Был такой случай — навигатор с отслеживанием трафика вылетал, если скорость превышали. Тоже не рассчитывали на 120-130, ведь «кто так ездить то будет?». Однако не все же по городу катаются, кто-то по магистрали летит.
Причем в Америке такая скорость — норма, у них есть выделенные трассы. Поэтому приложение крашилось у американских пользователей, а у нас мы это не могли отловить: в России так особо не поездишь.
Я, с одной стороны, не одобряю такую скорость. А с другой, краш навигатора в такой ситуации — это ОЧЕНЬ плохо. Потому что водитель обязательно отвлечется на телефон, увидев там ошибку. А отвлечение внимания от дороги на такой скорости может быть смертельно.
Резюме
Высокую скорость стоит проверять. И, разумеется, лучше это делать в эмуляторе, а не нагло превышать «во имя тестирования».
Может, исправлять баг и не станут, но нам как минимум надо знать, каким будет поведение системы в том же самолете. И если не дай бог приложение начнет терять данные (крашиться не сразу, а спустя пару минут) — это уже проблема и ее надо исправлять.
Потому что надо или поддерживать считывание высокой скорости, или отключать считывалку при превышении какого-то лимита. Чтобы хотя бы не тупить и не вылетать.
Потому что пользователь просто не вернется к приложению, если оно пару раз вылетит. Слишком много аналогов вокруг.
Казалось бы, зачем ставить в эмуляторе коэффициент 0,01? Ну плетемся мы аки черепашка, и что?
А то, что для медленного движения может быть слишком много промежуточных точек. И если приложение не умеет работать с памятью, то кирдык ему. Просто не осилит удержать «в голове» миллион промежуточных состояний.
Так что такой вариант тоже важно проверить!
Где:
Если приложение каким-то образом работает с вашими координатами, его надо тестировать на определение скорости. И не забыть про границы сверху и снизу. Что будет, если мы запустим приложение в самолете? Или, наоборот, будем очень медленно с ним плестись? В обоих вариантах возможны падения:
См также:
Debug-панель в тестировании мобильных приложений — видео от Арсения Батырова, где он рассказывает о тестировании мобилок, в том числе и GPX-путей через дебаг-панель приложения
PS: это выдержка из моей книги для начинающих тестировщиков как один из примеров использования граничных значений
GPX пути — это XML-файлы с последовательными координатами. Их можно загружать в эмуляторы мобильных, чтобы телефон думал, что он перемещается в пространстве с какой-то скоростью.
Полезно, если приложение считывает GPS-координаты для каких-то своих целей. Так оно само определяет, идешь ты, бежишь или едешь. А можно не бегать, просто скормить приложению координаты, выставить коэффициент их прохождения и тестировать, сидя в офисе.
Зачем тестировать? Приложения обычно сами расчитывают скорость — и потому могут падать. Например, карта в самолете может крашиться, потому что разработчики думали, что скорость максимум 120, а тут БАЦ, самолетик...
Обычная скорость
Просто задали координаты и эмулятор делает вид, что мы по ним передвигаемся. Даже если мы сидим себе в офисе и пьем чай
Обычное позитивное тестирование. Скажем, приложение расчитывает, где находится ближайший Старбакс. Можно ходить по улице и проверять, какие варианты он подсказывает. А можно начать с эмулятора, так будет быстрее.
Конечно, реальное тестирование ничего не заменит, но вдруг смена вашей позиции вообще никак не влияет на приложение, оно считывает координаты только при запуске? Зачем тратить время на прогулку, если такой баг можно было найти в офисе?
Высокая скорость
Тут самая соль и баги. Как обычно при поиске границ сверху, впрочем =)
Коллега рассказывал такие случаи из жизни:
Самолет
Запустил в самолете карту — приложение сразу свалилось. Потому что разработчики не предполагали, что скорость может быть выше 120.
Казалось бы, зачем запускать карту в самолете? А что мешает? Может, мне хочется посмотреть, где я лечу. Если не хочется обрабатывать такую ситуацию, всегда можно поставить в коде обходной вариант: если скорость выше допустимой, то считываем координаты на старте приложения и по кнопке «обновить».
Это всяко лучше краша приложения ))) Падающее приложение — это вообще фейл, я считаю. В мои времена
Скорость 120 на трассе
Был такой случай — навигатор с отслеживанием трафика вылетал, если скорость превышали. Тоже не рассчитывали на 120-130, ведь «кто так ездить то будет?». Однако не все же по городу катаются, кто-то по магистрали летит.
Причем в Америке такая скорость — норма, у них есть выделенные трассы. Поэтому приложение крашилось у американских пользователей, а у нас мы это не могли отловить: в России так особо не поездишь.
Я, с одной стороны, не одобряю такую скорость. А с другой, краш навигатора в такой ситуации — это ОЧЕНЬ плохо. Потому что водитель обязательно отвлечется на телефон, увидев там ошибку. А отвлечение внимания от дороги на такой скорости может быть смертельно.
Резюме
Высокую скорость стоит проверять. И, разумеется, лучше это делать в эмуляторе, а не нагло превышать «во имя тестирования».
Может, исправлять баг и не станут, но нам как минимум надо знать, каким будет поведение системы в том же самолете. И если не дай бог приложение начнет терять данные (крашиться не сразу, а спустя пару минут) — это уже проблема и ее надо исправлять.
Потому что надо или поддерживать считывание высокой скорости, или отключать считывалку при превышении какого-то лимита. Чтобы хотя бы не тупить и не вылетать.
Потому что пользователь просто не вернется к приложению, если оно пару раз вылетит. Слишком много аналогов вокруг.
Медленная скорость
Казалось бы, зачем ставить в эмуляторе коэффициент 0,01? Ну плетемся мы аки черепашка, и что?
А то, что для медленного движения может быть слишком много промежуточных точек. И если приложение не умеет работать с памятью, то кирдык ему. Просто не осилит удержать «в голове» миллион промежуточных состояний.
Так что такой вариант тоже важно проверить!
Структура файла
Выглядит файлик примерно вот так:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="RouteConverter">
<metadata>
<name>Test file by Patrick</name>
</metadata>
<wpt lon="9.860624216140083" lat="54.9328621088893">
<ele>0.0</ele>
<name>Position 1</name>
</wpt>
<wpt lon="9.86092208681491" lat="54.93293237320851">
<ele>0.0</ele>
<name>Position 2</name>
</wpt>
...
<wpt lon="9.867439849679859" lat="54.93392326167919">
<ele>0.0</ele>
<name>Position 9</name>
</wpt>
</gpx>
Где:
- <wpt lon="9.860624216140083" lat="54.9328621088893"> — широта и долгота
- <ele>0.0</ele> — высота над уровнем моря
- <name>Position 1</name> — имя элемента
Резюме
Если приложение каким-то образом работает с вашими координатами, его надо тестировать на определение скорости. И не забыть про границы сверху и снизу. Что будет, если мы запустим приложение в самолете? Или, наоборот, будем очень медленно с ним плестись? В обоих вариантах возможны падения:
- Скорость слишком быстро меняется, не осилил перестроиться;
- Скорость меняется медленно, получаем много промежуточных точек, а работать с памятью не умеет — кирдык.
Проще всего использовать для проверки GPX пути, меняя коэффициент его прохождения.
См также:
Debug-панель в тестировании мобильных приложений — видео от Арсения Батырова, где он рассказывает о тестировании мобилок, в том числе и GPX-путей через дебаг-панель приложения
PS: это выдержка из моей книги для начинающих тестировщиков как один из примеров использования граничных значений
Комментариев нет:
Отправить комментарий