ѕоиск
 лиенты

¬водна€ стать€ по тестированию: F.A.Q. новичка

“естирование программного продукта Ч один из важнейших этапов в процессе его разработки. Ќезнание основных терминов и пон€тий может усложнить работу тестировщика. ћы решили собрать самые распространенные вопросы по тестированию ѕќ, чтобы помочь тем, кто только начинает свой путь в профессии или просто интересуетс€ сферой IT. Ќекоторые из них касаютс€ теории тестировани€, другие Ч практики, третьи Ч документации в тестировании.

Ѕлагодарим за помощь в подготовке материала Ђјплана.  орпоративный университетї и в частности его преподавателей: јлександра Ѕеглар€на (ЂЅазовый курс тестировани€ и тест-дизайнаї) и ≈катерину ƒрюпину (курс Ђ–учное функциональное тестированиеї).

„то такое тестирование программного обеспечени€ (ѕќ)?. 1

 акие есть виды тестировани€?. 2

ћожно ли выделить наиболее востребованные виды тестировани€?. 3

≈сть ли какие-то базовые принципы тестировани€?. 3

 ак пон€ть, когда нужно начинать тестирование?. 4

„то такое баги?. 4

 акие инструменты инженер по тестированию обычно использует в своей работе?. 4

 ак можно оценить качество ѕќ?. 4

„то такое тест-план и что в нем должно быть написано?. 5

„то такое тест-дизайн и зачем он нужен?. 5

„то €вл€етс€ результатом работы инженера по тестированию?. 5

≈сть ли какие-то книги, которые могут быть полезны новичку в тестировании?. 5

 

„то такое тестирование программного обеспечени€ (ѕќ)?

—огласно Ђ–уководству к своду знаний по программной инженерииї (IEEE, SWEBOK, 2004), тестирование Ч это проверка соответстви€ между реальным и ожидаемым поведением программы, осуществл€ема€ на конечном наборе тестов, выбранном определенным образом.

—огласно Ђ—тандартному глоссарию терминов, используемых в тестировании программного обеспечени€ї (ISTQB), тестирование Ч это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиес€ планировани€, подготовки и оценки программного продукта и св€занных с этим результатов работ с целью определить, что они соответствуют описанным требовани€м, показать, что они подход€т дл€ за€вленных целей и определени€ дефектов.

¬ разных источниках, скажем, в книгах, стать€х, можно встретить большое количество определений пон€ти€ Ђтестированиеї. –азные специалисты пытались объ€снить его как можно точнее, придумыва€ все новые и новые формулировки. Ќапример, одна из самых простых: тестирование Ч это сравнение фактического результата с ожидаемым. ј еще Ч одна из техник контрол€ качества, включающа€ планирование работ (Test Management), проектирование тестов (Test Design), выполнение тестировани€ (Test Execution) и анализ полученных результатов (Test Analysis). Ёто исследование программы с целью обнаружени€ ошибок; возможный способ оценки качества программного обеспечени€ в терминах найденных дефектов, исполненных тестов и протестированных систем и т.д.

 акие есть виды тестировани€?

¬се виды тестировани€ программного обеспечени€, в зависимости от преследуемых целей, можно условно разделить на следующие группы:

  1. ‘ункциональные,
  2. Ќефункциональные,
  3. —в€занные с изменени€ми.

“естирование можно классифицироватьЕ

ѕо критерию запуска программы:

  • —татическое;
  • ƒинамическое.

ѕо объекту тестировани€:

ѕо уровн€м:

ѕо степени автоматизации:

ѕо времени проведени€ тестировани€:

ѕо степени подготовленности:

  • “естирование по документации;
  • »сследовательское тестирование;
  • »нтуитивное тестирование (ad hoc testing*).

ѕо признаку позитивности сценариев:

  • ѕозитивное тестирование;
  • Ќегативное тестирование*.

ѕо знанию системы:


ѕримечание: 

  • ќтказоустойчивость Ч реакци€ системы на нестандартные, непредвиденные ситуации.
  • Ad hoc Ч сложна€ активность, которую может выполнить только опытный тестировщик.
  • Ќегативное тестирование Ч обработка системой ситуаций, которые не заложены разработчиком в программный продукт.
  • “естирование Ђчерного €щикаї (black box) Ч проведение функционального тестировани€ без доступа к коду системы.
  • “естирование Ђбелого €щикаї (white box) Ч функциональное тестирование с доступом к коду системы.
  • “естирование Ђсерого €щикаї (gray box) Ч расширенный тип black-box тестировани€, включающий изучение кода. 

 

≈сть еще более сложные и полные классификации.   примеру, вот такой вариант использует один из преподавателей Ђјплана.  орпоративный университетї на своем курсе:

