ࡱ> AC>?@5@ bjbj22 MXXXvC$0_0_0_P_d_Rb.fj|f|f|fWg{;======$R`aWgWga|f|fveeeF|f|f;e;e@eB›i|fb D_~ 0_7+fO 0M// eaaO0_C"0_ SUBJECT \* MERGEFORMAT   TITLE \* MERGEFORMAT Test Plan Version <1.0> [Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields (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.] Revision History DateVersionDescriptionAuthor

 Table of Contents  TOC \o "1-3" 1. Introduction  PAGEREF _Toc5330775 \h 4 1.1 Purpose  PAGEREF _Toc5330776 \h 4 1.2 Background  PAGEREF _Toc5330777 \h 4 1.3 Scope  PAGEREF _Toc5330778 \h 4 1.4 Project Identification  PAGEREF _Toc5330779 \h 4 2. Requirements for Test  PAGEREF _Toc5330780 \h 5 3. Test Strategy  PAGEREF _Toc5330781 \h 5 3.1 Testing Types  PAGEREF _Toc5330782 \h 5 3.1.1 Function Testing  PAGEREF _Toc5330783 \h 5 3.1.2 User Interface Testing  PAGEREF _Toc5330784 \h 6 3.1.3 Data and Database Integrity Testing  PAGEREF _Toc5330785 \h 6 3.1.4 Performance Profiling  PAGEREF _Toc5330786 \h 6 3.1.5 Load Testing  PAGEREF _Toc5330787 \h 7 3.1.6 Stress Testing  PAGEREF _Toc5330788 \h 8 3.1.7 Volume Testing  PAGEREF _Toc5330789 \h 9 3.1.8 Security and Access Control Testing  PAGEREF _Toc5330790 \h 10 3.1.9 Failover / Recovery Testing  PAGEREF _Toc5330791 \h 11 3.1.10 Configuration Testing  PAGEREF _Toc5330792 \h 13 3.1.11 Installation Testing  PAGEREF _Toc5330793 \h 13 3.2 Tools  PAGEREF _Toc5330794 \h 14 4. Resources  PAGEREF _Toc5330795 \h 15 4.1 Workers  PAGEREF _Toc5330796 \h 15 4.2 System  PAGEREF _Toc5330797 \h 16 5. Project Milestones  PAGEREF _Toc5330798 \h 16 6. Deliverables  PAGEREF _Toc5330799 \h 17 6.1 Test Model  PAGEREF _Toc5330800 \h 17 6.2 Test Logs  PAGEREF _Toc5330801 \h 17 6.3 Defect Reports  PAGEREF _Toc5330802 \h 17 7. Appendix A: Project Tasks  PAGEREF _Toc5330803 \h 18   TITLE \* MERGEFORMAT Test Plan Introduction Purpose This Test Plan document for the  SUBJECT \* MERGEFORMAT  supports the following objectives: Identify existing project information and the software components that should be tested List the recommended Requirements for Test (high level) Recommend and describe the testing strategies to be employed Identify the required resources and provide an estimate of the test efforts List the deliverable elements of the test project Background [Enter a brief description of the target-of-test (component(s), application, system, etc.) and its goals. Include information such as major function(s) / features, architecture and a brief history of the project. This section should only be about 3 - 5 paragraphs.] Scope [Describe the stages of testing, for example, Unit, Integration, or System, and the types of testing that will be addressed by this plan, such as Function or Performance.] [Provide a brief list of the target-of-tests features, functions that will / will not be tested] [List any assumptions made during the development of this document, which may impact the design, development or implementation of testing] [List any risks or contingencies that may affect the design, development or implementation of testing] [List any constraints affect the design, development, or implementation of testing] Project Identification The table below identifies the documentation and availability, used for developing the test plan: [NOTE: Delete or add items as appropriate.] Document (and version / date)Created or AvailableReceived or ReviewedAuthor or ResourceNotesRequirements Specification( Yes ( No( Yes ( NoUse Case Reports( Yes ( No( Yes ( NoDesign Specifications( Yes ( No( Yes ( NoPrototype( Yes ( No( Yes ( NoUsers Manuals( Yes ( No( Yes ( NoProject Plan( Yes ( No( Yes ( No Requirements for Test The listing below identifies those items (use cases, functional requirements, and non-functional requirements) that have been identified as targets for testing. This list represents what will be tested. [Enter a high level list of the major requirements for test] Test Strategy [The Test Strategy presents the recommended approach to the testing the target-of-test. The previous section, Requirements for Test, described what will be tested, this section describes how the target-of-test will be tested. For each type of test, provide a description of the test and why it is being implemented and executed. If a type of test will not be implemented and executed, indicate in a sentence stating the test will not be implemented / executed and stating the justification, such as This test will not be implemented / executed. This test is not appropriate The main considerations for the test strategy are the techniques to be used and the criterion for knowing when the testing is completed. In addition to the considerations provided for each test below, testing should only be executed using known, controlled databases, in secured environments. ] Testing Types Function Testing [Function testing of the target-of-test should focus on any requirements for test that can be traced directly to use cases (or business functions), and business rules. The goals of these tests are to verify proper data acceptance, processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is based upon black box techniques, that is, verifying the application (and its internal processes) by interacting with the application via the GUI and analyzing the output (results). Identified below is an outline of the testing recommended for each application:] Test Objective:Ensure proper target-of-test functionality, including navigation, data entry, processing, and retrieval.Technique: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.Completion Criteria:All planned tests have been executed. All identified defects have been addressed.Special Considerations:[Identify / describe those items or issues (internal or external) that impact the implementation and execution of function test] User Interface Testing [User Interface testing verifies a users interaction with the software. The goal of UI Testing is to ensure that the User Interface provides the user with the appropriate access and navigation through the functions of the target-of-test. In addition, UI Testing ensures that the objects within the UI function as expected and conform to corporate or industry standards.] Test Objective:Verify the following: Navigation through the target-of-test 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.Technique:Create / modify tests for each window to verify proper navigation and object states for each application window and objects.Completion Criteria:Each window successfully verified to remain consistent with benchmark version or within acceptable standardSpecial Considerations:Not all properties for custom and third party objects can be accessed. Data and Database Integrity Testing [The databases and the database processes should be tested as a sub-system within the  SUBJECT \* MERGEFORMAT . These sub-systems should be tested without the target-of-tests User Interface (as the interface to the data). Additional research into the DBMS needs to be performed to identify the tools / techniques that may exist to support the testing identified below.] Test Objective:Ensure Database access methods and processes function properly and without data corruption.Technique: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)Completion Criteria:All database access methods and processes function as designed and without any data corruption.Special Considerations:Testing may require a DBMS development environment or drivers to enter or modify data directly in the databases. Processes should be invoked manually. Small or minimally sized databases (limited number of records) should be used to increase the visibility of any non-acceptable events. Performance Profiling [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.] Test Objective:Verify performance behaviors for designated transactions or business functions under the following conditions: - normal anticipated workload - anticipated worse case workload Technique:Use Test Procedures developed for Function 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).Completion Criteria: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.Special Considerations: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 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. Load Testing [Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).] [NOTE: Transactions below refer to logical business transactions. These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract.] Test Objective:Verify performance behaviors time for designated transactions or business cases under varying workload conditions. Technique: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.Completion Criteria:Multiple transactions / multiple users: Successful completion of the tests without any failures and within acceptable time allocation.Special Considerations: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. Stress Testing [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 results from competition for shared resource 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.] Test Objective: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 / accounts Worst case transaction volume / mix (see performance testing above). NOTES: The goal of Stress test 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.Technique:Use tests developed for Performance Profiling or Load 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.Completion Criteria: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).Special Considerations: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. Volume Testing [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.] Test Objective: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 / report transactions are executed simultaneously. Technique: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 / 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.Completion Criteria:All planned tests have been executed and specified system limits are reached / exceeded without the software or software failing.Special Considerations:What period of time would be considered an acceptable time for high volume conditions (as noted above)?Security and Access Control Testing [Security and Access Control Testing focus on two key areas of security: Application-level security, including access to the Data Functions System-level Security, including logging into / remote access to the system. Application-level security ensures that, based upon the desired security, actors are restricted to specific functions / 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 actors granted access to the system are capable of accessing the applications and only through the appropriate gateways.] Test Objective:Application-level Security: Verify that an actor can access only those functions / data for which their user type is provided permissions. System-level Security: Verify that only those actors with access to the system and application(s) are permitted to access them.Technique:Application-level: Identify and list each actor type and the functions / data each type has permissions for. Create tests for each actor type and verify each permission by creating transactions specific to each user actor. Modify user type and re-run tests for same users. In each case verify those additional functions / data are correctly available or denied. System-level Access (see special considerations below)Completion Criteria:For each known actor type, the appropriate function / data are available and all transactions function as expected and run in prior function tests Special Considerations: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. Failover / Recovery Testing [Failover / 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 I/O failures or invalid database pointers / keys. Recovery processes are invoked and the application / system is monitored and / or inspected to verify proper application / system / and data recovery has been achieved.] Test Objective: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 databaseTechnique: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 losses 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. Completion Criteria: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.Special Considerations: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). Configuration Testing [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 (e.g. applications, drivers, etc.) and at any one time many different combinations may be active and using different resources.] Test Objective:Verify that the target-of-test functions properly on the required hardware / software configurations.Technique:Use Function Test scripts Open / 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 actors 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. Completion Criteria:For each combination of the target-of-test and non-target-of-test software, all transactions are successfully completed without failure.Special Considerations:What non-target-of-test software is needed is available, accessible on the desktop? 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. Installation Testing [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, and under normal and abnormal conditions. Abnormal conditions include insufficient disk space, lack of privilege to create directories, etc. 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.] Test Objective:Verify that the target-of-test properly installs onto each required hardware configuration, under the following conditions (as required): New Installation, a new machine, never installed previously with  SUBJECT \* MERGEFORMAT  Update machine previously installed  SUBJECT \* MERGEFORMAT , same version Update machine previously installed  SUBJECT \* MERGEFORMAT , older version Technique:Manually or develop automated scripts to validate the condition of the target machine (new -  SUBJECT \* MERGEFORMAT  never installed,  SUBJECT \* MERGEFORMAT  same version or older version already installed). Launch / perform installation. Using a predetermined sub-set of function test scripts, run the transactions.Completion Criteria: SUBJECT \* MERGEFORMAT  transactions execute successfully without failure.Special Considerations:What  SUBJECT \* MERGEFORMAT  transactions should be selected to comprise a confidence test that  SUBJECT \* MERGEFORMAT  application has been successfully installed and no major software components are missing? Tools The following tools will be employed for this project: [NOTE: Delete or add items as appropriate.] ToolTest ManagementDefect TrackingFunctional testingPerformance testingProject Management Resources [This section presents the recommended resources for the  SUBJECT \* MERGEFORMAT  test effort, their main responsibilities, and their knowledge or skill set.] Workers This table shows the staffing assumptions for the project. [NOTE: Delete or add items as appropriate.] Human ResourcesWorkerMinimum Resources Recommended (number of workers allocated full-time)Specific Responsibilities/CommentsTest Manager / Test Project ManagerProvides management oversight Responsibilities: Provide technical direction Acquire appropriate resources Management reportingTest Designer Identifies, prioritizes, and implements test cases Responsibilities: Generate test plan Generate test model Evaluate effectiveness of test effortTesterExecutes the tests Responsibilities: Execute tests Log results Recover from errors Document change requestsTest System AdministratorEnsures test environment and assets are managed and maintained. Responsibilities: Administer test management system Install / manage worker access to test systemsDatabase Administration / Database ManagerEnsures test data (database) environment and assets are managed and maintained. Responsibilities: Administer test data (database) DesignerIdentifies and defines the operations, attributes, and associations of the test classes Responsibilities: Identifies and defines the test class(es) Identifies and defines the test packagesImplementerImplements and unit tests the test classes and test packages Responsibilities: Creates the test classes and packages implemented in the test model. System The following table sets forth the system resources for the testing project. 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 ResourcesResourceName / TypeDatabase ServerNetwork/SubnetTBDServer NameTBDDatabase NameTBDClient Test PC'sInclude special configuration requirementsTBDTest RepositoryNetwork/SubnetTBDServer NameTBDTest Development PC'sTBD[NOTE: Delete or add items as appropriate.] Project Milestones [Testing of  SUBJECT \* MERGEFORMAT  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 and accomplishments.] Milestone TaskEffortStart DateEnd DatePlan TestDesign TestImplement TestExecute TestEvaluate Test Deliverables [In this section list the various documents, tools, and reports that will be created, by whom, delivered to who, and when delivered] Test Model [This section identifies the reports that will be created and distributed from the test model.] Test Logs [Describe the method and tools used to record and report on the test results and testing status.] Defect Reports [In this section, identify the method and tool(s) used to record, track, and report on test incidents and their status.] Appendix A: Project Tasks Below are the test related tasks: Plan Test - Identify Requirements for Test - Assess Risk - Develop Test Strategy - Identify Test Resources - Create Schedule - Generate Test Plan Design Test - Workload Analysis - Identify and Describe Test Cases - Identify and Structure Test Procedures - Review and Access Test Coverage Implement Test - Record or Program Test Scripts - Identify Test-Specific functionality in the design and implementation model - Establish External Data sets Execute Test - Execute Test Procedures - Evaluate Execution of Test - Recover from Halted Test - Verify the results - Investigate Unexpected Results - Log Defects Evaluate Test - Evaluate Test-Case Coverage - Evaluate Code Coverage - Analyze Defects - Determine if Test Completion Criteria and Success Criteria have been achieved  DOCPROPERTY "Company" \* MERGEFORMAT  PAGE   SUBJECT \* MERGEFORMAT  Version: <1.0> TITLE \* MERGEFORMAT Test Plan Date:
 Confidential( DOCPROPERTY "Company" \* MERGEFORMAT Page  PAGE 13 )*+,CDMNP_- M    & ' ( ) * + . / 5 6 N jhNhyFUj/hNhyFUhNmHnHujhNhyFUhNhyFCJaJhNhyFaJhNhyF5hNhyFCJ hNhyFjhNhyFU7+OP^_`   - 2 : F M $$Ifa$.$a$$a$8~M N Z ` j q lffff$Ifkd$$Ifl\ $  04 laq r s t u v lffff$Ifkd$$Ifl\ $  04 lav w x y z { lffff$Ifkd|$$Ifl\ $  04 la{ | } ~  lffff$Ifkd:$$Ifl\ $  04 la + S ljhjb\\\\b  kd$$Ifl\ $  04 la N O P Q R S V W n o  !"'(9:R˽ҴҴ˦ҴҴ˘ˊjhNhyFUjhNhyFUjhNhyFUhNhyFaJjhNhyFU hNhyFhNhyFCJaJhNmHnHujhNhyFUj!hNhyFU4 "WEx5q,VG  D @  RSTUVW\]tu'(@ABCDEJKZ[stu˽˯ˡ˓˅j hNhyFUjb hNhyFUjhNhyFUjphNhyFUjhNhyFU hNhyFhNhyFCJaJhNmHnHujhNhyFUj~hNhyFU4uvwx}~/01345;<RSklmopqwxٽٯ١ٓj8 hNhyFUj hNhyFUjF hNhyFUj hNhyFUjT hNhyFU hNhyFhNhyFCJaJjhNhyFUhNmHnHu: &'(*+,/078PQRTUVXYklm´¦˜ŠjhNhyFUjhNhyFUj hNhyFUj* hNhyFU hNhyFhNhyFaJhNhyFCJaJhNmHnHujhNhyFUj hNhyFU5()ABCEFGIJcde}~˽˯ˡҘҘˊjhNhyFUhNhyFaJjyhNhyFUjhNhyFUjhNhyFU hNhyFhNhyFCJaJhNmHnHujhNhyFUjhNhyFU6   &'89?@DEKLRSijpquv|}ɾɾɾɾɾ johNhyFmH sH hNhyFmH sH hNhyF5OJQJmH sH  hNhNhNhyF6B*ph hNhyFjhNhyFUE,Ew@-a4$If  & F0^`0.. & F; %`% $%&B<<<<<4$Ifkdk$$Ifl4rZ $Y' 5  \\\\\2&4 laf4p2&'8DPQR}wwwww4$Ifkd$$Ifl4rZ $Y' 5 &4 laf4RSiu}wwwww4$Ifkd:$$Ifl4rZ $Y' 5 &4 laf4}wwwww4$Ifkd$$Ifl4rZ $Y' 5 &4 laf4}wwwww4$Ifkd$$Ifl4rZ $Y' 5 &4 laf4}wwwww4$Ifkd>$$Ifl4rZ $Y' 5 &4 laf4`g!!!""##4###D%&&/'0'''((((((((((())***y+z+++&-/00+2,2w3x3666Q8b8999::::;;hNhNmH sH jhNhyFUhNhyFOJQJmH sH  hNhN johNhyFmH sH hNhyFmH sH  hNhyFG,xr}{{vtrtvrrrrr. & F4kd$$Ifl4rZ $Y' 5 &4 laf4 !!&!!!!"9""pff 4 & F2$Ifrkd$$Ifl4    0v $ t0    4 laf44$If4. & F  & F0^`0 """""#|rr 4 & F6$If4$Ifrkd9$$Ifl4    0v $ t0    4 laf4 4 & F2$If##4##.$If4$Ifrkd$$Ifl4    0v $ t0    4 laf4####D%E%U%k%<&&zzpp 4 & F7$If4$If4^.4rkd$$Ifl4    0v $ t0    4 laf4 &&&/'4$Ifrkd"$$Ifl4    0v $ t0    4 laf4/'0'E''4$Ifrkd$$Ifl4    0v $ t0    4 laf4'''(4$Ifrkdh$$Ifl4    0v $ t0    4 laf4(((7()))*4$If.4rkd $$Ifl4    0v $ t0    4 laf4)***5**y+4$Ifrkd$$Ifl4    0v $ t0    4 laf4y+z+++4$IfrkdQ$$Ifl4    0v $ t0    4 laf4++,y,,&-4$Ifrkd$$Ifl4    0v $ t0    4 laf4&-'-(-?-.///_0~000}wwwww4$If4.  & Frkd$$Ifl4    0v $ t0    4 laf4 0000p1+24$Ifrkd:$$Ifl4    0v $ t0    4 laf4+2,2A22w34$Ifrkd$$Ifl4    0v $ t0    4 laf4w3x333444Z55@66||| 4 & F8$If4$Ifrkd$$Ifl4    0v $ t0    4 laf4 66668999::~~~4$If.4rkd# $$Ifl4    0v $ t0    4 laf4 ::*:f::4$Ifrkd $$Ifl4    0v $ t0    4 laf4:::;4$Ifrkdi!$$Ifl4    0v $ t0    4 laf4;;;#<x<4$Ifrkd "$$Ifl4    0v $ t0    4 laf4;x<>??0A1ABBCCDDDF.G5GGG_H`HJJJJ6KNOOQQORPR0SZZeeVf\f-g4gjjjjjjjjjjkk4k5kNkOk]k^kkkkkllll/l0l>l?lllmmmmqmrmmmmjhNhyFU hNhNhNhNmH sH  hNhyFhNhyFmH sH Rx<y<z<<K>>>>?T???<@}wwmmmm 4 & F($If4$If.  & Frkd"$$Ifl4    0v $ t0    4 laf4 <@=@@0A1Ao?oAoooooooopppppppqq:r;rrrnsosttttuvvvvvvvvwwwwww*w+w=w>w?w]w^wowpwwwwwwwhNhyFB*mH phsH hNhyFCJmH sH hNhyFmH sH  hNhyFjhNhyFUNdnenfnlnnnnnnzxvxpg 4$$Ifa$4$If.  & F0^`0 & Frkd1$$Ifl4    0v $s  t0    4 laf4nnnn| 4$$Ifa$4$Ifskd2$$IfTl    0 R 6  t0    4 laTnnnn| 4$$Ifa$4$Ifskd,3$$IfTl    0 R 6 t0    4 laTnnoo| 4$$Ifa$4$Ifskd3$$IfTl    0 R 6 t0    4 laToo%o&o| 4$$Ifa$4$Ifskdr4$$IfTl    0 R 6 t0    4 laT&o'o:o;o| 4$$Ifa$4$Ifskd5$$IfTl    0 R 6 t0    4 laT;oo| 4$$Ifa$4$Ifskd5$$IfTl    0 R 6 t0    4 laT>o?o@oAo| 4$$Ifa$4$IfskdF6$$IfTl    0 R 6 t0    4 laTAoBoCoMoopApnpopp~~x4$If. & Fskd6$$IfTl    0 R 6 t0    4 laT pppppp4$IfEkd~7$$Ifl4#H$ \ 4 laf4p ppqq6qHqdqqq~xxxxnnn 4 & F+$If4$Ifkd7$$Ifl4F#  , \\\    4 laf4pqqqqqqqrr:r 4 & F,$If4$If[kd8$$Ifl4F#  ,    4 laf4 :r;rBrCrVrhrvrrrr 4 & F-$If4$If[kd;9$$Ifl4F#  ,    4 laf4 rrrr ss?sns 4 & F.$If4$If]kd9$$Ifl4(F#  ,    4 laf4nsossssst 4 & F/$If4$If[kd:$$Ifl4F#  ,    4 laf4tt(t)ttttt 4 & F0$If4$If[kdt;$$Ifl4F#  ,    4 laf4tttt1uCuu 4 & F1$If4$If[kd<$$Ifl4F#  ,    4 laf4uuuuuvvvvvTEkd=$$Ifl4* \ 4 la<f4p 4$If[kd<$$Ifl4F#  ,    4 laf4 vvvvvwwMHkd/>$$Ifl40e  4 la<f44$Ifckd=$$Ifl40e   \\4 la<f4pwwwww&w*wgHkdI?$$Ifl40e  4 la<f44$IfHkd>$$Ifl40e  4 la<f4*w+wwkwowgHkdc@$$Ifl40e  4 la<f44$IfHkd?$$Ifl40e  4 la<f4owpwwwwwwgHkdA$$Ifl40e  4 la<f44$IfHkd@$$Ifl40e  4 la<f4wwwwwwwgHkdB$$Ifl40e  4 la<f44$IfHkdB$$Ifl40e  4 la<f4wwwwxx+x,x:x;xy2y3y@yAyPyQycydytyuyyy{~~~~~~~~~    '(67TUlmvwǷǝhNjhyFU hyF0JjhyF0JUhyFhN5CJ$OJQJhyF5CJ$OJQJjhyF5CJ$OJQJU hyFCJhNhyF5hNhyF5\mH sH jhNhyFU hNhyFhNhyFmH sH 2wwwwxyyyy)y2y 4$$Ifa$.Hkd9C$$Ifl40e  4 la<f4 2y3y=y>y?y@yhbbbb4$IfkdC$$IfTl\ FH *T04 laT@yAyMyNyOyPyhbbbb4$IfkdkD$$IfTl\ FH *T04 laTPyQy`yaybycyhbbbb4$Ifkd-E$$IfTl\ FH *T04 laTcydyqyrysytyhbbbb4$IfkdE$$IfTl\ FH *T04 laTtyuyyyyyhbbbb4$IfkdF$$IfTl\ FH *T04 laTyyyyz%zzzz{}{hfdb`b[b[b & F .kdsG$$IfTl\ FH *T04 laT }{{{{{{ |%|7|L|X|l||||| }X}w}}}}}} ~~(~4` 4hh^h`h4 & F1h^h(~F~`~r~~~~~~   8S oD($If]D$Ifh]h&`#$ $&dPa$ $dN4`STx$Iflkd5H$$Ifl0$k 04 la20.YkdYI$$Ifl$V%04 la$IflkdH$$Ifl0$k 04 laca_]_a_kdI$$IflF H$Z Z Z 0    4 la $$Ifa$ $$Ifa$ h$If]h w hNhyFhN0JmHnHu hyF0JjhyF0JUhNjhyFU jhyFhyF&0&P/ =!"#$%0#0:&P/ =!"#$%$$If!vh5 555 #v #v#v#v :V l05 555 4$$If!vh5 555 #v #v#v#v :V l05 555 4$$If!vh5 555 #v #v#v#v :V l05 555 4$$If!vh5 555 #v #v#v#v :V l05 555 4$$If!vh5 555 #v #v#v#v :V l05 555 4yDyK  _Toc5330775yDyK  _Toc5330776yDyK  _Toc5330777yDyK  _Toc5330778yDyK  _Toc5330779yDyK  _Toc5330780yDyK  _Toc5330781yDyK  _Toc5330782yDyK  _Toc5330783yDyK  _Toc5330784yDyK  _Toc5330785yDyK  _Toc5330786yDyK  _Toc5330787yDyK  _Toc5330788yDyK  _Toc5330789yDyK  _Toc5330790yDyK  _Toc5330791yDyK  _Toc5330792yDyK  _Toc5330793yDyK  _Toc5330794yDyK  _Toc5330795yDyK  _Toc5330796yDyK  _Toc5330797yDyK  _Toc5330798yDyK  _Toc5330799yDyK  _Toc5330800yDyK  _Toc5330801yDyK  _Toc5330802yDyK  _Toc5330803!$$If!vh5 55555 #v #v#v5#v :V l4 \\\\\2&5 5555 / 4af4p2$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh5 55555 #v #v#v5#v :V l4&5 5555 / 4af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh55#v#v:V l4 t0    554af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l t0    5s 54a$$If!vh5s 5#vs #v:V l t0    5s 54a$$If!vh5s 5#vs #v:V l t0    5s 54a$$If!vh5s 5#vs #v:V l t0    5s 54a$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5s 5#vs #v:V l4 t0    5s 54af4$$If!vh5 56 #v #v6 :V l t0    5 56 /  4T$$If!vh5 56 #v #v6 :V l t0    5 56 / 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4T$$If!vh5 56 #v #v6 :V l t0    5 56 4Tz$$If!vh5H$#vH$:V l4 \ 5H$/ 4f4p $$If!vh5 5 5,#v #v,:V l4 \\\5 5,/ 4f4py$$If!vh5 5 5,#v #v,:V l45 5,/ 4f4$$If!vh5 5 5,#v #v,:V l45 5,/ / / / 4f4$$If!vh5 5 5,#v #v,:V l4(5 5,/ / / / / / / / 4f4$$If!vh5 5 5,#v #v,:V l45 5,/ / / / / 4f4$$If!vh5 5 5,#v #v,:V l45 5,/ / / / 4f4y$$If!vh5 5 5,#v #v,:V l45 5,/ 4f4y$$If!vh5 5 5,#v #v,:V l45 5,/ 4f4$$If<!vh5*#v*:V l4 \ 5*/ 4a<f4p $$If<!vh5 5 #v :V l4 \\5 / 4a<f4p$$If<!vh5 5 #v :V l45 / / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / 4a<f4$$If<!vh5 5 #v :V l45 / / / / 4a<f4h$$If<!vh5 5 #v :V l45 / 4a<f4$$If!vh5 5*5T5#v #v*#vT#v:V l0,5 5*5T54T$$If!vh5 5*5T5#v #v*#vT#v:V l05 5*5T54T$$If!vh5 5*5T5#v #v*#vT#v:V l05 5*5T54T$$If!vh5 5*5T5#v #v*#vT#v:V l05 5*5T54T$$If!vh5 5*5T5#v #v*#vT#v:V l05 5*5T54T$$If!vh5 5*5T5#v #v*#vT#v:V l05 5*5T54T$$If!vh55k #v#vk :V l055k 4$$If!vh55k #v#vk :V l055k 4z$$If!vh5V%#vV%:V l05V%4$$If!vh5Z 5Z 5Z #vZ :V l05Z / 4:B@B Normal 1$d_HmH sH tH T@T Heading 1$ & F'x<@&5CJOJQJ<@< Heading 2  & F'@&CJB@B Heading 3  & F'@& 56CJ@@@ Heading 4  & F'@&5CJD@D Heading 5 & F'<@&CJH@H Heading 6 & F'<@&6CJ@@@ Heading 7 & F'<@&D@D Heading 8 & F'<@&6J @J Heading 9 & F'<@& 56CJDA@D Default Paragraph FontVi@V  Table Normal :V 44 la (k(No List POP Paragraph2$P^a$B*mH sH uB>@B Title$da$5CJ$OJQJPJ@P Subtitle $<a$6CJ$OJQJmH sH uF@"F Normal Indent|^`|>@> TOC 1 $<]>@> TOC 2 $]^:@: TOC 3 $`^`4@b4 Header  !4 @r4 Footer  !.)@. Page NumberO Bullet1p & FP>T?^`PO Bullet2p & F>Th?^`B* 6O6 Tabletext $x>B@> Body Text$x^@Y@  Document Map-D OJQJD&D Footnote ReferenceCJH*ff  Footnote Text&$$h((&d^h` CJOJQJXOX Main Title $d<a$5CJ KHOJQJ@O@ Paragraph1!$dPa$HO"H Paragraph3"$dP^a$HO2H Paragraph4#$dP^a$.. TOC 4 $X^X.. TOC 5 % ^ .. TOC 6 &^.. TOC 7 '^.. TOC 8 (x^x.. TOC 9 )@^@8P@8 Body Text 2*6B*NC@N Body Text Indent +^ 6>*B*HOH Body,$dx1$a$OJQJtH ubOb Bullet4-$ & FQ hdx1$]h^a$OJQJ>O> InfoBlue.x^6B*0U@0 Hyperlink>*B*<O< SubTitle01$ CJOJQJ>O> RevisionHist 11$d.L@". Date 21$d`O2` Hierarchy+3 pdx1$]OJQJLOBL body text4$dx_HmH sH tH >'Q> Comment ReferenceCJ>b>  Comment Text 61$dBZ@rB Plain Text 71$dOJ QJ JOJ Project8$d1$a$5CJ$OJQJROR CompanyName9$d1$a$5CJ$OJQJxX(X+OP^_`-2:FMNZ`jqrstuvwxyz{|}~+S"WEx5q , V  G , E w @-a $%&'8DPQRSiu,xr&94DEUk</0E   7 !!)"*"5""y#z####$y$$&%'%(%?%&'''_(~((((((p)+*,*A**w+x+++4,,Z--@.....0111222*2f2222333#4x4y4z44K66667T777<8=880919<9{99:::;;;;p<<<<<>>>.??^@_@`@k@@cABB3BBBB6C7C[CCC6D0FFFFuGGGHpHHnIIIINJOJPJhJ0K1K2KNKLLNNNjOOOO+PPPPPPQQZRSSxT UVVVVWWXX?YYYYY`[a[q[[[[[\#]z]{]]^^2^^^____aaaGbbcncpcqc|crdddddSeTeledfeffflfffffffffffffggg%g&g'g:g;gg?g@gAgBgCgMgghAhnhohhhhhhhhii6iHidiiiiiiiiijj:j;jBjCjVjhjvjjjjjjj kk?knkokkkkkll(l)llllllll1mCmmmmmmnnnnnnnnnoooooo&o*o+ookooopooooooooooooooopqqqq)q2q3q=q>q?q@qAqMqNqOqPqQq`qaqbqcqdqqqrqsqtquqqqqqqqqr%rrrrs}ssssss t%t7tLtXtlttttt uXuwuuuuuu vv(vFv`vrvvvvvvwww w w w8wSwTwxwwwwwwwwwwxxxxxxx x8000000.0.0.000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00000000000000000000000000000000 0' 0' 0 0 ; .0 ; .0 ; .0 ; .0 ; .0 ' 0 .0w ' 0 .0 .0 .0 .0 .0  0 0.040 40 40 40 40 0 40 40 40 40 40 0 40 40 40 40 40 0 40 40 40 40 40 0 40 40 40 40 40 0 40 40 40 40 40 0 40 40 40 40 40 0 4040 00.00 0.0.0.0.0.0 0( 0.04040 40 0 40 402 402 402 40 0 40 6 406 40 0 40 .0 0 40(' 0.04040 407 407 40 0 40 40 0 40 40 0 40 40 0 40(' 0.0 40  40  0  40  40 40  0  40  40  0  40  40 40 40  0  (0(' 0.0(%.0(%40(%40(% 40(%40(%40(%40(% 0(% 40(% 40(%40(%40(% 0(% 40(% 40(%40(% 0(% 40(% 40(%40(%8 40(%8 40(%8 40(%40(%40(% 0(% 40(%(' 0.0..0.0.40. 40.40. 0. 40. 40.40. 0. 40. 40. 0. 40. 40.40. 0. (0(' 0.0z4.0z40z440z4 40z4( 40z4( 40z4( 40z4( 40z440z440z440z4 0z4 40z4 40z440z440z4 0z4 40z4 40z4 0z4 40z4 40z440z440z4 0z4 40z4(' 0.0<0<40< 40<9 40<9 40<40< 0< 40< 40<40<40< 0< 40< 40< 0< 40< 40< 0< (' 0.07C% .07C% .07C.07C.07C07C407C 407C407C 07C 407C 407C407C407C407C 07C 407C 407C407C 07C 407C 407C 07C (0(' 0.02K.02K.02K02K02K 02K) 02K) 02K) 02K) 02K) 02K) 02K) 02K 02K 02K 02K* 02K* 02K* 02K* 02K02K02K02K02K 02K 02K 02K 02K 02K 02K02K02K 02K (0(' 0 .0Y0Y0Y 0Y 0Y 0Y 0Y0Y0Y0Y 0Y 0Y 0Y 0Y 0Y 0Y0Y0Y0Y 0Y (' 0 .0|_0|_0|_ 0|_0|_0|_0|_0|_ 0|_ 0|_ 0|_0|_0|_ 0|_ 0|_ 0|_ 0|_ 0|_ 0|_ 0|_ 0 00Xf.0Xf0Xf40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 40Xf 40Xf 0Xf 0' 0.05g' 05g5g0g.0g0g40g 0g 40g 40g40g 40g 0g 40g 40g 40g40g+ 40g+ 40g+ 40g 0g 40g40g 40g 40g40g, 40g, 40g, 40g 0g 40g 40g 40g40g- 40g- 40g- 40g- 40g 0g 40g 40g 40g40g. 40g. 40g 0g 40g 40g 40g40g/ 40g 0g 40g 40g 40g40g0 40g0 40g 0g 40g 40g 40g40g1 40g 0g 0g' 05g5g0|m0|m40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m 40|m 40|m 0|m .0|m0|m' 0.0o0o40o 40o 40o 40o 0o 40o 40o 40o 40o 0o 40o 40o 40o 40o 0o 40o 40o 40o 40o 0o 40o 40o 40o 40o