Тестирование с середины разработки
#1
Отправлено 15 октября 2004 - 04:51
В литературе в основном описаны ситуации в которых разработка тестов ведется параллельно с разработкаой продукта. А в данном случае, интеграционное тестирование сведено к минимуму, 90% занимает функционал.
Принципиальное отличие вижу том, что при интеграционном тестировании к концу накапливается обширная база тестов, покрывающая функциональность. А в моем случае существует black-box и надо сделать так чтоб дальнейшие его релизы хоть немножко но тестились автоматически.
#2
Отправлено 15 октября 2004 - 06:12
Нет никакой разницы когда начинать автоматизировать тесты, т.к. сам процесс автоматизации при этом не изменяеться.
Главный вопрос - какие тесты автоматизировать в первую очередь?
И он уже обсуждался на форуме. Предлагаю посмотреть мои предыдущие сообщения.
Если ничего не найдете - пишите.
#3
Отправлено 15 октября 2004 - 07:31
#4
Отправлено 15 октября 2004 - 07:53
. . .
Написал длинное сообщение и полнял, что хочу странного :)
Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.
Всем спасибо.
#5
Отправлено 15 октября 2004 - 11:07
Если не секрет, уточните, что Вы имели в виду под "GUI+backend"? Означает ли это, что Вы предполагаете тестировать модель (если оперировать терминами архитектуры MVC) отдельно от GUI? Тогда почему "GUI+backend", а не просто "backend"?Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#6
Отправлено 15 октября 2004 - 11:18
Наверное я просто в своем контексте, извиняюсь за неточность. Я имел ввиду следующее: автоматизирую тестирование через пользовательский интерфейс и добавлю функции для тестирования в обход интерфейса.Если не секрет, уточните, что Вы имели в виду под "GUI+backend"? Означает ли это, что Вы предполагаете тестировать модель (если оперировать терминами архитектуры MVC) отдельно от GUI? Тогда почему "GUI+backend", а не просто "backend"?Вобщем начну наверно все таки с GUI, потом GUI+backend, потом акцент на новые фичи, потом раздроблю, и напишу распределенку.
#7
Отправлено 15 октября 2004 - 11:28
(я знаю, как я сам ответил бы на этот вопрос, но хочу услышать независимое мнение).
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#8
Отправлено 16 октября 2004 - 07:25
1) Например в момем случае в продукте есть консольные команды не связанные с GUIВопрос: зачем тестировать в обход интерфейса? Какие цели при этом преследуются? Каких результатов предполагается достичь, которые труднее или невозможно достичь тестированием через интерфейс?
(я знаю, как я сам ответил бы на этот вопрос, но хочу услышать независимое мнение).
2) После некоторого действия в GUI можно напрямую проверить созданные данные ( тестирование выхода черного ящика) Т.е. можно на лету проверить правильность выполненных действий.
3) Сразу забивать подготовленные тестовые данные напрямую.
В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.
Было бы интересно услышать Ваше мнение.
#9
Отправлено 21 октября 2004 - 21:45
- Выясните, что должно произойти при нажатии кнопки. Если функциональность не задокументирована, то поговорите с разработчиками.
- Опишите вначале словами шаги проверки. Дайте посмотреть это разработчикам - верно ли вы их поняли.
- А теперь просто переведите ваши слова в скрипт. Может там слова GUI и не встретится.
Удачи!
#10
Отправлено 22 октября 2004 - 00:35
1. С функциональности со стабильным интерфейсом. ГУИ, не ГУИ - не важно. Иначе, зароетесь в поддержке тестов.
2. С изменяющейся функциональности, ну или, точнее, с той, над которой сейчас работают. Ессно, при условии стабильного интерфейса. Какой смысл писать тесты для законченой фичи - вы просто скорее всего не найдете ошибок.
3. С наиболее важной функциональности.
Ессно - это субъективная точка зрения (но основаная на опыте). Надеюсь, я хоть немножко вам помог. :)
#11
Отправлено 22 октября 2004 - 04:48
Ещё уточню, если можно, какое время сокращается -- время на разработку тестов, на отладку, на сопровождение, на выполнение (прогон в регрессионном режиме)?В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.
По этому поводу готовится статья. Где будет опубликована -- пока не скажу, но как только появится -- сообщу. Тогда мы это дело подробно обсудим.Было бы интересно услышать Ваше мнение.
Собственно именно поэтому мне так интересно предварительно сравнить своё мнение с чужим опытом.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 22 октября 2004 - 05:44
В обход GUI можно работать на разных уровнях. Ну например: в случае веб приложений - можно напрямую отправлять данные форм а можно сразу забивать в базу данных. В первом случае мы фактически уменьшаем время загрузки гуя, во втором - уменьшаем время обработки данных.Ещё уточню, если можно, какое время сокращается -- время на разработку тестов, на отладку, на сопровождение, на выполнение (прогон в регрессионном режиме)?В общем и целом, добавление подобного инструмента позволяет сильно ускорить время тестирования.
Для каждого конкретного приложения будут свои уровни, на каждом из которых можно работать по своему. Спускаясь вниз мы уменьшаем время вода и обрабоки данных, но соответственно и не тестим эту функциональность. (в идеале бы на каждый уровень поставить по watchdog`у и трэйсить весь путь поступивших данных, но это мечты ;) )
Для каждого уровня, соответственно, будут свои временные плюсы и временные минусы. В целом кажется, что можно сильно выиграть на regression тестах. Время на сопровождение, при уже выпущенном продукте, в котором добавляются новые фичи - не должно сильно отличаться от гуйного. Разработка, при правильных инструментах, тоже думаю будет не намного дольше GUI, хотя квалификация тестировщиков для написания подобных вещей должна быть соответствующей.
В любом случае все зависит от уровня обхода гуя.
#13
Отправлено 22 октября 2004 - 05:49
А что вы собственно будете тестить в этом случае? ;)
#14
Отправлено 22 октября 2004 - 06:24
Если совсем прямо в БД -- можно тестить триггеры и встроенные процедуры.>> можно сразу забивать в базу данных
А что вы собственно будете тестить в этом случае? ;)
Если имеется какой-нибудь тонкий слой типа ADO или JDO -- можно проверить, что он реализван правильно.
luden очень верно заметил, что современное ПО "слоистое", поэтому можно выбрать слой и тестировать его вместе со всем, что под ним. Иногда можно даже выбрать несколько слоёв, сделать заглушку снизу и тестировать такой "некомплект".
Какие при этом возникают специфические аспекты?
Во-первых, слоёв много, на тестирование всех подряд никакого времени и сил не хватить. Нужно выбирать.
Во-вторых, квалификация, как тоже верно отметил luden нужна разная для тестирования разных слоёв.
В-третьих, обнаруженные на нижних слоях ошибки могут на более высоких не проявляться, потому что они как-то скрываются или обходятся. Это так называемые латентные ошибки. Считать ли их ошибками или нет? Сейчас они не проявляются, но вдруг в будущем в верхний слой будет внесено изменение и ошибка начнёт проявляться, отловить её будет сложно, потому что причина не в том слое, который меняли.
У нас был опыт тестирования веб-приложения на двух уровнях (сервлеты через HTTP и EJB непосредственно в контейнере), в котором мы обнаружили ряд латентных ошибок на уровне EJB, которые "наверх" не проявлялись. К чести разработчиков, они всё признали и исправили.
Конечно, перечисленные аспекты не исчерпывают список возможных плюсов и минусов. Если кто-то ещё поделится опытом тестирования одного и того же приложения на разных уровнях -- буду очень благодарен!
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#15
Отправлено 22 октября 2004 - 06:38
Это, как правило, большой недостаток документации.
То есть, если функциональную спецификацию еще худо-бедно можно достать, т.к. ее делают не только для разработчиков, но и для других подразделений, то со спецификацией на отдельные уровни - просто беда.
Многие вопросы решаются на уровне Иванов, пишущий JSPшки, договорился с Петровым, пишущим бины, что этот метод будет работать так. Соответственно, какое все-таки поведение метода правильное? Правильно! Именно такое, какое мы и видим.
Т.е. приходится моделировать ситуации, когда поведение метода может вызвать ошибки на самом верхнем уровне. В большинстве случаев это не выгодно и проще тестировать все приложение целиком.
Как вариант - все таки навесить на разработчиков писать спецификацию.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных