Testing

1. 5. Test management(Управление тестированием)

1.1. 5.1 TEST ORGANIZATION (5.1 ИСПЫТАТЕЛЬНАЯ ОРГАНИЗАЦИЯ)

1.1.1. Glossary(Глоссарий)

1.1.1.1. tester(Тестер)

1.1.1.1.1. A skilled professional who is involved in the testing of a component or system (Квалифицированный специалист, который участвует в тестировании компонента или системы)

1.1.1.2. test leader (Тестовий лидер)

1.1.1.2.1. See test manager (См. Диспетчер тестов)

1.1.1.3. test manager (Менеджер по тестированию)

1.1.1.3.1. The person responsible for project management of testing activities and resources, and evaluation of a test object. The individual who directs, controls, administers, plans and regulates the evaluation of a test object (Лицо, ответственное за управление проектами для тестирования действий и ресурсов, а также оценку объекта тестирования. Лицо, которое направляет, контролирует, администрирует, планирует и регулирует оценку объекта тестирования)

1.1.2. 5.1.1 Independent and integrated testing (5.1.1 Независимое и интегрированное тестирование)

1.1.2.1. Independent Test Team (Независимая испытательная группа)

1.1.2.1.1. benefits (выгоды)

1.1.2.1.2. risks (риски)

1.1.3. 5.1.2 Working as a test leader (5.1.2 Работа в качестве лидера тестирования)

1.1.3.1. planning, monitoring, and control of the testing activities (Планирования, мониторинга и контроля за проведением проверок)

1.1.3.2. devise the test objectives, organizational test policies (if not already in place), test strategies and test plans (Разработать цели тестирования, политик организационных испытаний (если они еще не установлены), стратегии тестирования и планы тестирования)

1.1.3.3. estimate the testing to be done and negotiate with management to acquire the necessary resources (Оценить проводимое тестирование и договориться с руководством о приобретении необходимых ресурсов)

1.1.3.4. recognize when test automation is appropriate plan the effort, select the tools, and ensure training of the team (Узнайте, когда автоматизация тестирования соответствует планированию усилий, выберите инструменты и обеспечьте подготовку команды)

1.1.3.5. consult with other groups to help them with their testing (Проконсультируйтесь с другими группами, чтобы помочь им с их тестированием)

1.1.3.6. lead, guide and monitor the analysis, design, implementation and execution of the test cases, test procedures and test suites (Руководство, руководство и мониторинг анализа, проектирования, внедрения и выполнения тестовых примеров, процедур тестирования и наборов тестов)

1.1.3.7. ensure proper configuration management of the testware produced and traceability of the tests to the test basis (Обеспечить надлежащее управление конфигурацией тестируемого программного обеспечения и прослеживаемость тестов на тестовой основе)

1.1.3.8. make sure the test environment is put into place before test execution and managed during test execution (Убедитесь, что тестовая среда вставлена перед выполнением теста и управляется во время выполнения теста)

1.1.3.9. schedule the tests for execution and monitor, measure, control and (Планировать тесты для выполнения и мониторинга, измерения, контроля и)

1.1.3.10. report on the test progress, the product quality status and the test results, adapting the test plan and compensating as needed to adjust to evolving conditions (Отчет о ходе испытаний, состояние качества продукта и результаты испытаний, адаптация плана испытаний и компенсация по мере необходимости для адаптации к меняющимся условиям)

1.1.3.11. During test execution and as the project winds down, they write summary reports on test status (Во время выполнения теста и при ветре проекта они записывают сводные отчеты о состоянии теста)

1.1.4. 5.1.3 Working as a tester (5.1.3 Работа в качестве тестера)

1.1.4.1. In the planning and preparation phases (На этапах планирования и подготовки)

1.1.4.1.1. review and contribute to test plans (Просматривать и вносить вклад в тестовые планы)

1.1.4.1.2. review-ing and assessing requirements and design specifications (Обзор и оценка требований и проектных спецификаций)

1.1.4.2. identifying test conditions and creating (Определение условий тестирования и создание)

1.1.4.2.1. test designs(Тестовые проекты)

1.1.4.2.2. test cases(Тестовые примеры)

1.1.4.2.3. test procedure specifications(Спецификации процедуры испытаний)

1.1.4.2.4. test data(Данные испытаний)

1.1.4.2.5. automate or help to automate the tests (Автоматизировать или помочь автоматизировать тесты)

1.1.4.2.6. set up the test envi-ronments (Настроить тестовые среды)

1.1.4.2.7. assist system administration network management staff (Помочь сотрудникам управления сетью системного администрирования)

1.1.4.3. test execution (Выполнение теста)

1.1.4.3.1. execute and log the tests (Выполнять и регистрировать тесты)

1.1.4.3.2. evaluate the results (Оценивать результаты)

1.1.4.3.3. document problems found (Найдены проблемы с документами)

1.1.4.3.4. monitor the testing and the test environment (Контролировать тестирование и тестовую среду)

1.1.4.3.5. gather performance metrics (Собирать показатели производительности)

1.1.4.3.6. review each other's work, incl. test specifications, defect reports and test results (Пересмотреть работу друг друга, в т.ч. Спецификации испытаний, отчеты о дефектах и результаты испытаний)

1.1.5. 5.1.4 Defining the skills test staff need (5.1.4 Определение потребности персонала в тестировании навыков)

1.1.5.1. Application or business domain: (Область применения или бизнес:)

1.1.5.1.1. the intended behavior, the problem the system will solve, the process it will automate (Предполагаемое поведение, проблема, которую система решит, процесс, который он автоматизирует)

1.1.5.2. Technology: (Технологии:)

1.1.5.2.1. issues, limitations and capabilities of the chosen implementation technology (Проблемы, ограничения и возможности выбранной технологии внедрения)

1.1.5.3. Testing: (Тестирование:)

1.1.5.3.1. know the testing topics(Знать тестовые темы)

1.2. 5.2 TEST PLANS, ESTIMATES AND STRATEGIES

1.2.1. Glossary

1.2.1.1. entry criteria

1.2.1.1.1. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria

1.2.1.2. exit criteria

1.2.1.2.1. The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing

1.2.1.3. exploratory testing

1.2.1.3.1. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests

1.2.1.4. test approach

1.2.1.4.1. The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project’s goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed

1.2.1.5. test level

1.2.1.5.1. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test

1.2.1.6. test plan

1.2.1.6.1. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process

1.2.1.7. test procedure

1.2.1.7.1. test procedure specification: A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script

1.2.1.8. test strategy

1.2.1.8.1. A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects)

1.2.2. 5.2.1 The purpose and substance of test plans

1.2.2.1. Reasons

1.2.2.1.1. guides our thinking

1.2.2.1.2. forces us to confront the challenges that await us and focus our thinking on important topics

1.2.2.1.3. cating with other members of the project team, testers, peers, managers and other stakeholders

1.2.2.1.4. manage change

1.2.2.2. Master test plan

1.2.2.2.1. Test levels

1.2.2.2.2. hardware test plan

1.2.2.2.3. software test plan

1.2.2.3. planning tasks

1.2.2.3.1. purposes

1.2.2.3.2. select strategies

1.2.2.3.3. split the testing work into various levels

1.2.2.4. entry criteria factors

1.2.2.4.1. Acquisition and supply:

1.2.2.4.2. Test items:

1.2.2.4.3. Defects:

1.2.2.4.4. Tests:

1.2.2.4.5. Coverage:

1.2.2.4.6. Quality:

1.2.2.4.7. Money:

1.2.2.4.8. Risk:

1.2.3. 5.2.3 Estimating what testing will involve and what it will cost

1.2.3.1. phases

1.2.3.1.1. planning and control

1.2.3.1.2. analysis and design

1.2.3.1.3. implementation and execution

1.2.3.1.4. evaluating exit criteria and reporting

1.2.3.1.5. test closure

1.2.3.2. risk analysis

1.2.3.2.1. identify risks and activities required to reduce them

1.2.3.3. performance-testing planning

1.2.4. 5.2.4 Estimation techniques

1.2.4.1. consulting the people 'bottom up' estimation

1.2.4.1.1. who will do the work

1.2.4.1.2. other people with expertise on the tasks to be done

1.2.4.2. analyzing metrics top-down estimation

1.2.4.2.1. from past projects

1.2.4.2.2. from industry data

1.2.4.2.3. Approaches

1.2.4.2.4. tester-to-developer

1.2.4.3. estimation must be negotiated with management

1.2.5. 5.2.5 Factors affecting test effort

1.2.5.1. project documentation

1.2.5.2. Complexity

1.2.5.2.1. The difficulty of comprehending and correctly handling the problem the system is being built to solve

1.2.5.2.2. The use of innovative technologies, especially those long on hyperbole and short on proven track records

1.2.5.2.3. The need for intricate and perhaps multiple test configurations, especially when these rely on the timely arrival of scarce software, hardware and other supplies

1.2.5.2.4. The prevalence of stringent security rules, strictly regimented processes or other regulations

1.2.5.2.5. The geographical distribution of the team, especially if the team crosses time-zones (as many outsourcing efforts do)

1.2.5.3. increasing the size of the product leads to increases in the size of the project and the project team

1.2.5.4. availability of test tools

1.2.5.5. life cycle of development model

1.2.5.6. Process maturity, including test process maturity

1.2.5.7. Time pressure

1.2.5.8. people factors

1.2.5.8.1. skills of the individ-uals and the team as a whole

1.2.5.8.2. the alignment of those skills with the project's needs

1.2.5.8.3. solid relationships

1.2.5.8.4. reliable execution of agreed-upon commitments and responsibilities

1.2.5.8.5. a determination to work together towards a common goal

1.2.5.8.6. the stability of the project team

1.2.5.9. The test results

1.2.5.9.1. The delivery of good-quality software at the start of test execution

1.2.5.9.2. quick, solid defect fixes during test execution

1.2.6. 5.2.6 Test approaches or strategies

1.2.6.1. The major types

1.2.6.1.1. Analytical:

1.2.6.1.2. Model-based:

1.2.6.1.3. Methodical:

1.2.6.1.4. Process- or standard-compliant:

1.2.6.1.5. Dynamic:

1.2.6.1.6. Consultative or directed:

1.2.6.1.7. Regression-averse:

1.2.6.1.8. There is no one best way

1.2.6.2. Factors to consider

1.2.6.2.1. Risks:

1.2.6.2.2. Skills:

1.2.6.2.3. Objectives:

1.2.6.2.4. Regulations:

1.2.6.2.5. Product:

1.2.6.2.6. Business:

1.3. 5.3 TEST PROGRESS MONITORING AND CONTROL

1.3.1. Glossary

1.3.1.1. defect density

1.3.1.1.1. The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points)

1.3.1.2. failure rate

1.3.1.2.1. The ratio of the number of failures of a given category to a given unit of measure, e.g. failures per unit of time, failures per number of transactions, failures per number of computer runs

1.3.1.3. test control

1.3.1.3.1. A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned

1.3.1.4. test coverage

1.3.1.4.1. The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite

1.3.1.5. test monitoring

1.3.1.5.1. A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned

1.3.1.6. test report

1.3.1.6.1. test summary report: A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria

1.3.1.6.2. test progress report: A document summarizing testing activities and results, produced at regular intervals, to report progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision to management

1.3.2. 5.3.1 Monitoring the progress of test activities

1.3.2.1. Test monitoring's purposes

1.3.2.1.1. Give the test team and the test manager feedback to guide and improve the testing and the project

1.3.2.1.2. Provide the project team with visibility about the test results

1.3.2.1.3. Measure the status of the testing, test coverage and test items against the exit criteria to determine whether the test work is done

1.3.2.1.4. Gather data for use in estimating future test efforts

1.3.2.2. small projects

1.3.2.2.1. gather test progress monitoring information manually using

1.3.2.3. large teams distributed projects long-term test efforts

1.3.2.3.1. data collection is aided by the use of automated tools

1.3.2.4. Metrics

1.3.2.4.1. ultra-reliable software

1.3.2.4.2. common metrics

1.3.3. 5.3.2 Reporting test status

1.3.3.1. variations driven by

1.3.3.1.1. the pref-erences of the testers and stakeholders

1.3.3.1.2. the needs and goals of the project

1.3.3.1.3. reg-ulatory requirements

1.3.3.1.4. time and money constraints

1.3.3.1.5. limitations of the tools available

1.3.3.2. Enables conclusions, recommendations, and decisions about how to guide the project forward

1.3.3.3. data gathering for test report (should be identified at test planning and preparation periods)

1.3.3.3.1. How will you assess the adequacy of the test objectives for a given test level and whether those objectives were achieved?

1.3.3.3.2. How will you assess the adequacy of the test approaches taken and whether they support the achievement of the project's testing goals?

1.3.3.3.3. How will you assess the effectiveness of the testing with respect to these objectives and approaches?

1.3.3.4. test summary report (at a key milestone or at the end of a test level)

1.3.3.4.1. The IEEE 829 Standard Test Summary Report Template

1.3.4. 5.3.3 Test control

1.3.4.1. guiding and corrective actions to try to achieve the best possible outcome for the project

1.4. 5.4 CONFIGURATION MANAGEMENT

1.4.1. Glossary

1.4.1.1. configuration management

1.4.1.1.1. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements

1.4.1.2. version control

1.4.1.2.1. configuration control: An element of configuration management, consisting of the evaluation, co-ordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification

1.4.2. Goals

1.4.2.1. Determe clearly what the items are that make up the software or system

1.4.2.1.1. source code

1.4.2.1.2. test scripts

1.4.2.1.3. third-party software

1.4.2.1.4. hardware

1.4.2.1.5. data

1.4.2.1.6. both development and test documentation

1.4.2.2. making sure that these items are managed carefully, thoroughly and attentively throughout the entire project and product life cycle

1.4.2.3. support the build process

1.4.2.4. to map what is being tested to the underlying files and components that make it up

1.4.2.4.1. report defects against something which is version controlled

1.4.2.5. transmittal report or release notes

1.4.3. Should be planned during the project planning stage

1.4.3.1. As the project proceeds

1.4.3.1.1. the configuration process and mechanisms must be implemented

1.4.3.1.2. the key interfaces to the rest of the development process should be documented

1.4.4. IEEE 829 STANDARD: TEST ITEM TRANSMITTAL REPORT TEMPLATE

1.5. 5.5 RISK AND TESTING (5.5 РИСК И ИСПЫТАНИЯ)

1.5.1. Glossary(Глоссарий)

1.5.1.1. product risk(Риск продукта)

1.5.1.1.1. A risk directly related to the test object (Риск, непосредственно связанный с объектом тестирования)

1.5.1.2. project risk(Проектный риск)

1.5.1.2.1. A risk related to management and control of the (test) project, e.g. lack of staffing, strict deadlines, changing requirements, etc (Риск, связанный с управлением и контролем (тестового) проекта, например. Нехватка персонала, жесткие сроки, изменяющиеся требования и т. Д.)

1.5.1.3. risk(Риск)

1.5.1.3.1. A factor that could result in future negative consequences; usually expressed as impact and likelihood (Фактор, который может привести к будущим негативным последствиям, обычно выражается как воздействие и вероятность)

1.5.1.4. risk-based testing(Тестирование на основе риска)

1.5.1.4.1. An approach to testing to reduce the level of product risks and inform stakeholders of their status, starting in the initial stages of a project.It involves the identification of product risks and the use of risk levels to guide the test process (Подход к тестированию для снижения уровня рисков продукта и информирование заинтересованных сторон об их статусе, начиная с начальных этапов проекта. Он включает в себя идентификацию рисков продукта и использование уровней риска для руководства процессом тестирования)

1.5.2. 5.5.1 Risks and levels of risk (5.5.1 Риски и уровни риска)

1.5.2.1. Risk is the possibility of a negative or undesirable outcome (Риск - это возможность отрицательного или нежелательного результата)

1.5.3. 5.5.2 Product risks 'quality risks' (5.5.2 Риски качества рисков,)

1.5.3.1. Possibility that the system or software might fail to satisfy some reasonable customer, user, or stakeholder expectation (Возможность того, что система или программное обеспечение могут не удовлетворять ожидаемым ожиданиям клиентов, пользователей или заинтересованных лиц)

1.5.3.2. Risk-based testing (Тестування на основі ризику)

1.5.3.2.1. starts early in the project, identifying risks to system quality (Починається на початку проекту, визначаючи ризики для якості системи)

1.5.3.2.2. guide testing planning, specification, preparation and execution (Керівництво тестування планування, специфікації, підготовки та виконання)

1.5.3.2.3. involves both mitigation (Передбачає як пом'якшення наслідків)

1.5.3.2.4. involves measuring how well we are doing at finding and removing defects in critical areas (Включає в себе вимірювання того, наскільки добре ми робимо при пошуку та усуненні дефектів в критичних областях)

1.5.3.2.5. involve using risk analysis to identify proactive opportunities to remove or prevent defects through non-testing activities and to help us select which test activities to perform (Залучати використання аналізу ризику для визначення активних можливостей для усунення або запобігання дефектам через неперевірені заходи та допомогти нам вибрати, які тестові заходи виконувати)

1.5.3.2.6. product risk analysis techniques (Методи аналізу ризику продукту)

1.5.3.2.7. risks in the areas (Ризики в цих сферах)

1.5.3.2.8. a checklist of typical or past risks that should be considered (Контрольный список типичных или прошлых рисков, которые следует учитывать)

1.5.3.2.9. review the tests that failed and the bugs that you found in a previous release or a similar product (Контрольный список типичных или прошлых рисков, которые следует учитывать)

1.5.3.2.10. A five-point scale to rate likelihood and impact vary tends to work well (Пятиточечная шкала для оценки вероятности и влияния варьируется, как правило, хорошо работает)

1.5.3.2.11. Tips (Советы)

1.5.3.2.12. Untitled

1.5.4. 5.5.3 Project risks (5.5.3. Проектные риски)

1.5.4.1. Examples of possible risks (Примеры возможных рисков)

1.5.4.1.1. the late delivery of the test items to the est team (Поздняя доставка тестовых предметов в лучшую команду)

1.5.4.1.2. availability issues with the test environment (Проблемы доступности с тестовой средой)

1.5.4.1.3. excessive delays in repairing defects found in testing (Чрезмерные задержки в устранении дефектов, обнаруженных при тестировании)

1.5.4.1.4. problems with getting professional system administration support for the test environment. (Проблемы с получением профессиональной поддержки системного администрирования для тестовой среды.)

1.5.4.2. 4 typical options of risks: (4 типичных варианта рисков:)

1.5.4.2.1. Mitigate: Take steps in advance to reduce the likelihood (and possibly the impact) of the risk (Смягчение: предпримите шаги, чтобы уменьшить вероятность (и, возможно, влияние) риска)

1.5.4.2.2. Contingency: Have a plan in place to reduce the impact should the risk become an outcome (Непредвиденные обстоятельства: иметь план для уменьшения воздействия, если риск станет результатом)

1.5.4.2.3. Transfer: Convince some other member of the team or project stakeholder to reduce the likelihood or accept the impact of the risk (Передача: Убедить другого члена группы или участника проекта уменьшить вероятность или принять влияние риска)

1.5.4.2.4. Ignore: Do nothing about the risk, which is usually a smart option only when there's little that can be done or when the likelihood and impact are low (Игнорируйте: не делайте ничего о риске, который обычно является умным вариантом только тогда, когда мало что можно сделать или когда вероятность и влияние низки)

1.5.4.3. typical risks(Типичные риски)

1.5.4.3.1. Logistics or product quality problems that block tests: (Проблемы с логистикой или качеством продукта, которые блокируют тесты:)

1.5.4.3.2. Test items that won't install in the test environment: (Тестовые элементы, которые не будут установлены в тестовой среде:)

1.5.4.3.3. Excessive change to the product that invalidates test results or requires updates to test cases, expected results and environments: (Чрезмерное изменение продукта, которое отменяет результаты теста или требует обновлений для проверки случаев, ожидаемых результатов и сред:)

1.5.4.3.4. Insufficient or unrealistic test environments that yield misleading results: (Недостаточные или нереалистичные тестовые среды, которые приводят к ошибочным результатам:)

1.5.4.4. additional risks(Дополнительные риски)

1.5.4.4.1. Organizational issues such as shortages of people, skills or training, problems with communicating and responding to test results, bad expectations of what testing can achieve and complexity of the project team or organization (Организационные проблемы, такие как нехватка людей, навыки или обучение, проблемы с сообщением и ответом на результаты тестирования, плохие ожидания того, что может пройти тестирование, и сложность проектной команды или организации)

1.5.4.4.2. Supplier issues such as problems with underlying platforms or hardware, failure to consider testing issues in the contract or failure to properly respond to the issues when they arise (Проблемы поставщика, такие как проблемы с базовыми платформами или оборудованием, неспособность рассмотреть проблемы с тестированием в контракте или неспособность должным образом реагировать на возникающие проблемы)

1.5.4.4.3. Technical problems related to ambiguous, conflicting or unprioritized requirements, an excessively large number of requirements given other project constraints, high system complexity and quality problems with the design, the code or the tests (Технические проблемы, связанные с двусмысленными, противоречивыми или непривилегированными требованиями, чрезмерно большое количество требований, учитывая другие ограничения проекта, высокую сложность системы и проблемы с качеством при проектировании, коде или испытаниях)

1.5.4.5. test items can also have risks, e.g.:(Контрольные предметы также могут иметь риски, например:)

1.5.4.5.1. the test plan will omit tests for a functional area (В плане тестирования будут отсутствовать тесты для функциональной области)

1.5.4.5.2. that the test cases do not exercise the critical areas of the system (Что в тестовых случаях не выполняются критические области системы)

1.5.5. 5.5.4 Tying it all together for risk management (5.5.4. Связывание всего этого для управления рисками)

1.5.5.1. assess or analyze risks early in the project (Оценивать или анализировать риски на раннем этапе проекта)

1.5.5.2. educated guesses (Образованные догадки)

1.5.5.3. Do not confuse impact with likelihood or vice versa (Не путайте влияние с вероятностью или наоборот)

1.6. 5.6 INCIDENT MANAGEMENT (5.6 УПРАВЛЕНИЕ ИНЦИДЕНТАМИ)

1.6.1. Glossary(Глоссарий)

1.6.1.1. incident logging(Ведение каротажа)

1.6.1.1.1. Recording the details of any incident that occurred, e.g. during testing (Запись сведений о любом инциденте, который произошел, например. Во время тестирования)

1.6.2. 5.6.1 What are incident reports for and how do I write good ones? (5.6.1 Что такое отчеты об инцидентах и как писать хорошие?)

1.6.2.1. causes(Причины)

1.6.2.1.1. the system exhibits questionable behavior (Система проявляет сомнительное поведение)

1.6.2.1.2. a defect only when the root cause is some problem in tested item (Дефект только тогда, когда основной причиной является некоторая проблема в тестируемом элементе)

1.6.2.1.3. misconfiguration or failure of the test environment (Неправильная настройка или сбой тестовой среды)

1.6.2.1.4. corrupted test data (Поврежденные данные теста)

1.6.2.1.5. bad tests(Плохие тесты)

1.6.2.1.6. invalid expected results (Недопустимые ожидаемые результаты)

1.6.2.1.7. tester(Тестер)

1.6.2.1.8. mistakes(Ошибки)

1.6.2.2. defect detection percentage (DDP) metric (Показатель процента обнаружения дефектов (DDP))

1.6.3. 5.6.2 What goes in an incident report? (5.6.2 Что входит в отчет об инциденте?)

1.6.4. 5.6.3 What happens to incident reports after you file them? (5.6.3 Что происходит с отчетами об инцидентах после их публикации?)

2. 6. Tool support for testing(Поддержка инструмента для тестирования)

2.1. Glossary

2.1.1. debugging tool

2.1.1.1. A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step, to halt a program at any program statement and to set and examine program variables

2.1.2. driver

2.1.2.1. A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system

2.1.3. stub

2.1.3.1. A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component

2.1.4. probe effect

2.1.4.1. The effect on the component or system by the measurement instrument when the component or system is being measured, e.g. by a performance testing tool or monitor. For example performance may be slightly worse when performance testing tools are being used

2.1.5. data-driven testing

2.1.5.1. A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playback tools

2.1.6. keyword-driven testing

2.1.6.1. A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script for the test

2.1.7. scripting language

2.1.7.1. A programming language in which executable test scripts are written, used by a test execution tool (e.g. a capture/playback tool)

2.2. Types of tools

2.2.1. test execution tools

2.2.2. performance testing tools

2.2.3. static analysis tools

2.2.4. test management tools

2.3. 6.1 TYPES OF TEST TOOL

2.3.1. 'probe effect'

2.3.1.1. 'instrumenting the code'

2.3.1.1.1. different coverage tools get a slightly different coverage measure on the same program

2.3.1.2. 'Heizenbugs'

2.3.1.2.1. If the code is run with the debugger, then the bug disappears

2.3.2. 6.1.2 Tool support for management of testing and tests

2.3.2.1. Also known as:

2.3.2.1.1. 'the management of tests'

2.3.2.1.2. 'managing the testing process'

2.3.2.2. Test management tools

2.3.2.2.1. Features or characteristics

2.3.2.3. Requirements management tools

2.3.2.3.1. Features or characteristics

2.3.2.4. Incident management tools

2.3.2.4.1. also known as

2.3.2.4.2. Features or characteristics

2.3.2.5. Configuration management tools

2.3.2.5.1. Features or characteristics

2.3.3. 6.1.3 Tool support for static testing

2.3.3.1. Review process support tools

2.3.3.1.1. a common reference for the review process or processes to use in different situations

2.3.3.1.2. storing and sorting review comments

2.3.3.1.3. communicating comments to relevant people

2.3.3.1.4. coordinating online reviews

2.3.3.1.5. keeping track of comments, including defects found, and providing statistical information about them

2.3.3.1.6. providing traceability between comments, documents reviewed and related documents

2.3.3.1.7. a repository for rules, procedures and checklists to be used in reviews, as well as entry and exit criteria

2.3.3.1.8. monitoring the review status (passed, passed with corrections, requires re- review)

2.3.3.1.9. collecting metrics and reporting on key factors

2.3.3.2. Static analysis tools (D) *D - likely to be used by developers

2.3.3.2.1. calculate metrics such as cyclomatic complexity or nesting levels (which can help to identify where more testing may be needed due to increased risk)

2.3.3.2.2. enforce coding standards

2.3.3.2.3. analyze structures and dependencies

2.3.3.2.4. aid in code understanding

2.3.3.2.5. identify anomalies or defects in the code

2.3.3.3. Modeling tools (D)

2.3.3.3.1. identifying inconsistencies and defects within the model

2.3.3.3.2. helping to identify and prioritize areas of the model for testing

2.3.3.3.3. predicting system response and behavior under various situations, such as level of load

2.3.3.3.4. helping to understand system functions and identify test conditions using a modeling language such as UML

2.3.4. 6.1.4 Tool support for test specification

2.3.4.1. Test design tools

2.3.4.1.1. Types of tools

2.3.4.1.2. Features or characteristics

2.3.4.2. Test data preparation tools

2.3.4.2.1. enable data to be selected from an existing data-base or created, generated, manipulated and edited for use in tests

2.3.4.2.2. The most sophisticated tools can deal with a range of files and database formats

2.3.4.2.3. Features or characteristics

2.3.5. 6.1.5 Tool support for test execution and logging

2.3.5.1. Test execution tools

2.3.5.1.1. 'test running tool' or 'regression testing tools'

2.3.5.1.2. 'capture/playback' tools or 'capture/replay' tools or 'record/playback' tools

2.3.5.1.3. using programming skills

2.3.5.1.4. Features or characteristics

2.3.5.2. Test harness/unit test framework tools (D)

2.3.5.2.1. test harness

2.3.5.2.2. unit test framework tools

2.3.5.2.3. Features or characteristics

2.3.5.3. Test comparators

2.3.5.3.1. Dynamic comparison

2.3.5.3.2. Post-execution comparison

2.3.5.3.3. Features or characteristics

2.3.5.4. Coverage measurement tools (D)

2.3.5.4.1. component testing level coverage items

2.3.5.4.2. component integration testing level coverage items

2.3.5.4.3. system testing level

2.3.5.4.4. acceptance testing levels

2.3.5.4.5. Features or characteristics

2.3.5.5. Security tools

2.3.5.5.1. may focus on:

2.3.5.5.2. Features or characteristics

2.3.6. 6.1.6 Tool support for performance and monitoring

2.3.6.1. Dynamic analysis tools (D)

2.3.6.1.1. detecting memory leaks

2.3.6.1.2. identifying pointer arithmetic errors such as null pointers

2.3.6.1.3. identifying time dependencies

2.3.6.1.4. Broken links research 'web spider'

2.3.6.2. Performance-testing, load-testing and stress-testing tools

2.3.6.2.1. Performance-testing tools

2.3.6.2.2. 'load' test

2.3.6.2.3. 'volume' test

2.3.6.2.4. 'stress' test

2.3.6.2.5. Features or characteristics

2.3.6.3. Monitoring tools

2.3.6.3.1. For:

2.3.6.3.2. Features or characteristics

2.3.7. 6.1.7 Tool support for specific application areas (Kl)

2.3.7.1. web-based performance-testing tools

2.3.7.2. performance-testing tools for back-office systems

2.3.7.3. static analysis tools for specific development platforms and programming languages

2.3.7.4. dynamic analysis tools that focus on security issues

2.3.7.5. dynamic analysis tools for embedded systems

2.3.8. 6.1.8 Tool support using other tools

2.3.8.1. word processor

2.3.8.2. spreadsheet

2.3.8.3. SQL

2.3.8.4. debugging tools

2.4. 6.2 EFFECTIVE USE OF TOOLS: POTENTIAL BENEFITS AND RISKS

2.4.1. 6.2.1 Potential benefits of using tools

2.4.1.1. Benefits

2.4.1.1.1. reduction of repetitive work

2.4.1.1.2. greater consistency and repeatability

2.4.1.1.3. objective assessment

2.4.1.1.4. ease of access to information about tests or testing

2.4.1.2. Examples of repetitive work

2.4.1.2.1. running regression tests

2.4.1.2.2. entering the same test data

2.4.1.2.3. checking against coding standards

2.4.1.2.4. creating a specific test database

2.4.1.3. Examples of beneficial usage of tools

2.4.1.3.1. to confirm the correctness of a fix to a defect (a debugging tool or test execution tool)

2.4.1.3.2. enter-ing test inputs (a test execution tool)

2.4.1.3.3. generating tests from requirements (a test design tool or possibly a requirements management tool)

2.4.1.3.4. assessing the cyclomatic complexity or nesting levels of a component (a static analysis tool)

2.4.1.3.5. coverage (coverage measurement tool)

2.4.1.3.6. system behavior (monitoring tools)

2.4.1.3.7. incident statistics (test management tool)

2.4.1.3.8. statistics and graphs about test progress (test execution or test management tool)

2.4.1.3.9. incident rates (incident management or test management tool)

2.4.1.3.10. performance (performance testing tool)

2.4.2. 6.2.2 Risks of using tools

2.4.2.1. Risks include:

2.4.2.1.1. unrealistic expectations for the tool

2.4.2.1.2. underestimating the time, cost and effort for the initial introduction of a tool

2.4.2.1.3. underestimating the time and effort needed to achieve significant and con tinuing benefits from the tool

2.4.2.1.4. underestimating the effort required to maintain the test assets generated by the tool

2.4.2.1.5. over-reliance on the tool

2.4.2.2. Two other important factors are:

2.4.2.2.1. the skill needed to create good tests

2.4.2.2.2. the skill needed to use the tools well, depending on the type of tool

2.4.3. 6.2.3 Special considerations for some types of tools

2.4.3.1. Test execution tools

2.4.3.1.1. levels of scripting

2.4.3.1.2. Reasons why a captured test (a linear script) is not a good solution:

2.4.3.1.3. when capturing test inputs is useful

2.4.3.2. Performance testing tools

2.4.3.2.1. Examples

2.4.3.2.2. Issues

2.4.3.3. Static analysis tools

2.4.3.4. Test management tools

2.5. 6.3 INTRODUCING A TOOL INTO AN ORGANIZATION

2.5.1. 6.3.1 Main principles

2.5.1.1. Factors in selecting a tool:

2.5.1.1.1. assessment of the organization's maturity (e.g. readiness for change)

2.5.1.1.2. identification of the areas within the organization where tool support will help to improve testing processes

2.5.1.1.3. evaluation of tools against clear requirements and objective criteria

2.5.1.1.4. proof-of-concept to see whether the product works as desired and meets the requirements and objectives defined for it

2.5.1.1.5. evaluation of the vendor (training, support and other commercial aspects) or open-source network of support

2.5.1.1.6. identifying and planning internal implementation (including coaching and mentoring for those new to the use of the tool)

2.5.2. 6.3.2 Pilot project

2.5.2.1. should experiment with different ways of using the tool

2.5.2.1.1. different settings for a static analysis tool

2.5.2.1.2. different reports from a test management tool

2.5.2.1.3. differ-ent scripting and comparison techniques for a test execution tool

2.5.2.1.4. different load profiles for a performance-testing tool

2.5.2.2. The objectives for a pilot project for a new tool are:

2.5.2.2.1. to learn more about the tool (more detail, more depth)

2.5.2.2.2. to see how the tool would fit with existing processes or documentation, how those would need to change to work well with the tool and how to use the tool to streamline existing processes

2.5.2.2.3. to decide on standard ways of using the tool that will work for all potential users, e.g.:

2.5.3. 6.3.3 Success factors

2.5.3.1. incremental roll-out (after the pilot) to the rest of the organization

2.5.3.2. adapting and improving processes, testware and tool artefacts to get the best fit and balance between them and the use of the tool

2.5.3.3. providing adequate training, coaching and mentoring of new users

2.5.3.4. defining and communicating guidelines for the use of the tool, based on what was learned in the pilot

2.5.3.5. implementing a continuous improvement mechanism as tool use spreads through more of the organization

2.5.3.6. monitoring the use of the tool and the benefits achieved and adapting the use of the tool to take account of what is learned

2.6. CHAPTER REVIEW

2.6.1. Section 6.1

2.6.1.1. Tools that support the management of testing and tests:

2.6.1.1.1. test management tool

2.6.1.1.2. requirements management tool

2.6.1.1.3. incident management tool

2.6.1.1.4. configuration management tool

2.6.1.2. Tools that support static testing:

2.6.1.2.1. review process support tool

2.6.1.2.2. static analysis tool (D)

2.6.1.2.3. modeling tool (D)

2.6.1.3. Tools that support test specification:

2.6.1.3.1. test design tool

2.6.1.3.2. test data preparation tool

2.6.1.4. Tools that support test execution and logging:

2.6.1.4.1. test execution tool

2.6.1.4.2. test harness and unit test framework tool (D)

2.6.1.4.3. test comparator

2.6.1.4.4. coverage measurement tool (D)

2.6.1.4.5. security tool

2.6.1.5. Tools that support performance and monitoring:

2.6.1.5.1. dynamic analysis tool

2.6.1.5.2. performance-testing, load-testing and stress-testing tool

2.6.1.5.3. monitoring tool

2.6.2. Section 6.3

2.6.2.1. main principles of introducing a tool into an organization, e.g.:

2.6.2.1.1. assessing organizational maturity

2.6.2.1.2. clear requirements and objective criteria

2.6.2.1.3. proof-of-concept

2.6.2.1.4. vendor evaluation

2.6.2.1.5. coaching and mentoring

2.6.2.2. goals of a proof-of-concept or piloting phase for tool evaluation. e.g.:

2.6.2.2.1. learn about the tool

2.6.2.2.2. assess fit with current practices

2.6.2.2.3. decide on standards

2.6.2.2.4. assess benefits

2.6.2.3. Factors important for success, e.g.:

2.6.2.3.1. incremental roll-out

2.6.2.3.2. adapting processes

2.6.2.3.3. training and coaching

2.6.2.3.4. defining usage guidelines

2.6.2.3.5. learning lessons

2.6.2.3.6. monitoring benefits

3. Books(Книги)

3.1. Myers

3.2. Copeland

3.3. Kaner

3.4. Rex Black

4. Floating Topic

5. Contract acceptance testing (Приемочные испытания)

5.1. performed against a contract's acceptance criteria for producing custom-developed software (Выполненных в соответствии с критериями приемлемости контракта для производства специализированного программного обеспечения)

6. security testing(Тестирование безопасности)

6.1. Testing to determine the security of the software product (Тестирование для определения безопасности программного продукта)

7. 1. Fundamentals (Основы)

7.1. Test Principles(Принципы тестирования)

7.1.1. 1. Testing is context dependent - Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.(Тестирование зависит от контекста. Тестирование выполняется по-разному в разных контекстах. Например, критичное для безопасности программное обеспечение проверяется по-разному с сайтом электронной коммерции.)

7.1.2. 2. Exhaustive testing is impossible - Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.(Исчерпывающее тестирование невозможно. Тестирование всего (всех комбинаций входов и предварительных условий) невозможно, кроме тривиальных случаев. Вместо исчерпывающего тестирования мы используем риски и приоритеты для фокусировки усилий по тестированию.)

7.1.3. 3. Early testing - Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives. (Раннее тестирование. Тестирование должно начинаться как можно раньше в жизненном цикле программного обеспечения или разработки системы и должно быть сфокусировано на определенных задачах.)

7.1.4. 4. Defect clustering - A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures. (Дефектная кластеризация. Небольшое количество модулей содержат большинство дефектов, обнаруженных во время предварительного тестирования, или показывают наиболее оперативные сбои.)

7.1.5. 5. Pesticide paradox - If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects. (Парадокс пестицидов. Если одни и те же тесты повторяются снова и снова, в конечном итоге тот же набор тестовых примеров больше не будет обнаруживать никаких новых ошибок. Чтобы преодолеть этот «парадокс пестицидов», тестовые сценарии необходимо регулярно пересматривать и пересматривать, а новые и различные тесты должны быть написаны для использования различных частей программного обеспечения или системы, чтобы потенциально обнаружить больше дефектов.)

7.1.6. 6. Testing shows presence of defects - Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness. (Тестирование показывает наличие дефектов. Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов нет. Тестирование снижает вероятность обнаружения неоткрытых дефектов в программном обеспечении, но даже если дефектов не обнаружено, это не является доказательством правильности.)

7.1.7. 7. Absence of errors fallacy - Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations (Отсутствие ошибок - Поиск и устранение дефектов не помогает, если построенная система непригодна для использования и не отвечает потребностям и ожиданиям пользователей)

7.2. Problems(Проблемы)

7.2.1. Mistakes (see error)(Ошибки (см. Ошибку))

7.2.1.1. Error: A human action that produces an incorrect result. (Ошибка: человеческое действие, которое приводит к неправильному результату.)

7.2.1.1.1. Defect: A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system. (Дефект: дефект в компоненте или системе, который может привести к тому, что компонент или система не смогут выполнить требуемую функцию, например. Неправильное утверждение или определение данных. Дефект, если он встречается во время выполнения, может привести к сбою компонента или системы.)

7.2.2. Causes:(Причины:)

7.2.2.1. errors in the specification, design and implementation of the software and system (Ошибки в спецификации, проектирование и внедрение программного обеспечения и системы)

7.2.2.2. errors in use of the system(Ошибки в использовании системы)

7.2.2.3. environmental conditions(условия окружающей среды)

7.2.2.4. intentional damage(Умышленное повреждение)

7.2.2.5. potential consequences of earlier errors, intentional damage, defects and failures (Потенциальные последствия более ранних ошибок, умышленных повреждений, дефектов и сбоев)

7.3. Test Process(Процесс тестирования)

7.3.1. planning and control(Планирование и контроль)

7.3.1.1. Project and test plans should include time to be spent on planning the tests, designing test cases, preparing for execution and evaluating status (Планы проекта и тестирования должны включать время, затрачиваемое на планирование тестов, разработку тестовых примеров, подготовку к выполнению и оценку состояния)

7.3.1.2. test policies(Тестовые политики)

7.3.1.2.1. gives rules for testing, e.g. 'we always review the design documents'(Дает правила для тестирования, например. 'Мы всегда рассматриваем проектные документы')

7.3.1.3. test strategy(Стратегия тестирования)

7.3.1.3.1. test strategy is the overall high-level approach, e.g. 'system testing is carried out by an independent team reporting to the program quality manager. It will be risk-based and proceeds from a product (quality) risk analysis' (Стратегия тестирования - это общий подход на высоком уровне, например. «Системное тестирование проводится независимой командой, подчиняющейся менеджеру качества программы. Он будет основан на рисках и будет исходить из анализа риска продукта (качества))

7.3.1.4. Test planning tasks(Задачи планирования тестирования)

7.3.1.4.1. Determine the scope and risks and identify the objectives of testing(Определите масштаб и риски и определите цели тестирования)

7.3.1.4.2. Determine the test approach (techniques, test items, coverage, identifying and interfacing with the teams involved in testing, testware) (Определите подход к тестированию (методы, элементы тестирования, покрытие, выявление и взаимодействие с командами, участвующими в тестировании, тестировании))

7.3.1.4.3. Implement the test policy and/or the test strategy(Внедрение тестовой политики и / или стратегии тестирования)

7.3.1.4.4. Determine the required test resources (e.g. people, test environment, PCs) (Определите необходимые тестовые ресурсы (например, людей, тестовую среду, ПК))

7.3.1.4.5. Schedule test analysis and design tasks, test implementation, execution and evaluation (Запланировать анализ и задачи тестирования, выполнить тест, выполнить и оценить)

7.3.1.4.6. Determine the exit criteria: we need to set criteria such as coverage criteria (for example, the percentage of statements in the software that must be executed during testing)

7.3.1.5. Test control tasks (ongoing) (Задачи тестового контроля (текущие))

7.3.1.5.1. Measure and analyze the results of reviews and testing(Измерять и анализировать результаты обзоров и тестирования)

7.3.1.5.2. Monitor and document progress, test coverage and exit criteria(Мониторинг и документирование прогресса, охват тестированием и критерии выхода)

7.3.1.5.3. Provide information on testing(Предоставить информацию о тестировании)

7.3.1.5.4. Initiate corrective actions(Инициировать корректирующие действия)

7.3.1.5.5. Make decisions(Принимать решения)

7.3.2. analysis and design(Анализ и проектирование)

7.3.2.1. Review the test basis (such as the product risk analysis, requirements, archi tecture, design specifications, and interfaces), examining the specifications (Просмотрите тестовую основу (например, анализ риска продукта, требования, архитектуру, спецификации проекта и интерфейсы), изучив спецификации)

7.3.2.2. Identify test conditions based on analysis of test items, their specifications, and what we know about their behavior and structure (Определить условия тестирования на основе анализа тестовых элементов, их спецификаций и того, что мы знаем о их поведении и структуре)

7.3.2.3. Design the tests using techniques to help select representative tests based on the test conditions (Разработайте тесты с использованием методов, которые помогут выбрать типичные тесты на основе условий тестирования)

7.3.2.4. Evaluate testability of the requirements and system(Оценить проверяемость требований и системы)

7.3.2.5. Design the test environment set-up and identify any required infrastructure and tools. (Создайте среду тестовой среды и определите всю необходимую инфраструктуру и инструменты.)

7.3.3. implementation and execution(Внедрение и выполнение)

7.3.3.1. Implementation tasks(Задачи по внедрению)

7.3.3.1.1. Develop and prioritize our test cases, using the techniques, and create test data for those tests

7.3.3.1.2. Create test suites from the test cases for efficient test execution

7.3.3.1.3. Implement and verify the environment

7.3.3.2. Execution tasks(Выполнение задач)

7.3.3.2.1. Execute the test suites and individual test cases, following test procedures (Выполнение наборов тестов и отдельных тестовых примеров, следуя процедурам тестирования.)

7.3.3.2.2. Log the outcome of test execution and record the identities and versions of the software under test, test tools and testware: report defects, test logs, etc. (Записывать результаты выполнения теста и записывать идентификационные данные и версии тестируемого программного обеспечения, инструментов тестирования и тестового ПО: отчеты о дефектах, журналах испытаний и т. Д.)

7.3.3.2.3. Compare actual results with expected results(Сравнить фактические результаты с ожидаемыми результатами)

7.3.3.2.4. report discrepancies as incidents(Сообщать о несоответствиях как инцидентах)

7.3.3.2.5. Repeat test activities as a result of action taken for each discrepancy (Повторите действия теста в результате действий, предпринятых для каждого несоответствия.)

7.3.4. evaluating exit criteria and reporting (should be set and evaluated for each test level) (Оценка критериев выхода и отчетности (должны быть установлены и оценены для каждого уровня тестирования))

7.3.4.1. Check test logs against the exit criteria specified in test planning

7.3.4.2. Assess if more tests are needed or if the exit criteria specified should be changed

7.3.4.3. Write a test summary report for stakeholders

7.3.5. test closure activities(Тестирование закрытия)

7.3.5.1. Check which planned deliverables we actually delivered and ensure all incident reports have been resolved through defect repair or deferral (open); document the-acceptance or rejection of the software system (Проверить, какие запланированные результаты мы фактически поставили и обеспечить, чтобы все отчеты об инцидентах были устранены путем восстановления или отсрочки дефектов (открыты);Документировать принятие или отклонение программного обеспечения)

7.3.5.2. Finalize and archive testware, such as scripts, the test environment, and any other test infrastructure, for later reuse (Завершать и архивировать тестовое ПО, например сценарии, тестовую среду и любую другую тестовую инфраструктуру, для последующего повторного использования)

7.3.5.3. Hand over testware to the maintenance organization(Передайте тестовую программу в организацию обслуживания)

7.3.5.4. Evaluate how the testing went and analyze lessons learned for future releases and projects (Оцените, как проходило тестирование, и проанализируйте уроки, извлеченные для будущих выпусков и проектов.)

7.4. Test Process glossary(Глоссарий процесса тестирования)

7.4.1. Confirmation testing(Проверка подтверждения)

7.4.1.1. re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions. (Re-testing: Тестирование, которое запускает тестовые примеры, которые не были выполнены в последний раз, когда они были запущены, чтобы проверить успешность корректирующих действий.)

7.4.2. Exit criteria(Критерии выхода)

7.4.2.1. The set of generic and specific conditions, agreed upon with the stakeholders,(Набор общих и конкретных условий, согласованных с заинтересованными сторонами,)

7.4.2.2. for permitting a process to be officially completed. The purpose of exit criteria is to(За разрешение официального завершения процесса. Цель критериев выхода состоит в том, чтобы)

7.4.2.3. prevent a task from being considered completed when there are still outstanding parts of(предотвратить задачи из рассмотренных завершенным, когда все еще есть выдающиеся части)

7.4.2.4. the task which have not been finished. Exit criteria are used to report against and to plan (Задача, которая не была завершена. Критерии выхода используются для отчета и планирования)

7.4.2.5. when to stop testing(Когда прекращать тестирование)

7.4.3. Incident(Инцидент)

7.4.3.1. Any event occurring that requires investigation(Любое событие, которое требует расследования)

7.4.4. Regression testing(Регрессионное тестирование)

7.4.4.1. Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed (Тестирование ранее протестированной программы после внесения изменений, чтобы гарантировать, что дефекты не были обнаружены или обнаружены в неизмененных областях программного обеспечения в результате внесенных изменений. Это выполняется при изменении программного обеспечения или его окружения)

7.4.5. Test basis(Испытательная база)

7.4.5.1. All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis Все документы, из которых могут быть выполнены требования компонента или системы.Документация, на которой основаны тестовые примеры. Если документ может быть изменен только посредством формальной процедуры внесения поправок, то тестовая база называется замороженной тестовой основой

7.4.6. Test condition(Состояние испытания)

7.4.6.1. An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element (Элемент или событие компонента или системы, которые могут быть проверены одним или несколькими тестовыми примерами, например. Функция, транзакция, свойство, атрибут качества или структурный элемент)

7.4.7. Test coverage(Тестовое покрытие)

7.4.7.1. The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite (Степень, выраженная в процентах, к которой указанная статья покрытия была выполнена с помощью набора тестов)

7.4.8. Test data(Тестовые данные)

7.4.8.1. Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test (Данные, которые существуют (например, в базе данных) перед выполнением теста,и который влияет на или зависит от компонента или системы, подвергаемой тестированию)

7.4.9. Test execution(Выполнение теста)

7.4.9.1. The process of running a test on the component or system under test, producing actual result(s) (Процесс запуска теста на тестируемом компоненте или системе, Получение фактического результата (результатов))

7.4.10. Test log(Журнал испытаний)

7.4.10.1. A chronological record of relevant details about the execution of tests(Хронологическая запись соответствующих сведений о выполнении тестов)

7.4.11. Test plan(План тестирования)

7.4.11.1. A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process (Документ, описывающий сферу охвата, подход, ресурсы И график запланированных тестовых мероприятий. Он идентифицирует, среди прочего, тестовые элементы, тестируемые функции, задачи тестирования, кто будет выполнять каждую задачу, степень независимости тестировщика, условия тестирования, методы тестирования теста и критерии входа и выхода, которые будут использоваться, и обоснование их использования Выбора и любых рисков, требующих планирования на случай непредвиденных обстоятельств. Это запись процесса планирования тестирования)

7.4.12. Test strategy(Стратегия тестирования)

7.4.12.1. A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects) (Высокоуровневое описание уровней теста, которые необходимо выполнить, и Тестирование на этих уровнях для организации или программы (один или несколько проектов))

7.4.13. Test summary report(Тест итоговый отчет)

7.4.13.1. A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria (Документ, обобщающий действия и результаты тестирования. Он также содержит оценку соответствующих контрольных пунктов против критериев выхода)

7.4.14. Testware

7.4.14.1. Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing (Артефакты, созданные во время процесса тестирования, необходимые для планирования, проектирования и выполнения тестов, таких как документация, сценарии, исходные данные, ожидаемые результаты, процедуры настройки и очистки, файлы, базы данных, среда и любое дополнительное программное обеспечение или утилиты, используемые в тестирование)

7.5. The psychology of testing(Психология тестирования)

7.5.1. Glossary(Глоссарий)

7.5.1.1. Independence(Независимость)

7.5.1.1.1. Separation of responsibilities, which encourages the accomplishment of objective testing (Разделение ответственности, что способствует проведению объективного тестирования)

7.5.2. Levels of(Уровни)

7.5.2.1. tests by the person who wrote the item under test(Тесты, выполненные лицом, написавшим тестируемый объект)

7.5.2.2. tests by another person within the same team, such as another programmer(Тесты другого человека в той же команде, например, другого программиста)

7.5.2.3. tests by a person from a different organizational group, such as an independ ent test team (Тесты человека из другой организационной группы, например независимой тестовой группы)

7.5.2.4. tests designed by a person from a different-organization or company, such as outsourced testing or certification by an external body (Тесты, разработанные человеком из другой организации или компании, например аутсорсинг тестирования или сертификации внешним органом)

8. 2. Testing throughout the software life cycle(Тестирование на протяжении всего жизненного цикла программного обеспечения)

8.1. Glossary(Глоссарий)

8.1.1. Section 2.1

8.1.1.1. (Commercial) off-the-shelf software (COTS)((Коммерческое) готовое программное обеспечение (COTS))

8.1.1.1.1. A software product that is developed for the general market, i.e. for a large number of customers, and that is delivered to many customers in identical format(Программный продукт, который разрабатывается для общего рынка, то есть для большого числа клиентов, и который доставляется многим клиентам в идентичном формате)

8.1.1.2. incremental development model(Модель поэтапного развития)

8.1.1.2.1. A development lifecycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a ‘mini V-model’ with its own design, coding and testing phases(Жизненный цикл разработки, при котором проект разбивается на несколько приращений, каждый из которых обеспечивает часть функциональности в общих требованиях проекта. Требования распределяются по приоритетам и поставляются в порядке приоритетности с соответствующим шагом. В некоторых (но не во всех) версиях этой модели жизненного цикла каждый подпроект следует «мини-V-модели» со своей собственной фазой проектирования, кодирования и тестирования)

8.1.1.3. test level(Уровень тестирования)

8.1.1.3.1. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test(Группа тестовых действий, которые организуются и управляются вместе. Уровень теста связан с обязанностями в проекте. Примерами тестовых уровней являются компонентный тест, интеграционный тест, системный тест и приемочный тест)

8.1.1.4. validation(Валидация)

8.1.1.4.1. Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled(Подтверждение экспертизой и предоставление объективных доказательств того, что требования к конкретному предполагаемому использованию или применению выполнены)

8.1.1.5. verification(Верификация)

8.1.1.5.1. Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled(Подтверждение экспертизой и предоставление объективных доказательств того, что указанные требования выполнены)

8.1.1.6. V-model(V-модель)

8.1.1.6.1. A framework to describe the software development lifecycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development lifecycle(Основа для описания жизненного цикла разработки программного обеспечения от спецификации требований до обслуживания. V-модель иллюстрирует, как тестирование действий может быть интегрировано в каждую фазу жизненного цикла разработки программного обеспечения)

8.1.2. Section 2.2

8.1.2.1. alpha testing(Альфа-тестирование)

8.1.2.1.1. Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing (Моделируемое или фактическое оперативное тестирование потенциальными пользователями / клиентами или независимой группой тестирования на сайте разработчиков, но вне организации разработки. Альфа-тестирование часто используется для готового программного обеспечения как форма внутреннего приемочного тестирования)

8.1.2.2. beta testing(Бета-тестирование)

8.1.2.2.1. Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market (Оперативное тестирование потенциальными и / или существующими пользователями / клиентами на внешнем сайте, не связанное с разработчиками иным образом, для определения того, удовлетворяет ли компонент или система потребностям пользователей / клиентов и подходит ли он в рамках бизнес-процессов. Бета-тестирование часто используется как форма внешнего приемочного тестирования для готового программного обеспечения, чтобы получить обратную связь от рынка)

8.1.2.3. component testing(Компонентное тестирование)

8.1.2.3.1. The testing of individual software components (Тестирование отдельных программных компонентов)

8.1.2.4. driver(Драйвер)

8.1.2.4.1. A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system(Программный компонент или средство тестирования, которое заменяет компонент, который заботится о контроле и / или вызове компонента или системы)

8.1.2.5. functional requirements(функциональные требования)

8.1.2.5.1. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document (Условие или способность, необходимые пользователю для решения проблемы или достижения цели, которой должен удовлетворять системный компонент или системный компонент, чтобы удовлетворять договорному стандарту, спецификации или другому официально установленному документу)

8.1.2.6. integration(Интеграция)

8.1.2.6.1. The process of combining components or systems into larger assemblies(Процесс объединения компонентов или систем в более крупные сборки)

8.1.2.7. integration testing(Интеграционное тестирование)

8.1.2.7.1. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems (Тестирование, проведенное для выявления дефектов в интерфейсах и во взаимодействиях между интегрированными компонентами или системами)

8.1.2.8. non-functional testing (Нефункциональное тестирование)

8.1.2.8.1. Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability(Тестирование атрибутов компонента или системы, которые не связаны с функциональностью, например. Надежность, эффективность, удобство использования, ремонтопригодность и мобильность)

8.1.2.9. operational testing(Эксплуатационные испытания)

8.1.2.9.1. Testing conducted to evaluate a component or system in its operational environment (Тестирование, проведенное для оценки компонента или системы в рабочей среде)

8.1.2.10. regulation acceptance testing (compliance testing) (Приемочное испытание регулирования (тестирование соответствия))

8.1.2.10.1. The process of testing to determine the compliance of the component or system (Процесс тестирования для определения соответствия компонента или системы)

8.1.2.11. robustness testing(Испытание на прочность)

8.1.2.11.1. Testing to determine the robustness of the software product (Тестирование для определения надежности программного продукта)

8.1.2.12. stub(Oгрызок)

8.1.2.12.1. A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component(Скелетная или специальная реализация программного компонента, используемого для разработки или тестирования компонента, который вызывает или иным образом зависит от него. Он заменяет вызываемый компонент)

8.1.2.13. system testing(Системное тестирование)

8.1.2.13.1. The process of testing an integrated system to verify that it meets specified requirements(Процесс тестирования интегрированной системы, чтобы проверить, соответствует ли она определенным требованиям)

8.1.2.14. test-driven development(Разработка на основе тестов)

8.1.2.14.1. A way of developing software where the test cases are developed, and often automated, before the software is developed to run those test cases (Способ разработки программного обеспечения, в котором тестовые примеры разрабатываются и часто автоматизируются, до того, как программное обеспечение разработано для запуска этих тестовых примеров)

8.1.2.15. test environment(Тестовая среда)

8.1.2.15.1. An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test(Среда, содержащая аппаратные средства, контрольно-измерительные приборы, тренажеры, программные средства и другие элементы поддержки, необходимые для проведения теста)

8.1.2.16. user acceptance testing (Пользовательское приемочное тестирование)

8.1.2.16.1. Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system (Формальное тестирование в отношении потребностей пользователей, требований и бизнес-процессов, проводимых для определения того, удовлетворяет ли система критериям приемлемости и позволяет пользователю, клиентам или другому уполномоченному объекту определять, принимать ли систему)

8.1.3. Section 2.3

8.1.3.1. black-box testing(Тестирование черного ящика)

8.1.3.1.1. Testing, either functional or non-functional, without reference to the internal structure of the component or system (Тестирование, функциональное или нефункциональное, без ссылки на внутреннюю структуру компонента или системы)

8.1.3.2. code coverage(Покрытие кода)

8.1.3.2.1. An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage (Метод анализа, который определяет, какие части программного обеспечения были выполнены (покрыты) набором тестов и какие части не были выполнены, например. Покрытие заявлений, покрытие решений или покрытие условий)

8.1.3.3. confirmation testing (re-testing) (Подтверждение проверки (повторное тестирование))

8.1.3.4. functional testing(Функциональное тестирование)

8.1.3.4.1. Testing based on an analysis of the specification of the functionality of a component or system(Тестирование на основе анализа спецификации функциональных возможностей компонента или системы)

8.1.3.5. interoperability testing(Тестирование на совместимость)

8.1.3.5.1. The process of testing to determine the interoperability of a software product (Процесс тестирования для определения совместимости программного продукта)

8.1.3.6. load testing(Нагрузочное тестирование)

8.1.3.6.1. A type of performance testing conducted to evaluate the behavior of a component or system with increasing load, e.g. numbers of parallel users and/or numbers of transactions, to determine what load can be handled by the component or system (Тип тестирования производительности, проводимого для оценки поведения компонента или системы с увеличением нагрузки, например. Количество параллельных пользователей и / или количество транзакций, чтобы определить, какую нагрузку может обрабатывать компонент или система)

8.1.3.7. maintainability testing(Тестирование ремонтопригодности)

8.1.3.7.1. The process of testing to determine the maintainability of a software product(Процесс тестирования для определения ремонтопригодности программного продукта)

8.1.3.8. performance testing(Тестирование производительности)

8.1.3.8.1. The process of testing to determine the performance of a software product (Процесс тестирования для определения производительности программного продукта)

8.1.3.9. portability testing(Тестирование портативности)

8.1.3.9.1. The process of testing to determine the portability of a software product (Процесс тестирования для определения переносимости программного продукта)

8.1.3.10. regression testing(Регрессионное тестирование)

8.1.3.10.1. Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed (Тестирование ранее протестированной программы после внесения изменений, чтобы гарантировать, что дефекты не были обнаружены или обнаружены в неизмененных областях программного обеспечения в результате внесенных изменений. Это выполняется при изменении программного обеспечения или его окружения)

8.1.3.11. reliability testing(Тестирование надежности)

8.1.3.11.1. The process of testing to determine the reliability of a software product(Процесс тестирования для определения надежности программного продукта)

8.1.3.12. specification-based testing(Тестирование на основе спецификаций)

8.1.3.12.1. black box testing: Testing, either functional or non-functional, without reference to the internal structure of the component or system (Тестирование черного ящика: тестирование, функциональное или нефункциональное, без ссылки на внутреннюю структуру компонента или системы)

8.1.3.13. stress testing(Стресс-тестирование)

8.1.3.13.1. A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified work loads, or with reduced availability of resources such as access to memory or servers (Тип тестирования производительности, проводимого для оценки системы или компонента в пределах или за пределами ожидаемых или определенных рабочих нагрузок или с меньшей доступностью ресурсов, таких как доступ к памяти или серверам)

8.1.3.14. structural testing(Структурное тестирование)

8.1.3.14.1. white-box testing: Testing based on an analysis of the internal structure of the component or system (Тестирование белого ящика: тестирование на основе анализа внутренней структуры компонента или системы)

8.1.3.15. test suite(Набор тестов)

8.1.3.15.1. A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one. (Набор нескольких тестовых примеров для тестируемого компонента или системы, где условие отправки одного теста часто используется в качестве предварительного условия для следующего.)

8.1.3.16. usability testing (Тестирование юзабилити)

8.1.3.16.1. Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions (Тестирование для определения степени понимания программного продукта, его простоты в освоении, удобства в эксплуатации и привлекательности для пользователей в определенных условиях)

8.1.3.17. white-box testing(Тестирование белого ящика)

8.1.4. Section 2.4

8.1.4.1. impact analysis(Анализ воздействия)

8.1.4.2. maintenance testing (Тестирование обслуживание)

8.1.4.2.1. Testing the changes to an operational system or the impact of a changed environment to an operational system (Тестирование изменений операционной системы или влияния измененной среды на операционную систему)

8.2. SOFTWARE DEVELOPMENT MODELS (МОДЕЛИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ)

8.2.1. Glossary(Глоссарий)

8.2.1.1. Verification is concerned with evaluating a work product, component or system to determine whether it meets the requirements set. In fact, verification focuses on the question 'Is the deliverable built according to the specification?' (Проверка связана с оценкой продукта, компонента или системы работы, чтобы определить, соответствует ли она установленным требованиям. На самом деле, проверка фокусируется на вопросе «Является ли поставляемый Построен в соответствии со спецификацией? ')

8.2.1.2. Validation is concerned with evaluating a work product, component or system to determine whether it meets the user needs and requirements. Validation focuses on the question 'Is the deliverable fit for purpose, e.g. does it provide a solution to the problem?' (Валидация связана с оценкой продукта, компонента или системы работы, чтобы определить, отвечает ли она требованиям пользователя и требованиям. Валидация сосредотачивается на вопросе «Является ли поставляемая продукция пригодной для использования, например Это обеспечивает решение проблемы? ')

8.2.2. V-model

8.2.2.1. Test levels(Уровни тестирования)

8.2.2.1.1. component testing (Компонентное тестирование)

8.2.2.1.2. integration testing(Интеграционное тестирование)

8.2.2.1.3. system testing(Системное тестирование)

8.2.2.1.4. acceptance testing(приемочное тестирование)

8.2.3. Iterative life cycles(Итерационные циклы жизни)

8.2.3.1. incremental development models(Модели поэтапного развития)

8.2.3.1.1. prototyping

8.2.3.1.2. Rapid Application Development (RAD)

8.2.3.1.3. Rational Unified Process (RUP)

8.2.3.1.4. agile development

8.2.3.2. Example iteration(Пример итерации)

8.2.3.2.1. Define

8.2.3.2.2. Develop

8.2.3.2.3. Build

8.2.3.2.4. Test (increase each phase)

8.2.3.2.5. Implement

8.2.3.3. Testing within a life cycle model (Тестирование в модели жизненного цикла)

8.2.3.3.1. for every development activity there is a corresponding testing activity

8.2.3.3.2. each test level has test objectives specific to that level

8.2.3.3.3. the analysis and design of tests for a given test level should begin during the corresponding development activity

8.2.3.3.4. testers should be involved in reviewing documents as soon as drafts are avail able in the development cycle

8.3. Test levels(Уровни тестирования)

8.3.1. Component testing (unit) - module and program testing (e.g. modules, programs, objects, classes, etc.) that are separately testable (Компонентное тестирование (модуль) - тестирование модулей и программ (например, модули, программы, объекты, классы и т. Д.), Которые являются отдельными)

8.3.1.1. Stub - is called from the software component to be tested (Stub - вызывается из тестируемого программного компонента)

8.3.1.2. driver - calls a component to be tested (Driver - вызывает компонент для проверки)

8.3.1.3. resource-behavior (e.g. memory leaks) (Поведение ресурса (например, утечки памяти))

8.3.1.4. performance(Представление)

8.3.1.5. robustness(Прочность)

8.3.1.6. structural testing (e.g. decision coverage) (Структурное тестирование (например, покрытие решений))

8.3.1.7. In XP: test-first approach or test-driven development: prepare and automate test cases before coding (В XP: тест-первый подход или тест-ориентированная разработка: подготовить и автоматизировать тестовые сценарии перед кодированием)

8.3.2. Integration testing - tests interfaces between components,interactions to dif-ferent parts of a system or interfaces between systems (Тестирование интеграции - тестирование интерфейсов между компонентами, взаимодействие с различными частями системы или интерфейсов между системами)

8.3.2.1. component integration testing (Тестирование интеграции компонентов)

8.3.2.2. system integration testing(Тестирование системной интеграции)

8.3.2.3. Big-bang testing(Тестирование большого взрыва)

8.3.2.3.1. advantage: everything is finished before integration testing starts (Преимущество: все закончено, прежде чем начнется интеграционное тестирование)

8.3.2.3.2. disadvantage: in general it is time-consuming and difficult to trace the cause of failures(Недостаток: в целом отнимает много времени и трудно проследить причину сбоев)

8.3.2.4. Top-down: testing takes place from top to bottom, following the control flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems are substituted by stubs (Сверху вниз: тестирование проходит сверху вниз, следуя потоку управления или архитектурной структуре (например, начиная с GUI или главного меню). Компоненты или системы заменяются заглушками)

8.3.2.5. Bottom-up: testing takes place from the bottom of the control flow upwards. Components or systems are substituted by drivers. (Снизу: тестирование происходит снизу контрольного потока вверх. Компоненты или системы заменяются драйверами..)

8.3.2.6. Functional incremental: integration and testing takes place on the basis of the functions or functionality, as documented in the functional specification (Функциональный инкрементальный: интеграция и тестирование происходит на основе функций или функциональных возможностей, как описано в функциональной спецификации)

8.3.3. System testing - concerned with the behavior of the whole system/product as defined by the scope of a development project or product. Requires a controlled test environment (Тестирование системы - касается поведения всей системы / продукта Как это определено в рамках проекта или продукта разработки. Требуется контролируемая тестовая среда)

8.3.3.1. functional (функциональная)

8.3.3.2. non-functional (не функциональная)

8.3.3.2.1. performance(представление)

8.3.3.2.2. reliability(надежность)

8.3.3.3. Specification-based (black-box) techniques (Методы, основанные на спецификации (черный ящик))

8.3.3.3.1. Decision table may be created for combinations of effects described in business rules(Таблица решений может быть создана для комбинаций эффектов, описанных в бизнес-правилах)

8.3.3.4. Structure-based (white-box) techniques (Структурные методы (белый ящик))

8.3.4. Acceptance testing Requires 'as-if production' environment Приемочное тестирование Требует «как если бы производство» Окружающая среда

8.3.4.1. Questions(Вопросов )

8.3.4.1.1. 'Can the system be released?' («Можно ли выпускать систему?»)

8.3.4.1.2. 'What, if any, are the outstanding (business) risks?' («Что, если таковые имеются, являются неоплаченными (деловыми) рисками»?)

8.3.4.1.3. 'Has development met their obligations?' ('«Что, если таковые имеются, являются неоплаченными (деловыми) рисками»?)

8.3.4.2. Goals(Цели)

8.3.4.2.1. to establish confidence in the system, part of the system or specific non-functional characteristics e.g. usability, of the system.(Для установления доверия к системе, части системы или конкретным нефункциональным характеристикам, например. Юзабилити, системы.)

8.3.4.2.2. to determine whether the system is fit for purpose. (Чтобы определить, подходит ли система для цели.)

8.3.4.2.3. the system's readiness for deployment and use e.g. a large-scale system integration test may come after the acceptance of a system(Готовность системы к развертыванию и использованию например Крупномасштабный тест интеграции системы может наступить после принятия системы)

8.3.4.3. In other levels(На других уровнях)

8.3.4.3.1. A Commercial Off The Shelf (COTS) software product may be acceptance tested when it is installed or integrated(Программный продукт Commercial Off The Shelf (COTS) может быть проверен при приеме, когда он установлен или интегрирован)

8.3.4.3.2. Acceptance testing of the usability of a component may be done during com ponent testing(Приемочные испытания юзабилити компонента могут быть выполнены во время компонентного тестирования)

8.3.4.3.3. Acceptance testing of a new functional enhancement may come before system testing(Приемочное тестирование нового функционального усовершенствования может прийти до тестирования системы)

8.3.4.4. Types of acceptance testing(Типы приемочного тестирования)

8.3.4.4.1. Operational acceptance test (or Production acceptance test) (Испытания Оперативное принятие (или принятие Изготовление тест))

8.3.4.4.2. Compliance acceptance testing (or regulation acceptance testing) (Приемочные испытания (Или приемо-сдаточных испытаний))

8.3.4.4.3. 2 stages of acceptance test of COTS (2 этапа приемочного испытания COTS)

8.4. Test types(Типы тестирования)

8.4.1. Functional testing (often - 'black-box') 'what it does'

8.4.1.1. Based upon ISO 9126, can be done focusing on:

8.4.1.1.1. suitability

8.4.1.1.2. interoperability

8.4.1.1.3. security

8.4.1.1.4. accuracy

8.4.1.1.5. compliance

8.4.1.2. Perspectives:

8.4.1.2.1. requirements-based

8.4.1.2.2. business-process-based

8.4.1.2.3. experienced-based

8.4.2. Non-functional testing 'how well' the system works

8.4.2.1. Characteristics (ISO/IEC 9126, 2001)

8.4.2.1.1. functionality

8.4.2.1.2. reliability

8.4.2.1.3. usability

8.4.2.1.4. efficiency

8.4.2.1.5. maintainability

8.4.2.1.6. portability

8.4.2.2. Types

8.4.2.2.1. portability testing

8.4.2.2.2. reliability testing

8.4.2.2.3. maintainability testing

8.4.2.2.4. usability testing

8.4.2.2.5. stress testing

8.4.2.2.6. load testing

8.4.2.2.7. performance testing

8.4.3. Structural testing ('white-box')

8.4.4. Testing related to changes

8.4.4.1. Confirmation testing (re-testing)

8.4.4.2. Regression testing

8.5. Maintenance testing (testing an OS) different from maintainability testing, which defines how easy it is to maintain the system (Тестирование обслуживания (тестирование ОС) В отличие от тестирования ремонтопригодности, Которая определяет, насколько легко поддерживать систему)

8.5.1. Levels:

8.5.1.1. component test

8.5.1.2. integration test

8.5.1.3. system test

8.5.1.4. acceptance test

8.5.2. Parts

8.5.2.1. testing the changes

8.5.2.2. regression tests Based on:

8.5.2.2.1. Impact analysis

8.5.2.2.2. Risk analysis

8.5.3. Triggers

8.5.3.1. modifications

8.5.3.1.1. Planned modifications - 90% of work (enhancement changes (e.g. release-based))

8.5.3.1.2. Ad-hoc corrective and emergency changes

8.5.3.1.3. changes of environment

8.5.3.2. migration (from one platform to another

8.5.3.2.1. operational testing of the new environment

8.5.3.2.2. testing of the changed software

8.5.3.3. retirement of the system

8.5.3.3.1. the testing of data migration or archiving

9. 3. Static techniques(Статические методы)

9.1. 3.1 REVIEWS AND THE TEST PROCESS (ОБЗОРЫ И ПРОЦЕСС ИСПЫТАНИЙ)

9.1.1. Glossary(Глоссарий)

9.1.1.1. static testing

9.1.1.1.1. Testing of a component or system at specification or implementation level without execution of that software, e.g. reviews or static analysis

9.1.1.2. dynamic testing

9.1.1.2.1. Testing that involves the execution of the software of a component or system

9.1.1.3. reviews

9.1.1.3.1. An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough

9.1.2. Types of defects(Типы дефектов)

9.1.2.1. deviations from standards(Отклонения от стандартов)

9.1.2.2. missing requirements(Отсутствующие требования)

9.1.2.3. design defects(Конструктивные дефекты)

9.1.2.4. non-maintainable code (Код, не поддерживающий сопровождение)

9.1.2.5. inconsistent interface specifications (Несовместимые спецификации интерфейса)

9.1.2.6. Advantages:(Преимущества)

9.1.2.6.1. early feedback on quality issues (Ранняя обратная связь по вопросам качества)

9.1.2.6.2. Cheap fix and improvement(Дешевые исправления и улучшения)

9.1.2.6.3. development productivity increases(Рост производительности разработки)

9.1.2.6.4. exchange of information between the participants (Обмен информацией между участниками)

9.1.2.6.5. increased awareness of quality issues (Повышение осведомленности о проблемах качества)

9.2. 3,2 REVIEW PROCESS (ОБЗОР ПРОЦЕССА)

9.2.1. Glossary(Глоссарий)

9.2.1.1. entry criteria(Критерии поступления)

9.2.1.1.1. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria (Набор общих и конкретных условий, позволяющих процессу продвигаться вперед с определенной задачей, например. Этап тестирования. Цель входных критериев - предотвратить запуск задачи, которая повлечет за собой больше (впустую) усилий по сравнению с усилиями, необходимыми для удаления критериев неудачной записи)

9.2.1.2. exit criteria(Критерии выхода)

9.2.1.2.1. The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing (Набор общих и конкретных условий, согласованных с заинтересованными сторонами, для разрешения официального завершения процесса. Цель критериев выхода состоит в том, чтобы не допустить завершения выполнения задачи, когда все еще остаются незавершенными части задачи, которые еще не были выполнены. Критерии выхода используются для отчета и планирования, когда необходимо прекратить тестирование.)

9.2.1.3. formal review(Официальный обзор)

9.2.1.3.1. A review characterized by documented procedures and requirements, e.g. inspection(Обзор, характеризуемый документально оформленными процедурами и требованиями, например. осмотр)

9.2.1.4. informal review(Неофициальный обзор)

9.2.1.4.1. A review not based on a formal (documented) procedure. initiating (IDEAL): The phase within the IDEAL model where the groundwork is laid for a successful improvement effort. The initiating phase consists of the activities: set context, build sponsorship and charter infrastructure (Обзор не основан на официальной (документированной) процедуре. инициирование (ИДЕАЛ): Этап в модели IDEAL, где закладывается основа для Успешное улучшение. Начальный этап состоит из следующих действий: Устанавливать контекст, строить спонсорскую и чартерную инфраструктуру)

9.2.1.5. inspection(Осмотр)

9.2.1.5.1. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure (Тип рецензирования, основанный на визуальном анализе документов для обнаружения дефектов, например. Нарушения стандартов разработки и несоответствие документации более высокого уровня. Наиболее формальный метод обзора и, следовательно, всегда основанный на документированной процедуре)

9.2.1.6. moderator(Модератор)

9.2.1.6.1. The leader and main person responsible for an inspection or other review process(Лидер и главное лицо, ответственное за инспекцию или другой процесс рассмотрения)

9.2.1.7. reviewer(Рецензент)

9.2.1.7.1. The person involved in the review that identifies and describes anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process (Лицо, участвующее в обзоре, которое идентифицирует и описывает аномалии в рассматриваемом продукте или проекте. Рецензенты могут быть выбраны для представления различных точек зрения и ролей в процессе обзора)

9.2.1.8. scribe(Писатель)

9.2.1.8.1. The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. The scribe should ensure that the logging form is readable and understandable (Лицо, записывающее каждый дефект и любые предложения по улучшению процесса во время собрания по рассмотрению, в форме регистрации. Писец должен обеспечить читаемость и понятность формы ведения журнала)

9.2.1.9. technical review(Технический обзор)

9.2.1.9.1. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken (Дискуссионная группа по принципу «равный-равному», в которой основное внимание уделяется достижению консенсуса в отношении технического подхода)

9.2.1.10. walkthrough(Прохождение)

9.2.1.10.1. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content (Пошаговое представление автором документа с целью сбора информации и установления общего понимания ее содержания)

9.2.2. 3.2.1 Phases of a formal review(Этапы формального обзора)

9.2.2.1. informal(неофициальный)

9.2.2.1.1. not documented(Не документированы)

9.2.2.2. formal(формальный)

9.2.2.2.1. Phases(Этапы)

9.2.3. 3.2.2 Roles and responsibilities(Роли и обязанности)

9.2.3.1. The moderator(Модератор)

9.2.3.1.1. (or review leader) leads the review process ((Или руководитель обзора) ведет процесс обзора)

9.2.3.1.2. deter-mines, in co-operation with the author, the type of review(Определяет, в сотрудничестве с автором, тип обзора)

9.2.3.1.3. approach(подход)

9.2.3.1.4. the composition of the review team (Состав группы по рассмотрению)

9.2.3.1.5. performs the entry check(Выполняет проверку входа)

9.2.3.1.6. follow-up on the rework (Последующие меры по доработке)

9.2.3.1.7. schedules the meeting(Назначает встречу)

9.2.3.1.8. disseminates documents before the meeting (Распространяет документы перед собранием)

9.2.3.1.9. coaches other team members (Тренирует других членов команды)

9.2.3.1.10. paces the meeting(Проводит совещание)

9.2.3.1.11. leads possible discussions(Ведет переговоры)

9.2.3.1.12. stores the data that is collected(Сохраняет собранные данные)

9.2.3.2. The author(Автор)

9.2.3.2.1. learn as much as possible with regard to improving the quality of the document(Как можно больше узнать о том, как улучшить качество документа)

9.2.3.2.2. to improve his or her ability to write future documents(Улучшить его способность писать будущие документы)

9.2.3.2.3. to illuminate unclear areas(Освещать неясные области)

9.2.3.2.4. to understand the defects found(Понять недостатки)

9.2.3.3. The scribe (or recorder) (Писатель(или диктофон))

9.2.3.3.1. often the author(Часто автор)

9.2.3.3.2. to record each defect mentioned and any suggestions for process improvement(Для записи каждого упомянутого дефекта и любых предложений по улучшению процесса)

9.2.3.4. The reviewers (also called checkers or inspectors) (Рецензенты (Также называемых шашками или инспекторами))

9.2.3.4.1. to check any material for defects(Проверить любой материал на наличие дефектов)

9.2.3.5. The manager(Менеджер)

9.2.3.5.1. decides on the execution of reviews(Принимает решение о выполнении обзоров)

9.2.3.5.2. allocates time in project schedules (Выделяет время в расписаниях проектов)

9.2.3.5.3. determines whether review process objectives have been met(Определяет, были ли выполнены цели процесса обзора)

9.2.3.5.4. take care of any review training requested by the participants(Позаботьтесь о любой тренировке по рассмотрению, запрошенной участниками)

9.2.3.5.5. can also be involved in the review itself depending on his or her background, playing the role of a reviewer(Может также участвовать в самом обзоре в зависимости от его или ее происхождения, играя роль рецензента)

9.2.4. 3.2.3 Types of review(Виды рассмотрения)

9.2.4.1. Walkthrough(Прохождение)

9.2.4.1.1. guiding the participants through the document by the author (Направляя участников через документ автором)

9.2.4.1.2. useful for higher-level documents, such as requirement specifications and architectural documents(Полезен для документов более высокого уровня, таких как спецификации требований и архитектурные документы)

9.2.4.1.3. goals(Цели)

9.2.4.1.4. Key characteristics(Ключевые характеристики)

9.2.4.2. Technical review(Технический обзор)

9.2.4.2.1. discussion meeting that focuses on achieving con-sensus about the technical content of a document(Дискуссионное совещание, которое фокусируется на достижении соответствия технического содержания документа)

9.2.4.2.2. Compared to inspec-tions, technical reviews are less formal (По сравнению с инспекциями технические обзоры менее формальны)

9.2.4.2.3. little or no focus on defect identification on the basis of referenced documents (Мало или совсем не сосредоточено на выявлении дефектов на основе ссылочных документов)

9.2.4.2.4. goals(Цели)

9.2.4.2.5. Key characteristics(Ключевые характеристики)

9.2.4.3. Inspection(Осмотр)

9.2.4.3.1. the most formal review type(Наиболее формальный тип обзора)

9.2.4.3.2. Weinberg's concept of egoless engineering (Вайнбергская концепция эгоистической инженерии)

9.2.4.3.3. number of goals

9.2.4.3.4. goals(Цели)

9.2.4.3.5. Key characteristics(Ключевые характеристики)

9.2.5. 3.2.4 Success factors for reviews(Факторы успеха для обзоров)

9.2.5.1. Find a 'champion' (Найдите "чемпиона")

9.2.5.2. Pick things that really count (Выберите вещи, которые действительно считаются)

9.2.5.3. Explicitly plan and track review activities (Явно планировать и отслеживать действия по обзору)

9.2.5.4. Train participants(Участники поезда)

9.2.5.5. Manage people issues(Управление проблемами пользователей)

9.2.5.6. Follow the rules but keep it simple(Следуйте правилам, но держите их простыми)

9.2.5.7. Continuously improve process and tools(Постоянно совершенствовать процесс и инструменты)

9.2.5.8. Report results(Результаты отчета)

9.2.5.8.1. quantify the benefits as well as the costs (Количественно оценить выгоды, а также затраты)

9.2.5.9. Just do it!(Просто сделай это! )

9.3. 3.3 STATIC ANALYSIS BY TOOLS (СТАТИЧЕСКИЙ АНАЛИЗ ИНСТРУМЕНТОВ)

9.3.1. Glossary(Глоссарий)

9.3.1.1. compiler(Компилятор)

9.3.1.1.1. A software tool that translates programs expressed in a high order language into their machine language equivalents (Программный инструмент, который транслирует программы, выраженные на языке высокого порядка, в их эквиваленты машинного языка)

9.3.1.2. cyclo-matic complexity(Цикломатическая сложность)

9.3.1.2.1. The number of independent paths through a program. Cyclomatic complexity is defined as: L – N + 2P, where - L = the number of edges/links in a graph - N = the number of nodes in a graph - P = the number of disconnected parts of the graph (e.g. a called graph or subroutine) (Количество независимых путей в программе. Цикломатическая сложность Определяется как: L - N + 2P, где - L = количество ребер / связей На графике - N = количество узлов на графике - P = число Отключенных частей графика (например, вызываемого графа или подпрограммы))

9.3.1.3. control flow(Управляющий поток)

9.3.1.3.1. A sequence of events (paths) in the execution through a component or system (Последовательность событий (путей) при выполнении через компонент или систему)

9.3.1.4. data flow(Поток данных)

9.3.1.4.1. An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction (Абстрактное представление последовательности и возможных изменений состояния объектов данных, где состояние объекта - любое из: создание, использование или уничтожение)

9.3.1.5. static analysis(Статический анализ)

9.3.1.5.1. Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out by means of a supporting tool (Анализ программных артефактов, например. Требования или код, Выполненных без выполнения этих артефактов разработки программного обеспечения. Статический анализ обычно осуществляется с помощью вспомогательного инструмента)

9.3.2. Differents from dynamic testing(Отличие от динамического тестирования)

9.3.2.1. Static analysis is performed on requirements, design or code without actually executing the software artifact being examined (Статический анализ выполняется по требованиям, дизайну или коду без фактического выполнения рассматриваемого артефакта программного обеспечения)

9.3.2.2. Static analysis is ideally performed before the types of formal review(Статический анализ идеально выполняется перед формами официального обзора)

9.3.2.3. Static analysis is unrelated to dynamic properties of the requirements, design and code, such as test coverage(Статический анализ не связан с динамическими свойствами требований, дизайна и кода, такими как тестовое покрытие)

9.3.2.4. The goal of static analysis is to find defects, whether or not they may cause failures As with reviews, static analysis finds defects rather than failures (Цель статического анализа - найти дефекты, независимо от того, могут они вызывать сбои или нет. Как и в случае с обзорами, статический анализ обнаруживает дефекты, а не сбои)

9.3.3. 3.3.1 Coding standards(Стандарты кодирования)

9.3.4. 3.3.2 Code metrics(Показатели кода)

9.3.4.1. Complexity metrics identify high risk, complex areas (Метрики сложности идентифицируют высокорисковые, сложные области)

9.3.4.2. The cyclomatic complexity metric is based on the number of decisions in a program(Метрика цикломатической сложности основана на количестве решений в программе)

9.3.4.2.1. It is important to testers because it provides an indication of the amount of testing (including reviews) necessary to practically avoid defects (Это важно для тестировщиков, потому что оно дает представление о количестве тестов (включая обзоры), необходимых для того, чтобы практически избежать дефектов)

9.3.4.2.2. While there are many ways to calculate cyclomatic complexity, the easiest way is to sum the number of binary decision statements (e.g. if, while, for, etc.) and add 1 to it

9.3.4.3. The control flow(Управляющий поток)

9.3.5. 3.3.3 Code structure(Структура кода)

9.3.5.1. aspects(аспекты)

9.3.5.1.1. control flow structure(Структура управляющего потока)

9.3.5.1.2. data flow structure(Структура потока данных)

9.3.5.1.3. data structure(структура данных)

9.3.6. the value of static analysis (Значение статического анализа)

9.3.6.1. early detection of defects prior to test execution(Раннее обнаружение дефектов перед выполнением теста)

9.3.6.2. early warning about suspicious aspects of the code, design or requirements(Раннее предупреждение о подозрительных аспектах кода, дизайна или требований)

9.3.6.3. identification of defects not easily found in dynamic testing(Выявление дефектов, которые нелегко обнаружить при динамическом тестировании)

9.3.6.4. improved maintainability of code and design since engineers work according to documented standards and rules(Улучшенная ремонтопригодность кода и дизайна, поскольку инженеры работают в соответствии с документально оформленными стандартами и правилами)

9.3.6.5. prevention of defects, provided that engineers are willing to learn from their errors and continuous improvement is practised (Предотвращение дефектов, при условии, что инженеры готовы учиться на своих ошибках и постоянно совершенствуются)

10. 4. Test design techniques(Методы проектирования тестов)

10.1. 4.1 IDENTIFYING TEST CONDITIONS AND DESIGNING TEST CASES Test Documentation Standard [IEEE829] 4.1 ВИЯВЛЕННЯ УМОВИ ВИПРОБУВАНЬ І ПРОЕКТУВАННЯ ВИПРОБУВАННЯ ВИПАДКИ тест Документи Стандарт [IEEE829]

10.1.1. Glossary(Глосаррий)

10.1.1.1. test case(тест випадок)

10.1.1.1.1. A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement (Набор входных значений, предварительные условия выполнения, ожидаемые результаты и постусловия выполнения, разработанные для определенной цели или условия тестирования, такие как выполнение определенного пути программы или проверка соответствия конкретному требованию)

10.1.1.2. test case specification(Спецификация теста)

10.1.1.2.1. A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item (Документ, определяющий набор тестовых примеров (цель, входные данные, тестовые действия, ожидаемые результаты и предварительные условия выполнения) для тестового элемента)

10.1.1.3. test condition(Условие испытания)

10.1.1.3.1. An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element (Элемент или событие компонента или системы, которые могут быть проверены одним или несколькими тестовыми примерами, например. Функция, транзакция, функция, атрибут качества или структурный элемент)

10.1.1.4. test data(Дата проведения испытания)

10.1.1.4.1. Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test (Данные, которые существуют (например, в базе данных) перед выполнением теста, и которые влияют или зависят от тестируемого компонента или системы)

10.1.1.5. test procedure specification (Спецификация процедуры испытаний)

10.1.1.5.1. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script (Документ, определяющий последовательность действий для выполнения теста. Также известен как тестовый сценарий или ручной тестовый скрипт)

10.1.1.6. test script(Тестовый скрипт)

10.1.1.6.1. Commonly used to refer to a test procedure specification, especially an automated one (Обычно используется для обозначения спецификации тестовой процедуры, особенно автоматизированной)

10.1.1.7. traceability(Прослеживаемость)

10.1.1.7.1. The ability to identify related items in documentation and software, such as requirements with associated tests (Возможность идентифицировать связанные элементы в документации и программном обеспечении, такие как требования с соответствующими тестами)

10.1.2. 4.1.1 Introduction(4.1.1 Введение)

10.1.2.1. test conditions (Условия испытаний)

10.1.2.1.1. documented in a Test Design Specification (Задокументированы в спецификации тестового дизайна)

10.1.2.2. test cases(Тестовые примеры)

10.1.2.2.1. documented in a Test Case Specification (Задокументированы в спецификации тестового случая)

10.1.2.3. test procedures (or scripts) (Процедуры тестирования (или срипты))

10.1.2.3.1. documented in a Test Procedure Specification (also known as a test script or a manual test script) (Задокументированный в спецификации тестовой процедуры (также известный как тестовый сценарий или ручной тестовый скрипт))

10.1.3. 4.1.2 Formality of test documentation (4.1.2 Формальность тестовой документации)

10.1.4. 4.1.3 Test analysis: identifying test conditions (4.1.3. Анализ теста: определение условий испытаний)

10.1.4.1. A test condition is simply something that we could test (Условие испытания - это просто то, что мы могли бы проверить)

10.1.4.2. the basic ideas(Основные идеи)

10.1.4.2.1. [Marick, 1994]: 'test requirements' as things that should be tested ([Marick, 1994]: «требования к тестированию» как вещи, которые должны быть проверены)

10.1.4.2.2. [Hutcheson, 2003]: 'test inventory' as a list of things that could be tested

10.1.4.2.3. [Craig, 2002]: 'test objectives' as broad categories of things to test and 'test inventories' as the actual list of things that need to be tested

10.1.4.2.4. ISTQB: test condition

10.1.4.3. traceability.(Прослеживаемость.)

10.1.4.3.1. Test conditions should be able to be linked back to their sources in the test basis (Условия испытаний должны быть связаны с исходными данными на тестовой основе)

10.1.4.4. Test conditions can be identified for test data as well as for test inputs and test outcomes, (Условия испытаний могут быть идентифицированы для тестовых данных, а также для тестовых входов и результатов испытаний,)

10.1.4.5. IEEE 829 STANDARD: TEST DESIGN SPECIFICATION (СТАНДАРТ IEEE 829: СПЕЦИФИКАЦИЯ ПРОЕКТИРОВАНИЯ ИСПЫТАНИЙ)

10.1.5. 4.1.4 Test design: specifying test cases (4.1.4. Конструкция испытания: указание тестовых примеров)

10.1.5.1. IEEE 829 Standard for Test Documentation (Стандарт IEEE 829 для тестовой документации)

10.1.5.2. Oracle - source of informa-tion about the correct behavior of the system (Oracle - источник информации о правильном поведении системы)

10.1.5.3. IEEE 829 STANDARD: TEST CASE SPECIFICATION (СТАНДАРТ IEEE 829: СПЕЦИФИКАЦИЯ ИСПЫТАНИЯ)

10.1.6. 4.1.5 Test implementation: specifying test procedures or scripts (4.1.5. Реализация теста: указание тестовых процедур или сценариев)

10.1.6.1. test proce-dure in IEEE 829 also referred to as a test script (Процедура тестирования в IEEE 829, также называемая тестовым скриптом)

10.1.6.1.1. The document that describes the steps to be taken in running a set of tests (and specifies the executable order of the tests) (Документ, описывающий шаги, которые необходимо предпринять при запуске набора тестов (и определяет исполняемый порядок тестов))

10.2. 4.2 CATEGORIES OF TEST DESIGN TECHNIQUES 4.2 КАТЕГОРИИ ТЕХНОЛОГИЙ КОНСТРУКЦИИ ИСПЫТАНИЙ

10.2.1. Glossary(Глоссарий)

10.2.1.1. white-box test design techniques (Методы тестирования белого ящика)

10.2.1.1.1. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system (Процедура получения и / или выбора тестовых примеров на основе анализа внутренней структуры компонента или системы)

10.2.1.2. experience-based test design techniques (Опытные методы тестирования)

10.2.1.2.1. Procedure to derive and/or select test cases based on the tester’s experience, knowledge and intuition (Процедура получения и / или выбора тестовых случаев на основе опыта, знаний и интуиции тестировщика)

10.2.1.3. specification-based test design techniques (Основанные на спецификации методы проектирования)

10.2.1.3.1. Black box test design technique: Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure. (Метод тестирования теста черного ящика: процедура получения и / или выбора тестовых примеров на основе анализа спецификации, функциональной или нефункциональной, компонента или системы без ссылки на ее внутреннюю структуру.)

10.2.1.4. structure-based test design techniques (Методы проектирования на основе структуры)

10.2.1.4.1. See white box test design technique (См. Технику дизайна теста белого ящика)

10.2.1.5. white-box test design techniques (Методы тестирования белого ящика)

10.2.1.5.1. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system (Процедура получения и / или выбора тестовых примеров на основе анализа внутренней структуры компонента или системы)

10.2.2. 3 types or categories of test design technique, distin-guished by their primary source: (3 типа или категории методики проектирования тестов, отличающиеся их основным источником:)

10.2.2.1. a specification(Спецификация)

10.2.2.2. the structure of the system or component (Структура системы или компонента)

10.2.2.3. a person's experience(Опыт человека)

10.2.3. Techniques (Методы)

10.2.3.1. Static (Chapter 3) (Статический (глава 3))

10.2.3.2. Dynamic techniques (Динамические методы)

10.2.3.2.1. 4.2.2 Static testing techniques (4.2.2 Статические методы испытаний)

10.2.3.2.2. 4.2.4 Structure-based (white-box) testing techniques (or structural techniques) (4.2.4 Методы испытаний на основе структуры (белые ящики) (или структурные методы))

10.2.3.2.3. 4.2.5 Experience-based testing techniques (4.2.5 Методы тестирования на основе опыта)

10.3. 4.3 SPECIFICATION-BASED OR BLACK-BOX TECHNIQUES 4.3 ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ СПЕЦИФИКАЦИИ ИЛИ ЧЕРНОГО КОРОБКА

10.3.1. Glossary(Глоссарий)

10.3.1.1. boundary value analysis (Анализ граничных значений)

10.3.1.1.1. A black box test design technique in which test cases are designed based on boundary values (Метод дизайна теста черного ящика, в котором тестовые примеры разработаны на основе граничных значений)

10.3.1.2. decision table testing (Тестирование таблицы решений)

10.3.1.2.1. A black box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table (Метод дизайна теста черного ящика, в котором тестовые примеры предназначены для выполнения комбинаций входов и / или стимулов (причин), показанных в таблице решений)

10.3.1.3. equivalence partitioning (Разделение эквивалентности)

10.3.1.3.1. A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once (Метод тестирования теста черного ящика, в котором тестовые примеры предназначены для выполнения функций представителей из разделов эквивалентности. В принципе, тестовые примеры предназначены для покрытия каждого раздела, по крайней мере, один раз)

10.3.1.4. state transition testing (Тестирование перехода состояния)

10.3.1.4.1. A black box test design technique in which test cases are designed to execute valid and invalid state transitions (Метод дизайна теста черного ящика, в котором тестовые примеры предназначены для выполнения допустимых и недействительных переходов состояний)

10.3.1.5. use case testing

10.3.1.5.1. A black box test design technique in which test cases are designed to execute scenarios of use cases (Метод дизайна теста черного ящика, в котором тестовые примеры предназначены для выполнения сценариев использования)

10.3.2. 4.3.1 Equivalence partitioning and boundary value analysis (4.3.1. Разделение эквивалентности и анализ граничных значений)

10.3.2.1. Equivalence partitions are also known as equivalence classes (Эквивалентные разделы также известны как классы эквивалентности)

10.3.2.2. Untitled

10.3.2.3. Boundary value analysis (BVA) is based on testing at the boundaries between partitions (Анализ граничных значений (BVA) основан на тестировании на границах между разделами)

10.3.2.4. Untitled

10.3.2.5. Designing test cases(Проектирование тестовых примеров)

10.3.2.5.1. both equivalence partitioning and boundary value analysis (Как разделение эквивалентности, так и анализ граничных значений)

10.3.2.5.2. Invalid inputs are separate test cases (Недопустимыми входами являются отдельные тестовые примеры)

10.3.3. 4.3.2 Decision table testing ('cause-effect' table) (4.3.2 Тестирование таблицы принятия решений (таблица причинно-следственных связей))

10.3.3.1. combinations of things (e.g. inputs,conditions,etc.) (Комбинации вещей (например, входы, условия и т. Д.),)

10.3.3.2. other techniques with combination: (Другие методы с комбинацией:)

10.3.3.2.1. pairwise testing(Парное тестирование)

10.3.3.2.2. orthogonal arrays(Ортогональные массивы)

10.3.3.3. Creating a table listing all the combinations of True and False for each of the aspects (Создание таблицы с перечислением всех комбинаций True и False для каждого из аспектов)

10.3.3.4. Untitled

10.3.4. 4.3.3 State transition testing ('finite state machine') (Проверка состояния перехода («конечный автомат»))

10.3.4.1. four basic parts: (Четыре основные части:)

10.3.4.1.1. the states that the software may occupy (open/closed or funded/insufficient funds) (Государства, которые могут занимать программное обеспечение (открытые / закрытые или финансируемые / недостаточные средства))

10.3.4.1.2. the transitions from one state to another (not all transitions are allowed) (Переходы из одного состояния в другое (допускаются не все переходы))

10.3.4.1.3. the events that cause a transition (closing a file or withdrawing money) (События, которые вызывают переход (закрытие файла или вывод денег))

10.3.4.1.4. the actions that result from a transition (an error message or being given your cash) (Действия, возникающие в результате перехода (сообщение об ошибке или предоставление ваших денежных средств))

10.3.4.2. Untitled

10.3.4.3. model can be as detailed or as abstract as you need it to be (Модель может быть такой же детализированной или абстрактной, как вам нужно.)

10.3.5. 4.3.4 Use case testing (4.3.4. Использовать примеры тестирования)

10.3.5.1. is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish (Это метод, который помогает нам идентифицировать тестовые примеры, которые осуществляют всю систему в транзакции по транзакционной основе от начала до конца)

10.3.5.2. Untitled

10.4. 4.4 STRUCTURE-BASED OR WHITE-BOX TECHNIQUES 4.4. СТРУКТУРА ИЛИ БЕЛЫЕ ТЕХНОЛОГИИ

10.4.1. Glossary (Глоссарий)

10.4.1.1. code coverage (Покрытие кода)

10.4.1.1.1. An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage (Метод анализа, который определяет, какие части программного обеспечения были выполнены (покрыты) набором тестов и какие части не были выполнены, например. Охват заявлений, покрытие решений или покрытие условий)

10.4.1.2. decision coverage (Охват решения)

10.4.1.2.1. The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage (Процент результатов решения, которые были выполнены По тестовому набору. 100% охват решений подразумевает как 100% охват филиалов, так и 100% охват заявлений)

10.4.1.3. statement coverage (заявление покрытие)

10.4.1.3.1. The percentage of executable statements that have been exercised by a test suite (Процент исполняемых инструкций, которые выполнялись набором тестов)

10.4.1.4. structural testing(Структурное тестирование)

10.4.1.4.1. See white box testing(См. Тестирование белого ящика)

10.4.1.5. structure-based testing (Структурное тестирование)

10.4.1.5.1. See white-box testing(См. Тестирование белого ящика)

10.4.1.6. white-box testing (Тестирование белого ящика)

10.4.1.6.1. Testing based on an analysis of the internal structure of the component or system (Тестирование на основе анализа внутренней структуры компонента или системы)

10.4.2. 4.4.1 Using structure-based techniques to measure coverage and design tests (4.4.1 Использование структурных методов для измерения охвата и проектных испытаний)

10.4.2.1. 2 purposes: (2 цели:)

10.4.2.1.1. test coverage measurement (Измерение покрытия)

10.4.2.1.2. structural test case design (Конструкция конструктивного теста)

10.4.2.2. Types of coverage(Виды покрытия)

10.4.2.2.1. For testing levels (Для уровней тестирования)

10.4.2.2.2. For specification-based techniques (Для методов, основанных на спецификации)

10.4.2.3. Instrumentation to measure coverage (Инструментарий для измерения покрытия)

10.4.2.3.1. 1 Decide on the structural element to be used, i.e. the coverage items to be counted

10.4.2.3.2. 2 Count the structural elements or items.

10.4.2.3.3. 3 Instrument the code.

10.4.2.3.4. 4 Run the tests for which coverage measurement is required.

10.4.2.3.5. 5 Using the output from the instrumentation, determine the percentage of elements or items exercised.

10.4.3. 4.4.2 Statement coverage and statement testing (4.4.2. Заявление и проверка заявлений)

10.4.3.1. Untitled

10.4.3.2. Example(Пример)

10.4.3.2.1. READ A 2 READ B 3 C =A + 2*B 4 IF C> 50 THEN 5 PRINT large C 6 ENDIF

10.4.4. 4.4.3 Decision coverage and decision testing (4.4.3. Покрытие решения и тестирование решений)

10.4.4.1. Untitled

10.4.4.2. 'sub-sumes' statement coverage - this means that 100% decision coverage always guarantees 100% statement coverage but not the other way around! («Оговорка о суммировании субамов» - это означает, что 100% -ый охват решений всегда гарантирует покрытие 100% заявлений, но не наоборот!)

10.4.4.3. Bit to achieve 100% decision coverage, at least 2 test cases are necessary to cover both True and False (Бит для достижения 100% -ного охвата решений, по крайней мере, 2 тестовых случая необходимы для покрытия как True, так и False)

10.4.4.4. Example(Пример)

10.4.4.4.1. 1 READ A 2 READ B 3 C=A-2*B 4 IFC <0THEN 5 PRINT "C negative" 6 ENDIF

10.4.5. 4.4.4 Other structure-based techniques (4.4.4 Другие основанные на структуре методы)

10.4.5.1. branch coverage (Охват филиалов)

10.4.5.1.1. Branch coverage measures the coverage of both conditional and unconditional branches Whilst decision coverage measures the coverage of conditional branches (Отраслевое покрытие измеряет охват как условных, так и безусловных отраслей. В то время как охват решений охватывает охват условных ветвей)

10.4.5.2. linear code sequence and jump (LCSAJ) coverage (Линейная кодовая последовательность и скачок (LCSAJ))

10.4.5.3. condition coverage(Покрытие условий)

10.4.5.4. multiple condition coverage (condition combination coverage) (Множественное покрытие условий (комбинация условий охват))

10.4.5.5. condition determination coverage (multiple condition decision coverage or modified con-dition decision coverage, MCDC) (Охват определения условий (многократное принятие решения о состоянии или изменение разрешения для принятия решений, MCDC))

10.4.5.6. path coverage or 'independent path segment coverage' (Охват маршрута или «независимый охват сегмента пути»)

10.5. 4.5 EXPERIENCE-BASED TECHNIQUES 4.5 ТЕХНОЛОГИИ НА ОСНОВЕ ОПЫТА

10.5.1. Glossary(Глоссарий)

10.5.1.1. error guessing (Угадание ошибок)

10.5.1.1.1. A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them (Метод тестового проектирования, в котором опыт тестера используется для прогнозирования того, какие дефекты могут присутствовать в тестируемом компоненте или системе в результате сделанных ошибок, и специально разрабатывать тесты, чтобы выявить их)

10.5.1.2. exploratory testing (Разведочное тестирование)

10.5.1.2.1. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests (Неформальный метод тестового проектирования, в котором тестер активно контролирует дизайн тестов, когда эти тесты выполняются, и использует информацию, полученную во время тестирования, для разработки новых и лучших тестов)

10.5.2. 4.5.1 Error guessing (4.5.1 Угадание ошибок)

10.5.2.1. A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them (Структурированный подход к методу угадывания ошибок заключается в перечислении возможных дефектов или сбоев и разработке тестов, которые пытаются их произвести)

10.5.2.2. can be built based on (Могут быть построены на основе)

10.5.2.2.1. the tester's own experience (Собственный опыт тестера)

10.5.2.2.2. experience of other people (Опыт других людей)

10.5.2.2.3. available defect and failure data (Доступные данные о дефектах и сбоях)

10.5.2.2.4. from common knowledge about why software fails (От общих знаний о том, почему программное обеспечение не работает)

10.5.3. 4.5.2 Exploratory testing (4.5.2 Экспериментальные испытания)

10.5.3.1. is a hands-on approach in which testers are involved in minimum planning and maximum test execution (Является практическим подходом, в котором тестировщики участвуют в минимальном планировании и максимальном выполнении теста)

10.5.3.2. A key aspect of exploratory testing is learning (Ключевым аспектом поискового тестирования является обучение)

10.5.3.3. Books(Книги)

10.5.3.3.1. Kaner, 2002

10.5.3.3.2. Copeland, 2003

10.5.3.3.3. Whittaker, 2002 ('attacks')

10.6. 4.6 CHOOSING A TEST TECHNIQUE 4.6 ВЫБОР ТЕХНОЛОГИИ ИСПЫТАНИЙ

10.6.1. The best testing technique is no single testing technique (Лучший метод тестирования - это не единый метод тестирования)

10.6.2. Internal factors (Внутренние факторы)

10.6.2.1. Models used(Используемые модели)

10.6.2.1.1. The models available (i.e. developed and used during the specification) will govern which testing techniques can be used

10.6.2.2. Tester knowledge and experience(Знание и опыт тестера)

10.6.2.2.1. How much testers know about the system and about testing techniques (Сколько тестировщиков знают о системе и методах тестирования)

10.6.2.3. Likely defects(Вероятные дефекты)

10.6.2.3.1. Knowledge of the likely defects (since each technique is good at finding a particular type of defect) (Знание вероятных дефектов (поскольку каждый метод хорош При обнаружении определенного типа дефекта))

10.6.2.4. Test objective (Цель теста)

10.6.2.4.1. simply to gain confidence? - Use cases (Просто получить уверенность? - Случаи использования)

10.6.2.4.2. thorough testing? - more rigorous and detailed techniques (Тщательное тестирование? - более строгие и подробные методы)

10.6.2.5. Documentation(Документация)

10.6.2.5.1. Whether or not documentation exists and it is up to date (Независимо от наличия или отсутствия документации и актуальности)

10.6.2.5.2. The content and style of the documentation will also influence the choice of techniques (Содержание и стиль документации также будут влиять на выбор методов)

10.6.2.6. Life cycle model (Модель жизненного цикла)

10.6.2.6.1. A sequential life cycle model? - more formal techniques (Последовательная модель жизненного цикла? - более формальные методы)

10.6.2.6.2. An iterative life cycle model? - an exploratory testing approach (Итеративная модель жизненного цикла? - поисковый подход к тестированию)

10.6.3. External factors (Внешние факторы)

10.6.3.1. Risk (Риск)

10.6.3.1.1. The greater the risk (e.g. safety-critical systems)? - more thorough and more formal testing (Чем выше риск (например, критически важные для безопасности системы)? - более тщательное и более формальное тестирование)

10.6.3.1.2. Commercial risk (Коммерческий риск)

10.6.3.2. Customer and contractual requirements (Клиентские и контрактные требования)

10.6.3.2.1. Contracts may specify particular testing techniques (most commonly statement or branch coverage) (Контракты могут указывать конкретные методы тестирования (Чаще всего с заявлением или филиалом))

10.6.3.3. Type of system (Тип системы)

10.6.3.3.1. Financial application? - boundary value analysis (Финансовое приложение? - анализ граничных значений)

10.6.3.4. Regulatory requirements (Нормативные требования)

10.6.3.4.1. regulatory standards or guidelines (Нормативные стандарты или руководящие принципы)

10.6.3.4.2. the aircraft industry (Авиационная промышленность)

10.6.3.5. Time and budget (Время и бюджет)