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

Фотография

Что необходимо для внедрения автоматизации тестирования ПО


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

#61 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 10:12

Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:

Не понял, почему не уместно. В чём заключается принципиальное отличие по Вашему мнению?

1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.

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

2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком

Оценка результатов теста - это подпроцесс или просто активность? Т.е. он формализован, фиксирован, управляем, измерим в любом случае? Нет ли там каких-то частностей?

3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования

Т.е. автоматизированное тестирование принципиально без метрик и характеристик провести нельзя. Процессность в него заложена от рождения?

4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.

Опять же. Разве для выбора стратегии обязательно нужен процесс? Что вы собираетесь измерять в выборе стратегии, какие метрики? И вообще, представляю себе томик "Политика выбора стратегии тестирования" (формализация процесса).

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

Я Вам ещё раз говорю, нет таких програмных систем, которые бы нельзя было протестировать модульно (и при этом пользовательские прецеденты могут вообще не участвовать), а системы, которые нельзя или сложно протестировать через GUI есть и в большом количестве. Расклад по частотам слов в SWEBOK это косвенно подтверждает.
  • 0

#62 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 11:11

Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:

Не понял, почему не уместно. В чём заключается принципиальное отличие по Вашему мнению?

Не уместно в том плане, что вы рассматриваете этот процесс вообще, не вникая в детали, которые на самом деле вносят очень много корректив.

1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.

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

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

2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком

Оценка результатов теста - это подпроцесс или просто активность? Т.е. он формализован, фиксирован, управляем, измерим в любом случае? Нет ли там каких-то частностей?

Подпроцесс или активность - это уже вопрос восприятия. Формализовать, зафиксировать критерии оценки результатов крайне желательно. Выводы по результатам-то надо какие-то сделать. И делать это нужно на основании каких-то характеристик

3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования

Т.е. автоматизированное тестирование принципиально без метрик и характеристик провести нельзя. Процессность в него заложена от рождения?

Провести можно. Наличие/отсутствие метрик не влияет на возможность запустить. А вот для оценки этого всего метрики, характеристики - это ключевой момент. Опять же, конечной целью тестирования является определение уровня качества некоторого продукта. И это делается на основании чего-то.
  • 0

#63 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 11:11

4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.

Опять же. Разве для выбора стратегии обязательно нужен процесс? Что вы собираетесь измерять в выборе стратегии, какие метрики? И вообще, представляю себе томик "Политика выбора стратегии тестирования" (формализация процесса).

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

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

Я Вам ещё раз говорю, нет таких програмных систем, которые бы нельзя было протестировать модульно (и при этом пользовательские прецеденты могут вообще не участвовать), а системы, которые нельзя или сложно протестировать через GUI есть и в большом количестве. Расклад по частотам слов в SWEBOK это косвенно подтверждает.

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

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

#64 SALar

SALar

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

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


Отправлено 30 января 2008 - 11:21

Вручную вы производительность не проверите, а если и проверите, то результаты будут очень расплывчатые.

Легко. Более того в ряде случаев вручную дешевле, чем тулом. Но это оффтопик. Мы говорим только о "священной корове".
  • 0

-- 

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

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

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

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

 


#65 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 11:31

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

Ну т.е. стратегия это всё-таки проектный, а не процессный артефакт. :) Я согласен, процесс тестирования не нужен для выбора стратегии.

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

Я Вам ещё раз говорю, нет таких програмных систем

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

Ну мы конечно про софтверное тестирование говорим, а не про принтеры. Но засчитано, я слишком широко выразился. Предлагаю оставить на усмотрение читателя.
  • 0

#66 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 11:40

Вручную вы производительность не проверите, а если и проверите, то результаты будут очень расплывчатые.

Легко. Более того в ряде случаев вручную дешевле, чем тулом. Но это оффтопик. Мы говорим только о "священной корове".

Естественно, вручную дешевле. Более-менее нормальные тулы для перформанс тестирования в хорошей комплектации сопоставимы по стоимости с неплохой машиной. Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке? Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.

Ладно, вернемся к священным коровам
  • 0

#67 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 11:50

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

Я Вам ещё раз говорю, нет таких програмных систем

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

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

Хорошо. Другой пример, не привязанный к харду. Аморфный перемешанный код. Например, РНР-вставки вперемешку с HTML + JavaScript. На уровне кода функционал, который несут собой такие страницы мы не проверим, так как там и модули как-то выбить трудно и опять же, много эффектов воспринимаются исключительно визуально. Бизнес-логику придется проверять только через интерфейс. А если там еще примешивается графика, то подобная проверка будет настолько кошмарной, что такие вещи мало кому захочется автоматизировать.
  • 0

#68 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 11:53

Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке?

По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.

Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.

Возьму свой любимый gray box тест и запущу с нужной интенсивностью в некоторое количество потоков - это несколько десятков строк кода дополнительно.
  • 0

#69 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 13:21

Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке?

По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.

Логи и audit-trail-ы могут либо отсутствовать либо содержать слишком много левого. Ковырять это не всегда приятно. Приходится использовать вспомагательные средства.

Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.

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

Ну это уже не вручную же :acute: Это уже автоматика.
  • 0

#70 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 13:28

Ну это уже не вручную же :acute: Это уже автоматика.

Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)
  • 0

#71 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 14:17

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

#72 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 14:32

Ну это уже не вручную же :acute: Это уже автоматика.

Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)

Вообще это пример задачи, которую проблематично решить вручную.

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

Подход. Прежде чем чего-то внедрять, нужно определить свои нужды, подготовить основу. Все-таки и у нагрузочного тестирования есть определенные сценарии, определенные условия.
  • 0

#73 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 14:49

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

А подход к нагрузочному тестированию вшит в процесс?

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

И потом посмотреть, всё ли там необходимо и все ли эти ресурсы могут существовать только в рамках процесса регрессионного тестирования.
  • 0

#74 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 15:19

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

А подход к нагрузочному тестированию вшит в процесс?

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

И потом посмотреть, всё ли там необходимо и все ли эти ресурсы могут существовать только в рамках процесса регрессионного тестирования.

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

А теперь, если немного абстрагироваться, то получится, что и для нагрузочного тестирования и для регрессионного нужно вначале подтянуть ресурсы, инструментальные средства, подготовить среду, заготовить тесты или выявить правила формирования тестов (например в модульном тестировании тест соответствует некоторой функции) и уже потом автоматизировать тесты. То есть в данном случае подход один и тот же независимо от вида тестирования. Но главное то, что автоматизация уже делается тогда, уже есть основа, когда есть чего автоматизировать.
  • 0

#75 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 31 января 2008 - 07:58

И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?

Я так понимаю что Вы подразумеваете, что для автоматизации тестирования нужно чтобы существовало не само тестирование, а процесс тестирования и спрашиваю, зачем конкретно это нужно.

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

А теперь, если немного абстрагироваться, то получится, что и для нагрузочного тестирования и для регрессионного нужно вначале подтянуть ресурсы, инструментальные средства, подготовить среду, заготовить тесты или выявить правила формирования тестов (например в модульном тестировании тест соответствует некоторой функции) и уже потом автоматизировать тесты. То есть в данном случае подход один и тот же независимо от вида тестирования. Но главное то, что автоматизация уже делается тогда, уже есть основа, когда есть чего автоматизировать.

Теперь Вы говорите что Вам требуется вот это, но описываете, на мой взгляд, уже не процесс, а набор абстрактных методов, причём довольно статичный. Что в нём такого уж процессного? И вообще что в нём такого уж специфического для конкретного проекта, почему нельзя просто записать это в методике, что вот нужно делать то-то и то-то и успокоится, а нужно настаивать на существовании полноценного процесса?

Можно вы тут пока сами? Вернусь на той неделе.
  • 0

#76 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 01 февраля 2008 - 10:08

И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?

Я так понимаю что Вы подразумеваете, что для автоматизации тестирования нужно чтобы существовало не само тестирование, а процесс тестирования и спрашиваю, зачем конкретно это нужно.

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

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

А теперь, если немного абстрагироваться, то получится, что и для нагрузочного тестирования и для регрессионного нужно вначале подтянуть ресурсы, инструментальные средства, подготовить среду, заготовить тесты или выявить правила формирования тестов (например в модульном тестировании тест соответствует некоторой функции) и уже потом автоматизировать тесты. То есть в данном случае подход один и тот же независимо от вида тестирования. Но главное то, что автоматизация уже делается тогда, уже есть основа, когда есть чего автоматизировать.

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

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

