Техническая версия

1. НАПИСАНИЕ КОДА

Один программист написал: parent_ value = 1. Другой програм­мист написал: child_value = parent_ valu + 3.

2. ИНТЕГРАЦИЯ КОДА

а. Пытаемся два куска кода соединить в один:

parent_ value = 1,

child_value = parent_ valu + 3.

б. Код не компилируется (компайлер выдает ошибку о неоп­
ределенной переменной), так как второй программист на­
писал parent valu вместо parent value.

в. Код второго программиста фиксируется:

child_value —parent_value + 3.

г. Пытаемся два куска кода соединить в один:

parent_value = 1,

child_value = parent_value + 3.

д. Код компилируется, но первый программист выполняет
юнит-тест, по которому parent_yalue должно быть равно 7.

е. Код первого программиста фиксируется:
parent_value - 1.

ж. Пытаемся два куска кода соединить в один:

parent_value = 7,

child_value = parent_value + 3.

з. Вроде все в порядке, передаем тестировщикам — пусть
они тра... маются.

3. РЕМОНТ БАГОВ

Согласно спецификации должно быть:

child_value - parent_yalue x 3.

Тестировщик рапортует баг, и на основании этого бага програм- мист меняет код.

Тестирование Дот Ком. Часть 1

Лирическая версия

1. НАПИСАНИЕ КОДА

О написании кода мы уже говорили. Один момент:

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

2. ИНТЕГРАЦИЯ КОДА
Вариант 1. Неблагодарный

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

Пример

Собрали четырех отличных художников, причем каждый должен выпол­нить заказ на куске прозрачной пленки 50x50 см:

• задание первому: нарисовать удрученного, стоящего на коленях молодого человека;

• задание второму: нарисовать милостиво склонившегося старика;

• задание третьему: нарисовать фон, вызывающий сострадание;

• задание четвертому: нарисовать группу печальных людей.

"В общем, парни, генеральная идея... эта... типа как у этого... О! У Рем-браНа: возвращение загулявшего сына".

Неудивительно, что мы прочувствуем всю боль релиз-инженеров, ко­гда соединим четыре рисунка вместе и увидим

• удрученного великана, стоящего на коленях над

• стариком,

• гладящим промокшую болонку

• в окружении заспанных курсантов-суворовцев.

Остается только редактировать картинки каждого из художников и гру­стить, что их не совмещали по мере написания, используя...

Вариант 2. Благодарный

Чтобы избежать проблем, когда в один момент происходит мас­сированная интеграция кодов разных авторов, как в Варианте 1, программисты производят интеграцию постоянно по мере напи-

Цикл разработки ПО 99

сания нового кода (т.е. стадия 1 и стадия 2 цикла разработки кода сливаются в одну стадию), что дает возможность выявить несты­ковки между кодами разных авторов на раннем этапе.

3. РЕМОНТ БАГОВ...

происходит во время стадии "Тестирование и ремонт багов", по­сле того как код для данного релиза был заморожен и програм­мисты работают над кодом для нового релиза.

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

Пример

Представьте следующую ситуацию:

1. Программист закончил работу над функциональностью А;

2. Тестировщик проверил, что функциональность А работает, и дал добро на релиз;

3. За час до релиза программист вносит маленькое изменение в код, которое в теории ничего не ломает...

а на практике приводит к тому, что функциональность В, связанная с А, абсолютно перестает работать, т.е. получилось так, что тестировщик попросту потерял время (а значит, и деньги компании), тестируя не финальную версию продукта.

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

• код заморожен (обычно релиз-инженеры посылают соот­ветствующий е-мейл);

• версия продукта на внутреннем сайте, на котором вы будете производить тестирование, является именно той версией, которую вам нужно протестировать.

Пример

Допустим, что на интранете у нас есть два внутренних тестировочных веб-сайта, недоступных для пользователей:

• www.everest.testshop.rs и

• www.elbrus.testshop.rs

Допустим также, что сайт

• www.everest.testshop.rs(по-простомуназываемый "Эверест") является версией 1.0 и содержит функциональность А версии 1.0, а

• www.elbrus.testshop.rs(по-простомуназываемый "Эльбрус") является версией 2.0 и содержит функциональность А версии 2.0.

Тестирование Дот Ком. Часть 1

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

Допустим, тестировщик собирается проверить функциональность А версии 2.0, но ошибочно использует для тестирования Эверест (с вер­сией 1.0), вследствие чего он не только впустую тратит время, но и рискует дать добро на релиз непротестированного кода функцио­нальности А версии 2.0.

Подобные ошибки возникают, как правило, по небрежности или незнанию тестировщика и из-за "нелогичных" названий внутрен­них веб-сайтов.

Пути предотвращения ситуации, когда тестировщик тестирует не ту версию ПО:

1. Узнайте у релиз-инженера, как определить версию кода, и используйте сие знание перед началом исполнения тести­рования;

2. Посоветуйте, чтобы внутренние веб-сайты имели логич­ные имена. Например, версия кода, переданного пользова­телю, всегда должна быть на внутреннем сайте по адресу www.old.testshop.rs, а версия для следующего релиза — на www.main.testshop.rs;

3. Попросите релиз-инженеров, чтобы те создали на интра-нете динамически обновляемую страничку с информа­цией о

• версии и

• подверсии, т.е. билде (об этом позже),

каждого внутреннего тестировочного веб-сайта.

В завершение кодирования поговорим еще о паре вещей.

Хотя и спеки, а иногда даже и сами идеи для спеков — ребятки не без греха, большинство багов зачинается именно при написа­нии кода. При кодировании появляется присущий только этой стадии и одновременно самый простой в нахождении вид бага — синтаксический баг (syntax bug).

Прелесть синтаксических багов заключается в том, что они, явля­ясь ошибками в языке программирования, находятся компай-лером (например, в случае с C++) автоматически. Последний выдает на экран сообщение об ошибке и принципиально не соз-

Цикл разработки ПО

дает исполняемый файл, пока проблема не будет зафиксирована (в скриптовых языках, таких, как Python, исполняемым файлом является сам файл с кодом и синтаксические баги находит интер­претатор языка).

Пример

Вот первая программка любого изучающего C++: 1. #include <iostream.h> 2.

3. voidmain()

4. {

5. cout<< "Hello, World!<< endl;

6. }

Текст этой программки находится в файле syntax_error.cpp. По­пробуем ее скомпилировать:

~> C++ syntax error, cpp

syntax_error.cpp:5: unterminated string or character constant

syntaxerror.cpp: 5: possible real start of unterminated constant

Последние две строчки — это текст об ошибке, выданный ком-пайлером из-за того, что мы не закрыли кавычки в строке 5 после World! Никакого исполняемого файла создано не было. Если мы исправим эту ошибку, то файл без проблем скомпилируется.

Тестировщики обязаны устройству Вселенной за то, что есть ло­гические баги (logical bugs). Эти баги, как следует из их назва­ния, — это ошибки в логике кода, т.е. код компилируется без син­таксических ошибок, но фактический результат исполнения этого кода не соответствует ожидаемому результату.

Пример

Спецификация:

"7.2. Пользователь должен ввести два целых числа от 1 до 12, после чего программа выведет на экран их среднее арифмети­ческое".

Код:

1. #include <iostream.h> 2.

3. voidmain()

4. {

5. int first number = 0;

6. int secodndjnumber = 0;

7. float average = 0.0;

Тестирование Дот Ком. Часть 1

8.

9. //get first number

10. cout«"Enter first number:";

11. cin» first_n umber; 12.

13.

14. //get second number

15. cout«"Enter second number:";

16. cin» second number; 17.

18. //calculate average

19. average = firstjiumber+second_number/2.0; 20.

21. //output result

22. cout«"Average = "«average «endl; 23.

24. }

Тестирование:

Enter first number: 9 Enter second number: 2 Average =10

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

5,5 не равно 10, соответственно у нас есть логический баг.

Проблема, кстати, в строке 19, которая должна была звучать так (были пропущены скобки):

19. average = (first_number+second_number)/2.0.

Кстати, в приведенном пункте спека есть баг, так как непонятно, какое максимально допустимое целое число: 11 или 12? Программист, уви­дев этот баг, должен был сделать уточнение у продюсера и обязать то­го исправить спек. Если максимальное число = 12, то точная формули­ровка должна быть следующей: "7.2. Пользователь должен ввести два целых числа от 1 до 12 включительно, после чего программа выведет на экран их среднее арифметическое".

Кстати, программист заложил в коде еще один логический баг, так как согласно спеку код должен принять только действительный ввод, кото­рым являются целые числа 1—11 (или 1 — 12).

Кстати, спек имеет еще один баг: не сказано, как должна отреагиро­вать программа, если пользователь введет недействительный ввод, например 0, 13, "А", "#" или пустое место...

Цикл разработки ПО

Две последние вещи в разговоре о стадии кодирования. Первая вещь

Как мы помним, на этой стадии тестировщики пишут тест-кейсы. Так вот тест-комплекты необходимо, как и спеки, хранить в CVS и публиковать линки к ним на интранете для предоставления возможности свободного ознакомления с ними любому заинтере­сованному лицу внутри компании. Главные преимущества хране­ния тест-кейсов в CVS:

• отсутствие возможности случайного удаления файла;

• присутствие возможности возвратиться к предыдущим вер­сиям файла;

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

Вторая вещь

Хорошая идея для компании в целом и для интересов самого тестировщика — это провести рассмотрение тест-кейсов (Test-case Review), когда за несколько дней до начала тестирования со­бираются

• продюсер, написавший спек,

• программист, написавший по спеку код и

• тестировщик, написавший по спеку тест-кейсы.

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

Полезность рассмотрения тест-кейсов заключается в том, что во многих случаях продюсеры и программисты дают новые идеи для тестирования и/или корректируют допущенные не­точности.

---

Дата добавления: 2015-12-07