Как чисто визуальное "казнить можно помиловать" втолковать автомату?

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

Пример обнаруженной глазами при ручном тестировании неувязки (предложите любой другой пример):



Радиобаттон, обеспечивает выбор одного из вариантов. Визуально выглядит, будто выбрано несколько вариантов. Это баг. Он был найден случайно вручную. Вопрос: как автоматизировать поиск такого типа багов?

Комментарии (33)

RSS свернуть / развернуть
+
0
А можно сначала втолковать людям, что на вашей магической картинке?
avatar

Vader

  • 23 января 2010, 03:29
+
0
2. Другой пример визуально проявляющегося бага: элементы на странице перекрывают друг друга при некоторых вполне типичных масштабах страницы. Как проверять автоматическим тулом, то есть чтобы человек даже «не смотрел что у него получилось»?
avatar

korziner

  • 23 января 2010, 15:02
  • ↑
+
0
Скажите, а что вы подразумеваете под «визуально проявляющимся багом»? Баг UI?
Если так, то я вам в стопятисотый раз повторяю — то, что на вашем первом скрине — не баг UI, а самый настоящий функциональный баг, вызванный наличием индокода. И никаких проблем, в обнаружении его средствами автоматизации, быть не должно.

По поводу второго скрина… Автоматически такие баги не ловятся, ибо автоматические тулы не имеют чувства прекрасного и не могут вам сказать — красиво или некрасиво.
Да и к чему подобное стараться поймать автоматически? Любой самый захудалый тестировщик найдет этот баг, а любой самый захудалый верстальщик вставит в верхний див min-width. После чего динозавры сидящие за мониторами 640х480 смогут радостно перемещаться по сайту, бодро скроля его влево и вправо.
avatar

Vader

  • 23 января 2010, 22:14
  • ↑
+
+1
1. Что подразумеваю под «визуально проявляющимся багом»? Да, естественно баг UI. Но не всякий баг UI, а только (по любой причине, например из-за халатности индуса, «статический анализ мог бы») прошедший через фильтр анализатора кода и дошедший до уровня тестирования черного ящика. Черный ящик = «не смог придумать вразумительных способов допустить такой баг».
По причине недокуренного хтмл.
Или не вижу в черном ящике закрытого кода с багами.
Или не вижу и не начинал курить HTML7.1 января 2017 года, но мой авто-баголов должен эффективно находить баги на страничках через 6 лет.

Да, оба моих примера плохие. Пример Алексея community.software-testing.ru/uploads/images/f/1/6/5/96/dc66c32dd7.jpg лучше иллюстрирует проблему поиска неувязок, которые пока обнаруживаются только "посмотрев, что у программиста получилось".

2. По поводу второго скрина. Автоматически такие баги возможно ловятся, ибо автоматическим тулам для этого не надо иметь чувства прекрасного. Примерный алгоритм:
Скриншоты на десятках разрешений + ocr + сравнение с эталонным текстом страницы дает первое неложное срабатывание + отсутствующие в словаре «ильтр» и «б. 700» второе срабатывание.

Если мои примеры плохие, приведите свои примеры проявляющегося на GUI бага, автоматический поиск которых труден (но возможен). Желательно не косметику, а критические.
avatar

korziner

  • 24 января 2010, 20:17
  • ↑
+
+1
Честно говоря не очень понимаю что вы хотите сказать этой заметкой и этим коментарием в частности.

Толи вы говорите о «дестких» ошибках, которые легко найти с полувзгляда и возмущаетесь тем, что их не нашел программист писавший код. Ну так это бывает. А бывает, что у программиста все хорошо работало, а кто-то потом что-то где-то подкрутил…

Толи вы хотите чтобы какой-нибудь чудо инструмент автоматизированного тестирования находил ошибки неверного отображения элементов на ХТМЛной странице сам, без вмешательства тестировщика. Что на мой взгляд как-то нереально. Да и ваша вторая картинка с «ильтром» для меня выглядит как кусок нормальной веб-страницы, с выпавшим поп-ап рекламным сообщением про «Ближайшие».

