 |
Различные подходы к тестированию (черный ящик, белый ящик)
|
|
|
|
Долгое время основным способом тестирования было тестирование методом "черного ящика" - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия [3]. При этом как именно работает программа считается несущественным. Отметим, что даже при таком подходе необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать результаты.
Этот подход до сих пор является самым распространенным в повседневной практике, но у него есть целый ряд недостатков. Во-первых, таким способом невозможно найти взаимоуничтожающихся ошибок, во-вторых, некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.
В связи с этим появились методы тестирования, которые изучают не только внешнее поведение программы, но и ее внутреннее устройство (исходные тексты). Такие методики обобщенно называют тестированием "белого ящика". Назовем некоторых представителей этого класса методик: чтение программ, формальные просмотры программ, инспекции и т.п.). Основной трудностью подобных методов является сложность отслеживания вычислений времени выполнения.
Внимательное изучение этих методов тестирования показывает, что они дополняют друг друга, то есть различные методы находят разные ошибки. Поэтому наиболее эффективные процессы разработки ПО используют некоторую комбинацию методик "черного ящика" и "белого ящика".
В следующей таблице, заимствованной из книги [8], приводятся показатели минимальной, средней и максимальной эффективности различных методов тестирования. Обратите особое внимание на последнюю строчку, описывающую общую эффективность процесса, использующего все эти методики:
|
|
|
Таблица 4.1
| Название методики | Минимальная эффективность | Средняя эффективность | Максимальная эффективность |
| Персональные просмотры проектных документов | 15% | 35% | 70% |
| Неформальные групповые просмотры | 30% | 40% | 60% |
| Формальные просмотры проектных документов | 35% | 55% | 75% |
| Формальные инспекции кода | 30% | 60% | 70% |
| Моделирование и прототипирование | 35% | 65% | 80% |
| Проверка за партой | 20% | 40% | 60% |
| Тестирование модулей | 10% | 25% | 50% |
| Функциональное тестирование | 20% | 35% | 55% |
| Комплексное тестирование | 25% | 45% | 60% |
| Тестирование в реальных условиях | 35% | 50% | 65% |
| Применение всех перечисленных методик тестирования | 93% | 99% | 99% |
Итак, очевидно, что тестирование максимально эффективно в тех случаях, когда программа проверяется не только путем запуска, но и путем чтения, статических проверок и т.п. Поэтому классическое определение Майерса, приведенное выше, оказывается слишком узким и не охватывающим всех аспектов современного тестирования. В связи с этим мы будем пользоваться другим определением тестирования:
Определение.
Тестирование - это любая деятельность, направленная на обнаружение ошибок в программном продукте.
4.2. Смежные вопросы тестирования
Экономическая сторона тестирования. Тестирование само по себе является затратной деятельностью, отнимающей у нас время и деньги. Поэтому в большинстве случаев разработчики программного обеспечения (ПО) заранее формулируют какой-либо критерий качества создаваемых программ (определяют так называемую планку качества), добиваются выполнения этого критерия и после этого прекращают тестирование и выпускают продукт на рынок. Такая концепция получила название Good Enough Quality (достаточно хорошое ПО), в противовес более очевидной концепции Best Possible Quality (максимально качественное ПО).
К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality - If Time Permits (качество - если будет время). Конечно, выпуск плохо протестированного продукта из-за недостатка времени - это плохая практика. Практика показывает, что пользователи склонны со временем забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь.
|
|
|
На самом деле, Good Enough Quality - это просто поиск разумного компромисса между затратами на тестирование, длительностью разработки продукта и его качеством.
Психологические аспекты тестирования. Тестирование принципиально отличается от программирования по своим психологическим характеристикам [26]. Дело в том, что программирование носит конструктивистский характер, а тестирование ПО - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично - как к своим детям.
Все это не значит, что тестирование "хуже", чем программирование, или что в процессе тестирования нет места творчеству - просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программирования. Следовательно, программист не должен тестировать свои собственные программы; для этого необходим другой человек. Более того, программист не должен тестировать даже чужие программы! Дело в том, что программист потратит какое-то время просто на "раскачку", перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Понятно, что переключение с одного образа мышления на другой отнимет существенно больше времени - возможно даже день или два.
Именно поэтому с точки зрения разработчика e-mail значительно выгоднее телефона (есть возможность ответить на вопросы после достижения некоторой логической точки в работе). Более того, программистам рекомендуют проверять почту не постоянно, а два-три раза в день - чтобы увеличить среднее время работы без отвлечений.
|
|
|
Из всего вышесказанного следует очевидный вывод о том, что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодействовать друг с другом для достижения приемлемого качества окончательного продукта.
заключение
Конец 20-го и начало 21-го века характеризуются началом перехода от постиндустриального общества к информационному. Процесс, обеспечивающий переход от индустриального общества к информационному – это процесс создания, развития и всеобщего применения информационных средств и технологий, обеспечивающих достижение и поддержание уровня информированности всех членов общества, необходимого и достаточного для кардинального улучшения качества труда и условий жизни в обществе. При этом информация становится важнейшим стратегическим ресурсом общества и занимает ключевое место в экономике, образовании и культуре. Неизбежность информатизации общества обусловлена резким восстановлением роли и значения информации. Информационное общество характеризуется высокоразвитой информационной сферой, которая включает деятельность человека по созданию, переработке, хранению, передаче и накоплению информации.
Для решения задач обеспечения качества, надёжности, безопасности и экономической эффективности ИС информация о работоспособности оборудования и оперативного персонала имеет первостепенное значение.
Одной из современных тенденций обеспечения высокого уровня надёжности, безопасности и эффективности ИС является их анализ по двум направлениям: первое – «информация – информационная технология – информационный ресурс» и второе – «модель – алгоритм – программа».
Современные информационные системы отличатся большой разветвлённостью подсистем, разнотипностью выполняемых задач, сложностью алгоритмов управления.
Прогнозирование работоспособности, эффективности и надёжности ИС представляет собой комплексную задачу, решение которой позволяет снизить до минимума вероятность возникновения отказов в процессе эксплуатации. И наиболее важным, по мнению авторов, является установление количественных закономерностей разрабатываемого процесса на этапе проектирования
|
|
|
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Автоматизированная система управления предприятием. Система нормативов на ресурсы. ГОСТ 4.071.033-80, 1980.
2. Баронов В. В. и др. Информационные технологии и управление предприятием. – М.: Компания АйТи, 2004. – 328 с.
3. Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. – СПб.: Питер, 2004 г. 318 с.
4. Беклешов В. К. Технико-экономическое обоснование дипломных проектов. – М.: Высшая школа, 1991. – 176 с.
5. Благодатских В.А. и др. Экономика, разработка и использование программного обеспечения ЭВМ. – М.: Финансы и статистика, 1995. – 288 с.
6. Готра З. Ю., Николаев И.М. Контроль качества и надёжность микросхем: Учебник для техникумов. М.: Радио и связь, 1989. 168 с.
7. Деверадж С., Кохли Р. Окупаемость ИТ: Измерение отдачи от инвестиций в информационные технологии. – М.: ЗАО «Новый издательский дом», 2005. – 192 с.
8. Иыуду К. А. Надёжность, контроль и диагностика вычислительных машин и систем. М., 1989
9. Кадушин А., Михайлова Н. Методика оценки экономической эффективности ИТ. − М:., Тезисы доклада на III-й Всероссийской конференции "Стандарты в проектах современных систем", 23-24 апреля 2003 г.
10. Ковалёв С. П. Формальный подход к разработке программных систем: Учеб. пособие/ Новосиб. Гос. ун-т. Новосибирск, 2004. 180 с.
11. Корольков М. Д., Недосекин А.О., Сегеда А. В. Как правильно выбрать корпоративную информационную систему // Топ-Менеджер, 2003. № 12.
12. Костина Г., Михайлов А., Пискунова Н. Маркетинговые исследования в области информационных услуг для малого и среднего бизнеса России. // М. - "Маркетинг". – 1997. № 2. - с. 39 - 42.
13. Крылов Э. И. Анализ эффективности инвестиционной и инновационной деятельности предприятий. – М.: Финансы и статистика, 2003. – 608 с.
14. Липаев В. В. Тестирование программ – Москва: Радио и связь, 1986
15. Липаев В. В. Управление разработкой программных средств: Методы, стандарты, технология. – М.: Финансы и статистика, 1993. – 160 с.
16. Липаев В. В., Потапов А.И. Оценка затрат на разработку программных средств. – М.: Финансы и статистика, 1988. – 224 с.
17. Майерс Г. Искусство тестирования программ. – М.: Финансы и статистика. – 1982
18. Макгрегор Д., Сайкс Д. "Тестирование объектно-ориентированного программного обеспечения", Киев, ДиаСофт, 2002.
19. Нортон Д., Каплан Р.. Система сбалансированных показателей. От стратегии к действию. – М., Олимп-Бизнес, Библиотека IBS, 2003.
|
|
|
20. Острейковский В.А. «Теория надёжности». Учебник для ВУЗов. – Москва: Высшая школа, 2003 г. 463 с.
21. С. Канер, Дж. Фолк, Е. Кек Нгуен "Тестирование программного обеспечения", Киев, ДиаСофт, 2000. 416 с.
22. Скрипкин К. Г. Экономическая информатика: Введение в экономический анализ информационных систем: Учебник. М.: ИНФРА – М, 2005. – 958 с. – (Учебники экономического факультета МГУ).
23. Типовые нормы времени на программирование задач для ЭВМ. Госкомитет по труду и социальным вопросам. М., 1987.
24. Трейси Мейор. Как оценить преимущества ИТ // Computerworld. 2001. № 1.
25. Хадыкин А. М. Показатели надёжности. Омск, Издательство ОмГТУ, 2004 г.
26. Черняховский «Поиск устойчивых ошибок в программах», Москва, 1989 г.
27. Шнейдерман Б. "Психология программирования", М.: Радио и связь, 1984. 304 с.
28. McCarthy "Dynamics of Software Development", Microsoft Press, 1995. 184 p.
29. S. Maguire "Writing Solid Code", Microsoft Press, 1993. 256 p.
30. S. McConnell "Code Complete", Microsoft Press, 1993. 858 p.
ПРИЛОЖЕНИя
Таблица 1.1
Затраты времени при выполнении работ
на стадии « Техническое задание »
| Норма | Комплекс задач (задачи) подсистем | Степень новизны | |||
| А | Б | В | Г | ||
| Перспективное планирование развития и размещения отрасли, управление проектированием и капитальным строительством, технико-экономическое планирование, оперативное управление, управление ценообразованием | |||||
| Управление материально-техническим снабжением, управление сбытом продукции, управление комплектацией, управление экспортными и импортными поставками | |||||
| Бухгалтерский учет, управление финансовой деятельностью | |||||
| Управление организацией труда и заработной платой, управление кадрами, нормы и нормативы, управление охраной труда | |||||
| Управление качеством продукции, управление технологическими процессами, управление стандартизацией, управление технической подготовкой производства | |||||
| Управление транспортными перевозками, управление техническим обслуживанием производства, управление вспомогательными службами и энергоснабжением | |||||
| Управление НИР и ОКР | |||||
| Управление научно-технической информацией | |||||
| Совершенствование документооборота и контроль исполнения документов | |||||
| Управление охраной природы и окружающей средой | |||||
| Учет пенсий, пособий и страховых операций | |||||
| Статистические задачи | |||||
| Задачи расчетного характера |
Примечание. В случае участия в работе разработчиков постановки задачи и разработчиков программного обеспечения удельный вес их трудоемкости учитывается соответственно 0,65 и 0,35.
Таблица 1.2
Затраты времени при выполнении работ
на стадии « Эскизный проект »
| Норма | Комплекс задач (задачи) подсистем | Степень новизны | |||
| А | Б | В | Г | ||
| Перспективное планирование развития и размещения отрасли, управление проектированием и капитальным строительством, технико-экономическое планирование, оперативное управление, управление ценообразованием | |||||
| Управление материально-техническим снабжением, управление сбытом продукции, управление комплектацией, управление экспортными и импортными поставками | |||||
| Бухгалтерский учет, управление финансовой деятельностью | |||||
| Управление организацией труда и заработной платой, управление кадрами, нормы и нормативы, управление охраной труда | |||||
| Управление качеством продукции, управление технологическими процессами, управление стандартизацией, управление технической подготовкой производства | |||||
| Управление транспортными перевозками, управление техническим обслуживанием производства, управление вспомогательными службами и энергоснабжением | |||||
| Управление НИР и ОКР | |||||
| Управление научно-технической информацией | |||||
| Совершенствование документооборота и контроль исполнения документов | |||||
| Управление охраной природы и окружающей средой | |||||
| Учет пенсий, пособий и страховых операций | |||||
| Статистические задачи | |||||
| Задачи расчетного характера |
Примечание. В случае участия в работе разработчиков постановки задачи и разработчиков программного обеспечения удельный вес их трудоемкости учитывается соответственно 0,7 и 0,3.
Таблица 1.3
Затраты времени при выполнении работ на стадии
« Технический проект » для подсистем: управление финансовой деятельностью; бухгалтерский учет
|
|
|