ћожно ли выделить наиболее востребованные виды тестировани€?

ќпыт показывает, что наиболее востребованы ручное функциональное тестирование, автоматизированное функциональное тестирование и нагрузочное тестирование.

–учное функциональное тестирование (–‘“) Ч это тестирование вручную, то есть без использовани€ каких-либо автоматизированных средств. ¬ этом случае инженер по тестированию берет на себ€ роль конечного пользовател€ и, в соответствии с тестовым сценарием, провер€ет ѕќ или систему. ≈го задача Ч вы€вить поведение, отличное от ожидаемого конечным пользователем.

–учное тестирование примен€етс€ в регрессионном (тестирование изменений), интеграционном (св€зь с другими системами) и при тестировании нового функционала.

јвтоматизированное функциональное тестирование (ј‘“) Ч процесс верификации программного обеспечени€, при котором основные функции и шаги теста выполн€ютс€ автоматически при помощи инструментов дл€ автоматизированного тестировани€. ƒл€ этого сначала разрабатывают ручные тесты, затем их автоматизируют Ч тесты выполн€ютс€ программой-роботом, без привлечени€ ручных тестировщиков. ј‘“ может €вл€тьс€ частью регрессионного тестировани€ и входить в комплексное.

Ќагрузочное тестирование (Ќ“) позвол€ет определить, как и с какой скоростью программа работает под определенной нагрузкой. Ќагрузочное тестирование рекомендуетс€ проводить при выпуске нового программного обеспечени€, доработке эксплуатируемого ѕќ и при изменении конфигурации стендов.

≈сть ли какие-то базовые принципы тестировани€?

¬от семь основных из них:

  1. “естирование демонстрирует наличие дефектов. ќно может показать, что дефекты есть, но не может доказать, что их нет. “естирование снижает веро€тность наличи€ дефектов, наход€щихс€ в ѕќ, но, даже если они не были обнаружены, это не доказывает корректность тестировани€.
  2. »счерпывающее тестирование невозможно. ѕолное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. ¬место исчерпывающего тестировани€ должны использоватьс€ анализ рисков и расстановка приоритетов, чтобы правильнее распределить усили€.
  3. –анее тестирование. „тобы как можно раньше найти дефекты, нужно как можно раньше начать активности по тестированию в жизненном цикле разработки ѕќ или системы.  роме того, они должны быть сфокусированы на определенных цел€х.
  4. —копление дефектов. ”сили€ тестировани€ должны быть сосредоточены пропорционально ожидаемой, а позже и реальной плотности дефектов по модул€м. Ѕольша€ часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержитс€ в небольшом количестве модулей.
  5. ѕарадокс пестицида. ≈сли одни и те же тесты будут прогон€тьс€ много раз, в конечном счете этот набор тестовых сценариев перестанет находить новые дефекты. „тобы преодолеть Ђпарадокс пестицидаї, тестовые сценарии должны регул€рно рецензироватьс€ и корректироватьс€, новые тесты должны быть разносторонними, чтобы охватить все компоненты ѕќ или системы, и найти как можно больше дефектов.
  6. “естирование зависит от контекста. “естирование выполн€етс€ по-разному, в зависимости от контекста. ƒопустим, ѕќ, в котором критически важна безопасность, тестируетс€ не так, как сайт электронной коммерции.
  7. ќтсутствие ошибок не означает, что система готова к использованию. ќбнаружение и исправление дефектов не помогут, если созданна€ система не подходит пользователю и не удовлетвор€ет его ожидани€м и потребност€м.

 ак пон€ть, когда нужно начинать тестирование?

„ем раньше обнаружен дефект, тем дешевле обходитс€ его исправление, поэтому начинать тестирование нужно как можно раньше. Ќапример, статическое тестирование (до фактического получени€ ѕќ) делает проще динамическую стадию. Ќа ранних стади€х проще изменить тест-дизайн и т.д.

„то такое баги?

Ѕаг (bug) или дефект Ч это отклонение фактического результата от ожидаемого, изъ€н в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Ѕаги наход€т на этапе тестировани€, затем нужна отладка (дебаггинг), которую выполн€ет разработчик. ќтладка (debugging) Ч процесс поиска, анализа и устранени€ причин отказов в программном обеспечении. ѕосле отладки исправление требует новой проверки тестировщиком.

 акие инструменты инженер по тестированию обычно использует в своей работе?

“естировщик самосто€тельно определ€ет скорость работы, при которой он наиболее внимателен и эффективен.  ак специалист, он должен уметь проводить ревизию своих активностей дл€ вы€влени€ возможности ускорени€ действий.

Ѕазовые инструменты тестировщика:

  • “екстовый редактор дл€ поиска, конвертации и сравнени€ файлов (Notepad++, PSPad и др.),
  • Xml-редактор (Altova XML Spy (работа с xml и xsd), XMLPad и др.),
  • »нструмент дл€ работы со снимками экранов (Snipping Tool, Snagit, GreenShoot, ScreenHunter и др.),
  • »нструмент дл€ записи видео с содержимым экрана (CamStudio, Ashampoo Snap, Free Screen Video Recorder и др.),
  • »нструмент дл€ сравнени€ графических файлов (ImageDiscerner, FastStone Image Viewer, ImageDupeless, Graf2 Free rus),
  • ‘айловый менеджер (Total Commander, Far Manager, TrolCommander, Free Commander),
  • ѕланировщик задач (MS Outlook, Redmine и др.).

 ак можно оценить качество ѕќ? 

ќценка программного обеспечени€ производитс€ согласно международному стандарту ISO 9126. ѕќ будет качественным, если можно обеспечить его функциональность, надежность, удобство использовани€, удобство сопровождени€, производительность и переносимость. „ем больше атрибутов качества можно реализовать или поддержать (дл€ производительности Ч это соответствие стандартам, временна€ эффективность и эффективность использовани€ ресурсов и т.д.), тем выше будет качество ѕќ. ” атрибутов есть и численные показатели Ч метрики, которые позвол€ют измер€ть прогресс в достижении качества.

„то такое тест-план и что в нем должно быть написано?

“ест-план Ч это документ, описывающий весь объем работ по тестированию, начина€ с описани€ объекта, стратегии, расписани€, критериев начала и окончани€ тестировани€, до необходимого в процессе работы оборудовани€, специальных знаний, а также оценки рисков с вариантами их разрешени€.

 ак и в случае с тестированием, в профессиональной литературе можно встретить и другие определени€ тест-плана. ќдно из самых коротких: тест-план Ч это документ, обобщающий и координирующий тестирование. ј одно из самых длинных: тест-план Ч это документ, описывающий масштаб, подход, ресурсы и график тестировани€, в котором определены тестовые элементы, отдельные части функционала, тестовые задани€, специалисты, которые будут проводить конкретные тесты, и любые риски, требующие дополнительного планировани€.

ќсновные разделы тест-плана:

  • Ќазначение,
  • ќбъект тестировани€,
  • “естова€ стратеги€,
  • ѕримен€емые виды тестировани€,
  • ”слови€ проведени€ тестировани€,
  •  ритерии начала и завершени€ тестировани€,
  • ѕлан-график проведени€ тестировани€,
  • –есурсы, необходимые дл€ выполнени€ тестировани€,
  • ¬озможные риски.

„то такое тест-дизайн и зачем он нужен?

“ест-дизайн Ч одна из наиболее творческих де€тельностей в IT. Ёто этап процесса тестировани€ ѕќ, на котором, в соответствии с определенными ранее критери€ми качества и цел€ми тестировани€, проектируютс€ и создаютс€ тестовые случаи (тест-кейсы).

«адачи тест-дизайна:

  • ќптимизаци€ поиска критичных ошибок (с целью раннего их обнаружени€),
  • ћониторинг процесса тестировани€ и качества продукта,
  • ‘ормализованные и пон€тные последовательности действий, подход€щие дл€ начинающих инженеров по тестированию,
  • ”меньшение нагрузки на тестировщиков.

„то €вл€етс€ результатом работы инженера по тестированию?

ƒл€ большинства тестировщиков основной продукт работы Ч отчет о проделанных испытани€х в разрезе общего количества пройденных тестовых сценариев с их результатами, а также список открытых дефектов с указанием их критичности.

≈сть ли какие-то книги, которые могут быть полезны новичку в тестировании?

–екомендуем к прочтению следующие книги:

  • Ђ раткие основы тестировани€ программного обеспечени€ї, ј.  оробейник;
  • Ђ“естирование программного обеспечени€. Ѕазовый курсї, —. уликов;
  • Ђ“естирование дот комї, –. —авин;
  • Ђ“естирование программного обеспечени€. ‘ундаментальные концепции менеджмента бизнес-приложенийї, —.  аннер, ƒ. ‘олк, ≈.  . Ќгуен;
  • Ђ лючевые процессы тестировани€. ѕланирование, подготовка, проведение, совершенствованиеї, –. Ѕлэк;
  • Ђјвтоматизированное тестирование программного обеспечени€ї, Ё. ƒастин, ƒ. –эшка, ƒ. ѕол;
  • Ђ ак тестируют в Googleї, ƒ. ”иттакер, ƒ. јрбон.