И по поводу сравнения картинок, подумайте, сколько вам придется сделать шаблонных картинок для сравнения для одного и того же экрана программы когда UI окончательно не зафиксирован и каждый день происходят изменения.
avatar

LeshaL

  • 24 января 2010, 21:50
  • ↑
+
0
Идея с OCR мне кажется весьма интересной. Возникло желание попробовать :)
avatar

barancev

  • 24 января 2010, 22:42
  • ↑
+
0
Смайлик выражает скепсис, поскольку OCR пока не совершенны?
avatar

korziner

  • 25 января 2010, 12:28
  • ↑
+
0
Вовсе нет. В этом мире всё несовершенно.
А смайлик выражает желание попробовать :)
avatar

barancev

  • 25 января 2010, 15:56
  • ↑
+
0
Я, наверно, не буду комментировать, то, что вы написали, т.к. мои мысли чуть менее чем полностью совпадают с тем, что написал Leshal.

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

Vader

  • 24 января 2010, 23:05
  • ↑
+
0
Что за наезды на институты!
Ну вот я работаю в институте — ispras.ru/
И что? :)
avatar

barancev

  • 25 января 2010, 15:59
  • ↑
+
0
Да не волнуйтесь вы так, это не наезды :)

О том, что вы работаете в институте я знаю, но я об этом где-то прочитал. Просто так вряд ли догадался бы. А вот насчет korziner'a я не знаю наверняка, но его посты очень похожи на посты человека, который работает в институте. Вот я и проверяю, не потерял ли я еще сноровку в обнаружении институтских работников :)
avatar

Vader

  • 25 января 2010, 16:30
  • ↑
+
0
О, хороший пример в тему! Какие эвристики используюте для визуального обнаружения институтского работника и как их автоматизировать? Поделитесь шаблоном «поста человека, который работает в институте»? Если сможете втолковать автомату, то Ваша сноровка точно не потеряется. (Разве только актуальнось потеряет, ибо работники мутируют) :)
avatar

korziner

  • 25 января 2010, 16:42
  • ↑
+
0
Какие эвристики используюте для визуального обнаружения институтского работника и как их автоматизировать?

Нутром чую ;)
Если честно, думаю, что если я вам расскажу о своих «эвристиках», то вы будете очень сильно обижаться.
А Баранцев, в знак солидарности с институтскими работниками, того и гляди забанит :)
avatar

Vader

  • 25 января 2010, 17:04
  • ↑
+
0
Валяйте! Не обижаюсь по жизни. Не бойтесь, попрошу не банить. Скажу аффтар сам нарывался.
avatar

korziner

  • 25 января 2010, 17:12
  • ↑
+
0
Да я, как бы, не особо и опасаюсь :)
По моим личным наблюдениям, огромная часть институтских работников очень сильно оторвана от жизни и практической деятельности.
Они знают много умных слов и вворачивают их в разговор к месту и не к месту, даже если совершенно не ориентируются в предмете разговора, при этом абсолютно не представляя, как это реализовать на практике, а главное зачем. При этом, чужую точку зрения они обычно не воспринимают совсем, т.е. даже не пытаются проанализировать то, что им сказали.
Отакэ ;)
avatar

Vader

  • 25 января 2010, 18:36
  • ↑
+
0
Почему не хочу? Хочу! В институте не работаю, не аспирант, а «кто еще»: учусь немножко в Политехе, и онлайн, работаю тестировщиком черного и серого ящика с мобильными и корпоративными веб-приложениями на java. Когда стало скучно вручную тестить, решил почитать теорию и посмотреть как и чем другие ловят баги. Аспирантские семинары были слишком давно, тогда мы пытались автоматизировать процесс естественного вывода (автоматическое доказательство).
avatar

korziner

  • 25 января 2010, 17:11
  • ↑
+
+3
Ааа… сходил по урлу с картинки. В жизни бы не догадался, что вы хотели сказать.
Вобщем, рекомендую убрать кучу страшных тегов и курить хтмл.

<input type=«radio» name=«HideEmail» value=«1» >Скрыть email
<input type=«radio» name=«ShowEmail» value=«0» checked>Показывать email
<input type=«radio» name=«SiteEmail» value=«2» >Разрешить отправку email через сайт

avatar

Vader

  • 23 января 2010, 03:40
+
0
Эммм… пару вопросов.
1. А зачем автоматизировать поиск багов? Правильнее все же автоматизировать модель поведения пользователя, имхо.

2. Почему вы упорно считаете, что в этом случае:
Радиобаттон, обеспечивает выбор одного из вариантов. Визуально выглядит, будто выбрано несколько вариантов.

Я ж даже код написал…
Чтобы было понятнее, возьмите код ниже, сохраните в .html файл, потыцкайте на кнопочки и посмотрите, что будет передаваться в гете:
<html>
 <body>

 <form action="/" method="get">
  
          <input type="radio" name="HideEmail" value="1" >Скрыть email
	  <input type="radio" name="ShowEmail" value="0" checked>Показывать email
	  <input type="radio" name="SiteEmail" value="2" >Разрешить отправку email через сайт
    
      <input type="submit" value="Сохранить">
    
 </form>
 
 <form action="/" method="get">
  
          <input type="radio" name="Email" value="1" >Скрыть email
	  <input type="radio" name="Email" value="0" checked>Показывать email
	  <input type="radio" name="Email" value="2" >Разрешить отправку email через сайт
    
      <input type="submit" value="Сохранить">
    
 </form>

 </body>
</html>

Думаю, будет очевидно, где и сколько вариантов выбирается.

З.Ы. Человек, который написал то, что у вас по ссылке либо не смотрел что у него получилось, либо он индус. Если вас на работе преследуют подобные баги — бегите с этой работы.
avatar

Vader

  • 23 января 2010, 14:25
+
0
1. А зачем автоматизировать поиск багов? Правильнее все же автоматизировать модель поведения пользователя, имхо.

Вообще-то одно другому не мешает, можно автоматизировать и то и другое. Статический анализ кода, поиск уязвимостей, внутренний мониторинг с автоматической отправкой сообщений о сбоях в приложении — всё это не требует автоматизации модели поведения, но помогает найти баги.
avatar

barancev

  • 24 января 2010, 16:23
  • ↑
+
0
Да, тут вы правы. Посыпаю голову пеплом :)

Возможно, надо бы уточнить вопрос: зачем автоматизировать поиск таких багов? Тем более, с помощью тула указанного в тегах.
Кстати, подозреваю, что статический анализ мог бы такой баг поймать. Не такая уж сложная задача, имхо. Ну я в этом не спец… пока-что ;)
avatar

Vader

  • 24 января 2010, 16:55
  • ↑
+
+1
Обыкновенно такие штуки автоматизируются следующим способом:
1. Формулируем эвристику.
2. Формализуем её и автоматизируем.
3. Запускаем этот авто-баголов.
4. Анализируем вручную результаты его работы.

Рассмотрим на данном конкретном примере.
1. Эвристика: если несколько радиобаттонов расположены рядом друг с другом, они должны составлять группу.
2. Формализуем.
а) «образуют группу» = «имеют одинаковые значения атрибута „name“
б) „несколько“ = „2 или больше“
в) „расположены рядом друг с другом“ — это сложнее, но тут тоже можно применить некоторые эвристики — теги идут непосредственно друг за другом, или в элементах списка (ul, ol), или в ячейчках таблицы (по строкам или по столбцам) или… или… или…

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

3. Запускаем.
4. Анализируем вручную, потому что возможны ложные срабатывания. И чем более сложную эвристику „рядом“ мы сформулируем, тем больше вероятность ложных срабатываний. А чем менее сложную — тем больше вероятность пропуска бага. Такова жизнь :)
avatar

barancev

  • 24 января 2010, 16:47
+
0
Рассмотрим на данном конкретном примере.

Мне кажется, что в данном случае, достаточно только условия — «атрибут name каждого тега input не уникален в пределах одной формы», а сложные условия «рядом» для отлова этого бага ни к чему. Или я ошибаюсь?
avatar

Vader

  • 24 января 2010, 17:23
  • ↑
+
+2
По моему, в случае радиобатонов все просто с эвристикой — если есть в модели (на странице, на форме) группа радиобатонов, в которой только один элемент — то она бессмысленна.
А стоят ли радиобатоны в группе рядом или нет и определить-то не всегда можно, если проходить по HTML-ной модели документа каким-нибудь автоматизированным тулом. Да и не важно это на самом деле.

А вот почему автор заметки относит такой дефект к ошибкам в UI совершенно не понимаю. Вполне себе функциональная проблема (а точнее проблема с программистом, который, похоже, впервые в жизни пытался создать группу радиобатонов).
avatar

LeshaL

  • 24 января 2010, 21:38
  • ↑
+
0
Согласен, предложенное правило (отсутствие «одиноких» радиобатонов) является хорошим уточнением. Но всё таки не менее важно убедиться, стоят они рядом или нет (хотя и трудно, согласен). Потому что если не стоят — это подозрительно.
avatar

barancev

  • 24 января 2010, 22:25
  • ↑
+
+1
Я-таки думаю, что програмное обеспечение, предназначенное для людей, должны тестировать люди. Иными словами, гуй автоматизировать нельзя, или можно, но очень ограниченно.
avatar

rlabs

  • 27 января 2010, 01:20
+
0
Внимание человека-тестировщика — ограниченный ресурс. Поэтому хорошо, если есть инструмент, который помогает привлечь внимание к подозрительным местам. Но я не зря написал в своём комментарии выше пункт 4.
avatar

barancev

  • 28 января 2010, 11:36
  • ↑
+
0
я тоже склоняюсь к мнению, что автоматизированное тестирование через гуй — это не есть хорошо. Когда-то это было неизбежным злом, но сейчас это уже менее актуально. Внутреннюю логику, ошибки программирования можно и нужно проверять на уровне кода (юнит-тестирование, тестирование через апи и паблик интерфейсы итп), а то, что относится к гую, должно проверяться человеком. Во-первых, на разработку и поддержку этих скриптов тратится столько времени (я еще не видел ни одного приложения, где б в новой версии не менялся интерфейс :) ), что зачастую быстрее все равно проверить руками, а во-вторых, существует огромное количество проблем, которые гуи-автоматизацией все равно не будут найдены — и придется проверять вручную.
avatar

freiman

  • 28 января 2010, 12:48
  • ↑
+
0
Многие (но не большинство) видят веб-приложения, где в новой версии интерфейс меняется не настолько существенно, чтоб перестали работать хорошо написанные авто-тесты.

Мне на курсах говорили, что если автоматизация требует в 20 раз больше времени, чем вручную, то выбираем вручную. С другой стороны вручную скучно, fun ведь тоже фактор :)

Что мешает разработанными скриптами делиться (вынося конфиденциальную и прочую специфику в его модуль)? Не утверждаю, что ничто не мешает, а спрашиваю, что мешает делиться.
avatar

korziner

  • 28 января 2010, 13:14
  • ↑
+
0
1) Пользователь работает с приложением именно через гуй. И тестирование в любом случае должно будет проводится через гуй (речь сейчас о вебе).
Тестирование напрямую через апи-шмапи в обход гуя может обернуться 100%-ой работой апи-шмапи, но при этом гуй может оказаться мертвым. Тестировать через гуй все равно придется. А зачем проверять одно и тоже дважды в одном цикле тестирования? Вы не сможете оправдать такие затраты перед своими руководителями и получите по башке, что будет (имхо) справедливо.
2) Автоматизация тестирования самого гуя не имеет смысла (выравнивания там всякие, резолюции и т.д.). А автоматизация тестирования функциональности в большенстве случаев через гуй делается, ибо эмулирует работу пользователя. Опять же, если цена (в ресурсах) автоматизации тестирования будет велика, а roi ничтожно — имеет ли смысл вообще проводить автоматизацию? Тем паче если гуй не устоялся да к тому же будет менятся от версии к версии.

ЗЫ: Перед тем как автоматизировать какие-либо тесты надо провести анализ необходимости данной автоматизации. За «фан» фан платить не будут.
avatar

KonstantinGud

  • 28 января 2010, 17:49
+
0
1) гуй может оказаться мертвым только в том случае, если мы его вообще не проверяем, что, в общем-то, невозможно: в любом случае гуй будут смотреть. Да, тестировать через гуй необходимо, но вопрос в другом: что именно мы тестим через гуй — логику работы классов, компонентов? или же удобство использования, отсутствие именно интерфейсных ляпов, понятную логику? Никто не говорит, что надо тестировать дважды. Я хочу сказать, что не надо делать все одним способом, а осуществить часть автоматизации через программные интерфейсы.
2) иногда автоматизация именно гуя может быть полезной — например, сравнение сайта на разных браузерах: сделал скриншоты для проверки — и вперед, скрипт ходит по нужным страницам и сравнивает с эталонными :) но, конечно, это частный случай.
avatar

freiman

  • 29 января 2010, 00:03
  • ↑
+
0
Простите, но я перестал вас понимать. У меня сложилось впечатление, что вы рассуждаете чисто теоретически (возможно я ошибаюсь).
1) Через гуй вы тестируете ровно то, что нужно пользователю, не меньше.
Опять же, не надо разные типы тестирования валить в одну кучу. Я говорю о функциональном тестировании. Про «логику работы классов» не понял. Вам функциональную логику надо проверять.

2) А если еще добавить различные разрешения экрана; различные операционные системы + различные версии операционных систем — автоматизация отправляется прямо в топку. Гораздо дешевле глазами проверить.

ЗЫ:
Вы так и не обьяснили:
1) почему автоматизированное тестирование через гуй — это есть зло?
2) в каких случаях при тестировании веб-приложения необходимо тестировать апи интерфейсы (и какие)?
avatar

KonstantinGud

  • 29 января 2010, 13:39
  • ↑
+
0
я думаю, стоит отделить гуи-тестирование дескотпных и веб-приложений.

Насчет веба я ничего сказать не могу, т.к. не занимался им. Возможно, автоматизация тестирования веб-приложений через гуй — хороший вариант.

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

Мне кажется, будет лучше, если из цепочки «Скрипт — гуй — код» убрать гуй и автоматизировать тестирование кода, а тестить гуй руками.
avatar

freiman

  • 3 февраля 2010, 14:01
  • ↑
+
+1
Не думаю.
Нужно выбрать тот тул, который может определить эти контролы. За достаточно долгое время (для меня) не имел особых проблем с определением контролов.
Не хочу вас огорчать, но у тестировщика такой цепочки быть не может.
Если вы тестировщик, то вам надо работу приложения тестировать, а не код. А если вы к тому же и не проф. программист, то тестирование кода превратиться в бесполезное занятие с тратой времени впустую.
Вы опять путаете, не гуй тестировать, а функционал через гуй.
Тулы автоматизации функционального тестирования как раз для этого и предназначены, но ни как не для тестирования кода и «логики классов».
Расскажите пожалуйста, что такое автоматизация функционального тестирования не через гуй?
avatar

KonstantinGud

  • 3 февраля 2010, 17:20
  • ↑

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.