Версия 3 (от 9 июля 2014 года) Подготовлен Glossary Working Party
Скачать 0.93 Mb.
|
цикл Деминга (Deming cycle): Итеративный процесс решения проблемы, состоящий из 4х пунктов: планирование, выполнение, проверка, корректировка. Обычно используется при улучшении процессов [по Демингу]. цикл тестирования (test cycle): Выполнение процесса тестирования для одной однозначно определяемой версии тестируемого объекта. цикломатическая сложность (cyclomatic complexity): Число независимых линейных путей в программе. Цикломатическая сложность может быть рассчитана как: L - N + 2P, где L - число ребер/связей графа; N - число вершин графа; P - число несвязанных частей графа (например, граф вызова или подпрограмма). [McCabe] Ш широкополосный оракул (Wide Band Delphi): Методика оценки затрат на тестирование на базе экспертной оценки, ставящая целью точную оценку с помощью коллективного опыта членов команды. шкала измерений (measurement scale): Шкала, ограничивающая тип анализа данных, который может быть осуществлен над ней. [ISO 14598] шлюз качества (quality gate): Специальный рубеж в проекте. Шлюз качества располагается между теми фазами проекта, которые строго зависят от итоговых результатов предыдущей фазы. Шлюз качества предполагает формальные проверки документов предыдущей фазы. Э эвристическая оценка (heuristic evaluation): Статический анализ практичности, нацеленный на выявления проблем практичности интерфейса пользователя или его дизайна. При этой методике рецензенты изучают интерфейс и оценивают его соответствие признанным принципам практичности ("эвристика"). эквивалентная область (equivalence partition): Часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым. эквивалентное разбиение (equivalence partitioning): Разработка тестов методом черного ящика, в которой тестовые сценарии создаются для проверки элементов эквивалентной области. Как правило, тестовые сценарии разрабатываются для покрытия каждой области как минимум один раз. ATT EITP F ATA ATA ATM 69 эксперт по оценке (assessor): Человек, который проводит оценку; любой представитель группы оценки. эксплуатационное приемочное тестирование (operational acceptance testing): Эксплуатационное тестирование в фазе приемочного тестирования, обычно выполняемое пользователем и/или сотрудниками с администраторским доступом, в рабочей среде (возможно, симулированой), фокусируясь на функциональных аспектах. Например, восстанавливаемость, поведение ресурсов, устанавливаемость и техническое соответствие. См. также эксплуатационное тестирование. эксплутационное тестирование (operational testing): Тестирование, проводимое для оценки компонента или системы в его рабочем окружении. [IEEE 610] экстремальное программирование (extreme programming (XP)): Методология разработки программного обеспечения, используемая при гибкой разработке ПО, в которой применяются ключевые практики: парное программирование, простота и понятность кода, проведение исчерпывающей экспертизы кода и модульного тестирования всего кода. См. также гибкая методология разработки программного обеспечения. элемент конфигурации (configuration item): Сочетание аппаратного и/или программного обеспечения, предназначенное для управления конфигурацией и рассматриваемое как отдельный объект процесса управления конфигурацией. [IEEE 610] элемент покрытия (coverage item): Сущность или свойство, используемые как базис для тестового покрытия, например эквивалентные области или операторы в коде. элемент тестирования (test item): Отдельный элемент, который должен быть протестирован. Обычно имеется один тестовый объект и несколько элементов тестирования. См. объект тестирования. эмоциональный интеллект (emotional intelligence): Способность, возможность и умение определять, оценивать и управлять своими эмоциями и эмоциями других людей или групп. эмулятор (emulator): Устройство, компьютерная программа или система, которая принимает те же самые входные данные и выдаёт те же самые выходные данные, что и данная система [IEEE 610]. См. также имитатор. эталонный тест (benchmark test): (1) стандарт, согласно которому может производиться измерение или сравнение. (2) тест, который может использоваться для сравнения компонентов или систем друг с другом или на соответствие стандарту, указанному в (1). [Согласно IEEE 610] этап требований (requirements phase): Период в жизненном цикле программного обеспечения, в течении которого определяются и документируются требования к программному продукту. [IEEE 610] эффект зондирования (probe effect): Эффект, который оказывает измеряющий инструмент (например, инструмент тестирования производительности или монитор) на измеряемую систему. Для примера: производительность может быть несколько хуже в момент использования инструмента тестирования производительности. EITP EITP EITP ATT F F-AT 70 эффективность (efficiency): 1. Способность программного обеспечения обеспечивать необходимую производительность, относительно количества ресурсов используемых при установленных условиях. [ISO 9126] 2. Способность процесса обеспечивать ожидаемый результат относительно количества используемых ресурсов. Я язык описания сценариев (scripting language): Язык программирования, на котором пишутся автоматизированные сценарии тестирования для инструмента выполнения тестов (например, средства захвата/воспроизведения). ATM ATT F 71 Дополнение А (Справочное) Стандарты [DO-178b] DO-178B:1992. Software Considerations in Airborne Systems and Equipment Certification, Requirements and Technical Concepts for Aviation (RTCA SC167). [IEEE 610] IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology. [IEEE 829] IEEE 829:1998. Standard for Software Test Documentation. [IEEE 1008] IEEE 1008:1993. Standard for Software Unit Testing. [IEEE 1028] IEEE 1028:1997. Standard for Software Reviews and Audits. [IEEE 1044] IEEE 1044:1993. Standard Classification for Software Anomalies. [IEEE 1219] IEEE 1219:1998. Software Maintenance. [ISO 2382/1] ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms. [ISO 8402] ISO 8402: 1994. Quality Management and Quality Assurance Vocabulary [ISO 9000] ISO 9000:2005. Quality Management Systems – Fundamentals and Vocabulary. [ISO 9126] ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1: Quality characteristics and sub-characteristics. [ISO 12207] ISO/IEC 12207:1995. Information Technology – Software Lifecycle Processes. [ISO 14598] ISO/IEC 14598-1:1999. Information Technology – Software Product Evaluation - Part 1: General Overview. [ISO 15504] ISO/IEC 15504-9: 1998. Information Technology – Software Process Assessment – Part 9: Vocabulary Книги и периодические издания [Abbott] J. Abbot (1986), Software Testing Techniques, NCC Publications [Adrion] W. Adrion, M. Branstad and J. Cherniabsky (1982), Validation, Verification andTesting of Computer Software, in: Computing Surveys, Vol. 14, No 2, June 1982 [Akao] Akao, Yoji (1994), Development History of Quality Function Deployment – TheCustomer Driven Approach to Quality Planning and Deployment, Minato, Tokyo 107Japan: Asian Productivity Organization, pp. 339, ISBN 92-833-1121-3 [Bach] J. Bach (2004), Exploratory Testing, in: E. van Veenendaal, The Testing Practitioner –2nd edition, UTN Publishing, ISBN 90-72194-65-9 [Beizer] B. Beizer (1990), Software Testing Techniques, van Nostrand Reinhold, ISBN 0-442-20672-0 [Chow] T. Chow (1978), Testing Software Design Modelled by Finite-Sate Machines, in:IEEE Transactions on Software Engineering, Vol. 4, No 3, May 1978 [CMM] M. Paulk, C. Weber, B. Curtis and M.B. Chrissis (1995), The Capability MaturityModel, Guidelines for Improving the Software Process, Addison-Wesley, ISBN 0-201-54664-753 [CMMI] M.B. Chrissis, M. Konrad and S. Shrum (2004), CMMI, Guidelines for ProcessIntegration and Product Improvement, Addison Wesley, ISBN 0-321-15496-7 [Deming] D. W. Edwards (1986), Out of the Crisis, MIT Center for Advanced EngineeringStudy, ISBN 0- 911379-01-0 [Fenton] N. Fenton (1991), Software Metrics: a Rigorous Approach, Chapman & Hall, ISBN0-53249-425 72 [Fewster and Graham] M. Fewster and D. Graham (1999), Software Test Automation,Effective use of test execution tools, Addison-Wesley, ISBN 0-201-33140-3 [Freedman and Weinberg] D. Freedman and G. Weinberg (1990), Walkthroughs, Inspections,and Technical Reviews, Dorset House Publishing, ISBN 0-932633-19-6 [Garvin] D.A. Garvin (1984), What does product quality really mean?, in: Sloan ManagementReview, Vol. 26, nr. 1 1984 [Gerrard] P. Gerrard and N. Thompson (2002), Risk-Based E-Business Testing, Artech HousePublishers, ISBN 1-58053-314-0 [Gilb and Graham] T. Gilb and D. Graham (1993), Software Inspection, Addison-Wesley,ISBN 0-201-63181-4 [Graham] D. Graham, E. van Veenendaal, I. Evans and R. Black (2007), Foundations ofSoftware Testing, Thomson Learning, ISBN 978-1-84480-355-2 [Grochtmann] M. Grochtmann (1994), Test Case Design Using Classification Trees, in:Conference Proceedings STAR 1994 [Hetzel] W. Hetzel (1988), The complete guide to software testing – 2nd edition, QEDInformation Sciences, ISBN 0-89435-242-3 [Juran] J.M. Juran (1979), Quality Control Handbook, McGraw-Hill [McCabe] T. McCabe (1976), A complexity measure, in: IEEE Transactions on SoftwareEngineering, Vol. 2, pp. 308-320 [Musa] J. Musa (1998), Software Reliability Engineering Testing, McGraw-Hill Education,ISBN 0-07913-271-5 [Myers] G. Myers (1979), The Art of Software Testing, Wiley, ISBN 0-471-04328-1 [TMap] M. Pol, R. Teunissen, E. van Veenendaal (2002), Software Testing, A guide to theTMap Approach, Addison Wesley, ISBN 0-201-745712 [TMMi] E. van Veenendaal and J. Cannegieter (2011), The Little TMMi, UTN Publishing,ISBN 97-89490986- 03-2 [Veenendaal04] E. van Veenendaal (2004), The Testing Practitioner – 2nd edition, UTNPublishing, ISBN 90- 72194-65-9 [Veenendaal08] E. van Veenendaal (2008), Test Improvement Manifesto, in: TestingExperience, Issue 04/08, December 2008 73 Дополнение Б (Способы обсуждения данного Глоссария) Замечания по этому документу приветствуются, поскольку они позволят улучшить Глоссарий для удовлетворения нужд сообщества тестировщиков. В комментарий необходимо включать следующую информацию: Ваше имя и контактные данные; Номер версии Глоссария (в настоящее время 2.3); Ссылка на комментируемую часть Глоссария; Дополнительная информация, такая как причина предлагаемого изменения или ссылка на использование термина. Вы можете предложить свои замечания электронной почтой на адрес info@rstqb.org. |