pi314

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

На собеседовании я обычно прошу выбрать из послужного списка какой-нибудь один проект (на усмотрение самого кандидата - наиболее крутой: в котором было найдено какое-нибудь особенно интересное решение, или использованы какие-нибудь крутые технологии, или решена какая-нибудь нетривиальная задача... короче, которым он сам гордится) и рассказать о нем подробнее, но, опять же, не в смысле, какие именитые были заказчики или как необъятен был бюджет, а в смысле, что он любимый в нем конкретно сделал, чему научился и чего добился. Обычно уже сам выбор достаточно показателен. (Если чел собеседуется, например, на синьера JEE, а в качестве темы выберет написанный в старших классах школы сайт на PHP, на котором была особенно удачная фотография кошки - это уже повод задуматься.)

А дальше, по мере рассказа, начинаю задавать уточняющие вопросики (на вшивость): ага... тесты писали... а какое было покрытие? А как определяли? А в каком порядке выполнятся тесты из одного класса?.. Так, так... JBoss... а какая версия использовалась? Дескрипторы или аннотации? А что нового появилось в следующих версиях? А сервлеты вручную писали? ...ага, SOAP. А из каких трех частей состоит WSDL? А моки в SOAPUI делали? Ну, и далее - вглубь или вширь, по мере объема знаний кандидата.

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

И вторая: из резюме зачастую сложно даже предположить уровень "погружения" в отдельные технологии. В беседе удается точно выяснить предположительные сильные стороны кандидата и тогда уже задавать конкретные вопросы, позволяя ему раскрыть глубину познаний.

Еще по поводу отдельных технологий, о которых заходит речь, прошу кандидата оценить свои познания в ней по пятибальной шкале "1 - первый раз слышу, 5 - эксперт". Для экспертов у меня заготовлены конкретные вопросы из жизни, как правило, примеры кода, иллюстрирующие какую-нибудь нетривиальную хреновину, которые я тут же достаю из папочки и предлагаю совместно разобрать. Эксперт в Яве - хорошо! Давай побеседуем о медели памяти, сборщиках мусора или кеше процессора. Эксперт в SQL - замечательно! Давай попробуем оптимизировать запрос. Эксперт в сетях - чудесно! Давай разберемся, почему падает вот этот долбаный сокет. Опять же, цель этого подхода - отнюдь не завалить самоуверенного кандидата, а именно понять, как человек мыслит, как ищет решения проблем, достаточно ли у него для этого знаний и опыта. Не беда, если кандидат погорячился с самооценкой... тут важно не знание ответа, а именно подход к решению проблемы (т.к. от синьера именно таки ожидается решение проблемы, а не констатация ее сложности).

Если только двигатель не на сверхбыстрых фуфлонах, ускоряемых торсионными полями, то "чтобы всё было как по-настоящему" нужно учитывать уменьшение массы, неизбежно имеющее место быть по мере работы двигателя :)

Знак % перед javac убрать, и будет счастье (если, конечно, остальные пути правильные).

Если непонятно почему: пример приведен для unix-подобной системы с каким-нибудь csh или tcsh шелом. Это видно уже хотя бы из делимитеров файлов (прямой слеш). А знак % просто символизирует, что команда javac вводится в ответ на приглашение шела, коим он и является. Под Виндой его, разумеется, писать не нужно :)

Смотря для какого "долгого использования"... Если втечении следующих пятнадцати лет 10 раз измерить напраяжение в розетке и 5 раз прозвонить подозрительный предохранитель, то подойдет любая китайщина за пару десятков енотов.

А если для регулярной серьезной работы, то существyeт, в принципе, FLUKE (и еще, может, Agilent)... и все остальное :) Приличный мультиметр (если только речь именно о портативном, а не о настольном приборе) стоит пару сотен долларов. В любом случае желательно иметь прибор c т.н. true RMS, типа Fluke 117, Fluke 17B, Fluke 87, Fluke 289.

