АВТОМАТИЧЕСКАЯ ПРОВЕРКА КОНТРОЛЬНЫХ ПРИМЕРОВ, КОТОРАЯ НЕЯВНО СВЯЗАНА С АВТОМАТИЧЕСКИМ ИСПОЛНЕНИЕМ КОНТРОЛЬНЫХ ПРИМЕРОВ Российский патент 2010 года по МПК G06F11/36 

Ссылки на родственные заявки

Настоящая заявка связана с Патентной заявкой (США) номер MSFT-4148, озаглавленной "System and Method for Selecting Test Case Execution Behaviors for Reproducible Test Automation", поданной вместе с данной заявкой, и Патентной заявкой (США) номер MSFT-4150, озаглавленной "Test Automation Stack Layering", поданной вместе с данной заявкой.

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

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

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

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

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

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

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

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

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

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

Сущность изобретения

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

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

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

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

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

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

Краткое описание чертежей

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

На чертежах:

Фиг.1 - это блок-схема, показывающая примерное вычислительное окружение, в котором аспекты проверки контрольных примеров, которая не жестко связана с исполнением, могут быть реализованы;

Фиг.2 - это блок-схема системы проверки контрольных примеров, которая не жестко связана с исполнением контрольных примеров в соответствии с одним вариантом осуществления изобретения;

Фиг.3A-B - это последовательности операций проверки контрольных примеров, которые не жестко связаны с исполнением контрольных примеров в соответствии с одним вариантом осуществления изобретения;

Фиг.4 - это блок-схема системы проверки контрольных примеров, которая не жестко связана с исполнением контрольных примеров в соответствии с альтернативным вариантом осуществления изобретения.

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

Обзор

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

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

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

Примерное вычислительное окружение

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

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

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

На фиг.1 примерная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде вычислительной машины 110. Компоненты вычислительной машины 110 могут включать в себя, но не только, блок 120 обработки, системную память 130 и системную шину 121, которая соединяет различные компоненты системы, включая системную память, с блоком 120 обработки. Системная шина 121 может быть любой из некоторых типов шинных структур, включающих в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из многообразия шинных архитектур. В качестве примера, но не ограничения, такие архитектуры включают в себя шину промышленного стандарта (ISA), шину микроканальной архитектуры (MCA), расширенную шину ISA (EISA), локальную шину Ассоциации по стандартам в области видеоэлектроники (VESA) и шину взаимосвязи периферийных компонентов (PCI), также известную как шина расширения.

Вычислительная система 110 типично включает в себя множество машиночитаемых носителей. Машиночитаемым носителем может быть любой доступный носитель, к которому может осуществлять доступ вычислительная машина 110. Это может быть энергозависимый и энергонезависимый носитель, сменный и стационарный носитель. В качестве примера, но не ограничения, машиночитаемый носитель может включать в себя носитель хранения в вычислительной машине и носитель передачи данных. Носитель хранения в вычислительной машине включает в себя энергозависимый и энергонезависимый, сменный и стационарный носитель, реализованный по любому способу или технологии хранения такой информации, как машиночитаемые команды, структуры данных, программные модули и др. данные. Носитель хранения в вычислительной машине включает в себя, но не только, оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), электрически стираемое и программируемое ПЗУ (ЭСППЗУ), флэш-память или другую технологию памяти, ПЗУ на компакт-диске (диски CD-ROM), универсальные цифровые диски (DVD) или другое оптическое дисковое устройство хранения, магнитные дискеты, магнитную ленту, магнитооптические устройства хранения, запоминающее устройство на магнитном диске или другие магнитные устройства хранения, или любые другие носители, которые могут быть использованы для сохранения желаемой информации и которые могут быть доступны посредством вычислительной системы 110. Среда связи обычно воплощает машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированных сигналах данных, таких как сигнал несущей или другой механизм распространения, и включает в себя любую среду доставки информации. Термин "модулированный сигнал данных" означает сигнал, который имеет одну или более из его характеристик, установленных или изменяемых таким образом, чтобы кодировать информацию в сигнале. Для примера, но не только, среда связи включает в себя проводную среду, такую как проводная сеть или непосредственное проводное соединение, и беспроводную среду, такую как акустическая среда, радиочастота, инфракрасное излучение и другая беспроводная среда. Сочетания любого из вышеперечисленного также следует включить в число машиночитаемого носителя.

Системная память 130 включает в себя носитель хранения в вычислительной машине в виде энергозависимого и/или энергонезависимого запоминающего устройства, такого как ПЗУ 131 и ОЗУ 132. Базовая система 133 ввода/вывода (BIOS), содержащая в себе базовые процедуры, которые помогают передавать информацию между элементами в пределах вычислительной машины 110, к примеру во время запуска, обычно сохранена в ПЗУ 131. ОЗУ 132 обычно содержит данные и/или программные модули, которые непосредственно доступны и/или являются собственно выполняемыми блоком 120 обработки. В качестве примера, но не ограничения, фиг. 1 иллюстрирует операционную систему 134, прикладные программы 135, другие программные модули 136 и программные данные 137. ОЗУ 132 может содержать другие данные и/или программные модули.

Вычислительная машина 110 может также включать в себя другой съемный/стационарный, энергозависимый/энергонезависимый компьютерный носитель хранения. Только в качестве примера, фиг.1 иллюстрирует накопитель 141 на жестком диске, который считывает из или записывает на стационарный энергонезависимый магнитный носитель, накопитель 151 на магнитных дисках, который считывает из или записывает на съемный энергонезависимый магнитный диск 152, и накопитель 155 на оптических дисках, который считывает с или записывает на съемный энергонезависимый оптический диск 156, такой как CD-ROM, или другой оптический носитель. Другой съемный/стационарный, энергозависимый/энергонезависимый компьютерный носитель хранения, который может быть использован в примерном вычислительном окружении, включает в себя, но не только, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельное ОЗУ, твердотельное ПЗУ и подобное. Накопитель 141 на жестких дисках типично подключен к системной шине 121 посредством интерфейса стационарного запоминающего устройства, такого как интерфейс 140, а накопитель 151 на магнитных дисках и накопитель 155 на оптических дисках типично подключен к системной шине 121 посредством интерфейса съемного запоминающего устройства, таким как интерфейс 150.

Накопители и связанный с ним компьютерный носитель хранения, обсужденные выше и проиллюстрированные на фиг.1, предоставляют хранение машиночитаемых инструкций, структур данных, программных модулей, и других данных для вычислительной машины 110. На фиг.1, например, накопитель 141 на жестких дисках проиллюстрирован в качестве сохраняющего операционную систему 144, прикладные программы 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут либо быть такими же как или отличными от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 даны в настоящем документе с разными номерами, чтобы проиллюстрировать, что, как минимум, они являются различными другими копиями. Пользователь может вводить команды и информацию в вычислительную машину 110 посредством устройств ввода, например клавиатуры 162 и указательного устройства 161, обычно называемого мышью, шарового манипулятора или сенсорной панели. Другие устройства (не показаны) ввода могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер и т.п. Эти и другие устройства ввода часто подключены к блоку 121 обработки посредством пользовательского интерфейса 160 ввода данных, который соединен с системной шиной 521, однако могут быть подключены по другому интерфейсу и структурам шин, таким как параллельный порт, игровой порт или универсальная последовательная шина (USB).

Монитор 191 или другой тип дисплейного устройства также подключен к системной шине 121 посредством такого интерфейса, как видеоинтерфейс 190. Помимо монитора вычислительные машины могут также включать в себя другие периферийные устройства вывода, например, динамики 197 и принтер 196, которые могут быть подключены средствами периферийного интерфейса 195 вывода.

Вычислительная система 110 может работать в сетевом окружении, использующем логические соединения с одной или более удаленными вычислительными машинами, такими как удаленная вычислительная машина 180. Удаленной вычислительной машиной 180 может быть персональная вычислительная машина (ПЭВМ), сервер, маршрутизатор, сетевая персональная ЭВМ, одноранговое устройство или другой общий узел сети, и она типично включает в себя многие или все элементы, описанные выше относительно вычислительной машины 110, хотя на фиг.1 проиллюстрировано только запоминающее устройство 181 хранения. Логические соединения, показанные на фиг.1, включают в себя локальную вычислительную сеть (ЛВС) 171 и глобальную сеть (WAN) 173, но могут также включать в себя другие сети. Такие сетевые окружения являются обычными в офисах, корпоративных вычислительных сетях, сетях интранет (локальных сетях, использующих технологии Интернет) и Интернете.

При использовании в сетевом окружении ЛВС, вычислительная машина 110 подключена к ЛВС 171 посредством сетевого интерфейса или адаптера 170. Когда использована в сетевом окружении WAN, вычислительная машина 110 типично включает в себя модем 172 или другое средство установления обмена данными по WAN 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может быть подключен к системной шине 121 посредством пользовательского интерфейса 160 ввода или с использованием другого подходящего механизма. В сетевом окружении программные модули, показанные относительно вычислительной машины 110, или их части, могут быть сохранены на удаленном запоминающем устройстве хранения. В качестве примера, а не ограничения, фиг.1 иллюстрирует удаленные прикладные программы 185 как находящиеся на запоминающем устройстве 181 хранения. Должно быть очевидно, что показанные сетевые соединения являются примерными, и может быть использовано другое средство установления линии связи между вычислительными машинами.

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

Система и способ проверки контрольных примеров, которая неявно связана с исполнением контрольных примеров

Фиг.2 - это блок-схема системы 1 проверки (верификации) тестов для проверки контрольных примеров, которая не жестко связана с исполнением контрольных примеров в соответствии с одним вариантом осуществления изобретения. Система 1 может постоянно размещаться в вычислительной машине, которой может быть вычислительная машина 110, как описано относительно фиг.1. Система 1 может включать в себя одно или более из следующего: диспетчер 30 проверки, контрольный пример 20, блок 35 сравнения, структуру 36 данных ожидаемых состояний приложения, структуру 37 данных текущего состояния приложения и базу 31 данных. Система может включать в себя приложение 10, которое должно быть протестировано. Приложением 10 может быть любой процесс, машина, обработка или композиция либо любое их улучшение. Приложением 10 также может быть любая программа, программное обеспечение, устройство, механизм либо любое их улучшение. Например, приложением 10 может быть программа программного обеспечения, которая выполняется в любой вычислительной системе. Также, например, приложением 10 может быть механизм тестирования двери, в котором устройство стучит по дверной ручке, чтобы протестировать прочность, упругость или удобство использования дверной ручки, дверь, к которой прикреплена дверная ручка, петли, прикрепленные к двери, дверная коробка, к которой прикреплены петли и т.п. Приложение 10 может быть в разработке первый раз, обновленной версией прежнего приложения, ранее выпущенным приложением, которое пользователь каким-либо образом модифицировал, и т.п.

Приложение 10 может быть протестировано посредством одного или более контрольных примеров, представленных на фиг.2 контрольными примерами 20a, b, c…f и т.д. Контрольные примеры 20a-f могут быть вызваны для общего (интегрального) тестирования или функционального тестирования. Интегральное тестирование тестирует способ, которым два или более взаимодействующих компонента объединяются, работают вместе и влияют на друга. При функциональном тестировании контрольный пример ориентирован на конкретное функциональное поведение контрольного примера.

В общем, каждый контрольный пример 20a-f включает в себя четко определенное действие с четко определенными параметрами, которое должно быть применено к приложению 10. Контрольные примеры 20a-f могут каждый содержать один или несколько этапов, которые должны быть выполнены приложением 10. Каждый из контрольных примеров 20a-f может быть одним или последовательностью тестов, применяемых к приложению 10. Контрольные примеры 20a-f могут быть написаны на любом соответствующем языке программирования, таком как, например, C, C#, C++, Pascal, объектно-ориентированные языки и т.п. Контрольный пример 20a-f или комбинация контрольных примеров 20a-f может, например, предусматривать, чтобы графическое приложение начертило голубой прямоугольник на документе, который содержит другие формы различных цветов. Контрольные примеры 20a-f также могут быть не связанными с компьютерным языком программирования. Например, контрольный пример 20a может предусматривать ручное опускание 10-фунтовой киянки, висящей в четырех футах над и под углом 30° к дверной ручке, прикрепленной к двери. Следует понимать, что графическое приложение, приложение дверной ручки и любые другие примеры, предусмотренные в этой спецификации, никоим образом не ограничивают заданную в формуле область применения приложения, а наоборот, являются только иллюстративными вариантами осуществления, описанными для того, чтобы облегчить понимание.

Контрольные примеры 20a-f, показанные на фиг.2, каждый могут тестировать различный аспект приложения 10. Следует понимать, что контрольные примеры 20a-f просто представляют возможные контрольные примеры и что может быть любое число контрольных примеров 20a-f, чтобы протестировать приложение 10. Помимо этого, следует понимать, что каждый из контрольных примеров 20a-f может быть выполнен в одно и то же время или в разное время. Помимо этого, следует понимать, что, например, контрольный пример 20a может быть выполнен один раз, тогда как контрольный пример 20e может быть выполнен десять раз. Помимо этого, следует понимать, что контрольные примеры 20a-f могут быть выполнены тестирующими. В альтернативном варианте осуществления контрольные примеры могут быть выполнены блоком исполнения контрольных примеров или аналогичным устройством.

В примерном варианте осуществления изобретения контрольные примеры 20a-f могут быть в прямой связи с диспетчером 30 проверки. В альтернативном варианте осуществления изобретения контрольные примеры 20a-f могут вызывать другие подпрограммы, которые обмениваются данными с диспетчером 30 проверки. Контрольные примеры 20a-f могут не знать о том, как осуществляется проверка. Например, если многим контрольным примерам 20a-f требуется голубой прямоугольник, может быть написана подпрограмма, которая чертит голубой прямоугольник. Эта программа может обмениваться данными с диспетчером 30 проверки. Контрольные примеры 20a-f, использующие эту подпрограмму, должны знать, что подпрограмма чертит голубой прямоугольник, но не обязательно должны знать, что подпрограмма обменивается данными с диспетчером 30 проверки.

Диспетчер 30 проверки может включать в себя генераторы 32t-z ожидаемых состояний, блок 35 сравнения и структуры 36, 37 данных ожидаемых состояний приложения и текущего состояния приложения. Генератор ожидаемых состояний, например, каждый из генераторов 32t, u...z и т.д. ожидаемых состояний, может быть ассоциирован с одним или более конкретных компонентов, точек данных или свойств. Например, что касается тестирования графического приложения, в котором один, несколько или все контрольные примеры 20a-f предусматривают, чтобы приложение 10 начертило голубой прямоугольник в определенном положении, генераторы 32t-z ожидаемых состояний могут ориентироваться на различные компоненты состояния приложения. Генератор 32t ожидаемых состояний может ориентироваться на цвет прямоугольника. Генератор 32u ожидаемых состояний может ориентироваться на положение прямоугольника. Генератор 32v ожидаемых состояний может ориентироваться на наименее очевидные результаты выполнения контрольных примеров 20a-f, например, расположение треугольника в том же документе, где содержится только что начерченный голубой прямоугольник. Альтернативно, генераторы 32u, 32v ожидаемых состояний могут быть объединены в один или заменены одним генератором ожидаемых состояний (не показан), связанным с размещением любой формы в документе. Генератор 32w ожидаемых состояний может ориентироваться на состояние несвязанного параметра на панели инструментов, например параметра, чтобы открыть новый документ.

Также, например, если контрольные примеры 20a-f отдельно или совместно тестируют дверную ручку, прикрепленную к двери, посредством ударов по дверной ручке киянкой, то генератор 32t ожидаемых состояний может ориентироваться на возможность дверной ручки поворачиваться. Генераторы 32u и 32v ожидаемых состояний могут ориентироваться на верхнюю и нижнюю петлю, прикрепленную к двери, или могут быть объединены в один, или заменены одним генератором ожидаемых состояний (не показан), связанным с состоянием петли. Генератор 32w ожидаемых состояний может ориентироваться на деревянную часть двери, окружающую дверную ручку. Другие генераторы ожидаемых состояний могут ориентироваться на другие области приложения 10.

Все генераторы 32t-z ожидаемых состояний могут быть вызваны, когда один или более контрольных примеров 20a-f применяется к приложению 10, или может быть вызван только один или некоторые из генераторов 32t-z ожидаемых состояний. В одном примерном варианте осуществления генераторы 32t-z ожидаемых состояний могут выполняться независимо от и поэтому могут быть не жестко связанными с контрольными примерами 20a-f. Таким образом, контрольные примеры 20a-f не должны задавать диспетчеру проверки, какие генераторы 32t-z ожидаемых состояний должны быть вызваны в ходе применения контрольных примеров 20a-f. Контрольные примеры 20a-f в таком случае могут не содержать механизмов проверки. На самом деле, контрольные примеры 20a-f могут не знать, что должна быть осуществлена какая-либо проверка. Диспетчер 30 проверки может отвечать за проверку результатов контрольного примера 20a-f, и назначение контрольных примеров 20a-f может быть ограничено применением стимула с конкретными параметрами к приложению 10.

Тем не менее, специалисты в данной области техники признают, что контрольный пример может, без противоречий с примерным вариантом осуществления, содержать кодирование проверки. Это может иметь место в частности, если назначением выполнения контрольного примера 20a-f является определение, была ли решена конкретная проблема. В альтернативном варианте осуществления контрольный пример 20a-f может также указывать, чтобы был вызван один или более генераторов 32t-z ожидаемых состояний, и задавать, что некоторые генераторы 32t-z ожидаемых состояний не должны быть использованы.

При отделении проверки от контрольного примера 20a-f проверка может быть более всеобъемлющей для контрольного примера 20a-f. Диспетчер 30 проверки может включать в себя генераторы 32t-z ожидаемых состояний, которые ранее, возможно, были частью отдельных контрольных примеров. Например, диспетчер 30 проверки может содержать генераторы 32t-z ожидаемых состояний контрольных примеров 20a-f предшествующего уровня техники, предназначенных, чтобы тестировать возможность графического приложения чертить голубой квадрат, красный круг, желтый треугольник или овал, чтобы использовать параметр в раскрывающемся меню, чтобы отвечать на различный ввод данных пользователем посредством мыши или клавиатуры и т.п. Каждый из этих контрольных примеров должен иметь включенной конкретную проверку, ориентированную на назначение действий контрольного примера. С помощью специального диспетчера 30 проверки, содержащего генераторы 32 ожидаемых состояний, контрольный пример 20a-f для черчения голубого прямоугольника в графическом приложении может быть проверен более всеобъемлюще. Диспетчер 30 проверки может вызывать генераторы 32 ожидаемых состояний, которые характерны для голубого прямоугольника, красного квадрата, желтого треугольника, раскрывающегося меню, ввода данных с помощью мыши или клавиатуры и т.п. Таким образом, контрольный пример 20a-f, который предусматривает черчение голубого прямоугольника, может задавать, чтобы генераторы 32t-z ожидаемых состояний проверили очевидные и неочевидные воздействия контрольного примера 20a-f на приложение 10. Тестирующий может даже не знать, например, что проверяется красный круг, когда чертится голубой прямоугольник. Если результаты тестирования таковы, что красный круг остался незатронутым контрольным примером 20a-f и если это было ожидаемым результатом, то тестирующий и/или контрольный пример может не знать, что красный круг был проверен. Тем не менее, если красный круг неожиданно слегка передвинулся, то диспетчер 30 проверки может оповестить тестирующего, что получен неожидаемый результат.

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

Помимо этого, проверка контрольных примеров 20a-f может оставаться по большей части незатронутой, если приложение 10 изменено, обновлено и т.п. Могут быть созданы новые версии приложения 10, которые могут изменять способ, которым работает приложение 10. Следовательно, может потребоваться изменить контрольный пример 20. Например, контрольный пример 20a-f для тестирования графического приложения может потребовать пересмотра того, как он предусматривает черчение голубого прямоугольника. Также, например, контрольный пример 20a-f для тестирования дверной ручки, прикрепленной к двери, может потребовать изменить вес и высоту киянки, если новая дверная ручка, которая должна быть протестирована, имеет большую упругость, чем предыдущие версии. Тем не менее, генераторы 32 ожидаемых состояний могут не потребоваться быть измененными. В примере с графическим приложением генераторы 32 ожидаемых состояний могут продолжить проверять размещение нового голубого квадрата и имеющегося красного круга, желтого треугольника и овала аналогичным способом, поскольку до этого было изменено приложение 10. Также, генераторы 32 ожидаемых состояний могут проверять дверную ручку, дверь, петли и дверную коробку аналогичным способом, поскольку до этого новая дверная ручка была добавлена, и контрольный пример 10 модифицирован.

Генераторы 32t-z ожидаемых состояний могут обмениваться данными посредством диспетчера 30 проверки с базой 31 данных. База 31 данных может предоставлять информацию генераторам 32 ожидаемых состояний, чтобы генераторы ожидаемых состояний могли лучше определять ожидаемое состояние приложения 10 из контрольного примера 20. Например, контрольный пример 20a-f может повлечь за собой удар по дверной ручке, прикрепленной к двери, с помощью киянки. Генератор 32a ожидаемых состояний может определять воздействие контрольного примера на латунную петлю толщиной 1/8 дюйма и длиной 2 дюйма, прикрепленную к двери. При этом генератор 32a ожидаемых состояний может запросить базу 31 данных извлечь информацию, касающуюся, например, предела прочности латуни на разрыв. В альтернативном варианте осуществления генератор 32 ожидаемых состояний может поддерживать обмен данными с одной или более баз 31 данных независимо от диспетчера 30 проверки. Альтернативно, каждый генератор 32 ожидаемых состояний может извлекать или принимать информацию от подключаемого компонента.

Генераторы 32t-z ожидаемых состояний могут поддерживать обмен данными с блоком 35 сравнения. Как показано на фиг.2, блок 35 сравнения может быть частью диспетчера 30 проверки. Тем не менее, специалисты в данной области техники признают, что блок 35 сравнения может быть размещен вне диспетчера проверки. В этом случае блок сравнения может поддерживать обмен данными с диспетчером 30 проверки и/или с генераторами 32 ожидаемых состояний. Блок 35 сравнения может сравнивать структуру 36 данных ожидаемых состояний со структурой 37 данных фактических состояний.

Более конкретно, когда один или более контрольных примеров 20a-f предполагаются быть выполненными, контрольные примеры 20a-f или блок исполнения тестов может уведомить диспетчер 30 проверки. Диспетчер 30 проверки может сделать мгновенный «снимок» текущего глобального состояния приложения. Т.е. диспетчер проверки может сделать копию в памяти текущих значений свойств приложения. После этого диспетчер 30 проверки может уведомить генераторы 32 ожидаемых состояний о находящихся в ожидании контрольных примерах 20, которые должны быть выполнены. В примерном варианте осуществления только эти генераторы 32 ожидаемых состояний, которые могут быть привлечены в контрольный пример 20a-f, могут быть уведомлены. В альтернативном варианте осуществления могут быть уведомлены все генераторы 32 ожидаемых состояний.

На основе действия и параметров действия, которое предполагается быть выполненным, и сделанного диспетчером проверки снимка текущего глобального состояния каждый генератор 32 ожидаемых состояний вычисляет ожидаемое результирующее состояние по отношению к компоненту приложения из предполагаемого исполнения контрольных примеров 20a-f для приложения 10. Например, если приложением 10 является графическое приложение, а контрольные примеры 20a-f совместно требуют черчения голубого прямоугольника, то каждый генератор 32 ожидаемых состояний определяет ожидаемое состояние приложения по отношению к этому действию. Генератор 32t ожидаемых состояний может определить, что результат должен включать в себя прямоугольник. Генератор 32u ожидаемых состояний может определить, что прямоугольник должен быть голубым. Генератор 32v ожидаемых состояний может быть ориентирован на красный круг независимо от прямоугольника и может определить, что его ожидаемое состояние должно оставаться неизмененным посредством контрольного примера 20. Каждый генератор ожидаемых состояний передает это ожидаемое состояние компонента диспетчеру 30 проверки, и диспетчер 30 проверки может помещать данные в структуру 36 данных ожидаемых состояний приложения блока 35 сравнения. Таким образом, диспетчер 30 проверки может иметь глобальное ожидаемое состояние приложения до выполнения контрольных примеров 20a-f. Помимо этого, это означает, что глобальное ожидаемое состояние приложения может быть определено в любое время или по запросу. Ожидаемые результаты исполнения контрольного примера 20a-f могут быть детерминированными. Альтернативно, ожидаемые результаты могут быть не детерминированными, если генераторы 32t-z ожидаемых состояний понимают, что не детерминированные результаты допустимы.

После завершения контрольного примера 20 диспетчер 30 проверки может сделать другой снимок или копию в памяти текущих значений свойств приложения. Этот снимок позволяет показать текущее глобальное состояние приложения. Текущее значение свойств может быть сохранено в структуре 37 данных текущего состояния приложения. Блок 35 сравнения после этого сравнивает структуру 36 данных ожидаемых состояний приложения со структурой 37 данных текущего состояния приложения. Любые расхождения указывают области, дополнительное внимание к которым может быть оправдано. В альтернативном варианте осуществления структуры 35, 36 данных могут быть отправлены соответствующему передающему устройству для проведения сравнения. Например, сравнение может быть осуществлено посредством использования расширенного языка разметки (XML).

Расхождения между структурами 36, 37 данных текущего и ожидаемых состояний приложения могут оповещать тестирующего и результат в альтернативных заключениях. Расхождения между структурами данных текущего и ожидаемых состояний приложения могут указывать области, в которых приложение 10 не действует надлежащим образом. В таких случаях, например, может потребоваться отладка исходного кода или изменение структуры материала. Т.е., например, если контрольный пример 20a-f был предназначен, чтобы иметь следствием черчение голубого квадрата, и вместо этого контрольный пример 20a-f имел следствием начерченный красный квадрат, то тестирующий может быть склонен исправить приложение 10 и повторно запустить контрольный пример 20a-f. Если тестирующий не является человеком, разрабатывающим приложение, то тестирующий может уведомить разработчика о неправильном поведении - красном квадрате - посредством регистрации ошибки в системе отслеживания ошибок, отправки электронной почты, посещения офиса разработчика или используя какую-либо другую систему уведомления. Также, например, если контрольный пример 20a-f был предназначен, чтобы иметь следствием дверную ручку, которая продолжила работать, а вместо этого киянка, которой ударяют по дверной ручке, разбила дверную ручку двери, то тестирующий может быть склонен использовать более прочные крепежи, чтобы прикрепить дверную ручку к двери. Альтернативно, если тестирующий не изготавливает дверь, то тестирующий может порекомендовать изготовителю двери, чтобы были использованы более прочные крепежи.

Расхождения могут также указывать, что ожидаемое состояние приложения генератора 32 ожидаемых состояний было нереалистичным. В этом случае может быть оправдано изменение в генераторе 32 ожидаемых состояний. Например, приложением 10, которое должно быть протестировано, может быть графическое приложение. Один или более контрольных примеров 20a-f могут включать в себя черчение прямоугольника с помощью мыши. Затем один или более генераторов 32 ожидаемых состояний могут ожидать, что должен быть начерчен идеальный прямоугольник. Если черчение идеального прямоугольника с помощью мыши не является реальной возможностью в приложении 10, блок 30 сравнения может указать, что тест прошел неудачно из-за не идеальности получившегося прямоугольника. Тестирующий в таком случае может добавить допустимое отклонение в генераторы 32 ожидаемых состояний, чтобы разрешить ожидаемое состояние приложения, содержащее по существу прямоугольный, но не совершенно идеальный прямоугольник.

В примерном варианте осуществления генераторы 32 ожидаемых состояний могут определять ожидаемое состояние не только на основе действий и параметров, предписываемых в контрольном примере 20a-f, но также на основе текущего состояния приложения. Это дает возможность диспетчеру 30 проверки принимать во внимание предыдущие сбои при выполнении контрольных примеров и определять ожидаемое состояние на основе этих сбоев. Например, контрольный пример 20a-f может повлечь за собой удар по дверной ручке, прикрепленной к двери посредством киянки. Если при исполнении контрольного примера петля, прикрепленная к двери, повреждается, то проверки петли в будущих контрольных примерах 20a-f может не показывать сбой на основе предыдущего повреждения. Вместо этого диспетчер 30 проверки может определять ожидаемое состояние петли, принимая во внимание предыдущее повреждение.

Фиг.3A иллюстрирует блок-схему примерного способа выполнения слабо связанной проверки. Способ 200 проверки (верификации) может начаться на этапе 205 с контрольного примера 20a-f. В альтернативном варианте осуществления блок выполнения контрольного примера может отправлять событие начала диспетчеру проверки или вызывать диспетчер 30 проверки. Начиная с этого начального события или вызова, диспетчер 30 проверки может быть уведомлен о находящемся в состоянии ожидания контрольном примере 20. Контрольный пример 20a-f может включать в себя четко определенные действия, которые будут приложены к приложению 20a-f, включая параметры действия. После уведомления диспетчер 30 проверки может сделать снимок текущего глобального состояния. На этапе 210 диспетчер 30 проверки может определить, какие генераторы 32 ожидаемых состояний могут быть вовлечены в находящийся в состоянии ожидания контрольный пример 20a-f и уведомить применимые генераторы 32 ожидаемых состояний. Альтернативно, диспетчер 30 проверки может уведомить все генераторы 32 ожидаемых состояний о находящемся в состоянии ожидания контрольном примере 20a-f. На этапе 215 генераторы 32 ожидаемых состояний рассматривают применимые действия и параметры контрольного примера 20a-f. На основе текущего значения свойств своего компонента или компонентов генераторы ожидаемых состояний могут вычислить ожидаемое состояние компонента, ожидаемое после осуществления контрольного примера 20. Каждый уведомленный генератор 32 ожидаемых состояний затем может отправить свое ожидаемое состояние компонента диспетчеру 30 проверки. Эти данные могут быть сохранены в структуре 36 данных ожидаемых состояний приложения блока 35 сравнения. Когда все применимые генераторы 32 ожидаемых состояний сообщили данные об ожидаемом состоянии компонента, диспетчер 30 проверки будет иметь (на этапе 220) глобальное ожидаемое состояние приложения. Диспетчер 30 проверки после этого может на этапе 225 уведомить контрольный пример 20a-f или блок выполнения тестов о том, что контрольный пример 20 может быть выполнен. Контроль тем самым передан обратно контрольному примеру 20a-f (или блоку исполнения тестов). На этапе 230 контрольный пример 20a-f может быть выполнен.

Фиг.3B продолжает блок-схему фиг.3A. На этапе 235 контрольный пример 20a-f может быть выполнен, обновляя глобальный снимок. После осуществления контрольного примера 20 диспетчер 30 проверки на этапе 240 может быть уведомлен о том, что контрольный пример 20a-f был завершен. На этапе 245 диспетчер 30 проверки может сделать снимок текущего состояния приложения. Этот снимок может отражать фактические результаты контрольного примера для приложения. Этот снимок также может представлять значение свойств приложения. Диспетчер 30 проверки может сохранять снимок в структуре 37 данных текущего состояния приложения на этапе 250. После этого диспетчер 30 проверки на этапе 255 может сравнить данные по ожидаемому и текущему состоянию приложения и на этапе 260 сообщить о результатах полного сравнения или любые результаты, в которых ожидаемые и текущие значения свойств большей частью различаются. В альтернативном варианте осуществления изобретения снимки ожидаемого и текущего состояния могут быть осуществлены в ходе выполнения контрольного примера. Т.е. все или некоторые этапы 210-260 могут быть выполнены несколько раз в рамках контрольного примера.

Сравнение структур 36, 37 данных ожидаемых и текущего состояний может быть осуществлено в диспетчере 30 проверки. Альтернативно, структуры данных могут быть переданы последовательно в XML, чтобы сравнение могло быть осуществлено с помощью XML. В таких случаях XML может сравнить структуры 36, 37 данных и отправить результаты в диспетчер 30 проверки, контрольный пример 20 или блок исполнения контрольного примера. В альтернативном варианте осуществления изобретения блок 35 сравнения может быть отделен от процесса исполнения контрольного примера. Это разделение дает возможность, чтобы сравнение между ожидаемыми и текущим состояниями приложения было осуществлено во время, не связанное с исполнением контрольного примера. В таком случае данные ожидаемых и текущего состояний могут быть сохранены в базу данных или другое устройство хранения данных или сохранены в памяти вычислительной машины.

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

Следует понимать, что если один и тот же контрольный пример 20a-f выполнен снова или если выполнен другой контрольный пример 20a-f, все этапы способа 200, показанные на фиг. 3A-3B, могут не потребоваться. Например, диспетчер 30 проверки может содержать в блоке 35 сравнения структуру данных ожидаемых состояний для находящегося в состоянии ожидания контрольного примера 20. В таком случае диспетчеру 30 проверки может не потребоваться получать данные ожидаемого состояния компонента от генераторов 32 ожидаемых состояний до того, как выполняется контрольный пример 20a-f. Поэтому не все этапы способа 200 должны быть осуществлены каждый раз, когда выполняется контрольный пример 20a-f.

