Экспертиза задания на примере задачи о проверке анализатора РБНФ деклараций

Уважаемые коллеги, в чём выражается профессионализм тестировщика при его подходе к решению очередной задачи? В способности своевременно наверстать недостающие знания, погрузиться "до дна" в её контекст; выявить в её постановке неопределённости/некорректности, чётко сформулировать "непонятки" и устранить всё это при согласовании.

В данной статье я приведу подробную иллюстрацию — как проводить экспертизу задачи на тестирование.

Для чего? Честно говоря, я не знаю много теории для развития выше упомянутых профессиональных качеств. Для меня тестирование — это искусство, к которому я здесь хочу прикоснуться, а также поучиться этому с вами у тех, кто потом выскажет дельные замечания или дополнения.

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

Рассмотрим задание. Постановщиком задачи (далее ПЗ) сформулировано:

Подготовить тестовые наборы для проверки лексического анализатора, разбирающего декларации следующего вида (в предложенной нотации РБНФ):
procedure <return type> <name> ([<param type> <param name>{, <param type> <param name>}]);.
<return type> = void | int.
<param type> = int | long.
<name>, <param name>
— идентификаторы, соответствующие требованиям java.
ПЗ обращает внимание на то, что для выполнения задания не требуется специальных знаний, имеющих отношение к программированию или к тестированию белого ящика.

Наша цель – выполнить экспертизу данного задания и сделать это деликатно по отношению к ПЗ.

Итак, нам придётся выполнить поиск и изучение (или освежить в памяти) соответствующих спецификаций:
1. ISO/IEC 14977:1996(E) – спецификация по метаязыку Расширенная Форма Бэкуса-Наура
2. The Java Language Specification, Java SE 7 Edition – документация по языку JAVA v1.7

ЗАМЕЧАНИЕ_1: согласовываем с ПЗ – актуальны ли данные материалы для выполнения задания, достаточен ли их список для решения?!

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

Займёмся этим (см. ниже), а потом попросим ПЗ рассмотреть адаптированный вариант грамматики и обратить внимание на наши замечания, вопросы и комментарии.

(*
ЗАМЕЧАНИЕ_2: в оригинальном правиле сразу обращает на себя внимание строка:
"procedure <return type> <name> ([<param type> <param name>{, <param type> <param name>}]);."
Что здесь критично:
1.1 во фрагменте "procedure <return type> " пропущен знак равенства между идентификатором procedure и его определением, т.е. выражением справа от него;
1.2 во фрагменте " <param name>{, <param type> " запятая может трактоваться как символ конкатенации;
1.3 во фрагменте " <param name>}]);." каждый из двух последних символов может трактоваться как завершающий выражение;
1.4 использование угловых скобок "<", " >" – устаревшая конструкция, не в стиле расширенного синтаксиса.
*)

procedure = return type, blank, method name, opening parenthesis, args, closing parenthesis, semicolon;
(*
КОММЕНТАРИЙ_1: здесь, в предложенном варианте, устранены неоднозначности соответственно нашему пониманию РБНФ и представлению как, например, в java программе выглядит декларация метода, но если мы ошибаюсь – просим ПЗ нас поправить!

ВОПРОС_1: в рамках java-спецификации — если при объявлении метода не определяется его тело, то метод требуется указать как abstract. Спрашиваем ПЗ: в приведённой исходной грамматике это определение не подразумевается, это некритично?
*)

blank = " " ;
(* ЗАМЕЧАНИЕ_3: полагаем, что в 1-ой строке грамматики в соответствующих местах должен использоваться только один пробел и недопустим перевод строки и т.п. Иначе – просим ПЗ нас поправить здесь и в замечаниях 4 и 5 ниже! *)

args = [ arg, { comma, blank, arg } ] ;
(* ЗАМЕЧАНИЕ_4: сигнатура может быть пуста или содержать от одной до бесконечного количества пар типПараметра имяПараметра. Разделителями между парами являются 'запятая и один пробел' *)

arg = param type, blank, param name ;
(* ЗАМЕЧАНИЕ_5: между типомПараметра и именемПараметра разделитель 'один пробел' *)

сomma = ",";

param type = "int" | "long" ;

(*
В УСЛОВИИ: "идентификаторы, соответствующие требованиям java"
Далее в терминах РБНФ выявим, что под этим должно подразумеваться.
*)
param name = java identifier ; (* название параметра *)
(*
Стараемся вопросами к ПЗ исключать наши возникающие сомнения.
ВОПРОС_2: если в тестовом варианте у метода будут аргументы, тогда должен ли анализатор:
2.1 считать корректной декларацию, в которой имеются одинаковые имена параметров?
2.2 распознавать аргументы как различные в случае, если их имена состоят из одинакового набора символов, но они отличаются регистром?
2.2 определять как корректную декларацию, в которой одинаковые имена у метода и его параметра? зависит ли этот результат от разного регистра?

ПРИМЕЧАНИЕ_1: данные вопросы здесь и ниже очевидно необходимы, чтобы сформировать позитивные и негативные тестовые наборы.

В УСЛОВИИ: "выполнение этого задания не требует специальных знаний, не имеет отношения к программированию"
Снова вопросами к ПЗ исключаем неопределённости в задании.
ВОПРОС_3: правильно ли мы понимаем, что в задании в <param name> не следует рассматривать возможность конструкций:
3.1 троеточия перед наименованием последнего аргумента в сигнатуре, (т.е. метод с переменным количеством параметров анализатор не распознает как валидный)?
3.2 присвоения значений после указания имени параметра, (т.е. метод с предустановленными default-значениями параметров тоже не должен распознаваться)?
*)

method name = java identifier ; (* название метода*)
(* Грамматические правила составления имён параметров распространяются на названия методов *)

java identifier = definition — ( keyword | boolean literal | null literal ) ;
(* Мы предлагаем вниманию ПЗ конкретное правило формирования идентификатора на основе анализа документации java 1.7 *)

definition = java letter, { java letter | java digit } ;
(*
КОММЕНТАРИЙ_2: область значений definition такова, что нет необходимости исключать следующие два множества, определяемых правилами:
spec simbol = "[" | "]" | "(" | ")" | "{" | "}" | "." | "," | "~" | "!" | "?" | "@" | "#" | "%" | "^" | "&" | "*" | "+" | "-" | "=" | ":" | ";" | """ | "'" | "`" | "|" | "" | "/" | "<" | ">" (* и их octal analog /здесь не приводится/*);
escape sequence = "b" | "t" | "n" | "f" | "r" | """ | "'" | "\" (* и их octal analog /здесь не приводится/*);
но их (и не только их) надо иметь в виду на будущее для построения негативных наборов.
*)

java letter = latin letter | cyrillic letter | spec letter ;
(*
JAVA v1.7 полностью поддерживает UNICODE v6.0 в наименованиях параметра или метода, что включает практически все современные письменности, в том числе: арабскую; армянскую; бенгальскую; бирманскую; глаголицу; греческую; грузинскую; деванагари; еврейскую; кириллицу; китайскую; коптскую; кхмерскую; латинскую; тамильскую; корейскую (хангыль); чероки; эфиопскую; японскую (включает кроме китайских иероглифов слоговую азбуку) и многое другое.
ВОПРОС_4: нами будет предложено ПЗ определение с латиницей и кириллицей (русский алфавит) — если этого не достаточно, просим указать: какие конкретно интернациональные словари требуется ещё подключить для проверки, чтобы удовлетворить соответствующему требованию к работе анализатора?
*)

latin letter = "A" |… | "Z" | (* octal analog *) "u0041" |… | "u005a"
| "a" |… | "z" | (* octal analog *) "u0061" |… | "u007a";

keyword =
"abstract" | "continue" | "for" | "new" | "switch"
| "assert" | "default" | "if" | "package" | "synchronized"
| "boolean" | "do" | "private" | "this"
| "break" | "double" | "implements" | "protected" | "throw"
| "byte" | "else" | "import" | "public" | "throws"
| "case" | "enum" | "instanceof" | "return" | "transient"
| "catch" | "extends" | "int" | "short" | "try"
| "char" | "final" | "interface" | "static" | "void"
| "class" | "finally" | "long" | "strictfp" | "volatile"
| "const" | "float" | "native" | "super" | "while"
| (* reserved *) "goto" ;
(*
ВОПРОС_5: уточним у ПЗ — правильно ли считать, что deprecated "goto" следует рассматривать как недопустимое наименование для параметра и метода?
*)

boolean literal = "true" | "false";

null literal = "null" ;

С анализом и коррекцией грамматики закончили. Осталось уточнить несколько нюансов.

В УСЛОВИИ: "идентификаторы, соответствующие требованиям java"
ПРИМЕЧАНИЕ_2: java-идентификаторы теоретически могут иметь неограниченную длину. Но на практике, очевидно, ограничение имеет место в соответствии с небесконечными аппаратными/системными ресурсами проверочного комплекса (тестового стенда). Например, если тестовые наборы планируется вводить через web-интерфейс, надо учесть специфику браузера и сервера, накладывающую ограничение в соответствии с допустимыми размерами пакетов GET или POST запросов, посредством которых будет подаваться тестовый вариант на вход анализатору.
Для работы с граничными условиями необходима соответствующая информация, — запрашиваем её.
ВОПРОС_6: Обращаемся к ПЗ (или, через него к экспертам, знающим характеристики среды, где будут тестировать анализатор):
6.1 дать оценку МАX'имальной длинны текста корректного тестового варианта, при подаче которого на вход лексического анализатора не произойдёт искажения входного набора или, (если декларация будет передана без искажений), не произойдёт сбоя работы программы анализатора.
6.2 Если тестовые наборы должны быть подготовлены в файле, размещаемом на серверной стороне, каков должен быть его МАX'имально допустимый размер (в рамках вопроса о свободном пространстве на диске, необходимом для нормальной работы программы анализатора).
Спрашиваем ПЗ — может ли быть предоставлена конкретная информация по пп 6.1, 6.2? Иначе, или проверку на max граничное условие не выполняем или придётся описывать методику выявления верхней границы длинны текста отдельной декларации (с успешной проверкой) опытным путём в процессе проверки. В последнем случае потребуем от ПЗ сформулировать это дополнительной подзадачей в рамках исследования анализатора!

ПРИМЕЧАНИЕ_3: ПЗ обращает внимание на то, что для выполнения задания не требуется специальных знаний, имеющих отношение к тестированию белого ящика.
ВОПРОС_7: Зная, сколько разновидностей тестирования существует вне рамок белого ящика и какие знания там нужны, срочно уточняем — правильно ли мы поняли, что в задании требуется предоставить только тестовые наборы деклараций и не нужно подготавливать методику тестирования, например, с описанием организации подачи параллельных потоков на вход анализатора, проведения контроля утечки памяти, измерения быстродействия и прочих характеристик, связанных с нагрузочным тестированием или оценкой безопасности и т.д.? Иначе – потребуем ПЗ сформулировать это дополнительной подзадачей в рамках исследования программы анализатора (и предупредим, что это потребует отдельного согласования)!

Таким образом, нами проведена экспертиза задания, включая предложения по его коррекции.
Было важно не оставить "дыр" в будущем покрытии тестовыми наборами (а это уже дело техники, за рамками данной статьи, хотя и здесь не всё так просто… на эту тему написаны научные труды).
Остаётся обратиться к ПЗ с просьбой прокомментировать 7-мь вопросов и 5-ть замечаний (см. выше) для уточнения: требований задачи; необходимой документации; специфики, накладываемой средой тестирования и ожидаемыми видами тестирования, т.е. согласования её понятного и однозначно трактуемого обеими сторонами корректного условия.

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

От того, насколько полным и грамотным будет ответ ПЗ, зависит, быть или не быть качественному решению задачи.

Автор: testopatolog

Источник