понедельник, 6 апреля 2015 г.

Несколько рекомендаций по разработке стратегии тестирования

1. Тестируйте в первую очередь требования с наивысшим приоритетом.
Предположим, что в вашем распоряжении имеется документ определения требований, в котором требованиям присвоены приоритеты. Выберите те из них, которые представляют для   заказчика наибольшую важность, либо которые причинят за­казчику наибольшие неприятности  в случае выхода программного продукта из строя. Если запланировано тестирование всех требований, и ресурсы это позво­ляют, естественно, придется тщательно проверить выполнение всех требований. 
В случае нехватки ресурсов, перед отправкой продукта заказчику необходимо тщательно протестировать требования с наивысшими приоритетами. Возможно, стоит получить согласие заказчика на то, что требования, которые проверены частично или не проверены вообще, не будут поддерживаться вплоть до следую­щей версии продукта. 

2. Тестируйте новые функциональные возможности и программный код, кото­рый изменялся с целью исправления или совершенствования старых функ­циональных средств. Эвристическое правило гласит: если программный код подвергался исправлениям, его необходимо протестировать. В начальной версии программного продукта новым является все. Однако если версия является оче­редным обновлением или эксплуатационной версией, особое внимание следует уделить новому коду. Имейте ввиду, что любые изменения, внесенные в про­граммный код, могут исказить даже те части программы, которые непосредственно "не затрагиваются" изменениями. В этом случае лучше всего как можно чаще выполнять регрессионные тесты для всей функциональности программы, какими бы ни были изменения в коде. 


3. Используйте разбиение на эквивалентные классы и анализ граничных значе­ний для снижения трудозатрат на тестирование. Эти методы могут использоваться для выявления максимального тестового покрытия за счет определения поднабора входных значений во время тестирования компонентов ввода/вывода. 

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

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



Комментариев нет:

Отправить комментарий