Фиг.4 - это блок-схема примерной системы проверки (верификации) контрольных примеров, которая слабо связана с исполнением контрольных примеров в соответствии с альтернативным вариантом осуществления изобретения. В этом альтернативном варианте осуществления один или более контрольных примеров 20a-f могут быть применены к приложению 10. Как пояснялось выше, контрольный пример 20a-f может быть интегральным контрольным примером или функциональным контрольным примером. В общем, каждый контрольный пример 20a-f имеет четко определенный стимул с четко определенными параметрами, который должен быть применен к приложению 10. Контрольные примеры 20a-f могут, каждый, содержать этап или множество этапов, которые должны быть выполнены приложением 10. Каждый из контрольных примеров 20a-f может быть одним или последовательностью тестов, на которых работает приложение 10. Диспетчер 30 проверки может содержать блок 35 сравнения со структурами 36, 37 данных ожидаемых и текущего состояний приложения. Как пояснялось выше, следует понимать, что блок 35 сравнения может быть отдельным и поддерживать обмен данными с диспетчером 30 проверки. Помимо этого, генераторы 32x-z ожидаемых состояний могут быть отдельными от диспетчера 30 проверки. Генераторы 32 ожидаемых состояний могут поддерживать обмен данными с диспетчером 30 проверки. Функция генераторов 32 ожидаемых состояний и диспетчера 30 проверки может быть аналогична или идентична описанной относительно фиг.2. Компонент, на который может быть ориентирован каждый генератор 32t-z ожидаемых состояний, может быть точкой данных в приложении 10. Точка данных может быть значением свойства и поэтому каждый генератор 32t-z ожидаемых состояний может предоставлять диспетчеру 30 проверки ожидаемое значение свойства перед исполнением контрольного примера. Помимо этого, генераторы 32 ожидаемых состояний могут содержать другие генераторы 32 ожидаемых состояний. Генераторы 32 ожидаемых состояний могут поддерживать обмен данными с диспетчером 30 проверки. Более того, генераторы 32 ожидаемых состояний могут поддерживать обмен данными с одной или более базами 31a-b данных, которые могут быть подключаемыми компонентами.

Например, если контрольный пример 20a-f влечет за собой удар по дверной ручке, прикрепленной к двери, с помощью киянки, генератор 32x ожидаемых состояний может определить ожидаемое состояние петли, которая прикреплена к двери. При этом генератор 32x ожидаемых состояний может вызвать генератор 32x1 ожидаемых состояний, чтобы сообщить о нижней части петли. Также, генератор 32x ожидаемых состояний может вызвать генератор 32x2 ожидаемых состояний, чтобы сообщить о верхней части петли. Генератор 32x ожидаемых состояний может объединять данные при определении ожидаемого состояния и отправлять объединенные данные в надлежащие моменты времени диспетчеру 30 проверки. Помимо этого, если генератор 32x ожидаемых состояний должен определить воздействие теста на латунную петлю толщиной 1/8 дюйма и длиной 2 дюйма, прикрепленную к двери, генератор 32x ожидаемых состояний может запросить базу 31a данных извлечь информацию, касающуюся, например, предела прочности латуни на разрыв.

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

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

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

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

2. Система по п.1, в которой множество генераторов ожидаемых состояний определяет множество ожидаемых состояний приложения до исполнения действия.

3. Система по п.1, в которой множество генераторов ожидаемых состояний определяет множество ожидаемых состояний приложения по запросу.

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

5. Система по п.4, в которой множество генераторов ожидаемых состояний являются внешними по отношению к диспетчеру проверки.

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

7. Система по п.1, дополнительно содержащая контрольный пример, поддерживающий обмен данными и независимый от диспетчера проверки, для исполнения действия.

8. Система по п.1, в которой действие содержит
стимул и
параметр.

9. Система по п.1, в которой действие - это, по меньшей мере, одно из функционального теста и интегрального теста.

10. Система по п.1, дополнительно содержащая структуру данных ожидаемых состояний приложения и структуру данных текущего состояния приложения.

11. Система по п.10, в которой структура данных ожидаемых состояний приложения содержит информацию, принятую от множества генераторов ожидаемых состояний.

12. Система по п.10, в которой структура данных текущего состояния приложения содержит информацию, принятую от диспетчера проверки.

13. Система по п.1, в которой диспетчер проверки сравнивает множество ожидаемых состояний приложения с множеством текущих состояний приложения в автономном режиме.

14. Система по п.1, в которой диспетчер проверки сравнивает множество ожидаемых состояний приложения с множеством текущих состояний приложения в оперативном режиме.

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

16. Система по п.1, в которой диспетчер проверки выдает уведомление о сравнении множества ожидаемых состояний приложения с множеством текущих состояний приложения.

17. Система по п.16, в которой уведомление осуществляется в автономном режиме.

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

19. Способ по п.18, дополнительно содержащий этап, на котором создают копию множества исходных текущих состояний.

20. Способ по п.18, дополнительно содержащий этап, на котором принимают множество ожидаемых состояний компонента для множества компонентов приложения.

21. Способ по п.20, в котором множество ожидаемых состояний компонента сохраняют в структуре данных ожидаемых состояний приложения.

22. Способ по п.20, в котором множество ожидаемых состояний компонента определяется диспетчером проверки.

23. Способ по п.22, в котором множество генераторов ожидаемых состояний является внешним по отношению к диспетчеру проверки.

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

25. Способ по п.18, в котором этап сравнения осуществляется с помощью XML.

26. Способ по п.18, в котором этап сохранения множества текущих состояний приложения осуществляется после того, как применено действие.

27. Способ по п.18, в котором этап сохранения множества ожидаемых состояний приложения осуществляется до того, как применено действие.

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

29. Способ по п.28, в котором множество ожидаемых состояний приложения и множество текущих состояний приложения относятся к состояниям компонентов приложения.

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

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

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

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