OpenQuality.ru

Страшный сон тестировщика, или не навреди

Здравствуйте.

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

Рассмотрим простой пример (Linux). Производится установка новой версии приложения с предварительным удалением старой. Вот кусок кода:

[root@rh43 tmp]# cat install.sh
#!/bin/sh
APPDIR=$1   # The first cmd line argument
# ... skipped ...
rm -rf $APPDIR/*
# ... skipped ...

При вызове ./install.sh /path/to/your/app будут удалены все файлы в указанном каталоге. А что если значением APPDIR будет пустая строка? Правильно. Удалим системные каталоги в корневом разделе.

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

Мы нашли баг в системной библиотеке и хотим заменить ее своей? Другие продукты могут просто не понять и откажутся работать. Лучше держать свои компоненты отдельно и обращаться к ним по мере необходимости.

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

Какие ресурсы потребляют наши процессы? Не пожираем ли мы память хранением промежуточных результатов? Не загружаем ли процессор бесконечными циклами?

Каковы права доступа у наших компонентов? Не будет ли наше приложение плацдармом для хакерских атак?

Как мы работаем с реестром в Microsoft Windows? Мусором не захламляем? На чужие ключи не покушаемся? Могут ли неувязки в нашем продукте повлечь за собой неработоспособность базовых сервисов? Чем больше мы погружаемся в недра OS, тем больше степень нашего влияния на жизнь системы. Насколько мы предупредительны к AD, Exchange, IIS?

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

Причинение ущерба операционной системе и сторонним приложениям – самый страшный сон для тестировщика. Спокойной ночи.

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 16.11.2008 в рубрике "Подходы"

Комментарии (3)

1. Pingback : OpenQuality.ru | Тайны острова сокровищ, или Exploratory testing | May 2, 2009

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

   
   

2. Pingback : OpenQuality.ru | Качество программного обеспечения | May 1, 2012

   […] • Один ма-а-аленький пробел в командной строке способен привести к удалению каталога в среде Unix (по следам наших выступлений). […]

   
   

3. Pingback : OpenQuality.ru | Качество программного обеспечения | August 7, 2014

   […] Всего доброго и полегче на поворотах. […]

   
   

Добавить комментарий