Кроссбраузерность как раз и является наибольшей проблемой при тестировании, т.к. по стандартам можно и вслепую кодить. А вот если где-то под очередной Оперой что-то внезапно боком выползло, причём ещё три версии назад, то начинается "ой-ой-ой".
Т.е. необходимо функциональное тестирование в контексте конкретного и неидеального браузера-клиента, фактически заменяющее тыцающего мышью юзера.
У меня сейчас нет системы автоматизированного тестирования. Цель такая, что у меня под контролем около сотни различных живых сайтов, в основном тупых и мелких, но есть и большие и заумные, которые желательно время от времени мониторить, чтобы заказчики не натыкались на баги первыми :)
Репортинг нужен самый обычный, как во всех юнит-тестах, т.е. ЧТО и ГДЕ поломалось, если поломалось.
В основном из-за того что он никак не обходит (или я не нашёл, где это) запрет браузеров по кросс-доменному доступу. Ну и ещё потому, что разбираться там дольше чем своё писать :)
Unit-ы сейчас начинаю использвоать, но скорее просто из интереса, т.к. получаемые от них преимущества для меня приблизительно равны стоимости внедрения. У меня много мелких проектов, за которыми надо централизовано следить. Selenium не подошёл из-за того, что его надо на каждый сайт внедрять специально.
Никак. Решение — подразумевать наличие ClearType или иного сглаживания, а кто без него, тот сам виноват. Потому, что при создании страницы надо руководствоваться семантикой отображения, а уже как эту семантику трактовать при рендеринге — проблемы клиента. Тоже самое и с шрифтами.
Концепция HtmlUnit убила наповал :))) Тестирование веб-приложений под "эмулятором браузера", это видимо для тех кто пишет веб-приложения для эмуляторов браузеров, которыми будут пользоваться эмуляторы юзеров... :)
Попробовал... Не понравилось.
Все вышеперечисленные показали что проще тестировать руками или если уж совсем прижмёт, то написать свою систему для тестов :(
Юзабилити (эргономичность) — это свойство интерфейса, а не данных.
«the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use»
(отсюда)
Наличие данных / электричества / сигнала, это "контекст использования".
Не стоит путать контент/данные и юзабилити/представление. Если контента нет или он слабый, то это значит не то, что юзабилити почти нулевое, а только то, что контента нет или он слабый :) Если телекомпания прекратила вещание, то это не значит что у вашего телевизора изменилась эргономика.
Их там а)больше чем в IE, б)их сложнее обходить. Если в MSIE мы имеем дело только с безобидными лажами в трактовании CSS, то в Опере это именно злостные баги в DOM, JS, HTTP. Один только FF весь в белом :) Примеры (Opera 9.23) 1) неправильный эскейпинг двойных кавычек в работе с DOM/innerHTML; 2) Забывает перерисовывать элементы после присвоения им другого класса; 3) В некоторых случаях начисто игнорирует не только все HTTP директивы относительно кэширования, а даже изменение размера/даты файла.
Т.е. необходимо функциональное тестирование в контексте конкретного и неидеального браузера-клиента, фактически заменяющее тыцающего мышью юзера.
Репортинг нужен самый обычный, как во всех юнит-тестах, т.е. ЧТО и ГДЕ поломалось, если поломалось.
Все вышеперечисленные показали что проще тестировать руками или если уж совсем прижмёт, то написать свою систему для тестов :(
«the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use»
(отсюда)
Наличие данных / электричества / сигнала, это "контекст использования".