Лекции. Тестирование ПО (all in one) (1186159), страница 7
Текст из файла (страница 7)
Поэтому можно сказать, что тестирование всегда проводится на основенекоторых моделей, быть может, не представленных явно.Тестирование на основе моделей, которому посвящен этот курс, отличается только тем, чтовсе используемые при разработке, выборе и выполнении тестов модели формулируютсяявно. Наиболее важную роль среди моделей, используемых при тестировании, играютмодели требований, описывающие желательное поведение системы, и модели ситуаций иликритерии полноты тестирования, определяющие набор разрабатываемых или выбираемыхдля выполнения тестов.Литература[18] В.
В. Кулямин. Методы верификации программного обеспечения. 2008.[19] M. Broy, B. Jonsson, J.-P. Katoen, M. Leucker, A. Pretschner, eds. Model Based Testing ofReactive Systems. LNCS 3472, Springer, 2005.[20] M. Utting, B. Legeard. Practical Model-Based Testing: A Tools Approach. MorganKaufmann, 2007.[21] D. L. Detlefs, K. R. M. Leino, G. Nelson, J. B. Saxe. Extended static checking. TechnicalReport SRC-RR-159, Digital Equipment Corporation, Systems Research Center, 1998.[22] C. Csallner, Y.
Smaragdakis. DSD-Crasher: A hybrid analysis tool for bug finding. Proc. ofACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA),pp. 245-254. ACM, July 2006.[23] C. Pacheco, S. K. Lahiri, M. D. Ernst, T. Ball. Feedback-Directed Random Test Generation.Proc. of International Conference on Software Engineering, pp. 75-84, 2007.[24] P. Godefroid, N. Klarlund, K. Sen.
DART: Directed Automated Random Testing. ACMSIGPLAN Notices - Proceedings of PLDI 2005, 40(6):213-223, 2005.[25] K. Sen, G. Agha. CUTE and jCUTE: Concolic Unit Testing and Explicit Path ModelChecking Tools. LNCS 4144:419-423, Spriger, 2006.[26] Glenford J. Myers. Software Reliability. Principles and Practices. Wiley, 1976.[27] William C. Hetzel. The Complete Guide to Software Testing.
Wiley, 1984.[28] IEEE Standard 829: Standard for Software Test Documentation. IEEE, 1983.[29] B. Beizer. Software Testing Techniques. 2nd edition. Int. Thomson Publishing, 1990.[30] ANSI/IEEE 610.12-1990. Glossary of Software Engineering Terminology. NY:IEEE, 1987.[31] BCS 7925-1. Glossary of terms used in Software Testing. 1995.[32] Сem Kaner. Black box testing course. 1999.[33] IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004.[34] Daniel Galin. Software Quality Assurance. From theory to implementation.
2004.[35] ISTQB Glossary of Terms used in Software Testing. 2006.Тестирование на основе моделейВ. В. КуляминЛекция 2. Основные задачи и виды тестированияВ прошлой лекции тестирование было определено как проверка соответствия поведенияпрограммной системы требованиям, выполняемая по результатам реальной работы этойсистемы в некотором конечном наборе заранее определенных ситуаций [1].Таким образом, основная задача тестирования — проверка требований. Ее решение чащевсего сводится к последовательному решению ряда промежуточных задач.
Кроме того, длярешения этих задач в различных обстоятельствах необходимы разные подходы,определяемые технической спецификой и внешними целями — для чего именнотестирование нужно в контексте заданного проекта. Данная лекция посвящена основнымцелям и задачам тестирования, различным способам его проведения.Цели тестированияТестирование является одним из видов деятельности жизненного цикла программногообеспечения и в рамках всего процесса разработки и сопровождения ПО можетиспользоваться для достижения нескольких целей.•Наиболее очевидная цель тестирования — поиск ошибок, то есть расхождений междунаблюдаемым поведением ПО и требованиями к нему.Это наиболее понятная и простая цель, которая первой приходит на ум при разговоре отестировании.Даже весьма опытные разработчики ПО часто считают, что это — его единственнаяцель. Классическая фраза Дейкстры «тестирование может использоваться длядемонстрации наличия ошибок в программе, но не может использоваться длядемонстрации их отсутствия» часто интерпретируется именно в том смысле, чтоединственная польза от тестирования — найденные ошибки.•Менее очевидная и более сложная для понимания цель тестирования — общая оценкакачества ПО.
Помимо прямого обнаружения ошибок, оно должно давать информациюо том, где, скорее всего, находятся еще не найденные ошибки, насколько они могут бытьсерьезны, насколько тестируемая система надежно и корректно работает в целом,насколько корректны и стабильны ее отдельные функции и компоненты.Если единственной целью тестирования считать нахождение ошибок, то терпеливое,аккуратное и систематическое тестирование, в ходе которого ошибок не обнаруживается— бесполезно. Это не так, просто потому, что результатом такой работы являетсяценная информация о свойствах системы, недоступная из других источников, если,конечно, не относиться серьезно к уверенности разработчиков в собственнойнепогрешимости (обычно считается, что «уж в основном-то все правильно, так, мелочивсякие могут еще не работать»).
Такое тестирование, если оно действительноаккуратное и систематическое, показывает, что тестируемая система — достаточнохороша. Даже если в ней и есть ошибки (что их нет, доказать при помощи тестированиядействительно невозможно), они достаточно редки и случаются в очень специфическихситуациях. Однако проведение подобного тестирования — непростая задача, основнаятрудность которой — достижение такого уровня аккуратности и систематичности,который позволяет обоснованно делать соответствующие выводы.Другой возможной проблемой при понимании тестирования как деятельности,нацеленной только на поиск ошибок, является отсутствие рациональных аргументов дляопределения момента, когда нужно прекратить тестирование.
Если тестировщикизанимаются только поиском ошибок, они не могут предоставить руководству проектаобоснованную информацию о том, что «в системе еще очень много недоделок» или,•наоборот, «система уже достаточно надежна». В этом случае решение об остановкетестирования принимается только на основе наличия ресурсов, то есть по остаточномупринципу: есть еще есть время и деньги — продолжаем тестировать, нет — прекращаем.Такого рода решения не связаны с реальным качеством системы, и поэтому способныпринести большой урон репутации организации-разработчика ПО. Кроме того, онизакрепляют плохую практику управления проектами, способствуя перемещению всебольшей и большей части ресурсов проектов в разработку без тестирования, ведь оттестирования «нет прямой пользы» и его можно проводить на «остатки» ресурсов.Если руководитель проекта принимает подобные решения, это может означать либо, чтоон недостаточно компетентен и не воспринимает поступающую от тестировщиковинформацию, либо, что тестировщики недостаточно компетентны, чтобы такуюинформацию предоставить, и тестирование проводится хаотичным, недостаточноэффективным образом, несмотря даже на то, что оно выявляет важные ошибки, — ведьостается непонятным риск наличия еще невыявленных ошибок.Методом проб и ошибок на практике были выработаны рекомендации по организациитестирования, согласно которым ресурсы для проведения разработки тестов итестирования необходимо выделять заранее.
Их размер варьируется от 20% ресурсоввсего проекта при создании достаточно простых систем до 80-90% при разработкекритически важных и сложных систем реального времени с жесткими требованиями ких надежности и качеству в целом.Еще более редко упоминаемая и долговременная цель тестирования — обеспечениестабильного развития системы, предоставление средств для отслеживания измененийв ней и предсказания возможных проблем системы после внесения в нее тех или иныхизменений.Хорошие наборы тестов на практике становятся не только средством оценки качестватестируемой системы и сертификации ее пригодности для определенных задач, но иинструментом отслеживания важных изменений при развитии системы и измерения ееобщей стабильности и надежности.
Для этого, однако, необходимо поддерживать набортестов в работоспособном состоянии, соответствующем текущим требованиям ксистеме. При наличии нескольких поддерживаемых версий системы необходимо иметьлибо соответствующие версии тестового набора, либо средства его настройки,позволяющие тестировать функциональность, специфичную для каждой из версий. Длясложных систем это возможно только при использовании специфических образцоворганизации тестов, о которых пойдет речь в следующей лекции.Задачи тестированияЧтобы достигать указанных целей управляемым и предсказуемым образом, необходимоуметь решать ряд задач. Эти задачи специфичны для тестирования как особого видадеятельности и всегда должны решаться при его проведении, тем или иным способом.Однако прежде, чем формулировать их необходимо проанализировать точный смысл рядатерминов, повсеместно используемых при разработке тестов и тестировании.Как уже говорилось, тестирование всегда проводится в некотором конечном наборезаранее определенных ситуаций.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
