Документ освещает опыт тестирования API платформы САПР NanoCAD, начиная с ручного тестирования и переходя к автоматизации. Основное внимание уделяется созданию чертежей, особенностям API и этапам тестирования, включая ручные тесты и разработку автоматизированных тестов. Мысли о том, как обеспечить актуальность автотестов и совместимость с различными версиями системы, также занимают важное место в документе.

1. Опыт тестирования API САПР платформы
От ручных тестов к автоматизации
Илья Слободин
Клуб разработчиков nanoCAD
ЗАО «Нанософт», 2012

2. Об авторе
Впервые принял участие в разработке
САПР в 1994 году
Разрабатывал ПО для:
• архитектурной реставрации,
восстановления геометрии по
архивным фотографиям
• производства кухонной мебели
• обработки сканированных чертежей
В настоящее время: руководитель
проекта «Клуб разработчиков nanoCAD»

3. Что такое nanoCAD?
nanoCAD – это двумерный САПР
общего назначения,
«электронный кульман»
Предназначен для создания
чертежей
Обладает развитым API,
позволяющим создавать
специализированные
приложения

4. Зачем в САПР API?
1. Автоматизация создания
чертежей
2. Упрощение создания
и редактирования чертежей
Виды API:
COM, LISP, .NET, C++

5. Простейший чертёж
Создадим чертёж, состоящий из единственного отрезка
из точки (0, 0) в точку (100, 100)
Мышь: Клавиатура:

6. Программное создание чертежа: COM
JScript:
VBScript:

7. Программное создание чертежа: LISP

8. Программное создание чертежа: .NET

9. Программное создание чертежа: C++

10. Сложно ли подвинуть стену?
Угол сюда
Баба Яга

11. Делай – раз!
План начерчен отрезками, План начерчен стенами,
встроенными в nanoCAD окнами, дверями приложения
nanoCAD СПДС
525 отрезков 4 стены, 2 окна, 1 дверь

12. Настоящий чертёж
14399 объектов

13. Предпосылки возникновения nanoCAD
• К 2008 году нами было создано более 20 приложений
на платформе AutoCAD
• Кризис: AutoCAD дорог, и заметно дороже наших
приложений
• Решение: создание собственной платформы

14. Краткая история
• 2008 – первое приложение на платформе nanoCAD
• 2008-2012 – портировано более 10 приложений
…
• 2011 – релиз платформы
как самостоятельного продукта, открыт API,
заработал «Клуб разработчиков nanoCAD»
• 2012 – выход на международный рынок

15. Кому страшна регрессионная ошибка?
Если появилась ошибка там, где раньше её не было:
Человек найдёт
как обойти ошибку
Программа, установленная
у пользователя, обойти
ошибку в API платформы
не в состоянии

16. Что тестируем?
• API работы с чертежами:
▪ открытие, сохранение
• API взаимодействия с пользователем:
▪ выбор графических примитивов
▪ выбор точек на экране
▪ ввод координат, чисел, строк
▪ запуск команд
• События (реакторы):
▪ на создание, удаление, изменение всего и вся

17. Этап 1. Тестирование API вручную

18. Этап 1. Тестирование API вручную
• Тест API – специальная команда, вызывающая
функцию API со всеми основными вариантами
параметров
• Команду запускает вручную тестировщик
• Далее тестировщик выбирает точки на экране,
вводит координаты, и т.п. согласно тест кейсу
• По завершении тест кейса анализируется лог файл

19. Ручной тест API
Команда: GetAngleTest
Должен быть загружен документ UnitTest.dwg
Укажите угол мышью, первая точка: 0,0,0
Вторая точка: 100,100,0
Проверка на отмену. Нажмите Esc: Esc
Проверка на ввод 0. Введите 0: 0
Проверка на запрещение ввода 0. Введите 0: 0
Значение должно быть ненулевым.
Проверка на запрещение ввода 0. Введите 0: 1
Проверка на запрещение пустого ввода. Нажмите Enter или пробел: <Enter>
Проверка на запрещение пустого ввода. Нажмите Enter или пробел: <Space>
Проверка на запрещение пустого ввода. Нажмите Enter или пробел: 1
Проверка на пустой ввод. Нажмите Enter или пробел: <Enter>
Проверка свободного ввода. Введите не число: #sqadays12
Проверка на значение по умолчанию. Нажмите Enter <135>: <Space>
Проверка ввода с ключевыми словами. Введите число или [Пи/Два-пи/]: Пи
Проверка ввода по умолчанию с ключевыми словами.
Нажмите Enter или пробел <135> или [Пи/Два-пи/]: <Enter>

20. Этап 1. Тестирование API вручную
• Достоинства:
▪ API может быть проверен
• Недостатки:
▪ высокая трудоёмкость и низкая эффективность ручных
тестов

21. Автоматизируем?

22. Главный вопрос автоматизации
Как мы будем
поддерживать автотесты
в актуальном состоянии?

23. Что мешает автоматизации?
Специфика САПР: координаты, пиксели, масштабы
На координаты влияют:
• Размеры и взаиморасположение окна приложения и
его панелей управления
• Отображение элементов управления в разных
версиях ОС, стили оформления ОС
• Многомониторные конфигурации
• И многое, многое другое…

24. Как найти нужный пиксель?
Экран
(401, 18)
Чертёж
(100, 100, 0)

25. Как найти нужный пиксель?
Экран
(207, 128)
Чертёж
(100, 100, 0)

26. Как найти нужный пиксель?
Экран
(315, 161)
Чертёж
(100, 100, 0)

27. Координаты: из чертежа в пиксели
Вывод: Координаты должны храниться в системе
координат чертежа
COM модель расширена методами преобразования
координат:
nanoCAD.Utility.CoordFromPixelToWorld()
nanoCAD.Utility.CoordFromWorldToPixel()

28. Этап 2. Традиционная автоматизация
• Последовательность действий тестировщика
записана в виде сценария системы
автоматизированного тестирования
• Результат выполнения теста сохраняется в
специальный объект САПР платформы
• Система автоматизированного тестирования читает
результат через COM

29. В поисках идеального рекордера
Стандартный скрипт автоматизации:
Как автоматизировать это преобразование при записи?
Надёжный скрипт автоматизации:

30. Этап 2. Традиционная автоматизация
• Достоинства
▪ высокая скорость тестирования, низкая вероятность
ошибок, связанных с человеческим фактором
• Недостатки
▪ тесты сложно поддерживать, приходится синхронизировать
две разделённые части теста:
1. тест API, загружаемый в САПР платформу
2. сценарий автоматизированного теста

31. Этап 2. Традиционная автоматизация
Q. Как создать легко поддерживаемый тест?
A. Объединить две разделённые части автотеста
в один модуль

32. Вариант 1. Адаптер для nanoCAD
Логика теста только в системе автоматизированного
тестирования, в nanoCAD загружен адаптер
Не подходит. Мы теряем возможность прогона теста
вручную

33. Вариант 2. Адаптер для системы автотестов
Логика теста только в nanoCAD, в систему автотестов
загружен адаптер, «универсальный проигрыватель»
Подходит. Тесты можно прогнать вручную. Есть
теоретическая возможность замены системы
автотестирования

34. Изобрели велосипед?

35. Этап 3. Универсальный проигрыватель

36. Этап 3. Универсальный проигрыватель
• Сценарий автотеста содержит
лишь название теста и код
запуска универсального
проигрывателя
• Универсальный проигрыватель
запрашивает у модуля тестов
список действий
и последовательно их
выполняет

37. Этап 3. Универсальный проигрыватель
• Достоинства:
▪ тесты легко поддерживать:
при изменениях исправления
вносятся только в один модуль
• Недостатки:
▪ Большая трудоёмкость создания автоматизированного теста
по сравнению с традиционным подходом:
1. запись сценария в системе автоматизированного
тестирования
2. перенос сценария в модуль тестов

38. Требования к системе автотестирования
Система должна позволять:
• Автоматизировать мышь и клавиатуру
• Создать универсальный проигрыватель
• Прочитать через COM список действий и результат
выполнения тестов

39. Как мы выбирали систему автотестирования
Когда мы начинали думать об
автоматизации, отдел тестирования
уже использовал TestComplete
Мы работаем в Visual Studio,
основной язык разработки: С++
Первые ручные тесты были написаны
для .NET API на С#
Мы решили попробовать Coded UI Test
У нас получилось
Там и остались

40. P.S. Всё ли автоматизировано?
Времени не хватает: вперёд, только вперёд!
Что автоматизировано?
• Тесты исправленных
ошибок в API
• Тесты нового API
Что не автоматизировано?
• Тесты API, написанные
до решения проблемы
автоматизации

41. Точка роста твоей карьеры
Тесты, которые ещё не автоматизированы == Курс молодого бойца