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

[VDmitry]

По крайней мере речь про ситуацию с двумя последовательными тесткейсами в тестплане

Ситуация. Первый тескейс регистрирует нового юзера. Второй за ним логиниться этим юзером.

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

Ради чего такой подход?

Можно было конечно отказаться от генерации имен. Но есть же такой термин как например High Volume Automation и все такое...

[Dmitry_NS]

По крайней мере речь про ситуацию с двумя последовательными тесткейсами в тестплане

Ситуация. Первый тескейс регистрирует нового юзера. Второй за ним логиниться этим юзером.

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

Ради чего такой подход?

Можно было конечно отказаться от генерации имен. Но есть же такой термин как например High Volume Automation и все такое...

Это скорее не подход, это скорее реализация. Запуск тесткейсов из тестплана равносилен последовательному запуску каждого тесткейса независимо друг от друга. То есть это то же самое, что вы вы брали один тесткейс, запустили его, затем взяли следующий и так же запустили его. Это вообще одна из распространенных практик, целью которой является избежать эффекта домино для тестов и формируется эта практика по правилу "тест работает при пакетном запуске так же как и при одиночном". Если же у вас тесты привязаны к данным других тестов, то тогда лучше бы их объединить в один тесткейс (а все равно раздельно они не запускаются).

[VDmitry]

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

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

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

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

[Dmitry_NS]

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

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

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

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

Что вам там дополнительно логировать придется? Ошибки, они ошибками и останутся.

Ну и отдельно хотелось бы поговорить про "эффект домино". Так ли на практике страшен черт, как его малюют.

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

Вот скажем есть тест который создает документ (А), и следом за ним который в него что-то пишет (Б). Допустим тест А сдох. Тест Б автоматом тоже. Но откуда берется утверждение, что если бы тест Б не зависел от А, то он бы прошел? Он что, другой код будет использовать для создания?
Если в прилаге ломается создание документов, то как ни вертись, скриптом его не создашь. Хотя я могу допустить, что в некоторых ситуациях это помогает, но от интересно как часто.

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

Вы еще учтите такой момент, что библиотека 4Test дизайнилась как раз из расчета на то, что тесты будут независимыми. То есть мы зашли в нужную точку (appstate), выполнили действия (testcase), восстановили исходное состояние (appstate). Это можно в хелпе найти.

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

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

[VDmitry]

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

Что вам там дополнительно логировать придется? Ошибки, они ошибками и останутся.

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

Что мне не понравилось - вроде нельзя начать отладку тесткейса с уровня тестплана, приходится писать вызов с нужными параметрами где-то в main()

И по частям я их запускаю например для повторения конкретно того кода, который споткнулся. Для этого нужно просто знать, какие тесты от чего зависят. Запускать тесткейс на целый час заново, чтобы повторить багу на 35-й минуте?

Ну и отдельно хотелось бы поговорить про "эффект домино". Так ли на практике страшен черт, как его малюют.

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

Если в прилаге ломается создание документов, то как ни вертись, скриптом его не создашь. Хотя я могу допустить, что в некоторых ситуациях это помогает, но от интересно как часто.

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

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

[Dmitry_NS]

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

Что вам там дополнительно логировать придется? Ошибки, они ошибками и останутся.

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

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

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

Что мне не понравилось - вроде нельзя начать отладку тесткейса с уровня тестплана, приходится писать вызов с нужными параметрами где-то в main()

И по частям я их запускаю например для повторения конкретно того кода, который споткнулся. Для этого нужно просто знать, какие тесты от чего зависят. Запускать тесткейс на целый час заново, чтобы повторить багу на 35-й минуте?

Как сказать.

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

Во-вторых, если у вас весь тестсет расчитан на общее время выполнения не час, а скажем часов 6-8 как минимум, то тут надо подумать над тем, чтобы тесткейсы выполнялись без вашего контроля. Например, поставили на ночь. Так, от малейшего пука весь тестсет рухнет. Да, вы можете прийти потом и с нужного места стартовать, но не лучше ли на следующий день собрать упавшие тесткейсы и выполнить конкретно их, отбросив все остальные?

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

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

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

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

Вы создавали нового пользователя для каждого тесткейса?

Если я тестирую некоторый функционал, не привязанный к конкретному пользователю, то мне все равно какой пользователь будет. Соответственно, я беру любого из них. Для систем, где используется аутентификация пользователя, я обычно резервирую одного пользователя и использую его в большинстве тестов. Если же есть специфика, зависящая от пользователя (например, разные security permissions), то тогда я уже отдельно создам пользователей с нужными настройками, чтобы гарантировать наччальные условия, и буду работать с ним. А таких тестов не так уж и много по сравнению с остальным объемом тестов.

Вы готовили пользователей отдельно от тестов посредством запуска SQL скрипта прямо на базе и доказывали что это идентично тому что происходит при создании посредством ГУИ?

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

Вы переставляли базу после каждого тесткейса?

После тесткейса нет, а после тестсета целиком - да, было дело. Это один из этапов подготовки среды.

Винду? Или если речь идет о минимизации риска от эффекта Домино, то есть ли методики позволяющие определить где именно провести границу?

Очень много завязано на тест-дизайн и на то, как разделить тесты. Можно взять некоторый operational flow - наиболее ходовой сценарий работы с приложением или просто основной. А можно повыделять отдельно бизнес-функции и построить тесты по принципу "подготовил ресурсы - перешел к функции - выполнил ее - вышел". Как доставать дополнительные данные - это отдельный разговор. Есть несколько техник для этого. Но факт, что второй подход как раз хорошо позволяет локализовать тесты.

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

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

