Лекция 1. Качество ПО и методы контроля качества (1186160), страница 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..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
