понедельник, 5 сентября 2011 г.

Отчёт о написании программки.

Задание: Написать программу, удаляющую лишние символы (префиксы) в таблице Access опредленном столбце. Имеются столбцы с номером и производитетем (запчастей), наименованием, наличием и пр. Существенны - производитель и номер.
Примеры: Если производитель Febi и номер начинается с "Fe", то префикс "Fe" нужно удалить. Если производитель Ajusa и номер начинается на "Aj", удалить "aj". В зависимости от формата номеров в конкретной базе префиксы могут немного различаться, поэтому иногдя я оговариваю, что номер должен начинаться на определенный префикс, иногда - нет.
Для доступа к таблице и её редактирования потребовался динамичный массив Recordset, а так же библиотекa DAO (с некоторых пор включает в себя и необходимую JET) для доступа к данным (таблице). Собственно, долго и подробно про технологии доступа к данным тут. Не скажу, что я всё поняла оттуда, но кое-что пригодилось. Итак, код в студию. Код тут, ибо в html в удобочитаемом виде не получилось.

понедельник, 29 августа 2011 г.

Продолжая VBA. Строковые функции

■ Asc() — эта функция позволяет вернуть числовой код для переданного символа. Например, Asc("D") вернет 68. Эту функцию удобно использовать для того, чтобы определить следующую или предыдущую букву. Обычно она используется вместе с функцией Chr(), которая производит обратную операцию — возвращает символ по переданному его числовому коду. Например, такой код в Excel позволяет написать в ячейки с A1 по A20 последовательно буквы русского алфавита от A до У:
Dim n, nCharCode As Integer
n = 1
nCharCode = Asc("А")
Do While n <= 20
ActiveWorkbook.ActiveSheet.Range("A" & n).Value = Chr(nCharCode)
n = n + 1
nCharCode = nCharCode + 1
Loop
Варианты этой функции — AscB() и AscW(). AscB() возвращает только первый байт числового кода для символа, а AscW() возвращает код для символа в кодировке Unicode.
■ Chr() — возвращает символ по его числовому коду. Помимо того, что используется паре с функцией Asc() (см. предыдущий пример), без нее не обойтись еще в одной ситуации: когда нужно вывести служебный символ. Например, нам нужно напечатать в Word значение "Газпром" (в кавычках). Кавычка — это служебный символ, и попытка использовать строку вида:
Selection.Text = ""Газпром""
приведет к синтаксической ошибке. А вот так все будет в порядке:
Selection.Text = Chr(34) & "Газпром" & Chr(34)
Есть варианты этой функции — ChrB() и ChrW(). Работают аналогично та-ким же вариантам для функции Asc().
■ InStr() и InStrRev() — одни из самых популярных функций. Позволяют обнаружить в теле строковой переменной последовательность символов и вернуть ее позицию. Если последовательность не обнаружена, то возвращается 0. Функция InStr() ищет с начала строки, а InStrRev() — с конца.
■ Left(), Right(), Mid() — позволяют взять указанное вами количество символов из существующей строковой переменной слева, справа или из середины соответственно.
■ Len() — возвращает число символов в строке (длину строки). Часто используется с циклами, операциями замены и т. п.
■ LCase() и UCase() — переводят строку в нижний и верхний регистры соответственно. Часто используются для подготовки значения к сравнению, когда регистр не важен (фамилии, названия фирм, городов и т. п.).
■ LSet() и RSet() — заполняют одну переменную символами другой без изменения ее длины (соответственно слева и справа). Лишние символы обрезаются, на место недостающих подставляются пробелы.
■ LTrim(), RTrim(), Trim() — убирают пробелы соответственно слева, справа или и слева, и справа.
■ Replace() — заменяет в строке одну последовательность символов на другую.
■ Space() и String() — возвращают строку из указанного вами количества пробелов или символов соответственно. Обычно используются для форматирования вывода совместно с функцией Len(). Еще одна похожая функция — Spc(), которая используется для форматирования вывода на консоль. Она размножает пробелы с учетом ширины командной строки.
■ StrComp() — сравнивает две строки.
■ StrConv() — преобразует строку (в Unicode и обратно, в верхний и ниж-ний регистры, первую букву слов заглавной и т. п.).
■ StrReverse() — "переворачивает" строку, разместив ее символы в обратном порядке.
■ Tab() — еще одна функция, которая используется для форматирования вывода на консоль. Размножает символы табуляции в том количестве, в котором вы укажете. Если никакое количество не указано, просто вставляет символ табуляции. Для вставки символа табуляции в строковое значе-ние можно также использовать константу vbTab.

понедельник, 15 августа 2011 г.

VBA next. Операторы и циклы.

Повторение - мать учения.
Операторы условного и безусловного перехода.
If... Then
Конструкция такая:
If Условие Then
Команды1
[ElseIf УсловиеN Then
КомандыN]
[Else
Команды2]
End If
При этом:
■ Условие — выражение, которое проверяется на истинность. Если оно истинно, то выполняются Команды1, если ложно — Команды2;
■ УсловияN — дополнительные условия, которые также можно проверить. В случае, если они выполняются (выражение УсловияN истинно), то выполняются КомандыN.

Select... Case
Select Case Выражение
Case Условие1
Команды1
[Case УсловиеN
КомандыN]
[Case Else
Команды2]
End Select

И оператор GoTo, безусловного перехода, метка.

Теперь о циклах. C предусловием:
For...Next:
For iCounter = 1 to 10
MsgBox "Счетчик: " & iCounter
Next

Если нужно пройтись по всем элементам:
For Each...Next:
For Each oWbk in Workbooks
MsgBox oWbk.Name
Next

С постусловием:
До тех пор, пока утвержденеи истинно:
Do While...Loop
Do While MyVar < 10 MyVar = MyVar + 1 MsgBox "MyVar = " & MyVar Loop До тех пор, пока утверждение ложно (не станет истинным): Do Until...Loop
Do Until MyVar >= 10
MyVar = MyVar + 1
MsgBox "MyVar = " & MyVar
Loop

While...Wend
While My Var < 10
MyVar = MyVar + 1
WScript.Echo "MyVar = " & MyVar
Wend

воскресенье, 14 августа 2011 г.

Отступление от Тамре. VBA

Мне тут понадобилось накалякать программку - ибо вручную делать это раз за разом нет больше сил, и заодно ознакомится с языком. Так вот - читаю учебник. Конспектирование правильного обзывания переменных:
Чаще всего используется так называемое венгерское согла-шение (в честь одного из программистов Microsoft, Charles Simonyi, венгра по национальности):
■ имя переменной должно начинаться с префикса, записанного строчными буквами. Префикс указывает, что именно будет храниться в этой пере- менной:
• str (или s) — String, символьное значение;
• fn (или f) — функция;
• sub — процедура;
• c (или все буквы имени заглавные) — константа;
• b — Boolean, логическое значение (True или False);
• d — дата;
• obj (или o) — ссылка на объект;
• n — числовое значение;
■ имена функций, методов и каждое слово в составном слове должно начи-наться с заглавной буквы:
MsgBox objMyDocument.Name
Sub CheckDateSub()

понедельник, 8 августа 2011 г.

Тестирование объектно-ориентированного ПО

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

Создание тестовых примеров (продолжение конспекта)

Тестовые случаи (категории тестов, прмиеняемые к схеме) желательно фиксировать. Вряд ли, не обладая феноменальной памятью, мы сможем воспроизвести все те издевательства над системой, после которых ее отправили на доработку. А повторная прогонка после доработки необходима - проверить всё ли исправлено и корректно ли работают те функции, которые и раньше отрабатывали правильно. Итак, нам нужны краткие описания тестов. В общем случае она выглядит так:
1. ID тестового прмиера (идентификатор, уникальный номер);
2. Элемент схемы тестов (номер в той схеме с требованиями);
3. Предыдущее состоние (состояние системы до теста);
4. Входные данные (что мы, собственно, делаем);
5. Ожидаемые результаты (что должна делать система);
6. Реальные результаты (что в итоге она делает).
Отмечу, что при тестировании сайта (собственный опыт) предыдущее состояние не важно, зато важна последовательностей действий перед входными данными (впрочем, вся последовательность может включатся в "входые данные").
Упрощенный формат документации имеет место быть, однако только при условии, что никому, кроме вас не придется ею пользоваться в полной мере (не привлекаются новые сотрудниик и аудиторы). Упрощать схему можно как удобно тестеру, некоторые примеры рассмотрены в книге, мне же приводить их лень - все равно если мы захотим упростить тесты "под себя" мы их упростим так, как удобно нам самим.
Для фиксации очень удобны электронные таблицы.

Конспект-3

Глава next. С одной стороны условия тестирования упрощаются (времени уже не в обрез), но документация все еще в плохом виде; с другой - усложняется - теперь подход должен быть шире. Используется схематический подход к фиксации требований. Потом даются категории тестов:
1. Нет данных (что случится, если не ввести данные; есть ли значение по умолчанию);
2. Повторный ввод данных (быстрая отправка одних и тех же данных - как поведет себя система - игнорирует повторный ввод, возьмет только последние данные, обработает как независимые данные, вернет сообщение об ошибке);
3. Верные данные (диапазон, граничные значения);
4. Неверные данные (выход за границы диапазона, неверный формат данных);
5. Сброс (кнопка "отмена" или выдернуть кабель: как отреагирует система);
6. Потери мощности (актуально для ПО техники);
7. Создание напряжений в системе;
8. Тестирование характеристик.
Далее все типы применяются к схеме с требованиями.

пятница, 5 августа 2011 г.

Конспект-2

Все еще касаясь тестирования в экстримальных условиях. Наброски этапов:
1. Базовый тест. Контакт с авторитетным лицом проекта (только этао самаяое морда лицо может прояснить технические моменты; короче юзать вместо документации)
2. Оценка правдивости результирующих данных (вариации со входными - при условии, что нет схемы расчета). Иметь ввиду, что резкие скачки результирующих данных могут быть следствием пороговых значений.
3. Инвентаризация (правильность типов данных), анализ пунктов меню (доступных для выбора). Удерживая одно из начальных значений постоянным, варьируем другое по всем возможным значениям.
4. После исправлений необходимо прогнать программу по тем же базовым тестам (преварительно зафиксированным). Наращиваемый подход в создании тестовых ситуаций (сначала - изолированный, потом - наращиваемый)
5. Граничные оценки. при тестрировании границ - три тестовых примера (само граничное значение, гр. знач-е +1, гран-е значение -1)
6. Ошибочные данные (ожидается, что програма отловит эти данные и вернет сообщение об ошибке)
7. Создание напряжений (поставить систему в невыносимые условия - урезать память, параллельно запустить несколько приложений, разъединение кабелей и т.п.) в системных ресурсах.

четверг, 4 августа 2011 г.

Конспект

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

Продолжение ознакомления с литературкой

Я не могу читать Савина дальше. Это какой-то писец - возможно, за примерами я полезу, но читать общие положения невозможно. Плохой перевод - и больше у меня слов нет. Есть удачные мыли и аналогии, но в целом это кошмарно. Взялась за Тамре ("Введение в тестирование программного обеспечения") - намного лучше. Смотрите, какая прелесть: "Автору часто приходилось сдерживаться, чтобы не высказать менеджерам проекта свое негодование: "Требования [техническое задание, необходимое тестировщику как отправная точка] совсем никуда не годятся и мы не можем продуктивно проводить тестирование до тех пор, пока вы не проясните ситуацию". В действительности эта фараза обычно содержит непечатные идиоматические выражения и произносится под чьи-то вздохи...". Переводчик тоже не без чувства юмора. В общем, пока мне больше нравится эта книга. И не только наличием юмора на первых же страницах - она логична и целостна, чего не скажешь о Савине. Посмотрим, что дальше.

вторник, 2 августа 2011 г.

Еще полезные ссылки

http://www.quizful.net/interview/qa - вопросы по собеседованию
http://www.quizful.net/test - тесты проверки знаний

Ознакомление с литературой по сабжу

Начала читать Савина "Тестирование дот.ком...". Впечатления пока двоякие - вроде автор пытается писать неакадемическим языком, но получается слишком топорно. Такое впечатление, что читаешь плохой перевод. Даже академические тексты, правильно и грамотно написаные, читаются легче. Ну, к примеру:

Рассмотрим, что объединяет следующие ситуации.
1. Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии.
2. Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.
3. Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
1. Ожидаемый результат -— девушка умеет готовить.
Фактический результат — утро без завтрака.
2. Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии.
3. Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.

Вообще, это о чем?! Что есть баг, и что им не является, автор уже дал вполне понятное описание, так нет же, он решил еще пожевать резины и приплел сюда ситуации с параллелями, но неясно как относящиеся к т.н. багам. Такое впечатление, что автор хотел что-то сказать о возможной скопенсированности багов, но как-то все скомкал и просто свел сложную конструкцию к отдельным случаям. И таких фраз "их есть у меня". Право - плохой перевод, да и только. Или взять термин "спецификация". Цитирую:
Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Конец цитаты.
А я всегда думала, что тестировщики обычно отталкиваются от технического задания, по которому, собственно, пишется программа, и начинают ее тестить чем раньше, тем лучше.
Ладно, добавлю и пару ополовников мёда - автор честно пытается говорить просто о сложном. Почитаем дальше - увидим что там не только с терминологией, но и с частными случаями (проблемы и их решения).

четверг, 28 июля 2011 г.

Inception

Эту идею - сбрасывать все полезное по теме в блог - я честно сплагиатила у знакомой. Т.к. я всерьез (пока) решила заняться освоением тестирования и появилась куча литературы, которая уже не влазит в избранное, появилась необходимость некой систематизации и своеобразных "библиографических карточек". Этот блог будет выполнять функцию упорядочивания полученых знаний. А их пока реально - ноль. Итак - первые книги (спасибо за них Владимиру Кривенко):
1) "Быстрое тестирование", Роберт Калбертсон, Крис Браун, Гэри Кобб;
2) “Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах”, Роман Савин;
3) “Введение в тестирование программного обеспечения”, Луиза Тамре;
4) “Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование”, Рекс Блэк;
5) "Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем", Борис Бейзер.
Ну что ж, как сказал великий Гагарин: "Поехали!".
P.S. Для затравки понятная (не ленится изучать!) схемка о качестве ПО c сайта http://www.protesting.ru: