Russian ABAP Developer's Club Forum Index -> Blogs -> vga's blog

Users browsing this blog: None

Шаблоны: Запрос на изменение (Software Change Request)


Sat Feb 16, 2008 4:18 pm

[ Category: Шаблоны документов ]

Титульный лист

<Project>

Software Change Request

Версия 1.0

Дата создания


Подготовлен:
Фамилия И. О.
E-mail:

Контактная информация:
Фамилия И. О.
E-mail:


Полное название организации
Адрес:
Телефон:

1. Введение

1.1 Назначение
Документ Software Change Request описывает изменения, которые предлагается внести в <Project>, включая подробное описание новых требований к продукту, с точки зрения бизнес-процессов. Наряду с функциональными изменениями, он также описывает и нефункциональные, а также изменения в проектных требованиях и ограничениях и другие факторы, необходимые для предоставления полного и ясного описания требований к продукту.
Данный документ создается каждый раз, когда подается формальный запрос на изменение какого-либо элемента проекта.

1.2 Предмет
Предметом данного документа является описание изменений, которые необходимо внести в продукт <Project>, а также изменение его особенностей и требований к нему.

1.3 Термины, определения и соглашения
1.3.1 Аббревиатуры
<INSERT>
1.3.2 Соглашения
<INSERT>

1.4 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Project Proposal.]

НомерНазваниеДата и ИздательствоАвторКомментарий
-----


2. Описание изменений

<INSERT>
[Этот раздел кратко излагает суть запрашиваемого изменения]

1.1 Описание
<INSERT>
[Этот раздел подробно описывает обстоятельства, вызвавшие необходимость внесения изменения и описание этого изменения.]
1.1.1 Основные обстоятельства
<INSERT>
[Информация о причинах запроса на изменение.]
1.1.2 Примеры
<INSERT>
[Дополнительная информация, т.е. отчеты об ошибках, скрин-шоты отображающие некорректное поведение продукта и т.д.]

3. Оценка запроса на изменение

1.2 Область действия изменения
<INSERT>
[Оценка области действия изменения, с приведением списка всех объектов проекта, на которые окажет влияние вносимое изменение, включая всех лиц, подлежащих информированию.]
1.2.1 Необходимая техническая работа
<INSERT>
[Описание работ, которые должны быть выполнены для завершения внесения изменений]
1.2.2 Инструментарий, особые ресурсы
<INSERT>
[Здесь указывается необходимый инструментарий и прочие особые ресурсы]

1.1 Описание объектов проекта, затрагиваемых данным измененияем
<INSERT>
[Этот раздел рассказывает об объектах проекта, на которые повлияет данное изменение.]

1.2 Интеграционные эффекты
<INSERT>
[Влияние изменения на прочие системы.]

1.3 Технические риски
<INSERT>
[Описать риски, связанные с внесением изменения.]

1.4 Причина и правомерность
<INSERT>
[Этот раздел рассказывает о том, почему запрашивается данное изменение и приводятся подтверждения его правомерности.]

1.5 Предполагаемые последствия
<INSERT>
[Здесь описываются предположения подателя запроса относительно последствий данного изменения.]

1.6 Альтернативы
<INSERT>
[Мнение подателя запроса относительно наличия альтернатив данному изменению.]

1.7 Приоритет для подателя запроса
<INSERT>
[Обычно приоритет, приписываемый подателем запроса определенной работе оценивается по пятибалльной шкале.]

4. Стоимостная оценка

<INSERT>
[Этот раздел содержит стоимостную оценку внесения запрашиваемого изменения, включая оценку времени и усилий, которые должны быть потрачены.]

5. Рекомендации и выводы

<INSERT>
[Этот раздел представляет рекомендации в отношении изменения, его внутренний приоритет, и окончательные выводы в отношении запроса.]

1.1 Рекомендации
<INSERT>
[Должны ли вноситься эти изменения?]

1.2 Внутренний приоритет
<INSERT>
[Насколько важно это изменение в свете продолжающихся работ, и прочих аспектов бизнеса и продукта?]

1.3 Вывод
<INSERT>
[Будет ли сделано изменение и если да, то когда?]

6. Изменения проектной документации

<INSERT>
[Этот раздел содержит описание изменений в проектной документации, которые необходимо внести.]

7. Требования к проверке

<INSERT>
[В данном разделе необходимо дать описание деятельности SQA (Software Quality Assurance) и методов тестирования, необходимых для обеспечения гарантий того, что изменение не вызовет побочных эффектов.]

1.1 План пересмотра/переоценки
<INSERT>
[Здесь необходимо указать все пересмотры и переоценки, которые могут быть проведены.]

1.2 Тест-план
<INSERT>
[Описать план повторного тестирования и новых тестов, которые понадобяться]

8. Изменения

Person NameTitleApproval DateSignature
----


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

Person NameTitleApproval DateStatus
----



Posted By: vga    142 Comments    С уважением, vga

Trackbacks (0) Permalink

Шаблоны документов: План тестирования (Test Plan)


Sat Feb 09, 2008 11:17 am

[ Category: Шаблоны документов ]

Титульный лист

<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 AvailableReceived or ReviewedAuthor or ResourceNotes
Requirements SpecificationYes/NoYes/No--
Functional SpecificationYes/NoYes/No--
Project PlanYes/NoYes/No--
Design SpecificationsYes/NoYes/No--
Users ManualsYes/NoYes/No--
Business Model / FlowYes/NoYes/No--
Business Functions and RulesYes/NoYes/No--
Project / Business Risk AssessmentYes/NoYes/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 Инструментарий
Для тестирования проекта будут использованы следующие средства:

-ToolVendor/In-houseVersion
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
WorkerMinimum 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
ResourceName / Type
Database Server-
-Network/SubnetTBD
-Server NameTBD
-Database NameTBD
Client Test PC's-
-Include special configurationTBD
-requirementsTBD
SQA Test Repository-
-Network/SubnetTBD
-Server NameTBD
Test Development PC'sTBD


5. Project Milestones
В таблице должно содержаться описание трудоемкости для каждого объема работ, указанного в предыдущих секциях. Для связи статуса проекта и трудоемкости, необходимо определить отдельные этапы тестирования.
-Milestone Task-EffortStart DateEnd Date
Test Planning-----
Test Design-----
Test Development-----
Test Execution-----
Test Evaluation-----


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

Person NameTitleApproval DateStatus
----



Posted By: vga    0 Comments    С уважением, vga

Trackbacks (0) Permalink

Шаблоны: Техническое задание (Functional Specification)


Sun Feb 03, 2008 11:03 am

[ Category: Шаблоны документов ]

Титульный лист

<Project>

Functional Specification

Версия 1.0

Дата создания


Подготовлен:
Фамилия И. О.
E-mail:

Контактная информация:
Фамилия И. О.
E-mail:


Полное название организации
Адрес:
Телефон:

1. Введение

1.1 Назначение
Документ Project Proposal содержит общие требования, описания и предложения в соответствии с теми характеристиками и решениями, которые могут быть использованы. Он содержи оценкупроектных рисков и предложения по управлению этими рисками, решения возможных проблем, оценку времени и ресурсов проекта. Данный документ является отправной точкой для начала процесса утверждения проекта.

1.2 Предмет
Предметом данного документа является продукт <Project>, а также его особенности и требования к нему.

1.3 Термины, определения и соглашения
1.3.1 Аббревиатуры
<INSERT>
1.3.2 Соглашения
<INSERT>

1.4 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Project Proposal.]

НомерНазваниеДата и ИздательствоАвторКомментарий
-----


2. Общее описание функциональности

<INSERT>
[Данный подраздел описывает основные факторы, влияющие на продукт, требования к нему и предлагаемые решения.]

2.1 Требования к функциональности
<INSERT>
[Опишите с системной функциональной точки зрения. (т.е. как будут реализованы требования внутри системы). По необходимости обращайтесь к документу Requirements.]

2.1.1 Функциональность
<INSERT>
[Этот подраздел описывает подходы, необходимые для удовлетворения функциональных требований к системе. Здесь необходимо кратко описать особенности системы.]

2.1.2 Практичность
<INSERT>
[Этот раздел включает в себя все решения, удовлетворяющие требованиям практичности.]

2.1.3 Надежность
<INSERT>
[Здесь необходимо указать способы обеспечения надежности системы.]

2.1.4 Производительность
<INSERT>
[Здесь описываются характеристики производительности программных и аппаратных решений.]

2.1.5 Безопасность
<INSERT>
[Определите вопросы безопасности данных, системной, сетевой, физической и прочей безопасности.]

2.1.6 Требования к данным
<INSERT>
[Укажите решения вопросов связанных с данными.]

2.1.7 Требования к преобразованию данных
<INSERT>
[Укажите как должно быть реализовано преобразование данных.]

2.1.8 Масштабируемость
<INSERT>
[Опишите, как будут решаться вопросы масштабируемости.]

2.1.9 Удобство поддержки
<INSERT>
[Укажите решения по обеспечению удобства поддержки.]

2.1.10 Требования к пользовательской документации
<INSERT>
[Описывает реализацию он-лайновой пользовательской документации (при ее наличии), помощи, заметок "help about" и т.д.]

2.1.11 Требования к лицензированию
<INSERT>
[Определяет ужесточение требований к лицензированию и прочих требований к ограничению использования.]

3. Функциональное описание решения

3.1 Выбор компонентов, которые необходимо приобрести
<INSERT>
[Этот раздел детально описывает все покупные компоненты, которые будут использоваться в системе, почему этот конкретный компонент был выбран, вопросы лицензирования и совместимости компонента.]

3.2 Интерфейсы
<INSERT>
[Этот раздел определяет интерфейсы, обеспечиваемые продуктом. Он должен содержать сведения о специфике, протоколах передачи данных, аппаратных ресурсах и т.д. То есть обо всем, что позволило бы разрабатывать продукт в соответствии с требованиями интерфейса.]

3.2.1 Пользовательские интерфейс
<INSERT>
[Опишите элементы пользовательского интерфейса, которые будут реализованы в продукте. Составьте список представлений интерфейса на экране. Опишите следующие элементы для каждого представления:

  • Расположение.
  • Экранные области.
  • Меню.
  • Проверки.
  • Опции.
  • Эффекты нажатия кнопок.
  • Кнопки.
  • Навигация.
  • Прочее.]

3.2.2 Аппаратный интерфейс
<INSERT>
[Этот раздел определяет все аппаратные интерфейсы, поддерживаемые продуктом, включая логическую структуру, адресацию в памяти, сети, предполагаемое поведение и т.д.]

3.2.3 Программный интерфейс
<INSERT>
[Этот раздел описывает программные интерфейсы взаимодействия программного обеспечения с другими программными компонентами продукта. Этими компонентами могут быть покупные компоненты, компоненты, используемые повторно и разработанные ранее и прочие компоненты, с которыми данное программное обеспечение должно взаимодействовать.]

3.2.4 Коммуникационный интерфейс
<INSERT>
[Опишите все интерфейсы коммуникаций с другими системами и устройствами.]

3.3 Обработка ошибок
<INSERT>
[Приведите список возможных условий возникновения ошибок и опишите, как они будут обрабатываться.]

3.4 Планирование работ
<INSERT>
[Опишите подробно все запланированные работы, которые могут исполняться автоматически.]

3.5 Источник данных
<INSERT>
[Определите источник данных на уровне полей, все базы данных, технологии, которые планируется использовать количество записей и таблиц. Если возможно укажите местонахождение скриптов, все стандарты именования для этого проекта. Укажите изменения, которые необходимо произвести в базе данных. Требования к локализации.]

3.6 Преобразование данных
<INSERT>
[Подробная информация о преобразовании данных.]

3.7 Отчеты
<INSERT>
[Опишите все отчеты, которые пользователь будет просматривать.]

3.8 Проектные требования и ограничения
<INSERT>
[Этот раздел описывает все требования и ограничения по разработке проекта системы. Проектные ограничения это решения, которые были приняты и которым надо следовать. Примерами могут служить языки программирования, которые предлагается использовать, требования к процессу разработки, средства разработки, требования в архитектуре системы, покупные компоненты, библиотеки классов и т.д.]

4. Оценка ресурсов

<INSERT>
[Приведите здесь высокоуровневую оценку каждого вида ресурсов, необходимых для предоставления вышеописанного решения. Если необходимо, разбейте задачи на подзадачи.]

ЗадачаИмя ресурсаРоль% Использование
Analysis---
Design---
Build---
Test---
Document---


5. Предположения и зависимости

<INSERT>
[Опишите все функциональные или бизнес допущения и предположения, которые были сделаны в начале. Допущение - это нечто, что будучи неправильным, потребует незначительных изменений в будущем. Зависимость - это нечто, что будучи неправильным, в будущем требует пересмотра всей спецификации.]

6. Разрешенные вопросы

<INSERT>
[Список вопросов, относящихся к данным требованиям, разрешенных к настоящему моменту]

7. Открытые вопросы

<INSERT>
[Список вопросов, которые все еще не разрешены. Опишите, как каждый из них будет решаться или почему было принято решение не решать этот вопрос в настоящий момент.]

8. Заметки о пересмотре проекта

<INSERT>
[Примечания, добавления, замечания заказчика и.т.д.]

9. Дополнительная информация

<INSERT>
[Дополнительная информация делает использование Functional Specification более удобным. Она может включать различные приложения, индексы и т.д. При включении приложений Functional Specification должен явно указывать, что эти приложения являются они или нет неотъемлемой частью требований.]

История изменений документа

DateVersionDescriptionAuthor
----



Posted By: vga    36 Comments    С уважением, vga

Trackbacks (0) Permalink


Blog Owner: vga
Contributors: (none)
Blog: View All Entries
Friends
Go: Back/Forward

Calendar

 «   <   »   >  March 2024
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31


Contact vga

Email
Send Email
Private Message
Send private message
MSN Messenger


Yahoo Messenger

AIM Address

ICQ Number

About vga

Joined
Thu Oct 04, 2007 8:22 pm

Location
Санкт-Петербург
Occupation

Interests

Blog

Blog Started
Thu Jan 24, 2008 10:11 am
Total entries
13
Blog Age
5908 days
Total replies
8
Visits
1688251

RSS

RSS Feed