Сообщений в теме: 50

[barancev]

Не нравится мне этот полный набор тестов. Не всё учтено.

Почему не тестируется генерация списка нескольких последних новостей? Если база отвалилась, нету доступа или нету достаточно сообщений (<10)?

По поводу тестирование параметра topic.

1) topic без значения
... skip-skip-skip ...
3) mysql query hacking. При передаче значения topic в mysql query передаётся он напрямую или используются обёртки в php скрипте.

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

Про всё остальное -- см. мой ответ Сергею здесь: http://forums.softwa...?showtopic=2876

[STRAY]

3) mysql query hacking. При передаче значения topic в mysql query передаётся он напрямую или используются обёртки в php скрипте.

По-моему это уже Security Testing и производят его обы4но при помощи специальных тулов...
Хотя я им занимал всего пару раз, так 4то не буду настаивать... аля IMHO

[barancev]

Господин Алексей, будьте так любезны ответить на прямой вопрос в таком слу4ае:
КАК вы можете оценить требуемое коли4ество тестов???

Нау4ите "танцам с бубнами" ?!

Только что проделал часть такого "танца" с редактором. Никаких бубнов, никакой мистики. Тестирование -- инженерная наука, а не искусство.

Подразумевался слу4ай (4астый, зараза, какой-то), когда приходят проекты, в которых больше вопросов и неясностей, 4ем конкретики... А если сценарии создаются в специализированных средах (Rational Rose, Sparx Enterprise Architect), а не Ексель-подобные, то вопрос о переделке сценариев на4инает весить наааааамного больше, так как занимает куда больше времени...

Откуда Вы такие проекты берете? Если свои, внутренние -- надо что-то менять в консерватории. Если заказные -- просите больше денег "за вредность", а не получается -- не берите, раз не нравится.

[0xhh]

3) mysql query hacking. При передаче значения topic в mysql query передаётся он напрямую или используются обёртки в php скрипте.

По-моему это уже Security Testing и производят его обы4но при помощи специальных тулов...
Хотя я им занимал всего пару раз, так 4то не буду настаивать... аля IMHO

Не знаю как это называется :-)
Знаю, что в topic можно передать часть mysql query, и вопрос как этот скрипт такое скушает. Соответственно используется ли escaping и т.д.

[barancev]

Знаю, что в topic можно передать часть mysql query, и вопрос как этот скрипт такое скушает. Соответственно используется ли escaping и т.д.

Давайте проще. Привяжемся к построенной модели. Часть sql query (если она не является числом), приведет к появлению сообщения о том, что параметр не является числом. Вот и всё. И escaping тут совершенно ни при чем. Либо число, либо нет.

[Doveangel]

чуть опыта от меня:
Если например есть несколько полей - и система может реагировать по разному на ввод пусто/не пусто в жти поля, то я составляю колонку из нулей и единиц. Как в электронике.
например задано три поля
пусто - пусто - пусто
пусто - пусто - не пусто
010
011
100
101
110
111
итого восемь тестов. Все прогоняются и записываются результаты. (Это я насчет полноты говорю - некий элемент "танцев с бубнами")
замечание: использовать такой "метод" имеет смысл если три поля связаны между собой, конечно если у вас обособленные поля (например просто задание суммы в поле), то нет необходимости так тестить.
Если надо тестировать главную функциональность (работает-не работает, на каком месте отваливается), то действительно составляю блок-схему, как описал в статье Алексей (респект Вам), удобно.
Дело может в том, что мы не тестируем сразу все приложение, у нас идут доработки - и они обычно связаны с некоторой частью всего приложения.
Конечно, если Вам поступил на тестирование новый продукт, и надо тестировать с нуля всю функциональность, отображение окон, корректность ввода в поля... то - надо РАЗБИВАТЬ систему на куски (логически) и работатть с ними. И ни в коем случае не за 4 часа!! и не за 6!! Полное время тестирования должен оценить руководитель проекта... но лично я не представляю как можно протестировать софт за 6 часов....

[Spy]

Абсолютно полное тестирование невозможно. Это непреложный факт.

Мы про енто в курсе. Просто какое вы вкладываете значение слова, когда говорите о ГАРАНТИЯХ полноты тестового набора?

По мне гарантия - это когда производитель обязуется оплатить ущерб, который понесу я, в случае, если софтина производителя захочет полежать...
Всё остальное, типо AS IS - NO WARRANTY - обяцанки...

[barancev]

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

Технически -- см. ответ здесь: http://forums.softwa...indpost&p=16951

Финансово -- да, у нас бывает такой пункт в договорах, когда мы выполняем заказные проекты. Гарантийный срок, в течение которого заказчик может нам выставить счет, если мы что-то при тестировании пропустили и оно сломалось "в поле". Штрафные санкции за недоброкачественную работу -- это нормально.

[theart]

Позвольте поднять столь эпическую тему с парочкой вопросиков от новичка:
1) Стоит ли в кейсах подробно расписывать тестирование вводных значений для большОго количества полей ввода. Допустим на странице 10 таких полей, все они должны воспринимать только кириллицу и соответствовать ещё ряду мелких условий. Грамотным ли будет тест кейс, где единожды будут упомянуты все вводные значения (например: ввести "1111" нажать enter, ввести "11,11" нажать enter, etc), а далее будет что-то вроде "Протестировать поле ввода "Описание"?
2) Не знаю к радости или к сожалению, но у меня генетическая предрасположенность к нахождению нелогичных багов. Что-то вроде: открыл форму отправки 10 раз подряд, на 11 раз развернул её и именно такая последовательность крашит приложение. Таким образом я интуитивно мучаю каждый объект попадающий ко мне довольно продолжительное время, но опять же не знаю как быть с кейсами по этому поводу. Составить весь перечень моих неадыкватных действиях - жизни не хватит, фиксировать в кейсах сценарии приведшие к ошибки тоже не кажется правильным. На данный момент просто описываю порядок действий в багтрекере, в кейсах это не как не отображаю. Правильная ли это политика?
Извиняюсь за некропост.

[Wolonter]

Позвольте поднять столь эпическую тему с парочкой вопросиков от новичка:
1) Стоит ли в кейсах подробно расписывать тестирование вводных значений для большОго количества полей ввода. Допустим на странице 10 таких полей, все они должны воспринимать только кириллицу и соответствовать ещё ряду мелких условий. Грамотным ли будет тест кейс, где единожды будут упомянуты все вводные значения (например: ввести "1111" нажать enter, ввести "11,11" нажать enter, etc), а далее будет что-то вроде "Протестировать поле ввода "Описание"?

Мы пишем документ, чтоб его читали. А прочитавший, видимо будет тестировать.

Кто?
Прочтет суровый, закаленный в продакшенах ветеран? Прочтет новичок? Их отдадут внештатным кликерам? Документ будет просто историей и справочным материалом?
Как?
По этим сценариям будут лабать автотесты?
Как определят результат тестирования?
Было ли сложно вычислить значения для полей ввода? Достаточно ли здравого смысла, чтоб понять, что тут бага?
Какие баги ищем?
Любые? Ограничения полей ввода? Проверяем реализацию прав?

Ответьте на вопросы. Представьте читателя вашего документа. И будет понятно, надо ли дотошно описывать каждую цифру или достаточно будет напоминалки (не забудь проверить копипаст, дран-н-дроп и sql-инъекцию).

По собственному опыту - для ручного тестирования хватает таких напоминалок + список связей. А сценарии как-то сами генерятся.

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

Мы тоже не знаем как поступать правильно, поэтому для достаточно хитрых сценариев делаем две вещи:
- пишем специальный отдельный автоматизированный тест - чтоб ежели повторится - мы узнали.
- в постановке есть раздел "баги этой постановки" - это для ручного тестирования - если ее еще раз будут тестить - перепроверят.

Как-то так.

[theart]

Как-то так.

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