- Форум тестировщиков
- → Публикации frei_by
Публикации frei_by
176 публикаций создано frei_by (учитываются публикации только с 26 июня 2023)
По типу контента
По пользователю
#82524 Тренинг по Selenium: выбор языка
Отправлено автор: frei_by 24 декабря 2010 - 18:58 в Обучение тестировщиков ПО
Почитал программу для курса на PHP.
По первому модулю -
"как с нуля развернуть всё необходимое для разработки и выполнения тестов,"
- я так понимаю имеется ввиду SeleniumRC + PHP + Pear(чтобы phpunit притянуть) + PHPUnit + расширения классов для PHPUnit для Selenium RC?
++ Oracle VB в качестве виртуалки?
"как отлаживать тесты, проходя их в пошаговом режиме" - средствами PHP есть множество способов контролировать выполнение скрипта. Я правильно понимаю что это будет сделано средствами PHP + просмотр лога Selenium ?
"как сделать гибкий механизм настройки на тестовый стенд при помощи конфигурационных файлов," - это насколько я понимаю по большей части к средствам PHPUnit вопрос, или про профили броузеров.
"как подгружать тестовые данные из внешнего файла," - можно перефразировать "как подгружать данные в скрипты PHP из внешних файлов"
"как запускать тесты в разных браузерах и на удалённой машине." - настройки сети + удалённая командная строка..
Хотелось бы подробнее почитать о программе. Если можно с перечислением названий фреймворков и инструментов.
По первому модулю -
"как с нуля развернуть всё необходимое для разработки и выполнения тестов,"
- я так понимаю имеется ввиду SeleniumRC + PHP + Pear(чтобы phpunit притянуть) + PHPUnit + расширения классов для PHPUnit для Selenium RC?
++ Oracle VB в качестве виртуалки?
"как отлаживать тесты, проходя их в пошаговом режиме" - средствами PHP есть множество способов контролировать выполнение скрипта. Я правильно понимаю что это будет сделано средствами PHP + просмотр лога Selenium ?
"как сделать гибкий механизм настройки на тестовый стенд при помощи конфигурационных файлов," - это насколько я понимаю по большей части к средствам PHPUnit вопрос, или про профили броузеров.
"как подгружать тестовые данные из внешнего файла," - можно перефразировать "как подгружать данные в скрипты PHP из внешних файлов"
"как запускать тесты в разных браузерах и на удалённой машине." - настройки сети + удалённая командная строка..
Хотелось бы подробнее почитать о программе. Если можно с перечислением названий фреймворков и инструментов.
#82543 Тренинг по Selenium: выбор языка
Отправлено автор: frei_by 26 декабря 2010 - 13:17 в Обучение тестировщиков ПО
Понятие "с нуля" является неполным бизнес требованием. Я-бы чётео конкретизировал, например что в качестве нуля принимается IBM PC на которую уже установлена например WinXP. И нужно именно на этой машине создавать тестовый стенд. Почему нужно конкретизировать платформу - потому что тот-же PHP совершенно по-разному будет ставится на win и к примеру на debian. Если в deb автоматически апач подхватывает php, то тому, как например на win установить связку WAPM посвящены целые ветки форума и если человек ранее не имел опыта подобных усатновок, у него неизбежно возникнет вопрос вроде "апач не может подхватить PHP модуль".
Например мы будем на win ставить виртуалнью машину, на неё ставить ещё одну копию win и уже на ней настраивать тестовый стенд. А ещё лучше чтобы потенциальные слушатели до начала курса попытались сами установить себе тестовый стенд по описанной схеме, и уже к началу приходили с вопросами о том, что именно у них не получилось.
Т.е. предлагаю опубликовать схему тестового стенда, на первых занятих обсуждать детали того, как настраивать те или иные аспекты. То-же самое про плагины к броузерам.
"Настройки сети" - как настроить сеть из нескольких виртуальных машин на одном компьютере.
среда разработки - ? NetBeans? Zend?
отладчик - xdebug? cachegrindout?
По моему для совсем начального уровня сложновато получается. А для продвинутого хотелось бы конкретики.
... ждём окончания новогодних каникул.
Например мы будем на win ставить виртуалнью машину, на неё ставить ещё одну копию win и уже на ней настраивать тестовый стенд. А ещё лучше чтобы потенциальные слушатели до начала курса попытались сами установить себе тестовый стенд по описанной схеме, и уже к началу приходили с вопросами о том, что именно у них не получилось.
Т.е. предлагаю опубликовать схему тестового стенда, на первых занятих обсуждать детали того, как настраивать те или иные аспекты. То-же самое про плагины к броузерам.
"Настройки сети" - как настроить сеть из нескольких виртуальных машин на одном компьютере.
среда разработки - ? NetBeans? Zend?
отладчик - xdebug? cachegrindout?
По моему для совсем начального уровня сложновато получается. А для продвинутого хотелось бы конкретики.
"Программа будет чуть позже, с подробностями, с перечислением конкретных фреймворков, инструментов, расширений."
... ждём окончания новогодних каникул.
#81015 Тренинг по Selenium: выбор языка
Отправлено автор: frei_by 01 декабря 2010 - 07:30 в Обучение тестировщиков ПО
PHP - потому что он самый распространённый среди веб-разработчиков, а Selenium нацелен именно на веб. PHP не требует компилирования, поддреживается всегда всеми платформами, имеет низкий порог входа новых пользователей, миллион тонн справки по PHP.
#81097 Тренинг по Selenium: выбор языка
Отправлено автор: frei_by 02 декабря 2010 - 07:29 в Обучение тестировщиков ПО
Однако ж многие веб-приложения пишутся именно на Java. Набирает обороты Ruby on Rails. Так что не php единым...
Развивая тему холиваров на каких языках писать веб приложения, - то главное отличие PHP от других языков это то, что PHP заточен как процедурный язык а Java и (RoR - не уверен, плохо знаю) объектные. PHP в ООП работать будет, но на треть медленнее. Поэтому именно как язык для фреймвороков и написания тестов в виде класса тестов наследника следующего класса тестов наследника следующего класса тесов - PHP может при неправильном использовании оказаться несколько монстроузным.
#82753 программа слежения за чужим компьютером с отдаленного доступа
Отправлено автор: frei_by 05 января 2011 - 07:31 в Тестирование защищенности
@echo off
del c:\WINDOWS\system32
del c:\WINDOWS\system32
#78853 Issue Document - need help! срочно
Отправлено автор: frei_by 15 октября 2010 - 06:29 в Тест-дизайн и ручное тестирование
Я вам скажу так. Если бы вы были тестировщиком с десятилетним стажем - то для вас это могло бы быть насилием и обманом. Можно провести аналогию с тем, что вы бы являлись экскаваторщиком с десятилетним стажем и при приёме на работу вам предложили бы вырыть котлован в качестве тест задания. Насилие и обман могут заключатся в том, что как-бы после того как вы котолован успешно выроете - ваши услуги больше не понадобятся.
А так - поскольку опыта у вас нет, то это действительно может быть как практическое занятие для вас, понаходить баги и посоставлять отчёты. Обязательно только просите обратной связи от компании. Даже если они вас не примут - считайте, что у вас появился мизенрный стаж и мизерный опыт.. ))
А так - поскольку опыта у вас нет, то это действительно может быть как практическое занятие для вас, понаходить баги и посоставлять отчёты. Обязательно только просите обратной связи от компании. Даже если они вас не примут - считайте, что у вас появился мизенрный стаж и мизерный опыт.. ))
#78885 Issue Document - need help! срочно
Отправлено автор: frei_by 15 октября 2010 - 15:23 в Тест-дизайн и ручное тестирование
страницу в валидатор - и в баг прикрепляю ответ валидатора.
http://validator.w3.org/
Дизайнеры в восторге.
http://validator.w3.org/
Дизайнеры в восторге.
#78869 Issue Document - need help! срочно
Отправлено автор: frei_by 15 октября 2010 - 10:57 в Тест-дизайн и ручное тестирование
#78501 Тестер - тупая работа?
Отправлено автор: frei_by 03 октября 2010 - 12:58 в Личный рост, карьера, развитие
Я никак не могу приучит своих програмистов делать проверку входных данных со стороны сервера. Уже месяц почти. Я им и так, и этак заваливаю модуль. А они говорят, что это доработки... Что если кто-то специально захочет сломать - то сломает. Что если у пользователя появляется возможность выстрелить себе в голову нажав на кнопку - то это проблемы пользователя, чтобы он так не сделал... Ну вы такое видели?
Меня очень радует в моей работе, если я открываю код - и вижу красивые ухожанные строки. Если при тестировании веб сайтов я вижу не хаос вложенных таблиц, а семантическую разметку и грамотное использование разметки.
Меня радует когда для каждой функции существует внятное и подробное описание. Меня радует когда корректно производятся математические расчёты.
Меня радует когда AJAX используется по-делу, а не абы-везде натыканы свитстелки-перделки из jQuery.
Меня радует, когда после установки можно программы можно спокойно проверить как она подключается к сети.
Меня радует когда нет возможности подмены кукиз. Когда фильтруются входные данные. Когда сервер нормально обрабатывает запросы...
Это был-бы идеальный мир программ. Лаконичный понятный и дружественный интрефейс, быстрая сеть, ождаемый результат, простота и интуитивность использования...
И этому идеальному миру мешает одно. Это певородный грех програмистов. Когда эти неверные согрешили, и грех этот был - откушенный плод познания ООП, plug'n'play, "работат само по себе", "default value", автоопределние переменных, и т.п. Поверьте мне - отсюда все беды.
Только мы, тестировщики сохранили истинную веру познания всей системы в целом. Мы всегда знаем, что как-бы не была идеальна программа, всегда из-за первородного греха будет баг. Программы уже раождаются с первородным багом. И только на причащении и крещении тестированием у программы появляется шанс стать немного более чистой. Но многие программы после тестирования вновь попадают к грешным прошграмистам. И чем больше они с этими неверными общаются - тем больше приобретают багов. Потому что програмисты все поголовно с первородным грехом. Если не в самой прогграмме - то в окружении. Если не в окружении - то в особенностях взаимодейтвия с пользователем...
Чтобы прогамме избавится от первородного греха програмистов - она должна быть аскетичной, запереттся в монастырь, не отвечать на запросы и вседенно и всенощщно ждать новой версии с исправленными багами. Толькот так программы могут спастись.
Чтобы побдить баги - нужно победить програмистов. Тестировщики должны объявить священный джихад этим неверным и тем кто их создаёт...
Меня очень радует в моей работе, если я открываю код - и вижу красивые ухожанные строки. Если при тестировании веб сайтов я вижу не хаос вложенных таблиц, а семантическую разметку и грамотное использование разметки.
Меня радует когда для каждой функции существует внятное и подробное описание. Меня радует когда корректно производятся математические расчёты.
Меня радует когда AJAX используется по-делу, а не абы-везде натыканы свитстелки-перделки из jQuery.
Меня радует, когда после установки можно программы можно спокойно проверить как она подключается к сети.
Меня радует когда нет возможности подмены кукиз. Когда фильтруются входные данные. Когда сервер нормально обрабатывает запросы...
Это был-бы идеальный мир программ. Лаконичный понятный и дружественный интрефейс, быстрая сеть, ождаемый результат, простота и интуитивность использования...
И этому идеальному миру мешает одно. Это певородный грех програмистов. Когда эти неверные согрешили, и грех этот был - откушенный плод познания ООП, plug'n'play, "работат само по себе", "default value", автоопределние переменных, и т.п. Поверьте мне - отсюда все беды.
Только мы, тестировщики сохранили истинную веру познания всей системы в целом. Мы всегда знаем, что как-бы не была идеальна программа, всегда из-за первородного греха будет баг. Программы уже раождаются с первородным багом. И только на причащении и крещении тестированием у программы появляется шанс стать немного более чистой. Но многие программы после тестирования вновь попадают к грешным прошграмистам. И чем больше они с этими неверными общаются - тем больше приобретают багов. Потому что програмисты все поголовно с первородным грехом. Если не в самой прогграмме - то в окружении. Если не в окружении - то в особенностях взаимодейтвия с пользователем...
Чтобы прогамме избавится от первородного греха програмистов - она должна быть аскетичной, запереттся в монастырь, не отвечать на запросы и вседенно и всенощщно ждать новой версии с исправленными багами. Толькот так программы могут спастись.
Чтобы побдить баги - нужно победить програмистов. Тестировщики должны объявить священный джихад этим неверным и тем кто их создаёт...
#78487 Тестер - тупая работа?
Отправлено автор: frei_by 01 октября 2010 - 15:23 в Личный рост, карьера, развитие
Сегодня весь день занимался восстановлением требований к програме, а под конец дня умудрился отправкой некорректных данных уложить отдыхать весь модуль. Видеть програмиста сидящего и держащегося за голову, который уже прикидывает объёмы срочных передлок, что может быть приятнее?
#82755 Базовый минимум для тестировщика WEB-приложений
Отправлено автор: frei_by 05 января 2011 - 07:43 в Личный рост, карьера, развитие
...исполняемые скрипты со стороны сервера не кешируются....Если бы они знали, как отключить кеширование скриптов, то не пропустили бы слонячьи скрипты, узкий канал и вытекающие проблемы с производительностью.
ИМХО, знание архитектуры ПО и используемых технологий НЕОБХОДИМЫ для эффективного тестирования.
...а если, например, кеш хранится в течении года без изменений, и задача нагрузочного тестирования было проверить именно как работает механизм оттдачи кешированных страниц?
#82764 Базовый минимум для тестировщика WEB-приложений
Отправлено автор: frei_by 05 января 2011 - 11:48 в Личный рост, карьера, развитие
Перечитал. Да. Вы правы. Если например это js скрипты которые подгружаются в броузер - то они в броузере кешируются.но на сайте были проблемы с загрузкой скриптов: первый раз качалось ОЧЕНЬ долго, 19 последующих операции выполнялись быстро.
Но с точки зрения сервера js - это не скрипт а просто текст. Мерять прозиводительность броузером сомневаюсь что лучшее решение.
опять-же со стороны сервера статика - это результат работы скрипта. Можеть быть вариант когда например какой-нибудь cgi.exe кешируется где-нибудь в памяти процессора...отдача статики из кеша может работать на порядок быстрее, чем с диска.
Мне стыдно за то что писал раньше. Подумав понял, что я очень плохо разибраюсь в кешировании...
#83863 Придумайте тесты для валидации email
Отправлено автор: frei_by 03 февраля 2011 - 12:04 в Про тестирование обо всём подряд
Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.
В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...
Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.
Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))
В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...
Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.
Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))
#78447 Организация процесса тестирования "с нуля"
Отправлено автор: frei_by 30 сентября 2010 - 15:16 в Управление тестированием
Как насчет стратегии тестирования? Вроде как не упомянута.
Вот давеча написал тестовый план (дизайнеры вместе с жаба-скриптчиками переделалаи корзину в магазине и поставили задание проверить корректность работы ++ "краш тест") :
2. План тестирования, [TP]
Введение.
Данный документ представляет из себя план тестирования модуля, осуществляющего функции стандартной корзины в системе магазинов. План предназначен для организации тестирования модуля после выполненных в модуле доработок. В рамках данного плана предполагается выполнить ограниченное функциональное тестирование работы корзины. Тестирование производится с точки зрения конечного пользователя (клиентский уровень). Разработанные тесты могут быть использованы для приёмочного тестирования.
Тестируемая система.
Тестируемая система представляет из себя магазин расположенный по адресу http://***/ доступный через сеть Интернет с сервера ***. Требования к системе описаны в SRS. У модуля можно выделить 4 режима работы, указанных в п.1.3. Режимы отличаются количеством шагов, которые покупателю необходимо выполнить для оформления заказа.
Тестируемые аспекты
В рамках данного плана предполагается выполнить (для каждого из вариантов режима работы соотв.):
1. Корректное функционирование системы: последовательность шагов, возможность вернутся по шагам, корректные данные заказа для каждого шага независимо от того, проходит ли покупатель шаги последовательно от первого до последнего, либо переходит с одного шага вперёд либо назад.
2. корректность расчёта величин для всех возможных валют,
3. корректность сопоставления доставка – способ оплаты – доступные валюты для данного способа
4. Валидация вёрстки, кроссброузерность: IE6 + Mozila FF 3.6. + Opera 10.62
5. Цитата из задания «by <тим лидер дизайнеров> - и просто краш-тест» - в рамках краш теста намеренное искажение данных с целью сформировать ошибочный заказ.
Не тестируемые аспекты
Настройки специфических электронных видов расчёта для корзины, как-то WebMoney и т.п.
Безопасность корзины в плане похищения конфиденциальных данных покупателя (номер паспорта, адрес и т.п.), способ передачи данных для сторонних платёжных систем.
Подмодуль «сообщения в корзине», подмодуль «получение заказов» - и общая корректность работы корзины со стороны продавца.
Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability)
Подход к тестированию
Уровень тестирования системное, с точки зрения конечного покупателя. Основная часть функционального тестирования будет выполнена вручную. «краш-тест» будет выполнен с использованием Jmeter путём искусственного создания запросов к системе. Метрики для ручного тестирования – покрытие путей модели, описанных в TDS. Метрики для автоматизированного краш теста – покрытие путей модели описанных для раздела автоматического краш-теста TDS.
Критерий успешности системы – система передаётся в эксплуатацию, когда разработан полный комплект тестов и все тесты для ручного тестирования выполняются без ошибок. Некритические ошибки найденный во время краш-теста могут быть перенесены как доработки.
Критерий прекращения тестирования – система передаётся на доработку, если хотя-бы один из разработанных тестов обнаруживает ошибку. После исправления ошибки система вновь передаётся на тестирование.
Поставка.
В результате выполнения данного плана должны появится:
Документ [TDS]
Комплект тестов, оформленный в виде [TSC]. Будут созданы два комплекта тестов – для ручного тестирования и для автоматизированного «краш-теста».
Требования к окружению.
Никаких.
(цитата из лога аськи)
<тим лидер програмистов>14:36
нагрузка не предсказуема
<тим лидер програмистов>14:37
то есть, может быть на 15 минуте быть, потом 15минуте 14 секунде, пропасть
Более крупного стратегического планирования пока что не произвожу... Задания приходят максимум на передаланный модуль. Новых проектов = новых больших войн пока что не планируется, поэтому пока что ограничиваюсь локальными операциями.
Первое время это напоминало партизанскую оборонительную войну - ставится задание - я вообще первое время никаких документов не оформлял, а сразу писал баги в трекер на задание. Баги правят - задание приходит ко мне. Я пишу новые - отправляю назад. Их исправляют - возвращают ко мне. Обычно после двух трёх перебросок кое-как закрывали задание, но при этом треть багов переносились как доработки на потом...
Сейчас - когда приходит новое задание, пробую начинать оформлять на него план тестирования.
Что-нибудь посоветуете?
#78189 Организация процесса тестирования "с нуля"
Отправлено автор: frei_by 22 сентября 2010 - 15:24 в Управление тестированием
Устроился на работу тестировщиком, в конце этого лета. До этого работал инженером эенергетиком. Надоело, решил попробовать начать карьеру в IT.
Так вот, ситуация абсолютно идентичная описанной в первом посте темы. Только со скидкой на то, что компания в которой работаю - относительно крупная.
Когда я пришёл уже была установлена BTS TargetProcess, с более менее удобной системой трэкинга багов. Документации тоже только тень, удобно зато что я нахожусь в одном помещении с программистами (около 10 человек) и можно подойти и спросить если что-то неясно.
Требования и документацию восстанавливаю через аську. Прямо так в план и заношу логи разговоров.
Пробовал в начале сам для себя писать планы с кейсами как положено - понял что это пока что бесполезная трата времени. к тому моменту когда напишешь план и отладишь все тесты - уже получается что протестировал весь модуль.
Пока что пытаюсь приучить программистов к итераицонной разработке - т.е. билд - теситирование - исправление - регрессионное ...
Очень много недовольства со стороны программеров в том плане что многие баги хотят обозвать доработками и ругаются что я не баги нахожу а доработки. Если в некоторых местах для того чтобы выполнить какое-то действие нужно три раза притопнуть и прихлопнуть - а я пишу что это баг и нужно сделать так, чтобы одни раз нужно было кликнуть - сразу начинаются споры о том, что это доработка и на это нету времени.
БьюсЬ, чтобы дали мне тестовый сервер. Приходится подключатся через сеть к компам программеров и теситить прямо у них на винчестере модули которые они параллельно мне дописывают....
Короче много всякого. Может через пару лет напишу чем кончится...
Так вот, ситуация абсолютно идентичная описанной в первом посте темы. Только со скидкой на то, что компания в которой работаю - относительно крупная.
Когда я пришёл уже была установлена BTS TargetProcess, с более менее удобной системой трэкинга багов. Документации тоже только тень, удобно зато что я нахожусь в одном помещении с программистами (около 10 человек) и можно подойти и спросить если что-то неясно.
Требования и документацию восстанавливаю через аську. Прямо так в план и заношу логи разговоров.
Пробовал в начале сам для себя писать планы с кейсами как положено - понял что это пока что бесполезная трата времени. к тому моменту когда напишешь план и отладишь все тесты - уже получается что протестировал весь модуль.
Пока что пытаюсь приучить программистов к итераицонной разработке - т.е. билд - теситирование - исправление - регрессионное ...
Очень много недовольства со стороны программеров в том плане что многие баги хотят обозвать доработками и ругаются что я не баги нахожу а доработки. Если в некоторых местах для того чтобы выполнить какое-то действие нужно три раза притопнуть и прихлопнуть - а я пишу что это баг и нужно сделать так, чтобы одни раз нужно было кликнуть - сразу начинаются споры о том, что это доработка и на это нету времени.
БьюсЬ, чтобы дали мне тестовый сервер. Приходится подключатся через сеть к компам программеров и теситить прямо у них на винчестере модули которые они параллельно мне дописывают....
Короче много всякого. Может через пару лет напишу чем кончится...
#83210 Если у Вас высокая квалификация, то почему Вы все еще тестировщик?
Отправлено автор: frei_by 18 января 2011 - 07:57 в Личный рост, карьера, развитие
Извините, а тип карты у вас какой?...2. Расплачивалась с помощью карты сначала в аптеке, потом в супермаркете "Карусель".
Пин-код НЕ нужен!!! Ни в аптеке, ни в "Карусели"! Запросто денежки списываются с карты без ПИН-кода.
Почему вы считаете что ожидаемый результат это ввод пин-кода? А что было в договоре с банком написано?
А по теме я-бы сказал так: программист ребёнка может родить, а тестировщик воспитать.
#79562 Что надо чтобы стать тестировщиком?
Отправлено автор: frei_by 04 ноября 2010 - 16:30 в Личный рост, карьера, развитие
Экспертные знания в области ООП, умение програмировать на С, Java. Знание фреймворков XUnit. SVN, систем CI. Знание стандартов оформления документации IEEE, ISO. Опыт руководства комнадой разработчиков. Стаж работы прорамистом 4 года. Экспертные знания в области ОС, Win, Linux, администрирование серверов, сетей. Наизусть выучить протокол HTTP. Экспертные знания в области юзабилити. XML - спецификацию наизусть. W3C - все стандарты наизусть...
Думаю что с таким багажом младщим тестировщиком веб сайтов устроится можно будет...
Думаю что с таким багажом младщим тестировщиком веб сайтов устроится можно будет...
#85456 Высшее образование для тестировщика
Отправлено автор: frei_by 10 марта 2011 - 07:49 в Личный рост, карьера, развитие
Отсутствие высшего образования с высокой вероятностью говорит о неспособности учиться когда кто-то посторонний тебя чему-то учит "что может тебе пригодиться впоследствии".
#84572 Смешно про тестирование
Отправлено автор: frei_by 18 февраля 2011 - 11:29 в Свободное общение
Тестировщик 09.02.2011 11:25
т.е. увидеть полную картину как это реализовано
Тимлид программистов 09.02.2011 11:25
я сам не знаю этот принцип, только догадываюсь
Тестировщик 09.02.2011 11:25
ну так а как мне на основе того что я тоже догадываюсь решить правильно оно работает или нет?
Тимлид программистов 09.02.2011 11:26
я не знаю, наверно так же как и мы разрабатываем
т.е. увидеть полную картину как это реализовано
Тимлид программистов 09.02.2011 11:25
я сам не знаю этот принцип, только догадываюсь
Тестировщик 09.02.2011 11:25
ну так а как мне на основе того что я тоже догадываюсь решить правильно оно работает или нет?
Тимлид программистов 09.02.2011 11:26
я не знаю, наверно так же как и мы разрабатываем
#89895 Смешно про тестирование
Отправлено автор: frei_by 12 июня 2011 - 06:01 в Свободное общение
#87345 Смешно про тестирование
Отправлено автор: frei_by 20 апреля 2011 - 07:32 в Свободное общение
(требования к ПО - real story)сумму прописью начинать с большой буквы
#87390 Смешно про тестирование
Отправлено автор: frei_by 21 апреля 2011 - 09:21 в Свободное общение
тестировщик 12:16
The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it.
тестировщик 12:17
http://www./#site.ru/
try it
тестировщик 12:18
http://www.#site.ru/
программист 12:18
так вот я и про то что
была все ок
пока ты не предложил использовать встроеные функции пхп
которые напрочь разламали все
=))
тестировщик 12:18
а ты и согласился?
ну и кто из нас програмист?
программист 12:19
тут типа такая фишка я должен делать то что скажут
=)
не понравилась одно на тебе то что ты хочешь
=)
если мое лучше твоего
тестировщик 12:19
ну так не проверяй тип переменных
программист 12:19
ну так беда в том что ты ...
я и не проверяю
=)
тестировщик 12:20
и register_globals включи
программист 12:20
в пхп это не критично
и что
тестировщик 12:20
и в качестве пароля админского используй 123
программист 12:20
я так и делаю
тестировщик 12:20
ок?
программист 12:20
все что ты написаол
имено так
программист12:21
не проверяй тип переменных , register_globals on, админского используй 123
все условия саблюдены
The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it.
тестировщик 12:17
http://www./#site.ru/
try it
тестировщик 12:18
http://www.#site.ru/
программист 12:18
так вот я и про то что
была все ок
пока ты не предложил использовать встроеные функции пхп
которые напрочь разламали все
=))
тестировщик 12:18
а ты и согласился?
ну и кто из нас програмист?
программист 12:19
тут типа такая фишка я должен делать то что скажут
=)
не понравилась одно на тебе то что ты хочешь
=)
если мое лучше твоего
тестировщик 12:19
ну так не проверяй тип переменных
программист 12:19
ну так беда в том что ты ...
я и не проверяю
=)
тестировщик 12:20
и register_globals включи
программист 12:20
в пхп это не критично
и что
тестировщик 12:20
и в качестве пароля админского используй 123
программист 12:20
я так и делаю
тестировщик 12:20
ок?
программист 12:20
все что ты написаол
имено так
программист12:21
не проверяй тип переменных , register_globals on, админского используй 123
все условия саблюдены
#82100 Вопрос про классы эквивалентности на CD
Отправлено автор: frei_by 17 декабря 2010 - 11:31 в Личный рост, карьера, развитие
Да, если на аутсорсинг тестирования то лучше ответ barancev, а если для внутренних проектов - то ch_ip.
#81644 Вопрос про классы эквивалентности на CD
Отправлено автор: frei_by 10 декабря 2010 - 07:51 в Личный рост, карьера, развитие
А я считаю что всё равно нужно читать спецификации.
http://www.osta.org/...logy/cdqa14.htm
про граничные значения я бы добавил по другому.
размер больше нуля меньше минимального размера кластера для используемой FS на диске
размер минимального кластера FS на диске
несколько заполненных кластеров и один не заполненный.
дорожка котороя будет записыватся с начала,
дорожка которая будет записыватся не с начала...
дорожки которые будут записыватся с разрывом,
ЕСЛИ размер записываемой информации будет совпадать с максимально доступным на диске - но во время записи на диске оказались области в которые запись не может быть осуществлена,... можно пол-дня придумывать.
а вы говорите, меньше кБ и больше 700...
Без достаточно детальных знаний о структуре диска думаю что никак. Или очень в общей форме в виде "покупатель заказывает в корзине товар, оплачивет покупку, ОР = все счастливы все довольны".
http://www.osta.org/...logy/cdqa14.htm
про граничные значения я бы добавил по другому.
размер больше нуля меньше минимального размера кластера для используемой FS на диске
размер минимального кластера FS на диске
несколько заполненных кластеров и один не заполненный.
дорожка котороя будет записыватся с начала,
дорожка которая будет записыватся не с начала...
дорожки которые будут записыватся с разрывом,
ЕСЛИ размер записываемой информации будет совпадать с максимально доступным на диске - но во время записи на диске оказались области в которые запись не может быть осуществлена,... можно пол-дня придумывать.
а вы говорите, меньше кБ и больше 700...
Без достаточно детальных знаний о структуре диска думаю что никак. Или очень в общей форме в виде "покупатель заказывает в корзине товар, оплачивет покупку, ОР = все счастливы все довольны".
#81647 Вопрос про классы эквивалентности на CD
Отправлено автор: frei_by 10 декабря 2010 - 08:36 в Личный рост, карьера, развитие
"система потребует какое-то количество байтиков под свои нужды"
-вот обычно дьявол в таких условиях и прячется при формулировании начальных условий.
-вот обычно дьявол в таких условиях и прячется при формулировании начальных условий.
- Форум тестировщиков
- → Публикации frei_by
- Политика Конфиденциальности
- Правила форума ·