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

---

Аннотация

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

Ключевые слова

Автоматизированное тестирование, верификация, валидация, тестирование пользовательского приёма

---

Введение

Тестирование программного обеспечения в жизненном цикле разработки программного обеспечения (SDLC) — это процесс выполнения и оценки программы с целью поиска ошибок (Myers, 1979). В целом, оно фокусируется на любой деятельности, направленной на оценку атрибута или возможности программы или системы и на установление ее соответствия требованиям спецификации (Hetzel, 1988). Фактически, программная система мало чем отличается от других физических систем, где принимаются входные данные и производятся выходные данные (Pan, 1999). Однако программное обеспечение не страдает от физических изменений. Как правило, оно не меняется до тех пор, пока не будут внесены изменения, обновления или не изменятся требования пользователя (Pan, 1999). Следовательно, после выпуска программного обеспечения ошибки проектирования или баги будут скрыты и останутся скрытыми до активации (Pan, 1999). Все возможные значения должны быть проверены и протестированы, но идеальное тестирование невозможно (Humphrey, 1995). Если на предварительном этапе происходит сбой тестирования и код выпускается, программа может теперь работать с тестовым случаем, для которого она, возможно, не была предназначена ранее (Pan 1999). Но ее поведению на предотладочных тестовых случаях, с которыми она работала ранее, больше нельзя доверять (Pan 1999). Чтобы отреагировать на эту возможность, тестирование должно быть перезапущено. Затраты на этот этап часто, как правило, обескураживают (Pan 1999). В ответ на это верификация может использоваться для тестирования или проверки элементов, включая код, на согласованность и соответствие путем оценки результатов по заранее определенным требованиям. Отладка подразумевает, что тестирование должно намеренно стремиться к тому, чтобы что-то пошло не так, чтобы выяснить, происходят ли вещи, когда они не должны или не происходят когда должны. Валидация касается корректности системы, например, это процесс проверки того, является ли требование, которое должно быть указано, тем, что действительно нужно пользователю. Это означает, что процесс валидации проверяет, соответствует ли разработанная система требованиям заказчика и необходимо ли её включить в систему, в то время как процесс верификации проверяет, корректна ли эта система (Фишер, 1977). Следовательно, и верификация, и валидация необходимы как отдельные элементы любого процесса тестирования. В данной статье рассматриваются три этапа тестирования программного обеспечения для рассмотрения возможных требований, которые могут повлиять на возможности всей системы.

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

Проблемы при тестировании программного обеспечения

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

Процессы тестирования программного обеспечения

Процессы верификации и валидации обсуждаются ниже. Вкратце, верификация делает продукт правильным, а валидация — правильным. Многие тестировщики используют в этих процессах тестирование «белого ящика». Оно занимается исследованием внутренней логики и структуры кода. Кратко описаны некоторые важные процессы тестирования «белого ящика». Тестирование потока данных — это процесс, который может определять и использовать переменные программы (Horgan и London, 1991). Тестирование циклов касается исключительно валидности конструкций циклов. Тестирование ветвлений проверяет значения «истина» и «ложь», заданные для составных условий, появляющихся в различных операторах ветвления (Jorgensen, 2002). Тестирование потока управления — это структурное тестирование, которое использует поток управления программы в качестве модели и выбирает набор тестовых путей через программу (Rapps и Weyuker, 1985). Тестирование базисного пути позволяет разработчику тестового набора построить логическую меру сложности процедурного дизайна, а затем применять эту меру для определения базового набора путей выполнения (Clarke и др., 1989). Кроме того, некоторые тестировщики используют тестирование «черного ящика» вместо тестирования «белого ящика» для проверки фундаментальных аспектов системы, уделяя мало внимания ее внутренней логической структуре (Beizer, 1995). Существует несколько типичных процессов тестирования «черного ящика». Эквивалентное разбиение позволяет сократить количество тестовых случаев и разделить программный модуль на разделы данных, из которых можно определить тестовые случаи (Spillner et al., 2007). Анализ граничных значений касается тестирования при граничных значениях, таких как минимум, максимум, внутри и снаружи границ, значения ошибок и типичные значения. Причинно-следственный граф создает связь между причинами и следствиями (Nursimulu and Probert, 1995). Нечеткое тестирование выявляет ошибки реализации и использует внедрение некорректных данных в автоматизированном сеансе (Miller et al., 1990). Существуют и другие процессы тестирования «черного ящика». Регрессионное тестирование повторно запускает некоторые из выбранных тестовых случаев, чтобы убедиться, что модифицированная программная система по-прежнему обладает требуемой функциональностью (Ball, 1998). Тестирование по шаблонам — это новый тип автоматизированного тестирования, который позволяет проверить качество приложения на соответствие его дизайну, архитектуре и шаблонам (Glaser and Strauss, 1967). Тестирование с помощью ортогональных массивов — это систематический статистический способ тестирования программного обеспечения, который может применяться при тестировании пользовательского интерфейса, системном тестировании, регрессионном тестировании, тестировании конфигурации и тестировании производительности. Матричное тестирование предоставляет отчёт о состоянии проекта. При ручном тестировании тестировщик определяет операции ручного тестирования для тестирования программного обеспечения без цели автоматизации тестирования. Соответственно, это тестирование — трудоёмкая деятельность, требующая от тестировщика определённого набора качеств, например, умного, трудолюбивого, наблюдательного, креативного, склонного к размышлениям, инновационного, открытого, находчивого и опытного. Автоматизированное тестирование запускает тестируемую программу, используя правильные входные данные и оценивая выходные данные в соответствии с ожиданиями перед тестированием. Для автоматического тестирования требуется набор тестов, который генерируется генератором тестовых случаев, вмешательство человека не требуется. Примерами инструментов автоматизированного тестирования являются регрессионное тестирование, модульное тестирование, автоматизированное функциональное тестирование и управление тестированием. Регрессионное тестирование подразумевает повторное тестирование неизменённых частей приложения. В тестовом наборе тестовые случаи могут быть выполнены повторно, чтобы проверить, не привели ли новые изменения к появлению новых ошибок и сохранился ли прежний функционал приложения. Этот тест может быть построен в новой сборке, когда есть значительные изменения в исходной функциональности или даже одна отладка. В этой статье основное внимание уделяется трем основным методам, которые описаны ниже. Retest-All Testing — один из методов регрессионного тестирования, в котором все тесты в существующей функциональности или тестовом наборе могут быть выполнены повторно. Недостатком этого метода является его высокая стоимость, поскольку он требует огромных ресурсов и времени (Smith and Robson, 1992). При выборе регрессионного теста вместо повторного тестирования всего тестового набора лучше выбрать несколько тестовых случаев для запуска. Одним из преимуществ этого метода является то, что повторно используемые тестовые случаи могут быть использованы в последующих циклах регрессии. Приоритизация тестовых случаев обеспечивает планирование тестовых случаев в порядке, который улучшает возможности регрессионного тестирования (Elbaum et al. 2000). С другой стороны, для ручного тестирования тестировщики используют модульное тестирование / модульное тестирование вместо автоматизированного тестирования. Модуль — это наименьший тестируемый компонент в программной системе. Модульное тестирование вводится для проверки корректной работы наименьшей независимой функции в программном обеспечении. Тестируемый модуль тестируется, чтобы определить, работает ли он корректно, будучи изолированным от остального кода (Rothermel and Kinneer, 2004). Кроме того, интеграционное тестирование может: обеспечивать предполагаемую функциональность, когда модули построены для взаимодействия друг с другом; и проверять такие модули. Хотя отдельные классы могут быть созданы и протестированы корректно, ошибки могут возникать из-за их неправильного взаимодействия. Модульное тестирование относится к интеграционному тестированию, которое включает в себя рассмотрение: состояний нескольких модулей, участвующих в одно и то же время во взаимодействии; и состояния одного объекта модуля (Meyers, 1979). Последняя стратегия — тестирование методом серого ящика, оно сочетает в себе концепции тестирования методом белого ящика и черного ящика для тестирования приложения, имеющего частичные знания о внутренней структуре и в то же время обладающего знаниями о фундаментальных аспектах системы (Barnett et al., 2003).

Подходы к интеграционному тестированию

