2 ПЛАН ДЕЙСТВИЙ НА БУДУЩЕЕ
Тестирование является одной из старейших форм верификации. Таким образом, разработчики программного обеспечения предложили и использовали многочисленные методы тестирования, чтобы помочь им повысить уверенность в том, что программное обеспечение обладает различными качествами. Конечная цель тестирования программного обеспечения — помочь разработчикам создавать системы высокого качества. Таким образом, тестирование используется разработчиками всех типов систем. По мере совершенствования технологий стало возможным применять методы тестирования к более крупным системам. Однако широкое использование систематических методов тестирования не является обычным явлением в промышленности. Например, хотя для модульного тестирования был разработан ряд методов тестирования на основе кода, даже самые слабые формы этих методов не используются многими практиками. Другой пример: хотя повторное тестирование программного обеспечения после его модификации может быть автоматизировано, многие практики все еще выполняют эту задачу вручную.
На Рисунке 1 показан план действий по тестированию, ведущий к цели: предоставление практических методов, инструментов и процессов тестирования, которые могут помочь инженерам-программистам разрабатывать высококачественное программное обеспечение. Движение к этой цели требует фундаментальных исследований, создания новых методов и инструментов и проведения эмпирических исследований для облегчения передачи технологий в промышленность. Как показывают стрелки на рисунке, области могут быть пересмотрены на пути к цели. Например, после проведения эмпирических исследований с использованием прототипа инструмента, реализующего алгоритмы для тестирования компонентно-ориентированного программного обеспечения, и фундаментальные исследования, и разработка методов и инструментов могут быть пересмотрены.
Фундаментальные исследования
Исследования во многих областях тестирования позволили добиться прогресса, который обещает помочь нам достичь цели предоставления практических инструментов, которые могут помочь инженерам-программистам разрабатывать высококачественное программное обеспечение. Однако дополнительная работа должна быть проделана в ряде смежных областей, как показано на Рисунке 1. Например, при предоставлении методов для тестирования развивающегося программного обеспечения мы можем включить методы тестирования на основе архитектуры или методы, сочетающие статический анализ с тестированием.
Тестирование компонентно-ориентированных систем
Увеличение размера и сложности программных систем привело к текущему фокусу на разработке распределенных приложений,которые строятся из компонентно-ориентированных систем. Компонентно-ориентированная система состоит в основном из компонентов: модулей, которые инкапсулируют как данные, так и функциональность и являются настраиваемыми через параметры во время выполнения [29]. Учитывая растущую распространенность компонентно-ориентированных систем, нам требуются эффективные, действенные способы тестирования этих систем.
Мы можем рассматривать вопросы, возникающие при тестировании компонентно-ориентированных систем, с двух точек зрения: поставщика компонента и пользователя компонента. Перспектива поставщика компонента касается вопросов тестирования, которые интересуют поставщика (т.е. разработчика) программных компонентов. Поставщик компонента рассматривает компоненты независимо от контекста, в котором они используются. Поэтому поставщик должен эффективно тестировать все конфигурации компонентов независимо от контекста. Перспектива пользователя компонента, напротив, касается вопросов тестирования, которые concern пользователя (т.е. разработчика приложения) программных компонентов. Пользователь компонента рассматривает компоненты как контекстно-зависимые единицы, поскольку приложение пользователя компонента предоставляет контекст, в котором компоненты используются. Таким образом, пользователь интересуется только теми конфигурациями или аспектами поведения компонентов, которые необходимы для приложения пользователя компонента.
Один фактор, который различает вопросы, актуальные для двух перспектив, — это доступность исходного кода компонента: поставщики компонентов имеют доступ к исходному коду, тогда как пользователи компонентов, как правило, нет. Один из типов программного обеспечения, для которого исходный код обычно недоступен, — это коммерческое готовое программное обеспечение (COTS). Хотя на разработчиков COTS не налагается никаких нормативов, для стандартизации разработки и снижения затрат многие критические приложения требуют использования этих систем [32]. Отсутствие доступа к исходному коду компонентов ограничивает тестирование, которое может выполнить пользователь компонента.
Исследователи расширили существующие методы тестирования для использования поставщиками компонентов. Например, Doong и Frankl описывают методы, основанные на алгебраических спецификациях [34], Murphy и коллеги описывают свой опыт с кластерным и классовым тестированием, а Kung и коллеги представляют методы, основанные на состояниях объектов [26]. Другие исследователи расширили подходы на основе кода для использования поставщиками компонентов для тестирования отдельных компонентов. Например, Harrold и Rothermel представляют метод, который вычисляет пары "определение-использование" (definition-use pairs) для использования при тестировании классов [22]. Эти пары "определение-использование" могут быть полностью содержаться в одном методе или могут состоять из определения в одном методе, которое достигает использования в другом методе. Buy и коллеги представляют аналогичный подход, который использует символьное вычисление для генерации последовательностей вызовов методов, которые приведут к выполнению пар "определение-использование" [6]].
Исследователи рассматривали способы, с помощью которых пользователи компонентов могут тестировать системы, построенные из компонентов [45]. Rosenblum предлагает теорию адекватности тестирования компонентно-ориентированного программного обеспечения. Его работа расширяет набор аксиом Weyuker, формализующих понятие адекватности тестирования [52], и предоставляет способ тестирования компонента из каждого поддомена в программе, который его использует. Devanbu и Stubblebine представляют подход, который использует криптографические техники, чтобы помочь пользователям компонентов проверять покрытие компонентов без необходимости раскрытия интеллектуальной собственности разработчиком компонента [13].
При дополнительных исследованиях в этих областях мы можем ожидать эффективные методы и инструменты, которые помогут пользователям компонентов тестировать свои приложения более эффективно. Нам необходимо понять и разработать эффективные методы для тестирования различных аспектов компонентов, включая безопасность, надежность и отказоустойчивость; эти качества особенно важны в условиях взрывного роста веб-ориентированных систем. Эти методы могут предоставить информацию о тестировании, которая повысит уверенность разработчиков, использующих компоненты в своих приложениях.
Нам необходимо определить типы информации о тестировании компонента, которые нужны пользователю компонента для тестирования приложений, использующих этот компонент. Например, разработчик может захотеть измерить покрытие частей компонента, которые использует ее приложение. Для этого компонент должен иметь возможность реагировать на входные данные, предоставляемые приложением, и записывать покрытие, обеспечиваемое этими входными данными. Для другого примера, пользователь компонента может захотеть протестировать только интеграцию компонента со своим приложением. Для этого пользователь компонента должен иметь возможность идентифицировать связи между своим приложением и компонентом.
Нам необходимо разработать методы представления и вычисления типов информации о тестировании, которые нужны пользователю компонента. Существующие стандарты компонентов, такие как COM и JavaBeans, поставляют информацию о компоненте, которая упакована вместе с компонентом. Точно так же могут быть разработаны стандарты для представления информации о тестировании компонента вместе с эффективными методами вычисления и хранения этой информации. Например, информация о покрытии для использования в тестировании на основе кода или информация о связях для использования в интеграционном тестировании может храниться вместе с компонентом; или методы генерации этой информации могут быть разработаны поставщиком компонента и сделаны доступными через интерфейс компонента. Наконец, нам необходимо разработать методы, которые используют информацию, предоставляемую с компонентом, для тестирования приложения. Эти методы позволят пользователю компонента эффективно и действенно тестировать свое приложение с компонентом.
Тестирование на основе артефактов, созданных до кода
Методы тестирования могут основываться на артефактах, созданных до написания кода, таких как спецификации проектирования, требований и архитектуры. В прошлом многие из этих методов основывались на неформальных спецификациях. Однако в последнее время для этих спецификаций стали использоваться более формальные подходы. Методы, которые используют эти предкодовые спецификации для таких задач, как планирование тестовых случаев и разработка, могут помочь улучшить общий процесс тестирования. В этом разделе обсуждается использование одного типа предкодового артефакта — архитектуры программного обеспечения — для тестирования.
Увеличение размера и сложности программных систем привело к возникновению дисциплины программной архитектуры. Программная архитектура включает описание элементов, из которых строятся системы, взаимодействий между этими элементами, шаблонов, которые направляют их композицию, и ограничений на эти шаблоны [50]. Стили программной архитектуры определяют семейства систем с точки зрения шаблонов структурной организации. Учитывая растущий размер и сложность программных систем, необходимы методы для оценки качеств систем на ранних стадиях их разработки. Благодаря своим абстракциям, программная архитектура предоставляет многообещающий способ управления большими системами.
Появляющиеся формальные нотации для спецификации программной архитектуры могут предоставить основу, на которой могут быть разработаны эффективные методы тестирования. Недавно исследователи начали изучать способы использования этих формальных архитектурных спецификаций таким образом. Например, Eickelmann и Richardson рассматривают способы, с помощью которых архитектурная спецификация может быть использована для оценки тестируемости программной системы [15]; Bertolino и коллеги рассматривают способы использования архитектурной спецификации в интеграционном и модульном тестировании [5]; Harrold представляет подходы к использованию спецификации программной архитектуры для эффективного регрессионного тестирования [19]; а Richardson, Stafford и Wolf представляют комплексный подход к тестированию на основе архитектуры, который включает критерии покрытия на основе архитектуры, тестируемость архитектуры и срезы архитектуры (architecture slicing) [42]. Эти методы и инструменты тестирования на основе архитектуры могут облегчить динамический анализ и, следовательно, обнаружение ошибок гораздо раньше в процессе разработки, чем это возможно в настоящее время.
Чтобы ускорить исследования в этой области, в 1998 году Национальный исследовательский совет Италии и Национальный научный фонд США выступили спонсорами Семинара по роли программной архитектуры в тестировании и анализе. Этот семинар собрал вместе исследователей в области программной архитектуры, тестирования и анализа для обсуждения направлений исследований [43]. Отчет о результатах этого семинара можно найти по адресу http://www.ics.uci.edu/~djr/rosatea.
Дополнительные исследования в этой области обещают обеспечить значительную экономию в тестировании программного обеспечения. Нам необходимо разработать методы, которые можно использовать со спецификацией архитектуры для разработки тестовых случаев. Эти методы могут предоставить требования к тестовым случаям для оценки различных аспектов архитектуры. Этот подход позволит оценивать различные аспекты системы на ранних стадиях разработки. Эти методы также могут предоставить функциональные требования к тестовым случаям, которые могут быть использованы для разработки тестовых случаев для использования при тестировании реализации. Эти методы будут способствовать систематической разработке тестовых случаев на ранних стадиях процесса разработки. Наконец, эти методы могут предоставить способы автоматической генерации тестовых случаев. Эти методы позволят эффективно генерировать тестовые случаи на ранней стадии разработки программного обеспечения.
Нам также необходимо разработать методы, которые можно использовать для оценки тестируемости программных архитектур. С этой информацией разработчики могут рассматривать альтернативные проекты и выбирать тот, который соответствует их требованиям к тестируемости.
Тестирование развивающегося программного обеспечения
Регрессионное тестирование, которое пытается проверить модифицированное программное обеспечение и обеспечить, чтобы новые ошибки не были внесены в ранее протестированный код, широко используется в процессе разработки и сопровождения программного обеспечения. Регрессионное тестирование используется для тестирования программного обеспечения, которое разрабатывается в условиях постоянной изменяется по мере изменения рынка или технологий, для тестирования новых или модифицированных компонентов системы и для тестирования новых членов в семействе схожих продуктов. Несмотря на усилия по снижению его стоимости, регрессионное тестирование остается одной из самых дорогостоящих деятельностей, выполняемых в течение жизненного цикла программной системы: исследования показывают, что регрессионное тестирование может составлять до одной трети общей стоимости программных систем.
Поскольку регрессионное тестирование дорогое, но важное, исследователи сосредоточились на способах сделать его более эффективным и действенным. Исследования по регрессионному тестированию охватывают широкий круг тем. Chen и коллеги [7], Ostrand и Weyuker [37], и Rothermel и Harrold [48] разработали методы, которые, при наличии существующего набора тестов и информации о предыдущем тестировании, выбирают подмножество набора тестов для использования при тестировании модифицированного программного обеспечения.^2 Harrold, Gupta [20] и Soffa и Wong [53] и коллеги представляют методы, помогающие управлять ростом размера набора тестов. Leung и White [28] и Rosenblum и Weyuker [44] представляют методы для оценки регрессионной тестируемости. Эти методы позволяют оценить, до выбора регрессионных тестов, количество тестовых случаев, которые будут выбраны методом. Другие техники, такие как разработанная Stafford, Richardson и Wolf, оценивают сложность регрессионного тестирования на предкодовых артефактах [51].
Поскольку большинство разработок программного обеспечения включают применение модификаций к существующему программному обеспечению, дополнительные исследования, предоставляющие эффективные методы для тестирования модифицированного программного обеспечения, могут значительно снизить затраты на разработку программного обеспечения. Нам необходимо разработать методы, которые могут быть применены к различным представлениям программного обеспечения, таким как его требования или архитектура, чтобы помочь в выборочном повторном тестировании программного обеспечения. Эти методы позволят нам идентифицировать существующие тестовые случаи, которые могут быть использованы для повторного тестирования программного обеспечения. Эти методы также позволят нам идентифицировать те части модифицированного программного обеспечения, для которых требуются новые тестовые случаи.
Нам также необходимо разработать методы для помощи в управлении наборами тестов, которые мы используем для тестирования программного обеспечения. Эффективные методы, которые могут уменьшить размер набора тестов, сохраняя при этом желаемый уровень покрытия кода или требований, помогут снизить затраты на тестирование. Методы, которые позволяют нам идентифицировать тестовые случаи, которые из-за модификаций больше не нужны, также помогут снизить стоимость тестирования. Поскольку тестирование может выполняться часто, может не быть времени для запуска всего набора тестов. Таким образом, нам нужны методы, которые позволят нам расставлять приоритеты тестовых случаев, чтобы максимизировать (или минимизировать) некоторый аспект тестовых случаев, такой как покрытие, стоимость или время выполнения. Эти методы могут помочь тестировщикам находить дефекты раньше в процессе тестирования.
Наконец, нам необходимо разработать методы, которые позволят нам оценивать тестируемость как программного обеспечения, так и наборов тестов. Методы, которые позволят нам оценивать тестируемость программного обеспечения с использованием предкодовых артефактов, обещают обеспечить наиболее значительную экономию. Например, использование программной архитектуры может позволить нам оценивать альтернативные проекты и выбирать те, которые облегчают эффективное повторное тестирование программного обеспечения. Эти методы могут быть применены к развивающемуся программному обеспечению и семействам продуктов, чтобы помочь определить наиболее эффективные проекты. Методы, которые позволят нам оценивать тестируемость набора тестов, также обеспечат экономию. Например, набор тестов, который содержит тестовые случаи, проверяющие отдельные требования, может быть более эффективным для использования в регрессионном тестировании, чем тот, в котором один тестовый случай проверяет многие требования.
Демонстрация эффективности методов тестирования
Многочисленные методы тестирования были разработаны и используются, чтобы помочь разработчикам повысить свою уверенность в том, что программное обеспечение обладает различными качествами. Большинство этих методов сосредоточены на отборе тестовых случаев. Goodenough и Gerhart предлагают, как оценивать критерии для определения адекватности наборов тестов, и они сосредотачиваются на том, как выбирать тестовые случаи, которые вселяют уверенность [18].
С тех пор было разработано множество методов отбора тестовых случаев. Некоторые методы тестирования выбирают тестовые случаи, основанные на предполагаемом поведении программного обеспечения без учета его реализации, а другие направляют отбор тестовых случаев, основанных на коде.
Были некоторые исследования, демонстрирующие эффективность определенных критериев отбора тестов в выявлении дефектов. Однако есть много областей для дополнительных исследований. Нам необходимо идентифицировать классы дефектов, для которых эффективны определенные критерии. На сегодняшний день был разработан ряд критериев отбора тестов, нацеленных на определенные типы дефектов. Несколько исследователей, включая Rapps и Weyuker и Laski и Korel, разработали критерии тестирования, которые фокусируют отбор тестов на потоках данных в программе. Для критических приложений безопасности оценивается, что более половины исполняемых операторов включают сложные булевы выражения. Для тестирования этих выражений Chilenski и Miller разработали критерий, модифицированное условие/решение покрытия, который специально концентрирует тестирование на этих типах операторов [8].
Rothermel и коллеги разработали методы тестирования на основе существующих методов, основанных на коде, для тестирования языков визуального программирования на основе форм, которые включают коммерческие электронные таблицы. Недавние исследования показывают, что, имея интерфейс, пользователи, не обученные методам тестирования, могут эффективно тестировать свои программы [49].
Нам необходимо провести дополнительные исследования, которые предоставят аналитические, статистические или эмпирические доказательства эффективности критериев отбора тестов в выявлении дефектов. Нам также необходимо понять классы дефектов, для которых критерии полезны. Наконец, нам необходимо определить взаимодействие между различными критериями отбора тестов и найти способы их объединения для проведения более эффективного тестирования.
Даже для критериев отбора тестов, которые показали свою эффективность, может не существовать эффективного метода для обеспечения покрытия в соответствии с критериями. Например, хотя было показано, что мутационный анализ является эффективным критерием адекватности, исследователи еще не нашли эффективного способа проведения этого анализа. Имея эффективные критерии тестирования, нам необходимо разработать способы проведения тестирования эффективно [10]. Нам также необходимо исследовать методы, которые приближенно удовлетворяют критерию адекватности, но все же достаточно эффективны. Например, рассмотрим выполнение тестирования потоков данных на программах, содержащих переменные-указатели. Тестирование, которое рассматривает все отношения потоков данных, включающие переменные-указатели, может быть слишком дорогим для выполнения. Однако набор тестов, полученный без учета этих отношений указателей, может обеспечить достаточное покрытие. Дополнительные исследования могут определить, достаточно ли таких приближений полного покрытия для критериев тестирования потоков данных и других критериев.
Создание эффективных процессов для тестирования
Важным аспектом тестирования является процесс,который мы используем для его планирования и реализации. Beizer описывает процесс тестирования [4]. Такой процесс обычно состоит из построения плана тестирования во время фазы сбора требований и реализации плана тестирования после фазы реализации программного обеспечения. Для разработки своего программного обеспечения Microsoft, Inc. использует другую модель, которая часто синхронизирует то, что делают люди, и периодически стабилизирует продукт поэтапно по мере развития проекта. Эти действия выполняются непрерывно на протяжении всего проекта. Важной частью модели является сборка и тестирование версии программного обеспечения каждую ночь [9]. Richardson и коллеги отстаивают идею процесса перманентного тестирования. Их проект перманентного тестирования закладывает основу для того, чтобы рассматривать анализ и тестирование как постоянные деятельности по улучшению качества. Перманентное тестирование обязательно является инкрементальным и выполняется в ответ на или в anticipation изменений в артефактах программного обеспечения или связанной информации.
Процесс для регрессионного тестирования неявно присутствует в методах выборочного регрессионного тестирования [7, 37, 48, 53]. Для применения этих методов тестирование должно быть выполнено на одной версии программного обеспечения, и должны быть собраны артефакты тестирования, такие как пары вход-выход и информация о покрытии. Эти артефакты используются методами для выбора тестовых случаев для использования при тестировании следующей версии программного обеспечения. Onoma и коллеги представляют явный процесс для регрессионного тестирования, который интегрирует многие ключевые методы тестирования в разработку и сопровождение развивающегося программного обеспечения [35]. Этот процесс учитывает все аспекты разработки и сопровождения.
Дополнительные исследования могут проверить эти существующие модели. Например, уменьшает ли ночная сборка и тестирование, такая как та, что выполняется в Microsoft, объем тестирования, требуемого позже? Для другого примера, как часто нужно вычислять артефакты тестирования для эффективного выбора регрессионных тестов? Дополнительные исследования также могут разработать новые модели процессов для тестирования и проверить эти модели.
Хотя тестирование важно для оценки качеств программного обеспечения, оно не может показать, что программное обеспечение обладает определенными качествами, и результаты, полученные от тестирования, часто не могут быть обобщены. Однако процесс разработки высококачественного программного обеспечения мог бы сочетать тестирование с другими инструментами качества. Osterweil и коллеги [36] предполагают, что различные методы и инструменты качества могли бы быть интегрированы, чтобы предоставить ценность, значительно превышающую то, что могут предоставить отдельные технологии.
Нам необходимо понять, как связаны эти различные методы тестирования и анализа, и разработать модели процессов, которые их включают. Процесс, сочетающий методы статического анализа с тестированием, имеет потенциал для улучшения качества и снижения затрат.
Использование артефактов тестирования
Процесс тестирования производит множество артефактов.Артефакты от тестирования включают трассы выполнения (execution traces) программного обеспечения с тестовыми случаями. Эти трассы выполнения могут включать информацию о том, какие операторы были выполнены, какие пути в программе были выполнены или какие значения получили определенные переменные во время выполнения. Артефакты от тестирования также включают результаты выполнения тестовых случаев, такие как прошел тестовый случай или нет. Эти артефакты могут быть сохранены для использования при повторном тестировании программного обеспечения после его модификации.
Учитывая объем и сложность этих артефактов, они также могут быть полезны для других задач тестирования и программной инженерии. Исследователи начали исследовать новые способы использования этих артефактов. Было разработано множество методов, которые используют трассы выполнения. Pan, DeMillo и Spafford представляют метод, который использует динамические срезы программ (dynamic program slices), которые выводятся из трасс выполнения, вместе с результатами прохождения/непрохождения для выполнений, чтобы идентифицировать потенциально ошибочный код [38]. Они применяют ряд эвристик, которые рассматривают различные комбинации пересечений и объединений динамических срезов для подмножества набора тестов, которые прошли, и подмножества набора тестов, которые не прошли. В эмпирических исследованиях на небольших испытуемых объектах результаты применения эвристик помогли локализовать дефектный код.
Ernst и коллеги представляют другую технику, которая использует трассы выполнения, содержащие значения, в каждой точке программы, для каждой рассматриваемой переменной. Цель их подхода — идентифицировать инварианты программы. После повторного выполнения программы со многими тестовыми случаями подход предоставляет список вероятных инвариантов в программе [16]. Их эмпирические результаты показывают, что этот подход может быть вполне успешным в идентификации этих инвариантов. Эти динамически выведенные инварианты могут быть использованы во многих приложениях. Например, они могут помочь в генерации тестовых случаев или валидации набора тестов.
Исследователи также разработали методы, которые используют информацию о покрытии для задач программной инженерии. Rosenblum и Weyuker [44] представляют метод, который использует информацию о покрытии для предсказания объема регрессионного тестирования. Их метод предсказывает, в среднем, процент набора тестов, который должен быть перетестирован после внесения изменений в программу. Более поздняя работа Harrold и коллег предоставила дополнительную оценку работы и представила улучшенную модель предсказания [21]. Ряд исследователей разработали методы, основанные на информации о покрытии, для выбора тестовых случаев из набора тестов для использования в регрессионном тестировании [7, 37, 48, 53]. Несколько исследователей использовали артефакты тестирования для сокращения и расстановки приоритетов наборов тестов [20, 47, 53]. Эмпирические исследования показывают, что эти методы могут быть эффективны в сокращении времени, необходимого для регрессионного тестирования. Ball представил метод, который выполняет анализ понятий (concept analysis) на информации о покрытии для вычисления отношений между выполненными сущностями в программе [2]. Сравнение этих динамических отношений с их статическими аналогами может помочь тестировщикам выявить свойства их набора тестов.
Reps и коллеги представляют метод, который сравнивает спектры путей из различных запусков программы [41]. Различия в спектрах путей могут быть использованы для идентификации путей в программе, вдоль которых управление расходится в двух запусках, и эта информация может быть использована для помощи в задачах отладки, тестирования и сопровождения. Результаты эмпирических исследований с использованием различных типов спектров, проведенных Harrold и Rothermel, позволяют предположить, что спектры, основанные на менее дорогом профилировании, такие как спектры ветвей (branch spectra), могут быть столь же эффективны с точки зрения их способности различать поведение программы, как и спектры, основанные на более дорогом профилировании, такие как спектры путей (path spectra) [23].
Другие исследователи предоставили техники визуализации для артефактов тестирования. Например, Ball и Eick представляют систему для визуализации информации, включая информацию тестирования, такую как покрытие, для больших программ, и Telcordia Technologies имеет несколько инструментов, которые сочетают анализ и визуализацию артефактов тестирования [3], чтобы помочь сопровождающим программное обеспечение [24].
Хотя были некоторые успехи в использовании артефактов тестирования для задач программной инженерии, эти исследования находятся в зачаточном состоянии. Дополнительные исследования могут подтвердить, что существующие методы предоставляют полезную информацию для инженеров-программистов. Например, мы можем определить, помогают ли эвристики, разработанные Pan и коллегами [38], идентифицировать ошибочный код, когда в программе много дефектов или взаимодействующих дефектов. Эти результаты могут предоставить отправную точку для других исследований.
Дополнительные исследования в этой области также могут предоставить новые методы, которые используют артефакты тестирования для задач программной инженерии. Нам необходимо определить типы информации, которые требуются инженерам-программистам и менеджерам на различных фазах разработки программного обеспечения. Нам также необходимы методы, которые будут находить важные отношения, существующие в программном обеспечении. Методы, такие как интеллектуальный анализ данных (data mining), могут помочь в этой задаче. Имея эти типы информации, нам необходимо разработать методы для представления информации полезным образом. Методы для эффективной визуализации информации тестирования могут предоставить эффективные инструменты для инженеров-программистов.
Другие методы тестирования
В дополнение к областям фундаментальных исследований, обсуждавшихся в предыдущих разделах, есть много других областей, в которых методы могли бы помочь нам достичь нашей цели. В этом разделе кратко представлены некоторые из них.
Генерация тестовых данных (входных данных для тестовых случаев) часто является трудоемким процессом. На сегодняшний день был представлен ряд методов, которые генерируют тестовые данные автоматически. Однако большинство этих методов применимы для модульного тестирования и могут не масштабироваться на большие системы. Нам необходимо разработать автоматические или полуавтоматические методы генерации тестовых данных, которые тестировщики могут использовать для больших систем. Эти данные могли бы генерироваться с использованием предкодовых представлений или с использованием самого кода.
Многие методы тестирования требуют некоторого типа информации статического анализа. Например, анализ потоков данных полезен для тестирования потоков данных программных единиц и для интеграционного тестирования, когда эти единицы комбинируются. Однако существующие методы для вычисления точной информации о потоках данных prohibitively дороги. Нам необходимо разработать масштабируемые методы анализа, которые могут быть использованы для вычисления требуемой информации.
Существующие методы измерения адекватности для строгих критериев тестирования, таких как потоки данных, требуют дорогой или интрузивной инструментации. Например, необходимо соблюдать осторожность при вставке зондов в систему реального времени, чтобы обеспечить, что зонды не заставят программу вести себя иначе, чем без них. Если мы ожидаем использования этих более строгих критериев, нам нужны эффективные методы инструментирования и записи.
Методы и инструменты
В конечном счете, мы хотим разработать эффективные методы и инструменты, которые могут быть использованы практиками для тестирования их программного обеспечения. Pfleeger представила причины, по которым технологиям программной инженерии требуется в среднем 18 лет для переноса в практику [39]. Исследователи должны работать с промышленностью, чтобы сократить это время для передачи технологий. Она также представила комплексный подход для осуществления этой передачи. Одним важным аспектом этого подхода для передачи технологий является разработка методов и инструментов, которые могут быть использованы в промышленных условиях, чтобы продемонстрировать эффективность создаваемых нами методов. Мы должны разработать методы и инструменты, которые реализуют методы и которые могут быть использованы для демонстрации их эффективности.
Для достижения этого важным критерием является то, что эти методы и инструменты должны быть масштабируемы до больших систем. Промышленные системы большие и сложные, и методы и инструменты должны функционировать на этих системах. Масштабируемые инструменты будут предоставлять полезную информацию эффективным способом. Исследователи часто демонстрируют эффективность своих методов с помощью инструментов, которые функционируют на искусственных или игрушечных системах. Таким образом, результаты их экспериментирования с этими инструментами могут не масштабироваться на большие промышленные системы. Нам необходимо разрабатывать надежные прототипы, идентифицировать контекст, в котором они могут функционировать, и использовать их для проведения экспериментов по демонстрации методов.
При разработке этих инструментов нам необходимо учитывать вычислительные компромиссы. Например, нам нужно учитывать точность эффективность вычисления, и нам нужно учитывать хранение информации versus ее вычисление по мере необходимости. Murphy и Notkin [33] и Atkinson и Griswold [1] предоставляют обсуждения некоторых из этих компромиссов.
Эффективный подход для разработки методов и инструментов — предоставить способы автоматического их создания; аналогичный подход используется для автоматической генерации компиляторов. Одним примером такого подхода является фреймворк Genoa для генерации инструментов анализа исходного кода. Genoa может быть переориентирован на различные парсеры; структуры данных дерева разбора, построенные такими парсерами, используются в анализе. Этот подход может быть использован для автоматической генерации специализированных инструментов тестирования [11].
После демонстрации с помощью прототипов инструментов, что методы могут быть эффективны на практике, мы должны работать над разработкой методов и инструментов, которые привлекательны для практиков. Методы и инструменты должны быть легки в использовании и изучении, и их вывод должен представляться ясным и понятным образом. Наконец, насколько это возможно, инструменты тестирования должны быть автоматизированы и требовать минимального участия инженеров-программистов.
Эмпирические исследования
Тесно связана с разработкой методов и инструментов проведение эмпирических исследований.Используя методы и инструменты, эти исследования помогут продемонстрировать масштабируемость и полезность методов на практике. Эти исследования также предоставят обратную связь, которая поможет направлять фундаментальные исследования и разработку инструментов. Как передача масштабируемых технологий в практику, так и создание таких технологий требуют значительных эмпирических исследований.
Есть много свидетельств растущего акцента на экспериментировании. В дополнение к представлению аналитической оценки масштабируемости и полезности методов программной инженерии, многие недавние статьи в трудах и журналах также сообщают о результатах эмпирических исследований, которые пытаются оценить масштабируемость и полезность методов. Более того, новый международный журнал, Empirical Software Engineering, предоставляет форум для отчетов о методах и результатах различных типов эмпирических исследований вместе с описаниями инфраструктур для поддержки такого экспериментирования. Наконец, финансирующие агентства, такие как Национальный научный фонд, поддерживают ряд крупных проектов для работы в экспериментальных системах.
Усилия по эмпирической оценке методов тестирования сталкиваются с рядом препятствий. Одно препятствие, которое обсуждалось в предыдущем разделе, — это трудность получения достаточно надежных реализаций этих методов. Второе препятствие для значительного экспериментирования — это трудность получения достаточного количества экспериментальных субъектов. Субъекты для экспериментов по тестированию включают как программное обеспечение, так и наборы тестов. Однако практики неохотно выпускают эти типы экспериментальных субъектов.
Нам необходимо планировать контролируемые эксперименты для демонстрации разрабатываемых нами методов. Нам необходимо собирать наборы экспериментальных субъектов и, если возможно, делать их доступными для исследователей. Нам также необходимо проводить экспериментирование с промышленными партнерами. Методы тестирования могут быть реализованы в промышленной среде, и промышленные субъекты могут быть использованы для экспериментирования. Если эти субъекты не могут быть сделаны публично доступными, мы можем создать обезличенную информацию, которая не раскрывала бы собственнической информации, но все еще была бы полезна для экспериментирования.
