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

Тестирование REST API
онлайн, начало 2 ноября
Школа Тест-Аналитика
онлайн, начало 4 ноября
Практикум по тест-дизайну 2.0
онлайн, начало 30 октября
Школа тест-менеджеров v. 2.0
онлайн, начало 4 ноября

Публикации dlg99

8 публикаций создано dlg99 (учитываются публикации только с 30 октября 2019)


#78529 Подскажите по xpath

Отправлено автор: dlg99 04 октября 2010 - 22:08 в Selenium - Functional Testing

<div class="y6">
     <span id=":pi">text1</span>
     ‎<span class="y2"> - text2</span>
</div>

Как получить доступ к любому из span элементов по тексту text1 или text2?



что-нибудь вроде
//div[@class='y6']/span[contains(text(), 'text2')]
или
//div[@class='y6']/span[ends-with(text(), 'text2')]



#77212 Тестируйте не числом, а умением

Отправлено автор: dlg99 27 июля 2010 - 16:31 в Портал Software-Testing.Ru

Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типа
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд


я тоже ;)
только нужно еще в обратную сторону ограничить - если любое из Dashed/... =="NA", то остальные могут быть только "NA" и Border может быть только "no line".



#77211 Тестируйте не числом, а умением

Отправлено автор: dlg99 27 июля 2010 - 16:27 в Портал Software-Testing.Ru

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


в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.

к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.


заметьте, я не говорил, что можно использовать не думая. ;)

иногда проще разбить на части. иногда удобнее описать модель/правила в коде - меньше ручной работы при изменении бизнес-логики.
все Вами описанное выливается в 1 строчку кода, которую будет проще понять, чем 2 независимых генератора тестов (из моего опыта, YMMV).

посмотрите на http://sourceforge.n...s/example2.2.py (из http://engineering.m.../allpairs.aspx) как на пример задания фильтра просто в коде.
в pict можно задать sub-models в дополнение к constraints.
все можно сделать 'спокойно' - сосредоточившись на том, *какие* тесты генерировать, а не на том *как* их генерировать.



#77203 Тестируйте не числом, а умением

Отправлено автор: dlg99 27 июля 2010 - 15:09 в Портал Software-Testing.Ru

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


в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.



#77042 Стохастическое тестирование

Отправлено автор: dlg99 16 июля 2010 - 23:58 в Тест-дизайн и ручное тестирование

Bj Rollison упоминал, что в Microsoft проводили исследование на эту тему лет 5 назад, несколько лет, разные группы, разные подходы.
насколько я помню, стохастические методы в какой-то момент почти достигают того же покрытия (code coverage/tets coverage/bugs found), что и другие (см ниже), но существенно позже.
как результат эти методы применяются редко, предпочтение отдается автоматизации (комбинаторными методами + модели) с регулярным code coverage analysis и code reviews + static testing tools.
Была статья на этот счет, с графиками и прочим; название не помню. Можете или спросить Bj (www.testingmentor.com) или посмотрите в книге "How we test software at Microsoft", вроде бы там это тоже встречалось.

Исключением является security testing, где часто используют fuzzing и, пожалуй, machine learning.
С первым я серьезно не сталкивался, во втором проблемой является не "создать много случайных тестов", а "выбрать случайный минимальный statistically significant набор тестов"

Модели, кстати, можно строить при помощи разных тулов, например SpecExplorer.

по личным ощущениям и отзывам тех, кто с ними плотно общался, Канер и Бах:
- ориентированы на людей с нетехническим образованием/складом ума
- работают в режиме консалтинга, пришел-ушел. поэтому агитируют за самые простые для понимания менеджментом (легче продать/демонстрировать) подходы.
Майерс - 'технарь', оттого и расхождения во мнениях.

выбирайте сами - если проект на 2 месяца, то может быть написанный за 3 дня генератор случайных тестов имеет лучшее соотношение затраты/результат. Если проект на 3 года то см выше.



#76480 Представления о процессе тестирования

Отправлено автор: dlg99 23 июня 2010 - 18:00 в Управление тестированием

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


