Ответы пользователя по тегу Модульное тестирование
  • Как написать тест, покрывающий 100% кода при двойной проверке условия?

    lxsmkv
    @lxsmkv
    Test automation developer
    Лучше написать обработку ошибки запроса к базе. От этого действительно будет польза.
    Например в указаной таблице нет желаемого поля, либо таблицу переименовали. Клиентский код перестанет работать.
    В остальном можно смело доверять драйверу базы, что он работает правильно, если вы посылаете правильные запросы. Если просили с ценой больше нуля, то и получите с ценой больше нуля. Проверять это не нужно.
    Ответ написан
  • Какие тесты на каких этапах развития проекта наиболее важны?

    lxsmkv
    @lxsmkv
    Test automation developer
    Да там все в кучу свалено: тормоз, фара, водитель, права, дорожный знак. Все понятия относящиеся к вождению индивидуального транспортного средства. Бррр..

    Есть подходы к тестированию (парадигмы, напр. TDD), есть методики для систематического подхода к покрытию тестами (pairwise, boundary). Есть разделение по стадиям разработки (alpha, beta). Категоризировать и писать определения можно сколько угодно.
    Вам нужно проверять работоспособность приложения на регулярной основе. Это, как правило, юнит тесты на сам код, и функциональные тесты на приложение (эмуляция пользователя). Функциональный от слова проверка функции фичи.
    Это обеспечивает какую-то степень распознавания регрессий. Ревью кода - тоже тестирование. И когда Вы запускаете программу чтобы убедиться, что то, что Вы написали работает - тоже тестирование. Только вы знаете какие проверки Вам нужнее всего.
    Ответье себе на вопрос: "В чем вы хотите каждый день, после каждой сборки, после каждого коммита, быть уверены?" Не надо писать тесты только потому, что все так делают. Надо понять какая Вам от них польза. И все встанет на свои места.
    Ведь проблема в чем, приложение растет, и со временем разработчик тестирует только ту часть приложения которую только что написал. А все старое перепроверяется гораздо реже. Так вот автоматизация при систематичном ее применении может Вам в этом помочь.
    Ответ написан
  • На каком языке пишут скрипты в QA?

    lxsmkv
    @lxsmkv
    Test automation developer
    Для всех основных языков есть драйвера/обертки/библиотеки/API для работы с базами данных и для отправки SQL запросов. Автоматизированные тесты часто пишут на скриптовых языках, они гибче и легче в изучении. (bash и powershell хоть и тоже скриптовые языки, имхо не легки в изучении. Это уже из области системного программирования)
    Если система на фреймворке, то на сайте фреймворка есть как правило документация как проводить юнит-тестирование для этого фреймворка.
    Когда говорят умение писать скрипты, я думаю подразумевают, что разработчик в имеет опыт с одним из ходовых скриптовых языков (php, python, ruby, groovy, js) и за короткое время (недели три-четыре) в состоянии изучить любой другой, на достаточном для выполнения задач уровне. Для человека с опытом программирования это как правило не проблема. Детали синтаксиса всегда можно в документации посмотреть.
    Ответ написан
  • Анализ граничных значений для условия "строго больше"?

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

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

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

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

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

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

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

    lxsmkv
    @lxsmkv
    Test automation developer
    рискну продположитъ если вы не можете на словах объяснитъ пользу юнит-тестирования, то и сами не до конца понимаете для чего оно нужно. Задача юнит тестирования -убедиться что самостоятельная часть программы ведет себя в соответствии с ожиданием, при разных внешних условиях. Не программистский пример - замок открывается ключом, при нормальной внешней температуре, при повышеной температуре и при низкой температуре. Дверь открывается при нормальной внешней температуре при повышеной и пониженой температуре, т.е. ее не заедает. Вы проверили оба "модуля" - замок и дверь по отдельности, еще до сборки. Таким образом при сборке вы будете иметь некую уверенность, что вся конструкция будет устойчива к перемене темературы. Вот так.
    P.S. что такой подход дешевле проверки всей конструкции после сборки и отгрузки клиенту, думаю - очевидно.
    Ответ написан
  • Как называется такой подход к разработке, тестировани и баг-фиксу?

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

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

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

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

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

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

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

    lxsmkv
    @lxsmkv
    Test automation developer
    если у вас нет спецификации, что будет т.н. оракулом? Т.е как вы определите это ошибка или так и надо. Например, вы ввели вместе с числами буквы, поле стерлось и не было показано никакого сообщения что ввод неверный. Это ошибка? А может так было задумано. Все что вы можете сделать это эксплоративное тестирование. Т.е впринципе вы можете протестировать только положительные сценарии, для негативных сценариев нет информации. Все что вы можете это предположить как оно должно работать.
    Так же вы ограничены в глубине тестирования. Чтобы сделать самые интересные тесты вам придется переводить деньги. Этого вы сделать не можете, и никто от вас этого потребовать не может.
    Но даже при отсутствии спецификации, можно конечно сделать сравнительное тестирование, задокументировать поведение системы на одном устройстве и посмотреть ведет ли себя система так же на другом.
    Составьте пользовательские сценарии. Подумайте какие цели ставит себе человек решивший воспользоваться таким сервисом, и может ли он достигнуть цели.
    Покопайтесь в компьютерных журналах, там часто проводят сравнительные тесты программного обеспечения и сервисов, посмотрите какие критерии выбирают они. Тестирование удобства пользования (UX) тоже тестирование.
    Но если просто решать задачу для галочки, проверить нужно валидацию ввода, для текстовых данных ввод букв разных алфавитов. Комбинаторные тесты можно делать. Если поля два, четыре варианта ввода (пустой ввод, слишком длинный ввод, неполный ввод, верный ввод) для одного поля и четыре для другого у вас уже получается 16 комбинаций.
    Можно проверить рудиментарные требования к безопасности, например использует ли сервис шифрованый протокол. Стираются ли поля при перезагрузке страницы, при откывании страницы заново.
    Думайте, задание для того и дано, чтобы вы тренировались думать как тестировщик, а не для того чтобы вы дали верный ответ.
    Ответ написан
  • Как наилучшим способом протестировать программу?

    lxsmkv
    @lxsmkv
    Test automation developer
    если система имеет интерфейсы и новый функционал строится используя имеющиеся интерфейсы, то "сломать" систему невозможно. Интерфейсы на то и интерфейсы.
    https://habrahabr.ru/post/30444/
    Ваша задача - гарантировать неизменность интерфейсов. Для этого нужно код покрыть юнит-тестами, которые бы указывали разработчикам если рефакторинг нарушает существующий интерфейс. Еще есть конечно опасения, что не имея представления об имеющихся функциях будут строить велосипед рядом. Но тут нужно предоставить документацию.
    Ответ написан
  • С чего начать в Тестировании и как получить полезный опыт?

    lxsmkv
    @lxsmkv
    Test automation developer
    Cem Kaner, James Bach, Lisa Crispin, Dorothy Graham, Наталья Руколь. Ютубьте, гуглите :)
    Ответ написан
  • Какие шаги тестирования сайта?

    lxsmkv
    @lxsmkv
    Test automation developer
    попытайтесь ответить для себя на вопрос "какой фунционал предоставляет веб сайт для посетителя". Увидеть функционал сперва может показаться трудным. Но при должном упорстве серая пелена спадет.
    Начинайте так:
    1) У пользователя есть возможность ознакомиться с историей компании.
    2) - ""-- "" создать учетную запись
    и.т.д.
    Каждый глагол в списке это и есть функционал, который нужно проверить. Для тестирования каждой предоставляемой функции может потребоваться разное количество тестов. В итоге нужно удостоверится может ли посетитель использовать заявленную фунцкию в достаточном обьеме. Обьем при этом определяете вы. По верхам или каждую мелочь. Начать конечно лучше по верхам, чтобы уже что-то тестировалось в то время как вы будете искать способы для детального тестирования.
    Ответ написан