Отправляет email-рассылки с помощью сервиса Sendsay

Новые обсуждения форума тестировщиков Software-Testing.Ru

Подписаться Бесплатная «Серебряная» новостная рассылка Подписчиков 580 RSS
←   Август 2007   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней 26 выпусков (3-4 раза в неделю)


Сайт рассылки: http://https://software-testing.ru/forum/
Открыта: 04-06-2004

Автор
barancev@gmail.com

Статистика

580 подписчиков
0 за неделю
←   Все выпуски   →

Новые обсуждения IT-форума: it4business.ru


it4business.ru - проект об IT для бизнеса  

Новые темы IT-форума

AutomatedQA - Functional Testing -> Тестирование Интерфейса
2007-08-27 12:36 Yuliya
Расскажите плиз каким образом происходит тестирование интерфейса в ТК.

Обеспечение качества ПО - QA -> Цели И Задачи Тестирования По
2007-08-27 14:24 SALar
Давно я не стартовал сам новых тем в нашем форуме :)

Цели и задачи тестирования ПО в разрезе задач обеспечения качества ПО и некоторые мысли по автоматизации тестирования ПО.

Источник: Переход к автоматизированнуму тестированию

====>> Цитата (Green @ 27.8.2007, 8:50) :
У тестировщика три основных задачи:
1. выявить как можно больше существующих дефектов и
2. проверить, что они устранены и
3. при устранении известных дефектов не были внесены новые баги (проверка целостности).

Все!
<<====

Не согласен с приоритетами в целом, но соглашусь с некоторыми выводами в разрезе задач автоматизации тестирования ПО.

Постараюсь кратко, но не обещаю:
1. Выявление ошибок не есть цель тестирования ПО.
2. Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.
3. Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.
4. Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.

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

Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.

Что значит требует?
Занимает много времени при ручном тестировании (повторяется циклически многократно и/или требует множества автоматизируемых операций перед проверкой ключевой функциональности, как например проверка операции закрытия переода в биллинге, тестирование которой требует введения данных о потреблении услуг) и может в перспективе с учётом затрат на приобретение и внедрение инструмента автоматизации окупиться в бюджете проекта. Финансовая окупаемость - это единственный фактор, который определяет целесообразность внедрения автоматизации тестирования ПО в проекте. Зачастую на финансовую окупаемость может положительно влиять внедрение практик и инструментов автоматизированного тестирования на уровне компании, а не отдельно взятого проекта.

Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?

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

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

Автоматизация набора регрессионных тестов
Я не совсем понимаю этузадачу как вид тестирования и для себя не выделяю, но формулировки в форумах встречаются именно такие. Для меня структура тестов любого функционала примерно следующая:
1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Ревьювится перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.
2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования). Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования. Составляется в процессе создания тестового набора. Ревьювится перед каждым прогоном набора приёмочных тестов, по сути перед каждым раундом тестирования при выкатке новой версии. Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.

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

Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов. Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций. Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.

Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.

AutomatedQA - Functional Testing -> Написание Ftp Клиента
2007-08-27 15:09 Dmitry N
Всем доброго времени суток!
Начинаю осваивать TestComplete версии 5.13 и одна из проблем, на которую сразу наткнулся - не могу средствами VBScript изобразить FTP и Mail клиента. Основная загвоздка - не могу найти ответ как можно на пример по какому то адресу отправить команду "EHLO", "CONNECT", "DIR" и т.д. После чего, естественно получить отклик сервера, послать следующую команду и т.д.
Заранее благодарен.

Hewlett-Packard (Mercury) - Quality Center -> Запуск Скриптов Автоматизированного Тестирования На Удалённой Машине И
2007-08-27 17:26 Mr.Noname
Возникла проблема, при запуске из QC скриптов тестов WinRunner'а выдавалось сообщение "connection refused"
Умные люди помогли её решить:

====>> Цитата :
Проблема: При запуске автоматизированного теста из qc выдается ошибка вида «отказано в доступе».

Решение:

1. Посмотреть события системы (Event Viewer =>system). Найти в списке запись с параметрами: type = error; Source = Dcom. Убедиться в том, что в description этого event содержится запись вида: Настройки разрешений зависящие от конкретного приложения не предоставляют разрешение Локально Активация для приложения сервера COM Server с CLSID {0B171F02-F204-11D0-9398-0080C837F11F}

2. Для предоставления прав текущему пользователю системы на Dcom компонент, CLSID которого указан в description, выполнить следующее: Служба комнопентов => настройка dcom => Найти Dcom по номеру из description event и выдать все права для пользователя на закладке «Безопасность» в окне «Свойства» данного DCom компонента. Права необходимо раздать в разделах «Разрешения на запись и активацию», «Права доступа», «Разрешения на настройку».
<<====

Вроде сработало. Приятной всем работы.

AutomatedQA - Functional Testing -> Чтение Http Запросов, Как?
2007-08-27 23:14 luckync
Скрипт пишу на С#
версия TestComplete 5.13

Задание:
Продукт в один из моментов работы отсылает через HTTP запрос, в котором передает набор параметров для сервера, нужно этот самый запрос "на лету" читать (в смысле во время выполнения тестового скрипта считывать чтобы в последствии сравнить с эталоном).

Как это сделать методом скрипта, чтобы это все делалось в автоматическом режиме?
и можна ли вообще реализовать?

пока все что нашел, это TrafficRecording (создается HTTPTask с которым потом вполне прекрасно можна работать через скрипт), НО саму запись HTTP коннекта пока научился запускать только ручным способом, а через скрипт никак help.gif cray.gif

Обеспечение качества ПО - QA -> Источники Информации О Unit Тестировании
2007-08-28 07:43 Sudo -NAT
Здравствуйте, мне нужна любая информация о UNIT тестировании, не могу ли бы вы подсказать источники в интернете, где можно найти статьи по данной тематике.

P.S. Прошу прощения если ошибся разделом.

Оставайтесь на связи, мы работаем для вас!

© 2007 | IT для бизнеса: it4business.ru
В избранное