Ну вот ваш пример , это по сути то как я изначально и понимал себе компонентное тестирование (не задумываясь о случае когда модуль=компонент). Для меня (как и для вас) компонент это отдельный сервис в микросервисной архитектуре, и если мы тестируем его изолированно,то это по определению не может быть интеграционным тестированием , получается это компонентное.
Получается,что все это разделение субъективно и просто зависит от разбиения и абстракции, и больше всего размытости как раз на нижнем уровне. Недавно например мне высказали мнение,что ui тесты в определенном контексте тоже интеграционные - когда мы тестируем функционал ,который взаимодействует с сервером , форму например. Хотя вроде как , когда мы приступаем к ui это уже полноценное приложение (все его части собраны в единое) и тестирование системное.
В общем зависит от контекста и на собесах нужно не выпаливать определение,а рассуждать )
Здравствуйте, прочитал ваш материал, очень интересно. Понравилось пояснение - "компонентный тест - это частный случай интеграционного тестирования группы модулей". Исходя из вашего определения, что компонент состоит из модуля и является точкой входа, правильно ли я понимаю и описываю пример с методом-компонентом и методами-модулями?
А, я понял вашу мысль. Но,опять же повторюсь, что это больше визуальный прием для статьи. Я не использовал вдумчивый тест дизайн. Это статья не про цели тест дизайна ,а про последовательность действий и про то что пейрвайс может помочь в каких то случаях. Попарное тестирование,это далеко не панацея, и конечно неправильно рассматривать его как решение для всего этапа тестдизайна. Но вполне можно рассмотреть,как отдельную технику ,опуская все остальное.
Мы не рассуждаем о сокращении числа тестов впринципе, мы рассуждаем об инструменте для потенциального сокращения. Вы говорите о "сравнении числа тестов при хорошем подходе" ,но при хорошем подходе к чему? Если к применению конкретной технике попарного тестирования ,то ок,но если к этапу тест дизайна, то конечно же это не "хороший подход". Он скорее неправильный в реальной работе: как вы правильно заметили, нельзя на отвали применить одни техники и применив пейрвайс ,сказать что сократили кучу тестов, в реальной работе мы анализируем , фиксируем зависимые и независимые параметры , оцениваем какие-то риски , применяя весь набор техник тест дизайна комплексно и вдумчиво для соответствующих наборов данных, в конечном "идеальном" итоге получая минимальный набор тестов без потери эффективности тестового покрытия.
Я пишу сейчас это всё не конкретно для вас (не уверен что смогу тягаться с вами в продвинутом тест дизайне), а чтобы пояснить читающим на что стоит обратить внимание при чтении статьи.
Но очень часто начинающие специалисты изучают техники тест дизайна , только чтобы бодро ответить на собеседовании ,а в реальной работе используют только классы эквивалентности и граничный анализ ,только потомучто "так написано в книжке". Ограничивая себя из-за ,как правило, простых примеров применения этих техник в обучающих источниках и начинают испытывать проблемы при появлении ,к примеру, неупорядоченных данных.
Поэтому чем раньше Джун расширит свой взгляд на анализ тестируемого приложения,тем качественнее будет результат его работы.
Безусловно, при реальном тестировании, мы должны изначально опираться на бизнес логику. А вторая ошибка, что я сразу выкинул особые значения 100 и 200, это как раз следствие того, что бизнес логику я навешал уже после.
Но, в первом случае, задача была показать, на сколько изначально велико кол-во кейсов, и лишь потом приступать к их сокращению. Тут больше визуальный прием, чем реальная практика - я думал, всем понятно что мы никогда не будем так делать в реальности.
А вот особые значения страниц я упустил..это да. Но опять же, задача была показать саму необходимость применить классы эквивалентности на данном этапе.
Информация
В рейтинге
Не участвует
Откуда
Томск, Томская обл., Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Инженер по автоматизации тестирования, Инженер по ручному тестированию
Ну вот ваш пример , это по сути то как я изначально и понимал себе компонентное тестирование (не задумываясь о случае когда модуль=компонент). Для меня (как и для вас) компонент это отдельный сервис в микросервисной архитектуре, и если мы тестируем его изолированно,то это по определению не может быть интеграционным тестированием , получается это компонентное.
Получается,что все это разделение субъективно и просто зависит от разбиения и абстракции, и больше всего размытости как раз на нижнем уровне. Недавно например мне высказали мнение,что ui тесты в определенном контексте тоже интеграционные - когда мы тестируем функционал ,который взаимодействует с сервером , форму например. Хотя вроде как , когда мы приступаем к ui это уже полноценное приложение (все его части собраны в единое) и тестирование системное.
В общем зависит от контекста и на собесах нужно не выпаливать определение,а рассуждать )
Здравствуйте, прочитал ваш материал, очень интересно. Понравилось пояснение - "компонентный тест - это частный случай интеграционного тестирования группы модулей". Исходя из вашего определения, что компонент состоит из модуля и является точкой входа, правильно ли я понимаю и описываю пример с методом-компонентом и методами-модулями?
А, я понял вашу мысль. Но,опять же повторюсь, что это больше визуальный прием для статьи. Я не использовал вдумчивый тест дизайн. Это статья не про цели тест дизайна ,а про последовательность действий и про то что пейрвайс может помочь в каких то случаях. Попарное тестирование,это далеко не панацея, и конечно неправильно рассматривать его как решение для всего этапа тестдизайна. Но вполне можно рассмотреть,как отдельную технику ,опуская все остальное.
Мы не рассуждаем о сокращении числа тестов впринципе, мы рассуждаем об инструменте для потенциального сокращения. Вы говорите о "сравнении числа тестов при хорошем подходе" ,но при хорошем подходе к чему? Если к применению конкретной технике попарного тестирования ,то ок,но если к этапу тест дизайна, то конечно же это не "хороший подход". Он скорее неправильный в реальной работе: как вы правильно заметили, нельзя на отвали применить одни техники и применив пейрвайс ,сказать что сократили кучу тестов, в реальной работе мы анализируем , фиксируем зависимые и независимые параметры , оцениваем какие-то риски , применяя весь набор техник тест дизайна комплексно и вдумчиво для соответствующих наборов данных, в конечном "идеальном" итоге получая минимальный набор тестов без потери эффективности тестового покрытия.
Я пишу сейчас это всё не конкретно для вас (не уверен что смогу тягаться с вами в продвинутом тест дизайне), а чтобы пояснить читающим на что стоит обратить внимание при чтении статьи.
Это здорово,что вы понимаете цель тест дизайна.
Но очень часто начинающие специалисты изучают техники тест дизайна , только чтобы бодро ответить на собеседовании ,а в реальной работе используют только классы эквивалентности и граничный анализ ,только потомучто "так написано в книжке". Ограничивая себя из-за ,как правило, простых примеров применения этих техник в обучающих источниках и начинают испытывать проблемы при появлении ,к примеру, неупорядоченных данных.
Поэтому чем раньше Джун расширит свой взгляд на анализ тестируемого приложения,тем качественнее будет результат его работы.
Приятно читать подобные комментарии. Даже если вы единственный, кому это показалось полезным, значит я не зря потратил время ))
Полностью с вами согласен по обоим пунктам.
Безусловно, при реальном тестировании, мы должны изначально опираться на бизнес логику. А вторая ошибка, что я сразу выкинул особые значения 100 и 200, это как раз следствие того, что бизнес логику я навешал уже после.
Но, в первом случае, задача была показать, на сколько изначально велико кол-во кейсов, и лишь потом приступать к их сокращению. Тут больше визуальный прием, чем реальная практика - я думал, всем понятно что мы никогда не будем так делать в реальности.
А вот особые значения страниц я упустил..это да. Но опять же, задача была показать саму необходимость применить классы эквивалентности на данном этапе.