Вот если бы вы для каждого определения указали какие авторы придерживаются этого определения… а так, это ненаучный подход ;)
Я видел такие книги по тестированию, которые придерживаются академической манеры, но они бесполезны когда нужно ответить себе на вопрос «а что нужно протестировать (а что не нужно)» и «а как мoжно это протестироватъ».
Это также бесполезно как дискуссии на тему «Что мы делаем за тестирование?», юнит, системное или интеграционное. Да, называй как хочешь — ты качество давай. Программа или соответствует ожиданиям пользователя или нет. Определения не добавляют качества в продукт.
Ну и кроме того, теоретическую базу по методологии проведения тестирования хорошо дает Design of Experiments (DoE), как мне кажется. На пользу этих знаний для тестировщика например J.Bach указывал.
За год работы я добился от нашей автоматизации того, что если тест падает, он указывает на действительную проблему в системе. Я не делаю насильственной популяризации автоматизации в проекте, но добился за год того, что ко мне приходят и спрашивают, можно ли функцию автоматически протестировать, я пишу им для этого тест. (Или говорю, мол, нет, слишком затратно, или что тест не будет стабильным). Или после изменений разработчики прогоняют UI-тесты через локальную сборку (DevBuild) и сравнивают результаты на регрессию. Для меня все это хороший знак.
Инструментт тестирования у нас в принципе простой, но никто не хочет этим заниматься помимо основной работы. Да и я видел какие разработчики пишут юнит-тесты, не надо на них вешать автоматизацию :) У меня даже есть гипотеза, что разработчики подсознательно не видят крайних случаев, потому что мозг знает что если их увидеть, то это выльется в дополнительную работу.
я конечно подозреваю, что отсутствие каких-то функцкий не обязательно обусловленно отсутствием идей, а, вполне возможно, сложностью их достойной реализации.
Про отсутствие виртуальных папок я тоже постоянно удивляюсь. Так же теггирование всех ресурсов, локальных, сетевых, и веб, чтобы потом, по тэгу, можно было быстро найти всю релевантную информацию (успех твиттера не в 140 знаках, а в парадигме хештега)
А чтобы теггирование работало на уровне веб ресурсов, можно завязать это на использование непопулярного интернет-эксплорера (майкрософт, алё, тут деньги валяются, подбираем) Письменные аннотации они ведь прикрутили.
Хотя недавно нарыл интересную программку tabbles.net — она вроде закрывает этот пробел. Но интеграция в системе работает через плагины, а не нативно, вот в чем дело.
Если вам нужно написать книгу, кого вы возьмете, того кто уже писал книгу или человека который в совершенстве владеет грамматикой языка? Смешно, да? А на деле, для крупных заказчиков важен сертификат.
У нас сениоров заставляли сдавать сетификат по яве, так они выли от бессмысленности вопросов. «В какой последовательности можно ставить слова в public static void main ()», помню мне коллега жаловался. «Я, — говорит, — последний раз писал main() восемь лет назад, в универе»
Вот за что я не люблю некоторые информационные ресурсы. Главное привлечь внимание общественности. А указать на что опираются заявления? Да ну зачем. И так ведь все ясно.
But it was after a bit of googling that I discovered Victoria Police had recently undergone a trial of a similar device, and the estimated cost of roll out was somewhere in the vicinity of $86,000,000.
«A bit of googling», Карл.
Скоро в источниках научных статей начнут писать гугл дот ком.
Как человек получивший высшее образование, я начинаю кипеть если заявления не подкреплены конкретным источником. Таблицы, выкладки, рассчеты, где это все. Да даже в школе ответ не засчитывали если не был указан путь решения.
Давайте я скажу, что могу сделать воздушное ружье из велосипедного насоса, которым можно убить (я в гугле проверил), а армия тратит миллиарды на военное оснащение. Ну звучит-то все это именно так. Лучше бы оригинал в статье просто скромно написал: «Вот, заинтересовало новостное сообщение <источник>. Запилил на js свой велосипед по распознаванию номерных знаков в картинке.»
И такую ситуацию можно смоделировать в коде теста.
Сервер не является частью приложения, но частью системы. Как и операционная система, браузер и пр. Нужно четко обозначить границы системы. И в этом вам помогут тесты. Замокать браузер не получится. Это исполняющая среда (Runtime Environment). Но можно обеспечить корректную коммуникацию и реакцию на всевозможные параметры запросов, в точках раздела сред. Тестировать сервер на нагрузку нужно отдельно от приложения. Задержку ответа сервера можно тестировать в модели приложения. Это поможет вам в дальнейшем проще анализировать проблемы, когда ясно на стороне какой из компонент возникает проблема. Но это все сферическая теория в вакууме, на практике для такого подхода просто нет времени.
В приниципе юнит-тесты могут служить инструментом моделирования. Если использовать TDD подход, то мы еще не знаем как будет реализован класс, какой шаблон проектирования мы задействуем и пр. но знаем чего от него хотим. Это его интерфейс. Под этот интерфейс мы пишем тест. Пишем мок имплементации для использования в тесте. А в тесте реализуем сценарии использования модуля. Таким образом можно избавться от ненужных вещей в модуле на этапе проектирования и сделать набросок модуляризации. Ведь когда мы пишем мок мы говорим себе например «вот тут я получаю данные от такой штуки которая может быть чем угодно, назовем ее DataProvider» — вот вам и интерфейс. А проектирование на интерфейсах — делает ваш код изначально менее зависимым от изменения его окружения.
Если бы мне пришлось проектировать какую нибудь архитектуру, пусть даже простую 3 ступенчатую, я бы не стал полагаться на то что могу мозгом обьять всю скрытую глубину задачи во всех ее проявлениях. Я бы сделал наброски применения этой архитектуры, только не в UML, а в коде, который можно гонять туда сюда и смотреть какие есть шороховатости.
Расскажу еще один пример из жизни. Я захотел, чтобы в наш инструментарий по UI тестированию прикрутили возможность генерации тестов на лету. Чтобы написал один тестовый шаблон, кинул в него данные, и меняешь только данные, а не копипастишь код. Такая фишка есть в том же junit, но в нашем инструменте ее нет. Ну так вот, чтобы разрабы смогли ее сделать я им предоставил набор тестов без использования этой функции и аналог с использованием. Т.е им нужно заставить работать мой код. Если все будет сделано правильно оба набора тестов будут выдавать идентичный результат.
В данном применении это вполне инструмент моделирования. Чем писать TLDR спецификации и долго мусолить на совещаниях, куда однозначней: «вот шаблон кода — заставь его работать».
Закроем на минуту один из наших внимательных глаз на то, что впринципе несколько утверждений в одном тесте вобщем спорная, а в большинстве случаев довольно «прохладная тема».
Какая польза от первого утверждения? Он оберегает тест от ситуациии когда тест пройдет несмотря на то что страница была изначально активна. Значит посылание текста в активную страницу тестом не распознается. Вопрос: а является ли это ошибкой? Если да, то это должно быть протестированно отдельно. Если нет, то это входное условие лишнее.
у меня как-то тимлид спрашивал в чем причины необходимости поддержки UI тестов. И одним из пунктов я тогда назвал то что тестируемое приложение является Runtime Environment для самих тестов. (и еще подумал тогда, что это довольно трудное для понимания заявление) Т.е. в тесте мы (слепо) полагаемся на правильную работу некоторых компонент, например, что кнопка которую нам нужно нажать активна. Кнопка в сценарии не является предметом теста, но ее правильная функцкия необходима для работы теста.
Меня и по сей день регулярно посещает мысль, что компоненты должны быть тоже протестированы перед тем как гонять сценарии. Но наша задача проверить работу нашей части приложения, а не проверять фреймворк и пр. Поэтому так и живем.
bbidox Артем, вот скажите, вы стали править тесты, чтобы избавить их от тавтологий. Результаты тестов изменились? К лучшему? К худшему? Вот о чем нам бы всем интересно было узнать. Может приведете интересный пример из ваших UI тестов? Потому что надуманный пример из статьи, действительно, не очень нагляден. А UI тесты как правило очень наглядны.
В некоторых ситуациях я пользуюсь принципом (как сам его называю) «слабого» или «достаточного» доказательства.
У нас в приложении есть плеер, который имеет режим смешивания. Необходимо убедиться что функция смешивания работает. Сначала нужно определить, что для меня будет достаточным доказательством. Как бы я тестировал руками? Выбрал бы трек из середины списка, включил режим смешивания, нажал на кнопку «следующий трек» и проверил что новый трек не является следующим по списку, и не является треком который мы изначально выбрали. Т.е. он «любой другой, кроме». Мы не проверяем работу рандомизатора, мы проверяем функцию приложения, на соответствие заявленному поведению. Этот тест не дает нам абсолютной гарантии верного поведения, потому что рандомизация может перестать работать после второго нажатия по кнопке «след. трек». Но оно достаточное, чтобы двигаться дальше по покрытию. Усилить тест можно потом, в случае необходимости, если будут прецеденты.
Чтобы не залезть в дебри и не начать тестировать совсем не то что нужно, в совершенно неоправданных объемах, а быстро двигаться вперед, порой помогает вслух спросить себя «что является предметом теста?».
Это я так (видимо неудачно) иронизирую по поводу того, что что для разработки под андроид нужно ведро инструментов, а для разработки под айос я про такую необходимость не слышал.
Вообще разработка на платформе java меня каждый раз вводит в ступор этим. Вроде кроссплатформенная (что подкупает), но при этом количество разношёрстных технологий, библиотек, интрументов и пр вокруг которые надо или полезно знать зашкаливает. Ни в одной экосистеме наверное такого нет. А может это и есть цена кроссплатформенности?
Короче, оффтоп. Прошу прощения.
Когда я только познакомился с Javascript (во времена Netscape) он был совсем не такой навороченый, а вполне понятный.
Хотя натуральные языки тоже изменяются, заимствуют конструкции из других языков и перестают быть похожими на себя в классическом виде.
Я видел такие книги по тестированию, которые придерживаются академической манеры, но они бесполезны когда нужно ответить себе на вопрос «а что нужно протестировать (а что не нужно)» и «а как мoжно это протестироватъ».
Это также бесполезно как дискуссии на тему «Что мы делаем за тестирование?», юнит, системное или интеграционное. Да, называй как хочешь — ты качество давай. Программа или соответствует ожиданиям пользователя или нет. Определения не добавляют качества в продукт.
Ну и кроме того, теоретическую базу по методологии проведения тестирования хорошо дает Design of Experiments (DoE), как мне кажется. На пользу этих знаний для тестировщика например J.Bach указывал.
Инструментт тестирования у нас в принципе простой, но никто не хочет этим заниматься помимо основной работы. Да и я видел какие разработчики пишут юнит-тесты, не надо на них вешать автоматизацию :) У меня даже есть гипотеза, что разработчики подсознательно не видят крайних случаев, потому что мозг знает что если их увидеть, то это выльется в дополнительную работу.
А чтобы теггирование работало на уровне веб ресурсов, можно завязать это на использование непопулярного интернет-эксплорера (майкрософт, алё, тут деньги валяются, подбираем) Письменные аннотации они ведь прикрутили.
Хотя недавно нарыл интересную программку tabbles.net — она вроде закрывает этот пробел. Но интеграция в системе работает через плагины, а не нативно, вот в чем дело.
У нас сениоров заставляли сдавать сетификат по яве, так они выли от бессмысленности вопросов. «В какой последовательности можно ставить слова в public static void main ()», помню мне коллега жаловался. «Я, — говорит, — последний раз писал main() восемь лет назад, в универе»
«A bit of googling», Карл.
Скоро в источниках научных статей начнут писать гугл дот ком.
Как человек получивший высшее образование, я начинаю кипеть если заявления не подкреплены конкретным источником. Таблицы, выкладки, рассчеты, где это все. Да даже в школе ответ не засчитывали если не был указан путь решения.
Давайте я скажу, что могу сделать воздушное ружье из велосипедного насоса, которым можно убить (я в гугле проверил), а армия тратит миллиарды на военное оснащение. Ну звучит-то все это именно так. Лучше бы оригинал в статье просто скромно написал: «Вот, заинтересовало новостное сообщение <источник>. Запилил на js свой велосипед по распознаванию номерных знаков в картинке.»
Сервер не является частью приложения, но частью системы. Как и операционная система, браузер и пр. Нужно четко обозначить границы системы. И в этом вам помогут тесты. Замокать браузер не получится. Это исполняющая среда (Runtime Environment). Но можно обеспечить корректную коммуникацию и реакцию на всевозможные параметры запросов, в точках раздела сред. Тестировать сервер на нагрузку нужно отдельно от приложения. Задержку ответа сервера можно тестировать в модели приложения. Это поможет вам в дальнейшем проще анализировать проблемы, когда ясно на стороне какой из компонент возникает проблема. Но это все сферическая теория в вакууме, на практике для такого подхода просто нет времени.
Если бы мне пришлось проектировать какую нибудь архитектуру, пусть даже простую 3 ступенчатую, я бы не стал полагаться на то что могу мозгом обьять всю скрытую глубину задачи во всех ее проявлениях. Я бы сделал наброски применения этой архитектуры, только не в UML, а в коде, который можно гонять туда сюда и смотреть какие есть шороховатости.
Расскажу еще один пример из жизни. Я захотел, чтобы в наш инструментарий по UI тестированию прикрутили возможность генерации тестов на лету. Чтобы написал один тестовый шаблон, кинул в него данные, и меняешь только данные, а не копипастишь код. Такая фишка есть в том же junit, но в нашем инструменте ее нет. Ну так вот, чтобы разрабы смогли ее сделать я им предоставил набор тестов без использования этой функции и аналог с использованием. Т.е им нужно заставить работать мой код. Если все будет сделано правильно оба набора тестов будут выдавать идентичный результат.
В данном применении это вполне инструмент моделирования. Чем писать TLDR спецификации и долго мусолить на совещаниях, куда однозначней: «вот шаблон кода — заставь его работать».
исходник на гитхаб
Закроем на минуту один из наших внимательных глаз на то, что впринципе несколько утверждений в одном тесте вобщем спорная, а в большинстве случаев довольно «прохладная тема».
Какая польза от первого утверждения? Он оберегает тест от ситуациии когда тест пройдет несмотря на то что страница была изначально активна. Значит посылание текста в активную страницу тестом не распознается. Вопрос: а является ли это ошибкой? Если да, то это должно быть протестированно отдельно. Если нет, то это входное условие лишнее.
Меня и по сей день регулярно посещает мысль, что компоненты должны быть тоже протестированы перед тем как гонять сценарии. Но наша задача проверить работу нашей части приложения, а не проверять фреймворк и пр. Поэтому так и живем.
У нас в приложении есть плеер, который имеет режим смешивания. Необходимо убедиться что функция смешивания работает. Сначала нужно определить, что для меня будет достаточным доказательством. Как бы я тестировал руками? Выбрал бы трек из середины списка, включил режим смешивания, нажал на кнопку «следующий трек» и проверил что новый трек не является следующим по списку, и не является треком который мы изначально выбрали. Т.е. он «любой другой, кроме». Мы не проверяем работу рандомизатора, мы проверяем функцию приложения, на соответствие заявленному поведению. Этот тест не дает нам абсолютной гарантии верного поведения, потому что рандомизация может перестать работать после второго нажатия по кнопке «след. трек». Но оно достаточное, чтобы двигаться дальше по покрытию. Усилить тест можно потом, в случае необходимости, если будут прецеденты.
Чтобы не залезть в дебри и не начать тестировать совсем не то что нужно, в совершенно неоправданных объемах, а быстро двигаться вперед, порой помогает вслух спросить себя «что является предметом теста?».
Вообще разработка на платформе java меня каждый раз вводит в ступор этим. Вроде кроссплатформенная (что подкупает), но при этом количество разношёрстных технологий, библиотек, интрументов и пр вокруг которые надо или полезно знать зашкаливает. Ни в одной экосистеме наверное такого нет. А может это и есть цена кроссплатформенности?
Короче, оффтоп. Прошу прощения.
Хотя натуральные языки тоже изменяются, заимствуют конструкции из других языков и перестают быть похожими на себя в классическом виде.