Перейти к содержимому

Публикации galogenIt

64 публикаций создано galogenIt (учитываются публикации только с 06 июня 2023)



#92634 Работа с логами

Отправлено автор: galogenIt 15 августа 2011 - 13:57 в SmartBear (AutomatedQA) - Functional Testing

А в чем смысл выгрузки сообщений лога в текстовый файл? Лог собственно и есть ТЕКСТОВЫЙ файл. Не эффективнее ли просто разобраться с разметкой лога?
Мы, например, на VS написали программу, которая анализирует логи и формирует Excel-файл (отчет) в удобном для восприятия и работы виде. Гораздо лучше разобраться с устройством лога и научиться работать с ним. Это открывает для вас самые широкие горизонты. Для нас открыло



#94805 VirtualBox

Отправлено автор: galogenIt 27 сентября 2011 - 11:26 в Автоматизированное тестирование

Странно, писал ответ. Куда исчез?

Нам никак не удается поработать с VB. Она у нас падает с ошибкой bad_coll_header или bad_pool_header. Ошибка возникает на гостевой винде. Можем повторить вручную при выполнении действий в тестируемом приложении. На VMW этого не происходит. В чем может быть проблема? VB 4+



#94890 VirtualBox

Отправлено автор: galogenIt 29 сентября 2011 - 06:11 в Автоматизированное тестирование

Это не особенность какого-то окружения на мой взгляд. На VMW в течение 3 лет актвиной эксплуатации на разных хостовых машинах и с разными гостевыми ОС не было такого НИ РАЗУ. А при первом же запуске VB- хлабысь и хлабысь в одном и том же месте. Загадка сия великая есть



#92578 Mantis на русский

Отправлено автор: galogenIt 13 августа 2011 - 17:14 в Управление тестированием

2 galogenIt - отличное владение копипастом

тогда уж копипейстом :)



#92020 Как файл .xls Save As .txt?

Отправлено автор: galogenIt 03 августа 2011 - 15:06 в SmartBear (AutomatedQA) - Functional Testing

Просто на форумах не всегда полезный пост сопровождается положенными благодарностями.
Так что я за всех скажу -- muchas gracias!
Побольше бы таких "банальных" ответов, подробно и по существу.

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

Но все равно, приятно получить "muchas gracias" :)



#92524 Mantis на русский

Отправлено автор: galogenIt 12 августа 2011 - 07:42 в Управление тестированием

Русификация Mantis

Начиная с MySQL 5.0, нужно явно задавать кодировку соединения (utf-8 или cp1251, в зависимости от выбранной русской локализации Mantis). Этот баг уже зарегистрирован http://www.mantisbt....php?bug_id=6782 , и возможно уже исправлен в последующих версиях, но в версии 1.0.6 (если база под MySQL 5.0), нужно добавить строчку-определение кодировки в функцию db_connect, файла core/database_api.php:
$t_result = $g_db->Connect($p_hostname, $p_username, $p_password, $p_database_name );
$g_db->Execute ("SET NAMES utf8");
При этом стоит использовать только «Настройки/Язык» из русских языков стоит использовать только «russian_utf8».



#91974 Как файл .xls Save As .txt?

Отправлено автор: galogenIt 02 августа 2011 - 17:34 в SmartBear (AutomatedQA) - Functional Testing

Никому не интересно? Или банальные вещи?



#91889 Как файл .xls Save As .txt?

Отправлено автор: galogenIt 31 июля 2011 - 18:58 в SmartBear (AutomatedQA) - Functional Testing

Может просто сохранить в csv формате?

tab15, совершенно прав. Проще сохранить в csv. Хотя нет никакого труда сохранить в ЛЮБОМ нужном Вам формате. Для этого нужно обратится к Excel как COM_объекту

// Excel - сохранить как----------------------------------------------------------------------------
// тип файла, если 1 - в формате "xls"
//                 6 - в формате "csv"
function SaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVariant;
begin
  _FileDelete(aFileName);
  vMsExcel := _OleObjectCreate();
  // сохраянем книгу
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Quit();
  vMsExcel := nil;
  // убиваем процесс
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
  // проверяем, существует ли сохраняемый файл; это и будет проверкой, что данная функция отработала нормально
  result := _FileExists(aFileName);
end;

или

// Excel - сохранить как...
// тип файла, если 1 - в формате xls, 6 - в csv
function ExcelSaveAs(aFileName : String; aFileType : Integer = 1) : boolean;
var
  vMsExcel : OleVAriant;
  p1       : OleVAriant;
begin
  if aqFile.Exists(aFileName) then
    aqFile.Delete(aFileName);
  Delay(2000);  
  // ожидание открытия окна MSExcel
  p1 := Sys.WaitProcess('EXCEL', 120000, -1);
  Delay(2000); // тут уж ничего неподелаешь ... непонятные тормоза независящие от процесса  
  if not (p1.Window('XLMAIN', '*').Window('XLDESK').WaitWindow('EXCEL7', '*', 1, 120000).Exists) then
  begin
    Log.Error('Окно Excel не открылось. Тест продолжен не будет');
    if Sys.WaitProcess('EXCEL').Exists then
      p1.Terminate();
      CloseProcess;  
    Runner.Stop(true);
  end;
  p1.Window('XLMAIN', '*').Minimize(); 
  Delay(5000);
  vMsExcel := Sys.OleObject('Excel.Application');
  vMsExcel.DisplayAlerts := False;
  vMsExcel.Workbooks.Item[1].SaveAs(aFileName, aFileType);
  vMsExcel.Displayalerts := 0; // типа отключить встроенные предупреждения Excel'я
  vMsExcel.Quit();
  vMsExcel := nil;
  
  while Sys.WaitProcess('EXCEL').Exists do
    Sys.Process('EXCEL').Terminate();
    
  if aqFile.Exists(aFileName) then
  begin
    Log.Message('Файл: ' + aFileName + ' - успешно сохранен.');
    result := true
  end else
  begin
    Log.Error('Файл: ' + aFileName + ' - не сохранен.');
    result := false;
  end;
end;



#91265 Особенности тестирования тяжелых бизнес-насыщенных приложений

Отправлено автор: galogenIt 14 июля 2011 - 09:15 в Тест-дизайн и ручное тестирование

Не могу выделять явную проблему, хотя ...

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

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

Другая ситуация, протестировать все возможные аспекты практически нереально. Например влияние финансовых условий на конечные результаты, (суммы) выставляемые в автоматическом биллинге значений. Или как протестировать GUI? Если в нем контролов как грязи? И нужно ли это делать?

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

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



#91251 Особенности тестирования тяжелых бизнес-насыщенных приложений

Отправлено автор: galogenIt 14 июля 2011 - 05:12 в Тест-дизайн и ручное тестирование

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

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

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

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



#91299 Особенности тестирования тяжелых бизнес-насыщенных приложений

Отправлено автор: galogenIt 15 июля 2011 - 07:17 в Тест-дизайн и ручное тестирование

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

RUP?Маловато данных для анализа ситуации. Как организован процесс разработки и конкретно тестирования? Есть ли требования и специальные люди которые ими занимаются? Какие ресурсы имеются у тестирования: люди, навыки? Какая цель ставится перед командой?

Не, никакой не RUP. Водопад скорее, но такой неклассический, что-то от agile, что-то от других.
Процесс организован примерно так:
есть некоторые длинные работы-проекты, многорелизные.
Релиз типично занимает 2 месяца. Накануне планируется список работ к исполнению: исправление сложных ошибок, доработка, новый некрпный функционал или достаточно быстро разрабатываемый, работы на проектирование и подготовку длинных задач.
В конце периода дней за 10 - бранч. Тестирование происходит практически с момента начала нового релиза в фоновом режиме - (регрессия) + проверка релизных работ вручную с проектированием и реализацией новых автотестов.
Затем ставят на учебную базу скажем так для бета-тестирования, а потом на живую на бета-тестирование но уже в таком жестком режиме.

Группа тестирования: 6 человек. 1 системный программист, 3 прикладных тест-программиста, 1 тест-дизайнер-аналитик, 1 руководитель
2 сотрудника с годичным опытом, 1 с трехлетним, 3 в 2-2,5 годичным. Ранее нигде тестированием не занимались
Задачи: анализ логов прогонов автоматизированных тестов, прием работ над ошибками, прием релизных работ.
Цель по-моему одна - находить ошибки :) Ранее ставилась цель обеспечения устойчивости системы, отслеживание и перехват регрессии. Сейчас на раннее обнаружение ошибок, разгрузка аналитиков по приему релизных работ

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

Из опыта работы с большими (но не бааальшими) системами. А вы потом проверяете общую работоспособность системы? Регресс полностью пускаете по системе?К примеру, у нас модули связаны так, что даже когда разработчики уверяют, что вот это не трогали, то с вероятностью раз в год там что-то громко сломается :( И самое обидное, что может уже и у заказчика((

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



#93720 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 06:26 в Автоматизированное тестирование

Коллеги,

не судите строго, но объясните на примере. Как правильно составить (вообще) как составить unit-тест, например для подобного кода?
if vDoc.ClassID.InheritsFromClass(КПДокументНаПериод) and (позФИКСЦЕНА >= 0 or позНДСФИКСЦЕНА >= 0 or позСУММАФЦЗАПЕРИОД >= 0)  then
        begin
          netStrok := false;
          var ДопСостоянияДистр := ArrayToComma([СостояниеДистрибутива.Подключен, СостояниеДистрибутива.НаСкладе]);
          var ДатаНачала := EndOfDay(ToDate(vDoc.GetAttrValuesByName('ДатаНачала')));
          if fSN.AsString <> '' then
            ТекДистрибутив := Номенклатура.ВернутьДистрибутив(vDoc.Клиент, CommaGet(fSN.AsString, 0),
             Номенклатура(fArticle.AsInteger), ДопСостоянияДистр, ДатаНачала);
          if assigned(ТекДистрибутив) then
            var ФиксЦена := Rat.EvalQuery(
             SQLText
              !Select Reg.DistrFixedPrice
                From RegChangeDistributiv Reg
                Where Reg.Distributiv = &ToInt(ТекДистрибутив)&
                  and Reg.BeginDate <= &ToStr(ДатаНачала)&
                  and Reg.EndDate > &ToStr(ДатаНачала)&
                  and IsWorked = -1
                Order by Reg.BeginDate desc!
             end);
          ФиксЦена := ToFloat(ФиксЦена);
          if позФИКСЦЕНА >= 0 then
            vMas[i, позФИКСЦЕНА] := ФиксЦена;
          if позНДСФИКСЦЕНА >= 0 then
            vMas[i, позНДСФИКСЦЕНА] := Round(ToFloat(ФиксЦена) * fNDSRate.AsFloat / 100, 2, 1);
          if позСУММАФЦЗАПЕРИОД >= 0 then
          begin
            var ДатаОкончания := EndOfDay(ToDate(vDoc.GetAttrValuesByName('ДатаОкончания')));
            var КолМес := Функции_мат.КолМесяцев(ДатаНачала, ДатаОкончания);
            vMas[i, позСУММАФЦЗАПЕРИОД] := ФиксЦена * КолМес;
          end;

Т.е. на выходе будем иметь ФИКСЦЕНА или НДСФИКСЦЕНА или СУММАФЦЗАПЕРИОД. Как правильно изолироваться от реальных объектов и переменных? Мне нужно объяснить это на пальцах, а лучше показать пример программисту, чтобы мотивировать его на создание собственных юнит-тестов. :)

Спасибо



#93757 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 11:01 в Автоматизированное тестирование

Лучше это перенести в форум по Автоматизации тестирования, а не с привязкой к конкретному инструменту.
Только сегодня наткнулся на отличное видео про юнит тесты. Рекомендую к просмотру вместе с программистом. Там как раз подробно объясняется, как изолироваться от внешних зависимостей.

Спасибо за совет.

Посмотрел видео (вместе с программистами). Не это не айс. Это конкретный пример реализации, причем очень запутанный и слишком ограниченный по возможностям, исполнению. Да и доклад слишком растянут, а в сухом остатке имхо одни междометия

Коллеги-модераторы, можете сделать это? Перенести тему.



#93780 Ликбез по unit-тестированию

Отправлено автор: galogenIt 06 сентября 2011 - 18:33 в Автоматизированное тестирование

переместил

Большое спасибо