Урок 5. Слайд 252-254

Давненько не было переводов. Надо наверстывать.
Поехали:

Урок 252
Мы можем посчитать все возможные пути используя правила, которые мы изучили несколько слайдов назад.
Допустим, переменная V1 содержит все возможные пути от A до X. Их пять.
Теперь допустим, что переменная V2 содержит все пути от A до X, включающие петлю.
Их 25 если мы пройдем петлю дважды. Из 125 если мы пройдем петлю трижды.
Если у нас будет возможность пройти петлю 20 раз, то мы получим больше 100 триллионов последовательностей.

Урок 253
Очевидно, что все эти пути проверить нельзя.
Большинство людей проверит 5 путей от A до X. Затем добавит случай двадцатикратного прохождения петли по одному и тому же пути.
Этот тест проверит все ветви, все простые пути программы. Но будет ли его достаточно?
Допустим, у нас есть утечка памяти на определенном шаге программы. Если мы пройдем его 10 раз подряд, то программа упадет с переполнением. Если только мы не тестируем, используя мониторинг памяти, мы не заметим утечки, пока программа не начнет себя некорректно вести, например медленно работать или падать. И этот баг обнаружит только тест, проходящий через определенный шаг 10 раз. Тест, проходящий любое количество раз через другие шаги не обнаружит этот дефект.

Если у вас нет подозрений на утечку памяти, как много тестов вы проведете, пока не пройдете определенный шаг программы 10 раз и не обнаружите проблему? Их может быть очень много.
Позвольте мне усложнить ситуацию. Допустим на другом пути есть шаг, вызывающий очистку памяти. И он чистит память, утекшую благодаря багу.  Теперь программа упадет только в том случае, если мы 10 раз прошли по одному блоку и ни разу не прошли по второму.
Только небольшой процент из 100 триллионов тестов обнаружит этот баг, так что у вас должна быть или большая выборка или большое везение, чтоб найти этот баг.
Допустим, что случай еще более особенный и очистка памяти - наиболее вероятный путь использования программы.
Как вы думаете, в таком случае, вы вообще создадите тест, который сможет найти этот дефект?

Урок 254
Когда я задаю этот вопрос, студенты обычно отвечают "нет". Так говорят очень опытные и профессиональные тестировщики. Если вы говорите нет, что этот тест слишком сложный, слишком редкий и специфический, то вы в хорошей компании.
Итак просуммируем. Я показал вам, что вы не сможете проверить все возможные пути. И продемонстрировал случай, при котором, в теории, вы пропустите серьезный баг.
Но многие люди считают этот случай нереалистичным. Он никогда не случится в реальной жизни и представляет лишь академический интерес.
Отличный момент вспомнить правило о редких случаях. "Никто не будет этого делать" не означает, что никто не будет этого делать. Это значит "Никто, кого я сейчас могу себе представить не имеет причин, которые я сейчас могу себе представить, чтоб так сделать".
Тестирование - опыт скромности, оно раз за разом показывает нам, как на самом деле ограничено наше воображение.

Подарков пост

Комрады из сети подкинули идею для подарка.
Устремился и немедленно приобрел:

Памяти пост

Конец года - время отдавать долги.
Сегодня отдал один долг.
Наконец сходил и починил часы, которые носил мой дед, а затем отец.
Теперь они у меня.

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

Представительскую функцию часов всерьез не воспринимал и, надеюсь, не буду.

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

А еще эти часы - прошедшее через полвека рукопожатие деда, которого я не видел.

Часы Слава, 21 камень, механизм 2414, если я не ошибся. Сделано в СССР.

О книгах

Дочитываю Богадельню Олдей.

Не ахейский цикл, но тоже достойно. Кроме прочего, разница - в атмосфере.
Богоравные - под ярким солнцем, ихор вместо крови, гроза над морем.
Хенингцы не хуже, но уже немного устали.
И идет дождь.
Как-то так:

Скиталась осень в слепом тумане -
Дождь, град, и пуста сума...
Тропа вильнет, а судьба обманет -
Ах, в пути б не сойти с ума!

Иди, бродяга, пока идется -
Дождь, град, и пуста сума...
Луна упала на дно колодца -
Ах, в пути б не сойти с ума!

Грехи черствеют вчерашним хлебом -
Дождь, град, и пуста сума...
Хочу направо, бреду налево -
Ах, в пути б не сойти с ума!

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

Монах стращал меня преисподней -
Мол Мор, и глад, и вокруг тюрьма!
Монаху - завтра, а мне - сегодня!
Ах, в пути б не сойти с ума...

Господь Всевышний - моя опора!
Дождь, и град, и пуста сума...
Приют неблизко, покой не скоро,
Ах, в пути б не сойти с ума!..

К чему скорбеть о судьбе бродяги?
Дождь, град, и пуста сума...
Я гол и чист, словно лист бумаги, -
Ах, в пути б не сойти с ума!..

Мне нет удачи, мне нет покоя -
Дождь, и град, и пуста сума!
Пожму плечами, махну рукою -
Ах, в пути б не сойти с ума!..

Мои две клячи в дороге длинной -
Дождь, град, и пуста сума! -
Душа и тело, огонь и глина...
Ах, в пути б не сойти с ума!..

Международных стандартов пост

Вот тут ребята шутят, позволю себе уточнить и дополнить:

Предлагаю при оценке сложности реализации архитектурных решений пользоваться международной классификацией

• МКБ-10 R51 Головная боль
• МКБ-10 I84.9 Геморрой без осложнения не уточненный
• МКБ-10 I84.8 Геморрой с другими осложнениями не уточненный
• МКБ-10 R98 Смерть без свидетелей

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

Сомнений пост

Как думаете - выстрелит?
Я не знаю. Наверное, нет. Жаль.

Есть у Высоцкого славная баллада, о борьбе. И в ней строки:

И пытались постичь мы, не знавшие войн,
За воинственный клич принимавшие вой,
Тайну слова приказ, положенье границ,
Смысл атаки и лязг боевых колесниц.

Ненависти пост

Вот тут гражданин описывает как он шел к успеху.

И сперва советы относительно адекватные, но тут мы замечаем:

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

Это меня всего лишь насторожило, но чем дальше в лес...

Учиться лучше по туториалам, а не по книгам

... тем толще партизаны:

Для работы в Украине в ИТ профильное образование НЕ НУЖНО вообще

И финальное:

Но если ваша цель звучит приблизительно как «стать .NET\Java\Javascript разработчиком с зп 2500$+», то ни математика, ни С++, ни знания алгоритмов вам не нужны.

Здесь уже ничего не исправить, Господь, жги!

Документированности пост

От коллег, прекрасное:

"То чувство, когда вики страничка по Тайному Санте полнее вики твоего проекта"

