Интеграционное тестирование

Еще немного заметок.

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

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

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

Интеграционное тестирование применяется на этапе сборки модульно оттестированных модулей в единый комплекс. Известны два метода сборки модулей:
• Монолитный, характеризующийся одновременным объединением всех модулей в тестируемый комплекс
• Инкрементальный, характеризующийся пошаговым (помодульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей:
o "Сверху вниз" и соответствующее ему восходящее тестирование.
o "Снизу вверх" и соответственно нисходящее тестирование.

Особенности монолитного тестирования заключаются в следующем: для замены неразработанных к моменту тестирования модулей, кроме самого верхнего, необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки (stub), замещающие отсутствующие на момент сеанса тестирования модули нижних уровней.

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

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


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


Недостатки восходящего тестирования:
• Запаздывание проверки концептуальных особенностей тестируемого комплекса
• Необходимость в разработке и использовании драйверов


Особенности интеграционного тестирования для процедурного программирования

Процесс построения набора тестов при структурном тестировании определяется принципом, на котором основывается конструирование Графа Модели Программы (ГМП). От этого зависит множество тестовых путей и генерация тестов, соответствующих тестовым путям.

Первым подходом к разработке программного обеспечения является процедурное (модульное) программирование. Традиционное процедурное программирование предполагает написание исходного кода в императивном (повелительном) стиле, предписывающем определенную последовательность выполнения команд, а также описание программного проекта с помощью функциональной декомпозиции. Такие языки, как Pascal и C, являются императивными. В них порядок исходных строк кода определяет порядок передачи управления, включая последовательное исполнение, выбор условий и повторное исполнение участков программы. Каждый модуль имеет несколько точек входа (при строгом написании кода - одну) и несколько точек выхода (при строгом написании кода - одну). Сложные программные проекты имеют модульно-иерархическое построение, и тестирование модулей является начальным шагом процесса тестирования ПО. Построение графовой модели модуля является тривиальной задачей, а тестирование практически всегда проводится по критерию покрытия ветвей C1, т.е. каждая дуга и каждая вершина графа модуля должны содержаться, по крайней мере, в одном из путей тестирования.

©www.intuit.ru

Модульное тестирование

Заметки на полях.

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

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

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

Являясь по способу исполнения структурным тестированием или тестированием "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Тесты, связанные со структурным тестированием, строятся по следующим принципам:
• На основе анализа потока управления. В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования С0, С1,С2. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п.
• На основе анализа потока данных, когда элементы, которые должны быть покрыты, определяются на основе потока данных, т. е. информационного графа программы.


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

Тестирование на основе потока данных. Этот вид тестирования направлен на выявление ссылок на неинициализированные переменные и избыточные присваивания (аномалий потока данных). Недостаток стратегии в том, что она не включает критерий С1, и не гарантирует покрытия решений.


Методы проектирования тестовых путей для достижения заданной степени тестированности в структурном тестировании. Процесс построения набора тестов при структурном тестировании принято делить на три фазы:
• Конструирование УГП.
• Выбор тестовых путей.
• Генерация тестов, соответствующих тестовым путям.

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

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

Вторая фаза обеспечивает выбор тестовых путей. Выделяют три подхода к построению тестовых путей:
• Статические методы.
• Динамические методы.
• Методы реализуемых путей.


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

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

Методы реализуемых путей. Данная методика заключается в выделении из множества путей подмножества всех реализуемых путей. После чего покрывающее множество путей строится из полученного подмножества реализуемых путей.

Достоинство статических методов состоит в сравнительно небольшом количестве необходимых ресурсов, как при использовании, так и при разработке. Однако их реализация может содержать непредсказуемый процент брака (нереализуемых путей). Кроме того, в этих системах переход от покрывающего множества путей к полной системе тестов пользователь должен осуществить вручную, а эта работа достаточно трудоемкая. Динамические методы требуют значительно больших ресурсов как при разработке, так и при эксплуатации, однако увеличение затрат происходит, в основном, за счет разработки и эксплуатации аппарата определения реализуемости пути (символический интерпретатор, решатель неравенств). Достоинство этих методов заключается в том, что их продукция имеет некоторый качественный уровень - реализуемость путей. Методы реализуемых путей дают самый лучший результат.
©www.intuit.ru

Методика интегральной оценки тестированности

Заметки на полях о тестировании неспеша идут дальше.

1.Выбор критерия С и приемочной оценки тестированности программного проекта - L
2.Построение дерева классов проекта и построение УГП для каждого модуля
3.Модульное тестирование и оценка TV на модульном уровне
4.Построение УГП, интегрирующего модули в единую иерархическую (классовую) модель проекта
5.Выбор тестовых путей для проведения интеграционного или системного тестирования
6.Генерация тестов, покрывающих тестовые пути шага 5
7.Интегральная оценка тестированности проекта с учетом оценок тестированности модулей-компонентов
8.Повторение шагов 5-7 до достижения заданного уровня тестированности L
©www.intuit.ru

Отец

Если был бы отец живой,
я б ему позвонил домой
и, наверно, спросил:
"Ты все прыгаешь, Хил?
Как делишки? Где был, с кем пил?"

А отец бы ответил так:
"Как трактуешь отца, сопляк?
Впрочем, что с тебя взять?
Заходи, дам пожрать -
ты ж, небось, без копья опять?"

И пришел бы я в дом к отцу.
Он бы мне разогрел супцу,
и из высохших шпрот
сделал бы бутерброд,
и сказал бы: "Давись, проглот!"

Я бы все смолотил, смолол
и сказал бы: "Ну, я пошел!
А супец был хорош!"
А отец бы: "Ну, что ж,
Жрать захочешь, еще придешь".

Я бы вышел, курнул "дымку",
был бы март иль апрель в соку,
и мотался б скворец
по березе кривой,
если был бы отец
живой.
--------
©МВ
--------
Как-то так. За душу берет, не так ли?

Корпоративчик

"Может это прозвучит резко
Может это прозвучит дерзко"
©Роберт

Собственно, это был эпиграф.
Сегодня у меня были два корпоратива: на новом месте работы и на старом. Не буду гнать: на новом я ушел еще до того, как открыли бутылки с водкой. На старый я попал на весь.
Новое место оно на то и новое, на старом я тотальной пьянкой подвел черту. И вот что обнаружилось.
Докладываю результаты:
- выпито немеряно, средний градус - 40
- обсуждено все, от талий до OLAP кубов
- выиграл в теннис своего бывшего менеджера со счетом 4:0 (партии до 21, тут признаю, проиграл программисту со счетом бесконечность ноль)
- выкурено полторы пачки кента
- съедено много всего вкусного и не зря
А главное - главное то, что я увидел. chertenok_44, передай лично всем, кого я упомянул.
передай вот что: Девушки, женщины, вы самые красивые, вы самые интересные и привлекательные из всех дам, которых я когда-либо видел. Это одна из немногих причин, по которой мне жаль, что я Вас покинул. В одну... нет в двух из Вас я был совершенно искренне влюблен - и не зря. Я горжусь тем, что я с Вами знаком.
Конец послания, дальше цитировать по желанию.

Теперь стих на мотив "Танки грохотали":

По сцене танцевал директор
Админы пили по второй
А молодому программисту
Сейчас идти в последний бой

этот пост - о любви. Кот, да и я вместе с ним как бы говорю Вам: любовь есть.

Критерии тестирования

Продолжение заметок, на сегодня хватит, я так думаю

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

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

Структурные критерии
- используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing)

Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей)..

Функциональные критерии
- важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Отражают взаимодействие тестируемого приложения с окружением. Используется модель "черного ящика". Проблема:трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), достаточно объемны.

• Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
• Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
• Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
• Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
• Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
• Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.

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

Необходимо разработать программы - имитаторы случайных последовательностей входных сигналов{x}. Вычислить независимым способом значения {y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y). Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
• Детерминированный контроль - проверка соответствия вычисленного значения y значению y, полученному в результате прогона теста на наборе {x} - случайной последовательности входных сигналов, сгенерированной имитатором.
• Стохастический контроль - проверка соответствия множества значений {y}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).

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

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


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

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

Метод мутационного тестирования - в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.

.
За материал спасибо ©intuit.ru

Тестирование

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

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

Отладка (debug, debugging)– процесс поиска, локализации и исправления ошибок в программе [IEEE Std.610-12.1990].
Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода – CodeChecker.
Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.

При выявлении несовпадения ожидаемых и полученных результатов запускается процедура исправления ошибки, которая заключается во внимательном анализе (просмотре) протокола промежуточных вычислений, приведших к некорректным данным с помощью следующих методов:
А) "Выполнение программы в уме" (deskchecking).
Б) Вставка операторов протоколирования (печати) промежуточных результатов (logging).
В) Пошаговое выполнение программы (single-step running).
•Step Into – если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов, и программа останавливается на первой строчке вызываемой функции, процедуры или метода.
•Step Over - если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов и выполнение всей функции и программа останавливается на первой строчке после вызываемой функции.
•Step Out – предназначена для выхода из функции в вызывающую функцию. Эта команда продолжит выполнение функции и остановит выполнение на первой строчке после вызываемой функции.

Г) Выполнение с заказанными остановками (breakpoints), анализом трасс (traces) или состояний памяти - дампов (dump).
Д) Реверсивное (обратное) выполнение (reversible execution)

Тестирование – это:
•Процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [9].
•Процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [[IEEE Std.610-12.1990], [9].
•Контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок [IEEE Std 829-1983].
Реализация тестирования разделяется на три этапа:
•Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
•Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver [IEEE Std 829-1983], [9]) с получением протокола результатов тестирования (test log).
•Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.

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

Сегодня материал взят отсюда: http://www.intuit.ru/department/se/testing/
Ну или так: ©www.intuit.ru

Рутина

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

По коту видно, что уверенности у него поубавилось, но надежда есть, я это гарантирую.

На новом месте

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

Сеть стомегабитка, после прошлого гигабита как то некошерно. Курилка будет поправославней - на балконе(chertenok_44, привет тебе сиди и завидуй).
Общаются люди больше голосом, а не как на старом месте - печатным текстом, что - в пределах комнаты шесть на шесть – хоть и логично, но неудобно.
Прямо напротив сидит парень из одного институтского потока, здесь уже второй год. Говорит попал я удачно, в компании период либерализации в смысле зарплат. При чем тут кризис? chertenok_44, привет тебе еще раз и нашим передавай.
В середине второго дня работы я осилил установку системы, к вечеру в общих чертах понял как он работает. Потом имел небольшую двухчасовую лекцию и понял, что ничерта я не понял, что мне еще понимать и понимать. Как-то так.
Кстати, по ощущениям - ошибки искать на порядок сложнее, я за день нечаянно обнаружил только пару некорректныз отказов и пару полных вылетов из-за некорректного ввода данных, но это так. chertenok_44, а сколько я бы нашел подобных штук за день у нас?
В целом - интересно, еще интересней будет, когда я буду разбирать наработки прошлых попыток тестирования.
Хорошо. Посмотрим, что там - дальше.

Кот тоже без страха смотрит в будущее. И тоже слегка охуевает.

Вехи.

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

Ты же помнишь?

http://rutube.ru/tracks/97277.html

Боремся с депрессией

Жизнь сюрпризы преподносит,
Жизнь лупит нам под дых,
И депрессия все косит
Наши стройные ряды.
Обстановка неспокойна,
Психиатры сбились с ног,
А народ сигает в окна,
Нажимает на курок.

Люди злы, как прокуроры,
Ждут печального конца,
От тоски у всех запоры
И землистый цвет лица.
Улыбаться надо, братцы,
Не сдаваться, молодцы!
Если нация в прострации,
То нации - концы.

Припев: Всё будет обалденно,
И не о чем скорбеть.
Вам надо ежедневно
Сто сорок раз пропеть
О том, что всё отменно,
Всё просто офигенно,
Всё ништяк.

Эй, страдалец, зачитай-ка
Список личных неудач.
"Зайку бросила хозяйка!
Уронили в речку мяч!"
Из туфты не делай драму:
Мир прекрасен, жизнь идёт.
Глянь-ка - мама моет раму,
Саша кашу смачно жрёт.

