Титульный лист
<Project>
Test Plan
Версия 1.0
Дата создания
Подготовлен:
Фамилия И. О.
E-mail:
Контактная информация:
Фамилия И. О.
E-mail:
Полное название организации
Адрес:
Телефон:
1. Введение
1.1 Назначение
Документ Test Plan для проекта <Project> преследует следующие цели:
- Определить те компоненты продукта, которые должны быть протестированы.
- Создать список рекомендуемых Тестовых Требований (высокого уровня).
- Создать список и описать тестовые стратегии, которые планируется использовать.
- Определить необходимые ресурсы и привести расчет трудозатрат.
1.2 Предпосылки
<INSERT>
[Введите краткое описание проекта/приложения. Приведите такие сведения как краткое описание проекта/приложения, его основные особенности, функциональность, его архитектура и история проекта. Этот раздел должен быть не более 3-5 абзацев.]
1.3 Предмет
<INSERT>
[Опишите стадии тестирования, например Unit или Build, и типы тестирования, которые будут описаны в этом плане. Такие как Тестирование Функциональности или Производительности.]
[Приведите краткий список функциональностей, свойств, особенностей проекта, которые будут/не будут протестированы.]
[Укажите все допущения, которые были сделаны в процессе разработки данного документа и которые могли повлиять на процедуру тестирования.]
[Укажите те риски и вероятности, которые могут оказать влияние на процедуру тестирования.]
[Укажите ограничения, оказывающие влияние на процедуру тестирования.]
1.4 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Project Proposal.]
| Номер | Название | Дата и Издательство | Автор | Комментарий |
| - | - | - | - | - |
1.5 Паспорт проекта
Нижеследующая таблица содержит сведения о документации по проекту и ее доступности.
N.B.: добавляйте или удаляйте элементы по необходимости
| Document (and version / date) | Created or Available | Received or Reviewed | Author or Resource | Notes |
| Requirements Specification | Yes/No | Yes/No | - | - |
| Functional Specification | Yes/No | Yes/No | - | - |
| Project Plan | Yes/No | Yes/No | - | - |
| Design Specifications | Yes/No | Yes/No | - | - |
| Users Manuals | Yes/No | Yes/No | - | - |
| Business Model / Flow | Yes/No | Yes/No | - | - |
| Business Functions and Rules | Yes/No | Yes/No | - | - |
| Project / Business Risk Assessment | Yes/No | Yes/No | - | - |
2. Тестовые требования
Нижеследующий список содержит те объекты (Use-Case-ы, функциональные требования, нефункциональные требования), которые были определены в качестве объектов тестирования. Этот список показывает то, что будет протестировано.
<INSERT>
[На высоком уровне определите главные тестовые требования.]
3. Стратегия тестирования
Стратегия тестирования представляет собой рекомендуемый подход к тестированию продукта. Если предыдущий раздел тестовых требований описывал то, что должно быть протестировано, то данный раздел описывает то, как это нужно делать.
Главными вопросами тестовой стратегии являются техники тестирования, которые будут использоваться, и критерий, по которому можно было бы определить, что тестирование завершено.
3.1 Типы тестирования
3.1.1 Тестирование данных и целостности базы данных
Базы данных должны тестироваться как отдельные системы внутри <Project>. Эти системы должны тестироваться отдельно от приложений (таких как интерфейс доступа к данным). Необходимо провести дополнительное исследование СУБД на тему того, какие инструменты/техники существуют для выполнения нижеописанного тестирования.
3.1.1.1 Цель тестирования
Убедится в том, что методы доступа к данным работают правильно и без нарушения целостности БД.
3.1.1.2 Способы
- Вызвать каждый метод доступа к БД, предоставляя правильные и не правильные данные (или запросы к данным).
- Исследовать БД на предмет корректного заполнения ее данными, корректной обработки событий
3.1.1.3 Критерий завершенности
Все методы и процедуры БД функционируют так, как им положено и без нарушения целостности самой БД.
3.1.1.4 Особые замечания
- При тестировании может понадобиться среда разработки СУБД или драйвера для корректного подключения к базам данных.
- Процедуры должны вызываться вручную.
- Для повышения видимости неприемлемых событий БД необходимо использовать небольшие БД или БД с ограниченным количеством записей.
3.1.2 Системное тестирование
Тестирование приложений должно проводиться в соответствии с требованиями к продукту, которые могут быть отслежены вплоть до Use-Case-ов и бизнес правил. Целью этих тестов является проверка правильного приема, обработки и возврата данных, а также соответствующая реализация этих служебных правил. Такой вид тестирования основан на технике черного ящика, т.е. проверяет приложение (и его внутренние процессы) путем взаимодействия с приложением через GUI и анализа окончательного результата (результатов). Ниже приведены основные принципы, рекомендованные для тестирования каждого приложения:
3.1.2.1 Цель тестирования
Ensure proper application navigation, data entry, processing, and retrieval.
3.1.2.2 Способы
Execute each use case, use case flow, or function, using valid and invalid data, to verify the following:
- The expected results occur when valid data is used.
- The appropriate error / warning messages are displayed when invalid data is used.
- Each business rule is properly applied.
3.1.2.3 Критерий завершенности
- All planned tests have been executed.
- All identified defects have been addressed.
3.1.2.4 Особые замечания
[Identify / describe those items or issues (internal or external) that impact the implementation and execution of System test]
3.1.3 Тестирование цикличных бизнес-процессов
Тестирование цикличных бизнес-процессов должно эмулировать действия, совершаемые над системой <Project> через определенные промежутки времени. В качестве периода необходимо взять один год и выполнить те действия и транзакции, которые должны произойти за этот год. Сюда относятся все ежедневные, еженедельные и ежемесячные действия и события, которые являются датозависимыми, такие, как памятки.
3.1.3.1 Цель тестирования
Ensure proper application and background processes function according to required business models and schedules.
3.1.3.2 Способы
Testing will simulate several business cycles by performing the following:
- The tests used for application function testing will be modified / 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 / 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 / warning messages are displayed when invalid data is used.
- Each business rule is properly applied.
3.1.3.3 Критерий завершенности
All planned tests have been executed.
All identified defects have been addressed.
3.1.3.4 Особые замечания
- System dates and events may require special support activities
- Business model is required to identify appropriate test requirements and procedures.
3.1.4 Тестирование пользовательского интерфейса
Тестирование интерфейса проверяет взаимодействие пользователя с программным обеспечением. GUI необходимо тестировать для того, чтобы удостовериться, что GUI предоставляет пользователю возможность передвижения и соответствующий доступ к функциям приложения. Кроме того, тестирование GUI подтверждает, что объекты внутри GUI функционируют, как предполагается и соответствуют корпоративным и промышленным стандартам.
3.1.4.1 Цель тестирования
Verify the following:
- Navigation through the application properly reflects business functions and requirements, including window to window, field to field, and use of access methods (tab keys, mouse movements, accelerator keys)
- Window objects and characteristics, such as menus, size, position, state, and focus conform to standards.
3.1.4.2 Способы
Create / modify tests for each window to verify proper navigation and object states for each application window and objects.
3.1.4.3 Критерий завершенности
Each window successfully verified to remain consistent with benchmark version or within acceptable standard
3.1.4.4 Особые замечания
Not all properties for custom and third party objects can be accessed
3.1.5 Тестирование производительности
Тестирование производительности оценивает время реагирования/ответа, скорость выполнения транзакции и другие временные критерии. Целью ТП является проверка и подтверждение полученных критериев производительности. ТП обычно проводится несколько раз, каждый раз в системе используется разная "загрузка в фоновом режиме". Начальный тест должен проводиться с "номинальной" загрузкой, подобной нормальной загрузке установленной (или прогнозируемой) для этой системы. Второй тест на производительность проводится с использованием максимальной загрузки.
Кроме того, ТП может использоваться, чтобы представить и настроить производительность системы в зависимости от различных условий, таких как рабочая нагрузка или конфигурации железа.
Внимание: Ниже приведены транзакции, относящиеся к "логическим бизнес транзакциям". Эти транзакции характеризуются/ определяются как специальные функции, которые конечный пользователь системы, предположительно, будет использовать с помощью приложения, такие как добавить или изменить данный контракт.
3.1.5.1 Цель тестирования
Validate System Response time for designated transactions or business functions under a the following two conditions:
- normal anticipated volume
- anticipated worse case volume
3.1.5.2 Способы
- Use Test Procedures developed for Business Model Testing (System 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 Особые замечания below).
3.1.5.3 Критерий завершенности
- Single Transaction / single user: Successful completion of the test scripts without any failures and within the expected / required time allocation (per transaction)
- Multiple transactions / multiple users: Successful completion of the test scripts without any failures and within acceptable time allocation.
3.1.5.4 Особые замечания
- Comprehensive performance testing includes having a "background" load 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 SQL calls.
- Create "virtual" user load to simulate many (usually several hundred) clients. 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.
3.1.6 Тестирование загрузки
Тестирование загрузки оценивает объекты тестируемой системы при изменении рабочих нагрузок, чтобы оценить возможность системы продолжать функционировать должным образом при разных рабочих нагрузках. Целью тестирования загрузки является определить и подтвердить, что система функционирует должным образом за пределами предполагаемой максимальной рабочей нагрузки. Кроме того, тестирование загрузки оценивает характеристики производительности (время реагирования/ответа, скорость выполнения транзакции и другие).
Внимание: Ниже приведены транзакции, относящиеся к "логическим бизнес транзакциям". Эти транзакции характеризуются/определяются как специальные функции, которые конечный пользователь системы, предположительно, будет использовать с помощью приложения, такие как добавить или изменить данный контракт.
3.1.6.1 Цель тестирования
Verify System Response time for designated transactions or business cases under varying workload conditions.
3.1.6.2 Способы
- Use tests developed for Business Cycle Testing.
- Modify data files (to increase the number of transactions) or the tests to increase the number of times each transaction occurs.
3.1.6.3 Критерий завершенности
Multiple transactions / multiple users: Successful completion of the tests without any failures and within acceptable time allocation.
3.1.6.4 Особые замечания
- 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
3.1.7 Стресс-тестинг
Стресс-тестинг предназначен для нахождения ошибок, возникающих из-за недостатка ресурсов или из-за совместного их использования разными компонентами. Недостаток памяти или места на диске может выявить дефекты в программном обеспечении, которые не видны при работе в нормальных условиях. Прочие дефекты могут проявиться при одновременном использовании ресурсов, открытых для совместного доступа, таких как блокированные базы данных. Стресс-тестинг определяет максимальную загрузку, которую может выдержать система.
Внимание: Ниже приведены транзакции, относящиеся к "логическим бизнес транзакциям".
3.1.7.1 Цель тестирования
Verify that the system and software function 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 / accounts
- worst case transaction volume / mix (see performance testing above).
NOTES: Stress testing's goal 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.10, Configuration testing.
3.1.7.2 Способы
- Use tests developed for Performance Testing.
- To test limited resources, tests should be run on single machine, 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 / mix.
3.1.7.3 Критерий завершенности
All planned tests are executed and specified system limits are reached / exceeded without the software or software failing (or conditions under which system failure occurs is outside of the specified conditions).
3.1.7.4 Особые замечания
- Stressing the network may require network tools to load the network with messages / 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 / data accounts.
3.1.8 Тестирование объема
Тестирование объема предполагает загрузку программного обеспечения большим количеством данных, чтобы определить, когда будет исчерпан лимит, что будет причиной падения программного обеспечения. ТО, также, определяет длительность максимальной загрузки или объем, который может выдержать система за определенный период. Например, если программное обеспечение обрабатывает набор записей из базы данных для составления отчета, ТО будет использовать тестовую базу данных большого размера и проверит, нормально ли функционирует программное обеспечение и правильно ли составлен отчет.
3.1.8.1 Цель тестирования
Verify that the application / system 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 / report transactions are executed simultaneously.
3.1.8.2 Способы
- Use tests developed for Performance Testing.
- Multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix (see stress test above) for an extended period.
- Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries / report transactions simultaneously for extended periods.
3.1.8.3 Критерий завершенности
All planned tests have been executed and specified system limits are reached / exceeded without the software or software failing.
3.1.8.4 Особые замечания
What period of time would be considered an acceptable time for high volume conditions (as noted above)?
3.1.9 Тестирование безопасности и контроля доступа
ТБКД сосредоточено на двух ключевых моментах безопасности:
- Безопасность приложения, включая доступ к данным или бизнес функциям
- Безопасность системы, включая регистрацию / дистанционный доступ к системе.
Безопасность приложения обеспечивает такие условия, основанные на соображениях безопасности, при которых пользователи могут пользоваться определенным набором функций или имеют ограниченный доступ к данным. Например, любой пользователь может получить разрешение на ввод данных или создание новых учетных записей, но удалить их могут только менеджеры. Если это безопасность уровня данных, тестирование обеспечивает условия, при которых пользователь первого "типа" может видеть всю информацию о клиенте, включая финансовую информацию, в то время как второй пользователь видит только демографические данные того же клиента.
Безопасность системы обеспечивает такие условия, при которых только некоторые пользователи, имеющие доступ к системе, могут пользоваться приложениями и только определенным образом.
3.1.9.1 Цель тестирования
Function / Data Security: Verify that user can access only those functions / data for which their user type is provided permissions.
System Security: Verify that only those users with access to the system and application(s) are permitted to access them.
3.1.9.2 Способы
- Function / Data Security: Identify and list each user type and the functions / 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 / data are correctly available or denied.
- System Access (see Особые замечания below)
3.1.9.3 Критерий завершенности
For each known user type the appropriate function / data are available and all transactions function as expected and run in prior Application Function tests
3.1.9.4 Особые замечания
Access to the system must be reviewed / discussed with the appropriate network or systems administrator. This testing may not be required as it maybe a function of network or systems administration.
3.1.10 Тестирование падения / восстановления
Тестирование падения/восстановления обеспечивает такие условия, при которых приложение или вся система может "упасть" и восстановиться при большом количестве железных, программных или сетевых отказов/неправильных срабатываний с большой потерей или сохранением данных.
Тестирование на падение обеспечивает такие условия, для систем, которые должны продолжать работать, когда возникают условия для падения, при которых системы дублеры или резервные системы должным образом "замещают" упавшие системы без потери данных или транзакций.
Тестирование на восстановление является противоположным процессом, при котором приложение или система открыты для экстремальных условий (или смоделированных условий), таких как ошибка ввода/вывода или неверные указатели/ключи в базе данных. Включается процесс восстановления и приложение/система просматривается и/или проверяется, чтобы проверить корректность восстановления приложения/системы/данных.
3.1.10.1 Цель тестирования
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 server(s)
- Interruption, communication, or power loss to DASD and or DASD controller(s)
- Incomplete cycles (data filter processes interrupted, data synchronization processes interrupted).
- Invalid database pointer / keys
- Invalid / corrupted data element in database
3.1.10.2 Способы
Tests created for Application 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 server(s) / routers).
- Interruption, communication, or power loss to DASD and or DASD controller(s): simulate or physically eliminate communication with one or more DASD controllers or devices.
Once the above conditions / simulated conditions are achieved, additional transactions should 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.
3.1.10.3 Критерий завершенности
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 / keys, and reports indicating the processes or transactions that were not completed due to interruptions.
3.1.10.4 Особые замечания
- 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(s).
3.1.11 Конфигурационное тестирование
КТ проверяет функционирование программного обеспечения при различных конфигурациях софта и железа. В большинстве сред разработки отдельные технические условия железа различаются для рабочих станций клиентов, сетевых соединений и серверов баз данных. У рабочих станций клиентов может быть различное программное обеспечение (напр., приложения, драйвера и т.д.), и в любое время одновременно может быть задействовано множество разных комбинаций, и могут использоваться разные ресурсы.
3.1.11.1 Цель тестирования
Validate and verify that the client, <Project> Application function properly on the prescribed client workstations.
3.1.11.2 Способы
- Use Integration and System Test scripts
- Open / close various Microsoft applications, such as Excel and Word, either as part of the test or prior to the start of the test.
- Execute selected transactions to simulate users activities into and out of Ошибка! Стиль не определен. and Microsoft applications.
- Repeat the above process, minimizing the available conventional memory on the client.
3.1.11.3 Критерий завершенности
For each combination Microsoft application, transactions are successfully completed without failure.
3.1.11.4 Особые замечания
- What Microsoft Applications are available, accessible on the clients?
- What applications are typically used?
- What data are the applications running (i.e. large spreadsheet opened in Excel, 100 page document in Word).
- The entire systems, netware, network servers, databases, etc. should also be documented as part of this test
3.1.12 Инсталляционное тестирование
ИТ преследует две цели. Первая - убедиться, что программное обеспечение может быть установлено на всех возможных конфигурациях, таких как новая инсталляция, модернизация и полная или обычная инсталляция, а также при нормальных и отклоняющихся от нормы условиях. Отклоняющиеся от нормы условия включают в себя недостаток места на диске, отсутствие разрешения на создание директорий и т.д. Вторая - проверить, что однажды установленное программное обеспечение работает корректно. Обычно это предполагает проведение большого количества тестов, которые были разработаны для функционального тестирования.
3.1.12.1 Цель тестирования
Verify and validate that the <Project> client software properly installs onto each client under the following conditions:
- New Installation, a new machine, never installed previously with <Project>
- Update machine previously installed <Project>, same version
- Update machine previously installed <Project>, older version
3.1.12.2 Способы
- Manually or develop automated scripts to validate the condition of the target machine (new - <Project> never installed, <Project> same version or older version already installed).
- Launch / perform installation.
- Using a predetermined sub-set of Integration or System test scripts, run the transactions.
3.1.12.3 Критерий завершенности
<Project> transactions execute successfully without failure.
3.1.12.4 Особые замечания
What <Project>transactions should be selected to comprise a confidence test that <Project> application has been successfully installed and no major software components are missing?
3.2 Инструментарий
Для тестирования проекта будут использованы следующие средства:
| - | Tool | Vendor/In-house | Version |
| Test Management | - | - | - |
| Defect Tracking | - | - | - |
| ASQ Tool (functional testing) | - | - | - |
| ASQ Tool (performance testing) | - | - | - |
| Test Coverage Monitor or Profiler | - | - | - |
| Project Management | - | - | - |
| DBMS tools | - | - | - |
4. Ресурсы
Этот раздел представляет рекомендуемые для проекта <Project> ресурсы, их главные обязанности, знания и навыки.
4.1 Исполнители
| Human Resources |
| Worker | Minimum Resources Recommended (number of workers allocated full-time) | Specific Responsibilities/Comments |
| Test Manager / Test Project Manager | - | Provides management oversight
Responsibilities:- Provide technical direction
- Acquire appropriate resources
- Management reporting
|
| Test Designer | - | Identifies, prioritizes, and implements test cases
Responsibilities:- Generate test plan
- Generate test model
- Evaluate effectiveness of test effort
|
| Tester | - | Executes the tests
Responsibilities:- Execute tests
- Log results
- Recover from errors
- Document defects
|
| Test System Administrator | - | Ensures test environment and assets are managed and maintained.
Responsibilities:- Administer test management system
- Install / manage worker access to test systems
|
| Database Administration / Database Manager | - | Ensures test data (database) environment and assets are managed and maintained.
Responsibilities:- Administer test data (database)
|
| Designer | - | Identifies and defines the operations, attributes, and associations of the test classes.
Responsibilities:- Identifies and defines the test class(es)
- Identifies and defines the test packages
|
| Implementer | - | Implements and unit tests the test classes and test packages.
Responsibilities:- Creates the test classes and packages implemented in the test model.
|
4.2 Система
Нижеследующая таблица представляет системные ресурсы для тестирования проекта.
The specific elements of the test system are not fully known at this time. It is recommended that the system simulate the production environment, scaling down the accesses and database sizes if / where appropriate.
| System Resources |
| Resource | Name / Type |
| Database Server | - |
| -Network/Subnet | TBD |
| -Server Name | TBD |
| -Database Name | TBD |
| Client Test PC's | - |
| -Include special configuration | TBD |
| -requirements | TBD |
| SQA Test Repository | - |
| -Network/Subnet | TBD |
| -Server Name | TBD |
| Test Development PC's | TBD |
5. Project Milestones
В таблице должно содержаться описание трудоемкости для каждого объема работ, указанного в предыдущих секциях. Для связи статуса проекта и трудоемкости, необходимо определить отдельные этапы тестирования.
| - | Milestone Task | - | Effort | Start Date | End Date |
| Test Planning | - | - | - | - | - |
| Test Design | - | - | - | - | - |
| Test Development | - | - | - | - | - |
| Test Execution | - | - | - | - | - |
| Test Evaluation | - | - | - | - | - |
История изменений
| Person Name | Title | Approval Date | Status |
| - | - | - | - |
