
- •Институт инженерно-экологических систем и сооружений Кафедра информационных систем и технологий
- •По производственной технико-экономической практике
- •Введение
- •Сведения о компании Описание области деятельности.
- •Кратко о компании
- •История компании.
- •Цели компании
- •Штат сотрудников
- •Оснащение организации вычислительной техникой
- •Персональные компьютеры
- •Программное обеспечение
- •Наличие и параметры локальной вычислительной сети
- •Индивидуальное задание
- •Объект тестирования
- •Средство для автоматизации тестирования
- •Пример скрипта написанного в течение практики.
- •Заключение
- •Список источников информации
Наличие и параметры локальной вычислительной сети
Димин текст
Схема локальной сети одного из помещений
Индивидуальное задание
Разобраться со структурой и принципом работы автоматических тестов для платформы X. Написать автоматические тесты на новые требования.
Объект тестирования
X, это один из основных программных компонентов прикроватных мониторов, входящий в них в тех или иных конфигурациях. Это возможно благодаря тому, что конфигурирование X базируется на xml, что делает его очень гибким и позволяет создавать любые требуемые конфигурации для разных продуктов. По сути X, это фреймворк для отображения CPOC (common point of care) - компонентов, отвечающих за разные аспекты ПО компании XX, управляющий пользовательским интерфейсом (графикой, вводом пользователя, аудио, и так далее).
Главной целью тестирования фреймворка X является проверка всех требований (порядка 1800). Тестируется правильность поведения конкретного объекта, (что он правильно отрисовывается, правильно пишет в базу данных1, правильно реагирует на изменения в конфигурациях и др.) и правильность работы объектов вместе (проверяется не перекрывают ли графические объекты друг друга, что они способны выполнять совместные операции и прочее).
Для его тестирования применяется как ручное, так и автоматическое тестирование, причем доля автоматических тестов значительно больше (более 65%). Также присутствуют полуавтоматические тесты (около 14%). В них большая часть действий происходит автоматически, однако требуется участие тестировщика при вынесении вердикта в контрольных точках.
Средство для автоматизации тестирования
Автоматические и полуавтоматические тесты написаны на языке SQABasic в Rational Robot.
IBM Rational Robot - это средство автоматизации функционального тестирования клиент-серверных приложений, обеспечивающее обнаружение ошибок, включает наборы тестовых данных и средства управления тестами и поддерживает несколько типов пользовательского интерфейса.
Rational Robot позволяет специалистам по автоматизации тестирования расширять сценарии тестирования для обнаружения ошибок, а также создавать новые наборы тестовых данных, а так же предоставляет наборы тестовых данных для наиболее распространенных объектов и специализированные наборы тестовых данных для объектов среды разработки.
Rational Robot помогает отслеживать ошибки, управлять изменениями и выполнять трассировку требований, автоматизирует регрессивное, функциональное и конфигурационное тестирование.
Одним из достоинств Rational Robot, является то, что он позволяет упростить конфигурационное тестирование, то есть Rational Robot может быть использован для конфигурационного тестирования нескольких машин, в случае если каждая сконфигурирована различно. Также это средство поддерживает множество сред и языков, включая HTML и DHTML, Java, VS.NET, Microsoft Visual Basic и Visual C++, Oracle Developer/2000, PeopleSoft, Sybase PowerBuilder и Borland Delphi.
Пример скрипта написанного в течение практики.
<Code>
Здесь происходит включение заголовочных файлов, в которых определены функции используемые практические во всех скриптах. Данный скрипт тестирует одно из требований на контроль яркости экрана, поэтому заголовочный файл UtilsBrightnessControl_X.sbh, является специфичным для него, а так же для всего набора скриптов тестирующих эту область. В нем определены размеры окна запускаемого приложения, а также названия layout'тов необходимые для их смены в процессе выполнения теста.
<Code>
Эти функции отвечают за запуск всех необходимых служб для X, и перемещение окна приложения в левый верхний угол экрана, это нужно, так как проверка результата в большинстве скриптов происходит по средствам сравнения скриншотов (того что должно быть, с тем что есть) и если окно находится всегда в одном и том же месте, то координаты проверяемой области вычисляются проще и плюс к тому тест становится менее восприимчивым к изменениям интерфейса.
<Code>
Эти 3 функции необходимы для формирования удобочитаемого и детального лога тестирования. После проведения теста благодаря этим функциям в логе появятся поля с номером тест кейса, номером требования и текстом требования.
<Code>
Функция CriticalErrorCheck, проверяет правильность выполнения функции которая в нее передана, с вынесением соответствующего вердикта и записью в логе теста. Например в этих функциях проверяется запустилось ли приложения, проинициализировалась ли база данных и открылось ли соединение с базой данных.
<Code>
Функция XXML_InitXMLDoc читает ту .xml конфигурацию на которой должно запуститься тестируемое приложения и создает объект, который является ее представлением. Это позволяет скрипту при каждом запуске восстанавливать значения атрибутов, что делает его независимым от изменений в текущей конфигурации тестируемых элементов.
<Code>
Это задержка в исполнении скрипта.
<Code>
Эта функция запускает homescreen, то есть графическую оболочку.
<Code>
Функции TestCaseActionDescr и TestCaseExpRes также относятся к функциям формирования лога, они добавляют в него поля с информацией о действиях в тесте и ожидаемых результатах после них.
<Code>
Данный тест проверяет, что яркость дисплея меняется в зависимости от того в дневном или ночном режиме находится приложение. Для этого X переводится в ночной режим, по средствам изменения отвечающего за это узла Y (XTest.Therapy.Sett1.Label), это делается путем записи в него строки "night", предварительно преобразованную в структуру данных, которую может прочитать Y. Преобразование делает функция StrTo8Struct. Пишет в базу данных функция RR_YWrite, где YHandle - указатель на открытую базу данных, node - имя узла в который производится запись, value_str - значение записываемое в узел, 10 - размер записываемого значения.
Поскольку в ночном режиме, значения яркости дисплея должно быть равно 30, проверяется соответствующий узел Y и значение отображаемое на homescreen. Первое делается в функции RR_YRead, которая читает значение из узла X.System.Brightness.Value и записывает его в переменную value_long. Второе, в функции RegionVP, которая возвращает единицу в случае совпадения фотографируемой области ограниченной координатами 8,24,392,122 с уже существующей картинкой.
Далее идет проверка результатов и в случае если чтение из базы прошло успешно и картинки совпадают, то вызывается функция ActResPass, которая пишет в лог свой аргумент, являющийся положительным результатом выполненного действия. Если хотя бы одно из условий не выполняется вызывается функция ActResFail, которая пишет отрицательный результат выполнения действия.
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
<Code>
Здесь проверяется что значение яркости экрана равно 50, при переключении в дневной режим. Это делается тем же способом с единственным отличием, что в XTest.Therapy.Sett1.Label пишется "day".
<Code>
В этом блоке происходит вынесение общего вердикта тест кейса, говорящее о выполнении/не выполнении требования. В логе, функции LogWriteNonNumericPass, LogWriteNonNumericFail, делают соответствующие записи.
<Code>
Здесь закрывается соединение с базой и проверяется правильность этого, останавливаются все связанные с X службы, а также вызывается функция, которая пишет все ошибки в лог.