Низкой эрудированности пост

Ну, как-то так:

Нужно больше читать. И верить людям.

Наступающего будущего пост

Я один слоупок, а вы все наверняка уже слышали о функциональности Хрома "Окей, гугл".

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

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

Затем было установлено, что передачи данных не идет и распознавание именно этой фразы встроено в браузер, передача данных идет уже после произнесения фразы.

Тем не менее - на камерах есть прекрасная фича - горит красная лампочка, когда идет запись. Неплохо бы такое прикрутить и на микрофоны.

Ну и  еще одно замечание, гугл.
Сука - не мат.

Урок 5. Слайд 244-251

Лейтмотив этого месяца - hotfix driven development.

Поехали
Слайд 244-251
Все эти слайды - примеры покрытия веток.

Отличного фильма пост

Намедни был просмотрен фильм Предопределение, он же Патруль времени, в оригинале - Predestination.

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

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

После просмотра захотел узнать, кто так лихо закрутил и тут же обнаружил, что фильм снят по рассказу Хайнлайна "Все вы, зомби". Это многое объясняет.

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

Итого - фильм рекомендую к просмотру. Затем - рассказ к прочтению.

Урок 5. Слайд 242-243

Поехали:

Слайд 243
В предыдущем примере мы считали, что операция G делает с  X что-то простое наподобие печати. Но что если G более сложен, например деление чего-либо на X? В этом случае особые значения переменной X могут быть важны.
Пока вы тестируете переменную, важно знать, каким образом программа будет использовать эту переменную и тестировать различные ее значения, чтоб покрыть различные варианты использования. Тестирование влияния рассматривает то, что программа делает  переменной когда присваивает ее значение - навык подобного тестирования как раз отличает опытных тестировщиков от новичков.

Содержимое слайда:
Поток данных
Когда вы тестируете поток данных, недостаточно установить значение X и использовать его. Нужно задать следующие запросы:
Что программа делает с X?
Какие значения X могут вызвать проблемы при использовании?
Используется ли X в комбинации с другими переменными?
Создает ли программа новые переменные на основе X?


Слайд 244
Давайте посмотрим на следующий пример.

Отзывов пост

На просторах интернета, отзывы.

«Излишне интеллигентен на маршруте»
«Физически подготовлена слабо, развита хорошо, рекомендуется к завозу в альплагеря»
«Активен на ночевках»
«Активна на биваке»
«На бивуаке ленив, хотя может работать первым»
«Груб в отношениях с инструктором и примусами»
«Носил на ночевки баян и ни в чем себе не отказывал»
«Туп, ленив, прожорлив. Любит жумарить первым.»
«Ест много и ходит медленно»
«Грубил и дерзил, называл их пупырями, грозил уйти в спелеологи»
«Писал с гребня на соседнюю дружественную республику»
«Физически и технически подготовлен отлично. Несколько скован на спусках. Активен, инициативен, рассудителен»
«Может...»
«Бережлив»
«Физически и тех. подготовлен отлично Ищет трудности и находит»
«Алчен, мелочен, склочен, завистлив»
«Хороша на любом рельефе...»
«Излишне авторитетна»
«Печет блины»
«Страховаться любит, но не умеет»
«Рекомендуются восхождения в районе Валдайской возвышенности»
«Уверенно чувствует себя на горизонтальном рельефе типа тропа»
«ПРИДУРОК»
«Физически и технически подготовлен отлично. Любит ходить первым. Ленив и нахален, требует подзатыльников»
«Все плохо. Рекомендуется для занятий в других лагерях»
«Сонлив, сварлив, прожорлив»
«Обратить внимание на работу с верёвкой на маршруте и учитывать планы восхождений с планами инструктора»
«...уверенно передвигается по любым формам горного рельефа со скоростью, опережающей ход мысли...»
«Вечно голоден, готов есть всегда и везде. Умеет спускаться на снегобурах. Приветлив и улыбчив, и только за счёт этого живёт в палатке с дефчёнками»
«В состоянии крайнего физического утомления умирает молча, не нарушая движения»
«Обладает лучезарной улыбкой и отсутствием лишнего веса»
«Рекомендуется к восхождениям пока получает от этого удовольствия»
«Внимателен к женскому полу...любит ходить первым»
«Способна выполнять любую, посильную женщине работу»
«Рекомендуются занятия конными видами спорта»
«…удобна в транспортировке»
«На маршруте и на бивуаке готова работать в любой роли»
«Прожорлив и голосист»
«Имеет свойство есть общественный продукт индивидуально»
«Физическая подготовка хорошая. Морально–волевая отличная! Лыжная подготовка отличная. Владеет горнолыжной техникой. Хорошо справляется с обязанностями фотографа»
«Эрудирован, любознателен, хорошо подготовлен теоретически. Доброжелателен, но несколько эгоистичен»
«Поет на маршруте»
«Типичная гоняшка»
«Нагл и хитёр. Способен врать глядя прямо в глаза. Поедает недоброкачественные продукты в огромных количествах. Категорически не рекомендую занятия альпинизмом»
«Сколь прекрасна, столь и далека от альпинизма»
«Проявил себя способным,но способностей своих не проявил!»
«Страховаться любит, но не умеет. Физически слаба, в остальном положительна, на бивуаке всегда готова, пользовалась уважением многих инструкторов»
«Неуклюж, но музыкален. На страховке усидчив. На физическое воздействие реагирует правильно».
«Внизу ничего не боится, но на маршруте спуталась».
«Теоретически страшен, технически безнадёжен, кулинарно аморален и вообще чудовищен. Во сне храпит».
«В антабках толк понимает, к трещинам ледовым неравнодушен».
«Коммуникабельна, но никому не кобельна».
«Хороша вдали от альпинизма».

Итогов одного рабочего года пост

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

Я написал 466 писем.
Провел 2 дня в отпуске.
Завел 634 бага и проверил в два-три раза больше задач.
Перевел 151 страницу новой книги Канера.
Всего лишь раз попал в ДТП и то без повреждений.
Сменил банк и велосипед. Интернет провайдера не сменил, а стоило.
Проехал 3 131 километр на велосипеде, это не считая дороги на работу и обратно.
С командой запустил 2 проекта - Город и Мастер.
Прочел 43 книги.
Четыре раза побывал в Питере. Каждый раз - в командировке.

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

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

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

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

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

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

Вообще, весь год прошел под девизом "нужно больше тренироваться". В частности это о велосипеде, начал с 17 километров до академического, продолжил тренировками в 50 километров до Северки и пока еще не закрыл сезон.
Май и июнь запомнились километрами и кайфом от них. Июль на урале был полностью про дожди, но уже в августе доэкипировался и теперь ни дождь ни снег не помеха.
По поводу велопоездок - задолбал, наверное, всех друзей и знакомых. Но все-таки нашел подходящую компанию.
Яндекс, кстати, вносил посильный вклад в мои покатушки, частично оплачивая поездки по городу.

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

В мае загадал желание - посетить Гранд Макет Россия, в сентябре оно сбылось. Надо быть спокойным и упрямым, да...

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

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

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

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

Что потом?
Стоит подумать об этом и дописать сюда... Но в любом случае много работы. Еще, может быть, борд, английский, права, бег, питон. Можно выбрать, можно сделать все, кто знает.

Урок 5. Слайд 232-241

Поехали:

Слайд 232
Нам нужно расширить словарь. Когда я говорю путь я имею  в виду последовательность шагов программы от начала до завершения.
Я говорю подпуть, когда имею в виду более короткую последовательность шагов.
Многие другие используют это слово в общем смысле до обозначения как последовательности, так и подпоследовательности.

Слайд 233
Я рисую пути используя блок-схемы. Они вышли из моды, но я знаю много тестировщиков, которые находят их удобными и я сам их использую.

Слайд 234
Графы сейчас более популярны. Чтоб перевести наши схемы в графы, просто замените все ромбы и прямоугольники на круги.

Слайд 235-241
(Блок схема, на примере которой рассматривается покрытие ветвей и комбинаций. Ничего интересного.)

Про двух тестировщиков

Про этот пост - читайте тэги.

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

Чем я хуже? Не далее, как сегодня, мы в паре с Настей тестировали продукт и я отметил наш весьма разный стиль работы.
На схеме 2х2 я бы изобразил так:

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

Ну вот представьте:
У нас есть продукт, состоящий из 100%. В нем 20% важных фич и 80% неважных.

Первый тестировщик перед релизом плохо (50% вероятность нахождения бага) поверит 10% из 20% (половину) важных фич и 60% из 80% неважных. Остальное пропустит.
Второй хорошо (80%) проверит все 20% важных и всего 10% неважных. Остальное не успеет.

Допустим, в каждых 5% продукта есть баг. То есть 4 критикала и 16 миноров.

Тогда получается, что:




Первый найдет 1 важный баг и 6 неважных.
А второй найдет 3,2 важных бага и 1,6 неважных.

А более честная метрика - сколько пропустят?
Первый - 3 важных и 10 неважных.
Второй - 1 важный и 14,4 неважных.

Очевидно, надо брать Настю второго, а меня первого уволить.
Пытаясь оправдаться, я подумал, что в жизни вероятности нахождения багов немного другие. И вообще тянет поиграть с цифрами.
Потому создал табличку:
https://yadi.sk/i/NsBH5ruhcnSSq

Игры с цифрами не помогают, как ни крути. правильный ответ - медленно тестировать важные фичи.

Урок 5. Слайд 230-231

Кстати, по случаю в питере посетил дом книги и буквоед. Ассортиментом и конскими ценами первого остался недоволен.
Во втором приобрел немного свежей серии Ойкумены Громова и Ладыженского и, по старой памяти Мастер ветров и закатов, Мартынчик.

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

Поехали:

Слайд 230
Существуют техники тестирования, оптимизирующие выборки, так, что небольшим набором тестов можно найти большинство связанных с комбинациями ошибок. Из 1600 тестов на принтеры и видеокарты, эвристика выборок называемая all-pairs оставит 80 тестов.
Мы обсудим это более детально на курсе по тест-дизайну, но сейчас нужно понять, что 80 тестов, полученных благодаря технике, найдут большинство багов, но оставшиеся 1520 тестов отличаются от них. Эти тесты могут пропустить баг, который воспроизводится на системах с небольшим количеством памяти с этим специфическим принтером и этой специфической видеокартой.

Слайд 231
Далее мы рассмотрим ошибки, которые связаны с последовательностями действий.

Урок 5. Слайд 227-229

Вернулся из питера.
Городом доволен.
А вам - задачка на сообразительность: в какую сторону едет автобус?

 Поехали:

Слайд 227
Мы называем тестирование комбинаций конфигурационным, когда комбинации образованы окружением программы, например комбинации устройств, версий ПО и связями между внутренними сервисами.
Итак, если у вас для тестирования 40 принтеров  и 20 видеокарт, то всего будет 800 конфигураций. Что если еще вы проверяете, сколько доступной памяти имеется - предположим, мы рассматриваем уровень, когда паряти едва хватает и второй уровень - когда у нас есть много свободной памяти. Тогда у нас будет уже 1600 конфигураций.

Слайд 228
Если вы рассматриваете больше переменных и тестируете их вместе, суммарное количество тестов очень сильно быстро возрастет.

Слайд 229
Конфигурационное тестирование лишь один из примеров тестирования комбинаций. Другие примеры включают данные.
Однажды, когда я работал с текстовым процессором, у нас была утечка памяти. Если вы выделите текст, сделаете его жирным, затем курсивом, то все работает нормально. Но если вы сперва примените курсив, а затем сделаете текст жирным, экран будет таким же, но в памяти произойдет сбой. Комбинация ошибок может быть неожиданной и казаться беспричинной.
Вернемся к квадратному корню Hoffman. Он тестировал функцию, которая принимала 2 в 32 степени значений. У нас 2 в 32 степени комбинаций. Теперь представьте калькулятор. Сколько различных формул нужно протестировать?
Комбинации данных могут привести к делению на ноль, переполнению или ошибкам округления. 

Перемещений по офису пост

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

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

Два, в переговорке:

Три:

Четыре:

Пять, возможно тот же, что на предыдущем кадре, кто-то приехал на обед:

 Шесть, иногда попадаются занятные экземпляры:

 Семь:

 Восемь:

 Девять:

 Десять:

 Одиннадцать, этот, судя по всему, ранен:

Двенадцать, не самокат, но тоже имеет право на существование:

Баллада двойников

Из Олди, сборник "Ваш выход":

- Нежнее плети я,
Дешевле грязи я -
В канун столетия
Доверься празднику.

- Милее бархата,
Сильней железа я -
Душей распахнутой
Доверься лезвию.

...Левая рука - правою
Ложь у двойника - правдою,
Исключенье - правилом,
Лакомство - отравою.
Огорчаю?
- Нет!
Радую...

Червонней злата я,
Из грязи вышедши -
В сетях проклятия
Доверься высшему.

- Святой, я по морю
Шел аки посуху -
Скитаясь по миру,
Доверься посоху.

...Правая рука - левою,
Шлюха станет королевою,
Трясогузка - лебедью,
Бедность - нивой хлебною.
Отступаю?
- Нет!
Следую...

- Возьму по совести,
Воздам по вере я,
На сворке псов вести -
Удел доверия.