Что, начальник обижает?
Да ты в гробу его видал.
Негритят жена рожает?
А вдруг твой прадед - Ганнибал?
Это мелкие печали,
Был и хуже беспредел:
Одного вообще распяли,
Так он терпел и нам велел.

Припев.

Если водку пить печально,
Можно тихо ошизеть,
Но всё не так суицидально,
Если в корень посмотреть:
Денег нет - так и не будет,
Что ж печалиться о том.
Ты дыши, брат, полной грудью,
Жуй морковку полным ртом.

Занимайся сексом, спортом,
Плавай, рыбок разводи,
Дай хоть раз начальству в морду,
Делай что-то, не сиди.
Подними с дивана мощи,
Встань, занятие найди.
Соблазни соседку, тёщу,
Тестя... - только не сиди!

Припев.
©Тимур Султаныч

Кот символизирует.

Доброго дня

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

Кот спит, молчит и тоже о чем-то мечтает.

Ненависть

Но, наверное, самый важный вопрос о том, зачем психологам формальная логика, поиск ответа на который увлекает в самую суть психологической науки. Преподавание логики связано с самой главной мечтой психологии – быть похожей на «хорошие», точные науки, такие, как физика или химия. Психологи полагают, что представители этих наук мыслят логично, а сами они — нелогично, и именно поэтому упомянутые науки «хорошие» и точные, а психология — «плохая» и неточная. Следует отметить, что это предположение было проверено и экспериментально — естественно, психологами. Оказалось, что именно их мышление наиболее логично, т. е. они лучше представителей всех прочих наук знают и применяют правила формальной логики, затем идут социологи, потом среди изученных групп — биологи, а хуже всех знают и применяют формальную логику физики и математики. Среди всех участвовавших в эксперименте правильнее психологов применяли формальную логику только ... католические священники. Этот эксперимент показал, что между уровнем развития науки и степенью логичности мышления ее представителей существует обратная связь, и, чтобы сделать психологию похожей на точные науки, психологов следовало бы учить не соблюдать, а нарушать правила формальной логики. Но традиция есть традиция, и психологи продолжают возлагать большие надежды на логику.
Наткнулся на ЛОРе, исходник здесь.
Больше, чем психологов-теоретиков я ненавижу только философов. Последние имеют право на существование только в мертвом виде. И то не все.

Кот как бы намекает нам на то, что философы отнюдь не бесполезны. Из одного философа можно получить немало метана.

Рутина

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

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

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

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

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

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


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

RTFM

http://death-moroz.livejournal.com/298191.html#cutid1
К прочтению рекомендую. Все-таки - это русский язык, который важно уметь употреблять.


Кот цитирует.

P.S. death_moroz свою запись убил, но astenix предложил альтернативу: http://teneta.rinet.ru/rus/de/denis_yatsutko-matom.html

P.P.S. Нашлось: http://du-jingli.livejournal.com/44732.html

Как-то так

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

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


Кот как бы говорит нам: для того, чтоб быть свободным недостаточно быть на воле. Надо еще, чтоб все остальные сидели в тюрьмах.

Утро

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


Кот символизирует.

Рутина

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


Вот кот - точно хотел бы.

Рутина кризисная опять же

Все те же "Танки грохотали":

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

Все, хватит дури на сегодня.

Рутина, кризисное

Второй куплет на мотив "По полю танки грохотали"

Нам Жанна принесет заявку
Накрылся тазом их клиент
На завтра отменили пьянку
И на сочельник денег нет

Дурь продолжается. Надо было выспаться...

Работа

Да, я больной и вечером в воскресенье думаю только о работе.

У меня в голове такой вопрос. В плане баланса мировых сил и прочего подобного.
Итак.
Четыре девелопера, один с лишним проектировщик(ингда еще плюс полтора), два тестировщика.
Delphi+MS SQL.
Проект ведется уже пять лет.
Мне интересно, это нормальный баланс сил? Я понимаю, что все ситуативно и нюансово, но все же.

Ну и напоследок, на мотив "по полю танки грохотали":
Нам Таня планы написала
По ним тестируем опять
Наверно ждет меня Вальгалла
Щас буду сервер я ронять

Вот дурь...


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