SUT с человеческим именем

Допустим я тестирую продукт, который работает [в том числе] с «человеческими данными».

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

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

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

Например, вдруг оказалось, что в некоторых местах даже не очень длинные имена банально не влезают в отведённое пространство. Тут средней длины имя домена, тут фамилия пользователя, и вот емейл созданный по шаблону либо вылезает за границу поля, либо не виден полностью, либо появляется горизонтальная прокрутка на сайте, или ещё какое чудо случается. В первый раз очень удивляет: «обычный!»-то pb@pb1209.com нормально помещался, ничего не съезжало.

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

То же и при работе с названиями учреждений и компаний. Например, список ВУЗов города содержит много записей с одинаковым началом «Китежгородский государственный …» а до остального еще поди дотянись глазом. С выдуманными названиями можно и не обратить внимания, а с настоящими сразу приходит мысль, что хорошо бы указывать ещё и аббревиатуру на видном месте: тогда проще не спутать КГУ, КГИТ, КГМУ и т.п. То есть [почти] настоящие имена и названия помогают увидеть, обо что споткнётся пользователь — и вовремя улучшить эти коварные места.

Что до классов эквивалентности, то отчасти и их можно тестить с помощью настоящих имён. Так, по интернетам ходят слухи, что самое длинное имя содержит более 1000 символов. Как, обработает такое имя наш продукт? Или — имя не может быть длиннее 128 символов (БД ведь не резиновая)? А как насчёт имён, состоящих из нескольких слов и включающих в себя пробелы? Понятно, что индустрия таких людей не балует, они уже не ждут многого от IT и давно научились указывать краткое имя. С другой стороны — толика уважения, возможность указать полное имя, — такие вещи подкупают людей.

Так что теперь я использую имена и названия похожие на настоящие. Или — просто настоящие. Это привело к паре побочных эффектов. Первый из них: продукт тоже стал «более настоящим». Используя фейковые и тестовые имена я не мог отделаться от ощущения, что я не коммерческий продукт работаю, а играю в kind of компьютерной игры. Найди проблемы в продукте и добейся чтоб починили. Ачивку нарисуешь себе сам. А вот поверить, что продукт кто-то где-то по-настоящему использует — толком не получалось. То есть я знал, я видел проблемы утекшие к клиентам, обсуждал случившиеся на продакшенах фейлы, но ощущения что «всё по-настоящему» не было. С нормальными именами это ощущение стало появляться. Потому что в списках, формах и т.д. — не ерунда какая-то, не «абырвалг», а человеческие имена, адреса, телефоны, названия и прочая «ГлавРыба». К ним уважения и сочувствия больше.

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

Как по мне, вполне достаточная польза, чтоб использовать [почти] настоящие имена, названия и прочие атрибуты.

Напоследок пара слов о том, где взять эти самые имена: не тратить же время на выдумывание прямо во время тестирования.

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

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

[HDI] Увеличение своп-файла Linux без изменения разделов диска

Если вдруг потребовалось увеличить swap раздел на Linux’овой машинке, а править текущее разбиение диска на разделы не хочется, то можно поступить так:

# dd if=/dev/zero of=/var/swap bs=1M count=1048
# chmod 0 /var/swap
# mkswap /var/swap
# echo "/var/swap none swap defaults 0 0" >> /etc/fstab
# swapon -a

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

Ключевой момент тут count=1048 — этот параметр определяет, какого размера файл будет создан.

P.S. честно своровано отсюда

[HDI] Поиск и очистка inodes в Linux

Как известно, каждому файлу в Linux’е соответствует не только место на диске, но и некоторое количество inode. Как и место на диске, inod’ы тоже могут заканчиваться, и результат примерно тот же — создавать новые файлы становится невозможно.

Узнать, сколько inodes уже использовано можно с помощью команды

df -i

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

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


#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

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

P.S. своровано отсюда: http://stackoverflow.com/questions/653096/howto-free-inode-usage

[HDI] Создание ISO-файла в Linux

Создание ISO файла из подключённого CD/DVD диска

dd if=/dev/cdrom of=/cdrom_image.iso

где

  • dd == «disk dump» — утилита для побитового копирования
  • if == «input file» — устройство, откуда читать
  • of == «output file» — файл, куда писать

 

Создание ISO файла из папки

mkisofs -D -iso-level 4 -o ./myimage.iso ./myfolder/

где

  • -D — позволяет работать с деревьями папок глубокой вложенности
  • iso-level 4 — позволяет работать с длинными именами файлов
  • /myimage.iso  — путь к создаваемому ISO-файлу
  • ./myfolder/ — путь к папке, содержимое которой надо поместить в ISO-файл.