Перейти к содержимому

anr

Регистрация: 14 мая 2010
Offline Активность: 25 сен 2012 15:01
-----

Мои сообщения

В теме: Вопрос на собеседовании на который не смог найти ответа.

19 сентября 2012 - 14:48

Коллеги, узнала о себе кое-что новое: я могла бы работать за комплименты ))

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


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



- изначально неправильный подход того, кто проводил собеседование. Увы, такое встречается. Кто проводил собеседование? Руководитель компании или отдела тестирования?
Не взяли в такую контору - не велика беда )



На свое решение я потратила 40 минут.
Удалила вот почему: за обедом вдруг подумала, что, может быть, FreeMan1 очень тонко играет - хочет получить решение на свою тестовую задачку. Хотя, после первого прочтения условий такой мысли не возникло). FreeMan1, пожалуйста, простите мне мое недоверие!

Решение именно в том виде, как было, ниже,
но у меня появились новые мысли:
1) в тест-дизайне уделить внимание безопасности. Проверить, возможен ли тут аналог sql-инъекции. И как шифруются данные ; )
2) я указала, что не стала бы проверять для всех 59 потоков. Сейчас думаю, что я была не права. На практике сколько угодно случаев нелепых копи-пастов ; )

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


Именно таким никогда не занималась на работе, но интересно стало быстренько попробовать.

Первым делом, я бы спросила, есть ли подробная документация (говорят, это надо первым делом спрашивать на собеседовании : )). Видимо ответ будет: "это всё, что есть"

Я поняла условие так: есть функция f(бинарные данные; номер потока) - читает, перерабатывает, сохраняет данные - функция запускается при каком-то условии - по таймеру, или по размеру файлов на диске. Тут ещё хочется задать вопрос, с какими параметрами приложения может быть связь - вопрос к спецификации, аналитикам, разработчикам.

То есть, проверяем f(bin,i) и scheduler(?). Плюс, считаю, нужно и нагрузочное тестирование.

Что делать:

1. Разворачиваем окружение.
Сервер, на котором работает приложение: установка OS, ftp server, database, тестируемого приложения, конфигурация. Машина, с которой будут идти тестовые данные. Сетевой интерфейс между ними.

[часов 16 надо - учитывая риски, что админов не окажется на месте и всё такое. Возможно, в живом проекте всё это уже есть, и этот шаг пропустится]

2. Тест-дизайн.
Чтение с диска: размеры файлов, блокировки...
f(bin,i) - чтобы написать идеи, надо знать, каким образом перерабатываются данные перед сохранением в таблицу. Наверно, я бы сказала, что для каждого i специально проверять не буду )
сохранение данных в таблицу
scheduler

При составлении тест-дизайна формируются и требования к эмулятору входных данных - след. пункт.

[Зависит от процессов компании. Написание тест-кейсав - часов 20, подробный план тестирования - часов 10]

3. Создание эмулятора потоков входных данных - например, java, генерация данных в нужном формате и сохранение, возможно, запуск эмулятора по таймеру. Написание, отладка, тестирование.

[написание: 6 часа, доделка, отладка, проверка, со всякими рисками - 10 часов. Итого - 16]

4. Выполнение тестов

[функциональные тесты - 8 часов, нагрузочные - вообще не знаю )) , рассуждать буду так: отладка + калибровка + отработка - часов 8 человеческого присутствия, плюс выполнение - часов 20, в том числе ночью.]

5. Оформление, анализ результатов

[функциональные тесты - 2 часа, нагрузочные - опять не знаю )) , кажется миллион, но отвечу 6]

По времени получилось 50-90 часов


В теме: Вопрос на собеседовании на который не смог найти ответа.

19 сентября 2012 - 05:40

FreeMan1, напишите всё-таки, как Вы рассуждали.

В теме: Учусь писать test cases, нужна тренировка

11 ноября 2011 - 08:58


проверки на устойчивость к кросс-сайт скриптингу (по скольку все-таки веб-приложение)


А поподробнее?)


своими словами )

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

Пример: у меня в закладках elefant.ru (давно нашла на него ссылку где-то в инете, но его за долгие годы не починили). Попробуйте поискать, например, <input type=button onclick=alert('Hack')>, и увидите, что код выполнится, а не отобразится "как есть".

Почему это надо проверять?
Вроде для поля логина это не критично, если, конечно, этот логин не будет виден другим пользователям. НО! Никогда нельзя знать наверняка :acute: И доверять никому нельзя :acute:
Например, бывает, что некоторые серверные фреймворки без правильной конфигурации и корректной обработки просто не пропускают такие данные на сервер, и приложение просто падает.
Важно смотреть, как такой код будет отображаться на разных страницах.

В теме: Учусь писать test cases, нужна тренировка

11 ноября 2011 - 05:02

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

Что касается тестовых случаев, то не хватает дублирования логина и др параметров, проверки на устойчивость к кросс-сайт скриптингу (по скольку все-таки веб-приложение), и со служебными символами я бы предложила другой вариант (см тут: http://blog.shumoos.com/archives/67) + отдельно проверка того, что в логине нет второй собаки.

При выборе требований к логину при отсутствии документации я бы руководствовалась стандартами протокола. К примеру, лично для меня спорно, что длина логина ограничена 30 символами, ведь протокол позволяет 64, так же и недопустимость ввода подчерка (_), ведь протокол "не против". По-моему, это повод поспорить с аналитиками :friends: