GB/T 38634.1-2020 English PDFUS$999.00 · In stock
Delivery: <= 7 days. True-PDF full-copy in English will be manually translated and delivered via email. GB/T 38634.1-2020: Systems and software engineering - Software testing - Part 1: Concepts and definitions Status: Valid
Basic dataStandard ID: GB/T 38634.1-2020 (GB/T38634.1-2020)Description (Translated English): Systems and software engineering - Software testing - Part 1: Concepts and definitions Sector / Industry: National Standard (Recommended) Classification of Chinese Standard: L77 Classification of International Standard: 35.080 Word Count Estimation: 54,587 Date of Issue: 2020-04-28 Date of Implementation: 2020-11-01 Adopted Standard: ISO/IEC/IEEE 29119-1-2013, MOD Issuing agency(ies): State Administration for Market Regulation, China National Standardization Administration Summary: This standard specifies the concepts and definitions of software testing. This standard applies to the software testing process, testing documentation and testing techniques of GB/T 38634. GB/T 38634.1-2020: Systems and software engineering - Software testing - Part 1: Concepts and definitions---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order. Systems and software engineering - Software testing - Part 1.Concepts and definitions ICS 35.080 L77 National Standards of People's Republic of China System and software engineering software testing Part 1.Concepts and definitions 2020-04-28 released 2020-11-01 implementation State Administration for Market Regulation Issued by the National Standardization Management Committee Table of contentsPreface Ⅲ Introduction Ⅳ 1 Scope 1 2 Compliance 1 3 Terms and definitions 1 4 Software Testing Concept 10 Appendix A (informative appendix) The role of testing in verification and validation 29 Appendix B (informative appendix) Metrics and Measures 30 Appendix C (informative appendix) Tests in different life cycle models 31 Appendix D (informative appendix) Detailed test sub-process example 38 Appendix E (informative appendix) Test roles and responsibilities 45 Appendix F (informative appendix) Structure changes of this part compared with ISO /IEC /IEEE29119-1.2013 47 Reference 49 System and software engineering software testing Part 1.Concepts and definitions1 ScopeThis part of GB/T 38634 specifies the concept and definition of software testing. This section applies to the software test process, test documents and test technology of GB/T 38634.2 ComplianceGB/T 38634.1 is informative content and does not include compliance requirements. The GB/T 38634 software test standard includes three parts that can declare conformity. ---Testing process; ---Test documents; ---testing technology. Compliance is specifically proposed by GB/T 38634.2, GB/T 38634.3 and GB/T 38634.4.3 Terms and definitionsThe following terms and definitions apply to this document. 3.1 Accessibility test A type of usability testing. Used to measure the extent to which a certain test item can be used by the user, where the user should cover the largest range Individuals with various characteristics and different abilities. 3.2 results of testing The behavior and state set of the test item, or related data, and the state set of the test environment can be obtained as the result of test execution. Examples. output to hardware, changes to data, generation and display of reports, and sending of communication messages. 3.3 Backup and recovery test A type of reliability test. In the event of failure, within the specified time, cost, completeness and accuracy parameters, the measurement system The extent to which the system state can be restored from backup. 3.4 Black box testing See test based on specifications (3.39). 3.5 Capacity test A type of performance efficiency test. It is used to evaluate the ability level and performance of the test item when increasing the load (users, transactions, data storage, etc.) Need to maintain the performance compromise. 3.6 Compatibility test When sharing the environment (coexistence) with other independent products, and when it is necessary to exchange information (interoperability) with other systems or components, test The extent to which the measurement items meet the requirements. 3.7 Coverage item See test coverage item (3.54). 3.8 determination Make a choice among two or more possible outcomes, and determine the sentence type of the action set. Note. Typical judgments include simple choices (for example, if-then-else), deciding when to exit the loop (for example, while-loop), and multiple switch statements (for example, For example, case-1-2-3-..-n). 3.9 Dynamic Testing Need to run the test of the test item. 3.10 Durable test A type of performance efficiency test. It is used to evaluate whether the test item can sustain the required load in a specified period of time. 3.11 Equivalence class A subset of the range of a variable or variable set. In the test item or its interface, it is expected that the test item will handle all in the subset in the same way. Some values (that is, considered "equivalent"). 3.12 Equivalence category coverage The test set covers the proportion of identified equivalence classes in the test items. Note. In many cases, the equivalence class identification is subjective (especially in the "invalid" equivalence class), so it is not possible to explicitly count the equivalence class of the test item can. 3.13 Equivalence class division A type of test design technique. Use one or more representative members of each equivalence class to design test cases. 3.14 Wrong guess A type of test design technique. Derive test cases based on previous failure experience or common sense of failure modes. Note. Relevant knowledge can be obtained through personal experience, or packaged in the form of a defect database or "defect classification". 3.15 expected results According to specifications or other sources, the expected behavior of the test item that can be obtained under specific conditions. 3.16 Exploratory test An experience-based test. Testers based on their existing relevant knowledge and preliminary exploration of test items (including previous test results) As well as heuristic "rules of thumb" about common software behavior and failure types, tests are designed and executed spontaneously. Note. Exploratory testing looks for hidden attributes (including hidden behaviors).Although the possibility of its own harm is very small, it may interfere with other aspects of the software under test. Other attributes, and therefore the risk of software failure. 3.17 Feature set The collection of test conditions including test items can be collected from aspects such as risks, requirements, functions, and models. Note. It may be all the features of the item (its full feature set), or a subset (functional feature set, etc.) identified for a specific purpose. 3.18 Incident report Documentation of the occurrence, nature and status of the event. Note. Event reports are also called exception reports, error reports, defect reports, error reports, problem reports, etc. 3.19 Ease of installation test A type of portability test. Used to evaluate whether one or a group of test items can be installed in all specified environments. 3.20 Load test A type of performance efficiency test. It is used to evaluate the behavior of test items under expected varying loads. Between peak usage expectations. 3.21 Maintenance test Evaluate the effectiveness and efficiency of modifying test items. 3.22 Organizational Testing Policy The purpose, objectives and overall scope of the organization's testing. Note. The organization-level testing policy is as short as possible. 3.23 Organizational testing process Develop and manage the testing process of organization-level test specifications. 3.24 Organization level test specification A document that provides information for an organization's testing. The information is not specific to a specific project. Example. The most common examples of organization-level test specifications are organization-level test policies and organization-level test strategies. 3.25 Organizational testing strategy Provide documentation of general requirements for performing tests for all projects in the organization; provide details on how to perform tests. Note 1.It is consistent with the organization-level testing policy. Note 2.An organization can have multiple organization-level test strategies to deal with projects with different backgrounds. 3.26 Pass/fail criteria It is used to determine whether the test item or the characteristics of the test item pass or not. 3.42 Static test In the case of not running the code, a set of quality criteria or other criteria are used to check the test items. Examples. review, static analysis. 3.43 pressure test A type of performance efficiency test. Used to evaluate whether the test item is higher than the expected or specified capacity load demand, or lower than the minimum required capital Behavior under source conditions. 3.44 Structure test See structure-based testing (3.45). 3.45 Structure-based testing The dynamic test of test cases is derived from the test item structure. Note 1.Structure-based testing is not limited to use at the component level, it can be used at all levels, such as the menu item coverage in the system test. Note 2.Techniques include branch testing, decision testing and sentence testing. Note 3.Synonyms for structure-based testing include structural testing and white box testing. 3.46 Suspend guidelines The criteria used to (temporarily) stop all or part of the testing activities. 3.47 Test basis The knowledge system that serves as the basis for test analysis and test case design. Note. The test basis can be in the form of documents, such as requirements specifications, design specifications or module specifications, but it can also be in non-written form. Understanding of demand behavior. 3.48 Test case A collection of preconditions, inputs (including operations, if applicable), and expected results, used to drive the execution of test items to meet test goals, Test objectives include correct implementation, error identification, check quality and other valuable information. Note 1.The test case is the lowest test input level of the test sub-process. (That is, test cases cannot be divided into more detailed test cases) Note 2.The pre-conditions of test cases include test environment, existing data (such as database), software under test, hardware, etc. Note 3.Input is the data information used to drive test execution. Note 4.Expected results include passed criteria and failed checks. 3.71 Test management process The test process that contains the sub-processes required for test project management. Note. See test planning process, test monitoring and control process, test completion process. 3.72 Test monitoring and control process Sub-processes of the test management process. To ensure that the test is performed in accordance with the test plan and organization-level test specifications. 3.73 testing object See test item (3.68). 3.74 Test phase The concrete instantiation of the test sub-process. 3.75 Test Plan A document describing the test objectives to be achieved and the methods and arrangements to achieve the test objectives, used to coordinate the test activities of the test items. Note 1.A project can have multiple test plans, for example, there can be a project test plan (also known as the main test plan), which contains all of the project Test activities; more details of the test activities can be defined in one or more test sub-process plans (ie, system test plans or performance test plans). Note 2.Usually the test plan is recorded in writing, although other plan forms can also be partially defined in the organization or project. Note 3.Test plans can also be written for non-project activities, such as maintenance test plans. 3.76 Test planning process Sub-processes of the test management process. Used to complete test planning and develop test plans. 3.77 Test practice A conceptual framework that facilitates the implementation of testing, which can be applied to the organization-level testing process, test management process and/or dynamic testing process. 3.78 Test procedure The execution sequence of the test case, as well as any related actions required to construct the initial preconditions and the closing activities after execution. Note. The test procedures include detailed instructions on how to run one or more test cases continuously, including setting common preconditions, and provide for each test case Enter and evaluate actual results. 3.79 Test procedure specification A document describing one or more test procedures. These test procedures are a collection of test cases with specific goals. Note 1.The test cases in the test set are listed in the order of requirements of the test procedure. Note 2.The test procedure specification is also called manual test script. The specification of test procedures for automated test runs is usually called a test script. 3.80 Testing process The process of providing quality information for a software product usually consists of multiple activities, divided into one or more test sub-processes. Note. The test process of a specific project may include multiple sub-processes, such as system test sub-processes, test plan sub-processes (part of a larger test management process) Or static test sub-process.4 Software testing concept4.1 Overview of software testing 4.1.1 Overview The necessity of software testing is as follows. ---The decision maker needs information about the quality characteristics of the test item; ---The tested item does not always achieve the expected effect; ---The tested item needs to be verified; ---The tested item needs to be confirmed; ---The evaluation of the tested item shall run through the entire software and system development life cycle. It is generally accepted that perfect software cannot be built. Therefore, it is necessary to test the software before it is released to users to reduce The risk of software product errors in order to avoid negative effects when using the software. Similarly, it is necessary to ensure that the test can be performed well. Errors or defects are largely inevitable. Human-induced errors or mistakes cause software work products (for example, a Seek specifications or software components) defects. If no defects are encountered when the software is used, the defects will not affect the operation of the software. ring. However, if defects are encountered when using the product under certain conditions, the defects may cause the software product to fail to meet the reasonable needs of users. begging. The failure of the software may bring serious consequences for the user experience. For example, a defect may damage business reputation, public safety, business Business feasibility, business or user information security, environment, etc. Dynamic testing is necessary, but there is no guarantee that the software will perform as expected. Additional static testing activities, such as peer review and static scoring Analysis should be combined with effective dynamic testing activities. The main objective of the test is to provide quality information about the test item and any residual risks related to the quantity of the test item tested; Discover the defects of the test items before release; and reduce the risk of related stakeholders caused by insufficient product quality. Software quality information can be used for a variety of purposes, including. ---Improve test items by eliminating defects; ---Use the quality and risk information provided as the basis for decision-making to improve management decisions; ---Improve the processes in the organization by identifying processes that allow defects and/or may be found but still not found defects. Product quality has many aspects, including compliance with specifications, no defects, and the degree of compliance to meet product user needs. The eight quality characteristics defined by the GB/T 25000.10-2016 system and software quality model can be measured and evaluated through testing (see 4.5.4). Under the constraints of a given cost and schedule, software testing should focus on providing quality information about the software product, and make every effort during the development process. Find defects early and as many as possible. Factors considered for testing include. ---Testing is a process. Process is a series of interrelated or interacting activities that transform input into output. The purpose of this standard It is to propose and describe the general test process (see GB/T 38634.2 test process for details). ---The test policy and test strategy applied to cross-organizational projects and functions, which are set and maintained by the organization-level test process. ---The testing should be planned, monitored and controlled. The test management process contained in GB/T 38634.2 can be applied to all development The management of testing and exploratory testing in the life cycle. ---The test process and sub-processes can be applied to any test phase or level (such as system testing) or any type of test (such as performance test). ---The test needs to check the test items. ---The product can be tested without running the product on the computer. This testing technique is called in this standard and many industry fields Static testing, although in other standards (e.g. GB/T 32421-2015) it may be more specifically called review, walkthrough or inspection check. This standard recognizes and recognizes the role of testers in static testing activities, even if these activities may work in other standards Group or defined in other non-test standards. Static testing activities are very important for testing throughout the life cycle, and testing Incoming is essential for early defect detection, reducing the total cost of the project and ensuring the progress of the project. ---Static testing includes the use of static analysis tools to find defects in code and documents without running the code (such as compilation Analyzer, cyclomatic complexity analyzer, or code security analyzer). ---Dynamic testing is not only running executable test items, but also includes preparation activities and follow-up activities. Described in GB/T 38634.2 The dynamic testing process covers every activity to be performed in dynamic testing. ---Verification is to confirm that the specified requirements have been met in a given work item by providing objective evidence. ---Confirmation indicates that users can use the work item to perform their specific tasks. ---Whether it is a static test or a dynamic test, it aims to provide the information needed to verify and confirm the two kinds of Defects and cannot be immediately identified. 4.1.2 The role of testing in verification and validation Software testing is the main activity of verification and validation. This standard only involves software testing in verification and validation, and does not involve verification and validation. Other activities (e.g. V And other verification and confirmation activities. Only when this standard is combined with other standards and used as part of the entire project can it be opened. Develop complete product verification and confirmation activities. See Appendix A for the hierarchy of verification and validation activities. 4.1.3 Exhaustive testing Due to the complexity of the system and software, the test cannot cover every aspect of the test item. Testers should understand that exhaustive testing is not Possibly, testing activities should focus on the test objectives that best meet the test items. Risk-based testing is a way of using risk to guide testers Method of making. See 4.4 for risk-based testing. 4.1.4 Heuristic testing In engineering (software engineering), heuristic is a method based on experience (trial and error) that can be used to help solve and design problems. although Although the heuristic algorithm can be used to solve the problem, but it is not reliable, can not solve all the problems, or can only solve some of the problems. Many systems And software testing is based on heuristics. For example, by modeling the system under test, heuristic testing is very useful, but may not The system is fully modeled, so even if the test seems to have been completed, it may not be possible to find defects in the system......Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 38634.1-2020_English be delivered?Answer: Upon your order, we will start to translate GB/T 38634.1-2020_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 7 working days. The lengthier the document the longer the lead time.Question 2: Can I share the purchased PDF of GB/T 38634.1-2020_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 38634.1-2020_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet.Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to Sales@ChineseStandard.net. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay. |
