Задать вопрос
lxsmkv

Alexej Simakov

Test automation engineer
Ответы пользователя по тегу Тестирование ПО

  • В программисты или в тестировщики (идти)?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Предлагаю вам проверочное задание-шутку для профориентации:
    Посмотрите на этот
    юнит-тест
    public class ListMapTest {

    @Test
    public void testListMap() {
        ListMap<String, String> listMap = new ListMap<String, String>();
        listMap.put("bob", "hello");
        assert "hello".equals(listMap.get("bob"));
        assert "hello".equals(listMap.remove("bob"));
        assert listMap.size() == 0;
        assert listMap.isEmpty();

        listMap.put("abc", "1");
        listMap.put("def", "2");
        listMap.put("ghi", "3");
        listMap.put("jkl", "4");
        listMap.put("mno", "5");
        assert "3".equals(listMap.get("ghi"));
        assert listMap.size() == 5;
        assert !listMap.isEmpty();

        // check iteration order, should be consistent
        for (int i = 0; i < listMap.size(); i++) {
            String expectedValue = Integer.toString(i + 1);
            String key = listMap.getKey(i);
            String value = listMap.getValue(i);
            Entry<String, String> entry = listMap.getEntry(i);
            assert key.equals(entry.getKey());
            assert value.equals(entry.getValue());
            assert expectedValue.equals(value);
        }
    }
}


    (из опенсорсного игрового движка jmonkeyengine .)

    Что можно в нем улучшить ?

    Варианты ответов:
    1. ничего
    2. использовать junit
    3. разбить на несколько тестов и добавить недостающие проверки


    Ключ: если вы ответили 1. или 2. - вам в разработчики.
    Ответ написан
    1 комментарий
    1 комментарий

  • Анализ граничных значений для условия "строго больше"?

    lxsmkv
    @lxsmkv
    Test automation engineer
    4 можно не проверять (как и 6 в первом случае). Просто понимание больше или больше-равно у многих программистов такое же как понимание индекса в массиве, казалось бы самые основы, но на практике одна из самых частых ошибок, (я и сам подтормаживаю на этой теме когда не выспался)
    Давайте разберем на примере. Люблю примеры.
    Допустим у нас минимальная длина пин-кода в первом случае минимум 5 символов, во втором случае минимум 6 символов. Как только набрано необходимое количество символов кнопка "ок" становится активной.
    Чтобы проверить первый случай, нужно ввести 4 символа и убедиться что кнопка не активна, ввести пять символов и убедиться что кнопка активна.
    Чтобы проверить второй случай нужно ввести 5 символов и убедиться что кнопка не активна и ввести 6 символов и убедиться что кнопка активна.

    Ну и еще максимальное значение нужно проверить раз уж на то пошло (maxInt+1 для некоторых языков критичен) либо в примере с полем ввода максимальное количество символов.

    Вернемся к примеру с полем ввода. Допустим поле из-за програмной ошибки изначально содержит два невидимых символа.
    Мы вводим в первом случае 3 знака и кнопка ОК становится активной, хотя не должна.
    Так что граничные значения это все теория, без которой никуда, но чтобы найти баги надо понимать устройство компонент и принципы их взаимодействия и отталкиваться от этого знания. На чисто механистическом подходе далеко не уедешь.
    Ответ написан
    Комментировать
    Комментировать

  • Как добиться независимости в тестах (phpunit)?

    lxsmkv
    @lxsmkv
    Test automation engineer
    я в основном делаю ui тесты и у меня некоторые тесты связаны друг с другом. конечное состояние первого теста является начальным сосотоянием следующего. Например первый тест "зайти в формуляр" а следующий за ним "ввести данные в первую строку" а затем тест "ввести данные во вторую строку" а потом "нажать на отправку данных" а потом "тест сообщения об отправке". Естественно если первый тест завалится, завалятся и все после него, хотя реальная проблема только одна. Единственный серьезный недостаток такого подхода, это возможное перекрытие ошибок. Т.е. в билде может сломаться заход в формуляр, и отображение сообщения об отправке. Вторая проблема будет перекрыта первой.
    Но меня устраивает такой подход по следующим соображениям.
    - Если что-то сломалось в приложение надо в первую очередь чинить приложение, а не писать тонны дополнительного тестировочного кода.
    - Тестировочный код тоже код, чем его больше тем больше вероятность сделать ошибку в нем.
    - Лучше потратить время на увеличение покрытие пользовательских сценариев, чем на создание красивой и каноничной автоматизации.
    - Зависимые тесты выполняются быстрее, (а у нас время тестирования билда во всех вариациях уже перевалило за 16 часов)
    - Чинить по одной ошибке за раз - хорошо, пытаясь починить сразу несколько можно сломать что-то еще.

    Для того чтобы такой подход работал более менее чисто, я например стараюсь сдвигать все проверки в конец теста, уменьшая таким образом вероятность того что вылетевшее исключение не доведет приложение до нужного состояния для последующего теста.

    Но это все не по вашему вопросу. По вашему вопросу - да, писать тонны моков (не нужно). У меня например есть тесты которые проверяют как данные от железа передаются в api графического клиента. при проверке фунцкионала графического клиента, я опираюсь на корректную работу api графического клиента, поскольку им пользуюсь. Так же я опираюсь на корректную работу виджетов. И если какие-то условия не будут работать многие ui тесты посыплются. Мы найдем причину и устраним ее. Чтобы в таком случае падал только один тест, который специально сделан для нахождения этой ошибки, вам придется отвязать тестируемую компоненту от всех внешних зависимостей. Теоретически написав столько же кода сколько в самом приложении. Вы готовы к этому?

    P.S.: стоит добавить: наш тест-фреймворк выполняет тесты в алфавитном порядке и не поддерживает параллельное выполнение в принципе.
    Ответ написан
    Комментировать
    Комментировать

  • Как в зависимости от ссылки, сказать behat тесту на какую ссылку кликать?

    lxsmkv
    @lxsmkv
    Test automation engineer
    bdd тесты (как в прочем любые идеальные автоматизированные тесты) не приемлют разветвлений. каждый вариант ссылки это отдельный тест.
    сначала вы делаете setup а потом проверяете. никакой зависимости от входных данных в тесте быть не должно. зависимость от входных данных может быть перед тестом.
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно использовать инкапсуляцию в Page Object паттерне?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Если интерфейс контроллера предназначен для простых смертных, лучше писать функции общего плана с параметрами. Так вы сведете к минимуму возможность ошибочного использования. Например чтобы выбрать предмет из списка его нужно сперва раскрыть раскрывание будет производиться внутри общей функции напр. selectItemFromListMatchingName(String n) путем вызова приватной функции openItemList() а она будет использовать приватную функцию isListOpen() чтобы не открывать уже открытый список. Править такие тесты очень легко. Вы чините код в одной маленькой функции один раз. И все тесты которые опираются на нее чинятся автоматически.
    Ответ написан
    Комментировать
    Комментировать

  • Чем можно протестировать работу поискового движка на корректность выдаваемых им результатов?

    lxsmkv
    @lxsmkv
    Test automation engineer
    зависит от требований которые закладывались в систему поиска.
    - толерантность к опечаткам - подмена символа или нескольких в строке
    - одинаковый ответ при одинаковом запросе.
    - реакция на длинный запрос (пытается ли она найти пересечения)
    - взять два ключевых слова в одной и обратной последовательности (я ввожу "sony apple" и "apple sony" но система выводит только продукты apple, наверно так не должно быть)
    - порог соответствия, что результаты ниже определенного требованиями порога не выводятся. (пишу "пленка" выводятся только 10-15 результатов и далеко не все продукты содержащие слово "пленка" - наверное так не должно быть)
    - как реагирует алгоритм если в базе очень мало записей? А если очень много записей с очень высокой схожестью?

    Чем тестировать ? У вас есть api, берите jmeter шлите через аpi запросы и проверяйте ответы.
    Или не jmeter a другой интрумент для тестирования web api. в конце концов pycurl или python + curl вариантов достаточно. Первоочередная сложность не в инструменте а в определении требований к системе поиска.

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

    Или возьмите студента-тестировщика он вам быстрее найдет все серьезные недочеты если вам критичен скорый выход на рынок. А автоматизацию подтянете по ходу дела.
    Ответ написан
    Комментировать
    Комментировать

  • Есть ли книги по мануальному/автоматическому тестированию веб-проектов и прикладного ПО?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Для начинающих:
    "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах" (Роман Савин) - для тех кто хочет понять, а что же такое тестирование и зачем оно нужно. Написано очень доступным языком.

    Для продвинутых:
    "Lessons learned in software testing" (Kaner, Bach, Pettichord) - никакой воды только жизненные примеры что работает а что нет. Как не наступить на грабли. На эту книгу можно смело положиться на практике. Самому приходилось аргументировать не-тестировщикам сложности тестирования, и пригодилось очень.

    "A practitioner's guide to software test design" (Lee Copeland) - "Матчасть" так сказать.

    Это книги общего плана. Эти книги помугут научиться думать как тестировщик. По конкретным областям тестирования есть свои книги. Есть много других книг про тестирование, но я не могу их порекомендовать.

    Ну и конечно слушать лекции Джеймса Баха на ютубе. Он вообще вдохновил меня пойти в тестирование.

    И еще по автоматизации могу порекомендовать вики test automation patterns (Dorothy Graham) - просто "экстракт" практической пользы.
    Ответ написан
    Комментировать
    Комментировать

  • Как тестировать встроенные системы?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Как я упомянал в другом ответе https://toster.ru/answer?answer_id=1040391
    у нас в системе есть конфигурационные файлы, с флагами, эти флаги определяют при запуске системы какие части системы запускаются а какие нет. Т.е ПО в принципе поддерживает максимальную конфигурацию но путем флагов ее можно вариировать. Значение этих флагов можно опрашивать. Если знать как должна быть настроена система в идеале, то можно написать тесты проверяющие значение этих флагов.
    В принципе при тестировании настроек мы берем эталонные зачения и сравниваем с действительными, все довольно просто, но нужно написать файл с эталонными значениями. Это может быть дофига работы на несколько недель, но это окупится сторицей.
    И конечно тесты эти гонять перед релизом, т.е после сборки. Не до сборки, а после. Так вы сможете выявить проблемы в всей цепочке,чтобы не было такого что у разработчика на машине тесты зеленые, а сборка (внезапно) корявая.
    Ответ написан
    Комментировать
    Комментировать

  • Как тестируют прошивки мобильных телефонов?

    lxsmkv
    @lxsmkv
    Test automation engineer
    у нас в системе есть флаги на каждый поддерживаемый функционал, например есть ли GPS. таких флагов пару сотен.
    Каждый тест обернут в декоратор, если флаг включен то тесты требующие GPS выполняются, иначе пропускаются.
    Предварительная настройка выполняется перед тестом, например путем установки нужных параметров прямым доступом к системе (white box). Тесты у нас выполняются at runtime, путем рефлексии тестировочный фреймворк подключен к системе.
    Тесты выполняются для каждой принципиально отличной конфигурации устройства. например у нас более двадцати принципиально отличных конфигураций. получается простыня такая х тестов на y конфигураций.
    конкретно по машинам состояний есть model based testing (при наличии формального описания машины состояний может делать полный ее обход, в теории) есть например scxml для такого формального описания. однако по этой теме практическим опытом поделиться не могу, за неимением оного

    Если есть дополнительные вопросы, пишите.
    Ответ написан
    Комментировать
    Комментировать

  • Чем тетсировать android приложение?

    lxsmkv
    @lxsmkv
    Test automation engineer
    поищите "android test automation"
    Ответ написан
    4 комментария
    4 комментария

  • Какую вилку имеют специалисты по автоматизации тестирования?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Думаю от 50 до 200
    https://hh.ru/vacancy/20499815
    https://hh.ru/vacancy/20067315
    Возмите зарплату ручного тестировщика +30%-50%
    Ответ написан
    Комментировать
    Комментировать

  • Как систематически подойти к тестированию в малой компании разработчиков?

    lxsmkv
    @lxsmkv
    Test automation engineer
    систематическое тестирование начинается с наличия детальной спецификации. Если вы работаете по скраму, то при планировании спринта определяется что должно быть протестировано. Я сам в гибкой разработке не участвовал, но осмелюсь предположить по опыту, что на адекватную документацию тестовых сценариев, если тестировщику их придется писать самому, написание автоматизации к ним и отладку этой автоматизации может потребоваться больше времени чем на спринт. Можно попробовать BDD - т.е тест пишется на "естественном" языке и одновременно является и спецификацией, и приемочным тестом, тогда автоматизатору останется только заимплементировать шаги спецификации в коде. От таких спецификаций польза даже в том случае если вы не будете их автоматизировать. Такие сценарии можно проходить и вручную и вам будет ясно все ли сделано. И пользу от такого подхода можно выразить цифрами, например количество сценариев которые не были окончены к концу спринта.
    Ответ написан
    Комментировать
    Комментировать

  • Что нужно изучать, чтобы заниматься автотестированием web-приложений на Java?

    lxsmkv
    @lxsmkv
    Test automation engineer
    зависит от того на чем написано приложение которое вы тестируете. В зависимости от используемого стека выбирается инструмент. Нельзя просто сказать "хочу научиться пилить". В зависимости от того что у вас "system under test" пилить можно лобзиком, бензопилой, или циркулярной пилой. Давайте инфы побольше, получите более конкретный ответ.

    Upd.: для тестирования веб приложения с помощью Java через Selenium нужен Selenium - это и есть фреймворк который вам нужен. Туториалов по нему много. Изучать непременно надо само тестируемое приложение. Сперва задайте себе вопрос "что я хочу протестировать", а потом уже "как" (это реализовать с помощью Selenium)
    Ответ написан
    1 комментарий
    1 комментарий

  • Зачем нужно тестирование?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Если вы следуете парадигме ТДД то автоматически ставите наличие четкой спецификации, и архитектуры на первый план. И тем самым обеспечиваете себе отстуствие хаоса в разработке. Это моя основанная на личном опыте интерпретация. К сожалению мы не делаем ТДД и у нас хаос :)
    Ответ написан
    4 комментария
    4 комментария

  • Как называется такой подход к разработке, тестировани и баг-фиксу?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Спонтанное, не систематизированное "протыкивание" программы с целью нахождения дефектов называется ad-hoc testing
    Ответ написан
    Комментировать
    Комментировать

  • Ответственность за баги при нетривиальном поведении?

    lxsmkv
    @lxsmkv
    Test automation engineer
    я тестировал это все 1000 раз но эту комбинацию в голову не пришло сделать

    может имеет смысл принять на вооружение методику pairwise и инструмент PICT.
    По этой теме есть доклады, вот один из них для примера https://www.youtube.com/watch?v=Bqmuw3ZJ75g
    Цель методики заключается в том чтобы из бесчисленного количества возможных комбинаций выбрать те которые обеспечат максимальное покрытие, при минимальном наборе тестов.
    P.S. ну и автоматизация тестирования в обязательном порядке, если ее еще нет.
    Ответ написан
    Комментировать
    Комментировать

  • С чего начать изучение на должность QA автоматизатора?

    lxsmkv
    @lxsmkv
    Test automation engineer
    В автоматизации тестирования два главных вопроса: что? и как?
    Как - это связано с инструментами и возможностями тестировочной среды.
    Что - это что именно мы хотим протестировать?
    Часто на вопрос "что" - порой ответить сложнее чем на "как".
    Вопрос "что" абсолютно важен чтобы писать действительно полезные тесты.
    Ответ написан
    Комментировать
    Комментировать

  • Быть тестировщиком?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Тестировщики-автоматизаторы программируют, много, на скриптовых языках, и/или ranorex, hp qtp и т.д. или java .. вобщем какой язык инструмент поддерживает на том и программируют.
    Ручные тестировщики как правило не программируют вовсе. Однако технические навыки они должны иметь. причем широкие, но не глубокие. Но тоже смотря на какую задачу, если задача тестирования Программного Обеспечения требует калибровки спектрометра, он должен уметь калибрировать спектрометр. Такие специальные навыки однако приобретают обычно на месте. Т.е. быстрая обучаемость и тяга к новому - небходимое условие.

    Работа тестировщика ручного довольно однообразна, он каждый день проводит одни и те же "анализы"/тесты чтобы выявить отклонения. Работа автоматизатора веселее, ему нужно че-то там соображать, писать скрипт, разбираться в том как устроен инструмент, как устроена программа. Но и сложнее соответственно.

    Я освоился автоматизатором за пару-тройку месяцев, основная сложность по началу держать в голове все сложности и заковыристости программы, знать ее внутреннее устройство, и способы взимодействия с железом. Но это с временем приходит было бы желание. У меня еще например и так, что задачи мне никто не ставит, и тикетов никаких не пишет, т.е. я сам по себе работаю в меру возможностей. Тикеты пишу я, причем столько же сколько ручной тестировщик, и это помимо самой автоматизации. Иногда ковыряю код продукта, могу там что-нибудь накопать. У автоматизатора работа не кончается никогда, всегда есть что-то что можно доделать добавить переписать подправить., улучшить. Зато все уважают и даже порой побаиваются :)
    Заработок нормальный, серединка, даже больше чем у некоторых программистов.
    Ответ написан
    Комментировать
    Комментировать

  • Какой правильный подход к написанию тестов под задачу?

    lxsmkv
    @lxsmkv
    Test automation engineer
    когда вы пишите тест вы хотите знать если вдруг что-то пойдет не-так. Вы используете интерфейс, вы уверены что фунцкция этого интерфейса всегда делает то, что обещает по документации? А вы уверены что это будет так завтра и через год? Вы уверены что ваш код правильно реагирует на ответы которые приходят на ваши запросы по API? А как поведет себя код если формат ответа изменится? Все эти "а что-будет если" не из любопытства и духа экспериментаторства а от неизвестности и неуверенности.
    Когда ты ставишь свой код на "сигнализацию", стресса и неуверенности становится меньше, а информации больше. Можно проводить операции над кодом (рефакторинг) будучи уверенным, что если заденешь жизненно важный орган тебе об этом заморгает лампочка.
    Про ТДД ничего не могу сказать, мне тяжело думать шиворот-навыворот. Стремиться к этому наверно нужно, потому, что если ты можешь начать с тестов то значит спецификация у тебя жесткая, отлично закодокументированая, архитектура четкая - но в жизни к сожалению бывает и иначе, там где сначала пилим как придется, посмотрим что получится, и если это понравится заказчику - доведем до ума.

    П.С. помню как-то давно, когда только начинал изучать junit попробовал ради интереса написать на простенький класс-коллекцию тесты. Во-первых их получилось больше, чем мне казалось возможным на первый взгляд. Во-вторых, я не успел отъехать и на пятьсот строк кода, как уже тесты местами покраснели. Значит что-то задел и совершенно не обратил внимания. А казалось ну что можно напортачить в десяти классах. Можно.
    Ответ написан
    4 комментария
    4 комментария

  • Как создать отдел тестирования?

    lxsmkv
    @lxsmkv
    Test automation engineer
    первая мысль которая пришла в голову: если проблемы на стыке компонентов возникают, может сперва над архитектурой поработать?

    Тестирование ведь всего-лишь находит проявление ошибок. А желательно устранять причины приводящие к их возникновению. Иначе вы будете тратить все больше денег на то чтобы находить ошибки, релиз будет откладываться, клиенты будут недовольны задержками обновлений.
    Почитайте багтрекер на предмет, каковы причины найденых ошибок. Как правило есть несколько корней зла. Вот на это и стоит обратить внимание.

    У нас например ModelView слой программы выдает минимум треть ошибок, мы делаем автоматизацию, это дорого, а надо просто нахрен выкинуть тот инструмент которым мы делаем UI и перейти на что нибудь, что будет валидироваться у разработчика на компьютере а не завтра утром на сервере после полной сборки. Другое дело что на такой шаг начальство пойти не может, они в рабстве у вендора этого инструмента. Т.е. миграция возможна но не вдруг.
    Ответ написан
    Комментировать
    Комментировать