Для разработки плана интеграционного тестирования можно использовать сочетание следующих подходов. Интеграционный подход «Big-Bang» — это тип интеграционного тестирования, при котором программные и аппаратные элементы объединяются сразу, а не поэтапно. При этом отдельные модули программ не интегрируются до тех пор, пока не будет определено, какие модули входят в состав программы. Этот подход не подходит в основном для неопытных программистов, которые полагаются на выполнение тестов (Sage and Palmer, 1990). При интеграционном подходе «Bottom-Up» каждый подкласс придумывается и тестируется отдельно, после чего тестируется вся программа. Подкласс может состоять из множества модулей через четко определенные интерфейсы. Основная цель этого подхода заключается в том, чтобы каждый подкласс должен тестировать интерфейсы между различными модулями, образующими подсистему. Тестовые случаи должны быть тщательно отобраны для проверки интерфейсов всеми возможными способами. Интеграционный подход «Top-Down» — это инкрементальное интеграционное тестирование, которое начинается с тестирования модуля верхнего уровня. После этого он добавляет модули нижнего уровня один за другим. Он использует заглушки для имитации модулей нижнего уровня. Заглушка — это специальная структура кода, которая может имитировать поведение хорошо спроектированного и существующего модуля, который ещё не разработан или не сконструирован (Клив и Целлер, 2005). Смешанный подход к интеграции (комбинированный или гибридный) сочетает в себе подходы к тестированию «сверху вниз» и «снизу вверх». В этом подходе тестировщики используют драйверы (вызывающие программы) и заглушки (вызываемые программы) везде, где программы не завершены.

Тестирование эффективности

Тестировщики занимаются тестированием производительности, которое предоставляет заинтересованным сторонам информацию о стабильности, скорости и масштабируемости приложения. Тестирование производительности позволяет определить, соответствует ли программное обеспечение требованиям стабильности, скорости и масштабируемости. Далее следует тестирование восстановления, которое определяет, насколько хорошо система должна восстанавливаться после системных сбоев, аппаратных сбоев и других катастрофических проблем. Многие компьютерные системы должны восстанавливаться после ошибок и возобновлять работу в течение заранее определенного времени. Система может быть отказоустойчивой, что означает, что сбои в обработке не должны приводить к прекращению работы всей системы. Однако системный сбой должен быть устранен в течение определенного периода времени. Программа проверяется в процессе тестирования, сохраняя файлы данных в соответствующих каталогах. Соответственно, обеспечивается достаточное пространство для хранения и предотвращается непредвиденное завершение работы из-за нехватки места. Это внешнее хранилище, а не внутреннее. После этого проводится тестирование процедур, предоставляющее подробные инструкции по выполнению одного или нескольких тестовых случаев. Последнее тестирование, приемочное тестирование пользователем (UAT), представляет собой формальное тестирование, призванное определить, соответствует ли программная система критериям приемки. Это помогает покупателю определить, стоит ли отказываться от системы. Более того, приемочное тестирование предлагается для определения пригодности программного обеспечения к использованию. Кроме того, оно включает факторы, связанные с бизнес-средой. Альфа-тестирование проводится при выпуске любого типа нового программного обеспечения или версии старого программного обеспечения (называемой альфа-версией). Кроме того, альфа-версии тестируются определенными группами пользователей, выбранными разработчиком программного обеспечения. Они тестируют и проверяют, все ли предоставленные функции работают должным образом. Бета-тестирование проводится после альфа-тестирования. Версии программного обеспечения относятся к бета-версиям, которые выпускаются для ограниченного круга людей. Это может гарантировать, что продукт имеет несколько ошибок или неисправностей. Иногда бета-версии выпускаются для широкой публики, чтобы расширить область обратной связи и увеличить количество будущих пользователей. К сожалению, тестирование программного обеспечения является одним из самых сложных процессов в SDLC. Тестировщики могут тестировать программное обеспечение, используя различные методы тестирования. Поэтому в этой статье предлагаются фазы тестирования программного обеспечения в качестве альтернативного варианта для тестировщиков.

Design of Software Testing Phases

This section is the result of studying the theory of software testing. Software testing can be divided into three main phases: preliminary testing, testing and user acceptance testing.

Фаза предварительного тестирования

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

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

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

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

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

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

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

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

Фаза тестирования

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

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

Валидация: она проверяет, соответствует ли разработанное программное обеспечение требованиям пользователя.

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

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

Этап приёмочного тестирования пользователем (UAT)

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

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

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

Подтверждение проверки интеграционного тестирования: Этот шаг охватывает приемку всего тестирования системы. Достигается соглашение по дефектам. Это форма, подписанная менеджером проекта, которая подтверждает, что документация, системное тестирование и учебные материалы прошли все тесты в приемлемых пределах.

Ремонт: Этот шаг проводится для обеспечения стабильной работы на основе технических и функциональных спецификаций.

Координация выпуска: Этот шаг является последним перед выпуском нового программного обеспечения на рынок.

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

Заключение

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

Ссылки

1. 1. Ball, T. 1998. On the limit of control row analysis for regression test selection. Proc. ACM SIGSOFT Int. Symp. on Software Testing and Analysis (ISSTA), Clearwater Beach, FL, USA, 2–5 March 1998, pp. 134–42.
2. 2. Barnett, M.; Grieskamp, W.; Kerer, C.; Schulte, W.; Szyperski, C.; Tilmann, N.; and Watson, A. 2003. Serious specification for composing components. Proc. 6th ICSE Workshop on Component-based Software Engineering: Automated Reasoning and Prediction, Portland, OR, USA, 3–4 May 2003. 6 pages.
3. 3. Clarke, L.A.; Podgurski, A.; Richardson, D.J.; and Zeil, S.J. 1989. A formal evaluation of data row path selection criteria. IEEE Trans. Software Eng. 15(11): 1,318–32.
4. 4. Cleve, H.; and Zeller, A. 2005. Locating causes of program failures. Proc. 27th ACM Int. Conf. Software Eng. (ICSE), St. Louis, MO, USA, 15–21 May 2005, pp. 342–51.
5. 5. Elbaum, S.; Malishevsky, A.G.; and Rothermel, G. 2000. Prioritizing test cases for regression testing. Proc. ACM SIGSOFT Int. Symp. on Software Testing and Analysis (ISSTA), Portland, OR, USA, 22–25 August 2000, pp. 102–12.
6. 6. Fischer, K.F. 1977. A test case selection method for the validation of software maintenance modifications. Proc. IEEE Int. Computer Software and Application Conference (COMPSAC), Chicago, IL, USA, 8–11 November 1977, pp. 421–6.
7. 7. Glaser, B.G.; and Strauss A.L. 1967. The Discovery of Grounded Theory: Strategies for Qualitative Research. Aldine, Chicago, IL, USA.
8. 8. Hetzel, W.C. 1988. The Complete Guide to Software Testing. 2nd ed. QED Information Sciences, Inc., Wellesley, MA, USA.
9. 9. Horgan, J.R.; and London, S. 1991. Data row coverage and the C language. Proc. 4th ACM Symp. on Testing, Analysis, and Verification (TAV 4), Victoria, BC, Canada, 8–9 October 1991, pp. 87–97.
10. 10. Humphrey, W. S. 1995. A Discipline for Software Engineering. Addison Wesley, New York, NY, USA.
11. 11. Jorgensen, P.C. 2002. Software Testing: A Craftsman’s Approach. 2nd ed. CRC Press, New York, NY, USA. Chapter 6.
12. 12. Miller, B.P.; Fredriksen, L.; and Bryan, S. 1990. An empirical study of the reliability of UNIX utilities. Commun. ACM, 33(12): 32–44.
13. 13. Myers, G.J. 1979. The Art of Software Testing. John Wiley & Sons, New York, NY, USA.
14. 14. Nursimulu, K.; and Probert, R.L. 1995. Cause-effect graphing analysis and validation of requirements. Proc. Conf. of the Centre for Advanced Studies on Collaborative Research (CASCON), IBM Press, Toronto, Ontario, Canada, 7–9 November 1995. p. 46.
15. 15. Pan, J. 1999. Software testing. Student Report. Available:http://www.ece.cmu.edu/~koopman/des_s99/sw_testing.
16. 16. Rapps, S.; and Weyuker, E.J. 1985. Selecting software test data using data row information. IEEE Trans. Software Eng. 11(4): 367–75.
17. 17. Sage, A.P.; and Palmer, J.D. 1990. Software Systems Engineering. John Wiley & Sons, New York, NY, USA.
18. 18. Spillner, A.; Linz T.; and Schaefer, H. 2007. Software Testing Foundations. A Study Guide for the Certified Tester Exam. Foundation Level, ISTQB compliant. Rocky Nook Inc., Santa Barbara, CA, USA.