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

[YuP]

Как и многие присутствующие выбираю систему управления процессом тестирования :). Пересмотрел уже большое их количество.. На 100 подходящей, да что там, хотя бы на 75% пока не нашел.

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

Расскажите, как обойтись одним только описанием теста, без ссылки на набор данных. Ну неужели копировать тест столько раз, сколько есть наборов?

[Ra.]

Но больше всего интересует тот факт, что ни в одной из них пока не встретил такой сущности, как Набор_Данных.

В Rational ClearQuest это точно есть. Я сегодня поставил eval версию, правда пока только мельком его глянул
(что-то он плохо у меня встал, нужно посидеть поразбираться).
Из всего виденного на мой (очень скромный :) взгляд, это лучший продукт...

Но еще, возможно, Вы не совсем чётко формулируете, что именно вас не устраивает.

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

В любом случае в Rational я это видел. Гляньте, может появятся еще интересные мысли.

[YuP]

Хочется вот чего.. Запускаем тестирование. Появляется перед глазами Тест1 с Набором_данных1. Проверили, нажали "Pass". Открывается Тест1 и Набор_Данных2. Проверили, оказалось "Faild".

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

[Ra.]

Хочется вот чего.. Запускаем тестирование. Появляется перед глазами Тест1 с Набором_данных1. Проверили, нажали "Pass". Открывается Тест1 и Набор_Данных2. Проверили, оказалось "Faild".

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

Сложно дискутировать :) Не совсем ясно что вы подразумеваете под фразой: "Появляется перед глазами Тест1 с Набором_данных1"??

Что значит "появляется перед глазами Тест1"? Означает ли эта фраза, что появляется описание тест кейза? Это ручной тест, или автоматизированный? Если ручной, то кто мешает в очередном шаге выполнения теста написать: "Взять данные из приаттаченного файла test_data_file01.csv и выполнить такие то действия" в следующем шаге написать: "Взять данные из приаттаченного файла test_data_file02.csv и выполнить аналогичные действия" и т.д.? Почему нет?

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

[YuP]

:) Хотел попроще написать.. Попробую еще раз.

Это все значит вот что:
Ручное тестирование.
Имеется один тест, состоящий из 10 шагов. Название теста "Тест1".
Тест "Тест1" необходимо выполнить на 2 наборах данных. На шаге 1 используется параметр №1 из текущего набора данных, на шаге 2 - параметр "2, и т.д.
"Тест1" включен в единственный скрипт или набор тестов "ТестСкрипт1".

Появляется новый билд тестируемой программы.

Запускаем выполнение тестирования - система отображает все тесты, которые необходимо выполнить для нового билда. В большинстве TMS отобразится единственный тест "Тест1" и подставлять тестировщик туда параметры должен, как хочет (Например, в соответствии с инструкцией "Взять данные из приаттаченного файла.."). Тестировщик может только один раз нажать "Успех" и "Провал" по результатам успешности выполнения теста.

А мне логичным представляется, чтобы система отобразила "Тест1" два раза - первый раз со ссылкой на набор данных №1, второй раз - на набор данных №2. Соответственно тестировщик может для первого набора данных выбрать результат "Успех", а для второго "Провал".

Так понятнее?

[Ra.]

Тестировщик может только один раз нажать "Успех" и "Провал" по результатам успешности выполнения теста.

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

Поясню. Во многих инструментах можно указать ШАГИ выполнения теста. И соответственно результаты этих шагов. (Для каждого шага!)
Примеры таких систем: SpiraTest или rth

И вы можете указать результат выполнения КАЖДОГО шага. Нетрудно догадаться как тогда нужно построить свою работу:
1. В общем описании теста указываем общую последовательность действий с любым набором данных
2. Заводим требуемое количество "шагов" теста с формулировкой: "выполнить тест с таким то набором данных".

Все. В результате тестеру достаточно указать какие шаги теста (т.е. какие наборы данных) привели к неверным результатам.

Так пойдет?

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

[YuP]

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

[YuP]

Можно, но неудобно, т.к.
1) Сколько наборов данных, столько шагов надо добавлять в тест. А при изменении количества редактировать тест.
2) Тест и так из нескольких шагов состоит. Поэтому не получится отметить, что произошла ошибка, скажем, на третьем шаге для второго набора данных.

[Ra.]

Можно, но неудобно, т.к.
1) Сколько наборов данных, столько шагов надо добавлять в тест. А при изменении количества редактировать тест.
2) Тест и так из нескольких шагов состоит. Поэтому не получится отметить, что произошла ошибка, скажем, на третьем шаге для второго набора данных.

Вам действительно непонятно, или Вы шутите?

[YuP]

Вам действительно непонятно, или Вы шутите?

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