- Открыта дверь, за ней -
Угрюмый сад камней.
Мой раб, доверься мне!
Не доверяйся мне....

...В зеркале глаза - разные
Позже ли сказать?
Сразу ли?!
Словом или фразою,
Мелом или краскою?
Сострадаю?!
- Нет! -
Праздную...

Урок 5. Слайд 224-226

Поехали:

Слайд 224
Даже если вы протестируете полностью каждую отдельную переменную, то программа все равно не работает только с одной переменной в одно время. Она работает с несколькими.

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

Слайд 226
Когда мы проверяем переменные вместе, то называем это тестированием сочетаний (комбинаторным). Если вы тестируете три переменные, V1. V2. V3 и у них соответственно N1, N2, N3 значений, то суммарное количество сочетаний будет равно N1*N2*N3

Урок 5. Слайд 222-223

Именно сегодня хотелось бы процитировать сумасшедшего Френки, выпуск "Зритель":

Кстати, а кто-нибудь из вас знает, на какой срок избирается Господь Бог, есть ли на небесах Демократия? И Конституционно или неконституционно переизбирать Бога на повторный срок? Да и возможно ли это вообще, хотя это я так, к слову. Ловкий жест, отвлекающий внимание, чтобы исподтишка, заехать кое-кому прямо в нос, чтобы эта дурацкая лампа, все же выскочила из чьих-то рук, и он перестал ее тереть, терзая нашего бедного Джина, своими ужасными желаниями, на которые он просто не может ответить иначе, как, «Слушаю и Повинуюсь, Я раб лампы и моя работа, реализовывать всю эту мерзость и возводить в статус реальности. Я раб лампы! Если вы скажете «пойди и убей», Я пойду и убью, Я раб лампы.

Слишком много всего в последнее время сбывается, надо как-то аккуратней, что-ли.
Фото кота, чтоб расслабиться:

Поехали:

Слайд 222
Недозаполнение также вызывает сбои. Если вы просто нажмете ввод в диалоге ввода данных, вы передадите программе пустую строку. Некоторые программы сбоят на пустых строках.
Еще есть пасхальные яйца. Пасхалки - скрытые сюрпризы в программе. Если вы введете особую последовательность символов в особом месте программы, то программа выдаст специальный ответ. Некоторые пасхалки являются шутками, другие - критикой компании от уволенных программистов. нецензурными выражениями или танцующими голыми девушками. Ваша компания может не хотеть выпускать программу с такими сюрпризами.
Тестирование программы на пасхалки - другая проблема выборок. Любая последовательность символов или действий может привести к проявлению пасхалки и невозможно проверить их все.

Слайд 223
Наконец, рассмотрим полностью невалидный ввод. Некоторые тестировщики и многие программисты не беспокоятся о нем, так как не ждут от людей подобных действий.
В 1997 на USS Yorktown (крейсер соединенных штатов) матрос ввел ноль в поле ввода, в котором не ожидалось появление нуля. Результатом стало зависание систем корабля в результате чего прекратила работу двигательная система корабля.
Люди делают то, чего вы от них не ждете. Может быть, они устали или не понимают системы или ждут, чтоб система сделала то, для чего она не была спроектирована или просто уронили что-нибудь на клавиатуру.Или они умышленно пытаются сделать что-нибудь, что вы бы не одобрили. Ваша система должна справляться со всем этим, так как все это может случиться.
Но вы не сможете все это протестировать.
И в этом суть.
Даже если вы тестируете всего одну переменную, вы не сможете проверить все, что люди туда попытаются ввести. Вы можете много тестировать. И это будет полезно для того, чтоб узнать, как много времени займет подобное тщательное тестирование, так как иногда вам действительно нужно провести большой набор тестов, как Hoffman. Но в большинстве случаев, лучшее, что у вас есть - это выборка.

Урок 5. Слайд 220-221

Поехали:

Слайд 220
Тесты Hoffman сфокусированы на тестировании функции, читающие данные из известной области памяти. Они не рассматривают, как эти данные туда попадают.
Когда вы тестируете пользовательский ввод, у вас есть намного больше вариантов некорректного поведения.
Например, когда вы вводите число, у вас есть возможность редактировать его во время ввода вы можете ввести 123, затем стереть это и ввести 456. Некоторые программы могут сломаться даже на этом и прочесть 123456 вместо 456.
Другая забавная проблема может случиться, когда вы печатаете слишком быстро или слишком медленно или когда другая активность компьютера занимает процессорное время. Программа может неправильно истолковать пользовательский быстрый ввод данных.
Или может закончиться время. Попробуйте набрать на телефоне 6 цифр и перестать набирать. Через минуту кончится время. Вы услышите звук ошибки. Что если вы введете 7ю цифру в тот момент, когда система сообщает о том, что время закончилось? Это известный источник багов в телефонных системах. Такие тайм-ауты есть в большинстве многопользовательских систем и системах реального времени.
Тайм-ауты вызывают больше проблем. когда вы уже ввели несколько значений в диалог или несколько. Что программе делать с вашим неполным набором данных?

Слайд 221
У нас появятся еще несколько рисков, если переменная, которую мы проверяем связана с пользовательским вводом. Например, допустим мы умножаем два числа. Ввод может быть валидным, но результат может вызвать переполнение. Мы должны спроектировать тесты, которые вызовут переполнение внутренней переменной и, если это значение будет выводиться или печататься, то попытаться переполнить место для отображения или печати.

Урок 5. Слайд 219

Поехали:

Слайд 219
У MASPAR был встроенный механизм для работы с числами с плавающей точкой. Один из них читал 32-битное слово как integer и извлекал из него корень.
Когда я спрашиваю студентов, как много времени займет прогнать 4 миллиарда тестов, большинство считает, что это займет слишком много времени. Так отвечают и студенты с несколькими годами опыта.
Большинство людей, зная, как много можно провести тестов, проверят самое большое и самое маленькое числа - 0 и 4294967295. Некоторые проверят степени двойки: 1,2,4,8,16 итак далее. В терминах бинарной логики, у этих чисел все биты содержат нули, кроме одного с 1.
Некоторые люде проверял случайные числа, или такие, в которых они сомневаются, но мало кто проверит больше ста чисел.
А что, если предположить, что нужно полностью выполнить эту задачу? Hoffman оценил время, вышло около 6 минут. И он проверил все числа.
2 теста упало. 2 из четырех миллиардов.
Ни один из упавших тестов не находился на какой-либо границе. Ни один из тестов, которые я описал не нашел бы эти 2 бага.
Сможете ли вы найти эти баги? Либо вы проверите все варианты, либо вам невероятно повезет.
Рассмотрим функцию извлечения корня из 64битного слова. Это 2 в 64 степени тестов, вместо 2 в 32. Их проверка займет около 24 миллиардов минут, это 49 тысяч лет компьютерного времени.
И если вы найдете достаточно компьютеров для проведения такого теста, то вам все равно останется проверить 64-битное умножение, 64-битное деление и все остальные функции.
Вы не сможете запустить так много тестов. Поэтому, даже если существуют еще ошибки и этот компьютер используется для управления ракетами, то лучшее, что вы сможете сделать - провести достаточно много тестов.
Есть другие стратегии для увеличения надежности ПО, такие как аккуратное ревью кода или TDD, но с точки зрения тестирования черного ящика, всегда есть больше тестов, чем вы смогли бы провести.

Поговорок пост

Найденогде-то в недрах контактика. Велопоговорки:

1. Встречай по велосипеду, проважай по результатам.
2. Спица не воробей, вылетит-не поймаешь.
3. Сколько маунтинбайкера на шоссер не сади, все равно в лес смотрит.
4. И сколько маунтинбайкера не корми, все равно жрать хочет.
5. Лучше руль в руках, чем колеса в небе.
6. Весна покажет кто как ОФП занимался.
7. На чужую гонку со своим номерком не ездят.
8. Велогона-ноги кормят.
9. Все тайное со временем становится доппингом.
10. Всех гонок не выйграешь.
11. Проехал лучше чем смог, но хуже чем хотел.
12. Горбатого дропчик исправит.
13. Шоссер бмх-еру не товарищ.
14. Двое пашут, а семеро на колесе сидят.
15. Делу время, тренировке час.
16. Срезка срезана, комар носа не поддочит.
17. Держи ноги на педалях, голову-в шлеме, а живот -в голоде.
18. Велогонам закон не писан.
19. Велосипедиста без байка не бывает.
20. Куда руль-туда и велосипед.
21. Лучше поздно, чем без велосипеда.
22. Мал золотник)), да дорог.
23. Медведь на ногу наступил.
24. На бога надейся, а сам тренируйся.
25. Вел-второе счастье.
26. Не было забот, купила баба велосипед.
27. Не все то велосипед, что едет.
28. Не пойман-не срезал.
29. Не стыдно быть слабаком, стыдно не тренироваться.
30. Нет велосипеда-нет проблем.
31. Ни байк, ни шоссер.
32. Новый велосипед, по новому едет.
33. Один на старте-не гонщик.
34. Одна педаль хорошо, а две лучше.
35. От гонщика до инвалида-один дроп.
36. От прокола да от поломки не зарекайся.
37. Крутит как курица лапой.
38. Педали есть, осталось купить велосипед.
39. Дх-ника видать по полету.
40. Родился в джерси.
41. С работы- на гонку.
42. МТБшник всегда грязи найдет.
43. Семеро одного не ждут)).
44. Семь тренировок на неделе.
45. Не говори гоп, пока не перепрыгнешь)).
46. Сила есть-рулить не надо.
47. Слезами проколу не поможешь.
48. Велосипедисты часов не наблюдают.
48. Тише едешь-хуй доедешь).
48. У страха глаза велики😃
48. Велосипед в чехле не утаишь.
49. Вел хоть и херов, да свой.
50. Если хочешь быть счастливым, будь велосипедистом.

Тренировок пост

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

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

Урок 5. Слайд 217-218

Поехали:

Слайд 217
Во время подготовки к этой лекции вы, вероятно, анализировали функцию, читающую 32-битное слово из памяти и интерпретирующую как положительный integer и возвращающую квадратный корень этого числа.
Больше 4 миллиардов возможных значений на входе в этом примере. Все они валидны. Неважно, что вы намерены хранить в этой области памяти: буквы, отрицательные числа, числа с плавающей точкой - все это функция прочтет как положительный 32-битный integer.
Если вы прочтете не одно, а 2 слова, то у вас будет 2 в 64 степени возможных значений.
У нас есть возможность выбрать для теста небольшой набор примеров - в сравнении с количеством возможных значений даже 1000 тестов это очень мало. Неважно, как вы оптимизируете этот набор, мы не можем быть уверены, что обнаружим все баг, а следовательно мы не можем рассматривать этот набор как полное тестирование.
Позвольте мне сказать пару слов опытным тестировщикам. Вы могли бы использовать техники по выборке данных наподобие тестирования доменов, анализа границ или классов эквивалентности - и протестировать все значения, которые потребуют проверить эти техники - и это, скорее всего, будет хороший набор тестов. Но он не будет полным.

Слайд 218
Doug Hoffman проиллюстрировал это в отчете по тестированию математических функций компьютера MASPAR. MASPAR это сверхбыстрый компьютер с 64 тысячами параллельными процессорами.
Архитекторы MASPAR ожидают, что этот компьютер будет использоваться для критичных задач безопасности. Одно из приложений - целеуказание для ядерных боеголовок. Было бы неплохо, если бы математика на нем работала правильно.

Урок 5. Слайд 214-216

Настоятельно рекомендую к прочтению.

Когда я слышу слово «методология», моя рука тянется к кобуре ©

 Поехали:

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


Содержимое слайда:
Два теста отличаются, если один тест может обнаружить баг, который второй пропустит. 
Очевидно, что для проведения полного тестирования нужно провести все отличающиеся тесты и тестировать до тех пор, пока не будут найдены все баги. Очевидно, что эти критерии эквивалентны. 

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

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

Слайд 216
Начнем с переменных.
Обычный подход заключается в том, что они тестируются на нескольких значениях. Мы проверяем нормальное поведение, обработку ошибок, передаем программе несколько нормальных значений, затем несколько слишком маленьких и слишком больших или странных. Возможно, пробуем какие-то особые кейсы.

Урок 5. Слайд 212-213

Поехали:

Слайд 212

Содержимое слайда:
Список литературы. 
Обязательно.
Doug Hoffman, 2003 Exhausting your test options
Cem Kaner, 1997, The impossibility of complete testing
Полезно:
Rex Black, 2002, Factors that influence test estimation
Michael Bolton, 2009, Blog: When do we stop a test?
Cem kaner, 1997, Negotiating testing resources:  A collaborative approach
Mike Kelly, Estimating testing using speadsheets

Слайд 213
На прошлом уроке я продемонстрировал, что полное структурное покрытие не означает полного тестирования. 

Урок 5. Слайд 210-211

Поехали:

Слайд 210
Добро пожаловать на пятый урок.

Слайд 211
Я хочу поговорить о невозможности полного тестирования. Я расскажу о пяти основных способов оценки тестирования-  как много мы сможем проверить?

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

Урок 5. Введение

Намедни испытал немного радости и хорошего настроения.

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

Я рассказываю и ненавязчиво так  намекаю, что вот тут за дверями магазина томятся в одиночестве минимум три консультанта, у них можно послушать, потрогать товар и незамедлительно приобрести. Специалисты и вообще.
Мужичок и говорит в том смысле, что неизвестно, что там внутри в тепле сидят за люди, а по мне видно, что я явно катать люблю и умею, ибо кто еще будет по снегу в 11 в воскресенье рассекать?
Приятно, черт побери.

Поехали.

Урок 5. Невозможность завершения тестирования.
Введение.
В пятом уроке мы рассмотрим, что мы понимаем под достижением полного тестирования. Четвертая лекция дала понимание концепции покрытия. Некоторые люди пришли к нам на курс, считая, что тестирование будет полным, если они достигнут 100% структурного покрытия. Этот урок продемонстрирует им, как серьезно они ошибаются.

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

Два ключевых примера:
- В примере MASPAR для функции извлечения корня пришлось прогнать 4294967296 тестов, чтоб найти два бага.
- В примере переполнения стека Telenova покрыть все ветви, операторы и независимые подпути невозможно. Для воспроизведения убивающего систему бага тестировщику нужно создать последовательность такую длинную и сложную, что ее создание практически невозможно.Видеолекция обращает внимане на то, что персонал Telenova в конечном счете создал эмулятор который передает программе длинные случайно сгенерированные последовательности и диагностирует состояние системы. Они нашли много других багов, используя этот вид тестирования, таких которые лишь иногда воспроизводятся в боевых условиях, но при этом достаточно серьезных. В лекции мы рассмотрим диаграммы последовательностей. Они похожи на знаменитые диаграммы Glen Myers из книги Искусство тестирования ПО. Myers что проверка всех последовательностей на примере простой программы потребует больш 100 триллионов тестов. Для поиска бага Telenova понаюдобится еще больше тестов.

Одна ключевая формула:
Если у нас есть V(1-k) (k независимых переменных) и если N1 это число возможных значений Vi, то количество комбинаций тестов на все переменные составит N1*N2*...*Nk

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

Урок 4. Слайд 208-209

Поехали:

Слайд 208


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

Слайд 209
Конец урока 4.

Урок 4. Слайд 207

Поехали:

Слайд 207
Brian Marick один из самых первых авторов инструмента измерения покрытия кода. Он написал широко известный монитор для программ, написанных на C и был нанят как консультант по написанию ядер для многих коммерческих инструментов измерения покрытия кода. Также он консультировал компании, использующие эти инструменты. Он писал о проблемах своей работы в статье How to Misuse Code Coverage.
Когда вы измеряете чью-либо производительность, эти люди, обычно, делают что-нибудь, чтоб выглядеть лучше. Если вы считаете, как много моих операторов тестируется, я добавлю тесты, чтоб проверять больше операторов, но это не значит, что я добавлю хорошие тесты. Покрытие не измерит качество моих тестов, не измерит то, как он спроектированы, как находят баги. Оно лишь проверит, как много операторов затронуто.
Brian увидел, что многие компании заставляли своих программистов поддерживать 100% покрытие, но их тесты не обязательно были качественными. Люди перемещали фокус с написания хороших тестов на написание тестов, дающих хорошее покрытие. Они покрывали больше строк кода, но находили меньше багов.
Измерение покрытия - плохой способ узнать, как близки вы к достижению цели. Достижение 90% покрытия ветвей не скажет вам, насколько тщательно вы провели тестирование. однако это не делает измерение покрытия ветвей бесполезным. Это лишь говорит о том, что это плохой инструмент для определения полноты тестирования.
Другой путь использования этого инструмента - узнать, какие области вашей программы не тестируются или тестируются плохо.
Тестируя снаружи, можно пропустить многие вещи. Много отчетов по покрытию говорили, что план тестирования проекта покрывает всего 35% кода. Когда вы определите, что стоит за остальными 65%, вы сможете спроектировать тесты так, что они покроют и эти пропущенные участки.

Урок 4. Слайд 205-206

Поехали:

Слайд 205
Покрытие ветвей удобно в использовании. Ничего из того, что я говорил вам сегодня, не должно заставить думать вас, что покрытие ветвей не стоит использовать.
Программисты, достаточно дисциплинированные, чтоб достичь 100% покрытия ветвей кода, пропускают гораздо меньше багов, чем те, кто этого не делают.
Когда я веду курсы программирования, я настоятельно рекомендую моим студентам изучить и использовать монитор покрытия кода и стремиться достигать 100% покрытия ветвей. на продвинутом курсе, те, кто этого не делает, получают ноль за задания.
Такие инструменты обычно свободно распространяются или достаточно дешевы, просты в использовании и помогают находить баги. Когда вы пишете код, вы должны их использовать.
Некоторые люди пытаются поощрять тестировщиков, тестирующих методом черного ящика, к использованию подобных инструментов, когда они занимаются своим тестированием. Но в качестве black box tester я никогда не находил подобные инструменты полезными.

Слайд 206
Год назад я управлял разработкой нового релиза десктопной программы. VP разработки поинтересовались, какого покрытия коды достигает наше тестирование. Я не знал. Они спросили снова спустя несколько дней и я сказал, что перед тем, как мы этим займемся, ы должны проверить совместимость нашей программы с 80 принтерами. Сейчас же мы работаем с 10. И я беспокоюсь об этом.
После этого VP прекратили задавать мне вопросы о том, сколько линий кода мы протестировали и начали спрашивать с каким количеством моделей принтеров мы работаем. процент принтеров - лучшая оценка, нежели процент покрытия кода.
Другая важная метрика, которая влияла на тот проект - это большой список текстовых и графических программ с которыми мы должны были работать. Это значит, что мы должны были проверить их все.
Также у многих программистов нашей платформы были проблемы с чтением или записью файлов размером от 2 до N байт. Поэтому мы хотели протестировать каждый тип файла и для всех размерах файлов, о которых мы беспокоились.

Это примеры покрытия:
- совместимость с устройствами
- формат входных файлов
- формат и размер выходных файлов

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

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

К сожалению, общее число тестов всегда бесконечно, так что настоящее покрытие всегда равно нулю.

Франкенштейн

Третьего дня посетил спектакль с сабжевым названием из серии TheatreHD - видеозапись спектакля.
Для справки: кинопоиск, вики.
Постер:

И это, мать его. круто.




Суть коротко: офигенные актеры играют в крутой пьесе - существо и доктора. А потом - по приколу - меняются ролями и играют еще раз.
Я видел ту, где Миллер - существо.
Запись идет как положено - без дубляжа, с сабами. На ближайших выходных будет вариант с существом-Камбербэтчем, но все билеты уже раскуплены, потому жду декабря.

Фотка из первой конфигурации:

И из второй:

К просмотру - рекомендую.

Урок 4. Слайд 203-204

Вчера первый раз прокатился по снегу:

Занятно, но ботинки все же летние, поэтому сегодня поставил педали топталки - и впервые за несколько месяцев прокатил на них. Ужасно, слишком привык к хорошему. Как вообще раньше на них катал, хех.

Поехали:

Слайд 203
Структурное покрытие легко измерять, но оно неполное.
Вот простой пример программы, иллюстрирующий проблему. Программа запрашивает два инпута: A и B и печатает их отношение. Можно достичь покрытия ветвей программы за 1 тест.
Но можно ввести значение B=0. Что тогда случится? Структурное тестирование слепо к переменным, которые не проверяются программой. Нет кода, учитывающего B=0. И мы не увеличим этот вид покрытия, добавив такой тест.

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

Урок 4. Слайд 201-202

Снежок...

Поехали:


Слайд 201
Вы достигните покрытия ветвей, если пройдете все операторы и все ветви.
Подавляющее большинство программистов и консультантов считают, что мы получаем 100% покрытия кода, если имеем 100% покрытия ветвей. Это глупо.
Со структурной точки зрения, вопиющая ошибка этого утверждения в том, что оно не учитывает прерывания. Операционная система может переключать контроль с программы на обработчик прерывания в любой момент выполнения программы и настолько, насколько нужно. Состояние системы за это время может изменится способом, который критичен для вас. Другое ПО может изменить данные на диске, в памяти, занять ресурсы, замедлить обработку ваших данных или могут случиться другие подобные вещи до того, как вы будете готовы работать с ними. Все это может вызвать сбои. Также все это может вызвать сбои в системе, на которой работает программа.
Я рассматриваю прерывания как ветви. Можно рационализировать их игнорирование, так как тестировать прерывания достаточно проблематично. Их нельзя увидеть в коде. Кроме того, обычно программисты не учитывают их в коде. Таким образом нельзя сказать, что мы учитываем эти ветви, когда говорим о покрытии кода.
И было бы неправильным говорить о полном покрытии кода, когда есть масса путей вызвать сбой.


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

Урок 4. Слайд 198-200

Поехали:

Слайд 198
Когда программисты и профессора компьютерных наук говорят о покрытии, они обычно имеют в виду структурное покрытие.
Amman и Offutt вели интересную дискуссию о покрытии графов. 
Paul Jorgenson написал хорошее введение в покрытие потока данных.

Содержимое слайда:
Структурное покрытие оперирует управляющими структурами программы. Примеры:
Покрытие операторов: выполнение каждого оператора программы
Покрытие ветвей: каждый оператор и каждая ветвь
Multi-condition: покрытие всех комбинаций логических переменных.

Слайд 199
Но во всех обсуждениях, включая обсуждения стандартов, обычно говорится о простом описании структуры управления программы.

Содержимое слайда:
IEEE 982.1-1988 4.17

Слайд 200
Вы добъетесь 100% покрытия операторов программы, если каждый оператор будет выполнен,
Можно достичь 100% покрытия простой программы за 1 тест.

Рутина

Совсем недавно слышал что-то такое, но все равно не мог не переписать:

У нас было 2 ведущих разработчика с командами, 39 задач, 2 тестировщика, четыре телефона и целое множество ip-номеров всех сортов и расцветок, а также чай, пряники, ящик кофе, и немного терпения у менеджера. Не то, что бы это был необходимый запас для релиза. Но если начал разрабатывать, становится трудно остановиться. Единственное что вызывало у меня опасение — это терпение. Нет ничего более ненадежного, скоротечного и зыбкого, чем терпение менеджера. Я знал, что рано или поздно оно закончится.

 Надо пересмотреть, кстати. 

Урок 4. Слайд 196-197

Поехали:

Слайд 196
Прерывание это сигнал о том, что какой-то вид события произошел. Есть хардварные и софтварные прерывания. В любом случае, компьютер хранит определенный набор ключевых данных в некоем временном хранилище. Затем компьютер запускает обработчик прерывания, определяет, как реагировать на событие, которое произошло, работает с ним, возвращается к работе с основной программой, перезагружает временные данные.
Для основной программы как бы ничего не произошло. Но это фоновое событие, обработанное через прерывание, может быть критичным для программы. Например, принтер может уйти в оффлайн, пока программа работает с ним. Или данные, с которыми работает программа, изменились.

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

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

Примеры:

• нажатие клавиш
• ошибки ввода вывода
• сигналы времени

Ошибки:

• гонка состояний (задержка выполнения программы, связанная с недостатком ресурсов)
• переполнение стека
• смертельное объятие (событие А не может произойти, пока не закончится событие В, событие В не может закончится, пока не произойдет событие А)

Слайд 197
Теперь, когда мы рассмотрели хранение и управление данными, можно обратиться к покрытию. Вопрос покрытия - сколько вы протестировали? Обычно ответ выглядит как процент или пропорция. Я проверил половину кода или все принтеры.

Есть вопросы

В последнее время неоднократно сталкивался с такой ситуацией и не до конца уверен, что я в ней прав..

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

В результате тестирования выясняется, что одн из фич- реализована, но не работает (или баг все еще воспроизводится).

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

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


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

может быть у вас есть свои варианты - но с учетом условий.

Урок 4. Слайд 193-195

Поехали:

Слайд 193
Петля это повторяющаяся последовательность.

Содержимое слайда
Программа повторяет набор инструкций, пока не выполнится критерий выхода

Ошибки:
- бесконечная петля
- петля выполняется за единицу времени слишком много или слишком мало раз
- переполнение памяти
- слишком большие объекты порожденные петлей, так как она выполнилась слишком много раз
- слишком медленная, так как код не оптимизирован для большого количества выполнений

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

Содержимое слайда:
Функции
- могут быть вызваны из другой части программы
- содержат действие и/или возвращают значение

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

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

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

Урок 4. Слайд 190-192

Происходит такая хуйня столько интересного, что тянет процитировать пана Анджея:

В лето Господне 1420 конец света не наступил. Хоть многое говорило о том, что наступит.
Но все равно было весело.
Знаете, господа, как узнать, что время идет историческое? Просто всего происходит очень много и быстро.
Порой было так страшно, что, с вашего позволения, аж жопа съеживалась.

Поехали:

Слайд 190
До сих пор мы изучали данные, в основном, как компьютер хранит и ищет данные. Время переместить фокус на управление. Структуры управления сообщают компьютеру что делать дальше.

Содержимое слайда:
Структуры управления
- последовательность
- ветвь
- петля
- вызов метода
- исключение
- прерывание

Слайд 191
Простейшая структура это последовательность. Просто выполнять следующую команду.

Содержимое слайда:
программа включает в себя список операторов
если вы начали выполнять последовательность, то закончите ее

Слайд 192
Ветвь - это точка принятия решения. Компьютер оценивает логическое выражение, наподобие X равен Y.
Если выражение равно true, программа делает что-то одно, если false, то что-то другое.

Содержимое слайда
Программа принимает решение, какую последовательность выполнять дальше в зависимости от значения логического выражения.

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

Урок 4. Слайд 187-189

Доброго утра:

Поехали:

Слайд 187
Следующая структура данных - запись, учетная запись (record).

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

Операции:
- поиск запили по полю среди других
- получение значения поля
- изменение значения поля
- сортировка записей

Ошибки:
- запись некорректных данных или запись в неверное поле
- хранение некоректных данных
- переполнение или неполные данные (underflow)

Слайд 188
Массив - последовательность определенных типов данных. В массиве A состоящем из integer, вы можете запросить A[0] и получите первый элемент из массива A. Можно создать массив из записей.

Содержимое слайда:
Линейная последовательность переменных определенного типа.
Операции: чтение, запись, сортировка,
Ошибки:
- чтение или запись после завершения массива
- чтение неинициализированных данных
- чтение/ запись неправильного элемента

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

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

Ошибки:
- Поиск вперед по списку, когда нужный элемент находится позади текущей позиции
- Чтение или запись за границами списка.
- некорректное определение текущего положения указателя относительно элемента

Урок 4. Слайд 185-186

Установил намедни приложение я.транспорт - в рамках поддержки коллег.
И тут же вижу, как мой дом был переехан трамваем первого маршрута:

В режиме реального времени. Потом трамвай еще покрутился по площади и поехал по рельсам.
Есть над чем работать.

Поехали:

Слайд 185
наряду с хранением отдельных чисел и символов мы имеем возможность хранить структуры данных. Мы воспринимаем структуру данных как набор чисел и символов, специальным образом организованных.
Моя цель - просто упомянуть об этом, чтоб вам было известно. Большинство данных в программах хранится именно в структурах данных. Чтоб узнать больше о них, пройдите курс структуры данных. Это один из самых первых курсов в учебном плане компьютерных наук. На этом курсе вы узнаете, чем одни структуры отличаются от других, какие в каких случаях лучше использовать, какие баги с ними случаются и какие риски они несут.
В будущем я часто буду упоминать ошибки, связанные со специфическими структурами данных. Это не обязательно самые распространенные или самые важные ошибки. Это ошибки, которые пришли мне в голову первыми, чтоб лучше объяснить вам то, как связаны структуры данных, используемые нами и тестирование.

Слайд 186
Простейшая структура - строка. Последовательность символов.

Содержимое слайда:

Строка.
Операции:
- поиск по подстроке
- замена подстроки
- объединение с другой строкой
- вычисление длинны
- усечение (truncate)

Типовые ошибки:
- переполнение
- совпадение или несовпадение

Урок 4. Слайд 183-184

Накраудфандили офисной комнатой бинокль x30:

Отличная штука, из тех, что не нужны, но очень хочется.

Поехали:

Слайд 183
Мы можем хранить в памяти символы, но не числа. Мы их декодируем. Наиболее широко распространенная схема кодирования ASCII - американский стандартный код для обмена информацией. ASCIIкодирует буквы, цифры и другие символы типа пробелов. например код двойки - 50.
ASCII изобретена для телетайпа, поэтому хранит все в 8 битах.
Другой стандарт кодирования называется Юникод. Он хранит данные в 16 битах и работает с многими языками.

Слайд 184
Давайте просуммируем. Когда программа читает 32-битное слово из памяти, она их так или иначе интерпретирует. Как integer, число с плавающей точкой, последовательность символов или что-то еще. По самим 32 битам данных нет возможности сказать. какой тип данных передается.
У программа может воспринимать данные корректно - или может ошибочно считать слово числом или наоборот.

Второй городской сессии тестирования пост

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

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

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

Реальность, как водится. не подвела и организовалась таким образом, что необходимое случилось.

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

Одна короткая просьба - и Саша помогает мне с багтрекером для продукта.

Я рассказал о идее команде продукта - и Серега за несколько дней поднял тестовое окружение - Атлантиду - которую мы используем и в реальном тестировании. Он же - и Саша, Лев, Настя - загорелись идеей и не пожалели выходной. Четыре часа подряд в адском темпе верифицировать 220 тикетов - это не шутки.

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

Сам день Д выдался отличный.
Прийти на 2 часа раньше остальных и донастроить багтрекер.
Волноваться - все ли придут. А не придут ли те, на кого не выдан доступ?
Явка, кстати, составила 97%, неплохо для второго раза, я считаю.

С понтом стартанул знакомство.

Забавный момент, в связи с особенностями доступа - на команды делили заранее и названия им придумывал я. Сперва был примерно такой набор - названия,  герои, просто запомнившиеся объекты из любимых книг:

Белый единорог, Белый дракон, Крылатый пес, Алекс, Юстас, Встречный ветер, Попутный ветер, Тахмасиб, Амальтея, Мелкие боги, Восьмой цвет, Адам Селена, Божьи воины, Свет вечный, Башня шутов

Протестировал на паре человек, понял, что у меня специфический список литературы.
Решил сделать такие названия:

Sex Pistols, Led Zeppelin, Slipknot, Limp Bizkit, Deep Purple‎, Linkin Park, Ace of Base‎, Children of Bodom, Cannibal Corpse, Nazareth, Guns N'Roses, AC/DC, Gorillaz‎, Blind Guardian‎, Linkin Park, Metallica, Within temptation, Drowning pool, System Of A Down

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

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

1 за минор
3 за нормал
6 за крит
10 за блокер

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

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

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


Судя по статистике:

Общее количество заведенных багов - 220
Из них подтверждено - 124 (3 critical, 29 normal и 92 minor)
Заведено дефектов в трекере продукта по итогам тест-сессии - 38

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

А что потом?
Наверное, будет еще сессия, от нас или от контура, а скорее всего и та и другая.
Может быть соберемся тестировщиками несколько раз потравить байки, рассказать пару лекций поспорить, да мало ли.
Тщательность подготовки и выверенность сценария в моем случае необходимы и их не хватало - не умею импровизировать. И чем больше деталей будет учтено - от месторасположения и расстояния до розеток до текста прощания и выбора бара - тем лучше.
Наверняка знаю, что следующее - любое - мероприятие - нужно гораздо тише готовить и громче пиарить. Было много лишних обсуждений с теми, кто мог, но ничего не делал, не помогал, не принимал участие. Лишних.
Наверное, самое важное - в создании таких движух должны участвовать не компании, а люди. Добровольцы в свободное время, те, кому интересно, те кто готов тратить время и ничего не ждет взамен. И тогда получится намного лучше.


И немного фото из группы вконтактике. Раз:

Два:

Три:

Комиссия:

Подводим итоги: