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

Фотография

Ода скриптовому тестированию


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 16

#1 baranceva

baranceva

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 4 242 сообщений
  • ФИО:Баранцева Наталья


Отправлено 30 мая 2012 - 16:42

Автор: Наталья Руколь

Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.

Словарь

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

Читать дальше
  • 0
Наталья Баранцева
Тренинги по тестированию ПО

#2 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 01 июня 2012 - 23:37

Автор: Наталья Руколь

Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.

Словарь

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

Читать дальше

При всем уважении к автору, но называть скриптованное и исследовательское тестирование (и др.) подходами ошибочно. Это не более чем виды тестирования, которые замечательно комбинируются. Какой-то определенный баланс между ними, да, это уже подход.
  • 0

#3 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 02 июня 2012 - 14:25

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

Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))

Почему нельзя называть скриптовое и исследовательское тестирование подходами? Можно какое-нибудь определение слова и что именно в этом контексте противоречит значению слова?
  • 0

#4 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 04 июня 2012 - 07:48

Аа!!!
Запуталась!

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

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?

"документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"

хм... ну если есть требования(спецификация) можно заниматься анализом.
Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?

Если нету требований (спецификации), то чтоб заниматься анализом, созданием карты, разбиением на классы.. и тыпы ---
то нужен сам софт, хоть как-то работающий. Чтоб включить и посмотреть - как он работает. Вроде - никак по-другому.
А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#5 kitsune

kitsune

    Активный участник

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 04 июня 2012 - 09:03

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?


По этим тестам, которые "во время" - потом еще тестирование планируется?
  • 0

#6 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 04 июня 2012 - 09:20

По этим тестам, которые "во время" - потом еще тестирование планируется?


Да.
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#7 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 05 июня 2012 - 03:42

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?

В тот момент, когда мы тестируем не по заранее созданным тестам, тестирование НЕ скриптовое. Если в процессе такого тестирования мы создаём тесты, а потом по ним будем осуществлять планирование и тестирование, то последующие итерации будут в скриптовом тестировании.

"документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"
хм... ну если есть требования(спецификация) можно заниматься анализом.

Ну требования всегда есть, если разработчики сидят код пишут. Вопрос только в их задокументированности. Чем менее детальны требования и спецификации, тем важнее тест-анализ.

Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?

Если вкратце, то да.

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

Ну я вменяемо документированных требований никогда не встречала, а тест-анализ провожу всегда. Узнаю как и что должно работать, выясняю, продумываю тесты. И кстати проектирование тестов без учёта интерфейса делает их значительно более полезными, ориентированными на бизнес-логику, а не на чек-боксики и радио-баттоны.

А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?

Да, мы можем совмещать исследовательское тестирование с написанием тестов для последующего скриптового, не поняла, что в этом странного?
Я не встречала условий, в которых бы можно было использовать только один подход, их обычно надо комбинировать.
  • 0

#8 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 05 июня 2012 - 07:19

Ок. Ок.
Серьмяга статьи в том, что тесты (как и кулинарные рецепты домашней выпечки) полезно документировать.

Про полноту покрытия тестами.
Ну во-первых, стоит сначала понять -- про какое именно покрытие речь идет.
Про покрытие функциональных требований или еще про какое.
Собственно, покрытие - величина считаемая.
Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#9 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 06 июня 2012 - 06:39

Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).

Если есть требования - ставить плюсики рядом с проверенными.
+ Code Coverage, если вообще никакой документации нет.
  • 0

#10 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 06 июня 2012 - 07:50

Если есть требования - ставить плюсики рядом с проверенными.
+ Code Coverage, если вообще никакой документации нет.

а диаграммы раскрашивать фломастерами.....

Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#11 AlexeyEfimov

AlexeyEfimov

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 07 июня 2012 - 15:25

Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).


Кстати, технически это несложно сделать. Большинство сред исполнения/framework-ов позволяют записать, какие строчки кода вызывались хотя бы один раз за определенный интервал времени (profiling/tracing). Независимо от степени документированности тестов можно померять % строк кода, которые выполнились за одну сессию/сеанс/раунд/прогон тестирования.
  • 0

#12 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 08 июня 2012 - 15:55

Если нету требований (спецификации), то чтоб заниматься анализом, созданием карты, разбиением на классы.. и тыпы ---
то нужен сам софт, хоть как-то работающий. Чтоб включить и посмотреть - как он работает. Вроде - никак по-другому.
А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?


...
Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).

Необязательно. Иногда можно пользоваться джедайскими техниками.
Например я знаю, что вменяемый модуль "оргструктура" для приличной (>1000 UC) КИС-ы для организации 5000+ человек должет содержать порядка десятка объектов класса:
* сотрудник
* позиция
* отдел
и прочее

Для кажного из объектов стандартный CRUDL и чего то нестандартное. Полсотни юзкейсов, несколько сотен тестов. В принципе все это можно смоделировать в голове без спецификации и без софта. Так же можно просто держа в голове эти 100 - 300 тестов провести их и не пропустить ни одного. В принципе можно. Но как говорил один мой хороший знакомый, очень хороший человек и очень, очень хороший специалист: "Так засрать мозг и оперативную память ради какой то фигни!"
------------
Из опыта. Спецификация на этот модуль пишется грамотным, опытном аналитиком примерно за неделю, почти без обращений к заказчику, потому как во всех организациях примерно одно и то же. И после 3-ей КИС-ы (лет 10 опыта) такие спеки можно писать не включая мозг. И тестировать тоже можно не включая мозг.
Ну потому опытных людей иногда и ищут. И что удивительно иногда им за этот опыт даже доплачивают.
------------


Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).


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

Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#13 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 08 июня 2012 - 16:04

Собственно, чего я в эту тему полез.
Я сейчас пишу перечень предложений по тестированию. Ну и реестр тесткейсов там ка одно из. Мне проще проверить часть моих гипотез на форуме, тем более, что кому то это потом может пригодиться.

-- Гипотеза ------------------------
На мой взгляд, в статье забыта два важнейших выигрыша от реестра.

1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.

2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.

Указанные же в статье преимущества относительно менее значимы. Точно так же как забытая, но нежно любимая менеджерами и заказчиками возможность расчета трудоемкости.
-- Конец гипотезы ------------------------
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#14 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 08 июня 2012 - 22:41


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

Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))

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

Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.
  • 0

#15 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 09 июня 2012 - 01:27

Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.

А! Тогда полностью согласна :)
  • 0

#16 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 09 июня 2012 - 01:30

1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.

Эм... Это же преимущество №1 в статье?

2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.

Я бы не сказала, что без скриптов нельзя грамотно разбить работу в команде, поэтому это сложно назвать преимуществом.
  • 0

#17 AlexeyEfimov

AlexeyEfimov

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 09 июня 2012 - 07:01

Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.


Вопрос был "как померять", а не "хорошая ли это метрика".

А ссылка не совсем в тему. Речь шла именно про ручное тестирование, а не unit-testing, с которым обычно особых вопросов про оценку покрытия не возникает (у программистов).
  • 0


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных