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

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

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

С чего же начинать организацию процесса тестирования?

Я выделяю 11 основных критериев в организации процесса тестирования:

1. Цели и область тестирования
2. Команда
3. Управление
4. Коммуникация и взаимодействие
5. Методология тестирования
6. Документированность процесса
7. Управление рисками
8. Измерение процесса
9. Инструменты
10. Тестовые среды
11. Совершенствование процесса

Именно выполнение всех этих критериев позволяет равномерно развивать процесс тестирования, что в короткие сроки позволяет достигать того уровня, когда процесс тестирования будет приносить положительные результаты.

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

• Зачем нам нужно тестирование?
• Что мы имеем, чтобы сделать тестирование?
• Какие процессы нужно формализовать или создать?
• Как и что мы должны тестировать?

Только после того, как мы получим ответы на эти вопросы, можно начинать переходить к стандартам.

Я выделяю следующие стандарты, которые действительно нужно изучить перед тем, как начинать строить процесс:

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

Естественно, использование полностью практик, изложенных в стандартах нельзя. Любой стандарт должен быть кастомизирован под потребности именно вашего процесса тестирования, потому что необдуманное внедрение практик стандартов может привести к неблагоприятным последствиям, потому что ваш процесс тестирования не будет выполнять требований бизнеса.

Любой ИТ процесс всегда должен удовлетворять потребностям бизнеса!

Мы разберем основные критерии построения процесса тестирования.

Цели и область тестирования

Целью тестирования является обнаружение дефектов, проверка соответствия ПО заявленным требованиям, а также предоставление обратной связи о дефектах всем заинтересованным сторонам.

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

Говоря об области тестирования, мы должны прекрасно понимать, что именно нам предстоит тестировать. Это могут быть системы, компоненты, бизнес процессы. Для того, чтобы это понять, то нужно просто ответить на два вопроса:

• Что надо тестировать?
• Что будем тестировать?

Зачастую, то что надо тестировать и то что будем может сильно различаться. Это зависит от возможностей вашего процесса тестирования. «Что надо» часто диктуется бизнесом и руководством, поэтому хороший руководитель должен всегда понимать, «что нужно» тестировать. Как говорится в поговорке: «За двумя зайцами погонишься, ни одного не поймаешь», так и тут. Всегда лучше качественно тестировать то, что действительно вы можете тестировать вашей командой, чем хвататься за все, что просит бизнес и ничего не успевать в срок, да еще и пропускать критичные дефекты.

Команда и управление

Команда — это самая важная составляющая процесса тестирования. Без команды вы, как руководитель, ничего не сделаете. Зачастую к формированию команды подходят несколькими подходами:

Инструменты и инфраструктура

Какой же процесс тестирования без инструментов? Это получается ручной труд ради ручного труда 🙂 Я думаю многие из вас часто слышали о написании тест-кейсов в документах ворд, о построения графиков и диаграмм в экселе. Но, зачем тратить усилия, если рынок предлагает нам готовые продукты управления тестирования, такие как HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr и многие другие.
Поэтому, если вы приступили к организации процесса тестирования, то делайте этот процесс удобным и эффективным. Пишите тест-кейсы в удобных формах готовых продуктов, интегрируйте инструменты с системой управления задачами, настраивайте и т.д.

Подходя к выбору инструмента нужно всегда понимать:

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

Получив ответы на эти вопросы вы сможете определить наиболее удобные для вас инструменты тестирования, а возможно и разработать собственные.

Помимо инструментов управления тестирования, к инструментам тестирования также можно отнести:

• Система управления дефектами и задачами (может включаться в систему управления тестированием)
• Вспомогательные инструменты (для скриншотов, снятия логов, работы с БД, SOUP UI для XML и т.д.)
• Инструменты автоматизации ( , Selenium и т.д.)
• Системы управления знаниями (на wiki движке)

Теперь поговорим об инфраструктуре. В текущем контексте своего повествования я подразумеваю тестовые среды.

