- Форум тестировщиков
- → Публикации galogenIt
Публикации galogenIt
64 публикаций создано galogenIt (учитываются публикации только с 06 июня 2023)
По типу контента
По пользователю
#92634 Работа с логами
Отправлено автор: galogenIt 15 августа 2011 - 13:57 в SmartBear (AutomatedQA) - Functional Testing
А в чем смысл выгрузки сообщений лога в текстовый файл? Лог собственно и есть ТЕКСТОВЫЙ файл. Не эффективнее ли просто разобраться с разметкой лога?
Мы, например, на VS написали программу, которая анализирует логи и формирует Excel-файл (отчет) в удобном для восприятия и работы виде. Гораздо лучше разобраться с устройством лога и научиться работать с ним. Это открывает для вас самые широкие горизонты. Для нас открыло
Мы, например, на VS написали программу, которая анализирует логи и формирует Excel-файл (отчет) в удобном для восприятия и работы виде. Гораздо лучше разобраться с устройством лога и научиться работать с ним. Это открывает для вас самые широкие горизонты. Для нас открыло
#94805 VirtualBox
Отправлено автор: galogenIt 27 сентября 2011 - 11:26 в Автоматизированное тестирование
Странно, писал ответ. Куда исчез?
Нам никак не удается поработать с VB. Она у нас падает с ошибкой bad_coll_header или bad_pool_header. Ошибка возникает на гостевой винде. Можем повторить вручную при выполнении действий в тестируемом приложении. На VMW этого не происходит. В чем может быть проблема? VB 4+
Нам никак не удается поработать с 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».
Начиная с 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
tab15, совершенно прав. Проще сохранить в csv. Хотя нет никакого труда сохранить в ЛЮБОМ нужном Вам формате. Для этого нужно обратится к Excel как COM_объектуМожет просто сохранить в csv формате?
// 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? Если в нем контролов как грязи? И нужно ли это делать?
Да еще проблема, в том, что тестирование началось системно не так давно. Так что покрытие довольно слабоватое. главным образом генеральное направление и новый функционал
...
Я конечно понимаю, что никаких уличных методик нет, но есть некая практика, которая может быть весьма полезной ...
Скажем так. Мое представление классического тестирования. Есть бааальшая система. Типично, что она поделена на системы по-меньше, те в свою очередь и т.д. Декомпозиция, ведь.
Мы берем кусочек, выделенный и отработанный, тестируем на предмет наличия ошибок. Помечаем как годный и идем дальше не вспоминаня о этом моуле пока его кто-то не захочет дернуть. Так вот у нас сделать это крайне сложно. Такова архитектура.
Другая ситуация, протестировать все возможные аспекты практически нереально. Например влияние финансовых условий на конечные результаты, (суммы) выставляемые в автоматическом биллинге значений. Или как протестировать GUI? Если в нем контролов как грязи? И нужно ли это делать?
Да еще проблема, в том, что тестирование началось системно не так давно. Так что покрытие довольно слабоватое. главным образом генеральное направление и новый функционал
...
Я конечно понимаю, что никаких уличных методик нет, но есть некая практика, которая может быть весьма полезной ...
#91251 Особенности тестирования тяжелых бизнес-насыщенных приложений
Отправлено автор: galogenIt 14 июля 2011 - 05:12 в Тест-дизайн и ручное тестирование
Коллеги,
не могу назать себя очень опытным тестировщиком. Поскольку имел дело только с системами, заявленными в заголовке темы. Да и уж если совсем откровенно, то и система то была всего одна. Ни тебе веб-приложений, ни какого-то там встроенного ПО, ни наукоемких приложений, ни просто узкофункциональных продуктовых разработок от разных производителей в разной архитектуре, технологии и т.п. Да и методы и способы тестирования главным образом фокусируются на черном ящике и по сути проверке исполнения требований.
Вместе с тем тестируемая система представляет себе мощную платформу для разработки и реализации (автоматизации) самых разных бизнес-процессов. Разнообразие бизнес-задач, операций, частые изменения логики их работы, сложность построения их моделей создают определенные трудности в тестировании.
С другой стороны долго изучая подобную систему, постепенно сродняешься с ней что ли, понимаешь все ее проблемные места и сложности (кстати создает эффект, что начинешь аккурантно их обходить). Но все равно уровень тестирования недостаточен. Об этом говорим ПМ, сетуют аналитики, видно по пользовательским инцидентам.
Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?
не могу назать себя очень опытным тестировщиком. Поскольку имел дело только с системами, заявленными в заголовке темы. Да и уж если совсем откровенно, то и система то была всего одна. Ни тебе веб-приложений, ни какого-то там встроенного ПО, ни наукоемких приложений, ни просто узкофункциональных продуктовых разработок от разных производителей в разной архитектуре, технологии и т.п. Да и методы и способы тестирования главным образом фокусируются на черном ящике и по сути проверке исполнения требований.
Вместе с тем тестируемая система представляет себе мощную платформу для разработки и реализации (автоматизации) самых разных бизнес-процессов. Разнообразие бизнес-задач, операций, частые изменения логики их работы, сложность построения их моделей создают определенные трудности в тестировании.
С другой стороны долго изучая подобную систему, постепенно сродняешься с ней что ли, понимаешь все ее проблемные места и сложности (кстати создает эффект, что начинешь аккурантно их обходить). Но все равно уровень тестирования недостаточен. Об этом говорим ПМ, сетуют аналитики, видно по пользовательским инцидентам.
Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?
#91299 Особенности тестирования тяжелых бизнес-насыщенных приложений
Отправлено автор: galogenIt 15 июля 2011 - 07:17 в Тест-дизайн и ручное тестирование
Не, никакой не RUP. Водопад скорее, но такой неклассический, что-то от agile, что-то от других.RUP?Маловато данных для анализа ситуации. Как организован процесс разработки и конкретно тестирования? Есть ли требования и специальные люди которые ими занимаются? Какие ресурсы имеются у тестирования: люди, навыки? Какая цель ставится перед командой?Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?
Процесс организован примерно так:
есть некоторые длинные работы-проекты, многорелизные.
Релиз типично занимает 2 месяца. Накануне планируется список работ к исполнению: исправление сложных ошибок, доработка, новый некрпный функционал или достаточно быстро разрабатываемый, работы на проектирование и подготовку длинных задач.
В конце периода дней за 10 - бранч. Тестирование происходит практически с момента начала нового релиза в фоновом режиме - (регрессия) + проверка релизных работ вручную с проектированием и реализацией новых автотестов.
Затем ставят на учебную базу скажем так для бета-тестирования, а потом на живую на бета-тестирование но уже в таком жестком режиме.
Группа тестирования: 6 человек. 1 системный программист, 3 прикладных тест-программиста, 1 тест-дизайнер-аналитик, 1 руководитель
2 сотрудника с годичным опытом, 1 с трехлетним, 3 в 2-2,5 годичным. Ранее нигде тестированием не занимались
Задачи: анализ логов прогонов автоматизированных тестов, прием работ над ошибками, прием релизных работ.
Цель по-моему одна - находить ошибки :) Ранее ставилась цель обеспечения устойчивости системы, отслеживание и перехват регрессии. Сейчас на раннее обнаружение ошибок, разгрузка аналитиков по приему релизных работ
Постоянно проверяем это. Регресс крутится в автоматическом режиме без нашего участия по ночам.Из опыта работы с большими (но не бааальшими) системами. А вы потом проверяете общую работоспособность системы? Регресс полностью пускаете по системе?К примеру, у нас модули связаны так, что даже когда разработчики уверяют, что вот это не трогали, то с вероятностью раз в год там что-то громко сломается :( И самое обидное, что может уже и у заказчика((Мы берем кусочек, выделенный и отработанный, тестируем на предмет наличия ошибок. Помечаем как годный и идем дальше не вспоминаня о этом моуле пока его кто-то не захочет дернуть. Так вот у нас сделать это крайне сложно. Такова архитектура.
У нас это легко может происходить ежедневно. Раз в год - это просто чудо :)
Проблема в том, что регресс на все не поставишь. Ясно, что там где идет интенсивное изменение и рефакторинг применяется и усиленное внимание. Однако бывает и так, что где-то тронули. Наш регресс прошел, поскольку он же не всемогущ, и проявляется у клиента :(
#93720 Ликбез по unit-тестированию
Отправлено автор: galogenIt 06 сентября 2011 - 06:26 в Автоматизированное тестирование
Коллеги,
не судите строго, но объясните на примере. Как правильно составить (вообще) как составить unit-тест, например для подобного кода?
Т.е. на выходе будем иметь ФИКСЦЕНА или НДСФИКСЦЕНА или СУММАФЦЗАПЕРИОД. Как правильно изолироваться от реальных объектов и переменных? Мне нужно объяснить это на пальцах, а лучше показать пример программисту, чтобы мотивировать его на создание собственных юнит-тестов. :)
Спасибо
не судите строго, но объясните на примере. Как правильно составить (вообще) как составить 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 в Автоматизированное тестирование
Большое спасибопереместил
- Форум тестировщиков
- → Публикации galogenIt
- Политика Конфиденциальности
- Правила форума ·