Если бюджет не позволяет взять что-то нормальное (или нет потребности), то остаются китайцы, типа тех же Vichi, UNI-T и т.д... однако, не стоит ожидать чудес - за пару десятков енотов не бывает того же качества, что за пару сотен :)

Среда разработки - это: комната/стул/стол - комп/клавиатура/мышка - ОС/сеть - редактор (возможно, IDE) - используемый язык программирования - (возможно, используемые frameworks и/или библиотеки) - (возможно, другие системы: репозиторий, continuous integration server и т.д.).

Framework - это (возможно!), набор библиотек/API и конвенций о том, как и для чего ими пользоваться при создании программ. Хотя, сам этот термин несколько шире. Вполне корректно было бы сказать, что Тостер предоставляет нам framework для получения ответов на вопросы, а мы им пользуемся. Мы, конечно, могли бы поступать иначе, например, бросать вопросы в море в запечатаной бутылке, указывать на Тостере координаты "вброса", а ответы (если бутылку захотелось и удалось таки выловить!), отправлять голубиной почтой. При этом мы достигали бы той же цели, хотя, и с несколько большими усилиями. Но при полном и правильном использовании framework, предоставляемого Тостером (т.е. при следовании правилам и договоренностям), это ощутимо быстрее и удобнее :)

Все замечательно, только вот обрабатывать пришедшие данные в простейшем случае нужно не на 'data', а на 'end'! А на 'data' нужно тупо (еще лучше - умно!) накапливать пришедшие данные и продолжать верить в светлое будущее, т.е. в то, что когда-нибудь придет 'end'.

Тогда, если совсем тупо, то как-то так:

var data = '';
tcp.on('data', function(chunk){
  data += chunk;
});

tcp.on('end', function(){
  parseAnswer(data);
  ...
});

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

Но есть еще два момента.

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

Второй. Написанное выше справедливо только для односторонней передачи через сокет. Если же через тот же сокет нужно слать ответ или др. данные, то делать это нужно иначе. (На случай, если "socket.emit('cl_stat1');" в коде имеет отношение к этому же сокету.) Тогда нужно самому определять (на 'data'), когда закончились данные клиента (а для этого нужно знать протокол обмена, в простейшем случае - признак конца пакета, который искать в данных), и слать ответ, и потом уже, если нужно, самому закрывать сокет. Тогда событие 'end' не поможет, т.к. оно прилетает только, если сокет на другом конце уже сам пытается закрыться.

var data = '';
tcp.on('data', function(chunk){
  data += chunk;
  if(packetComplete(data)){
    parseAnswer(data);
    ...
    sendResponse();
  }
});

В 64К тоже нет ничего волшебного. В любой ОС между сокетом "в программе" и сетью есть как минимум один буфер. Разные языки предоставляют разные средства воздействия на него, либо вызов flush(), блокирующий, пока данные не будут физически отправлены, либо, как нод, чей метод socket.write()

Returns true if the entire data was flushed successfully to the kernel buffer. Returns false if all or part of the data was queued in user memory. 'drain' will be emitted when the buffer is again free.
The optional callback parameter will be executed when the data is finally written out - this may not be immediately.

B принципе, данные могут приходить частями любого размера. Если программист сам не заботится о моменте отправки (а это далеко не всегда полезно!), буфер отправляется, как только заполнился. И то же самое справедливо и для приема. Прикиньте, что бы было, если бы через сокет слали не несколько десятков K, а, скажем, 10 GB, а в системе, скажем, на все про все (включая нод) всего 4 GB? Откуда бы было взять бедному ноду столько памяти, чтоб потом за рaз отдать все одной строкой - не в магазин же сбегать... Отсюда и многочисленные события 'data' при приеме "одной, но большой" строки.

Так что, вопрос, по сути, нужно бы было назвать "Как работать с сокетами" :)

Вообще, это делается как-то так:

1. Формулируются ожидания с т.з. бизнеса. В данном случае понятие "дико медлено" нужно выразить как-то объективно. Например. Имеем: поиск по ключевой фразе А при объеме данных Х заниманет N секунд. Поиск по ключевым фразам типа Б вообще невозможен. Требуется: поиск по фразе А и Б должен занимать не более N/10 секунд для объема данных до Х*1000.
Формулируются внятные тесткейсы и пишутся тесты производительности, позволяющие позже проверить, достигнуты ли эти ожидания.

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

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

4. Пишется альтернативная имплементация, которой на стенде заменяется "старая", прогоняются тесты (по функционалу и производительности). Если все прошло удачно - архитектору премию и выкатываем на продакшн. Если облом - архитектору выговор, и все сначала :)

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

Тем более, что ответ на вопрос легко получается простейшим рассчетом. КПД чайника можно принять за 95~98%, КПД микроволновки - около 60%. И далее в полном соответствии со школьной физикой - сколько произвели работы, на столько увеличили температуру :)

Если же охота таки насиловать микроволновку, не проверяя температуру термометром (что, кстати, само по себе довольно проблематично, т.к. лабораторные термометры на такой диапазон температур ртутные, или от датчика идет провод... про ИК камеру вообще мочу), то "кипятите" хотя бы сильно газированную воду или насыпьте в нее немного песка, или опустите в нее деревянные палочки - короче, чтоб в ней могли образовываться пузырьки. В чайнике это происходит естественным образом засчет конвекции, а в микроволновке вода нагревается равномерно по всему объему, и для видимого "закипания" (образования пузырьков), ей нужна помощь.

Вот как это выглядит с т.з. работодателя

Джун
- собеседование
изъясняется исключительно на сленге (большую часть которого не может внятно объяснить), готов в одиночку за неделю написать новую ОС, или две - за полторы, если только для этого не придется учить ассемблер, несмотря на юный возраст уже обладатель прав на обе версии и один бэкап личного сайта с фотографией кошки в розовой рамке и знает, что синглтон - это абсолютное зло, хотя и не может написать его без ошибок.
- испытательный срок
долго мудохается с настройками рабочего места, которые регулярно слетают под тяжестью многотысячных плагинов, шелов и скринсейверов, донимает админов, находит две (орфографические) ошибки в документации проекта и один быстрый альтернативный способ сделать форк из SVN, после которого проект, к сожалению, не билдится не только у него, но и у всей команды. Берется все немедленно исправить с помощью другого чудотворного плагина, (неожиданный баг в котором приходится фиксить двум миддлам), после чего насильственно лишается рута, плагинов и шелов и начинает изучать проект под чутким контролем матерящихся миддлов.
- работа
научился билдить проект, писать тесты и коммитить, не роняя этим билд, понял смысл многих сленговых выражений, подружился с миддлами и админами, не путается в названиях ключевых технологий, радикально сократил число плагинов, удалил сайт с кошкой, работает.

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

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

Процессор - это не просто электронная схема, по элементам которой течет ток, а логическая, или, цифровая схема. Это значит, что в зависимости от того, есть или нет напряжения в каком-то ее "месте", это самое "место" находится в одном из двух четко враженых состояний . Эти состояния мы и принимаем условно за 1 и 0. Назовем такое "место" - ячейкой памяти. Памяти - потому, что если в схеме ничего больше не будет изменяться, то эти значения останутся там, пока мы не выключим питание, и мы всегда сможем их еще раз узнать.

Мы договорились, что с помощью этих 1 и 0 мы будем кодировать числа, в двоичной системе, (а с помощью чисел будем кодировать все остальное - буквы, цвета, уровень громкости и т.д.) Таким образом, если мысленно выстроить в ряд (назовем его регистром), скажем, 8 таких ячеек (а мы помним, что про каждую из них мы можем точно сказать, там сейчас 1 или 0; например, измерить напряжение вольтметром), мы получим 1 байт, в котором может быть закодировано число от 0 до 255 примерно так:

0 - 00000000
1 - 00000001
2 - 00000010
3 - 00000011
и т.д. вплоть до
255 - 11111111

Далее. Т.к. все ячейки соединены между собой определенным образом, то от наличия или отсутствия напряжения в одном месте напрямую зависит, в каком состоянии будет соседнее с ним место... что-то вроде шестеренок в часах - если повернуть одну, так или иначе повернутся все остальные.

Несколько упрощая, можно сказать, что для построения процессора достаточно три таких "определенных образа" соединения ячеек (схем, или видов логических элементов):

1. Если две ячейки соединены в схему инвертор, это означает, что если в одной из них сейчас есть напряжение (1), то в другой его точно нет (0), и наоборот.
2. Если три ячейки соединены в схему И, то в одной из них есть напряжение (1) только тогда, когда оно есть в двух других. И, наконец,
3. схема ИЛИ - в одной из трех ячеек напряжение есть только, если оно есть хотя бы в одной из двух соседних.

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

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

Далее из таких схем-кирпичиков выстроены более сложные схемы: сдвигающие регистры, сумматоры, компараторы, и, собственно, АЛУ. Его образно называют сердсем процессора, но на самом деле это его мозг. Это то, чем процессор выполняет программу. Очень сильно упрощая, его работу можно представить себе так:

Есть некий регистр, в котором сейчас находится код операции (некое закодированное число). Оно определяет, что конкретно АЛУ сейчас, вот на этом шаге должно делать, например, складывать. И есть еще два регистра, в которых находятся закодированные числа, например, 2 и 3. Эти регистры подключены к АЛУ. В такой ситуации АЛУ, выполняя шаг, складывает числа из регистров данных (2 и 3) и помещает результат (5) в первый из них (теперь там уже не 2 а 5), а в регистр операции - следующую инструкцию. Так процессор выполнил один шаг программы и готов к следующему.

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

Ну, и, наконец, осталось выяснить, а что же такое этот шаг и что заставляет процессор совершать отдельные шаги?

Заставляет всю эту кухню крутиться тактовый генератор. Вот его было бы правильно называть сердцем. Это такая другая схема, построенная на кристалле кварца, которая ничего иного не делает, как очень быстро выдает то 1 то 0. Очень быстро - это те самые МГц и ГГц, которыми любят меряться владельцы крутых компьютеров, т.е. скорость, с которой процессор совершает шаги. Выход тактового генератора напрямую подключен к нужным частям всей схемы, и выдаваемые им 1 и 0 - это то самое, что и приводит всю схему в действие, заставляя все логические элементы переключаться по цепочке и изменять значения отдельных ячеек согласно заданной нами логике... и программе.

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

UPD: Несколько поверхностная, но весьма наглядная статья о схемотехнике логических элементов на Хабре.

...а потом у пользователя угоняют эту куку, и начинается веселуха со всеми отягчающими. Так что, сделать-то, оно, конечно можно, но определенно - не нужно (ибо этот вариант уступает по надежности даже обыкновенной сессии php)!
Если уж хочется как-то выпендриться на тему секюрити сессии, то, по крайней мере, в каждом ответе выдавать новый токен и потом только по нему идентифициривать сессию. И все это, разумеется, под SSL.

А, вообще, детство это все... SSL с двухсторонней авторизацией - вот в чем залог счастья :)

Для реализации модульности и слабой связанности. Интерфейс - это, по сути, контракт (на "поставляемое" множество и сигнатуры методов).

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

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

Классический пример правильного использования интерфейсов - явовские коллекции. Прикиньте, учитывая соображения выше, какой бы это был геморой в использовании, если бы API было сделано не через интерфейсы, а через абстрактные классы :)

1. IP сайта показывает DNS
2. Хреново определяют. Ввел IP, на котором точно висит несколько сайтов - ничего не нашли. Отсюда можно сделать вывод, что, возможно, некая база, накапливаемая по ходу дела.

Вот точно такие и соответствуют, только называются иначе:

1)
en: (product / customer) requirement specification
de: Lastenheft

2)
en: functional specification
de: Pflichtenheft

Первый документ (в теории!) составляет заказчик. В нем он, так сказать, описывает суть проблемы, которую нужно решить, и свои ожидания от решения.

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

Примеры ищите типовые - т.к. реальные документы являются частью соотв. контрактов и, тем самым, коммерческой тайной, никто их Вам просто так не даст.

Если звук частоты 50Гц, то очень смахивает на проблемы с электропроводкой в доме (где-то оборван "ноль"). Если так, будьте осторожны! При неудачном стечении обстоятельств, если взяться одной рукой за флешку, а другой - за батарею иди водопроводную трубу, можно получить нехилый удар током. Проверьте наличие "гудения" в других зданиях.

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

Тыц - тыдыц.

P.S. Только, когда возьмут за одно место, не говорите, что вас не предупреждали о незаконности того, что вы планируете ;)

Если имеется ввиду платиновый терморезистор, то сам по себе он не дает никаких читабельных значений, тем более - температуры. Однако, его сопротивление довольно точно соответствует температуре (при 0°С - 100 Ом, при 20°С - 107.79 Ом и т.д.)

Таким образом, это сопротивление сначала нужно измерить. Но контроллер не умеет мерять сопротивление - только напряжение. Значит, нужно измерить падение приложенного к резисторy эталонного напряжения и пересчитать в сопротивление по закону Ома.

Потом полученное сопротивление нужно пресчитать в температуру (по документации конкретного датчика). Вот оно уже будет читабельным и его можно загонять на экран :)

offtop: откуда в деревне Простоквашино взялась городская библиотека?

А по сути - два соображения:

1. Скрипты создания таблиц некорректно называть SQL, т.к. SQL - язык запросов к данным, а его расширение для манипуляции структурой БД, на котором пишутся эти скрипты, называется DDL (Data Definition Language).

2. И, наконец, с непривычки решать такие задачи лучше графически... А потом уже писать скрипты.

<form>
 <fieldset>
  <legend>Personalia:</legend>
  Name: <input type="text"><br>
  Email: <input type="text"><br>
  Date of birth: <input type="text">
 </fieldset>

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

Поясню на примере. На Тостере есть функционал, позволяющий использовать некоторые HTML тэги в тексте ответа и комментария. Тесткейс для этого функционала может выглядеть (упрощенно) так:
-----
ID: UI1234
Author: V. Pupkin
Category: UI, manual, validation
Description: HTML тэги в тексте ответа
Precondition: Сервер запущен и доступен, В списке есть хотя бы один вопрос, Пользователь авторизован
Steps: Выбираем вопрос из списка. В поле ответа набираем текст, в котором используем [список] и др. HTML тэги, после чего нажимаем кнопку "Отправить".
Expected: Введенный текст отображается полностью, HTML тэги [разрешенные] отображаются соотв. разметкой, все прочие тэги игнорируются.
Postcondition: Сервер все еще доступен, кол-во вопросов в списке не изменилось, в ЦОД не возник пожар и т.д.
-----
Соответственно, если при исполнении теста что-то не не выполнилось (разметка не отобразилась, сгорел ЦОД или ответ удалось написать без авторизации - не важно, что именно), тест считается проваленным.

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

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

Ну, а тест-план - это вообще из другой оперы. Это документ, в котором подробно и основательно описывается, какие части системы как именно (и почему именно так) мы тестируем, что нам это дает (и что не дает) и обосновывается, почему такой подход обеспечивает требуемое качество продукта. Его обычно составляют совместно архитектор/техлид и ответственный QA в процессе разработки.