Standard number: JR/T 0175-2019
Standard name: Software testing specification for securities and futures industry
English name: Specification for securities and futures industry software test ||
tt||Standard format: PDF
Release time: 2019-09-30
Implementation time: 2019-09-30
Standard size: 1.16M
Standard introduction: This standard specifies the overall requirements, unit testing, integration testing, system testing, system integration testing, acceptance testing and other testing activities in the construction process of information systems in the securities and futures industry.
This standard applies to the securities and futures market core institutions (hereinafter referred to as market core institutions), securities and futures fund operating institutions (hereinafter referred to as market operating institutions), securities and futures information technology service institutions (hereinafter referred to as market service institutions) to carry out securities and futures computer software and external information system testing work.
Note 1: Market core institutions, such as securities and futures exchanges, securities registration and settlement institutions, futures market monitoring centers, etc.
Note 2: Market operating institutions, such as securities companies, futures companies, fund companies, etc.||
tt||Note 3: Market service institutions, such as software developers, information providers, service providers, etc.
2 Normative referenced documents
The following documents are indispensable for the application of this document. For all referenced documents with dates, only the versions with the dates noted are applicable to this document. For any undated referenced documents, the latest version (including all amendments) applies to this document
GB/T11457-2006 Information technology software engineering terminology
GB/T15532-2008 Computer software testing specification
GB/T29834.3-2013 System and software maintainability Part 3: Test methods
2016 Core technical indicators of capital market transaction and settlement system
This standard was drafted in accordance with the rules given in GB/T1.1-2009.
This standard is proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4)
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (AC/TC180)
The drafting units of this standard are: Information Center of China Securities Regulatory Commission, Securities and Fund Institutions Supervision Department of China Securities Regulatory Commission, Dalian Commodity Exchange, Shanghai Stock Exchange, Shenzhen Stock Exchange, Shanghai Futures Exchange, Zhengzhou Commodity Exchange, China Financial Futures Exchange, Securities and Futures Industry Information Technology Testing Center (Dalian), China Galaxy Securities Co., Ltd., and Southern Fund Management Co., Ltd.
This standard specifies the overall requirements, unit testing, integration testing, system testing, system integration testing, acceptance testing and other testing activities in the process of information system construction in the securities and futures industry. This standard is applicable to the securities and futures industry market core institutions, securities and futures fund operating institutions, and securities and futures information technology service institutions to carry out securities and futures industry computer software and external information system testing. Note 1: Market core institutions, such as securities and futures exchanges, securities registration and settlement institutions, futures market monitoring centers, etc.; Note 2: Market operating institutions, such as securities companies, futures companies, fund companies, etc.; Note 3: Market service institutions, such as software developers, information providers, service providers, etc.
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4).
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180).
The drafting units of this standard: Information Center of China Securities Regulatory Commission, Securities and Fund Institutions Supervision Department of China Securities Regulatory Commission, Dalian Commodity Exchange, Shanghai Stock Exchange, Shenzhen Stock Exchange, Shanghai Futures Exchange, Zhengzhou Commodity Exchange, China Financial Futures Exchange, Securities and Futures Industry Information Technology Testing Center (Dalian), China Galaxy Securities Co., Ltd., and Southern Fund Management Co., Ltd.
The main drafters of this standard are: Zhang Ye, Liu Tiebin, Jiang Dongxing, Zhou Yunhui, Ma Chen, Gao Hongjie, Wang Kai, Guo Fu, Chen Nan, Wang Fenghai, Xu Qiang, Xu Haitao, Liu Jun, Sun Ruichao, Lu Suyuan, Jiang Kai, Chen Yan, Yu Huali, Wan Chunbo, Gu Junmei, Chen Liang, Zou Xingzhong, Xu Ling, Yu Sanlu, Liu Xiangfu, Lu Jidong, Dai Peng, Liu Jin, Wang Xuanxuan, Dong Lin, Xu Yan, Liu Jieru, Han Xiuling, Deng Zhiyuan, Liu Dan, Tang Peilai, Deng Tingxun, Qiu Xing, Niu Yunfeng.
The following documents are indispensable for the application of this document. For any dated referenced document, only the version with the date is applicable to this document. For any undated referenced document, the latest version (including all amendments) is applicable to this document.
GB/T 11457-2006 Information technology software engineering terminology
GB/T 15532-2008 Computer software testing specification
GB/T 29834.3-2013 System and software maintainability Part 3: Test methods
JR/T 0145-2016 Core technical indicators of capital market transaction and settlement system
Foreword III
Introduction IV
1 Scope1
2 Normative references1
3 Terms and definitions1
4 General requirements2
5 Unit testing17
6 Integration testing18
7 System testing20
8 System integration testing21
9 Acceptance test21
Appendix A (Normative Appendix) Test process24
A1 Test estimation24
A2 Test plan24
A3 Test design24
A4 Test execution26
A5 Test report26
Appendix B (Informative Appendix) Software test template28
B1 Test effort estimate28
B2 Test plan29
B3 Test requirements30
B4 Test cases31
B5 Test defect list32
B6 Review Record33
B7 Test Summary Report33
B8 Manager Report35
B9 Milestone Summary Report36
Appendix C (Normative Appendix) Testing Technology38
C1 Black Box Testing38
C2 White Box Testing44
C3 Gray Box Testing45
Appendix D (Normative Appendix) Static Testing Method46
D1 Overview46
D2 Review46

Appendix E (Normative Appendix) Business Classification49
Appendix F (Normative Appendix) Defect Management50
F1 Purpose of Defect Management50
F2 Life Cycle of Defect Management50
F3 Defect Management Flowchart52
F4 Defect severity classification53
F5 Defect priority classification53
F6 Root cause examples53
References55

ICS03.060
TiikAa~cJouakAa
Financial Industry Standard of the People's Republic of China
JR/T 0175—2019
Specification for securities and futures industry software test2019-09-30 Release
China Securities Regulatory Commission
2019-09-30 Implementation
TiiKAa~cJouaKAa-
Introduction,
2 Normative references
3 Terms and definitions..
4 General requirements...
5 Unit test
6 Integration test.
7 System test.
8 System integration test.
9 Acceptance test.
Appendix A (Normative Appendix)
A.1 Test estimation...
A.2 Test plan.
A.3 Test design.
A.4 Test execution..
A.5 Test report
iikAa~cJouakAa-
Test process,
Appendix B (Informative Appendix) Software Test Template B.1 Test Effort Estimate.
B.2 Test plan
B.3 Test requirements
B.4 Test cases...
B.5 Test defect list.
B.6 Review records....
B.7 Test summary report.||tt ||B.8 Manager’s report
B.9 Milestone summary report
Appendix C (Normative Appendix) Testing techniques
C.1 Black box testing.
C.2 White box testing..
C.3 Grey box testing
Appendix D (Normative Appendix) Static testing methods D.1 Overview
D.2 Review.
JR/T0175—2019
JR/T0175—2019
iiKAa~cJouakAa-
Appendix E (Normative Appendix) Business classification
Appendix F (Normative Appendix) Normative Appendix) Defect Management
F.1 Purpose of Defect Management..
F.2 Life Cycle of Defect Management..bzxZ.net
F.3 Defect Management Flowchart..
F.4 Defect Severity Classification.
F.5 Defect Priority Classification.
F.6 Root Cause Examples.
References
TiiKAacJouaKAa
This standard was drafted in accordance with the rules given in GB/T1.1-2009. This standard was proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4). This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180). JR/T0175—2019
The drafting units of this standard are: Information Center of China Securities Regulatory Commission, Securities and Fund Institutions Supervision Department of China Securities Regulatory Commission, Dalian Commodity Exchange, Shanghai Stock Exchange, Shenzhen Stock Exchange, Shanghai Futures Exchange, Zhengzhou Commodity Exchange, China Financial Futures Exchange, Securities and Futures Industry Information Technology Testing Center (Dalian), China Galaxy Securities Co., Ltd., and Southern Fund Management Co., Ltd.
The main drafters of this standard are: Zhang Ye, Liu Tiebin, Jiang Dongxing, Zhou Yunhui, Ma Chen, Gao Hongjie, Wang Kai, Guo Guo, Chen Nan, Wang Fenghai, Xu Qiang, Xu Haitao, Liu Jun, Sun Ruichao, Lu Suyuan, Jiang Kai, Chen Yan, Yu Huali, Wan Chunbo, Gu Junmei, Chen Liang, Zou Xingzhong, Xu Ling, Yu Sanlu, Liu Xiangfu, Lu Jidong, Dai Peng, Liu Jin, Wang Xuanxuan, Dong Lin, Xu Yan, Liu Jieru, Han Xiuling, Deng Zhiyuan, Liu Dan, Tang Peilai, Deng Tingxun, Qiu Xing, and Niu Yunfeng.
JR/T0175—2019
iiKAacJouaKAa
The development and smooth operation of the securities and futures market are highly dependent on industry information systems. Standardizing and unifying the testing standards of industry information systems will help standardize the testing management of industry information systems, improve the standardization of industry software testing processes, and promote the overall improvement of industry software testing levels, thereby reducing the operating risks of industry information systems and promoting the sustainable and healthy development of the securities and futures industry. This standard has distinct industry characteristics, closely combining industry experience, practice and testing theory, making the standard easier to implement and implement, and can effectively guide industry software testing activities and improve testing quality. Among them: a) Test management and test processes are compiled based on the "CMMI Software Capability Maturity Integrated Model" and the "TMMI Test Maturity Model", and on this basis, the following content adapted to industry characteristics is provided: 1) Provide work requirements for each test stage to guide the testing work in more detail, see 4.2.1: Clarify the specifications and basic content of each test document and provide reference Template, see 4.2.2 and Appendix B; 2)
Provide test management details to clarify the specific requirements and implementation content of each management work so that the test management work can be carried out effectively, 3)
See 4.6;
Refine the work content and requirements of each stage in the test process according to industry characteristics, see Appendix A; 4)
Refine the test entry/exit requirements of each test type and test level to guide the specific test work in more detail, 5)
See 4.5, 5.5, 6.5, 7.5, 8.5, 9.5. The basic requirements for system content and test type, test level and test type follow GB/T15532-2008 "Computer Software Testing Specifications" and clarify the following relationships based on industry characteristics: The relationship between system content and test type is convenient for industry organizations to select appropriate test types based on the test content that may be involved in software products, and at the same time add four test types: emergency drills, networking tests, full market tests and selection tests. 2) The corresponding relationship between test levels and test types is convenient for industry organizations to select appropriate test levels and test types based on their roles, software product characteristics and other actual conditions, to ensure that industry organizations perform their testing duties and ensure the quality of software products. c) The content of this standard complies with the audit requirements related to software testing in the series of standards of JR/T0146-2016 (all parts) "Guidelines for Auditing Information Systems in Securities and Futures Industry"
1 Scope
iiKAacJouaKAa
Software Testing Specifications for Securities and Futures Industry
JR/T0175—2019
This standard specifies the content of testing activities such as overall requirements, unit testing, integration testing, system testing, system integration testing, and acceptance testing in the process of building information systems in the securities and futures industry. This standard applies to the market core institutions of the securities and futures industry (hereinafter referred to as market core institutions), securities and futures fund operating institutions (hereinafter referred to as market operating institutions), and securities and futures information technology service institutions (hereinafter referred to as market service institutions) to carry out computer software and external information system testing in the securities and futures industry. Note 1: Market core institutions, such as securities and futures exchanges, securities registration and settlement institutions, futures market monitoring centers, etc.; Note 2: Market operating institutions, such as securities companies, futures companies, fund companies, etc.; Note 3: Market service institutions, such as software developers, information providers, service providers, etc. Normative references
The following documents are indispensable for the application of this document. For dated references, only the version with the date is applicable to this document. For undated references, the latest version (including all amendments) is applicable to this document. GB/T11457-2006 Information Technology Software Engineering Terminology GB/T15532-2008 Computer Software Testing Specification GB/T29834.3-2013 System and Software Maintainability Part 3: Test Methods JR/T0145-2016 Core Technical Indicators for Capital Market Trading and Settlement Systems 3 Terms and Definitions
The terms and definitions defined in GB/T11457-2006 and the following terms and definitions are applicable to this document. For ease of use, some terms and definitions in GB/T11457-2006 are repeated below 3.1
Test leveltestlevel
According to the software development life cycle, test objects and testers, the testing activities in the software life cycle are divided into different levels.
Test processtestprocess
The process of two complete test tasks going through in sequence. 3.3
Test casetestcase
A collection of test inputs, execution operations, and expected results written for a specific goal. Note: Rewrite GB/T11457-2006, definition 2.16953.4
Test cyclestestcycles
The number of times all executable test cases planned in the project are executed once on a complete and full release version. 1
JR/T0175—2019
iiKAacJouakAa
Production readiness testBefore the launch of new systems, new businesses, and new products, it is organized by the core market institutions and participated in by all market participants to simulate the first-day behavior of the system/business/product on the production environment. 3.6
The third-party testing instituteThe third-party testing institute is a professional testing institution that is independent of the interests of users and product developers and conducts objective quality inspections on products according to relevant standards or specifications. 3.7
Tailor
Adjust, add, delete, replace, change the order of relevant test activities, test methods, test content, test types, test output documents, etc.
4 General requirements
4.1 Test purpose
Verify that the software meets the software quality requirements of the software development contract, system/subsystem design documents, system requirements specifications, system design specifications, product specifications, operation and maintenance manuals, and operation manuals. Discover software defects through testing to provide a basis for the quality evaluation of software products. 4.2 Test process
4.2.1 Work requirements for the test phase
Tests of various test levels and test types should follow this test process. This test process is divided into five stages: test estimation, test planning, test design, test execution, and test report. The activities, inputs and outputs of each stage are shown in Appendix A. The work requirements to be followed in each test stage are shown in Table 1. Table 1 Work requirements
Test phase
Test estimation
Test plan
Work requirements
a) The test scope of functional testing and non-functional testing is reasonable, comprehensive, and without redundancy.b) When estimating the workload, the test strategy selection is reasonable and effective;c) The test workload estimation of both functional testing and non-functional testing has been completed, and there is sufficient basis for the estimation:d) If there is other work such as test tool development, acceptance test support, test management, etc., the test workload estimation has been completed, and there is sufficient basis for the estimation.
a) Clarify the functional and non-functional test scope, test strategy, and entry/exit requirements for test execution: b) When there is a significant difference between the test strategy and the test effort estimate, there should be a reasonable explanation: c) The detailed test schedule is reasonable and the milestone time points are clear to avoid insufficient or excessive testing d) The test environment deployment strategy meets the system planning requirements, and the name, version and purpose of the test tools used are clearly described; e) Clarify the risks that may occur in the testing activities, their impact and emergency measures: f) Clarify the problem management process, change management process, progress management process, and defect management process in the testing process Test phase
Test design
Test execution
Test Report
TriKAa~cJouaKAa
Table 1 Work requirements (continued)
Work requirements
JR/T0175—2019
a) Test requirements: should cover 100% of business requirements and system requirements specifications, and appropriately refer to relevant development design documentsb) Test cases: should cover 100% of test requirements or cover 100% of relevant design and requirement documents according to different test levels, such as unit tests and integration tests covering relevant development design documents, system tests covering system requirements specifications, etc.: c) The design of non-functional test scenarios should fully consider the amount of business data that may be affected, and it should be valid in the real production environment and testable in the test environment.
a) Clearly record the execution results of each test case, and the reasons for non-execution of the unexecuted cases should be stated; b) For core and important systems and functions, the test execution process should be recorded by screenshots or logs: c) Defects and problems found during the execution should be recorded in the defect management tool or defect list in a timely manner and handled in a timely manner. There should be no defects other than the final state after the test. a) Clarify the test scope of functions and non-functions. If there are differences with the test plan, an explanation can be given: b) Clarify the test conclusions, describe the specific passing standards and actual test results from the functional and non-functional perspectives, and give a conclusion on whether the test is passed:
c) Describe the deployment of the test environment and the difference analysis between the test environment and the production environment d) Clarify the test version, test execution status, and summarize and analyze the defects: e) Provide improvement suggestions and lessons learned to provide reference for subsequent work. Test document specifications
The output documents of each test phase should include the basic content shown in Table 2, which can be appropriately tailored according to actual needs. For specific templates, see Appendix B.
Table 2 Basic contents of the document
Test estimation
Test plan
Test design
Test execution
Test report
Test management
Output document
Test workload estimate
Test plan
Test requirements
Test cases
Test defect list
Test execution results
Test summary report
Manager's report
Milestone summary report
Basic contents of the document
Test design complexity, test execution complexity, estimated number of test cases, test design workload, test execution workload, non-functional test workload, etc. of each system module, test objectives, test scope, test strategy, test schedule, test environment, test method, test management, test report, etc.
Required functions, verification points, verification methods, etc. Test case ID, priority, scenario description, method/function, normal/abnormal system, prerequisite, test purpose, test steps, test data, expected results, etc. Defect ID, defect description, reproduction steps, expected results, actual results, test round, test type, discovery version, discovery date, defect owner, defect submitter, severity, priority, defect status, root cause, solution, closing date, etc. Actual execution result of the test case, pass or fail, corresponding defect ID, tester, actual test date, test step screenshots, etc.
Test scope, test conclusion, difference analysis between test environment and production environment, functional test/non-functional test execution, defect summary and legacy problem analysis, test result analysis, lessons learned, improvement suggestions, etc., progress, workload deviation, quality goal achievement, risks and problems, etc., milestone progress, cost and quality, risks and problems, lessons learned, improvement suggestions, etc. 3
JR/T0175—2019
4.3 Test Type
4.3.1 Functional Test
iiKAacJouaKAa
The main purpose, test content and test technology of functional test are as follows: a) Self-
Based on the system requirements specification, the system functional characteristics such as the function implementation and business operation required therein are verified to ensure that the system meets the customer's functionality and usability requirements under the specified conditions. b)
Test Content/Focus
The test content concerns include correct implementation of functions, absence of useless functions and absence of missing functions, as follows 1) Correct implementation of functions: consistent with the functions required in the system requirements specification; 2) There is no useless function: the scope of the implemented functions does not exceed the scope described in the system requirements specification; 3) There is no missing function: the scope of the implemented functions can completely cover the scope described in the system requirements specification. c)
Testing technology
Mainly based on black box testing technology, supplemented by gray box testing technology. The black box testing technology, white box testing technology and gray box testing technology mentioned in this standard are shown in Appendix C. 4.3.2 Performance Testing
The main purpose, test content and test technology of performance testing are as follows: a) Purpose
Evaluate the various performance indicators of the system by simulating business scenarios under various load conditions such as real and high-pressure conditions, usually including load testing, stress testing, capacity testing, business response time testing, etc. Test content/focus
Test content/focus includes load testing, stress testing, capacity testing and business response time testing, as follows: 1) Load testing: Continuously increase the pressure on the system or continue to maintain the maximum safe load until one or more performance indicators of the system reach the safety critical value (for example, a certain resource has reached saturation, etc.), and obtain the performance indicators of the system under different load conditions:
2) Stress testing: When the safety load is exceeded, the system is continuously stressed, and the maximum service level that the system can provide is obtained by determining the bottleneck of a system or the performance point where it cannot receive user requests: 3)
Capacity testing: Use the limit values ​​that reflect the system capacity characteristics (such as the maximum number of concurrent users, the number of database records, etc.) to stress the system, and observe that the system does not have any software failures or can maintain normal operation of the main functions under the extreme capacity state to detect the system's capacity indicators: 4) Business response time testing: The system under test performs business operations during continuous operation under stable pressure or after reaching a certain capacity, and records the time spent on system processing to detect whether the business response time meets performance requirements. c) Testing technology
Specifically as follows:
1) The test method for load testing, stress testing and business response time testing is to obtain the delay, throughput and processing time of software system function processing by simulating single-user and multi-user concurrent scenarios. Automated testing tools are used to construct data and load stress. Modules with representative or core businesses and businesses with high access volume are usually selected to construct various performance test scenarios, so as to conduct single-machine performance testing or concurrent performance testing. Test indicators include order peak throughput rate, transaction peak throughput rate, order continuous throughput rate, transaction continuous throughput rate, order processing delay, daily settlement processing capacity, etc.;
TiiKAacJouaKAa
JR/T0175—2019
2) The test method for capacity testing is to construct corresponding capacity data under different system configurations and different business scenarios to evaluate the system's limit capacity and hardware resource occupancy rate. Among them, the limit capacity includes the maximum number of users, the maximum processing volume, the maximum number of transactions (execution units), the maximum throughput, the maximum file capacity, etc.: the hardware resource occupancy rate includes memory, CPU, hard disk, network bandwidth, equipment, etc. Test indicators include daily order processing capacity, daily transaction processing capacity, etc. 4.3.3 Reliability test
The main purpose, test content and test technology of reliability test are as follows: a) Purpose
Reliability test is to verify the system's ability in exception handling, fault tolerance, data recovery and disaster recovery by simulating various abnormalities or failures that may occur in the system, and evaluate the reliability of the system. The purpose is to ensure that the system meets the high availability requirements under specific environmental deployment conditions. It usually includes maturity testing, fault tolerance testing, stability testing and recoverability testing.
Test content/focus
Test content/focus includes maturity testing, fault tolerance testing, stability testing and recoverability testing, as follows: Maturity testing: When code judgment errors, interface errors in integration, communication message errors, business logic errors in the system and other errors caused in the design, development and other links occur in the software system, verify that the system can eliminate the impact of the errors and can still work normally;
Fault tolerance testing: When external errors are introduced, such as illegal operations, data deletion, forced termination and other serious behaviors that cause the system (including hardware, software and affiliated programs) to become abnormal, verify that the system should have protective measures under abnormal circumstances (methods for handling abnormalities include: automatic system processing and manual intervention processing): Stability testing: Verify the stability of the system under certain pressure for a long time through continuous testing methods: 3
Recoverability testing: The ability of the system to recover to a normal state when it fails. The failure state should be a system crash or 4)
or the machine stops all functions, rather than a running state with a fault; the normal state should at least ensure that the main functions of the system can run in full. Obtain the system recovery time (RTO) and data recovery time (RPO). The definitions of RTO and RPO are as follows:
c) Testing technology
Specific as follows:
1) The testing method of maturity testing and fault tolerance testing is to verify the ability of the system or component to effectively handle failures by artificially simulating failure scenarios, such as process crashes and hangs, network disconnections and delays, server failures, etc., or by using tools or manually creating abnormal operations or abnormal data inputs, etc.: The testing method of stability testing is 7*24 hours stress testing, that is, imitating the business ratio relationship of production, maintaining different multiples of order pressure according to actual production needs, and running the tested system for 24 hours a day for 7 consecutive days. During the test, the correctness of the system operation status can be verified by checking the system process status, executing functional operations, and checking the operation log information:
3) The test method of recoverability testing is to simulate the failure of the system due to a fault or disaster, and obtain the system recovery time (RTO) and data recovery time (RPO) indicators by analyzing the system log or running water. 4.3.4 Security Testing
The main objectives, test contents and test techniques of security testing are as follows: a) Purpose
Through security testing means and methods, verify that the security features of the software are consistent with expectations and test the software product's ability to prevent various attacks, thereby ensuring the safety quality of the product. 5
JR/T0175—2019
Test content/focus
Specifically as follows:
iiKAacJouaKAa
Configuration management: 1) Perform security configuration on the operating system, application, database, network equipment, etc. in accordance with the requirements of information security level protection;
Resource utilization: Application memory usage and resource competition issues, such as uninitialized variables, array out of bounds, memory overflow, resource leakage, process thread exception, etc.:
Identity authentication: The identity and authentication of users who log in to the operating system, database system and application system are performed, such as 3)
A strong password policy should be used, the number of consecutive login attempts should be limited, and a valid verification code should be used; 4)
Access control: Users should access system resources (such as servers, self-recording, files, etc.) according to their own permissions and shall not access beyond their authority:
Data protection: The application stores sensitive information In this case, the stored sensitive information should be encrypted, including but not limited to passwords, keys and other sensitive information should be encrypted and written into the cache, file system, database, etc.; 6)
Communication security: When the application uses a secure communication protocol (such as SSL, TLS), the transmission of sensitive information should be encrypted, etc.:
Session management: Local and server-side settings for session timeouts, sensitive information used by the application after the session ends 7)
should be deleted from the memory, and the legitimate user's session is not hijacked, etc.; Data verification: The application correctly verifies the input data from the client or the outside world before use, to avoid vulnerabilities such as 8)
Cross-site scripting attacks, command injections, file injections, SQL injections, etc.: Security auditing: Log the operation status of network equipment in the network system, network traffic, user behavior, etc.; 9)
Audit records should include the date and time of the event, user, event type, event success, and other audit-related information.
c) Testing technology
Common security testing technologies include security function checking, code security testing, vulnerability scanning, penetration testing and fuzz testing, as follows:
Security function checking refers to the process in which testers interview relevant system management personnel and observe, verify and analyze the test objects (such as relevant systems, various equipment, baseline standards, development and design documents) to confirm that the test objects comply with the information security level protection, relevant information security requirements and security function requirements. 2)
Code security testing is divided into static testing and dynamic testing. Static detection is the process of using code detection software to perform static code scanning and manually analyzing the scan results to discover and locate vulnerabilities; dynamic detection is error checking at runtime, mainly by converting an already written program into a new program (whose functions are equivalent to the original program). The new program contains some additional code, and their function is to check errors during program execution; vulnerability scanning refers to the use of professional vulnerability scanning tools to detect the security status of the target system through scanning, detection and other methods based on the Common Vulnerabilities and Exposures (CVE) vulnerability database or feature library to discover exploitable vulnerabilities; penetration testing is to simulate the intrusion of the target system by simulating the attack methods of malicious hackers to find out the vulnerabilities, technical defects and vulnerabilities in the system; fuzz testing is a method of discovering software failures by providing unexpected inputs and monitoring abnormal results. It is an automatic or semi-automatic process, which usually includes stages such as identifying targets, identifying inputs, generating fuzz test data, executing fuzz testing, monitoring abnormalities, and determining exploitability. 4.3.5 Portability Test
The main purpose, test content and test technology of portability test are as follows: a) Purpose
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.