Практически в любой организации, особенно если организация крупная и не разрабатывает мобильные приложения для плеймаркета, вам потребуется тестовая (ые) среда (ы) для тестирования. Мощности и объемы интеграции систем в тестовых средах могут быть различными в зависимости от объемов тестирования.

Стандартно я выделяю следующие типы тестовых сред:

• Среда разработки (можно ли ее относить к тестовой?, но тем не менее)
• Среда тестирования системы (может быть развернута одна или несколько систем, компонент, не требует серьезных мощностей)
• Среда интеграции (полноценный интеграционная среда для проверки работоспособности сквозных бизнес процессов)
• Среда (основное требования — соответствие мощностями боевому контуру)
• Среда ПродЛайк/ПреПрод (среда для отладки готового протестированного билда, проведение инсталяционного тестирования)

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

Совершенствование процесса

Я очень часто говорю такую фразу, что «Любой процесс, неважно какой, всегда должен постоянно совершенствоваться», на что очень часто слышу «Зачем, наш процесс и так хорошо работает».

Но это не так. Почему мы должны постоянно совершенствовать процесс тестирования:

1. Цели тестирования не могут быть одинаковыми, они постоянно меняются в зависимости от потребностей бизнеса, что диктуется рынком.

2. ИТ сфера постоянно развивается. Приходят новые технологи подходы, которые всегда позволяются совершенствовать процесс тестирования.

Как говорится, совершенству нет предела!

Ну а как совершенствовать — это стандартный цикл Демминга.

Запланировали — .Сделали — Проанализировали — Скорректировали

Ну и в заключение скажу, что правильная позволяет в кротчайшие сроки создать действительно эффективный процесс тестирования, решающий поставленные ему цели и задачи.

Введение

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

Такой процесс формальной проверки, или верификации , может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов - это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

Также к статическому тестированию относят тестирование требований , спецификаций , документации .

Регрессионное тестирование

После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования .

Тестовые скрипты

Тестировщики используют тестовые скрипты на разных уровнях: как в модульном, так и в интеграционном и системном тестировании. Тестовые скрипты, как правило, пишутся для проверки компонентов, в которых наиболее высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования, фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании чёрного ящика , тестировщик имеет доступ к ПО только через те же интерфейсы , что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).

Покрытие кода

Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

Цитаты

• «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» - Дейкстра , 1970 г.

См. также

• Обратная семантическая трассировка - универсальный метод тестирования любого проектного артефакта

Примечания

Литература

• Гленфорд Майерс, Том Баджетт, Кори Сандлер Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. - М .: «Диалектика», 2012. - 272 с. - ISBN 978-5-8459-1796-6
• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. - М .: «Вильямс», 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 экз. - ISBN 978-5-8459-1625-9
• Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. - Киев: ДиаСофт, 2001. - 544 с. - ISBN 9667393879
• Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. - М .: «Вильямс», 2002. - 374 с. - ISBN 5-8459-0336-X
• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. - М .: БИНОМ, 2008. - 368 с. - ISBN 978-5-94774-825-3
• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. - СПб. : Питер, 2004. - 320 с. - ISBN 5-94723-698-2

Ссылки

• Портал специалистов по тестированию и обеспечению качества ПО (рус.)
• Портал об автоматизированном тестировании ПО (рус.)
• Качество программного обеспечения (рус.)

— процесс выявления ошибок в программном обеспечении (ПО). Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования анализируемой программы особенно в закрытых частных программах. Поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.

Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

Тестирование ПО — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем.

Для наглядности: почти все производители коммерческого ПО исправляют ошибки в своих продуктах.

Например: Корпорация Microsoft выпускает пакеты обновлений («Service Pack»), для своих операционных систем. Разработчики игр регулярно выпускают «патчи» для своих продуктов. Большинство разработчиков ПО после устранения ошибок выпускают обновлённую (новую) версию своей программы.

Тестирование программного обеспечения

Существует несколько признаков по которым принято производить классификацию видов тестирования. Обычно выделяют следующие признаки:

По объекту тестирования:

• Функциональное тестирование (functional testing)
• Нагрузочное тестирование
  • Тестирование производительности (perfomance/stress testing)
  • Тестирование стабильности (stability/load testing)
• Тестирование удобства использования (usability testing)
• Тестирование интерфейса пользователя (UI testing)
• Тестирование безопасности (security testing)
• Тестирование локализации (localization testing)
• Тестирование совместимости (compatibility testing)

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

• Тестирование чёрного ящика (black box)
• Тестирование белого ящика (white box)
• Тестирование серого ящика (gray box)

По степени автоматизированности:

• Ручное тестирование (manual testing)
• Автоматизированное тестирование (automated testing)
• Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

• Компонентное (модульное) тестирование (component/unit testing)
• Интеграционное тестирование (integration testing)
• Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

• Альфа тестирование (alpha testing)
  • Тестирование при приёмке (smoke testing)
  • Тестирование новых функциональностей (new feature testing)
  • Регрессионное тестирование (regression testing)
  • Тестирование при сдаче (acceptance testing)
• Бета тестирование (beta testing)

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

• Позитивное тестирование (positive testing)
• Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

• Тестирование по документации (formal testing)
• Эд Хок (интуитивное) тестирование (ad hoc testing)

Уровни тестирования

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
  • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.
  • Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

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

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing , также говорят — прозрачного ящика ), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing ), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

При тестировании чёрного ящика, тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).

Статическое и динамическое тестирование

Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование .

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Регрессионное тестирование

После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.

Тестовые скрипты

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

Покрытие кода

Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

Разработка через тестирование (test-driven development)

(англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.

Ни один программист не считает работу над некоторым фрагментом кода завершенной, не проверив перед этим его работоспособность. Однако, если вы тестируете свой код, это не означает, что у вас есть тесты.

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

Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.

«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:

У разработчика появляется шанс усвоить уроки, которые преподносит ему код. Если он воспользуется первой же идеей, которая пришла ему в голову, у него не будет шанса реализовать вторую, лучшую идею.

Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них.

Разработчику приятнее писать такой код.

Однако как мы можем получить чистый код, который работает? Очень многие силы мешают нам добиться этого, а иногда нам не удается получить даже код, который работает. Чтобы избавиться от множества проблем, мы будем разрабатывать код, исходя из автоматических тестов. Такой стиль программирования называется разработкой через тестирование. В рамках этой методики мы:

Пишем новый код только тогда, когда автоматический код не сработал.

Удаляем дублирование.

Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

Проектируя код, мы постоянно запускаем его и получаем представление о том, как он работает, это помогает нам принимать правильные решения.

Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас.

Наша среда разработки должна быстро реагировать на небольшие модификации кода.

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

Два упомянутых правила TDD определяют порядок этапов программирования:

Красный - напишите небольшой тест, который не работает, а возможно, даже не компилируется.

Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

Рефакторинг - удалите из написанного вами кода любое дублирование.

Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

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

Определенно существуют задачи, которые невозможно(по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность основана на коде, в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.

Терминология, связанная с модульными тестами

• Разработка через тестирование - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

• Модульные тесты - Unit Tests, Programming Tests, Developer Tests - тесты, проверяющие функциональность отдельных классов, компонентов, модулей приложения. Эти тесты не видны конечному заказчику или доменному эксперту. Обычно их начинают писать после оформления функциональных тестов.

• Зеленая/Красная полоса - многие графические среды для выполнения модульных тестов отображают результат выполнения тестов в виде линии, которая окрашена в зеленый цвет, если все тесты выполнились удачно, и красной, если были ошибки.

• Моки, Мок-объекты (MockObjects) - автоматически генерируемые заглушки, которые могу выступат в роли реальных объектов. Поведением моков можно управлять непосредственно в тесте. Моки могут выполнять дополнительные проверки, что тестируемый код их использовал, как ожидалось.

• Модульный тест - тест, который проверяет поведение небольшой части приложения. Эта часть может быть одним классом, одним методом или набором классов, который реализуют какое-то архитектурное решение, и это решение необходимо проверить на работоспособность.

• Тест - TestCase - набор тестовых методов, предназначенных для тестирования одного класса (в среде xUnit). Обычно TestCase состоит из методов, чье имя начинается с приставки test. Каждый такой метод тестирует какой-либо один момент тестируемого класса. В приемочном тестировании TestCase - это набор команд, которые тестируют одну значимую для заказчика функциональность.

• Фикстура - Fixture - состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Это может быть набор каких-либо объектов, состояние базы данных, наличие определенных файлов и т.д. Фикстура создается в методе setUp() перед каждым вызовом метода вида testSomething теста (TestCase) и удаляется в tearDown() после окончания выполнения тестового метода.

• Проверка - Assert - метод класса TestCase, который предназначен для сверки реального состояния тестируемого кода с ожидаемым.

Терминология, связанная с наборами тестов

• Набор тестов - TestSuite - набор тестов, предназначенный для тестирования какой-либо укрупненной сущности программной системы. В SimpleTest есть понятие TestGroup, которые практически эквивалентно понятию TestSuite. Иногда TestSuite употребляют в значении «все тесты, которые есть для приложения».

Терминология, связанная с приемочными тестами

• Приемочные (функциональные) тесты - Customer tests, Acceptance tests - тесты, проверяющие функциональность приложения на соответствие требованиям заказчика. Приемочные тесты не должны ничего знать о деталях реализации приложения. Приемочные тесты заменяют ТЗ при использовании методики экстремального программирования (XP).

• Регрессионный тесты - тесты, которые проверяют, что поведение системы не изменилось. На самом деле, большинство регрессионных тестов являются или модульными или функциональными тестами, которые включаются в определенный набор тестов (RegressionTestSuite), который гарантирует, что функциональность системы не будет случайно изменена.

Тестирование – это исследовательский метод, который позволяет выявить уровень знаний, умений и навыков, способностей и других качеств личности, а также их соответствие определенным нормам путем анализа способов выполнения испытуемым ряда специальных заданий. Такие задания принято называть тестами. Тест – это стандартизированное задание или особым образом связанные между собой задания, которые позволяют исследователю диагностировать меру выраженности исследуемого свойства у испытуемого, его психологические характеристики, а также отношение к тем или иным объектам. В результате тестирования обычно получают некоторую количественную характеристику, показывающую меру выраженности исследуемой особенности у личности. Она должна быть соотносима с установленными для данной категории испытуемых нормами.

Значит, с помощью тестирования можно определить имеющийся уровень развития некоторого свойства в объекте исследования и сравнить его с эталоном или с развитием этого качества у испытуемого в более ранний период.

Существуют определенные правила проведения тестирования и интерпретации полученных результатов. Эти правила достаточно четко проработаны, и основные из них имеют следующий смысл:

1) информирование испытуемого о целях проведения тестирования;

2) ознакомление испытуемого с инструкцией по выполнению тестовых заданий и достижение уверенности исследователя в том, что инструкция понята правильно;

3) обеспечение ситуации спокойного и самостоятельного выполнения заданий испытуемыми; сохранение нейтрального отношения к тестируемым, уход от подсказок и помощи;

4) соблюдение исследователем методических указаний по обработке полученных данных и интерпретации результатов, которыми сопровождается каждый тест или соответствующее задание;

5) предупреждение распространения полученной в результате тестирования психодиагностической информации, обеспечение ее конфиденциальности;

6) ознакомление испытуемого с результатами тестирования, сообщение ему или ответственному лицу соответствующей информации с учетом принципа «Не навреди!»; в этом случае возникает необходимость решения серии этических и нравственных задач;

7) накопление исследователем сведений, полученных другими исследовательскими методами и методиками, их соотнесение друг с другом и определение согласованности между ними; обогащение своего опыта работы с тестом и знаний об особенностях его применения.

Выделяют также несколько типов тестов, каждому из которых сопутствуют соответствующие процедуры тестирования.

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

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

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

Личностные тесты предназначены для выявления свойств личности испытуемых. Они многочисленны и разнообразны: существуют опросники состояний и эмоционального склада личности (например, тесты тревожности), опросники мотивации деятельности и предпочтений, определения черт характера личности и отношений.

Имеется группа тестов, называемых проективными, которые позволяют выявить установки, неосознаваемые потребности и побуждения, тревоги и состояние страха.

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

Надежность теста определяется тем, насколько получаемые показатели являются стабильными и насколько они не зависят от случайных факторов. Разумеется, речь идет о сравнении показаний одних и тех же испытуемых. Это значит, что надежному тесту должна быть свойственна согласованность показателей тестирования, полученных при повторном тестировании, и можно быть уверенным в том, что тест выявляет одно и то же

свойство. Применяются разные способы проверки надежности тестов.

Один способ – это только что упомянутое повторное тестирование: если результаты первого и через определенное время проводимого повторного тестирования покажут наличие достаточного уровня корреляции, то это будет свидетельствовать о надежности теста. Второй способ связан с применением другой эквивалентной формы теста и наличием высокой корреляции между ними. Возможно и применение третьего способа оценки надежности, когда тест допускает его расщепление на две части и одна

и та же группа испытуемых обследуется с применением обеих частей теста. Надежность теста показывает, насколько точно измеряются психологические параметры и насколько высокой может быть мера доверия исследователя к полученным результатам.

Валидность теста отвечает на вопрос о том, что именно выявляет тест, насколько он пригоден для выявления того, для чего он предназначен. Например, тесты способностей нередко выявляют несколько иное: натренированность, наличие соответствующего опыта или, наоборот, его отсутствие. В таком случае тест не отвечает требованиям валидности.

В психодиагностике выделяют разные виды валидности. В простейшем случаеь валидность теста обычно определяется путем сопоставления полученных в результате тестирования показателей с экспертными оценками о наличии данного свойства у исследуемых (текущая валидность или валидность «по одновременности»), а также путем анализа данных, полученных в результате наблюдения за обследуемыми в различных ситуациях их жизни и деятельности, и их достижений в соответствующей области.

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

Изучение продуктов деятельности – это исследовательский метод, который позволяет опосредованно изучать сформированность знаний и навыков, интересов и способностей человека на основе анализа продуктов его деятельности. Особенность этого метода заключается в том, что исследователь не вступает в контакт с самим человеком, а имеет дело с продуктами его предшествующей деятельности или размышлениями о том, какие

изменения произошли в самом испытуемом в процессе и в результате его включенности в некоторую систему взаимодействий и отношений.

Введение

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

Такой процесс формальной проверки, или верификации , может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов - это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

Также к статическому тестированию относят тестирование требований , спецификаций , документации .

Регрессионное тестирование

После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования .

Тестовые скрипты

Тестировщики используют тестовые скрипты на разных уровнях: как в модульном, так и в интеграционном и системном тестировании. Тестовые скрипты, как правило, пишутся для проверки компонентов, в которых наиболее высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования, фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании чёрного ящика , тестировщик имеет доступ к ПО только через те же интерфейсы , что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).

Покрытие кода

Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

Цитаты

• «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» - Дейкстра , 1970 г.

См. также

• Обратная семантическая трассировка - универсальный метод тестирования любого проектного артефакта

Примечания

Литература

• Гленфорд Майерс, Том Баджетт, Кори Сандлер Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. - М .: «Диалектика», 2012. - 272 с. - ISBN 978-5-8459-1796-6
• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. - М .: «Вильямс», 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 экз. - ISBN 978-5-8459-1625-9
• Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. - Киев: ДиаСофт, 2001. - 544 с. - ISBN 9667393879
• Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. - М .: «Вильямс», 2002. - 374 с. - ISBN 5-8459-0336-X
• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. - М .: БИНОМ, 2008. - 368 с. - ISBN 978-5-94774-825-3
• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. - СПб. : Питер, 2004. - 320 с. - ISBN 5-94723-698-2

Ссылки

• Портал специалистов по тестированию и обеспечению качества ПО (рус.)
• Портал об автоматизированном тестировании ПО (рус.)
• Качество программного обеспечения (рус.)