План тестирования

• Название: План тестирования
• Дата: 06.10.2022
• Размер: 38.93 Kb.
• Имя файла: 31.07 Test Plan .docx
• Тип: Документы; #717851

_{План тестирования}

https://www.uz.gov.ua/>
Версия <1.0>

[Текст в квадратных скобках – это инструкции для автора тест-плана, и он должен быть удален в финальной версии документа.]

[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

История изменений

Дата	Версия	Описание	Автор
1/07/22	1.0.x	Создание	Истомина М. Д.

Содержание


План тестирования

1. Введение

   1. Назначение

Данный план тестирования для <Название Проекта> разрабатывается для достижения следующих целей:

• [Определить, какие проектные документы и компоненты системы должны быть протестированы

• Перечислить рекомендуемые требования для тестирования (высокоуровневые).

• Порекомендовать и описать стратегии тестирования.

• Определить необходимые ресурсы, даты, затраты.

• Перечислить выходные документы для тестирования (отчеты, списки ошибок, рекомендации)]

2. Описание проекта

[В этой части тест-плана опишите тестируемый объект (компонент, приложение, систему и т.д.), его задачи/цели. Также укажите информацию об основных функциях и возможностях, архитектуре проекта, и, при необходимости, историю проекта. Эта часть тест-плана должна состоять из 3-5 параграфов.]

3. Объем тестирования

[Определите уровни тестирования (модульное, интеграционное, системное, приемочное) и виды тестирования (функций, нагрузочное, юзабилити и т.д.).
Составьте список функций/возможностей, которые будут протестированы.
Составьте список функций/возможностей, которые не будут протестированы. Опишите причины.
Укажите всю необходимую информацию, полученную в ходе подготовки данного документа, которая может повлиять на проектирование, разработку и выполнение тестов.

Перечислите риски и обстоятельства, которые могут повлиять на проектирование, разработку ли выполнение тестов.


Перечислите ограничения, которые могут повлиять на проектирование, разработку ли выполнение тестов.]

1. Проектная документация

В данной таблице содержится информация о документации, использованной при составлении данного плана тестирования:

[Вы можете добавить необходимые элементы или удалить неиспользуемые]

Документ (и версия/дата)	Доступен	Проведено ревью	Автор / Источник	Примечания
Requirements Specification	□ Да □ Нет	□ Да □ Нет
Functional Specification	□ Да □ Нет	□ Да □ Нет
Use-Case Reports	□ Да □ Нет	□ Да □ Нет
Project Plan	□ Да □ Нет	□ Да □ Нет
Design Specifications	□ Да □ Нет	□ Да □ Нет
Prototype	□ Да □ Нет	□ Да □ Нет
User’s Manuals	□ Да □ Нет	□ Да □ Нет
Business Model or Flow	□ Да □ Нет	□ Да □ Нет
Data Model or Flow	□ Да □ Нет	□ Да □ Нет
Business Functions and Rules	□ Да □ Нет	□ Да □ Нет
Project or Business Risk Assessment	□ Да □ Нет	□ Да □ Нет

1. Требования для тестирования

Данный список содержит элементы – сценарии использования, функциональные и нефункциональные требования – которые были определены как объекты для тестирования. Список определяет, что будет протестировано.

[Составьте список требований/объектов для тестирования.]

2. Стратегия тестирования

[Тестовая стратегия описывает рекомендуемый подход для тестирования каждого из тестируемых объектов. Если предыдущая секция описывала, что будет протестировано, то здесь описывается, как это нужно сделать.

Для каждого вида тестирования укажите описание и цели.

Если какой-то вид тестирования не будет применен, то укажите это, а также опишите краткое обоснование.

Также внимание в стратегии тестирования стоит уделить используемым методам и критериям завершения тестирования. ]

2. Виды тестирования

1. Тестирование данных и тестирование целостности баз данных

[Базы данных и процессы работы с БД должны быть протестированы как подсистема в проекте
Name>. Эти подсистемы должны быть протестированы без использования конечного пользовательского интерфейса. Для проведения тестирования могут потребоваться дополнительные исследования.]

Цели тестирования:	[Удостовериться, что процессы обработки данных и методы доступа к БД работают корректно и не приводят к повреждениям данных.]
Методы:	∙ [Invoke each database access method and process, seeding each with valid and invalid data or requests for data. ∙ Inspect the database to ensure the data has been populated as intended, all database events occurred properly, or review the returned data to ensure that the correct data was retrieved for the correct reasons]
Критерии завершения:	[Все методы доступа к БД и процессы обработки данных проверены и работают так, как было спроектировано, и не приводят к каким-либо повреждениям данных.]
Особые замечания:	∙ [Тестирование может потребовать специальных прав доступа и инструментов для работы с БД. ∙ Процессы должны запускаться вручную. ∙ БД должны быть минимально возможного размера, чтобы повысить видимость каких-либо недопустимых событий]

1. Тестирование функций

[Тестирование функций системы должно фокусироваться на тех требованиях к системе, которые основываются на вариантах использования, бизнес-функциях, бизнес-правилах. Тестирование проводится методом черного ящика через пользовательский интерфейс.]

Цели тестирования:	[Удостовериться, что функциональность работает так, как запланировано, в том числе ввод, обработку, вывод информации.]
Методы:	[Выполнить каждый сценарий как на валидных, так и невалидных входных данных (позитивные и негативные тесты). ∙ На валидных данных получается ожидаемый результат. ∙ На невалидных данных появляется соответствующее сообщене об ошибке. ∙ Каждое бизнес-правило применено корректно.]
Критерии завершения:	∙ [Все запланированные тесты выполнены. ∙ Все найденные дефекты назначены соответствующим ЛПР]
Особые замечания:	[Опишите, что может повлиять на разработку и проведение тестов]

1. Тестирование в режиме бизнес-цикла

[Тестирование бизнес-цикла должно эмулировать все те действия, которые обычно выполняются в рамках проекта в течение определенного времени. Этот отрезок времени должен быть определен. Например, если в качестве такого периода берется год, то все действия, которые должны повторяться ежедневно, еженедельно, ежемесячно, должны быть выполнены, а также все те действия, которые зависят от дат.]

Цели тестирования:	[Удостовериться, что все тестируемые и фоновые процессы работают в соответствии с бизнес-моделями и расписанием.]
Методы:	[Testing will simulate several business cycles by performing the following: ∙ The tests used for target-of-test’s function testing will be modified or enhanced to increase the number of times each function is executed to simulate several different users over a specified period. ∙ All time or date-sensitive functions will be executed using valid and invalid dates or time periods. ∙ All functions that occur on a periodic schedule will be executed or launched at the appropriate time. ∙ Testing will include using valid and invalid data to verify the following: ∙ The expected results occur when valid data is used. ∙ The appropriate error or warning messages are displayed when invalid data is used. ∙ Each business rule is properly applied.
Критерии завершения:	∙ [Все запланированные тесты выполнены.. ∙ Все найденные дефекты назначены на ЛПР]
Особые замечания:	∙ [Системные события и даты могут потребовать дополнительной настройки ∙ Для определения тестовых требований и процедур требуется бизнес-модель.]

2. Тестирование интерфейса

[Тестирование пользовательского интерфейса проверяет взаимодействие пользователя с системой. Цель тестирования – удостовериться, что интерфейс предоставляет доступ ко всем функциям, и внешний вид приложения соответствует принятым стандартам в компании и в индустрии.]

Цели тестирования:	[Необходимо проверить как минимум следующее: ∙ Навигация соответствует бизнес-правилам и требованиям, доступны несколько способов навигации (мышь, горячие клавиши) ∙ Все объекты пользовательского интерфейса соответствуют общепринятым стандартам]
Методы:	[Создать сценарии, которые проверяют навигацию по окнам или страницам. Создать тесты, проверяющие состояния объектов на экране. Создать тесты для проверки соответствия всех элементов стандартам.]
Критерии завершения:	[Каждое окно/страница проверены на соответствие требованиям, внутренним и внешним стандартам.]
Особые замечания:	[Особое внимание обратите на нестандартные объекты пользовательского интерфейса..]

3. Тестирование производительности

[Performance profiling is a performance test in which response times, transaction rates, and other time-sensitive requirements are measured and evaluated. The goal of Performance Profiling is to verify performance requirements have been achieved. Performance profiling is implemented and executed to profile and tune a target-of-test's performance behaviors as a function of conditions such as workload or hardware configurations.

Note: Transactions below refer to “logical business transactions”. These transactions are defined as specific use cases that an actor of the system is expected to perform using the target-of-test, such as add or modify a given contract.]

Цели тестирования:	[Verify performance behaviors for designated transactions or business functions under the following conditions: ∙ normal anticipated workload ∙ anticipated worst case workload]
Методы:	∙ [Use Test Procedures developed for Function or Business Cycle Testing. ∙ Modify data files to increase the number of transactions or the scripts to increase the number of iterations each transaction occurs. ∙ Scripts should be run on one machine (best case to benchmark single user, single transaction) and be repeated with multiple clients (virtual or actual, see Special Considerations below).]
Критерии завершения:	∙ [Single Transaction or single user: Successful completion of the test scripts without any failures and within the expected or required time allocation per transaction.] ∙ [Multiple transactions or multiple users: Successful completion of the test scripts without any failures and within acceptable time allocation.]
Особые замечания:	[Comprehensive performance testing includes having a background workload on the server. There are several methods that can be used to perform this, including: ∙ “Drive transactions” directly to the server, usually in the form of Structured Query Language (SQL) calls. ∙ Create “virtual” user load to simulate many clients, usually several hundred. Remote Terminal Emulation tools are used to accomplish this load. This technique can also be used to load the network with “traffic”. ∙ Use multiple physical clients, each running test scripts to place a load on the system. Performance testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. The databases used for Performance Testing should be either actual size or scaled equally.]

4. Нагрузочное тестирование

[Нагрузочное тестирование — это тест производительности, который подвергает объект тестирования различным рабочим нагрузкам для измерения и оценки характеристик производительности и способности объекта тестирования продолжать нормально функционировать при этих различных рабочих нагрузках. Целью нагрузочного тестирования является определение и обеспечение правильной работы системы за пределами ожидаемой максимальной рабочей нагрузки. Кроме того, при нагрузочном тестировании оцениваются характеристики производительности, такие как время отклика, скорость транзакций и другие вопросы, чувствительные ко времени).]

[Примечание: приведенные ниже транзакции относятся к «логическим бизнес-транзакциям». Эти транзакции определяются как определенные функции, которые конечный пользователь системы должен выполнять с помощью приложения, например, добавлять или изменять данный контракт.]

Цели тестирования:	[Verify performance behavior time for designated transactions or business cases under varying workload conditions.]
Методы:	∙ [Use tests developed for Function or Business Cycle Testing. ∙ Modify data files to increase the number of transactions or the tests to increase the number of times each transaction occurs.]
Критерии завершения:	[Multiple transactions or multiple users: Successful completion of the tests without any failures and within acceptable time allocation.]
Особые замечания:	∙ [Load testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. ∙ The databases used for load testing should be either actual size or scaled equally.]

5. Стресс-тестирование

[Stress testing is a type of performance test implemented and executed to find errors due to low resources or competition for resources. Low memory or disk space may reveal defects in the target-of-test that aren't apparent under normal conditions. Other defects might result from competition for shared resources like database locks or network bandwidth. Stress testing can also be used to identify the peak workload the target-of-test can handle.]

[Note: References to transactions below refer to logical business transactions.]

Цели тестирования:	[Verify that the target-of-test functions properly and without error under the following stress conditions: ∙ little or no memory available on the server (RAM and DASD) ∙ maximum actual or physically capable number of clients connected or simulated ∙ multiple users performing the same transactions against the same data or accounts ∙ worst case transaction volume or mix (see Performance Testing above). Notes: The goal of Stress Testing might also be stated as identify and document the conditions under which the system FAILS to continue functioning properly. Stress Testing of the client is described under section 3.1.11, Configuration Testing.]
Методы:	∙ [Use tests developed for Performance Profiling or Load Testing. ∙ To test limited resources, tests should be run on a single machine, and RAM and DASD on server should be reduced or limited. ∙ For remaining stress tests, multiple clients should be used, either running the same tests or complementary tests to produce the worst-case transaction volume or mix.
Критерии завершения:	[All planned tests are executed and specified system limits are reached or exceeded without the software failing or conditions under which system failure occurs is outside of the specified conditions.]
Особые замечания:	∙ [Stressing the network may require network tools to load the network with messages or packets. ∙ The DASD used for the system should temporarily be reduced to restrict the available space for the database to grow. ∙ Synchronization of the simultaneous clients accessing of the same records or data accounts.]

6. Объемное тестирование

[Volume Testing subjects the target-of-test to large amounts of data to determine if limits are reached that cause the software to fail. Volume Testing also identifies the continuous maximum load or volume the target-of-test can handle for a given period. For example, if the target-of-test is processing a set of database records to generate a report, a Volume Test would use a large test database and check that the software behaved normally and produced the correct report.]

Цели тестирования:	[Verify that the target-of-test successfully functions under the following high volume scenarios: ∙ Maximum (actual or physically- capable) number of clients connected, or simulated, all performing the same, worst case (performance) business function for an extended period. ∙ Maximum database size has been reached (actual or scaled) and multiple queries or report transactions are executed simultaneously.]
Методы:	∙ [Use tests developed for Performance Profiling or Load Testing. ∙ Multiple clients should be used, either running the same tests or complementary tests to produce the worst-case transaction volume or mix (see Stress Testing above) for an extended period. ∙ Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries and report transactions simultaneously for extended periods.]
Критерии завершения:	∙ [All planned tests have been executed and specified system limits are reached or exceeded without the software or software failing.]
Особые замечания:	[What period of time would be considered an acceptable time for high volume conditions, as noted above?]

7. Тестирование безопасности и контроля доступа

[Security and Access Control Testing focus on two key areas of security:

∙ Application-level security, including access to the Data or Business Functions

∙ System-level Security, including logging into or remote access to the system.

Application-level security ensures that, based upon the desired security, actors are restricted to specific functions or use cases, or are limited in the data that is available to them. For example, everyone may be permitted to enter data and create new accounts, but only managers can delete them. If there is security at the data level, testing ensures that” user type one” can see all customer information, including financial data, however,” user two” only sees the demographic data for the same client.

System-level security ensures that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways.]

Цели тестирования:	Application-level Security: [Verify that an actor can access only those functions or data for which their user type is provided permissions.] System-level Security: Verify that only those actors with access to the system and applications are permitted to access them.]
Методы:	Application-level Security: [Identify and list each user type and the functions or data each type has permissions for.] ∙ [Create tests for each user type and verify each permission by creating transactions specific to each user type.] ∙ Modify user type and re-run tests for same users. In each case, verify those additional functions or data are correctly available or denied. System-level Access: [See Special Considerations below]
Критерии завершения:	[For each known actor type the appropriate function or data are available, and all transactions function as expected and run in prior Application Function tests.]
Особые замечания:	[Access to the system must be reviewed or discussed with the appropriate network or systems administrator. This testing may not be required as it may be a function of network or systems administration.]

8. Тестирование на сбои и восстановление

[Failover and Recovery Testing ensures that the target-of-test can successfully failover and recover from a variety of hardware, software or network malfunctions with undue loss of data or data integrity.

Failover testing ensures that, for those systems that must be kept running, when a failover condition occurs, the alternate or backup systems properly “take over” for the failed system without loss of data or transactions.

Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions, or simulated conditions, to cause a failure, such as device Input/Output (I/O) failures or invalid database pointers and keys. Recovery processes are invoked and the application or system is monitored and inspected to verify proper application, or system, and data recovery has been achieved.]

Цели тестирования:	[Verify that recovery processes (manual or automated) properly restore the database, applications, and system to a desired, known, state. The following types of conditions are to be included in the testing: ∙ power interruption to the client ∙ power interruption to the server ∙ communication interruption via network servers ∙ interruption, communication, or power loss to DASD and or DASD controllers ∙ incomplete cycles (data filter processes interrupted, data synchronization processes interrupted). ∙ invalid database pointer or keys ∙ invalid or corrupted data element in database]
Методы:	[Tests created for Function and Business Cycle testing should be used to create a series of transactions. Once the desired starting test point is reached, the following actions should be performed, or simulated, individually: ∙ Power interruption to the client: power the PC down. ∙ Power interruption to the server: simulate or initiate power down procedures for the server. ∙ Interruption via network servers: simulate or initiate communication loss with the network (physically disconnect communication wires or power down network servers or routers. ∙ Interruption, communication, or power loss to DASD and DASD controllers: simulate or physically eliminate communication with one or more DASD controllers or devices. Once the above conditions or simulated conditions are achieved, additional transactions should be executed and upon reaching this second test point state, recovery procedures should be invoked. Testing for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated. Testing for the following conditions requires that a known database state be achieved. Several database fields, pointers, and keys should be corrupted manually and directly within the database (via database tools). Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed.]
Критерии завершения:	[In all cases above, the application, database, and system should, upon completion of recovery procedures, return to a known, desirable state. This state includes data corruption limited to the known corrupted fields, pointers or keys, and reports indicating the processes or transactions that were not completed due to interruptions.]
Особые замечания:	∙ [Recovery testing is highly intrusive. Procedures to disconnect cabling (simulating power or communication loss) may not be desirable or feasible. Alternative methods, such as diagnostic software tools may be required. ∙ Resources from the Systems (or Computer Operations), Database, and Networking groups are required. ∙ These tests should be run after hours or on an isolated machine.]

9. Конфигурационное тестирование

[Configuration testing verifies the operation of the target-of-test on different software and hardware configurations. In most production environments, the particular hardware specifications for the client workstations, network connections and database servers vary. Client workstations may have different software loaded⎯for example, applications, drivers, and so on⎯and at any one time, many different combinations may be active using different resources.]

Цели тестирования:	[Verify that the target-of-test functions properly on the required hardware and software configurations.]
Методы:	∙ [Use Function Test scripts. ∙ Open and close various non-target-of-test related software, such as the Microsoft applications, Excel and Word, either as part of the test or prior to the start of the test. ∙ Execute selected transactions to simulate actor’s interacting with the target-of-test and the non-target-of-test software. ∙ Repeat the above process, minimizing the available conventional memory on the client workstation.]
Критерии завершения:	[For each combination of the target-of-test and non-target-of-test software, all transactions are successfully completed without failure.]
Особые замечания:	∙ [What non-target-of-test software is needed, is available, and is accessible on the desktop? ∙ What applications are typically used? ∙ What data are the applications running; for example, a large spreadsheet opened in Excel or a 100- page document in Word? ∙ The entire systems, netware, network servers, databases, and so on also needs to be documented as part of this test.]

10. Тестирование установки

[Installation testing has two purposes. The first is to insure that the software can be installed under different conditions⎯such as a new installation, an upgrade, and a complete or custom installation⎯under normal and abnormal conditions. Abnormal conditions include insufficient disk space, lack of privilege to create directories, and so on. The second purpose is to verify that, once installed, the software operates correctly. This usually means running a number of the tests that were developed for Function Testing.]

Цели тестирования:	Verify that the target-of-test properly installs onto each required hardware configuration under the following conditions: ∙ new installation, a new machine, never installed previously with ∙ update, machine previously installed , same version ∙ update, machine previously installed , older version
Методы:	∙ [Manually or develop automated scripts, to validate the condition of the target machine⎯ new - never installed; same version or older version already installed). ∙ Launch or perform installation. ∙ Using a predetermined sub-set of function test scripts, run the transactions.]
Критерии завершения:	transactions execute successfully without failure.
Особые замечания:	[What transactions should be selected to comprise a confidence test that application has been successfully installed and no major software components are missing?]

2. Инструменты

Следующие инструментальные средства были использованы при тестировании данного проекта:

[Вы можете удалить неиспользуемые/добавить необходимые строки]

	Инструмент	Разработчик	Версия
Управление тестированием
Система учета ошибок
Автоматизация функционального тестирования
Автоматизация тестирования производительности
Инструмент для подсчета покрытия тестами
Управление проектом
СУБД

3. Ресурсы

[В этом разделе представлены рекомендуемые ресурсы для проекта <Имя проекта>, их основные обязанности, а также их знания или набор навыков.]

1. Роли

В таблице представлены роли, участвующие в тестировании проекта.

[Вы можете добавить недостающие роли и удалить неиспользуемые.]

Человеческие ресурсы
Сотрудник	Рекомендованное количество ресурсов (количество человек на полный рабочий день)	Описание
Тест-менеджер		Provides management oversight. Responsibilities: provide technical direction acquire appropriate resources provide management reporting
Разработчик тестов		Identifies, prioritizes, and implements test cases. Responsibilities: generate test plan generate test model evaluate effectiveness of test effort
Тестировщик		Executes the tests. Responsibilities: execute tests log results recover from errors document change requests
Администратор тестовой среды		Ensures test environment and assets are managed and maintained. Responsibilities: administer test management system install and manage access to test systems
Администратор баз данных		Ensures test data (database) environment and assets are managed and maintained. Responsibilities: administer test data (database)
Проектировщик автоматизированных тестов		Identifies and defines the operations, attributes, and associations of the test classes. Responsibilities: identifies and defines the test classes identifies and defines the test packages
Разработчик автоматизированных тестов		Implements and unit tests the test classes and test packages. Responsibilities: creates the test classes and packages implemented in the test model

2. Система

Системные ресурсы, необходимые для тестирования проекта.

[Опишите все используемые ресурсы: сервер (если есть), ПК, мобильные устройства и т.д. ]

Системные ресурсы
Ресурс	Название / Тип
Сервер
—Сеть	TBD
—Имя сервера	TBD
—База данных	TBD
Клиентский компьютер тестировщика
—Требования к оборудованию	TBD
Сервер для хранения тестов
—Сеть	TBD
—Имя сервера	TBD
Компьютер разработчика тестов	TBD

4. Ключевые даты

[Testing of
should incorporate test activities for each of the test efforts identified in the previous sections. Separate project milestones should be identified to communicate project status accomplishments.]

Задача	Продолжительность	Начало	Завершение
Составление плана тестирования
Проектирование тестов
Разработка тестов
Выполнение тестов
Оценка тестирования

5. Поставляемые документы

[В этом разделе напишите список документов, отчетов, которые будут предоставлены по завершению тестирования. Для каждого из документов укажите автора, предполагаемые даты получения документов и адресаты (тест-менеджер, разработчики, все участники проекта и т.д.]

1. Отчеты по тестированию

[Производительности, юзабилити, на битые ссылки, покрытие модульными тестами и пр.]

1. Отчеты по найденным дефектам

[Список найденных проблем, приоритет, статус.]

Приложение 1. Проектные задачи

Ниже представлен список задач, относящихся к тестированию:

∙ Планирование тестирования

• 
  identify requirements for test
  
• 
  assess risk
  
• 
  develop test strategy
  
• 
  identify test resources
  
• 
  create schedule
  
• 
  generate Test Plan
  

∙ Проектирование тестов

- prepare workload analysis

- identify and describe test cases

- identify and structure test procedures

- review and assess test coverage

∙ Разработка тестов

• 
  record or program test scripts
  
• 
  identify test-specific functionality in the Design and Implementation Model
  
• 
  establish external data sets
  

∙ Выполнение тестов

- execute Test procedures

- evaluate execution of Test

- recover from halted Test

- verify the results

- investigate unexpected results

- log defects

∙ Оценка результатов тестов

- evaluate Test-case coverage

- evaluate code coverage

- analyze defects

- determine if Test Completion Criteria and Success Criteria have been achieved