Как организовать скрытый ввод пароля в vbscript

Следующий код запрашивает у пользователя ввод пароля. Вводимые символы при этом не отображаются. После ввода пароля скрипт выводить его на экран.

Set objPwd = WScript.CreateObject(«ScriptPW.Password»)
strUserPassword = objPwd.GetPassword()
WScript.Echo strUserPassword

Примечание: Данный код работает только при запуске через cscript.exe.

Как сгенерировать GUID в vbscript

Следущий код генерирует и выводит GUID:

Set TypeLib = CreateObject(«Scriptlet.TypeLib»)
Wscript.Echo TypeLib.Guid

Быстрая сортировка на vbscript

Option Explicit
Dim i, arrSample (9)

arrSample (0) = 9.9
arrSample (1) = 8.7
arrSample (2) = 7
arrSample (3) = 6
arrSample (4) = 5.8946456
arrSample (5) = 4
arrSample (6) = 3
arrSample (7) = 2.4
arrSample (8) = 1

qsort arrSample, 0, 8

For i = 0 To 8
WScript.Echo arrSample(i)
Next

Sub qsort (arr, l, r)
Dim i, j, x, y
    i = l
    j = r
    x = arr((l + r) \ 2)
Do
        While arr(i) < x
            i = i + 1
Wend
        While x < arr(j)
            j = j - 1
Wend
        If i <= j Then
            If arr(i) <> arr(j) Then
                y = arr(i)
                arr(i) = arr(j)
                arr(j) = y
End If
            i = i + 1
            j = j - 1
End If
    Loop Until i > j
If l < j Then qsort arr, l, j
If i < r Then qsort arr, i, r
End Sub

Синтаксис описания дефектов

Наткнулся в документе Administering & Using StarTeam 2008 (Borland) на интересное предложение по описанию дефектов. Предлагается использовать такой набор сокращений:

Shorthand	Description
1, 2, 3,…	Номер шага.
LClick	Левый клик мышкой.
RClick	Правый клик мышкой.
DClick	Двойной клик мышкой.
[ ]	Кнопка клавиатуры. For example: [F1] for Help or [F5] for Refresh.
< >	Кнопка диалогового окна. For example: Press <OK> or <Cancel>.
>	Разделитель пунктов меню. For example: Select File > Open or Topic > Tools > Reports.
//	Комментарий, не являющийся шагом выполнения сценария. For example: 3) LClick the field. // At this point my machine started to smoke.
EXP	Ожидаемый результат. For example: EXP: The focus moves to the next field.
ACT	Полученный результат. For example: ACT: The application crashes.

Описанный с помощью этих сокращений дефект, может выглядеть примерно так (пример взят из того же документа):

1. RClick the column headers in the upper pane.
2. Select Show Fields.
3. LClick Show Advanced Fields check box.
// The check box is activated.
4. LClick Show Advanced Fields check box.
// The check box is deactivated.
5. EXP: The standard fields appear in the Available Fields list box. 6. ACT: No fields appear in the Available Fields list box.

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

Чему учиться тестировщику

Решил поделиться некоторыми соображениями на тему обучения и развития тестировщиков. Все что я скажу это мое IMHO, так что относится к этому лучше критически.

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

1. Автоматизация тестирования с использованием специализированных средств.

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

2. Инженерное направление.

Т.е. развитие в сторону системного администратора. Тестировщику довольно часто не хватает серьезных знаний по работе с какими-то технологиями (сужу по себе). В сложных проектах вводится даже отдельная должность – DBA (Database Administrator). Человек, который может создать и поддерживать необходимый стенд нужен не только в тестировании, но и в разработке.

3. Развитие по какому-то отдельному виду тестирования.

Например, нагрузочное тестирование (в т.ч. производительности). Настоящих специалистов в этой области мало, и они востребованы. На мой взгляд, интересное направление. А, например, специалисты в области безопасности вообще по-моему avis rara ;)

4. Руководство и управление.

Это развитие в сторону менеджмента тестирование. Разработка планов, управление рисками и т.д. и т.п. Т.е. тут надо будет изучать различные методологии, выбирать лучшее и адаптировать под конкретные проекты.

5. Qaulity Assurance

Иногда тестирование называют QA, это неправильно. QA – деятельность, направленная на контроль качества процессов создания ПО (а не самого ПО, как тестирование). Тоже интересное, но мало мне знакомое, направление :)

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

Откуда взять информацию тестировщикам

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

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

На рисунке 1 приведена схема, на которой указаны основные, на мой взгляд, источники информации для тестировщика.

Рисунок 1 Источники информации

Информацию можно получать на разных этапах разработки: до реализации новой «фичи» или требования, и после того как изменения были внесены в код. На разных этапах источники разные. Рассмотрим их подробнее.

Источники, актуальные до внесения изменений в код.

Спецификации. Предположим, что спецификации у нас отсутствуют или не обновляются  Данный источник здесь рассматривать не будем, тут в общем все просто.

Менеджер проекта.

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

User story/use-case. Т.к. менеджер формулирует задачу для разработчика, он может привести пример использования новой или измененной функции. Это бывает полезно при разработке или обновлении test-case’ов. Правда тут многое зависит от менеджера, как правило, менеджеры люди занятые, и доставать лишний раз их расспросами не стоит 

Аналогичные приложения.

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

Стандарты. В качестве стандартов можно использовать продукты ведущих разработчиков ПО. Особенно полезно это бывает при тестировании GUI (например, можно ориентировать на MS Office для Windows-приложений). В споре с разработчиками тот факт, что MS делает совсем по-другому будет хорошим аргументом.

Знание предметной области и понимание реализуемых use-case’ов

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

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

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

Разработчик, архитектор

Т.е. исполнитель, тот кто непосредственно вносил изменения в код и кто находится в курсе реализации.

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

«Слабые» места программы. Иногда бывает так, что у разработчика возникли трудности при реализации той или иной функции. Если он поделится этой информацией с тестировщиком, то последний сможет акцентировать внимание на «проблемной» функции и протестировать ее более тщательно.

Само приложение

Самый «грустный» источник информации  В том смысле, что когда отсутствуют всякая документация и никто не хочет делиться информацией ничего не остается, как заняться исследованием тестируемого приложения.

Release notes

Здесь под Release notes я понимаю комментарии к каждой версии, которая приходит на тестирования. Может название не очень удачное, но так мы называем комментарии к билду у себя в компании. Это очень ценная информация, которая помогает экономить время тестировщиком и более эффективно выполнять тестирование.

Release notes помогает определить порядок тестирования. Логично в первую очередь протестировать те части программы, которые изменились в последней версии, т.к. именно в них наибольшая вероятность возникновения ошибок.

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

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

Примерный шаблон Release notes приведен ниже. Он не случайно такой простой. Чтобы добиться от разработчиков регулярного его заполнения, он должен быть максимально кратким и простым. Иначе они просто не захотят с ним разбираться. Также важно указывать к какой версии/билду относятся данные Release notes, без этого информация может оказаться менее полезной.

Шаблон Release notes

Версия сборки (build’а)

• Добавлено:
• Изменено/исправлено:
• Удалено:

В каждом пункте указать какие компоненты либо функции либо требования были изменены

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

---

PS.
Статья была опубликована на IT4business.ru. В комментариях было справедливо замечено что «В статье не упомянут самый главный и единственный заслуживающий доверия источник информации — ЗАКАЗЧИК либо ПОТРЕБИТЕЛЬ.» :) Комментарий оставил Алексей Баранцев.