При этих словах просто необходимо давать ссылкуЯ знаю точно, невозможное возможно...
- Форум тестировщиков
- → Публикации LeshaL
81 публикаций создано LeshaL (учитываются публикации только с 24 апреля 2023)
Отправлено автор: LeshaL 24 октября 2011 - 11:10 в Про тестирование обо всём подряд
При этих словах просто необходимо давать ссылкуЯ знаю точно, невозможное возможно...
Отправлено автор: LeshaL 04 мая 2012 - 21:03 в Автоматизированное тестирование
А что найдет wget + grep? Даже если рекурсивно wget запускать и потом анализировать коды ответа (хотя тут grep-а явно не хватит), то он битые ссылки внутри документа все-равно не найдет.чем обусловлено требование из консоли на линуксе? Почему нельзя воспользоваться виндовой виртуалкой?это хорошее средство. но надо такое, которое можно было бы запускать из консоли на линуксеXenu's Link Sleuth
Из консоли на линуксе хорошо запускается wget+grep
Отправлено автор: LeshaL 23 августа 2011 - 19:51 в Тест-дизайн и ручное тестирование
Конечно, случаи разные бывают. Но из описания понятно, что баг не исчез, а остался. Меня-то это зацепило.Просто в случае, который я описала для исправления бага нужно было потратить много времени и перелопатить всё фичу. Поэтому решили, что дешевле оставить так (реальный пользователь всё равно врядли наткнётся).
А вообще (по моим наблюдениям) отношение программистов "мне лень чинить" идёт не от них, а от руководителей. Если руководитель относится к найденной проблеме: "ой, это не важно, всё равно в реальной ситуации на это не наступят" - это передаётся программистам. И потом начинается: "я не буду чинить, пока это кастомер не найдёт" и т.п. Но это уже совсем другая история.
Отправлено автор: LeshaL 16 сентября 2011 - 04:24 в Тест-дизайн и ручное тестирование
Похожего вопроса касались вот тут: http://software-test...9272#entry49272Вопрос актуальный в контексте собеседования тестировщика.
Я придерживаюсь такой позиции, что не важно как называть эти вещи, главное, чтобы человек умел их применять.
Но иногда сталкиваюсь с ситуацией, когда нужно просто знать точное определение.
Какой, например, должен быть ответ на вопрос "Перечислите методы тестирования, которые вы знаете?"
На сколько я понимаю, методы - это более широкое понятие. Типа метод "белого" и "черного ящика". Техники - это подходы в рамках какого-то метода. Типа Equivalence partitioning и Boundary-value analysis. Технологии - просто слово из рефератов и резюме.
Поправьте, если я ошибаюсь.
Отправлено автор: LeshaL 05 февраля 2012 - 17:15 в Автоматизированное тестирование
Спасибо за столь детальный анализ. На мой взгляд не хватает обобщенного вывода в конце, по которому можно было бы принять решение....
Отправлено автор: LeshaL 29 января 2012 - 18:47 в Автоматизированное тестирование
Отправлено автор: LeshaL 06 февраля 2012 - 12:43 в Автоматизированное тестирование
Интересная идея, надо обдумать. Хотя она не отменяет прохождение по специфицированным (читай acceptance) сценариям. А тестирование сценариев, конечно же, не отменяет функционального тестирования.Если вам нужно писать тесты на workflow, пишите машину, которая будет уметь генерировать workflow, а не проходить один и тот же сценарий из раза в раз.
Отправлено автор: LeshaL 07 февраля 2012 - 05:41 в Автоматизированное тестирование
Да никак пока не ограничили. Сейчас тесты идут порядка 3х минут ибо их не много еще. Добрая половина из них уедет в другие наборы, когда я наконец засетаплю все через хадсон. Программисты обычно не делают много комитов за день (имеется ввиду в интеграционное пространство) и пару раз запустить такой набор - не проблема, тем более, что это их инициатива изначально.
Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.
Жутко интересно, как вы ограничили размер набора. Выбрали самое важное что укладывается в n минут? GUI тесты имеют свойство идти долго. Если не секрет, сколько идет этот зеленый набор?
Отправлено автор: LeshaL 29 января 2012 - 20:30 в Автоматизированное тестирование
В первом варианте приведения вроде можно избежать, как сделать я придумал только вот сейчас отвечая на вопрос. Завтра попробую. Да и возникают они только после метода open общего для всех страниц. А метод используется редко сам по себе.Скорость написания в третьем случае иллюзорна - быстро будет написан первый тест(пока вилларибо пишет фреймворк, виллабаджо наклепала 3 теста), потом копипаст утянет в пучину.
Первый вариант кстати лично меня отталкивает лишь наличием приведения - из-за снижения читабельности и рассеивания внимания +)
Второй вариант конечно заманчив - но решительность при выборе в его пользу зависит от сложности системы в целом.
Я бы начал со второго варианта, но не слишком бы убивался пытаясь придерживаться его - написал бы некоторое кол-во разноплановых тестов, а потом бы уж точно определился со стилем. Да и вообще бы на первых порах написания фреймворка не советовал наращивать "критическую массу" тестов.
Отправлено автор: LeshaL 06 февраля 2012 - 12:53 в Автоматизированное тестирование
Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)Походу можно новую тему открывать :) про уровни автоматизации тестирования :)
Отправлено автор: LeshaL 06 февраля 2012 - 06:14 в Автоматизированное тестирование
Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.
.doLogout() .checkLoggedIn(false) .checkLoggedOut(true);имеет две проверки после действия. Можно сделать одну, так чтобы второй метод вызывал первый и в данном случае это прокатит, но в другом случае будет сложнее не запутаться, чем вызвать несколько проверок.
Отправлено автор: LeshaL 05 февраля 2012 - 18:06 в Автоматизированное тестирование
Отправлено автор: LeshaL 05 мая 2012 - 20:48 в Selenium - Functional Testing
Отправлено автор: LeshaL 05 октября 2011 - 08:24 в Свободное общение
Вас не смущает, что прошло 8 лет?Страницы не существует..
Отправлено автор: LeshaL 25 июня 2012 - 21:19 в Личный рост, карьера, развитие
Неправда ваша. У меня среди знакомых есть обратные примеры.Когда-то сам копал в эту сторону и пришел к выводу, что оно того не стоит. Почти везде, где нужно серьёзное тестирование (и как следствие приличные зп) невозможно впринципе тестировать из дома.
Отправлено автор: LeshaL 31 октября 2011 - 12:37 в Тест-дизайн и ручное тестирование
Файловых систем в мире не так уж и много. У меня есть подозрение, что ваш вопрос о чем-то другом.Если у кого-то есть опыт тестирования файловой системы, поделитесь пожалуйста.
Интересует подход к тестированию (что именно вы тестировали, как тестировали, какие tools использовали).
Может есть чек-лист того, что проверяли?
Какие были трудности, нюансы? В общем, инетересует любая информация ))
Спасибо!
Отправлено автор: LeshaL 05 февраля 2012 - 18:24 в QA: обеспечение качества
А по простому не получится? Если взять определённый набор данных и послать его через канал с известной пропускной способностью, то зная время начала передачи данных и время конца передачи, можно вычислить и реальную скорость передачи, которую можно сравнить с пропускной способностью.Всем привет.
Требуется определить, что приложение максимально использует пропускную способность канала. Может кто знает какие - нибудь утилиты для этого?
Заранее благодарен за ответы.
Отправлено автор: LeshaL 23 октября 2011 - 16:26 в Про тестирование обо всём подряд
Поддерживаю, будет интересно. Мы кодировки тестируем, точнее тестируем с использованием различных кодировок.Артем, отличная идея! Конечно, интересно знать про кодировки, чем больше, тем лучше.
Вопрос в том есть ли нужда у других тестировщиков знать что-то о кодировках?
Если есть то может что-то конкретное можете сказать?
Мне все интересно, особенно, если упорядочено, логично, можно хоть от истоков начинать. ASCI, Unicode, разница кириллическх кодировок. нструменты по преобразованию, как тестировать. Редкие и специальне кодировки, про которые стоит знать тестировщикам.
В общем, пишите, будет полезно!
Отправлено автор: LeshaL 14 октября 2011 - 21:31 в Свободное общение
Отправлено автор: LeshaL 30 августа 2011 - 21:19 в Личный рост, карьера, развитие
На мой взгляд, за исключением редких случаев - не должен. Вы правильно осознали. Если тестировщики начнут править код, а программисты исправлять тесткейсы - то что это за балаган получится?Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?
з.ы. вроде осознал, Тестировщик должен найти проблему и передать в вышестоящие инстанции(н-р прогерам), а они уже будут решать проблему...
Отправлено автор: LeshaL 25 апреля 2012 - 21:22 в Про тестирование обо всём подряд
Отправлено автор: LeshaL 30 августа 2011 - 20:43 в Тест-дизайн и ручное тестирование
Интересно, сколько раз надо написать одно и тоже...Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?
Отправлено автор: LeshaL 07 апреля 2012 - 05:07 в Начинающему тестировщику
Леша, интересный подход. Надо бы посмотреть реально ли так. Хотя мне почему-то кажется, что реализация все-таки больше в % соотношении должна занимать (даже без учета багфиксов)....
На ручное тестирование времени примерно надо в два раза меньше чем на реализацию этой фичи.
Отправлено автор: LeshaL 25 июня 2012 - 20:13 в Selenium - Functional Testing
Не очень понятно в чем вопрос. Напишите, что вы хотите сделать. Что такое MainWindow?Здравствуйте.
Решил использовать "по науке" pageobject и столкнулся с проблемой. Есть у меня отдельно класс какой-либо страницы и класс проверок. Отдельно конечно же существует класс с тест-кейсами и вот тут-то у меня загвоздка, наверное, от плохого знания Явы. Так вот проблема в следующем.
MainWindow mainwndw = new MainWindow(driveк)
mainwndw.buttonclick(mainwndw.submit);
В константах у класса страниц хранятся xpath к элементам на этих страницах, а как же тогда к ним обращаться из тест-кейсов и проверок, неужели только через mainwndw.submit? Нельзя ли это сделать красивей как-то? Спасибо.
Отправлено автор: LeshaL 30 августа 2011 - 21:04 в Тест-дизайн и ручное тестирование
По мне так это ошибка в программе - должно логинитьесли вводишь верно имя, фамилию и дату рожд. НЕуникального пользователя (Петров Петр 03.03.1993) программа выдает ERROR
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru