Продолжение о тестах

Первая серия была тут - http://18delphi.blogspot.com/2013/04/blog-post_5863.html

Пишет мой коллега:

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

Таким образом, избегая зацикливания на одном объекте системы, тесты охватывают всю систему паутиной. И стоит “задеть” одну нить – вся паутина задрожит и даст знать, что что-то случилось. С одной стороны, это замечательно, что тесты перестали проходить. Значит, они работают и нужно проверить изменения в системе. С другой, это ужасно неудобно с точки зрения локализации проблемы. Очень редко, ну очень, возвращается старая ошибка. Тест специально заточен под то, чтобы аккуратно зафиксировать ошибку и уведомить об этом тестировщика. Но, как правило, ломается что-то другое, “по-соседству”. Тест это честно находит, но часто не может четко показать причину ошибки. На эти случаи вставляются ASSERT ы, но всех возможных ошибок нельзя учесть (тогда написание одного теста будет занимать очень долгое время).

Сами тесты я разделяю на следующие группы:

- Уникальные тесты (которые никогда не пересекаются с другими тестами и проверяют область, которую не проверяют другие тесты);

- Тесты, на которые могут повлиять другие тесты (и это тоже проблема, которая решается “качественным” кодом). Например, любые тесты с поиском (от другого теста может остаться фильтр, который изменит результат).

- Тесты – близнецы (разница в которых может составлять и одну строку, и один символ).

Значит, тесты можно делать либо максимально универсальными, либо максимально уникальными. Но в сложных программах путь универсализации – ошибочен. Первое время я старался писать тесты и слова для них с запасом для будущих тестов. Специально “опускал” некоторые части кода. Например:

: “Выделить весь текст в документе”

“Зайти в документ”

“Выделить весь текст”

“Сравнить выделенный текст с эталоном”

; \\ “Выделить весь текст в документе”

То есть, я знаю, что при входе в документ фокус стоит в тексте. И опускаю код “Установить фокус в текст”. Значит, в этом тесте проверяется не только результат выделения, но и то, что фокус оказывается в документе (косвенно). Но знаю также, что есть другой тест, который проверяет именно то, где находится фокус:

: “Проверить, что фокус после открытия документа находится в тексте”

“Зайти в документ”

“Проверить, в каком контроле стоит фокус”

; \\“Проверить, что фокус после открытия документа находится в тексте”

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

: “Выделить весь текст в документе”

“Зайти в документ”

“Установить фокус в текст”

“Выделить весь текст”

“Сравнить выделенный текст с эталоном”

; \\ “Выделить весь текст в документе”

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

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

Если рассматривать мою работу, с точки зрения результативности, то я бы оценил её как среднюю. Ошибки исправно находятся, но есть несколько причин, по которым её нельзя назвать хорошей.

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

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

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

В-четвертых, можно ли утверждать, что когда-то написанный и отлаженный тест будет корректно проверять именно то, что нужно, через 2-3 года. Нельзя. Нужно иногда проводить ревизию тестов (хотя бы выборочно).

Есть еще несколько малозначимых причин. Их, думаю, можно не указывать.

Теперь рассмотрим, какой же человек может справиться с работой с автоматическими тестами.

1) Он должен знать термины и аббревиатуры, принятые в системе.

2) Нужны базовые знания любого языка программирования (не обязательно Delphi или FORTH).

3) Нужна аккуратность, вдумчивость и усидчивость.

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

Приведу пример из жизни. Однажды мне пришлось поработать в Тверьстате (Территориальный Орган Федеральной Службы государственной статистики). Первая половина работы не имеет к данному рассказу никакого отношения (контроль и правка результатов сканирования). Зато вторая стала очень поучительной. Её суть заключалась в правке Excel – документов (оптимизировать размер полей под печать на минимальном количестве листов). Задача очень простая. Но однотипных документов были тысячи, и выполнять все действия вручную было несерьезно. Была нужна автоматизация. И она была создана одним очень талантливым студентом.

Процесс нашей работы имел вид:

1 день) Ознакомились с заданием, вручную сделали несколько документов.

2 день) Кто-то вспомнил, что в Excel есть макросы. Создав один макрос, его можно указывать из любого документа. Исправили несколько сотен документов.

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

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

То есть, на мой взгляд, написание основной группы тестов должно рано или поздно свестись к работе, схожей с написанием макросов: выполняем действия, система их запоминает и в конце сравнивает результат по каким-либо критериям. Это сделает написание тестов более простым и гораздо более быстрым. Если потребуется написать тест под каждое требование из ТЗ или автоматизировать проверку уже созданных тесткейсов – данный подход поможет это сделать. Ручное написание подобного количества тестов заняло бы годы.

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

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

Трофимов Андрей

Тестировщик

Пишет коллега (то что выделено - выделено - мной):

Раньше я и не подозревал, что в нашем городе (Тверь) можно найти работу, которая непосредственно связана с тестированием каких-либо программных продуктов, приложений и т.п. Да, и вообще о существовании должности тестировщика, отделах тестирования и прочих тематических деталях мне не приходилась слышать до некоторых пор. Но как только это произошло, моё внимание было полностью скоординировано именно на этой, так сказать, карьерной ветви. Тогда я ещё учился в университете, а точнее, даже уже писал дипломный проект. А так как моё образование было целиком и полностью связано с IT-сферой, я решил, что тестирование для меня будет интересным родом деятельности, в котором я смогу стать квалифицированным специалистом.

И вот, я устроился работать тестировщиком программного обеспечения. Я был ознакомлен с программным продуктом, алгоритмами тестирования, внутренней инфраструктурой и прочими элементами, которые распахнули передо мной двери в так называемый мир Тестировщика. Задача моя была весьма понятной. Необходимо было «брать» тест-кейсы, применять их для приложения и находить, таким образом, баги. Этим я, собственно, и занимался. На самом деле, хоть это и не было довольно «крутым» делом (на мой взгляд), чувствовалось, что приобретается ценный опыт не только по данной профессии, но и в развитии аналитического мышления. И благодаря этому опыту получалось смотреть на приложения не только глазами обычного пользователя (как было в начале), но и глазами хорошего тестировщика.

Конечно, не всегда всё упиралось в тест-кейсы, так как была свобода действий (никто «не бил по рукам»), но, несмотря на это, спустя примерно полгода работа стала казаться рутинной. Тест-кейсы брались уже по n-ному кругу, а тестируемое приложение, по большому счёту, оставалось таким же (кардинальных изменений не было, а новый функционал практически не прибавлялся). Поэтому лично я чувствовал, что могу, хочу и должен делать что-то большее, приносить более весомую пользу тестируемому приложению. И вышло так, что уважаемые коллеги из Москвы предоставили мне возможность заниматься автоматизацией. Бинго! Это то, что было нужно. Новый уровень, да и вообще, другая, более серьёзная деятельность. Мне дали шанс заняться программированием. Необходимо было покрывать автоматическими тестами найденные ошибки, что считалось весьма полезным делом, ведь это:

• обеспечивало пополнение базы автоматических тестов, которые наряду с тестировщиками, регулярно проверяли приложение на те или иные ошибки;

• помогало программистам, которые исправляли баги, без труда прогонять тесты и проверять результаты своих исправлений;

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

Язык, на котором требовалось писать авто-тесты, называется FORTH и представляет собой «живой язык» программирования, сгенерированный на основе Delphi. Сначала всё казалось гораздо проще, особенно, когда писался первый тест, ведь это выглядело примерно так:

: Тест
«Открыть документ»
«Выделить всё»
«Сравнить выделенный текст с эталоном»
;
Тест

Всё по-русски, всё понятно, да и работает, как надо. Но со временем всё чаще приходилось сталкиваться с ситуациями, когда содержимого словаря языка было недостаточно для того, чтобы написать тот или иной тест. И пришлось лезть ВНУТРЬ. А там ждали совсем не «Открыть документ» и «Выделить всё», там ждали уже отголоски Delphi, а также ООП. Но благодаря уважаемым коллегам и это стало более или менее перевариваться. Спустя несколько месяцев уже было в моих силах реализовать новое функционально «русское» слово, которое делало бы то, что, собственно, необходимо. Массивы, строки, деревья, стеки, рекурсия и прочие «хорошие вещи», с которыми связывала меня только студенческая жизнь, оказались очень полезными. Приходилось «играться» с размерами форм, модальными окнами, таймерами и прочим. И выходило всё достаточно неплохо, да и в удовольствие :)

 На том этапе я уже чувствовал, что то, что я делаю, можно назвать программированием, к тому же, как тестировщик, я стал смотреть на весь процесс тестирования под другим углом. Находя ту или иную ошибку, я видел набросок будущего теста, а также (в некоторых случаях) и причину бага. А самое приятное, что о рутинности и речи быть не могло. Работы было много, она была совершенно разносортной (в рамках автоматизации тестирования, конечно же), а желание «кодить» только усиливалось. А, самое приятное было тогда, когда приходилось ломать голову над одним тестом день или больше, а потом своими силами находить правильное решение. Вы ведь понимаете, о чём я? :)

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

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

Владимир Селянкин.

Тестирование глазами молодого специалиста

Написал мой коллега:

Тестирование глазами молодого специалиста.

К процессу тестирования, зачастую, относятся довольно пренебрежительно, не видя необходимости прибегать к разработке отдельных программных средств нахождения ошибок. Максимум, что может своевременно найти ошибку – это проверка самим разработчиком измененного кода, ревью кода других разработчиков или специальный человек (или коллектив), который контролирует работоспособность конечного продукта. Так мне казалось, когда закончив ВУЗ, поступило предложение заняться тестированием. Казалось бы, что может быть проще, чем проверить работоспособность программы, когда в твоем распоряжении находится актуальное ТЗ, архив с уже созданными и, в большинстве своем, исправленными ошибками, огромное количество обсуждений, в которых можно найти ответ практически на любой вопрос. Но ожидания оказались не совсем верными. И дело даже не в не умении найти нужный материал, а в разнице между текущим поведением программы и неясностями (двояким толкованием, пробелами) в текущих требованиях. И самый надежны способ определить единственно верное поведение – обратиться к людям, это поведение реализовывающим. К разработчикам. Но, естественно, с течением времени, с ростом количества реализованных и назначенных задач знания об определенных объектах и методах их реализации подзабываются. Это человеческое естество и с ним ничего не сделать. И на первый план выходят выходят автоматические тесты – минипрограммы, в которых четко зафиксировано ТЕКУЩЕЕ поведении системы, особенности ее работы. И чем больше этих программ – тем лучше, т.к. они будут охватывать всю систему (в идеале). Любое отклонение от нормы будет зафиксировано и человек вынесет решение – новая ли это ошибка или требования изменились и нужно изменить тест (эталон). Эту систему невозможно обмануть, новую ошибку нельзя пропустить (при наличии работоспособного теста), как это мог бы сделать, например, не вовремя отвлекшийся человек, ищущий ошибку. Но сильно забегаю вперед, перенесемся в самое начало пути – к тестированию системы вручную.

Моя работа тестировщиком началась со знакомства с системой. И сразу же появились первые вопросы – “Почему это работает так?”, ”Верно ли это?”. Вообще говоря, именно первые недели наиболее благоприятны для поиска ошибок, т.к. новый человек может заметить то, что большинство уже и за ошибку не считают. Новый сотрудник обращает внимание на каждый клик, каждое новое открывающееся окно, к любому событию он относится с подозрением - “А верно ли это?”. Далее, ответ на спорное поведение ищется в описании прецедентов в требованиях. Конечно, всегда можно спросить у знающих людей, но самостоятельный поиск информации ведет к гораздо более глубокому пониманию системы. Со временем, эти знания накапливаются, и новую ошибку уже можно найти не только в результате выполнения тесткейсов, но и проанализировав текущие изменения в системе. Приходит понимание возможных причин появления ошибок. С другой стороны, ежедневный поиск ошибок по четко зафиксированным алгоритмам интересен и разнообразен лишь первые 2-3 прогона всех заданий. Далее, внимание притупляется, тесткейсы уже вызывают меньше вопросов, становится очень трудно проверять задания не механически. Выходом стало тестирование другого проекта. И пусть задания похожи, но нужно вновь разбираться, активно работать с ТЗ, учиться новому. Далее следует возврат к первому проекту, затем опять на новый. Только такой подход, на мой взгляд, позволяет эффективно находить всё новые и новые ошибки. Но рано или поздно, сам процесс такого тестирования начинает казаться неэффективным. И я стал присматриваться к работе с автоматическими тестами, благо все условия были для этого созданы. Но жизнь вносит свои правки, и не успев даже поверхностно познакомится с автоматизированным тестированием, меня выбрали основным человеком, который этими тестами и занимается.

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

: Кликаем_на_кнопку_ДАЛЕЕ

 : Действия

  “Переместить курсор мыши на кнопку ДАЛЕЕ”

  “Кликнуть левой кнопкой мыши”

  “Определить, был ли переход по Далее”

 ; \\ Действия

 “Запомнить позицию курсора мыши и выполнить {(@ Действия)}”

; \\ Кликаем_на_кнопку_ДАЛЕЕ

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

Поначалу, небольшие сложности вызывала обратная польская запись кода, а также обилие форм, контролов и классов. Но это объяснимо: последний раз самостоятельно программировать пришлось в далеком 2005 году в колледже (если не ошибаюсь, последней работой стала программа “Определение уровня безопасности помещения” на Delphi). Программированием это назвать сложно – все в рамках учебных курсов. Но тем не менее, основы, заложенные тогда, помогают разбираться и теперь с тестами. Когда приходит понимание, как найти контрол на форме, как передать ему фокус – настроение сразу поднимается. Это увлекательно, здесь нет однообразия: нужно успевать фиксировать результаты прогона тестов, писать новые, править старые, распределять тесты по пресетам, разбираться в старых ошибках, чужом коде и думать (последнее самое ценное). Поэтому, мое отношение к автотестам – очень позитивное и положительное. Да, можно проверить уже исправленные ошибки вручную, но здесь главную роль играет время – его уйдет неимоверно много на повторение старой ошибки, по сравнению со временем прохождения теста.

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

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

Но плюсов, безусловно, больше, ведь главное – не пропустить ошибку. А если есть тест, который проверяет исправленную ошибку, то в случае ее возврата, она будет найдена.

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

Прим.: Мнение автора может не совпадать с мнением коллег.

Трофимов Андрей

FORTH vs LISP

Они конечно - "близнецы-братья". С точки зрения парадигмы.

Только в FORTH - обратная польская запись, а в LISP - прямая.

Ну по моему скромному мнению - FORTH проще и технологичнее. И более расширяем с плане "синтаксического сахара". Он на это - идеологически заточен.

ОЧЕНЬ хорошая идея - взять FORTH-машину и сделать над ней DSL. Который бы позволял сделать примерно следующее:


: K216794957

 ТБ24
 ППР
 "Перевести фокус в поле 'Орган/Источник' в ППР"
 "в поле 'Орган/Источник' ввести {('Правительство России и СССР')}"
 "Выделить текст в поле"
 "Начинаем набирать {('Органы')}"
 "Сравнить абзац текущего редактора с эталоном"
 "Нажать {('Enter')}"
 "Сравнить абзац текущего редактора с эталоном"
 "Нажать Искать"
 "Проверить информацию о списке"
;
--------------
K216794957


: K224135514

 "Копировать в буфер строку {('01.01.2010')}"
 ППР
 "Перевести фокус в поле 'Дата принятия' в ППР"
 "Вставить"
 "Выделить текст в поле"
 "Сравнить выделенный текст текущего редактора с эталоном"
;
--------------
K224135514


: K224790135
 "Открыть НК"
 "Список редакций"
 СР
 "Вызвать Список редакций из статусной строки"
;
--------------
K224790135


: K226006496

 : Действия1
  "Перевести фокус в текст"
  "В конец документа"
  "Перевести фокус в оглавление"
  "Получить заголовок текущего контрола"
 ;

   : Действия
     "Выставить форме размеры {(1400 800)} ширину навигатора в {(300)} и {(@ Действия1)}"
   ;

 "Открываем НК"
 "Сделать {(@ Действия)} с изменением состояния и размеров окна {("Найти главное окно")}"
;
--------------
K226006496


: K232098711
 "Открываем НК"
 "Список редакций"
 "Стрелка вниз"
 "Выделить текущий элемент"
 "Построить обзор изменений для выбранных редакций"
 "Сравнить текст с эталоном"
 "Открываем НК"
 "Список редакций"
 "Стрелка вниз"
 "Выделить текущий элемент"
 "Сравнить выбранные редакции"
;

K232098711
--------------

: K235865644
 "В БП ищем контекст {('Сдача результата работ заказчику оформляется актом приемки выполненных работ, составленным по форме N КС-2')}"
 "Нажать {('Enter')}"
 // - открываем первый документ списка - он д.б. флешом
 "Установить фокус во флеш"
 "Проверить что номер кадра флеша равен {(2)}"
;

K235865644

-- это - ТЕСТЫ, а не просто "кейсы". Они - КОМПИЛИРУЮТСЯ и ВЫПОЛНЯЮТСЯ. FORTH-машиной.


Простите уж мне моё занудство. Я писал и на FORTH и на AutoLISP.

Идея AutoLISP меня кстати давным давно - ОЧЕНЬ вдохновила. Что можно не только было рисовать чертежи мышью, но и "программировать" их.

Но FORTH - по-любому - круче. Для "синтаксического сахара".

И в конечном итоге для снижения порога вхождения.

Попробуйте подумать в эту сторону. Может быть вам понравится.

FORTH-машина для скриптов

Что сделано:

1. Стандартные возможности. Обратная польская запись (ОПЗ). Строки. Числа. Арифметические операторы. DUP, DROP, ROT etc. Определение слов, выполняемых непосредственно при компиляции скрипта. IF, WHILE, LOOP. Определение констант.
2. Вложенные слова.
3. Переменные.
4. Массивы.
5. Лямбды и итераторы.
6. Определение собственных "классов".
7. Возможность обработки не только ОПЗ, но и аргументов справа.
8. Проекция стандартных Delphi-классов на словарь машины.
9. Доступ к RTTI от Delphi. Delphi 7. (Delphi XE3 - сделаем. Там всё веселее, там RTTI сильно богаче).
10. Работа с файлами.
11. try..finally, try..except, возбуждение собственных исключений.
12. exit, break, continue, halt.
13. Возможность управления встроенным парсером.
14. Стереотипы (мета-классы и мета-мета-классы). Программисты БД может быть поймут так - "данные" и "мета-данные".
15. Проверка типов.
16. Работа с деревом словаря. Перебор слов. Доопределение слов в run-time.
17. Оператор CASE.
18. Оператор RULES.
19. Масса слов для работы со строками и наборами символов.
20. Ленивые выражения.
21. Потоки (THREAD). Без синхронизации между друг другом. Синхронизация есть только с основным потоком выполнения.
22. Специализированная обработка модальности. Модальные объекты получают свой собственный кусок скрипта и выполняют его в собственном модальном цикле.
23. Вызов функций относительно текущего контекста (пример - передача this или self).
24. callback'и для процесса компиляции.
25. virtual, abstract, override, redefinition.
26. inherited.

-- и всё это сделано на Delphi7. Порт на Delphi XE3 - не за горами.

Ну и немного иронии: