Тест-дизайн для системного и интеграционного тестирования

Все, что касается проектирования тестов...

Модератор: YuriY

Тест-дизайн для системного и интеграционного тестирования

Сообщение YuriY » 26 авг 2008, 09:40

Предисловие
Материал из Википедии — свободной энциклопедии:
Систе́мное тести́рование програ́ммного обеспече́ния — это тестирование программного обеспечения (ПО), выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.
Интеграцио́нное тести́рование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) — одна из фаз тестирования программного обеспечения, при котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

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

А вопросы у меня такие:
- кто-нибудь сталкивался или реализовывал такой подход (разработка отдельных комплектов тестов для системного и интеграционного тестирования)? Может, на самом деле, все так и делают, но лично я еще не встречал такого четкого разграничения задач по тест-дизайну, да и по выполнению тестирования... Могу только предположить, что роль интеграционного тестирования, описываемого Блэком, у нас обычно выполняет smoke- или sanity (поверхностное) тестирование.
- кто-нибудь делает четкое разделение в своей работе этих фаз? Если да, то как? Вообще я столкнулся с тем, что на практике, при рассмотрении конкретных тестируемых приложений, гораздо сложнее разграничить "зоны ответственности" этих фаз тестирования, хотя, когда читаешь определения, все звучит четко и ясно...
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение wishaway » 26 сен 2008, 11:36

Согласен, на практике тяжело разграничить, и в основном используется либо smoke, либо sanity в зависимости от количества и влияния изменений/дополнений.

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

Для новичков (в качестве расширения знаний) уточню: Smoke и Sanity в корне отличаются друг от друга, хотя и похожи по общим признакам.

Кому интересно - здесь
http://www.softwaretestinghelp.com/smok ... ifference/

Там много и другой полезной инфы.
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение YuriY » 24 янв 2009, 19:00

wishaway писал(а):Для новичков (в качестве расширения знаний) уточню: Smoke и Sanity в корне отличаются друг от друга, хотя и похожи по общим признакам.

Кому интересно - здесь
http://www.softwaretestinghelp.com/smok ... ifference/

Не прошло и полгода... Решил написать чуть.
Вчера на встрече клуба упоминался глоссарий ISTQB.
Сегодня я его нашел и решил вдруг взглянуть на определения Sanity и Smoke тестов. Оказалось, что по версии Рекса Блэка и сотоварищей это практически одно и то же.

Потом полез в википедию, а она - туда же клонит:
http://en.wikipedia.org/wiki/Sanity_testing

Это я не к тому, что давайте-ка устроим глупый спор да с мордобитием...))
А только лишь к тому, что в нашем мире все по-прежнему неоднозначно... Поэтому будьте аккуратны при использовании, в частности, этих терминов, особенно, если ведете дискуссию с коллегой из другой конторы. Сначала уточните определения понятий, а потом уже говорите, так сказать, на одном языке).
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение wishaway » 26 янв 2009, 12:21

Ну, википедия меня вообще посмешила, если честно :)

Smoke: "возможно ли производить тестирование" (доступна ли страница, есть ли отклик от нажатия на кнопку и т.п.)
Sanity: "имеет ли смысл производить тестирование" (запуск минимальных тестов, чтобы понять, работают ли базовые функции приложения)

То, что я всегда называл smoke - здесь называют Sanity.
А вот Smoke здесь определяют как проверку возможности проводить "Sanity" тестирование.

По сути взяли классический Smoke и разложили его еще на 2 более мелких вида тестов. Притом назвали один из них Sanity, чем внесли еще больше сумбурности в и так не простой Glossary по терминам тестирования.

ИМХО, в топку эту статью на википедии...
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Re: Тест-дизайн для системного и интеграционного тестировани

Сообщение pl » 21 ноя 2009, 05:29

Как я понимаю, описанная Блэком ситуация может иметь место при итерационной разработке - не при водопаде.
Почему же? При водопаде интеграционное проводится по мере готовности модулей к интеграции. Пока еще система полностью не собрана - используются драйверы и заглушки.

- кто-нибудь сталкивался или реализовывал такой подход (разработка отдельных комплектов тестов для системного и интеграционного тестирования)?
Да, у нас Integration и System создаются раздельно, причем, разными группами людей.

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

Относительно "как" - трудностей не возникает если требования к интерфейсам у вас вынесены в отдельный раздел SRS. Эти требования проверяются при интеграционном тестировании, а общие функциональные - при системном.

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

Если ваш проект относительно небольшой и не критичный с точки зрения качества, думаю, лучше не усложнять себе жизнь.
pl
Newcomer
 
Сообщений: 3
Зарегистрирован: 21 ноя 2009, 04:39

Сообщение pl » 21 ноя 2009, 05:58

Smoke: "возможно ли производить тестирование" (доступна ли страница, есть ли отклик от нажатия на кнопку и т.п.)
Sanity: "имеет ли смысл производить тестирование" (запуск минимальных тестов, чтобы понять, работают ли базовые функции приложения)


Да, в таком изложении - разница несущественная. Просто - Dry Run ;)

Хотя, я не вижу смысла и в выделении Sanity как узконаправленной регрессии. В таком случае, понадобится еще термин для разности между общей регрессией и Sanity.
pl
Newcomer
 
Сообщений: 3
Зарегистрирован: 21 ноя 2009, 04:39


Вернуться в Проектирование тестов | Test Design

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3

cron