Тестирование готового ПО

Добрый день всем!

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

Проблема вот в чём:
1. Имеется готовый Продукт - программа с полным набором экзешников, длллек, хелпов, конфигурационников и всего остального-прочего
2. Фирма-исполнитель (Разработчики) постоянно выпускают новые версии продукта, разрабатываемого по нашему заказу.
3. Естественно, что пользоваться тем, что выпускают разработчики никто не будет - необходимо протестировать полученное ПО
4. Существует несколько тестовых конфигураций Продукта для выполнения различных задач (и разные конфигурационники); существует несколько стабильных версий Продукта, для которого выпускаются обновления конфигурации самим Заказчиком.

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

Только во проблема в том, что большинство систем контроля версий - для разработчиков ПО, работают на уровне исходного кода. Как же тогда организовать систему контроля версий для уже готового проекта? Мерджить конфиги, дллки, хелпа и прочее?

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

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

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

Сборка в этом случае представляет собой многомерный вектор по версиям файлов.

Репозиторий можно организовать в виде папок по компонентам/версиям. И написть батники вида build_XXX, которые будут складывать определенным образом файлы нужных версий .

А можно использовать системы контроля версий типа CVS или SVN - в этом случае вытаскивать "сборку" можно по тагу.

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

DrVal - вот смотрите, моделируем ситуацию: есть тестовая версия 1.5 продукта. Эта версия собирается (вручную, не разработчиком) в виде трёх разных сборок, которые необходимо протестировать. А есть версия 1.0 продукта и к ней выпускаются апдейты (в основном в виде изменяющихся xmlок). Так вот задача еще в том, чтобы из 1.0 эти изменения попали и в тестовые версии. Ну и, в случае принятия версии, из тестовых 1.5 изменения пошли в стабильную 1.5.

SVN сможет это обеспечить? И вообще, интересно, какие тулзы могут быть использованы тут?

SVN сможет это обеспечить? И вообще, интересно, какие тулзы могут быть использованы тут?

SVN сможет!

По вашим постам складывается впечатление, что вы имеете мало опыта работы с VCS`ами (может ошибаюсь). Почитайте http://svnbook.red-bean.com/en/1.5/ или что-то по контролю версий. Проведите свои варианты использования в SVN на модельных примерах, поможет.

Alfa - совершенно верно, не ошибаетесь - не имею никакого опыта ;-) Хотя вполне представляю как работать с контролем версий при использовании исходных файлов (кода) ПО. А вот с готовыми версиями возник затор. Всё, что есть в настоящий момент - куча папок с тестовыми сборками. И когда происходят изменения в когфигах релизной версии, приходится всё переносить в тестовые вручную.

Поставил SVN. Поставил TortoiseSVN. Создал репу, импортировал несколько версий. Вот что примерно получилось:
 repo_tree.PNG   30,49К   45 Количество загрузок:

Пояснения:
Версии папки Dev - тестируемые. Есть базовая версия, есть отдельная сборка (например, для Яндекса)
Версии папки Stable - стабильные. Опять же - есть базовая версия, есть отдельная для кого-то (тут - для Рамблера)

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

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

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

Ветки и слияния ваше спасение.
http://svnbook.red-b...ranchmerge.html

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

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

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

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

Понял, моя ошибка.
Надеюсь в остальном помог.

Например, можно одну стабильную версию сделать транком, а все последующие тестовые версии - копировать (бранчами). А ежели простой импорт всех версий - это будет совсем не то?

Например, можно одну стабильную версию сделать транком, а все последующие тестовые версии - копировать (бранчами). А ежели простой импорт всех версий - это будет совсем не то?

Можно ветки называть как угодно (и класть как угодно/удобно в репозитории), например как в вашем скриншоте. Чтобы переносить между ветками измения применяется merge — это как раз то, что вам надо, как я понял.

На самом деле svn для бинарников тоже самое, что и для кода.

К SVN документация есть и на русском http://svnbook.red-b...y/ru/index.html , если Вам так удобней.