Тестирование готового ПО
#1
Отправлено 18 мая 2009 - 12:02
Сам я не тестировщик ПО ни в коей мере, однако, в силу работы, приходится заниматься тестированием готового ПО, так что скоро можно уже будет полноправно причислить себя и к тестировщикам ПО ;-)
Проблема вот в чём:
1. Имеется готовый Продукт - программа с полным набором экзешников, длллек, хелпов, конфигурационников и всего остального-прочего
2. Фирма-исполнитель (Разработчики) постоянно выпускают новые версии продукта, разрабатываемого по нашему заказу.
3. Естественно, что пользоваться тем, что выпускают разработчики никто не будет - необходимо протестировать полученное ПО
4. Существует несколько тестовых конфигураций Продукта для выполнения различных задач (и разные конфигурационники); существует несколько стабильных версий Продукта, для которого выпускаются обновления конфигурации самим Заказчиком.
Задача:
1. Увязать тестовые версии в различных сборках и конфигурациях и стабильные версии в конфигурациях, использовать некоторую систему контроля версий.
2. В конечном счёте - изменения со стабильных версий должны попадать и в тестовые
Только во проблема в том, что большинство систем контроля версий - для разработчиков ПО, работают на уровне исходного кода. Как же тогда организовать систему контроля версий для уже готового проекта? Мерджить конфиги, дллки, хелпа и прочее?
Быть может, кто-нибудь имел дело с этим? Был бы признателен за любую помощь по вопросу.
#2
Отправлено 18 мая 2009 - 16:03
- есть стабильная сборка продукта (как совокупность файлов и их версий)
- время от времени выдаются новые версии отдельных файлов
- после тестирования хочется добавить некоторые из этих файлов в стабильную сборку
Строить репозиторий можно не только из исходных кодов, но и из бинарных файлов.
Просто каждый файл должен обладать уникальным номером билда (если исполнитель не обеспечивает это при сборке, то в качестве идентификатора можно взять md5 сумму).
Сборка в этом случае представляет собой многомерный вектор по версиям файлов.
Репозиторий можно организовать в виде папок по компонентам/версиям. И написть батники вида build_XXX, которые будут складывать определенным образом файлы нужных версий .
А можно использовать системы контроля версий типа CVS или SVN - в этом случае вытаскивать "сборку" можно по тагу.
Главное, чтобы "сборка" была повторяемой. Тогда на тестовых и продакшн системах можно получить одинаковые наборы файлов.
Нюнасы типа баз данных, кофиг. файлов или ключей в реестре не рассматриваю (но здесь тоже все решаемо).
#3
Отправлено 19 мая 2009 - 03:21
SVN сможет это обеспечить? И вообще, интересно, какие тулзы могут быть использованы тут?
#4
Отправлено 19 мая 2009 - 06:07
SVN сможет!SVN сможет это обеспечить? И вообще, интересно, какие тулзы могут быть использованы тут?
По вашим постам складывается впечатление, что вы имеете мало опыта работы с VCS`ами (может ошибаюсь). Почитайте http://svnbook.red-bean.com/en/1.5/ или что-то по контролю версий. Проведите свои варианты использования в SVN на модельных примерах, поможет.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#5
Отправлено 19 мая 2009 - 06:56
Поставил SVN. Поставил TortoiseSVN. Создал репу, импортировал несколько версий. Вот что примерно получилось:
repo_tree.PNG 30,49К 45 Количество загрузок:
Пояснения:
Версии папки Dev - тестируемые. Есть базовая версия, есть отдельная сборка (например, для Яндекса)
Версии папки Stable - стабильные. Опять же - есть базовая версия, есть отдельная для кого-то (тут - для Рамблера)
Смотрите - я вношу изменения в любой конфигурационный файл стабильной 1.28. Надо эти же изменения распихать и по тестовым сборкам папки Dev. Вручную - много времени занимает.
Вот создал такое дерево версий, а что с ним дальше делать - не знаю. Черепаха не позволяет сравнить файлы из двух разных версий - только версии целиком. Что-то вообще малдо понятно про то, что потом-то с черепахой можно делать - кроме как хранить уже готовое и собранное.
#6
Отправлено 19 мая 2009 - 07:18
Ветки и слияния ваше спасение.Смотрите - я вношу изменения в любой конфигурационный файл стабильной 1.28. Надо эти же изменения распихать и по тестовым сборкам папки Dev. Вручную - много времени занимает.
http://svnbook.red-b...ranchmerge.html
А почему не вносить эти изменения в исходники и из них собирать новую(-ые) версию(-ии)? В этом случае вообще не хранить бинарники, а всегда собирать из исходников.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#7
Отправлено 19 мая 2009 - 08:39
А почему не вносить эти изменения в исходники и из них собирать новую(-ые) версию(-ии)? В этом случае вообще не хранить бинарники, а всегда собирать из исходников.
Внимательнее - как и описано в исходных данных, мы заказываем ПО у разработчика. Разработчик передаёт нам ПО, а мы его тестируем. Ведь не будем же мы принимать бажную версию, которая не работает. Поэтому исходников нет и не будет никогда. Вот и возникает такая задача - приёмочное тестирование переданных версий. Версии настраиваются конфигурационными файлами.
#8
Отправлено 19 мая 2009 - 16:46
Понял, моя ошибка.Внимательнее - как и описано в исходных данных, мы заказываем ПО у разработчика.
Надеюсь в остальном помог.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#9
Отправлено 20 мая 2009 - 09:21
#10
Отправлено 20 мая 2009 - 13:51
Можно ветки называть как угодно (и класть как угодно/удобно в репозитории), например как в вашем скриншоте. Чтобы переносить между ветками измения применяется merge — это как раз то, что вам надо, как я понял.Например, можно одну стабильную версию сделать транком, а все последующие тестовые версии - копировать (бранчами). А ежели простой импорт всех версий - это будет совсем не то?
На самом деле svn для бинарников тоже самое, что и для кода.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#11
Отправлено 20 мая 2009 - 13:52
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных