пятница, 31 октября 2014 г.

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

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

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

Поехали:

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

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

четверг, 30 октября 2014 г.

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

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

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

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


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

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

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

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

среда, 29 октября 2014 г.

Урок 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
На прошлом уроке я продемонстрировал, что полное структурное покрытие не означает полного тестирования. 

вторник, 28 октября 2014 г.

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

Поехали:

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

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

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

понедельник, 27 октября 2014 г.

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

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

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

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

Поехали.

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

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

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

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

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

пятница, 24 октября 2014 г.

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

Поехали:

Слайд 208


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

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

среда, 22 октября 2014 г.

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

Поехали:

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

вторник, 21 октября 2014 г.

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

Поехали:

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

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

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

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

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

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

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

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


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




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

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

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

пятница, 17 октября 2014 г.

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

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

Поехали:

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

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

четверг, 16 октября 2014 г.

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

Снежок...


Поехали:


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


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

среда, 15 октября 2014 г.

Урок 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-номеров всех сортов и расцветок, а также чай, пряники, ящик кофе, и немного терпения у менеджера. Не то, что бы это был необходимый запас для релиза. Но если начал разрабатывать, становится трудно остановиться. Единственное что вызывало у меня опасение — это терпение. Нет ничего более ненадежного, скоротечного и зыбкого, чем терпение менеджера. Я знал, что рано или поздно оно закончится.
 Надо пересмотреть, кстати. 

вторник, 14 октября 2014 г.

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

Поехали:

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

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

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

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

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

пятница, 10 октября 2014 г.

Есть вопросы

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

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

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

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

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


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

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

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

Поехали:

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

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

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

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

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

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

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

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

четверг, 9 октября 2014 г.

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

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

Поехали:

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

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

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

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

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

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

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

среда, 8 октября 2014 г.

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

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


Поехали:

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

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

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

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

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

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

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

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

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

вторник, 7 октября 2014 г.

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

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

Поехали:

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

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

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

Строка.

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

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

понедельник, 6 октября 2014 г.

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

Накраудфандили офисной комнатой бинокль x30:
Отличная штука, из тех, что не нужны, но очень хочется.

Поехали:

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

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

среда, 1 октября 2014 г.

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

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

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

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

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

На горизонте появилась замечательный человек Настя и взяла на себя абсолютно все вопросы, не связанные собственно с тестированием: группа вконтактике, удлиннители, пицца, помещение, рассылки по почте, призы, 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
проводить такие штуки стоит.
Судя по первым, да и не первым отзывам - понравилось и участникам и организаторам.

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


И немного фото из группы вконтактике. Раз:
Два:
Три:
Комиссия:
Подводим итоги: