РАЗДЕЛЕНИЕ НА УРОВНИ СТЕКА АВТОМАТИЗАЦИИ ТЕСТОВ Российский патент 2010 года по МПК G06F13/00 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Эта заявка связана с патентной заявкой США Attorney Docket Number MSFT-4148, называющейся «System for Selecting Test Case Execution Behaviors for Reproducible Test Automation», поданной с этой, и патентной заявкой США Attorney Docket Number MSFT-4149, названной «Automated Test Case Verification That Is Loosely Coupled With Respect To Automated Test Case Execution», поданной с этой.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

фиг.3 является более детальной блок-схемой части системы фиг.2 в соответствии с одним вариантом воплощения изобретения, и

фиг.4 является блок-схемой примерного способа использования автоматизированной системы тестирования программного обеспечения фиг.2 в соответствии с одним вариантом воплощения изобретения.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Краткий обзор

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

Щелчок на меню File, щелчок на подменю New, после этого щелчок на пункте меню New Document.

Набрать Alt+F для вызова меню File, набрать N для вызова подменю New, после этого набрать N для вызова пункта меню New Document.

Набрав Alt для вызова главного меню неоднократным нажатием клавиши «стрелка влево» до выбора меню File, неоднократно нажать клавишу «стрелка вниз», пока не будет выбран пункт подменю New, нажать клавишу «стрелка влево» один раз для того, чтобы развернуть подменю New, неоднократно нажать клавишу «стрелка вниз», пока пункт меню New Document не будет выбран, затем нажать Enter для вызова пункта меню New Document.

Вызвав пункт меню New Document через API программного обеспечения для людей с ограниченными возможностями.

Щелкнув кнопкой New Document панели.

Вызвав кнопку панели New Document через API программного обеспечения для людей с ограниченными возможностями.

Набрав Ctl+N.

Выполнив метод сценария объектной модели, который создает новый документ.

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

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

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

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

Автоматизированные тестовые примеры обычно очень сильно привязаны к специфической части проверяемого программного обеспечения, то есть типичный тестовый пример кодируется непосредственно для объекта, который он проверяет. Например, автоматизированное тестирование приложения с помощью тестовых примеров часто непосредственно управляет состоянием приложения. Тестовые примеры для автоматизированного тестирования интерфейса пользователя (UI) часто пишутся непосредственно для одного или более управляющих элементов UI и идентифицируют управляющий элемент(ы) явным кодированием названия или уникального идентификатора управляющего элемента(ов) в тестовых примерах. Если управляющий элемент изменяется (например, от кнопки к списку или даже от одной кнопки (например, кнопка 36) к другой кнопке (например, кнопка 42)), все тестовые примеры для UI должны быть изменены.

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

Логический уровень может обеспечить представление приложения, основанного на действиях, которые могут быть предприняты (например, действие «открыть документ»), а не определенные детали интерфейса пользователя (например, «откройте меню File и щелкните Open, ждите открытия диалогового окна File Open, введите имя файла для открытия, нажмите OK, ждите исчезновения диалогового окна File Open, ждите приложение для открытия документа и будьте готовым к дальнейшему вводу»). Логический уровень также сильно абстрагирует такое большое знание, как реальность UI, так что тестам, написанным в логическом уровне, не требуется редактирование, если UI изменится. Логический уровень также может привнести разнообразие для различных физических способов выполнения так, чтобы единственное тестирование, написанное на логическом уровне, могло быть выполнено с помощью мыши, клавиатуры и т.д., не требуя делать какие-либо изменения в тестовом примере.

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

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

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

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

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

Примерная компьютерная среда

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

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

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

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

Компьютер 110 обычно включает разнообразные читаемые компьютерные носители информации. Читаемые компьютерные носители информации могут быть любыми доступными носителями, к которым можно обратиться компьютером 110, и включают энергозависимые и энергонезависимые носители, сменные и несменные носители. В качестве примера, но не ограничения читаемые компьютерные носители могут включать компьютерные носители данных и коммуникационные носители. Компьютерные носители данных включают и энергозависимые и энергонезависимые, сменные и несменные носители, осуществленные любым способом или технологией для хранения информации типа читаемых компьютером команд, структур данных, программных модулей или других данных. Компьютерные носители данных включают, но не ограничены этим, оперативную память (RAM), постоянную память (ROM), электронно-перепрограммируемую постоянную память (EEPROM), флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другую оптическую память на диске, магнитные кассеты, магнитную ленту, магнитную память на диске или другие магнитные запоминающие устройства или любой другой носитель информации, который может использоваться для хранения желаемой информации и к которому можно обратиться компьютером 110. Коммуникационные носители обычно воплощают читаемые компьютерные команды, структуры данных, программные модули или другие данные в модулируемом сигнале данных типа несущей или другом транспортном механизме и включают любые доставляющие информационные носители. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или более из его набора характеристик, измененных таким способом, чтобы кодировать информацию в сигнале. В качестве примера, но не ограничения коммуникационные носители включают проводные носители типа проводного сетевого или непосредственного подключения и беспроводные носители типа акустического, радиочастотного, инфракрасного и других беспроводных носителей информации. Комбинации любого из упомянутых выше должны быть также включены в читаемые компьютерные носители информации.

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

Компьютер 110 может также включать другие сменные/несменные, энергозависимые/энергонезависимые компьютерные носители данных. Только в качестве примера фиг.1 иллюстрирует жесткий диск 141, который читает или пишет на несменные энергонезависимые магнитные носители, дисковод 151 магнитных дисков, который читает или пишет на сменный энергонезависимый магнитный диск 152, и оптический дисковод 155, который читает или пишет на сменный энергонезависимый оптический диск 156 типа CD-ROM или другие оптические носители. Другие сменные/несменные, энергозависимые/энергонезависимые компьютерные носители данных, которые могут использоваться в примерной среде, включают, но не ограничены этим, кассеты магнитной ленты, платы флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельную оперативную память, твердотельную 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 позиционирования, обычно представляющее собой мышь, шаровой манипулятор или сенсорную панель. Другие устройства ввода (не показанные здесь) могут включать микрофон, джойстик, игровую панель, спутниковую антенну, сканер или подобное этому. Эти и другие устройства ввода часто соединяются с процессорным модулем 120 через интерфейс 160 пользовательского ввода, который подсоединен к системной шине 121, но может быть соединен с помощью другого интерфейса и шинной структуры, такой как параллельный порт, игровой порт или универсальная последовательная шина (USB).

Монитор 191 или другой тип устройства отображения также связан с системной шиной 121 через интерфейс типа видеоинтерфейса 190. Графический интерфейс 182 типа Northbridge (северный мост, часть набора системных микросхем) может также быть связан с системной шиной 121. Northbridge является набором микросхем, который взаимодействует с центральным процессором или ведущим процессорным модулем 120 и отвечает за связь с ускоренным графическим портом (AGP). Один или более графических процессоров 184 (GPU) могут взаимодействовать с графическим интерфейсом 182. В этом отношении GPU 184 вообще включают память на чипе типа регистровой памяти, и GPU 184 взаимодействует с видеопамятью 186. GPU 184, однако, является всего лишь одним примером сопроцессора, и, таким образом, разнообразные устройства совместной обработки могут быть включены в компьютер 110. Монитор 191 или другой тип устройства отображения также связан с системной шиной 121 через интерфейс типа видеоинтерфейса 190, который может, в свою очередь, подсоединяться к видеопамяти 186. В добавление к монитору 191 компьютеры могут также включать другие периферийные устройства вывода типа динамиков 197 и принтера 196, которые могут быть подсоединены к внешнему устройству вывода с помощью интерфейса 195.

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

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

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

Стек автоматизации многоуровневой архитектуры

В некоторых вариантах воплощения изобретения приложение определяется через логическую функциональную модель, которая использует фокусируемое на пользователе представление приложения, в отличие от представления объектной модели или другого типа представления. Код, который используется много раз, может быть разделен на компоненты фокусируемым на пользователе способом. Например, действия могут быть сгруппированы по целям: на логическом уровне SceneElements может содержать способы, которые затрагивают набор элементов на активной сцене типа элементов Create, Select, Deselect, Cut, Copy, Paste, Delete. Группа методов Transforms может иметь методы для вращения, масштабирования и преобразований иным способом для элементов сцены. Путь может содержать методы управления элементами сцены, которые являются путями, и так далее. В большинстве приложений большинство пользовательских действий может быть выполнено множеством различных способов. Инфраструктура, требуемая для различных путей выполнения, обычно идентична. Следовательно, в некоторых вариантах воплощения изобретения менеджер поведения выполнения является общим для тестовых примеров и выбирает соответствующее поведение (метод логической функциональной модели) для тестового примера. В некоторых вариантах воплощения изобретения прежде чем тестовый пример или метод логической функциональной модели выполнит операцию, уведомляется менеджер проверки. Менеджер проверки может сохранить копию законченного текущего состояния приложения. Эта копия формирует основу ожидаемого состояния, когда операция закончена. В некоторых вариантах воплощения изобретения тестовый пример выполняет последовательность действий без знания того, как действия выполняются или проверяются.

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

Автоматизированная тестовая система 250 может постоянно находиться на одном или более компьютерах типа примерного компьютера 110, описанного по отношению к фиг.1. Автоматизированная тестовая система 250 может включать одну или более: тестовую управляющую программу 252, менеджер данных 254, менеджер поведения 256 и связанный банк данных поведений (не показанный здесь), менеджер проверки 258 и стек 200 автоматизации. Тестовая управляющая программа 252 может выполнить тестовый пример 260 для приложения 262. Менеджер данных 252 в некоторых вариантах воплощения изобретения может предоставить тестовые данные, требуемые тестовым примером 260. Менеджер данных может предоставить доступ к централизованному хранилищу всех тестовых данных и позволить производить изменения в тестовых данных способом, при котором тестовые данные генерируются, требуя минимального или не требуя никаких изменений в тестовых примерах.

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

Фиг.3 является блок-схемой, иллюстрирующей примерную многоуровневую архитектуру стека автоматизации автоматизированной тестовой системы в соответствии с одним вариантом воплощения изобретения. Фиг.3 является более детальной блок-схемой части системы фиг.2. На фиг.3 библиотека 200 автоматизации может включать один или более уровней. Каждый уровень библиотеки 200 автоматизации может включать один или более наборов объектов. Уровни библиотеки 200 автоматизации могут включать один или более: физический уровень 202, логический уровень 204, один или более тестовых примеров на уровне тестового примера 206, уровень 208 всесторонней проверки, уровень 210 поведения и уровень 213 менеджера данных. Уровень 210 поведения может включить менеджера 212 поведения выполнения и банк 214 данных поведения выполнения. Альтернативно поведение выполнения может постоянно находиться на логическом уровне 204.

Библиотека 200 автоматизации может включать один или более из физического уровня 202, логического уровня 204 и один или более тестовых примеров на уровне 206 тестового примера, в то время как уровень 210 поведения выполнения, уровень 208 всесторонней проверки и уровень 213 менеджера данных могут существовать внешне к архитектурному стеку 230 автоматизации. В некоторых вариантах воплощения изобретения уровень 210 поведения выполнения, уровень 208 всесторонней проверки и уровень 213 менеджера данных либо отделены от логического уровня 204, либо интегрированы в логический уровень 204. Поскольку уровень 210 поведения выполнения, уровень 208 всесторонней проверки и уровень 213 менеджера данных являются отделенными от логического уровня 210, к уровню 210 поведения выполнения, уровню 208 всесторонней проверки и уровню 213 менеджера данных можно обратиться снаружи архитектурного стека.

Библиотека 200 автоматизации может представлять уровень системной библиотеки, включающей один или более компонентов, включающих, например, одно или более: операционную систему, внешние инструментальные средства, графическую подсистему анимации и т.д. На фиг.2 примерная системная библиотека 240 включает внутренний тестовый модуль 216 автоматизации, модуль 218 программного обеспечения для людей с ограниченными возможностями, модуль 222 автоматизации UI, графическую подсистему 228 анимации (включающую модель графического объекта 220 анимации и графическое анимационное приложение 224) и приложения системного уровня.

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

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

Каждый уровень библиотеки автоматизации 200 имеет прямой доступ (может делать запросы) к нижнему уровню. То есть уровень 206 тестового примера имеет прямой доступ к логическому уровню 204. Логический уровень 204 имеет прямой доступ к физическому уровню 202 и так далее. В некоторых вариантах воплощения изобретения существует средство, предназначенное для обращения к уровню или для запроса к более глубокому уровню, то есть, например, для тестового примера может быть возможно непосредственно обратиться к внутреннему уровню 216 тестовой автоматизации, физическому уровню 202 и так далее, когда желательно сделать так.

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

Запустить графическую подсистему анимации

Добавить новый проект

Рисовать прямоугольник от 0,0 до 4,4

Установить цвет прямоугольника в красный

Сохранить проект

Завершить графическую подсистему анимации

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

В некоторых вариантах воплощения изобретения логический уровень 202 направлен на функции, которые приложение, как предполагается, исполняет, а не на то, какие операции каждой функции осуществляются. Логический уровень 202 может формировать или скрывать в себе логические операции графической подсистемы 228 анимации, абстрагируя реализацию деталей логических операций. В некоторых вариантах воплощений изобретения логический уровень 202 абстрагирует практически все знание UI и обеспечивает интерфейс между тестовым примером уровня 206 тестового примера и уровня проверки 208, уровня поведения 210 и уровня 213 менеджера данных. Логический уровень 202 может также обеспечить интерфейс между графическим объектом 220 модели анимации (внутреннее состояние графического приложения 224 анимации) и тестовым примером. Логический уровень может обеспечить изменчивость по последовательности действий, используемых для выполнения отдельных пользовательских действий.

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

Другой примерный тестовый пример, написанный на физическом уровне, может быть, например:

Запустить графическую подсистему анимации

Вызвать меню File

Вызвать подменю New

Вызвать пункт меню New Project

Напечатать название для нового проекта

Закрыть диалоговое окно New Project

Ждать от графической подсистемы анимации завершения создания нового проекта

Активизировать инструмент рисования прямоугольника

Перетащить мышь от 0,0 до 4,4

Выбрать «Red» от списка возможных штриховых цветов в области окна свойств цвета

Вызвать меню File

Вызвать пункт меню Save

Ждать от графической подсистемы анимации завершения сохранения проекта

Вызвать меню File

Вызвать пункт меню Exit

Ждать от графической подсистемы анимации завершения

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

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

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

Уровень 208 всесторонней проверки в некоторых вариантах воплощения изобретения формирует обработку проверки. Логический уровень 204 в некоторых вариантах воплощения изобретения уведомляет уровень проверки 208 перед тем, как логический уровень 204 выполнит тестовый пример, чтобы дать возможность уровню 208 проверки взять снимок состояния перед тестом. После того как тестовый пример выполнен, логический уровень 204 уведомляет уровень 208 проверки, что тестовый пример был выполнен. Уровень 208 проверки может после этого определить, совпадают ли фактические результаты с ожидаемыми результатами. Дальнейшая информация относительно уровня проверки может быть найдена в родственной заявке, U.S. Patent Application Attorney Docket Number MSFT-4149, называемой «Automated Test Case Verification That Is Loosely Coupled With Respect To Automated Test Case Execution».

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

В некоторых вариантах воплощения изобретения отдельное поведение (сохраненное в банке данных поведения 214 выполнения на логическом уровне 202 или в другом месте) может быть реализовано для каждого способа, реализующего логическую операцию. Использование поведения позволяет написать гораздо меньше тестовых примеров, обеспечивая при этом ту же самую степень всестороннего тестирования. Менеджер 212 поведения выполнения из уровня 210 поведения выполнения в некоторых вариантах воплощения изобретения определяет, какие поведения из поведений 214 выполнения являются уместными рассматриваемой логической операцией. В некоторых вариантах воплощения изобретения могут использоваться весовые коэффициенты и другие параметры настройки для выбора специфического поведения. Дальнейшая информация относительно уровня 210 поведения может быть найдена в родственной заявке U.S. Patent Application Attorney Docket Number MSFT-4148, называемой «System for Selecting Test Case Execution Behaviors for Reproducible Test Automation».

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

Фиг.4 является блок-схемой способа использования архитектурного стека в автоматизированном тестировании. На шаге 402 получают тестовый пример, записанный в архитектурный стек. Тестовый пример может быть написан для логического уровня. Альтернативно тестовый пример может быть написан для уровня, расположенного глубже в стеке. На шаге 404 уровню проверки может быть послано уведомление, что будет выполнен тестовый пример. В некоторых вариантах воплощения изобретения будет сделан снимок перед тестом ожидаемого состояния приложения, которое будет тестироваться. На шаге 406 анализируется описание тестового примера. В некоторых вариантах воплощения изобретения каждое описание тестового примера представляет собой логическую операцию. На шаге 408 определяется поведение, уместное логической операции. Вместо того чтобы реализовывать детали непосредственно каждого шага, тестовые примеры могут запросить у менеджера поведения выполнения соответствующее поведение. В некоторых вариантах воплощения изобретения менеджер поведения выполнения для уровня поведения выполнения определяет, какие поведения в банке данных поведения выполнения являются уместными рассматриваемой логической операции. Менеджер поведения выполнения может просмотреть набор отношений между индивидуальными поведениями, которые могут использоваться для реализации шага в тестовом примере, и может сделать выбор. Могут использоваться весовые коэффициенты и другие параметры настройки для выбора специфического поведения. На шаге 410 может быть выполнена операция, используя выбранное поведение. Шаги 406-410 могут быть повторены для каждого описания в тестовом примере. На шаге 412 уровень проверки может быть уведомлен, что тестовый пример выполнился. Уровень проверки может определить, совпадают ли фактические результаты с ожидаемыми результатами. Альтернативно обработка проверки может произойти после того, как каждое описание в тестовом примере выполнится.

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

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

Изобретение относится к автоматизированному тестированию программного обеспечения. Техническим результатом является повышение надежности и быстродействия при проведении тестирования. Система содержит процессор, выполненный с возможностью приема тестового примера, выбора поведения выполнения тестирования, выполнения тестового примера, используя конкретный путь выполнения, который ссылается на объект в физическом уровне многоуровневой библиотеки. Физический уровень обеспечивает объектную модель для интерфейса пользователя приложения. Логический уровень обеспечивает объектную модель для функций приложения. Управляющая тестовым примером программа может выполнить тестовый пример. Менеджер данных может гарантировать изменчивость тестовых данных. Менеджер поведения может определить подробности выполнения, соответствующие специфическому тестовому случаю. Менеджер проверки может произвести выполнение проверки после того, как тестовый пример выполнится. 3 н. и 21 з.п. ф-лы, 4 ил.

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

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

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

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

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

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

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

8. Система по п.1, в которой объекты, связанные с выбором тестовых данных, сохранены на втором логическом уровне не в тестовом стеке автоматизации.

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

10. Система по п.1, в которой объекты, связанные с проверкой тестовых результатов, отделены от объектов, связанных с вариантами выполнения.

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

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

13. Система по п.1, в которой объект, связанный с проверкой тестовых результатов, сохраняют на логическом уровне стека автоматизации.

14. Система по п.12, в которой администратор проверки сравнивает фактические результаты выполнения тестового примера с ожидаемыми результатами выполнения тестового примера.

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

16. Способ по п.15, дополнительно содержащий этап, на котором посылают уведомление, что тестовый пример будет выполнен.

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

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

19. Способ по п.15, в котором объекты, связанные с проверкой тестовых результатов, отделены от объектов, связанных с вариантами выполнения.

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

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

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

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

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