Разглеждане на задачата на примера на задачата за проверка на анализатора на RBNF декларации
Уважаеми колеги, в какво се изразява професионализмът на тестера в подхода му към решаването на следващата задача? В способността своевременно да компенсирате липсващите знания, да се потопите „до дъното“ в неговия контекст; идентифицирайте несигурностите/неправилността в неговата формулировка, ясно формулирайте „недоразуменията“ и елиминирайте всичко това, когато се съгласявате.
В тази статия ще дам подробна илюстрация как да се проведе проверка на задача за тестване.
За какво? Честно казано, не познавам много теория за развитието на гореизброените професионални качества. За мен тестването е изкуство, до което искам да се докосна тук, както и да се уча от вас от тези, които по-късно правят добри коментари или допълнения.
Подгответе тестови пакети за тестване на лексикален анализатор, който анализира декларации от следната форма (в предложената RBNF нотация):процедура ([
- идентификатори, които отговарят на изискванията на java. PP изтъква, че задачата не изисква специални познания, свързани с програмиране или тестване в бяла кутия.
Нашата цел е да извършим проверка на тази задача и да я направим чувствително по отношение на ПП.
Така че ще трябва да потърсим и проучим (или да освежим) съответните спецификации: 1. ISO/IEC 14977:1996(E) - Спецификация на метаезика, разширена форма на Backus-Naur 2. Спецификацията на езика на Java, издание на Java SE 7 - документация на езика JAVA v1.7
ЗАБЕЛЕЖКА_1: съгласни сме с PP - тези материали подходящи ли са за изпълнение на задачата, списъкът им достатъчен ли е за решаване?!
В процеса на анализиране на спецификациите и предоставеното състояние на проблема става необходимо да се изясни изложението на проблема, да се коригира, за да се отървете отнеясноти.
(* ЗАБЕЛЕЖКА_2: в оригиналното правило редът веднага привлича вниманието: "процедура ([
>]);." Което е критично тук: 1.1 във фрагмента "процедура" липсва знак за равенство между процедурата на идентификатора и нейната дефиниция, т.е. изразът вдясно от нея; 1.2 във фрагмента "
" запетая може да се третира като знак за конкатенация; 1.3 във фрагмент "
>]);." всеки от последните два знака може да се третира като завършващ израз; 1.4 използването на ъглови скоби " " е остаряло, не е в стил на разширен синтаксис. *)
процедура = тип на връщане, празно място, име на метод, отваряща скоба, аргументи, затваряща скоба, точка и запетая;(* КОМЕНТАР_1: тук, в предложената версия, неяснотите са разрешени според нашето разбиране за RBNF и представяне, както например декларацията на метод изглежда в java програма, но ако грешим, молим PP да ни коригира!
празно = " "(* аналогов код *)"\u0020";(* ЗАБЕЛЕЖКА_3: вярваме, че трябва да се използва само един интервал в първия ред на граматиката на подходящите места и нови редове и т.н. не са разрешени. В противен случай молим PP да ни коригира тук и в бележки 4 и 5 по-долу! *)
args = [ arg, < comma, blank, arg >];(* ЗАБЕЛЕЖКА_4: подписът може да е празен или да съдържа от една до безкраен брой двойки тип параметър Име на параметър. Разделителите между двойките са „запетая и един интервал“ *)
arg = тип параметър, празно, име на параметър;(* ЗАБЕЛЕЖКА_5: разделител „един интервал“ между типа параметър и името на параметъра *)
запетая = ","(* аналогов код *)"\u002c";
точка и запетая=";"(* аналогов код *)"\u003b";
отварянескоба = "("(* аналогов код *)"\u0028";
затваряща скоба = ")"(* аналогов код *)"\u0029";
връщане тип = ("v" "\u0076"), ("o" "\u006f"), ("i" "\u0069"), ("d" "\u0064") ("i" "\u0069"), ("n" "\u006e"), ("t" "\u0074");(*char или код смесза "void" "int" * )
параметър тип = ("i" "\u0069"), ("n" "\u006e"), ("t" "\u0074") ("l" "\u006c"), ("o" "\u006f"), ("n" "\u006e"), ("g" "\u0067");(*сигнал или смес от кодовеза "int" "long" *)
(* В УСЛОВИЕТО: "идентификатори, които отговарят на изискванията на java" По-нататък, от гледна точка на RBNF, ще разберем какво трябва да се има предвид с това. *)име на параметър = идентификатор на Java;(* име на параметър *) tor: 2.1 третира като валидна декларация, която има същите имена на параметри? 2.2 разпознава аргументите като различни, ако техните имена се състоят от едно и също набор от символи, но те се различават по регистър? 2.2 дефинира като валидна декларация, която има еднакви имена за метод и неговия параметър? този резултат зависи ли от различен регистър?
ЗАБЕЛЕЖКА_1: Въпросите тук и по-долу очевидно са необходими за формиране на положителни и отрицателни тестови случаи.
ПРИ УСЛОВИЕ: "изпълнението на тази задача не изисква специални познания, няма нищо общо с програмирането" Отново с въпроси към ПП, изключваме неясноти в задачата. QUESTION_3: правилно ли разбираме, че в задачата в
конструкции не трябва да се разглеждат: 3.1 многоточие преди името на последния аргумент в подписа (т.е. метод с променливо числопараметри, които анализаторът не разпознава като валидни)? 3.2 присвояване на стойности след посочване на името на параметъра (т.е. метод с предварително зададени стойности на параметрите по подразбиране също не трябва да се разпознава)? *)
име на метод = java идентификатор;(* име на метод*) (* Граматичните правила за именуване на параметри се прилагат за имената на методите *)
java > (* Представяме на вниманието на PP конкретно правило за генериране на идентификатор въз основа на анализа на документацията на java 1.7 *)
дефиниция = java буква, < java letter java digit >;(* COMMENT_2: обхватът на дефиницията е такъв, че не е необходимо да се изключват следните два набора правила: spec simbol = "[" "]" "(" ")" "" "." "," "
" "!" "?" "@" "#" "%" "^" "&" "*" "+" "-" "=" ":" ";" "\"" "'" "`" "" "\" "/" " "" (* и техния кодов аналог /не е показан тук/*); изходна последователност = "\b" "\t" "\n" "\f" "\r" "\"" "\'" "\\" (* и техния кодов аналог /не е показан тук/*); но те (и не само тях) трябва да се имат предвид за в бъдеще, за да се изградят отрицателни множества. *)
java буква = латинска буква кирилица буква спецификация буква;(* JAVA v1.7 поддържа напълно UNICODE v6.0 в имена на параметри или методи, което включва почти всички съвременни скриптове, включително: арабски; арменски; бенгалски; бирмански; глаголица; гръцки; грузински; деванагари; иврит; кирилица; китайски; коптски; кхмерски; латински, тамилски, корейски (хангул), Cher okee, етиопски, японски (в допълнение към китайските знаци, сричковата азбука) и много други.моля: 4.1 посочете кои конкретни международни речници все още трябва да бъдат свързани за проверка, за да се изпълни съответното изискване за анализатора? 4.2 за изясняване дали има ограничения в изискванията, съответно за всяка операционна система и т.н. от средата, където трябва да се изпълни програмата на анализатора? *)
латинска буква = "A" … "Z"(* аналогов код *)"\u0041" … "\u005a" "a" … "z"(* аналогов код *)"\u0061" … "\u007a";
кирилска буква = "A" ... "Z" "a" ... "z"(* аналогов код *)"\u0410" ... "\u044F" "Ё" "ё"(* аналогов код *)"\u0401" "\u451";
спец. буква = "$"(* аналогов код *)"\u0024" "_"(* аналогов код *)"\u005f";
java цифра = "0" … "9"(* аналогов код *)"\u0030" … "\u0039";
ключова дума = "abstract" "continue" "for" "new" "switch" "assert" "default" "if" "package" "synchronized" "boolean" "do" "private" "this" "break" "double" "implements" "protected" "throw" "byte" "else" "import" "public" "thro ws" "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" ( * запазено *) "goto";(* тук за всяка дума не е дадена, но съответната конструкция се подразбираchar или code mix*) (* QUESTION_5: проверете с PP - правилно ли е да се счита, че отхвърленото "goto" трябва да се счита за невалидно име за параметър и метод? *)
булев литерал = "true" "false";(* не е посочено тук, но се подразбирасъответстваща конструкцияchar или смес от кодове*)
нулев литерал = ("n" "\u006e"), ("u" "\u0075"), ("l" "\u006c"), ("l" "\u006c");(*сигнал или смес от кодовеза "null" *)
Приключих с анализа и граматичната корекция. Остава да изясним няколко нюанса.
ПРИ УСЛОВИЕ: "java-съвместими идентификатори" ЗАБЕЛЕЖКА_2: Java идентификаторите теоретично могат да имат неограничена дължина. Но на практика, очевидно, ограничението се осъществява в съответствие с ограничените хардуерни / системни ресурси на тестовия комплекс (тестов стенд). Например, ако се планира тестови пакети да се въвеждат през уеб интерфейс, е необходимо да се вземе предвид спецификата на браузъра и сървъра, което налага ограничение в съответствие с допустимите размери на GET или POST пакети заявки, чрез които тестовият случай ще бъде подаден към анализатора като вход. Необходима е подходяща информация за работа с гранични условия - изискваме я. ВЪПРОС_6: Обръщаме се към PP (или чрез него към експерти, които познават характеристиките на средата, в която анализаторът ще бъде тестван): 6.1 за оценка на максималната дължина на текста на правилен тестов вариант, когато се подаде на входа на лексикалния анализатор, входният набор няма да бъде изкривен или (ако декларацията се предава без изкривяване), програмата на анализатора няма да се срине. 6.2 Ако тестовите пакети трябва да бъдат подготвени във файл, хостван от страната на сървъра, какъв трябва да бъде неговият МАКСИМАЛЕН размер (по отношение на свободното дисково пространство, необходимо за нормалната работа на програмата за анализатор). Питаме PP - може ли да се предостави конкретна информация за параграфи 6.1, 6.2? В противен случай или граничното условие не се проверява за max, или трябва да опишемметод за идентифициране на горната граница на дължината на текста на отделна декларация (с успешна проверка) емпирично в процеса на проверка. В последния случай ще изискаме от PP да формулира това като допълнителна подзадача в рамките на изследването на анализатора!
ЗАБЕЛЕЖКА_3: PP обръща внимание на факта, че задачата не изисква специални познания, свързани с тестването на бялата кутия. ВЪПРОС_7: Знаейки колко вида тестване има извън бялата кутия и какъв вид знания са необходими там, ние спешно изясняваме - разбрахме ли правилно, че в задачата се изисква да се предоставят само тестови набори от декларации и не е необходимо да се изготвя методология за тестване, например с описание на организацията на доставяне на паралелни потоци към входа на анализатора, контрол на изтичането на памет, измерване на производителността и други характеристики, свързани с тестване на натоварване или оценка на сигурността, и т.н.? В противен случай ще изискаме от PP да формулира това като допълнителна подзадача като част от проучването на програмата на анализатора (и ще ви предупредим, че това ще изисква отделно одобрение)!
P.S. Зависи от това колко умни и точни са били въпросите на тестера, дали искат да прехвърлят съответната задача в ръцете му за изпълнение.
От това колко пълен и компетентен ще бъде отговорът на ПП зависи дали ще има или не качествено решение на проблема.