Базовый минимум для тестировщика WEB-приложений

Имеется большая вероятность того, что в ближайшее время мне прийдётся сменить место работы, а следственно и специфику проверяемых продуктов в том смысле, что тестировать, скорее всего, прийдётся web-приложения, поск. бОльшая часть вакансий в моём городе именно для тестировщиков web-приложений. И хотя тексты вакансий содержат определённые требования, хотелось бы знать о некотором минимально допустимом уровне владения прикладными знаниями, как то HTML/CSS/JS(JS-framework)/какой-то язык програмиирования.

Иногда бывает принципиально важно понимать, как хранятся данные, какими путями они с сервера к браузеру и обратно ходят, и каким образом данные трансформируются (если такое и происходит).

Если будете знать, как и из чего собирается страница сайта - хорошо. Если не будете знать - пофигу. Не в технологиях дело.

HTML/CSS/JS/какой-то язык програмиирования - это нужно знать программистами. Вам, как эмулятору конечного пользователю, какое дело до того, на чем написано приложение и как оно "внутри" работает?! :)

Иногда считается, что тестировщик должен знать SQL - просто так знать, без привязки к местности. Если в требованиях к кандидату знание SQL не указано - то и знать этот язык незачем, пользователи взаимодействуют с браузером без SELECT * where...

HTML/CSS/JS/какой-то язык програмиирования - это нужно знать программистами

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

Благодарю за ответ.

HTML/CSS/JS/какой-то язык програмиирования - это нужно знать программистами. Вам, как эмулятору конечного пользователю, какое дело до того, на чем написано приложение и как оно "внутри" работает?! :)

Думается мне, что знание интернет-технологий существенно помогает проектировать тесты.
Конечно, глубокое знание синтаксиса HTML5 врядли является необходимым, но понимание базовых принципов, отличия сайтов HTML и PHP/ASP, работы с кукисами, кеширования js файлов разными браузерами и т.д. необходимы для грамотного тестирования веб-сайтов (ИМХО, конечно).

Иногда бывает принципиально важно понимать, как хранятся данные, какими путями они с сервера к браузеру и обратно ходят, и каким образом данные трансформируются (если такое и происходит).

Если будете знать, как и из чего собирается страница сайта - хорошо. Если не будете знать - пофигу. Не в технологиях дело.

HTML/CSS/JS/какой-то язык програмиирования - это нужно знать программистами. Вам, как эмулятору конечного пользователю, какое дело до того, на чем написано приложение и как оно "внутри" работает?! :)

Иногда считается, что тестировщик должен знать SQL - просто так знать, без привязки к местности. Если в требованиях к кандидату знание SQL не указано - то и знать этот язык незачем, пользователи взаимодействуют с браузером без SELECT * where...

То, что можно спокойно всё тестировать и без дополнительных знаний - согласен. Только это будет пользовательское тестирование со всеми вытекающими. Ну почти пользовательское :)

2автор: минимального набора знаний нет, каждый его по своему представляет. К тому же - ручное тестирование web-приложений это одно, а нагрузочное\автоматизированное\тестирование БД\etc - это другое. Так что, я бы посоветовал разбираться с проблемами по мере их поступления. Что от вас во время работы потребуется, то и изучать.

То, что можно спокойно всё тестировать и без дополнительных знаний - согласен. Только это будет пользовательское тестирование со всеми вытекающими. Ну почти пользовательское :)

Дык уточнений о профиле тестирования не было. Отсюда делаем вывод о том, что речь идет о "Здравствуйте, я просто тестировщик вашего сайта!"

То, что можно спокойно всё тестировать и без дополнительных знаний - согласен. Только это будет пользовательское тестирование со всеми вытекающими. Ну почти пользовательское :)

Дык уточнений о профиле тестирования не было. Отсюда делаем вывод о том, что речь идет о "Здравствуйте, я просто тестировщик вашего сайта!"

Неоднократно вижу проблемы, связанные с "просто тестированием". Чаще всего они проявляются в избыточном, неоправданном тестировании (а ведь это не значит, что тестирование становится лучше - это значит, что не остаётся времени на более важные проверки!).

Применительно к веб: в одной крупной компании тестировщики меряли производительность сайта "по-взрослому": 20 раз перезапускали 1 и тот же тест и считали среднее значение. УмнО, но на сайте были проблемы с загрузкой скриптов: первый раз качалось ОЧЕНЬ долго, 19 последующих операции выполнялись быстро. "Среднее значение в пределах нормы, а пользователи почему-то жалуются!"

Если бы они знали, как отключить кеширование скриптов, то не пропустили бы слонячьи скрипты, узкий канал и вытекающие проблемы с производительностью.
ИМХО, знание архитектуры ПО и используемых технологий НЕОБХОДИМЫ для эффективного тестирования.

ИМХО, знание архитектуры ПО и используемых технологий НЕОБХОДИМЫ для эффективного тестирования.

Ну дык!

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

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

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

Если тратить всё рабочее время на походы в соседние здания, то бит и кляпов не запасёшься. Учесть кеширование как отдельный фактор, влияющий на производительность - знаааачительно эффективнее, чем изображать тупого пользователя и проверять всё что влиять может и не может и не должно и не будет.

Чаще всего проблемы нехватки знаний проявляются в избыточном, неоправданном тестировании (а ведь это не значит, что тестирование становится лучше - это значит, что не остаётся времени на более важные проверки!).

Если бы они знали, как отключить кеширование скриптов, то не пропустили бы слонячьи скрипты, узкий канал и вытекающие проблемы с производительностью.
ИМХО, знание архитектуры ПО и используемых технологий НЕОБХОДИМЫ для эффективного тестирования.

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

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

...исполняемые скрипты со стороны сервера не кешируются....

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

но на сайте были проблемы с загрузкой скриптов: первый раз качалось ОЧЕНЬ долго, 19 последующих операции выполнялись быстро.

Перечитал. Да. Вы правы. Если например это js скрипты которые подгружаются в броузер - то они в броузере кешируются.
Но с точки зрения сервера js - это не скрипт а просто текст. Мерять прозиводительность броузером сомневаюсь что лучшее решение.

отдача статики из кеша может работать на порядок быстрее, чем с диска.

опять-же со стороны сервера статика - это результат работы скрипта. Можеть быть вариант когда например какой-нибудь cgi.exe кешируется где-нибудь в памяти процессора...

Мне стыдно за то что писал раньше. Подумав понял, что я очень плохо разибраюсь в кешировании...

опять-же со стороны сервера статика - это результат работы скрипта. Можеть быть вариант когда например какой-нибудь cgi.exe кешируется где-нибудь в памяти процессора...

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

Но я имел в виду то, что даже "настоящую" статику -- js-код, css-файлы, картинки и другие медиа-данные -- тоже кешировать иногда выгодно, потому что из кеша контент отдаётся быстрее. Операции чтения данных с диска крайне медленные, поэтому если пользователи часто загружают какую-то картинку (например, на главной странице новостного сайта, в топ-ньюс) -- её выгодно закешировать на серверной стороне, держать в памяти постоянно и отдавать непосредственно из памяти, не перечитывая каждый раз с диска.

Но я не стану утверждать, что знание таких деталей относится к "базовому минимуму" для тестировщика веб-приложений :)

Если это "настоящая" статика, то выгодно использовать сервер созданный для отдачи статики, например nginx или lighttpd. В этом случае конечно же будет кэширование, например файловый кэш.
Для динамических данных получаемых от сервера лучше использовать специальный кэш, информация в котором "портится" достаточно быстро.

Если это "настоящая" статика, то выгодно использовать сервер созданный для отдачи статики, например nginx или lighttpd. В этом случае конечно же будет кэширование, например файловый кэш.

Я тоже так думал до недавнего времени :) Но оказывается, что иногда и этого недостаточно. За последнее время мне попались на тестирование два проекта, где были специальные CDN для отдачи статики. Причём в одном проекте это были тысячи мелких картинок-аватарок, а в другом -- фильмы. И в обоих использовалось кеширование наиболее часто запрашиваемого контента в памяти, в первом проекте для мелких картинок использовался memcaсhed, а во втором был сделан самописный кеш, в котором хранились в памяти порезанные на куски фильмы-"бестселлеры".

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

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

nginx. Шарить можно и через файловую систему. Но там дело было не в шаринге, все аватарки отдавались с одного сервера, а именно в том, что часто используемые картинки дешевле считать один раз с диска и потом в памяти держать. Чистой воды кеширование.

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

nginx. Шарить можно и через файловую систему. Но там дело было не в шаринге, все аватарки отдавались с одного сервера, а именно в том, что часто используемые картинки дешевле считать один раз с диска и потом в памяти держать. Чистой воды кеширование.

Надо думать, мемкэш работал на одной машине с nginx-ом. Интересно, этот вариант сравнивался с вариантом использования только дискового кэша, насколько я понимаю, разницы в производительности практически не будет, при правильной настройке этого самого кэша, естественно :).

Доброго времени суток, коллеги! :) Ну и баталии разгорелись
Далековато от базового минимума, как по мне. Хочется, чтоб эта тема была полезна для кого-то ещё, кроме меня.

HTML/CSS/JS/какой-то язык програмиирования - это нужно знать программистами. Вам, как эмулятору конечного пользователю, какое дело до того, на чем написано приложение и как оно "внутри" работает?! :)

Зависит от специфики, но протоколы и какие-то базовые вещи вроде HTML знать все же стоит. Гражданин Виттакер давно уже написал что между вами как эмулятором конечного пользователя и собственно продуктом стоит куча всякого добра в котором неплохо было бы хоть как-то разбираться чтобы понимать что вообще может случиться с продуктом. Опять же какой-то человеческий фидбек разработчикам поставить можно будет и избежать бесполезной работы потому что кеш почистить забыли приступив к тестированию новой версии.