[VDmitry]

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

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

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

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

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

И можно подробнее почему параметров в тесткейсах стоит избегать?! Раз уж отделять данные от кода, так совсем?

Вы переставляли базу после каждого тесткейса?

После тесткейса нет, а после тестсета целиком - да, было дело. Это один из этапов подготовки среды.

Интересно, эта перестановка делалась на автомате?

[Dmitry_NS]

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

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

Такие вещи просто нахрапом не берутся. На самом деле каждый отдельный тест требует в качестве начальных условий наличия некоторого набора записей или просто объектов, с которыми он работает. Этот набор ограничен для данного теста. Более того, часть записей можно создать, а часть взять прямо из системы. Например, вам для заполнения формы нужно взять некоторый существующий элемент, который может быть выбран прямо там из списка или выбран через поиск. И не важно, откуда он взялся изначально, просто есть уже в системе - это единственное условие. В этом случае проще выбрать случайным образом элемент из списка. Это уже уменьшает затраты на разработку. Причем, что характерно, для подготовки данных вырабатывается несколько подходов, их где-то 3-4, не более. И в зависимости от ситуации используется тот, что нужно.

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

И еще насчет способа организации тестов. Однажды на военке нашего препода по тактике спросили, правильное ли то или иное решение по размещению подразделений. На что был ответ: "Фактически любое решение правильное, главное, чтоб свои же по своим не стреляли. Главое потом - это суметь управлять этой всей системой". Так вот, применительно к организации тестов, любое ваше решение будет правильным, если вы потом с ним сможете управиться. Просто если все тесты связать друг с другом, то у вас могут появиться дополнительные проблемы, о которых я написал выше. Справитесь с тем, что есть - хорошо. Если есть проблемы - я показал направление.

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

Естественно. Поэтому-то и выделен отдельный тип файлов, как файлы тестплана со своими операциями. Я просто к тому, что просто понимайте суть этого. Это фактически батник + некоторые дополнительные фичи.

И можно подробнее почему параметров в тесткейсах стоит избегать?! Раз уж отделять данные от кода, так совсем?

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

Вы переставляли базу после каждого тесткейса?

После тесткейса нет, а после тестсета целиком - да, было дело. Это один из этапов подготовки среды.

Интересно, эта перестановка делалась на автомате?

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

[VDmitry]

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

Какие например имеются ввиду подходы? Из дампа, с помощью специально созданных функций по вводу данных через гуи? Еще?

Справитесь с тем, что есть - хорошо. Если есть проблемы - я показал направление.

Ок, посмотрим.

И можно подробнее почему параметров в тесткейсах стоит избегать?! Раз уж отделять данные от кода, так совсем?

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

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

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

Интересно, как это происходило. Вот например дамп базы брался когда? Каждый билд через ГУИ набивали данные, снимали дамп, проводили тесты, восстанавливали базу, проводили следующие? Или если бы фиксированный дамп на все время, то как можно было полагаться на его корректность по отношению к новым билдам?

[Dmitry_NS]

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

Какие например имеются ввиду подходы? Из дампа, с помощью специально созданных функций по вводу данных через гуи? Еще?

1) Из заготовленного дампа базы данных (уже залитого в тестовую среду ).
2) Создание записи через непосредственное обращение к базе или через вспомагательные элементы (веб-сервисы например)
3) Создание записи специальными функциями через ГУИ
4) Произвольный выбор существующих записей во время выполнения скрипта
5) Случайное заполнение/выбор (как правило, это используется для заполнения форм, не привязанных к другим записям)

И можно подробнее почему параметров в тесткейсах стоит избегать?! Раз уж отделять данные от кода, так совсем?

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

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

Вот это очень похоже на data-driven тест, который в тестплане описывается фактически 2-3 строчками. И это более резонная форма.
Кстати, если вам так важна наглядность тестплана, то я бы порекомендовал поработать немного в другом направлении. Лучше позаботиться о том, чтобы у тесткейсов были информативные имена, чтобы они были сгруппированы тематически (все-таки каждый отдельный тесткейс выполняет некоторую узкую активность), тут можно и комментарии приписать для наглядности.

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

Четкость обозначения тестов зависит от того, как вы их разместите, как вы их назовете и т.п., о чем я указал немного выше. Строчек с комментариями вы можете накидать сколько угодно, а за подробностями вам надо будет лезть в код, что вполне нормально. Более того, вместо читабельности тестплана уделите основное внимание наглядности лога результатов. Его-то вам читать уж наверняка придется и уже исходя из его содержимого определять, где же проблема возникла, а это уже совсем другая история, тут много своих нюансов.

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

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

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

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

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

Интересно, как это происходило. Вот например дамп базы брался когда? Каждый билд через ГУИ набивали данные, снимали дамп, проводили тесты, восстанавливали базу, проводили следующие? Или если бы фиксированный дамп на все время, то как можно было полагаться на его корректность по отношению к новым билдам?

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

Если же возникали сомнения в актуальности базы по отношению к новой версии, то разрабатывался скрипт, который бы через ГУИ набил базу нужными данными (через ГУИ специально, чтоб не нарушать чистоту эксперимента, так как конечный пользователь будет пополнять базу через ГУИ ).

[VDmitry]

ок, спасибо за ответы