In "What inputs do software test case design need to refer to?" In this paper, the author proposes several main sources of reference for test case design: development documents, user requirements, standards and specifications, similar product requirements, test experience knowledge base, and other implicit requirements. Identification of test conditions for test objects will take these reference documents as input.Copy the code

During testing practice, different testers are responsible for different functions and features of the test object. Therefore, assigning reference input documents related to a function or feature to the same tester can help improve the efficiency and effectiveness of test condition identification. What are the following characteristics or principles for identifying test conditions for different reference input sources? 1) Development documentation Development documentation is a general term that covers various software work products in the development process, such as system requirements specifications, outline design specifications, etc. For system testing, system requirement specification is one of the most important reference inputs. For other test levels, the primary source of reference input is the corresponding development document. If the system requirements specification is formal, it is relatively easy to extract test conditions from the document, based on the principle that each requirement item should be covered by at least one test case. According to the granularity of requirements, multiple requirements can be verified in one test case. Some requirements items can be combined into one and verified in the same test case. In the process of extracting test conditions, testers need to pay attention to: requirements are more from the perspective of software development, and testers need to consider such requirements from the perspective of testing. It can be a challenge to identify test conditions if system requirements specifications are incomplete or absent. Here are a few suggestions for identifying test conditions: (1) First, discuss with the systems and developers of the software product that, from a testing perspective, will have undocumented requirements in their heads; (2) Secondly, if the tester has the ability of code, the code can be used to explain how the software system is implemented, and they can also be used as a reference to identify test conditions. One issue, of course, is whether the code implementation is correct and comprehensive, and this is something that testers need to consider. (3) Third, promote the development team to improve the quality of development documents from the perspective of testing, and gradually improve the quality of system requirements from the level of standardizing the software development process (process). For example, promote the improvement of the quality of development documents by outputting test documents or check lists in the test. 2) During user requirements testing, we often hear that testers not only need to verify that the development has implemented the function correctly, but also need to consider whether the software product really meets the user’s requirements from the user’s perspective. This is the focus of Validation in testing. And user requirements play a very important role in it. User requirements are usually described and divided from the perspective of the actual use of users, similar to use case scenarios. Since users do not necessarily know and are familiar with knowledge and skills related to software products, user requirements are hardly complete. When testing personnel analyze user requirements, they need to combine the specific content of the relevant development documents of the software product. At the same time, testers should actively communicate with customers, product technical support personnel, and sales personnel to obtain possible test conditions from their perspective. For example, you can view the actual network topology and function configurations. 3) Standards and specifications Standards and specifications are defined in much more detail than is possible in the development documentation, so they are important objects for deep and careful learning by testers. For example, a lot of function development in data communication products is based on some international, national and industry standards and specifications, based on their access to test conditions, for improving the coverage and effectiveness of the test is very necessary. The following are some principles and suggestions for identifying test conditions based on standards and specifications: (1) The development document does not describe a particular function or feature of the software product in detail, but refers directly to a protocol standard. For example, the FORMAT of OAM PDU is compatible with Y.1731/802.1AG /D80. (2) Protocol conformance test, standards and specifications conformance test, etc. At this time, standards and specifications may be the main reference input to identify test conditions. Testers can check for deviations in the implementation of software products based on standards and specifications, which is mainly the focus of Verification in testing. (3) In addition to obtaining test conditions through standards and specifications, testers can also check development documents for omissions and errors through them, which is one of the main purposes of the preliminary review. As software products become more complex, there are more and more occasions in the industry to adopt incremental and iterative development models, such as agile development. Testers are often faced with software products that are based on existing systems, that is, the test objects are based on changes in previous versions such as feature additions, bug fixes, and platform migrations. Therefore, testers need to analyze whether historical testing is comprehensive, whether changes to test objects affect previously running software versions, and so on. Based on this information, testers can obtain new testing requirements. 5) Testing knowledge base testing is not a stage after coding, testing should be throughout the entire software development life cycle. Like development process improvement, testing should be a PDCA (Deming Quality Cycle) process. Therefore, test experience in different projects is an important input to the design of each test case. Through the test knowledge base, the test team’s test experience and skills are shared across the organization. The knowledge base of test experience can come from the experience of test execution, the classification and analysis of defects found in the process of test, and the classification and analysis of defects fed back by users. 6) Other implicit requirements In addition to identifying test conditions from the input documents mentioned above, other implicit outputs can also serve as the basis for identifying test conditions, such as memos agreed by different product stakeholders regarding changes to the intermediate version of the test object; Find some common defects and failures of similar test object products through magazines and networks, and discuss the use of software products in the user site. With reference inputs to test case design: system requirements, user requirements, standards and specifications, similar product requirements, knowledge base of test experience, and other implicit requirements, the tester can obtain a set of initial test conditions, known as a list of test conditions. To improve test efficiency and effectiveness, a test priority needs to be set for each test case. The initial test condition list needs further test type analysis and functional interaction analysis to get a relatively perfect test condition list. Next, testers can use a range of testing techniques and methods to design detailed test cases. Welcome to add QQ group 599411652 learning, communication software testing, loaded together, a fly ~