Как стать автором
Обновить

Компания НПО «Компьютер» временно не ведёт блог на Хабре

Сначала показывать

Поддержание «стороннего» информационного ресурса. Как и для чего

Время на прочтение7 мин
Количество просмотров6.5K
С 2006 года наша компания вкладывает в «самостоятельный» инфоресурс — ecm-journal.ru. Предвкушая, что вопросы «самостоятельности» и «независимости» могут казаться спорными, сначала пишу определения в кавычках; но, в общем-то, эпитеты имеют место быть.



Под катом — попытка снять бремя кавычек, рассказ о работе с ресурсом, расчет затрат на его поддержание и описание получаемых эффектов. Предназначено для маркетологов от ИТ и не только для них.
Далше
Всего голосов 29: ↑4 и ↓25-21
Комментарии22

Аналитический отчёт по трейсу Microsoft SQL Server

Время на прочтение23 мин
Количество просмотров18K
Аналитический отчёт по трейсу Microsoft SQL Server

Постановка задачи


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

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

Используемые технологии:
  • Microsoft SQL Server;
  • Microsoft Office Excel;
  • Комплекс sql-запросов, организованный в проект SQLProfilerReportHelper;
  • Инструмент нагрузочного тестирования с возможностью выполнить sql-запрос (JMeter, Visual Studio Ultimate, ...);


Уровень 300 (для профессионалов).

Если коротко, то порядок действий для формирования отчётов по готовому трейсу таков:
  1. запустить SQLProfilerReportHelper, кликнуть по кнопкам;
  2. выполнить выборку записей из таблиц-отчётов, скопировать результаты в буфер обмена;
  3. запустить Microsoft Office Excel, вставить записи из буфера в автоматически форматируемую таблицу и сохранить документ-отчёт.

Инструмент и шаблон отчёта доступны для скачивания SQLProfilerReportHelper.
Если вам интересно ознакомиться с описанием инструмента и отчётов и порядком их составления, читайте далее.
Тысячи символов, десятки картинок и примеров кода
Всего голосов 8: ↑6 и ↓2+4
Комментарии1

Создание User-Friendly движка бизнес-процессов на основе Windows Workflow Foundation

Время на прочтение5 мин
Количество просмотров8.8K

Постановка задачи




Одной из неотъемлемых частей любой ECM-системы является управление бизнес-процессами, или workflow.

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

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

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

При разработке новой версии движка бизнес-процессов мы решили попробовать Windows Workflow Foundation (далее WF).
Читать дальше →
Всего голосов 9: ↑8 и ↓1+7
Комментарии11

Классификация видов тестирования

Время на прочтение5 мин
Количество просмотров215K
Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.
Виды тестирования

О ней и будет сей рассказ.
Всего голосов 71: ↑64 и ↓7+57
Комментарии35

Группа тестирования в Scrum-проекте

Время на прочтение5 мин
Количество просмотров17K


У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:
  • командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
  • автоматизация рутины важнее задавливания массой;
  • быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
  • доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
  • открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
  • демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
  • необходимый минимум правил, но требовательность при их исполнении;
  • когда все думают одинаково — никто не думает;
  • «мужик сказал — мужик сделал», все несут ответственность за свои решения.

Все хорошо, но несколько лет нас не отпускали мысли о том, как организовывать тестирование. Мы немало поэкспериментировали, прежде чем пришли к нынешнему положению вещей.
Читать дальше →
Всего голосов 11: ↑8 и ↓3+5
Комментарии13

Как мы практикуем коридорное тестирование

Время на прочтение2 мин
Количество просмотров3.9K
Разработчики хотят делать понятные и удобные программные продукты.
Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:
image
Если к программе можно написать плагин, то она удобная и расширяемая. Если можно поменять в конфиге цвет фона окна сообщения — гибкая. Нормальному же пользователю от такой гибкости ни тепло ни холодно, ему свои задачи надо решать, а не плагины писать.

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

Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.
Читать дальше →
Всего голосов 11: ↑5 и ↓6-1
Комментарии0