dlg99

<div class="y6">
     <span id=":pi">text1</span>
     ‎<span class="y2"> - text2</span>
</div>

Как получить доступ к любому из span элементов по тексту text1 или text2?

что-нибудь вроде
//div[@class='y6']/span[contains(text(), 'text2')]
или
//div[@class='y6']/span[ends-with(text(), 'text2')]

Я проще делаю, ко множеству значений добавляю параметр NA и создаю правило типа
IF Border="No Line" then Dashed="NA" and BorderWidth="NA" итд

я тоже ;)
только нужно еще в обратную сторону ограничить - если любое из Dashed/... =="NA", то остальные могут быть только "NA" и Border может быть только "no line".

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.

в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.

к сожалению, "спокойно" - нельзя. Если есть 9 параметров, у каждого из которых от 3 до 10 значений, то описание зависимых параметров становится нетривиальной задачей.

заметьте, я не говорил, что можно использовать не думая. ;)

иногда проще разбить на части. иногда удобнее описать модель/правила в коде - меньше ручной работы при изменении бизнес-логики.
все Вами описанное выливается в 1 строчку кода, которую будет проще понять, чем 2 независимых генератора тестов (из моего опыта, YMMV).

посмотрите на http://sourceforge.n...s/example2.2.py (из http://engineering.m.../allpairs.aspx) как на пример задания фильтра просто в коде.
в pict можно задать sub-models в дополнение к constraints.
все можно сделать 'спокойно' - сосредоточившись на том, *какие* тесты генерировать, а не на том *как* их генерировать.

Пары имеет смысл составлять как раз для независимых параметров. Когда параметры зависимые, мы получаем вырожденные пары, ухудшающие покрытие.

в нормальных тулах все отсекается при генерации, а не после.
в том же pict можно задать constraints.
можно спокойно использовать и с зависимыми параметрами.

Bj Rollison упоминал, что в Microsoft проводили исследование на эту тему лет 5 назад, несколько лет, разные группы, разные подходы.
насколько я помню, стохастические методы в какой-то момент почти достигают того же покрытия (code coverage/tets coverage/bugs found), что и другие (см ниже), но существенно позже.
как результат эти методы применяются редко, предпочтение отдается автоматизации (комбинаторными методами + модели) с регулярным code coverage analysis и code reviews + static testing tools.
Была статья на этот счет, с графиками и прочим; название не помню. Можете или спросить Bj (www.testingmentor.com) или посмотрите в книге "How we test software at Microsoft", вроде бы там это тоже встречалось.

Исключением является security testing, где часто используют fuzzing и, пожалуй, machine learning.
С первым я серьезно не сталкивался, во втором проблемой является не "создать много случайных тестов", а "выбрать случайный минимальный statistically significant набор тестов"

Модели, кстати, можно строить при помощи разных тулов, например SpecExplorer.

по личным ощущениям и отзывам тех, кто с ними плотно общался, Канер и Бах:
- ориентированы на людей с нетехническим образованием/складом ума
- работают в режиме консалтинга, пришел-ушел. поэтому агитируют за самые простые для понимания менеджментом (легче продать/демонстрировать) подходы.
Майерс - 'технарь', оттого и расхождения во мнениях.

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