Приветствую вас, хабралюди!

Взбрело мне в голову написать несколько статей, о том как реализованы некоторые структуры данных в Java. Надеюсь, статьи будут полезны визуалам (картинки наше всё), начинающим java-визуалам а также тем кто уже умеет писать new ArrayList(), но слабо представляет что же происходит внутри.



Сегодня поговорим о ArrayList-ах

ArrayList — реализует интерфейс List. Как известно, в Java массивы имеют фиксированную длину, и после того как массив создан, он не может расти или уменьшаться. ArrayList может менять свой размер во время исполнения программы, при этом не обязательно указывать размерность при создании объекта. Элементы ArrayList могут быть абсолютно любых типов в том числе и null.

Upd: добавлены скиншоты.

19-20 мая в Минске проходил Software Engineering Forum 2011. Мы выступили с докладом «Новый уровень автоматизации тестирования», или альтернативный длинный вариант – «Доавтоматизация» автоматизированного тестирования через интеграцию тестового инструментария». В нем мы раскрыли три основных вопроса:

1. Уровни автоматизации тестирования в организации.
2. Основные моменты, на которые стоит обратить внимание при автоматизации тестирования (на основе собственного опыта и опыта коллег, а также результатов опросов).
3. Прототип решения для управления автоматизированным тестированием (на базе внутренней разработки Octopus).

Под катом – содержание доклада, ссылка на промо-версию Octopus. Длинный пост.

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

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

Для тех кто ни разу не использовал JMeter, рекомендую для начала почитать базовые обзоры, например, Простой нагрузочный тест с Apache JMeter. Когда я первый раз запустил данную программу, первая мысль была разобраться во всем методом «тыка», но как выяснилось это вообще нереально, и метод «тыка» неприменим к JMeter. Поэтому если хотите его использовать, то сразу открывайте мануал, поверьте, вам придется заглядывать туда очень часто, пока полностью не разберетесь, что и как. Я же здесь сейчас опишу самое очевидное и важное, а именно: как собственно создавать нагрузочные тесты. Если бы я в свое время сразу нашел подобную статью, то сэкономил бы без малого день на изучении этой софтины.

Доброго времени суток, уважаемое Хабрасообщество.

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

Я хочу рассказать вам основы теории Игр, доказать функцию Шпрага-Гранди, разобрать несколько классических impartial-задач и проиллюстрировать их кодом на python.

Сказка

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

К счастью, транспортная компания (которая не удосужилась составить четкого расписание) содержит сайт, на котором в реальном времени с помощью Google Maps можно узнать, где сейчас находится тот или иной автобус. И вот в один прекрасный день Ваше терпение лопается и Вы садитесь писать скрипт, который будет отправлять ту желанную SMS-ку. Но все не так просто. Придется долго повозиться, чтобы по карте и маленькому кружочку на ней оценить скорость и время прибытия реального транспортного средства на Вашу остановку. Вы ведь не можете просто написать: «хочу получать SMS, когда вот эта точка попадет вот в этот прямоугольник на карте». Или все-таки можете?

Продолжение к посту модель Миллса.

Парная оценка

Данная модель требует тестирование программы двумя специалистами (или группами специалистов). Зато не требует внесение в программу искусственных ошибок. Итак, пусть программу тестируют независимо друг от друга две группы специалистов. Предположим, что в программе содержится N ошибок. Пусть первая группа нашла N₁ ошибок, а вторая — N₂. Часть ошибок обнаружена обеими группами. Пусть таких ошибок N₁₂.

Сколько ошибок в программе? Это вопрос, который волнует каждого программиста. Особую актуальность придает ему принцип кучкования ошибок, согласно которому нахождение в некотором модуле ошибки увеличивает вероятность того, что в этом модуле есть и другие ошибки. Точного ответа на вопрос о количестве ошибок в программе очень часто дать невозможно, а вот построить некоторую оценку — можно. Для этого существуют несколько статических моделей. Рассмотрим одну из них: Модель Миллса.

Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

Такие тесты проводятся после каждого релиза и занимают очень много времени.

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

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

Немного истории

Slash

Возникновение слеша относят к временам Римской империи. На ранних стадиях современности, во Фрактуре [1], которая была широко распространена по всей Европе в средневековье, слеш (/) использовался вместо запятой, в то время как двойной слеш (//) использовался вместо тире. Двойной слеш, в конечном счете, превратился в символ похожий на знак равенства (=), а позже был еще больше упрощен до тире или дефиса [2].

Привет всем из 2023 года!
Я написал эту статью 12 лет назад. И внезапно — это — моя самая популярная статья. Я так же удивился что люди до сих пор заходят сюда и читают эту статью. Поэтому я решил её обновить. И после прочтения понял, что обновлять ничего не буду.

Да, powershell обновился за последние годы. Теперь он стал Powershell Core, и его можно запускать как на Windows, так и на Linux и MacOS. В скриптах появилось много плюшек, но основная идея осталась той же.

Если вы только начинаете писать на Powershell эта статья для вас. Вам будут даны основные понятия, которые относятся к Powershell в 2023 году, и которые позволят вам погрузиться в эту оболочку с головой.

Приди ко мне брате в Консоль!
— Админ Долгорукий.

Много ярлыков улетело в корзину со времён выхода в свет 2008 Windows. Люди попроще дивились новому синему окошку, которое ребята из Майкрософт зачем-то вставили в свои новые продукты. Люди, которые сидят на блогах и знают программирование начали изучать это окошко.



В итоге к народу начало приходить осознание того, что Майкрософт действительно разработали что-то новое и интересное.
И так, зачем вам это нужно? В основном, программа под названием PowerShell (в дальнейшем PS) предназначена для администраторов и программистов. Она позволяет автоматизировать примерно 99% всех действий в системе. С помощью неё вы можете настраивать удалённые компьютеры, запускать и перезапускать сервисы и производить обслуживание большиства серверных приложений. Как выяснилось, возможности у программы потрясающие.

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

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

«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»

Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?

Тогда прошу под кат!

     «Милая „Наталья“, я вам пишу, чего же… » Нет, не такое вступление должно быть для монолога в стиле Роберта Пирсига. Такое обращение оставим для диалога в комментариях.

Книгу Дзен и искусство ухода за мотоциклом я рекомендую всем, кому важно качество, особенно тем, кто близок к тестированию!

Есть один замечательный вопрос, который возникает в любой дискуссии связанной с юнит-тестированием. «Надо ли создавать тесты для юнит тестов». Ответом на этот вопрос, как правило, служит технология Code Coverage. Действительно, если вы хотите убедиться в том, что юнит тест подготовлен правильно, вам нужно только проверить вызываются ли все ветвления в коде. Достигается это простым методом – надо подать на вход проверяемой функции все комбинации данных, которые позволят обойти эти ветвления. И академические примеры из документации это показывают.

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

Команда проекта ReactOS в очень скором времени (в течение недели) готовится представить следующий минорный релиз.
Обращаюсь к сообществу с просьбой оказать помощь в тестировании на предмет совместимости программ и драйверов. Очень важно выявить и задокументировать возможные регрессии.

Скачать установочный образ для тестов ~40 мб.

1. Страничка тестирования релиза www.reactos.org/wiki/Tests_for_0.3.13
2. Портал для регистрирования багов www.reactos.org/bugzilla
3. Инструкция «как заполнять баг-репорты» www.reactos.org/wiki/File_Bugs
4. Инструкция «как получить дебажный лог» www.reactos.org/wiki/Debugging

Мне давненько хотелось вживую «пощупать» Microsoft Visual Studio Test Professional. Все-таки это продукт, позиционируемый Microsoft как основная платформа для тестирования программ, создающихся в Visual Studio (а это мой главный рабочий инструмент). Да и чего уж тут греха таить, к стати подвернувшийся конкурс от Microsoft тоже не оставил меня равнодушным. Прошу заранее простить мой несколько «ламерский» взгляд на предмет статьи — сам я программист, а не тестер, и могу неверно употреблять некоторые термины (а иногда и вовсе пороть бессовестную чушь).

Сегодня мы обнародовали два новых проекта, входящих в наш Open Source портфолио — OperaWatir и OperaDriver. Как и Opera Dragonfly, оба проекта относятся к средствам разработки, облегчающим несладкую жизнь веб-программиста. Если говорить кратко, то данные инструменты позволяют создавать автоматические тесты, имитирующие действия бешеного пользователя, зашедшего на ваш веб-сайт и без какой-либо чёткой цели кликающего ссылки, вводящего всякую тарабарщину в текстовые поля или заполняющего любые формы, подвернувшиеся под руку. В общем, в реале подобного уникума вряд ли встретишь, но на всякий случай лучше проверить свою работу на стойкость — наша жизнь, знаете ли, всякие фокусы любит выкидывать.

Привет, Хабражители!

По роду своей деятельности мне часто приходится подбирать тестировщиков для тестирования различных проектов (web, desktop, mobile и т.д.).
При этом тестировщики не всегда оправдывают свои заявленные умения и свой профессионализм.

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

Зачем нанимать «одного» тестировщика, если можно получить сотню и оплачивать только интересные баги.

В последнее время развелось очень много различных AJAX-приложений. По сути автоматизация тестирования такого приложения не отличается от автоматизации тестирования обычного WEB-приложения, но есть несколько тонкостей. Одна из тонкостей — это как раз ожидание завершения всех AJAX-запросов. Например, если отметка некого checkbox'а на странице вызывает обновление какого-нибудь select'a по AJAX-запросу, то тест, который сразу после отметки выбирает конкретный option, свалится, т.к. этого option'a там не будет. А всё потому, что сам тест выполняется намного быстрее чем AJAX-запрос на обновление списка.

В данном случае у автоматизатора есть несколько выходов.

Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

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

Так программист может контролировать поведение системы на контрольных точках и пограничных значениях.
Часто именно неверная отработка пограничных значений приводит к проблемам. И опытные программисты это знают и учитывают при проектировании Unit-тестов.

Удобство Unit-тестов ещё и в том, что изменяя код вы ожидаете получить предсказуемые результаты и провести полностью автоматическое тестирование по имеющимся сценариям, чтобы быстро выявить наведённые изменениями неприятности.

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

Однако, любой пользователь всегда несёт в себе элемент случайности.

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

Если программа делает больше чем печать «Hello World!», то скрытые ошибки в любом случае остаются.
Это могут быть ошибки и в логике в том числе.

Программа компилируется, все Warning'и устранены… но иногда что-то идёт не так… у пользователя (который живёт далеко в домике на островке в тихом океане — приехать к нему и пощупать нет возможности). Программист прокликал и протестировал со своей стороны всё что мог, но ошибки не нашёл. Что же делать?