owasp

Если использовать xpath с абсолютными путями, то могут появиться ложные срабатывания?

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

При изменении дизайна, придётся не один раз изменить селектор для основного элемента, а изменить его несколько раз - дополнительно поправив селекторы дочерних элементов.

В моём проекте есть строки таблицы (которые могу уникально определить), а внутри строк есть всплывающие элементы - кнопки действий, что появляются для каждой строки при наведении. И у кнопок своих уникальных селекторов нет.
Единственный вариант уникального селектора для всплывающего элемента, заданный относительно браузера - "Уникальный селектор основной строки" + "селектор всплывающего элемента".
Но можно, ведь, получить основную строку по селектору "Уникальный селектор основной строки", а уже относительно полученного IWebElement получить дочерние элементы по коротким относительным селекторам "селектор всплывающего элемента".

Если использовать Java и базовый паттерн PageObject, то задавать относительные селекторы в атрибутах нельзя - все селекторы задаются относительно браузера => приходится дублировать селекторы.
Если использовать чистый PageObject, то работу со всплывающими элементами без дублирования селекторов можно организовать передавая в методы работы с ними базовый для них IWebElement (а относительно него искать).

Можно использовать паттерн HTML Elements, который реализован в разработке Яндекса, тогда исключается дублирование кода и дублирование селекторов:
http://habrahabr.ru/...ex/blog/158787/
https://github.com/y...ls/htmlelements

В своих тестах использую C#. Идеи HTML Elements повторил, как сумел, средствами dotNet. Получилось сыровато (есть проблема, когда компонент вложен в компонент, вложен в компонент и все эти элементы не являются кешируемыми - конечные узлы ищутся долго), но работает. Думаю сделать механизм обновления дерева компонент (Refresh()), как это сделано в TestComplete и разрешить каждому компоненту кешировать экземпляр своего родительского компонента. Это немного увеличит затраты по памяти (16 байт на ссылку), но увеличит быстродействие.

1) Указатель оказывается в том месте, куда он был помещён. На своё реальное место указатель не возвращается.
2) Имеет значение. Чтобы навести указатель на элемент, который может быть в конце страницы (быть не видимым) можно пробовать отображать его, используя скроллинг.
Например, в C# это делается при получении значения свойства LocationOnScreenOnceScrolledIntoView см. http://selenium.goog...ledIntoView.htm

var fakePoint = (iwebElement as Locatable).LocationOnScreenOnceScrolledIntoView;
var fakePoint = (iwebElement as RemoteWebElement).LocationOnScreenOnceScrolledIntoView;

В Java есть аналогичный get-метод

getLocationOnScreenOnceScrolledIntoView()

, см. http://selenium.goog...rolledIntoView()
3) Особо с hover-элементами не работал, но понятно, что при работе с ними можно:
3.1. использовать поиск относительно базового элемента, на котором сейчас фокус, а не относительно страницы браузера. Так как поиск относительно браузера даст ложные срабатыввания (если не фильтровать по видимости) и будет выполняться дольше.
3.2. не использовать кеширование элементов (каждый раз искать элементы по новой), так как наличие hover-элемента на странице непостоянное.

Да, дело в траектории движения мыши.
moveToElement передвигает указатель от ценра элемента "Ходожественные фильмы" к центру элемента "Короткометражный ходожественный фильм". На рис. 3 видно, что прямая соединяющая центры этих элементов проходит через "Документальные фильмы".

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

Используйте в реализации меню эффект запаздывания, или более удобно организуйте работу с выбором элементов следующего уровня (как в Amazone).
Для сравнения меню с запаздыванием и меню без запаздывания (но при этом рабочего, более удобного) можете обратиться к статье Загадка выпадающего списка «Амазона»: http://habrahabr.ru/post/171905/

Или в тесте нужно передвигать указатель не по прямой соединяющей центры пунктов, а по кривой, не задевающей другие элементы (но пользователи не будут так делать, и сложный дизайн не будет пользоваться популярностью).
Кривая следующая (вправо по горизонтали и, возможно, вниз по вертикали):
moveToElement(пункт меню)
moveToElement(первый пункт подменю)
moveToElement(нужный пункт подменю)
click(нужный пункт подменю)

Ребят, а как поступить в случае, если просто нет времени на обучение тестировщиков?

Они сами могут обучаться.

Но даже это требует времени. Формально процесс самообучения сводится к внутреннему обмену опытом в команде. Кто-то научился грамотно настраивать съём показаний счётчиков производительности и проанализировал какие из них важны, а какие не мало полезны. Кто-то грамотно настраивает proxy-сервера и мастерски отлаживает/замеряет/замедляет/... что-то с их помощью. Кто-то автоматизировал развертывание ПО в парке виртуальных тестовых стендов. И так далее.
Это надо заметить. Похвалить людей. Выделить время, чтобы они подготовились, как-то организовали знания по теме и рассказали о своём опыте коллегам (бывает, неделю надо готовиться к такому). Снова похвалить (поддержать общее одобрение проделанной работе).
Дальше можно сказать - мол, формализируй накопленный опыт, напиши инструкцию или руководство (на этом моменте можно зарубить стремление человека к дальнейшему самостоятельному изучению темы, если с его стороны ситуация будет выглядеть так: "напиши инструкцию, поставь точку и возвращайся к работе, дел полно", - то стремление изучать тему не усилится).
Или разобраться в вопросе, прикинуть как и где данные знания пригодятся, и спросить у человека совета, как лучше поступить вот так или вот так ... (не праздный интерес, а для пользы дела). Или ничего не делать, если люди самоорганизованные, они сами организуются.

Когда-то ведь работа, заканчивается. И вот тут стоит рассказать, как же она была сделана, и благодаря чему она была сделана хорошо. Конечно, если уйти в работу с головой, то всё вокруг кажется обыденностью, о которой и рассказывать не стоит (мол так всегда и было). Но всегда есть, о чем рассказать или написать.

Сложно объяснить, отделом не руковожу, работаю в нём (как мной руководят - не представляю, есть только некие ощущения). Технические знания у нас передаются между тестировщиками и разработчиками. Есть площадки для общения - внутренний портал, где люди обсуждают рабочие вопросы (если его нет, то надо сделать) и личное общение за чаем или за обедом. Или бывает дают возможность группового просмотра какого-то вебинара (как правило, бесплатного/рекламного/бесполезного) по рабочей теме. Но во время просмотра, узнаёшь, что коллеги думают по теме, узнаёшь что-то, и это общение даже важнее того, что говорит докладчик. Внешнее обучение - редкая ситуация, хотя, согласно статистике этому уделяется большое внимание (видимо, кого-то учат).

Здравствуйте. Да достаточно. Возможно, даже излишне достаточно, ведь можно обойтись меньшим.

При написании модульных тестов использую NUnit (см. http://www.nunit.org/). Атрибуты, Assert-ы, обработку исключений использую от NUnit, а не от Microsoft. Это позволяет разрабатывать тесты, например, в SharpDevelop или Visual Studio Express. Основная причина, почему отказался от Microsoft Unit Testing:

• Сложно параметризировать модульные тесты, а нужна была именно параметризация. NUnit позволяет задавать списки параметров через явное определение (Values, см. http://www.nunit.org...=values&r=2.6.2 ), что гораздо удобнее чем CSV или Datasource (таблица или представление базы данных).
• Тесты нужно выполнять на нескольких конфигурациях. При использовании mstest на машине где запускаются тесты нужно иметь Visual Studio. Это несложно, количество имеющихся лицензий позволяет поставить. Но NUnit гораздо меньше Visual Studio, подготовить стенды было проще.

Конечно, результаты NUnit не сохраняются автоматически в TFS, в отличие от использования mstest (использование фреймворка Microsoft), и это недостаток. Но так как не было требований со стороны разработчиков, отображать результаты тестов в TFS, то всё нормально,

Что касается Microsoft Test Manager, не имею опыта работы с этим продуктом. Но если это большой продукт, то думаю он не нужен для выполнения модульных тестов. Вам стоит стремиться к автоматизации их выполнения. А значит тесты нужно выполнять одной командой, используя nunit или mstest. А если требуется более сложный анализ, например, анализ логов по завершении теста, и автоматическая рассылка результатов, то можно использовать сценарии nant, powershell или даже bat (или функционал TFS, раз у вас используется TFS).

BDDfy - хороший вариант.
В этом фреймворке есть три способа привязаться к тестам:

• Attributes - указав атрибуты у модулей.
• Method name convention - указав полное описание сути теста в имени метода.
• Fluent API - самый гибкий вариант, так как позволяет указывать описание во время выполнения (используя его).

Например, тест выполняется с использованием Mozilla Firefox (на данной итерации). Поэтому метод Init сейчас будет инициализировать WebDriver для этого браузера. В истории это можно отразить.

[Test]
public void CardHasBeenDisabled()
{
    foreach(EnumBrowser browser in listTestBrowser)
    {
        this.Given(s => s.Init(browser), String.Format("Имеется браузер {0}", browser))
            .When(s => s.NavigateToStartPage(), "Когда осуществлён переход на стартовую страницу")
            .Then(s => s.StartPageTitleIsOK(), "Тогда заголовок страницы соответствует ожидаемому")
                .And(s => s.LoginFormIsExist(), "И форма аутентификации корректно отображена на странице")
                .And(s => s.ErrorsInLogsNotExist(), "И в логах сайта нет ошибок")
                .And(s => s.ErrorsOnPageNotExist(), "И на странице нет ошибок")
            .BDDfy();
    }
}

Обратите внимание, что текст истории параметризован в данном примере. Имя браузера (элемент перечисления, написание которого близко к оригинальному названию) передаётся в историю, конкретизируя её содержание.
И как понимаете, журнал имееет самый низкий уровень детализации. Конкретную информацию с указанием строки, в которой генерируется исключение можно найти в trx-файле, которое генерируется средой исполнения (visual studio).

Вот тут рекомендуют другой способ: http://software-test...-platform-bddfy
Но о нём узнал недавно и ещё не использовал. Собственно, то, чего нет в используемом сейчас способе - сейчас нет записи видео о прохождении теста. А в остальном, история и скриншоты есть.

Мечтаю сделать такой же способ ведения истории тестирования какой есть в Visual Studio 2012 Ultimate для нагрузочного тестирования - попробовал его на бесплатной beta версии продукта. Где ход ведения теста записывается в базу данных. Такой же подробный сбор информации есть в инструменте нагрузочного тестирования Яндекс Танк. Но это нагрузочное тестирование.
Когда текущего уровня детализации ведения журнала будет нехватать, то использую NLog или библиотеку ведения логов из Microsoft Best Practis (забыл как она называется). И можно будет сохранять историю в БД.

Мысль об ограниченности строки не является совсем верной. Формально в базе данных унжно будет хранить лишь хеш пароля. В зависимости от функции хеширования, для хранения надо будет зарезервировать 256 или 512 байт.
А каким же может быть сам пароль:

• Классический, человеческий.
• Машинно-сгенерированный (который не запонимается, а берётся из менеджера паролей).

Если отбросить факт использования менеджеров паролей, то максимальная длина может быть любой. А если не отбрасывать, и обратить внимание на документацию этих программ (ссылки можно посмотреть в статье http://habrahabr.ru/post/125248/), то можно заметить, что распространено использование в качестве паролей хешей. Длиной 256-bit (32 байта, 64 символа, при отображении набором символов для 16-ти ричной системы), реже 512-bit (64 байта, 128 символов, при отображении набором символов для 16-ти ричной системы: [a-f, 0-9]).

То есть, ограничивая максимальную длину пароля, оставьте возможность использования программно-генерируемых паролей длиной порядка 64 символа (можно и 128).

И правильно было замечено, что слишком большое ограничение на пароль может привести к появлению слабого места в системе.
Например, на веб-сайте максимальная длина пароля = 1048576 байт (1 МБайт), и известно, что:

• передача такого длинного пакета от клиента к серверу занимает 4 секунды.
• вычисление хеша для такого пароля, используемой функцией хеширования занимает 6 секунд (и при том загружает процессор сервера на 100% и потребляет на сервере 38 МБайт оперативной пмяти) - цифра выдуманная и нереальная, но допустим используется такой кривой алгоритм хеширования.
• на сайте не предусмотрена защита от брутфорса (например, при вводе 5-ти неверный паролей подряд, доступ к сайте не блокируется для IP-адреса или логина)
• вычисление хеша вычисляется на этом же сервере, не используются очереди операций и другие "разгружающие" подходы в архитектуре системы

Тогда злоумышленник может сделать DoS (отказ в отслуживании), просто послая (в одиночку) по 10 запросов в минуту к сайту. Сайт будет постоянно загружен и потребит всю память. В отличие от DDoS (Распределённый отказ в отслуживании), злоумышленник может в одиночку положить сервер, ему не нужно 1000000 ботов.

Но в реальности, хеши вычисляются быстро. Думаю даже 1 МБайт для пароля - не является проблемой, если сервер достаточно новый. Кроме того, можно вынести все трудоёмкие операции в очередь. А также предусмотреть защиту от брутфорса. Тогда можно использовать в качестве пароля, что угодно, любого размера (например, аутентификация по уникальному файлу размером 4 МБайта со случайным содержимым, или просто уникальным содержимым - фотография или звукозапись).

Вы не можете получить тег "a", ведь вы ищите тег первый тег "div" среди всех: driver.findElelment(by.xpath("//div")).

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

fireBug - это отладчик для JavaScript. И на вкладке "Сценарий" там отображается JavaScript код, а не разметка (но это не суть).
Вероятно, элементы на вашей странице создаются динамически, и пока JavaScript не отработал, их нет, и title нет. И fireBug показывает разметку после отработки JavaScript (результат отладки), а браузеры показывают исходное состояние страницы (первоначальное, до обработки JavaScript).

Ищите по форуму темы:

• Ajax + Selenium (это не то, что нужно, но близко по теме)
• Selenium и ожидание загрузки страницы (это тоже не то, что нужно, но близко)
• Selenium и ожидание формирование страницы (вот это то, что нужно)
• ...

А как ожидать появления элементов, написано в справке.
Раздел "Неявные ожидания": http://selenium2.ru/...waits-reference

Какие тесты забыли:

• При запуске номер порта не является номером из диапазона 0...65535 (является строкой, отрицательным числом, слишком большим числом - должна быть корректная ошибка или должен использоваться порт по умолчанию - 4010, если его использовать возможно).
• При запуске номер порта не указан (должен использоваться порт 4010, надо проверить, что именно он и используется).
• При запуске указан номер порта, который уже занят (должно быть корректное сообщение об ошибке, тест простой - дважды запустить программу с одним и тем же значением параметра).
• При запуске указан номер порта, который не занят (должно быть всё корректно, порт будет открыт сервером) - этот тест вы не забыли, он тут так, для полноты.

Проверка того, как устанавливается соединение:

• Сервер может слушать только 127.0.0.1 (тогда из вне к нему не подсоединиться)
• Сервер может не отправлять ответ, если ответ пришёл с локальной машины.
• ...

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

Но это всё ручные проверки. Автоматизация - важная часть часть задания.
Как посылать запросы описано тут, например (первое, что дал Яндекс по запросу: MSDN Samples TCP Client):
http://msdn.microsof....tcpclient.aspx

Там в примере буфер для получения ответа фиксированного размера (256 символов). Для получения фразы «Hello, World» хватит, для получения текстов с сообщениями об ошибке - тоже (но не факт, что полностью, если сервер будет распечатывать стек вызова в обработчике исключений, то не влезет). Плюс надо будет сделать замер времени: из времени получения ответа, вычитать время начала установки соединения.

• Сделайте цикл от 0 до 255, отправьте все байты, проверьте, что всегда вернётся «Hello, World».
• А потом пошлите 2 байта.
• А потом пошлите 20000 байт.
• Пошлите запрос и закройте соединение.

Дорабатывал.
Когда в TestLink ещё не было поддержки кастомизации стилей, использовался плагин Stylish для FireFox.

Текст стиля для Slylish такой:

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document url-prefix("http://testlink/lib/execute/execNavigator.php"),
url-prefix("http://testlink/lib/general/mainPage.php"),
url-prefix("http://testlink/lib/testcases/listTestCases.php?feature=edit_tc"),
url-prefix("http://testlink/lib/general/staticPage.php"),
url-prefix("http://testlink/lib/execute/execSetResults.php")
{
    #ext-gen8
    {
        height: 100% !important;
        width: 100% !important;
        background-color: white !important;
        background-image: none !important;
    }
    div.vertical_menu
    {
        width: 300px !important;
        font-size: 100% !important;
        background-color: transparent !important;
    }
    div.x-tl-panel-header-text
    {
        font-size: 15px !important;
        font: bold 15px tahoma,arial,verdana,sans-serif !important;
    }
    div.testproject_title form select
    {
        width: 100% !important; 
    }
    #tree
    {
        height: 100% !important;
    }
    div.x-panel-header, div.x-tl-panel-header
    {
        background-image: url(http://testlink/custom/white-top-bottom.png) !important;
        border-color: black !important;
    }
    div.workBack, div.x-panel-body, div.x-tl-panel-body, div.testproject_title
    {
        background-image: url(http://testlink/custom/fon3.png) !important;
        background-color: transparent !important;
        border-color: black !important;
    }
    div#testspecification_topics a, div#requirements_topics a, div#testproject_topics a, div#test_plan_mgmt_topics a, div#ext-gen33 a, div#ext-gen38 a
    {
        color: white !important;
    }
    div.exec_tc_title, h1.title, body#ext-gen6
    {
        background-image: url(http://testlink/custom/fon0.png) !important;
    }
    b.niftycorners
    {
       visibility:hidden !important;
       height: 0px;
    }
}

@-moz-document url-prefix("http://testlink/login.php")
{
    body, div.messages
    {
        background-image: url(http://testlink/custom/fon0.png) !important;
        text-align: center;
    }
    
    div.forms
    {
        margin:20px 30% 40px 30% !important;
        min-width: 260px !important;
    }
    div.forms, div.fullpage_head, h1.title
    {
        background-image: url(http://testlink/custom/fon3.png) !important;
    }
    
    b.rb1, b.rb2, b.rb3, b.rb4, b.rb5, b.rb6, b.rb7, b.rb8, b.niftycorners
    {
       visibility:hidden !important;
    }
}
@-moz-document url-prefix("http://testlink/lib/general/navBar.php")
{
    body, div.x-panel-body, div.x-tl-panel-body, div.testproject_title
    {
        background-image: url(http://testlink/custom/fon3.png) !important;
        background-color: transparent !important;
        border-color: black !important;
    }
}

Недостающие картинки: testlink_style_png.zip (1,13кБ)

Думаю, что COM-интерфейс к excel + COM-интерфейс к MSXML сделают своё дело.
В качестве примера могу дать Word2TestLink (у нас тесты пишутся в Word-е, так было исторически).

Word 2 Testlink - сценарий переноса структуры тестов из документа Microsoft Word в систему урпавления тестами Testlink. Есть две версии (обе написаны на VBS + XSLT, поэтому исходный код и есть программа):

• Версия 1.0.4:
  
  
• Дистрибутив: Word2TestLink.1.0.4.hta.zip
• В документе описывается иерархия тестов (без списка шагов, подробных описаний и ожидаемых результатов) в виде иерархического списка.
• Структура тестов определяется иерархией элементов списка.
• Перед передачей документа утилите Word 2 Testlink нужно убрать из документа всё, кроме структуры тестов (самого списка).
• Есть:
  
• Заголовок теста
• Описание теста (одна строка)
• Шаг теста (одна строка, только один шаг)
• Ожидаемый результат (одна строка, только один ожидаемый результат)

[*]Версия 1.0.5.

• Дистрибутив: Word2TestLink.1.0.5.hta.zip
• В документе описывается иерархия тестов с шагами, подробными описаниями, ожидаемыми результатами.
• Структура тестов определяется по иерархии заголовков документа.
• Перед передачей документа утилите Word2Testlink ничего из документа убирать не нужно, Word2Testlink найдёт заголовок "Тестовые условия" и всё содержимое соотвествующего раздела/главы перенесёт в xml-файл.
• Есть:
  
• Заголовок теста
• Описание теста (любое число строк и абзацев)
• Шаги (любое количество шагов)
• Ожидаемый результат (любое количество ожидаемых результатов)

[/list]
Краткое описание формата входного документа для 1.0.4
В проекте тестов (в документе Word) используются следующие соглашения по разметке:

• {...}​ - описание группы тестов или теста;
• (*...*) - шаг;
• [...] - ожидаемый результат.

Иерархия тестов определяется иерархией списка тестов, в одной строке надо описать один тест полностью. Раньше (до TestLink 1.9.3 не было отдельных шагов и отдельных ожидаемых результатов, было только одно поле Шаг и одно большое поле Ожидаемый результат, вот в те времена использовали такой способ написания, если его использовать сейчас, в 1.9.3, то будет заполнен только первый шаг и первый одижаемый результат).
Например:

• Функциональное тестирование {описание группы тестов - необязательно}
  
  • Поиск в графическом режиме {Это соновной способ выполнения поиска, тесты этой группы надо выполнять в первую очередь}
    
    • Единый поиск по всем объектам {описание группы тестов - необязательно}
      
    • Поиск по тексту документа {Поиск по тексту версий документа} (*Ввести в критериях поиска текст, который не состоит полностью из стоп-слов (or, the, and, a, ..., к, в, от, ...), текст должен содержать слова, используемые в тексте одной из версий документа, разрешаетс использовать символ *, и выполнить поиск.*) [В результатах поиска будет показан документ, в версии которого точно содержится поисковая фраза, поиск выполнится быстро, в результатах поиска не будет лишних элементов]
    • Поиск по реквизитам карточки документа {описание - необязательно} (*шаг - необязательно*) [ожидаемый результат - необязательно]
    • Поиск по реквизитам карточки папки {описание} (*шаг*) [ожидаемый результат]
  • Обновление результатов поиска без смены критериев {описание}
    
    • Какой-то тест {описание} (*шаг*) [ожидаемый результат]
  • Уточнение критериев поиска {описание}
    
    • Какой-то тест {описание} (*шаг*) [ожидаемый результат]
• Выполнение поиска через объектную модель {описание}
  
  • Тест {описание} (*шаг*) [ожидаемый результат]
  • Тест {описание} (*шаг*) [ожидаемый результат]
  • Тест {описание} (*шаг*) [ожидаемый результат]

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


Краткое описание формата входного документа для 1.0.5.
Когда в TestLink поиявились отдельные строки для шагов и для каждого шага стало возможным задание ожидаемого результата, то была сделана ещё одна версия.

• Тестами считаются все элементы, начиная с заголовка 1-го или 2-го уровней, начинающегося со слов "Тестовые условия" и до заголовка уровня 1 или 2 (или до конца документа, если заголовков уровня 1 или 2 не будет найдено).
• Струкура тестов определяется уровнем вложенности заголовков, таким образом будущую иерархию тестов можно наблюдать в левой панели "Иерархия" Microsoft Word.
• Элементы иерархии, что не имеют вложенных элементов (за ними нет заголовков, чей уровень превышает по номеру уровень текущего), считаются тестами, для них обрабатываются описания, а также шаги и ожидаемые результаты.
• Элементы иерархии, что имеют вложенные элементы (за нимим идут заголовки, номер уровня которых больше текущего) считаются группами, для них весь текст от текущего заголовка (названия группы) до сделующего (название вложенной группы или тестов) считается описанием текущей группы тестов и переносится в поле описание.
• Шаги и ожидаемые результаты оформляются в виде таблицы. В таблице должно быть 2 столбца, первая строка таблицы не обрабатывается (считается что там всегда записано в первой колонке текст "Шаг", а во второй "Ожидаемый результат" - заголовки колонок), а все последующие строки таблицы обрабатываются и переносятся как шаги и соотвествующе ожидаемые результаты.
• Также есть выгрузка картинок, вставленных в документ (картинки будут видны в TestLink).

На будущее
По хорошему, надо привести пример документов. И так-то обещал сделать это для одной девушки (Татьяна из компании ЦВТ), обещание было дано давно, ещё на презентации Visual Studio 2011 beta (13 апреля 2012 года). Но текущая документация на Word2TestLink содержит текст тестов, которые нельзя демонстрировать другим. А переписать документацию всё нет времени.

Но как-нибудь после майских праздников перепишу, или попрошу коллег на работе сделать это (придумать тесты при кофеварки, звездолёты и так далее, на английском хочется). И будет релиз. Верну моральный долг сообществу, подарившему TestLink компании, в которой работаю.

Копилефт
Лицензия на Word2TestLink - GNU GPL последней версии.

Здравствуйте!
Может кто уже тестировал сайты с онлайн интернет-банкинкг, какие особенности? как проверить на защищённость. В общем впервые столкнулась с таким...

Компания Digital Security проводит вебинары http://dsec.ru/press...es/?news_id=312 (планирует).


Вебинар: Где лежат деньги? – 19 апреля 2012 года.
Ведущий – Алексей Синцов, руководитель департамента аудита ИБ

На вебинаре будет рассказано о проблемах онлайн-банкинга с точки зрения безопасности. Будут раскрыты реальные проблемы юридических лиц с обеспечением информационной безопасности рабочего места сотрудника, работающего с банк-клиентом, а также уязвимости инфраструктуры отечественных банков перед возможными угрозами. Кроме того, в докладе будет показано множество 0-day уязвимостей реальных систем онлайн-банкинга (вся информация обезличена), а также общие ошибки всех разработчиков отечественных популярных продуктов. И, конечно же, будет рассказано, к чему все это приводит с точки зрения вероятности хищения денежных средств…

Регистрация: https://www3.gotomee...ister/193608150
Денег не требуют.

Также есть хорошая статья в журнале системный администратор
http://samag.ru/archive/more/116

POS-системы. Методы защиты
Привыкли расплачиваться в магазинах пластиковой картой? Давайте рассмотрим, какие меры предпринимают банки для того, чтобы защитить нас от «электронных» мошенников.
Автор: Иван Михайлов

Короче - какова цель? Что хотим узнать?

Насколько программа подвержена не санкционированному копированию.

Посмотрите отчёты по прохождению различных crackme. Как правило один crackme соответсвует одному способу защиты (приёму для её обхода).
Рекомендуемые ресурсы: wasm.ru (а также фоурм ресурса), и другие ресурсы по Assembler, защите, ...

Например, у вас используется следующий комплекс защитных мер:
1. Проверка пароля, записанного в конфигурационный файл, при запуске
- возможно обходится поиском места операции сравнения этого пароля и записью его в конфигурационный файл.
- если же происходит не прямое сравнение строк, а ещё куча криптографии, вривязка к SID, ... то возможно будет проще пропатчить исполняемый файл, чтобы он всегда возвращал положительный результат проверки.
2. Наличие антиотладочных функций (чтобы нельзя было узнать суть защиты)
- проверка, что Olly Debugger 1.0 и 2.0 (+ вариации, как Immunity Debugger) не отлаживают программу, вообще не могут найти точку входа.
- проверка что Hview тоже ничего не видит (точку входа).
- что IDA не мжет дизассемблировать код.
- что Windows Debugger не справился.
3. Возможно для защиты от копировать какие-то данные передаются по сети
- проверка что не сервер передаёт клиенту ключ, а наоборот (такое тоже может быть)
- проверка что непонятно из чего сформирован ключ
- проверка, что у двух разных клиентов на раных машинах, ... будут созбарны разные ключи запроса
4. Вероятно используется криптография:
- проверка что критография надёжная
- что используется для хеширования не CRC32, не MD4 и даже не MD5, а 100-кратный MD5 с солью, SHA, или надёжное шифрование
5. Если используется "отложенная проверка", то:
- проверка, что отложенная провека проверка срабатывает при запуске, при сохранении, при экспорте, ...
- что её сложной обойти
6. Проверка, что у исполняемого файла есть защита от модификации:
- зашифрованные и упакованные критические участки кода (для простоты подойдет даже бесплатные и для .NET и для нативных приложений есть, но можно и самому написать)
- проверка цифровой подписи исполняемого файла

Почитайте, поспрашивайте, выпишите тесты. А потом отчёт - пройден (вот в такой конкретной ситуации)/не пройден/требует дальнейшего изучения (непройден, но большой кровью, стоимость взлома несопоставима со стоимостью ПО).

Чем занимается наш руководитель:
1. Составляет планы на месяцы вперёд (очень хорошо и точно, с реальными сроками)
Когда этого не было, сроки спускались "сверху", а так как тестировщики последние в пищевой цепи, то сроки были жёсткими. Суббота была "официальным" рабочим днём. И никто не был удовлетворён ни одним своим планом тестирования (каждый раз что-то не успевалось, откладывалось, ...).

2. Внедряет инновации
Если кто-то захочет, например, изучить руководство по безопасности WCF, самостоятельно, ему скажут - да иди ка ты, тут работы полно.
А если сказать руководителю, что так-то так-то, есть такое руководство, на 600 с лишним страниц, надо изучить и оценить что там не так, возможно, с нашими тестируемыми веб-сервисами. Если ответ - хорошо,приступай через 3 недели. То через 3 недели можно уверено отвечать - я занят, изучаю безопасность WCF.

3. Налаживает работу с другими отделами
Тестировщик и отдел тестирования - это не неизбежное зло и убытки (а так некогда считалось).
А очень нужный отдел. Отдельный тестировщик не сможет доказать это кому-либо. А руководитель отдела тестирования, с собранной статистикой, и списком дел это запросто доказывает.
Результат - тестировщиков ждут и ценят.

4. Может и простую работу делать
Когда руководитель начинает помогать, сразу задача становится простой. Задача как-то сама собой делится на простые части с понятным результатом, выделяются важные вещи и ненужные.

5. Формирует отчёты (для этого надо отчитываться руководителю), собирает статистику, считает премию.
Те же мифические 75% (трудоёмкость тестирования ~ 75% трудоёмкости разработки) не с потолка взялись, а кто-то методично собирал статистику, выявлял зависимости, и отклонения от ожидаемых значений. Если были отклонения - выяснял причины и проводил беседы.

6. Согласует все планы тестирования.
7. Решает кому и когда повышать/понижать ЗП.
8. Планирует отпуска (контролирует чтобы не было такого, что в разгар проекта все разом ушли на 2-3 недели).
Наверно ещё что-то делает, секретное, о чем я не знаю.

К сожалению, не до конца понял ваш пример. Вы везде приводите все к UTF-8 и в UTF 8 работает. А в 1251 где-то не работает. Могу только прикинуть, что где-то кто-то все-время ожидает UTF-8, а ему прилетает что-то в 1251, вот отсюда и путаница.
MD5 должен быть один и тот же, иначе грош ему цена. А то, что 1251 и UTF-8 строки с одним и тем же русским словом будут разные - тут и к гадалке ходить не надо. А один и тотже хэш будет одинаково работать для одного и того же массива байтов.

Причем я не говорю, что тут не может быть багов. Именно багов реализации и использования. Я вовсе не являюсь сторонником паролей русскими буквами. Но к пробелу, все это, имхо, не имеет отношения.

Сравните:
PHP: d7473d0c3627deef383ae2d3aed819f7 (Проверка)
MySQL: 25baf6240e126086b3b23f55a8dea830 (Проверка)

До ":" написано кто вычисляет MD5, после ":" - значение MD5, а в скобках - строка, от которой берётся MD5.
Как видно значения разные d7473d0c3627deef383ae2d3aed819f7 != 25baf6240e126086b3b23f55a8dea830

И я не являюсь запретителем пробелов в паролях. Когда у службы поддержки NextMail выпытавал почему максимальная длина пароля = 16 символов и в нём нельзя использовать кирилицу + @ + \ + / + ... мне так ничего и не сказали. Но убеили, что пароли в явном виде в БД не хранятся и что всё как надо сделано. Тогда там был баг с символом @ - его можно было использовать в пароле. Я устанавливал пароль через Web-клиента, и символ @ попал в пароль как %40 и через веб-клиент вход осуществлялся, а через Mozilla Trunderbird вход не работал по причине - пароль неверный. Пришлось заменить все @ на A или a.

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