Terms and explanations for Software Testing

1. Unit Testing (unit test ):Refers to a sectionCodeThe actual size of the basic test is not fixed, usually a function or sub-ProgramIs generally executed by developers.

2. Integration Testing (integration test ):All components of the tested system are integrated to identify the relationship between the tested system components and errors in interfaces. This test is generally performed after the unit test.

3. Acceptance Testing (Acceptance Test ):A stage of the system development lifecycle methodology. At this time, the relevant users and/or independent testers test and receive the system based on the test plan and results. It allows the System user to decide whether to receive the system. It is a test to determine whether the product meets the contractual or user-defined requirements. This is administrative and defensive control.

4. Alpha testing (a test ):It is a test performed by a user in the development environment, or it can be controlled by the company's internal users in the simulated actual operating environment. Alpha testing cannot be completed by programmers and testers. Alpha testing can start after the software product code is complete, or after the module (subsystem) test is complete, you can also start after the product reaches a certain degree of stability and reliability during the validation test. Relevant manuals (drafts) should be prepared before Alpha testing.

5. beta testing:It is a test performed by multiple software users in the actual use environment of one or more users. Developers are generally not in the test site, and beta testing cannot be completed by programmers or testers. Therefore, beta testing is an on-site application of software in an environment that cannot be controlled by developers. Beta testing focuses on Product Support and starts beta testing only when Alpha testing reaches a certain level of reliability.

6. Black box testing (black box test ):A testing method that testers do not care about how the program is implemented. Testing of Software defects based on software specifications by various input and observation of various output results of the software. Such testing does not consider the internal operating principles of the software, therefore, software is like a black box for users.

7. white box testing (white box test ):Tests are carried out based on the internal working Principle Analysis of the software. Code-based tests allow testers to judge the quality of the software by reading program code or by using one-step debugging in development tools, generally, white-box testing is implemented by the Project Manager in program development.

8. Automated Testing ):Automated testing tools are used for testing. Such tests generally do not require human intervention and are usually used in Gui, performance, and other tests.

9. BUG Tracking System (Error Tracking System, BTS ):It is also called "defect tracking system, DTS". It manages the dedicated database system for Software Test defects and can efficiently complete the reporting, verification, modification, query, statistics, storage, and other tasks of Software defects. Especially suitable for testing and management of large-scale multilingual software.

10. Build (working version ):Incomplete software versions such as functions and performance tested by users during software development. The working version can be either an operable version of the system or a part of the system that shows some of the functions to be provided in the final product.

11. Functional testing (function test ):Also known as behavioral testing (behavior testing), tests the characteristics and operational behavior of a product based on product features, operation descriptions, and user solutions to determine that they meet design requirements. A functional test of the localization software to verify that the application or website works properly for the target user. Use appropriate platforms, browsers, and test scripts to ensure that the target user experience is good enough, just as applications are specially developed for this market.

12. Load Testing ):Test the system performance when resources are overloaded to identify design errors or verify the load capacity of the system. In such a test, the test object will assume different workloads to evaluate and evaluate the performance and behavior of the test object under different workload conditions and the ability to continue normal operation. The goal of load testing is to determine and ensure that the system can still run normally when the maximum workload is exceeded. In addition, load testing also evaluates performance features, such as response time, transaction processing rate, and other time-related aspects.

13. Performance Testing (Performance Test ):A test that evaluates whether a product or component meets the performance requirements. Includes load testing, strength testing, database capacity testing, benchmark testing, and other types.

14. Pilot testing (Pilot Test ):In software development, verify the system's ability to handle typical operations based on real hardware and customers. In software outsourcing testing, pilot testing is usually a form of testing capability of the customer to check the software testing company, the software testing company can accept the software testing of the customer's real software project.

15. Portability testing (or portability test ):Test whether the software can be successfully transplanted to a specified hardware or software platform.

16. Compatibility testing (compatibility test ):It is also called "configuration testing" to test whether the software is compatible with other system interaction elements, such as browsers, operating systems, and hardware. Verify the running status of the test object in different software and hardware configurations.

17. Installing testing (installation test ):Ensure that the software can be installed under normal and abnormal conditions, such as initial installation, upgrade, complete or custom installation. Exceptions include insufficient disk space and permission for creating directories. Verify that the software runs properly immediately after installation. Installing testing includes the test and installation code and the installation manual. The installation manual provides how to install and the installation Code provides the basic data that can be run by installing some programs.

18. Smoke Testing (smoke test ):The smoke test object is the version of each newly compiled software that needs to be officially tested. The purpose is to confirm that the basic functions of the software are normal and subsequent formal tests can be conducted. The implementer of the smoke test is the version compiler. See "sanity testing )"

19. sanitytesting (sound test ):A simple test of the main functional components of the software to ensure that it can perform basic tests.

20. regression testing (regression test ):Test the previous test again after the modification to ensure the correctness of the modification. In theory, regression tests are required for any new version of the software to verify that errors previously discovered and fixed are reproduced on the new software version.

21. Priority (priority ):From a business perspective, it refers to the importance of errors, especially from the perspective of customers and users. It refers to the impact of errors on the feasibility and acceptability of the system. Compare with "severity (severity.

22. Severity (severity ):The extent to which errors affect the system to be tested, the possibility of occurrence under the conditions of end users, and the extent to which software errors impede system use.

23. software life cycle (software life cycle ):It begins with the conception of a software product and ends with the period during which the product is no longer used.

24. SRS (Software Requirement Specification ):Software Requirement Specification

Question:
1. Differences between UAT and sit
UAT (user acceptance testing ):End-user integration testing mainly requires users to participate in the testing process and be recognized by users for the software. Users are encouraged to design and conduct Destructive Testing on their own, clearly, it is difficult to fully expose system design and functional issues, and user acceptance and destructive testing. Because the tester does not know what means and thinking model the user uses for testing, The UAT is a bit similar to the user experience.
Sit (System Integration Testing): System Integration testing is similar to General software module integration testing, but there are few opportunities for user participation, mainly carried out within the company;