Что в нём такого уж процессного? И вообще что в нём такого уж специфического для конкретного проекта, почему нельзя просто записать это в методике, что вот нужно делать то-то и то-то и успокоится, а нужно настаивать на существовании полноценного процесса?

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

#77 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 01 февраля 2008 - 10:29

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

Нет, не понимаю.
Хорошо, будем считать что процесс это просто последовательность стадий, алгоритм, что после чего делать и какими входами выходами активности цепляются друг за друга.
Представим что есть уже внедрённый процесс регрессионного тестирования, который несколько десятков раз сработал.
И представим, что есть просто записанный на бумаге процесс автоматизировааного тестирования, который можно внедрить сверху вниз в первый же раз как вам понадобится провести итерацию автоматизированного тестирования.
В чём преимущество первого процесса перед вторым в данном случае? Или в чём сложность внедрения второго с первого раза?
  • 0

#78 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 01 февраля 2008 - 11:05

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

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

Разница в том, что для автоматизированного тестирования нужна куда более жесткая основа, иначе этот процесс быстро выйдет из управляемого состояния. Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).
  • 0

#79 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 01 февраля 2008 - 12:42

Разница в том, что для автоматизированного тестирования нужна куда более жесткая основа, иначе этот процесс быстро выйдет из управляемого состояния.

А что значит управляемое состояние? По-моему, для процесса, который просто является последовательностью действий, для управляемости достаточно просто возможности менять его описание и распространить новое описание среди участников.

Кстати, я просил сравнить живой и мёртвый процесс с точки зрения пригодности для автоматизации тестирования, в Вы мне говорите, что разница между ними в жёсткости основы. Только я не понял, какой из них полагается более жёстким?

Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).

Давайте конкретику - посмотрю, а так Вы только время тратите, моё и читателей, которым некуда посмотреть. Я несколько раз делал нагрузочное тестирование для сторонних заказчиков, про орг. вопросы имею представление, и ни разу никаких ассетов, артефактов, ресурсов от существующего процесса регрессионного тестирования для этого не понадобилось (от других процессов было нужно, но не всегда, кроме того, те сведения можно и нужно было в ряде случаев добыть "внепроцессно"). Ну разве только, тест-кейсы были нужны для записи скриптов, которые, впрочем, тоже отбирались по признакам, которые нельзя получить из процесса регрессионного тестирования и которые можно было написать тоже "внепроцессно", по документации. Т.е. они были, эти ассеты процесса регрессионного тестирования, но для внедрения автоматизации были не нужны. Вы необходимых среди них тоже назвать не смогли.

Сообщение отредактировал a66at: 01 февраля 2008 - 13:10

  • 0

#80 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 01 февраля 2008 - 13:12

Разница в том, что для автоматизированного тестирования нужна куда более жесткая основа, иначе этот процесс быстро выйдет из управляемого состояния.

А что значит управляемое состояние? По-моему, для процесса, который просто является последовательностью действий, для управляемости достаточно просто возможности менять его описание и распространить новое описание среди участников.

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

Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).

Давайте конкретику - посмотрю, а так Вы только время тратите, моё и читателей, которым некуда посмотреть. Я несколько раз делал нагрузочное тестирование для сторонних заказчиков, про орг. вопросы имею представление, и ни разу никаких ассетов, артефактов, ресурсов от существующего процесса регрессионного тестирования для этого не понадобилось (от других процессов было нужно, но не всегда, кроме того, те сведения можно и нужно было в ряде случаев добыть "внепроцессно"). Ну разве только, тест-кейсы были нужны для записи скриптов, которые, впрочем, тоже отбирались по признакам, которые нельзя получить из процесса регрессионного тестирования и которые можно было написать тоже "внепроцессно", по документации. Т.е. они были, эти ассеты процесса регрессионного тестирования, но для внедрения автоматизации были не нужны. Вы необходимых среди них тоже назвать не смогли.

Не, ну вы привязались к переходу с регрессионки на перформанс. А вы можете автоматизировать регрессионное тестирование, не поставив при этом само регрессионное тестирование? То же самое с перформансом. Автоматизация наращивается, но не ставится. А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.
  • 0


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

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