Комментарии 9
В избранное. Спасибо.
Речь докладчика несколько скомкана.
На слайдах черного цвета невозможно прочитать темно синие ссылки.
В целом неплохо.
На слайдах черного цвета невозможно прочитать темно синие ссылки.
В целом неплохо.
Спасибо. Полезно.
Мы на данный момент тестировали свое приложения по большей части в ручную.
Мы на данный момент тестировали свое приложения по большей части в ручную.
Отличный доклад, так держать, Степа!
А мы в одной компании использовали Perl+MonkeyRunner
А во второй Calabash.
А во второй Calabash.
Спасибо за то что поделились опытом. Но у меня есть несколько вопросов и уточнений, если что-то не учитываю или неправильно понимаю, поправляйте:
Весь доклад, по сути говорит о том, что при тестировании Вы занимаетесь покрытием только того, что касается графического интерфейса, делая скидку на то, что среди всего этого могут всплыть баги, ведущие к низкоуровневым проблемам.
Robotium — это фреймворк для тестирования черного ящика и то что Вы используйте только его для тестирования своих приложений, как я понял из доклада, обусловлено только тем, что в процессе разработки Вы сваливаете весь процесс тестирования на Ваших QA, которые не знают всех нюансов написанного кода, а в особенности того, что происходит внизу, и соответственно вынуждены работать с черным ящиком. Это очень спорный момент, по мне, так гораздо больше багов можно выявить если написанием тестов занимается помимо QA сам разработчик, который знает где и что в коде может всплыть. Компромиссный вариант — white box тестирование с использованием Robolectric за разработчиком, а затем black box тесты с помощью Robotium+Spoon от QA. Хотя тот же Square, который сделал Spoon вполне обходится им в связке с Robolectric.
И еще один момент — на приведенной диаграмме процесса разработки непонятно, где происходит процесс устранения багов, найденных в ходе тестирования.
Весь доклад, по сути говорит о том, что при тестировании Вы занимаетесь покрытием только того, что касается графического интерфейса, делая скидку на то, что среди всего этого могут всплыть баги, ведущие к низкоуровневым проблемам.
Robotium — это фреймворк для тестирования черного ящика и то что Вы используйте только его для тестирования своих приложений, как я понял из доклада, обусловлено только тем, что в процессе разработки Вы сваливаете весь процесс тестирования на Ваших QA, которые не знают всех нюансов написанного кода, а в особенности того, что происходит внизу, и соответственно вынуждены работать с черным ящиком. Это очень спорный момент, по мне, так гораздо больше багов можно выявить если написанием тестов занимается помимо QA сам разработчик, который знает где и что в коде может всплыть. Компромиссный вариант — white box тестирование с использованием Robolectric за разработчиком, а затем black box тесты с помощью Robotium+Spoon от QA. Хотя тот же Square, который сделал Spoon вполне обходится им в связке с Robolectric.
И еще один момент — на приведенной диаграмме процесса разработки непонятно, где происходит процесс устранения багов, найденных в ходе тестирования.
Спасибо за интересное видео.
А есть ли уже решение как тестить приложения типа чата? Например на одном девайсе отправить месседж, на другом проверить пришло оно или нет?
А есть ли уже решение как тестить приложения типа чата? Например на одном девайсе отправить месседж, на другом проверить пришло оно или нет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация тестирования Android-приложений с помощью Robotium и Spoon