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

Фотография

Тестирование с середины разработки


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

#1 luden

luden

    Новый участник

  • Members
  • Pip
  • 17 сообщений
  • Город:Russia - Novosibirsk

Отправлено 15 октября 2004 - 04:51

Может кто-нибудь подскажет книги/статьи/сайты/спецификации на тему автоматизации тестирования в процессе разработки. Т.е. когда автоматизация вводиться не с начала разработки, а уже после многих и многих релизов.
В литературе в основном описаны ситуации в которых разработка тестов ведется параллельно с разработкаой продукта. А в данном случае, интеграционное тестирование сведено к минимуму, 90% занимает функционал.

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

#2 Green

Green

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

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 15 октября 2004 - 06:12

luden,

Нет никакой разницы когда начинать автоматизировать тесты, т.к. сам процесс автоматизации при этом не изменяеться.

Главный вопрос - какие тесты автоматизировать в первую очередь?
И он уже обсуждался на форуме. Предлагаю посмотреть мои предыдущие сообщения.
Если ничего не найдете - пишите.
  • 0
Гринкевич Сергей

#3 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 15 октября 2004 - 07:31

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

#4 luden

luden

    Новый участник

  • Members
  • Pip
  • 17 сообщений
  • Город:Russia - Novosibirsk

Отправлено 15 октября 2004 - 07:53

В том-то и дело, что не заморозили ;) И "фича имплементинг" в полном разгаре.
. . .
Написал длинное сообщение и полнял, что хочу странного :)
Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.

Всем спасибо.
  • 0

#5 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 октября 2004 - 11:07

Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.

Если не секрет, уточните, что Вы имели в виду под "GUI+backend"? Означает ли это, что Вы предполагаете тестировать модель (если оперировать терминами архитектуры MVC) отдельно от GUI? Тогда почему "GUI+backend", а не просто "backend"?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#6 luden

luden

    Новый участник

  • Members
  • Pip
  • 17 сообщений
  • Город:Russia - Novosibirsk

Отправлено 15 октября 2004 - 11:18

Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.

Если не секрет, уточните, что Вы имели в виду под "GUI+backend"? Означает ли это, что Вы предполагаете тестировать модель (если оперировать терминами архитектуры MVC) отдельно от GUI? Тогда почему "GUI+backend", а не просто "backend"?

Наверное я просто в своем контексте, извиняюсь за неточность. Я имел ввиду следующее: автоматизирую тестирование через пользовательский интерфейс и добавлю функции для тестирования в обход интерфейса.
  • 0

#7 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 15 октября 2004 - 11:28

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

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

#8 luden

luden

    Новый участник

  • Members
  • Pip
  • 17 сообщений
  • Город:Russia - Novosibirsk

Отправлено 16 октября 2004 - 07:25

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

(я знаю, как я сам ответил бы на этот вопрос, но хочу услышать независимое мнение).

1) Например в момем случае в продукте есть консольные команды не связанные с GUI
2) После некоторого действия в GUI можно напрямую проверить созданные данные ( тестирование выхода черного ящика) Т.е. можно на лету проверить правильность выполненных действий.
3) Сразу забивать подготовленные тестовые данные напрямую.

В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.

Было бы интересно услышать Ваше мнение.
  • 0

#9 Oleg_V

Oleg_V

    Новый участник

  • Members
  • Pip
  • 14 сообщений
  • Город:Reston, VA

Отправлено 21 октября 2004 - 21:45

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

Удачи!
  • 0

#10 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 22 октября 2004 - 00:35

Прежде всего надо начинать с (в порядке приоритета):

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

Ессно - это субъективная точка зрения (но основаная на опыте). Надеюсь, я хоть немножко вам помог. :)
  • 0
no fate but what we make

#11 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 22 октября 2004 - 04:48

В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.

Ещё уточню, если можно, какое время сокращается -- время на разработку тестов, на отладку, на сопровождение, на выполнение (прогон в регрессионном режиме)?

Было бы интересно услышать Ваше мнение.

По этому поводу готовится статья. Где будет опубликована -- пока не скажу, но как только появится -- сообщу. Тогда мы это дело подробно обсудим.
Собственно именно поэтому мне так интересно предварительно сравнить своё мнение с чужим опытом.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#12 luden

luden

    Новый участник

  • Members
  • Pip
  • 17 сообщений
  • Город:Russia - Novosibirsk

Отправлено 22 октября 2004 - 05:44

В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.

Ещё уточню, если можно, какое время сокращается -- время на разработку тестов, на отладку, на сопровождение, на выполнение (прогон в регрессионном режиме)?

В обход GUI можно работать на разных уровнях. Ну например: в случае веб приложений - можно напрямую отправлять данные форм а можно сразу забивать в базу данных. В первом случае мы фактически уменьшаем время загрузки гуя, во втором - уменьшаем время обработки данных.
Для каждого конкретного приложения будут свои уровни, на каждом из которых можно работать по своему. Спускаясь вниз мы уменьшаем время вода и обрабоки данных, но соответственно и не тестим эту функциональность. (в идеале бы на каждый уровень поставить по watchdog`у и трэйсить весь путь поступивших данных, но это мечты ;) )

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

В любом случае все зависит от уровня обхода гуя.
  • 0

#13 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 22 октября 2004 - 05:49

>> можно сразу забивать в базу данных

А что вы собственно будете тестить в этом случае? ;)
  • 0
no fate but what we make

#14 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 22 октября 2004 - 06:24

>> можно сразу забивать в базу данных

А что вы собственно будете тестить в этом случае? ;)

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

luden очень верно заметил, что современное ПО "слоистое", поэтому можно выбрать слой и тестировать его вместе со всем, что под ним. Иногда можно даже выбрать несколько слоёв, сделать заглушку снизу и тестировать такой "некомплект".

Какие при этом возникают специфические аспекты?

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

Во-вторых, квалификация, как тоже верно отметил luden нужна разная для тестирования разных слоёв.

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

У нас был опыт тестирования веб-приложения на двух уровнях (сервлеты через HTTP и EJB непосредственно в контейнере), в котором мы обнаружили ряд латентных ошибок на уровне EJB, которые "наверх" не проявлялись. К чести разработчиков, они всё признали и исправили.

Конечно, перечисленные аспекты не исчерпывают список возможных плюсов и минусов. Если кто-то ещё поделится опытом тестирования одного и того же приложения на разных уровнях -- буду очень благодарен!
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#15 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 22 октября 2004 - 06:38

Есть еще один очень важный момент в тестировании не верхнего, то есть не интерфейса приложения, уровня.
Это, как правило, большой недостаток документации.
То есть, если функциональную спецификацию еще худо-бедно можно достать, т.к. ее делают не только для разработчиков, но и для других подразделений, то со спецификацией на отдельные уровни - просто беда.
Многие вопросы решаются на уровне Иванов, пишущий JSPшки, договорился с Петровым, пишущим бины, что этот метод будет работать так. Соответственно, какое все-таки поведение метода правильное? Правильно! Именно такое, какое мы и видим.
Т.е. приходится моделировать ситуации, когда поведение метода может вызвать ошибки на самом верхнем уровне. В большинстве случаев это не выгодно и проще тестировать все приложение целиком.
Как вариант - все таки навесить на разработчиков писать спецификацию.
  • 0
no fate but what we make


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

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