У Вас богатый опыт руководства, Вы MBA и Вам все равно чем и кем руководить?
Если нет, то просите начальство нанять кого-нибудь с опытом работы и учитесь.



#73624 Собеседование по тестированию ПО

Отправлено автор: dlg99 01 февраля 2010 - 21:36 в Личный рост, карьера, развитие

Мне бы больше помогла информация как тестировать такие программы.Т.е меня посадят за компьютер и скажут протестируй программу для электронного банкинга.Хотелось бы узнать как именно тестировать данные программы,например если у меня не будет спецификации.Проверить работают ли основной функционал,а дальше что...Какая пошаговая инструкция?


с Вашим опытом (или с его отсутствием, судя по уровню задаваемых вопросов) пошаговая инструкция - "выполнять пошаговую инструкцию".
Вменяемые люди Вам не доверят ответственность (ну хотя бы моральную) за потенциально много миллионов потерянных денег в такой системе.
Исходя из этого готовьтесь продемонстрировать на интервью способность учиться, воспринимать простые инструкции и понимать незамысловатую техническую документацию.
Сходите в книжный магазин, полистайте там пару часиков книжки по тестированию "для начинающих". Не для получения пошаговой инструкции, а для "введения в специальность". Потом еще два часа - попытайтесь ответить на простые вопросы - как протестировать диалог записи файла, алгоритм поиска в бинарном дереве, удаление элемента из однонаправленного списка, программу рисования кружочка, кружку-непроливайку и т.п. Подумайте, как Ваш план тестирования масштабируется на более сложные системы (блокнотик, или простая база данных). Если Вы сможете сделать это самостоятельно - в голове у Вас будет покой и порядок и на интервью все будет ок; если будете просто зубрить пошаговую инструкцию - это быстро вылезет наружу.

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

Удачи!



#73527 Какие книги на английском посоветуете

Отправлено автор: dlg99 28 января 2010 - 03:15 в Литература по тестированию ПО

- "How We Test Software at Microsoft®" -- тоже самое (название если честно не подкупает, хотя я и к виндам и Майкрософту отношусь нормально).


Нормальное название, вполне соответствует содержанию. ;)
Там нет упора на "а вот сейчас я вас всех тестировать научу" (yep, this is why it is not named "how *you* should test software" :)), там описан опыт компании в которой 5000+ человек занимаются тестированием.
Очевидно, некоторые вещи напрямую не переносятся в любую произвольно взятую компанию, что, конечно, может разочаровать определенную категорию читателей.
Тем не менее, я думаю что почитать про опыт и мотивацию использования некоторых практик должно быть интересно людям с опытом тестирования.
Еще, МС большой, все группы немного разные и авторы не пытались посчитать "среднюю температуру по больнице", а вычленяли вещи, которые показали себя наиболее эффективными и используются повсеместно (code review, code coverage analysis, modeling etc.).

Новичкам книга тоже должна быть интересна, там достаточно внимания уделено "введению в специальность", с примерами (минус детальное описание техник тестирования, метрик и т.п.). Учтите, что предполагается что каждый SDET в МС умеет программировать и может читать код, т.е. акценты на практиках и подходах соответствующие.
Во многом структура книги повторяет курс "быстрого старта в тестировании" для SDETs с малым опытом или нанятых из университетов (я курс не посещал, просматривал материалы).
В общем-то, это и не удивительно, т.к. авторы книги этот курс и создавали и вели. Курс создавался с упором на МСовские практики (см. название книги), с учетом различий процессов в разных группах и пр, с учетом того что потом можно пойти на другие более детальные тренинги по тестированию. Курс 'обкатывался' несколько лет на достаточно большом количестве людей, так что исходного материала для книги было достаточно.

По-моему, канеровского динозавра про "как тестировать" давно пора отправить в макулатуру ('context-driven ...' оставить), а на освободившееся на полочке место вполне можно поставить эту книгу.

да, коллеги еще советуют "The Practical Guide to Defect Prevention" - там про метрики. Я добавить ничего не могу - руки не дошли почитать.
приятного чтения!




Яндекс.Метрика
Реклама на портале