Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 417
Скачиваний: 1
СОДЕРЖАНИЕ
Роль тестирования в процессе разработки
Фазы жизненного цикла тестирования программного обеспечения
Измерения в процессе тестирования. Польза измерений
Польза измерений при тестировании программного обеспечения
Показатели, характеризующие стоимость тестирования
Показатели, характеризующие стратегию тестирования
Метрики для этапа планирования тестирования
Метрики для показателей этапа тест-дизайна
Метрики для оценки качества тестирования
Метрики для оценки стоимости тестирования
Метрики для оценки объема тестирования
Метрики для оценки стратегии тестирования
Измерение комбинаций техник тестирования
Оценка адекватности тестовых данных
Польза и правила применения метрик в процессе тестирования
Сочетание с экспертным мнением
Метрики помогают обоснованному принятию решений, но степень субъективности, экспертное суждение и аналогия все еще играют важную роль в принятии окончательного решения, касающегося планирования тестирования программного обеспечения и проектирования тестов. Поэтому принятие решения должно взаимодействовать между мнениями экспертов и результатами метрик.
Заключение
Тестирование программного обеспечения широко применяется во всех компаниях по разработке программного обеспечения от самых маленьких до самых крупных корпораций.
Несомненно, каждая компания стремится разработать процесс тестирования программного обеспечения, который будет выгодным, качественным и быстрым.
Сегодня большинство метрик в тестировании программного обеспечения рассматриваются на этапе выполнения тестов и основаны на количестве ошибок, обнаруженных при выполнении тестов. Существует очевидный пробел в области применения метрик для этапа планирования тестирования и проектирования тестов. Данное исследование было призвано закрыть этот пробел.
Измеримые показатели этапа планирования тестирования программного обеспечения и проектирования тестов не упоминаются в литературе в консолидированной форме. Проведенное исследование разделило показатели по категориям: прогресс (6 показателей), стоимость (4 показателя), качество (3 показателя), область тестирования (3 показателя) – для этапа планирования тестирования; прогресс (3 показателя), стоимость (1 показатель), качество (3 показателя), объем (3 показателя), стратегия (4 показателя) – для этапа проектирования тестирования. Такая классификация - хороший шаг к дальнейшим исследованиям внутри каждой категории.
Разработано 19 метрик для показателей для формирования осознанного принятия решений. Представлены способы измерения каждого из показателей. Разработанные методические рекомендации предлагают правила по применению метрик.
В рамках данной работы удалось сделать шаги на пути к решению глобальных задач по оптимизации процессов планирования и проектирования тестирования, а именно:
-
Была составлена полная классификация типов тестирования с их описанием; -
Выявлены и внимательно исследованы важные этапы жизненного цикла тестирования программного обеспечения; -
Идентифицированы важные показатели исследуемых этапов тестирования, необходимые для проведения исследования метрик для повышения эффективности процесса тестирования; -
Исследованы метрики относительно выделенных показателей; -
Разработаны краткие методические рекомендации по применению метрик.
Список литературы
[1] R. S. Pressman. Software Engineering – A Practitioner’s Approach. McGraw Hill Education Asia, 2005.
[2] J. Seo, B. Choi. Tailoring Test Process by Using the Component-Based Development Paradigm and the XML Technology. In IEEE Software Engineering Conference, 2000.
[3] IEEE Standard 1059-1993. IEEE Guide for Software Verification and Validation Plans. IEEE, 1993.
[4] R. D. Craig, S. P. Jaskiel. Systematic Software Testing. Artech House Publishers, BostonLondon, 2002.
[5] ISEB Foundation Certificate in Software Testing. SIM Group Ltd., SQS Group AG, 2002.
[6] G. J. Myers. The Art of Software Testing. John Willey & Sons, Inc., New York, USA, 1976.
[7] E. Dustin. Effective Software Testing-50 Specific Ways to Improve Your Testing. Addison Wesley, 2002.
[8] J. Tian. Software Quality Engineering- Testing, Quality Assurance, and Quantifiable Improvement, IEEE Computer Society, 2005.
[9] IEEE Standard 829-1998. IEEE Standard for Software Test Documentation. IEEE, 1998.
[10] D. J. Paulish, A. D. Carleton. Case Studies of Software Process Improvement Measurement. IEEE, 1994.
[11] N. E. Fenton, S. L. Pfleeger. Software Metrics - A Rigorous & Practical Approach. Second Edition. PWS Publishing Company, 1997.
[12] S. Morasca, L. C. Briand. Towards a Theoretical Framework for Measuring Software Attributes. IEEE, 1997.
[13] C. Kaner. Software Engineering Metrics: What Do They Measure and How Do We Know? 10PthP International Software Metrics Symposium, 2004.
[14] R. E. Park, W. B. Goethert, W. A. Florac. Goal Driven Software Measurement-A Guidebook. CMU/SEI-96-BH-002, Software Engineering Institute, Carnegie Mellon University, August 1996.
[15] K. H. Moller, D. J. Paulish. Software Metrics: A Practitioner’s Guide to Improved Product Development. IEEE CS Press, Los Alamitos, 1993.
[16] IEEE Standard 1061-1998. IEEE Standard for Software Quality Metrics Methodology. IEEE, 1998.
[17] I. Burnstein. Practical Software Testing. Springer-Verlag New York, Inc., 2003.
[18] R. B. Grady. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall Inc., New Jersey, 1992.
[19] A. D. Carleton et al. Software Measurement for DoD Systems: Recommendations for Initial Core Measures. Tech. Report CMUISEI-92-019, ESC-TR-92-019, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1992.
[20] L. M. Laird, M. C. Brennan. Software Measurement and Estimation: A Practical Approach. John Wiley & Sons, Inc., New Jersey, 2006.
[21] S. R. Rakitin. Software Verification and Validation for Practitioners and Managers. Artech House Inc. Boston-London, 2001.
[22] S. H. Kan. Metrics and Models in Software Quality Engineering. Second Edition. Addison Wesley, 2002.
[23] M. L. Hutcheson. Software Testing Fundamentals: Methods and Metrics. John Willey & Sons, 2003.
[24] R. Chillarege. Software Testing Best Practices. Center for Software Engineering, Copyright IBM Research- Technical Report RC 21457 Log 96856, 1999.
[25] I. Burnstein, T. Suwanassart, R. Carlson. Developing a Testing Maturity Model for Software Test Process Evaluation and Improvement. In IEEE, Test Conference, 1996.
[26] K. Iberle. Divide and Conquer: Making Sense of Test Planning. In the International Conference on Software Testing, Analysis and Review, STARWEST, 1999.
[27] R. Shewale. Unit Testing Presentation. A StickyMinds Article. November 2006.
[28] E. Dustin, J. Rashka, J. Paul. Automated Software Testing. Addison-Wesley, 1999.
[29] The Standish Group. Chaos Report.
[30] K. Molokken and M. Jorgensen. A Review of Surveys on Software Effort Estimation. Simula Research Laboratory, 2003.
[31] N. Bajaj, A. Tyagi, R. Agarwal. Software Estimation – A Fuzzy Approach. ACM SIGSOFT Software Engineering Notes Volume 31 Number 3, May 2006.
[32] J. P. Lewis. Limits to Software Estimation. ACM SIGSOFT Software Engineering Notes Volume 26 Number 4, July 2001.
[33] L. M. Laird, M. C. Brennan. Practical Software Measurement and Estimation: A Practical Approach. Copyright IEEE Computer Society, 2006.
[34] R. Fantina. Practical Software Process Improvement. Artech House Inc., 2005.
[35] W. E. Lewis. Software Testing and Continuous Quality Improvement. Second Edition. Auerbach Publications, 2005.
[36] S. McConnell. Daily Build and Smoke Test. IEEE Software, Volume 13, Number 4, July 1996.
[37] J. Bach. Test Plan Evaluation Model. Satisfice, Inc., 1999.
[38] B. Berger. Evaluating Test Plans with Rubrics. International Conference on Software Testing Analysis and Review, 2004.
[39] J. Gray. Why do Computers Stop and What Can be Done About it? In TProceedings of 5th Symposium on Reliability in Distributed Software and Database SystemsT, 1986.
[40] J. Bach. Testing Testers — Things to Consider When Measuring Performance. A StickyMinds Article. http://www.stickyminds.com, November 2006.
[41] Y. Chernak. Validating and Improving Test-Case Effectiveness. IEEE Software, 2001.
[42] R. Black. Critical Testing Processes: Plan, Prepare, Perform, Perfect. Addison Wesley, 2003.
[43] M. Marre´, A. Bertolino. Using Spanning Sets for Coverage Testing. In IEEE Transactions on Software Engineering, Volume 29, Number 11, November 2003.
[44] P. Piwowarski, M. Ohba, J. Caruso. Coverage Measurement Experience During Function Test. International Business Machines Corporation. In IEEE Software Engineering Proceedings, 1993.
[45] V. Karthikeyan. Traceability Matrix. A StickyMinds Article.1, 2006.
[46] T. Pyhälä, K. Heljanko. Specification Coverage Aided Test Selection. In Proceedings of the Third International Conference on Application of Concurrency to System Design (ACSD’03), IEEE, 2003.
[47] M. P. E. Heimdahl, D. George, R. Weber. Specification Test Coverage Adequacy Criteria = Specification Test Generation Inadequacy Criteria? In Proceedings of the Eighth IEEE International Symposium on High Assurance Systems Engineering (HASE’04), IEEE, 2004.
[48] M. W. Wahlen, A. Rajan, M. P. E. Heimdahl, S. P. Miller. Coverage Metrics for Requirements Based Testing. In Proceedings of the 2006 International Symposium on Software Testing and Analysis, 2006.
[49] D. S. Rosenblum, E. J. Weyuker. Predicting the Cost Effectiveness of Regression Testing Strategies. In the Proceedings of 4PthP ACM SIGSOFT Symposium on Foundations of Software Engineering, 1996.
[50] R. Patton. Software Testing. Sams Publishing, July 2006.
[51] S. Elbaum, A. G. Malishevsky, G. Rothermel. Test Case Prioritization: A Family of Empirical Studies. In the Proceedings of IEEE Transactions on Software Engineering, Volume 28, Number 2, 2002.
[52] T. J. Ostrand, E. J. Weuker, R. M. Bell. Predicting the Location and Number of Faults in Large Software Systems. IEEE Transactions on Software Engineering, Volume 31, Number 4, 2005.
[53] T. M. Khoshgoftaar, E. B. Allen, K. S. Kalaichelvan, N. Goeal. Early Quality Prediction: A Case Study in Telecommunications. IEEE Software, Volume 13, Issue 1, 1996.
[54] T. L. Graves, A. F. Karr, J. S. Marron, H. Siy. Predicting the Fault Incidence Using Software Change History. IEEE Transactions on Software Engineering, Volume 26, Number 27, 2000.
[55] J. C. Munson, T. J. Khoshgoftaar. The Detection of Fault-Prone Programs. IEEE Transactions on Software Engineering, Volume 18, Number 5, 1992.
[56] N. Ohlsson, H. Alberg. Predicting Fault-Prone Software Modules in Telephone Switches. IEEE Transactions on Software Engineering, Volume 22, Number 12, 1996.
[57] P. J. Schroeder, B. Korel. Black-box Test Reduction Using Input-Output Analysis. In the Proceedings of the 2000 ACM SIGSOFT International Symposium on Software Testing and Analysis ISSTA, 2000.
[58] R. Torkar, S. Mankefors-Christiernin. Fault Finding Effectiveness in Common Black Box Testing Techniques: A Comparative Study. 2003.
[59] L. Lauterbach, W. Randall. Experimental Evaluation of Six Test Techniques. In the Proceedings of the Fourth Annual Conference on Systems Integrity, Software Safety and Process Security, IEEE, 1989.
[60] What are Metrics and Why are they Important ? http://www.managementstudyguide.com/what-are-metrics.htm
[61] Kan S.H., Metrics and Models in Software Quality Engineering, Second Edition. - Addison Wesle, 2002.
Приложение 1
Таблица 31. Типы тестирования
Тип тестирования | Описание |
Функциональное тестирование | Функциональное тестирование представляет собой метод тестирования, который используется для проверки функций / функциональности системы или программного обеспечения, оно должно охватывать все сценарии, в том числе пути с ошибками и граничные случаи. |
Интеграционное тестирование | Интеграционное тестирование тестирует взаимодействие, интеграцию или интерфейсы между разными частями (модулями) системы. |
Системная интеграция | Интеграционное тестирование системы включает в себя общее тестирование всей системы из многих компонентов, подсистем или элементов. Тестируемая система может состоять из аппаратных средств, или программного обеспечения, или аппаратных средств со встроенным программным обеспечением, или аппаратным / программным обеспечением с тестированием с участием человека. |
Интеграция сверху-вниз | Интеграция сверху-вниз имитирует поведение модулей нижнего уровня, которые еще не интегрированы. Заглушки – это модули, которые действуют в качестве временной замены для вызываемого модуля и дают тот же результат, что и фактический продукт. |
Интеграция снизу-вверх | Во время интеграции снизу-вверх каждый компонент на более низком уровне иерархии проверяется отдельно, затем проверяются компоненты уровнем выше |
Двунаправленная интеграция (Сэндвич тестирование) | Сэндвич тестирование – это тип тестирования, который объединяет два подхода: интеграцию сверху-вниз и снизу-вверх. |
Структурное тестирование | Структурное тестирование проверяет реализацию программы или кода. Целью структурного тестирования является не проверка различных входных или выходных условий, а проверка различные внутренних данных и структур программирования, используемых в программе. |
Тестирование покрытия кода | Тестирование покрытия кода проверяет, какая часть вашего кода покрыта тестами. Измерять покрытие можно разными способами, основные из них:
|
Тестирование сложности | Цикломатическая сложность является измерением сложности исходного кода, который коррелирует с количеством ошибок при кодировании. Дж. Маккейб предложил метод, который заключается в проверке каждого линейно независимого пути. При таком подходе количество необходимых тестов соответствует цикломатической сложности программы |
Мутационное тестирование | Мутационное тестирование используется для разработки новых тестов и оценки качества существующих. Тестирование при помощи мутаций предполагает небольшие изменения программы. Цель состоит в том, чтобы помочь тестировщику разработать эффективные тесты или найти слабые места в тестовых данных, используемых для программы или в разделах кода, которые редко используются (или никогда). |
Модульное тестирование | Модульное тестирование представляет собой метод тестирования программного обеспечения, с помощью которого отдельные единицы исходного кода, наборы одного или нескольких компьютерных программных модулей вместе с сопутствующими данными управления, процедурами использования и операционными процедурами проверяются, чтобы определить, являются ли они пригодными для использования. |
Дымовое тестирование | Это выполнение определенного набора тестов, которые покрывает главный функционал продукта и проверяет его работоспособность для возможности проведения дальнейшего тестирования. |
Санитарное тестирование | Санитарное тестирование используется для узконаправленной проверки конкретной новой/исправленной функции. |
Системное тестирование | Системное тестирование проводится на полностью интегрированной системе. Чтобы оценить соответствие системы требованиям. Тестирование системы проводится методом черного ящика, что не требует знаний о внутреннем устройстве системы. |
Регрессионное тестирование | Регрессионное тестирование является одним из видов тестирования программного обеспечения, которое проверяет, что ранее разработанное и протестированное программное обеспечение все еще правильно выполняет свои функции даже после того, как оно было изменено или связано с другим программным обеспечением. |
Приемочное тестирование | Приемочное тестирование проводится перед тем, как новый продукт официально выйдет к клиенту. |
Тестирование установки | Приемочное тестирование также известно, как бета-тестирование. |
Тестирование пользовательского интерфейса | Тестирование установки является своего рода работой по обеспечению качества в индустрии программного обеспечения, которая сосредотачивается на том, новое программное обеспечение может быть успешно установлено, обновлено, удалено и настроено. Процесс тестирования установки может включать в себя полную/частичную установку и/или модернизацию. |
Нефункциональное тестирование | Нефункциональное тестирование проверяет соответствие нефункциональным требованиям: как система работает, а не конкретное ее поведение. |
Тестирование доступности | Тестирование доступности означает запуск приложения на запланированный период времени для сбора информации об ошибках и времени ремонта. После чего проводится сравнение времени доступности к общему времени работы. |
Базовое тестирование | Базовое тестирование относится к проверке документов и спецификаций, на основе которых разработаны Тестовые случаи. |
Тестирование совместимости | Тестирование совместимости - тип тестирования, используемый для проверки совместимости разработанной системы / приложения / веб-сайта с различными другими объектами, такими как: другие веб-браузеры, аппаратные платформы, пользователи (в том случае, если это очень специфический тип требования, если пользователь, говорит и может читать только на конкретном языке), операционные системы и т.д. Этот тип тестирования помогает выяснить, насколько хорошо система работает в той или иной среде, которая включает в себя аппаратные средства, сети, операционной системы и другое программного обеспечения и т.д. |
Тестирование на соответствие стандартам | Это своего рода аудит системы, который проводится, чтобы проверить, все ли указанные стандарты соблюдены или нет. Тестирование на соответствие также известно как аттестационное тестирование. Стандарты, обычно используемые в ИТ-индустрии, в основном определяются крупными организациями, как IEEE (Международный институт инженеров электротехники и электроники) или W3C (World Wide Web Consortium) и т.д. Он также может осуществляться независимой компанией/ третьей стороной, которая специализируется на этом типе тестирования и обслуживания. |
Руководство по обеспечению доступности веб-контента (WCAG) | Все пользователи, независимо от статуса инвалидности, могут получить доступ к технологии. Это призвано сломать барьеры и предоставить новые возможности для всех пользователей Интернета. |
SOX | SOX Section 404 (Sarbanes-Oxley Act Section 404) устанавливает, что публичные компании должны создать механизмы внутреннего контроля и процедуры финансовой отчетности и должны документировать, тестировать и поддерживать те элементы управления и процедуры для обеспечения их эффективности. SOX определяет, какие записи должны храниться и как долго. |
Конфигурационное тестирование | Конфигурационное тестирование – это процесс тестирования приложения с различным набором программно-аппаратного обеспечения. Цель его – определить оптимальную конфигурацию, при которой приложение работает стабильно и без ошибок. |
Тестирование документации | Тестирование документации включает в себя проверку документированных артефактов, разработанных до или во время тестирования программного обеспечения. |
Тестирование эргономики | Тестирование эргономики проверяет, соответствует ли продукт требованиям, оптимальным для использования человеком. |
Тестирование взаимодействия | Тестирование взаимодействия проверяет, совместима ли с другими данная программа или технология и присутствует ли функциональность совместного использования. |
Тестирование портативности | Тестирование портативности - это метод проверки, при котором система помещается в какую-либо другую среду, чтобы проверить ее поведение. |
Тестирование локализации и интернационализации | Тестирование локализации включает тестирование локализованного продукта в соответствии с национальными стандартами языка, поиск непереведенного текста в пользовательском интерфейсе, проверки согласованности форматов (формат даты, числовые форматы и т.д.), проверку на соответствие правилам капитализации и правильного использования алфавитов, проверку правильности использования валют и т.д. Тестирование интернационализации проверяет, был ли продукт правильно адаптирован для работы при различных языковых и региональных настройках (возможность отображать символы с диакритическими знаками, чтобы работать на неанглийских операционных системах). |
Тестирование сопровождаемости | Тестирование сопровождаемости определяет, насколько легко поддерживать систему: насколько легко анализировать, изменять и тестировать систему. |
Операционное приемочное тестирование | Операционное приемочное тестирование используется для проверки оперативной готовки продукта (пре-релиза) в рамках системы управления качеством. |
Тестирование надежности | Надежность системы является показателем стабильности и эффективности работы системы в течение продолжительного периода времени при различных конкретных наборах условий. Этот тип тестирования включает в себя результаты нефункционального тестирования, такие как стресс-тестирование, тестирование безопасности, тестирование соединения, наряду с функциональным тестированием. |
Тестирование устойчивости | Тестирование устойчивости подтверждает, что система может восстановиться после ожидаемого или неожиданного падения без потери данных и функциональности. |
Тестирование безопасности | Тестирование безопасности представляет собой процесс, предназначенный для выявления недостатков в механизмах безопасности системы, которые защищают данные и поддерживают функциональные возможности. |
Тестирование удобства пользования | Юзабилити-тестирование проверяет удобство использования конкретного объекта или набора объектов, а исследования взаимодействия человека и компьютера пытаются сформулировать универсальные принципы. |
Тестирование производительности | Тестирование производительности проводится для определения того, как система работает с точки зрения оперативности и стабильности при определенной рабочей нагрузке. Оно может также служить для исследования, измерения или проверки качества и других атрибутов системы, таких как масштабируемость, надежность и использование ресурсов. |
Нагрузочное тестирование | Нагрузочное тестирование является самой простой формой тестирования производительности. Оно обычно проводится, чтобы понять поведение системы при определенной ожидаемой нагрузке. Этот тест будет выдавать время отклика всех важных бизнес-критических операций, потребление ресурсов, оперативной памяти и другие. Базы данных, сервер приложений и прочее также контролируются во время испытания, это поможет выявить уязвимые места в прикладном программном обеспечении и оборудовании, на котором оно установлено. |
Стресс-тестирование | Стресс-тестирование обычно используется, чтобы понять, верхние пределы мощности в системе. Такого рода тест проводится для определения надежности системы с точки зрения крайней нагрузки и помогает администраторам приложений определить, будет ли система достаточно надежной, если поток нагрузки будет намного выше ожидаемой. |
Тестирование объемом | Тестирование объемом относится к тестированию программного приложения с большим объемом данных, которые должны быть обработаны, чтобы проверить эффективность применения. Основной целью данного тестирования является мониторинг эффективности приложения при различных объемах базы данных |
Тестирование масштабируемости | Тестирование масштабируемости проверяет, насколько сильно можно расширить систему (путем увеличения памяти, числа машин и т.д.) и каково крайнее значение, после которого расширение уже невозможно. |
Тестирование восстановления | Тестирование восстановления подтверждает, что пораженная система может быть успешно перезапущена после сбоя. |
Тестирование продолжительной работы | Такое тестирование включает в себя тестирование системы с ожидаемой нагрузкой в течение длительного периода времени, чтобы выявить поведение системы. Давайте возьмем пример, когда система предназначена для работы в течение 3 часов, нужно узнать ее поведение при работе в течение 6 часов. Чаще всего проверяются утечки памяти или сбои систем. |
Тестирование нестабильной нагрузкой | Тестирование нестабильной нагрузкой проводится при помощи внезапного увеличения или уменьшения нагрузки на систему. Цель – проверить поведение системы при неожиданных скачках. |
Тестирование конфигурации | Вместо того, чтобы проверять производительности с точки зрения нагрузки, такие тесты созданы, чтобы определить влияние изменений в конфигурации компонентов системы на производительность и поведение системы. |
Изолированное тестирование | Изолированное тестирование не является уникальным для тестирования производительности, но включает в себя повторение теста, который привел к системной проблеме. Такое тестирование часто может изолировать и подтвердить домен с неисправностью. |