Table of contents
5. Development model and test model
1. The concept of demand
Basis for Measuring Software Testing Results—Requirements
Concept: To meet user expectations or formalize the conditions and capabilities of documents (contracts, standards, specifications), including user needs and software requirements
User requirements: It can be simply understood as the requirements put forward by Party A. Without Party A, it is the task that end users must complete when using the product. No technical implementation details are involved. User needs are obtained from user communication, market research, or demand analysis.
Software Requirements (Functional Requirements): It is a detailed description of the functional behavior and operation of a software system. It specifies which functions and the associations between functions should be provided by the software system. Functional requirements are usually described in the form of use cases, functional specifications, or requirements specifications so that developers and testers can understand and implement them.
Serious needs of testers: Take the user login and registration business as an example
How to understand the needs in depth?
Conduct a needs review meeting
Requirements review meeting is an important activity in the software development and testing process to review, discuss and verify the requirements of the software system. This meeting usually involves relevant members of the project team, including requirements analysts, developers, testers, project managers, and other stakeholders.
Requirements review meeting is an important part of project team collaboration and requirements consensus formation, which can help discover and correct problems in requirements, and reduce changes and risks in subsequent development and testing stages. Through timely requirements review meetings, the efficiency and quality of the software development process can be improved.
2. Test cases
A test case is a collection of test environments, expected results, operation steps, and test data designed and executed to verify whether the software system meets the expected requirements . Use cases are called "cases"
Take the blog system login business as an example:
Test environment: windows system + chrome browser + local
Test data: account + password
Operation steps: Enter the account number, enter the password, and click Login
Expected result: successful login, jump to personal blog page
The expected result is the same as the actual result, and the test case is said to pass
Why are there test cases?
Improve the work efficiency of testers and reduce the repetition of work of testers
Test cases are the basis of resume automation testing
3. What is BUG
A mismatch between the program and the specification (software requirements) (expected result != execution result) is a BUG if and only if the specification exists and is correct
For functions not mentioned in the requirements specification, the judgment standard is ultimately based on the user: when the program does not meet the functional requirements reasonably expected by the end user, it means that the software system has a bug
On the user login interface, the password is displayed in clear text, which is easy to cause password leakage. Obviously this is a BUG
4. Software life cycle
Six phases: requirements analysis, planning, design, coding, testing, operation and maintenance
Requirements analysis: pay attention to whether the requirements are reasonable and complete
Planning: development, testing, scheduling
Coding: writing code
Test: conduct tests and generate test reports
Operation and maintenance: After the project goes online, if there is a problem, the tester needs to assist the developer to locate the problem, and then go online again after solving the problem
5. Development model and test model
development model
waterfall model
Output after requirements analysis: requirements document
Output in the design phase: technical documents, which interfaces are involved, library tables, mq, timed tasks, UI visual drafts
Test: Execute test cases and submit bugs
Pros: The work of each stage is very clear
Disadvantages: high risk, because it is a single process, the testers intervene late, and the BUG revealed in the later test stage loses the opportunity to correct it early, wasting manpower and material resources
Applicable projects: projects with small projects and short development cycles
rapid prototyping model
Rapid Prototype Model (Rapid Prototype Model) is a software development process model, which is mainly used for rapid verification and demonstration of concepts, designs and functions.
Key features of rapid prototyping models include:
Rapid Development: The rapid prototyping model focuses on rapid iteration and development. The development team quickly creates a simplified prototype to demonstrate the core functionality and appearance of the system. This facilitates early user feedback and design validation
User Involvement: The rapid prototyping model emphasizes user involvement and feedback. Prototypes can be used to interact with users and get their opinions and suggestions. This helps ensure that the final software system meets user needs and expectations
Highly visualized: Rapid prototyping models are usually based on graphical interfaces, which demonstrate system functions and interfaces through graphical elements and interactive operations. This enables users to better understand and assess how the system looks and behaves
Iterative Improvement: Rapid prototyping models are developed iteratively. According to user feedback and changes in requirements, the development team will continue to improve and expand the prototype to ensure that the quality and functionality of the system meet expectations
Disadvantages: Rapid prototyping models can lead to technical and complexity challenges in subsequent development stages, requiring careful evaluation and planning
Applicable scenarios: suitable for projects that quickly verify and demonstrate system functions and interfaces
spiral model
Features:
Iterative Loops: The spiral model divides the software development process into iterative cycles. Each iteration cycle includes requirements analysis, design, development, testing and review stages. Each iteration cycle gradually refines the software system, adapting and improving based on previous experience
Risk-driven: The spiral model focuses on risk management. At the beginning of each iteration cycle, a risk assessment and analysis is performed. Development teams prioritize high-risk issues to reduce the risk of project failure
Prototype development: The spiral model supports prototype development. In the early stages of a project, rapid prototyping can be used to validate requirements and designs, obtain user feedback, and guide subsequent development efforts
Phase Review: After each iteration cycle in the spiral model, a phase review will be conducted. The review will check and review the results of the previous stage to confirm its rationality and feasibility, and determine the direction of the next stage
Disadvantages: May require more resources and time, and require tighter management and control to ensure the success of the project
Applicable projects: The spiral model is suitable for large, complex and high-risk software projects
incremental model
Decompose the development and delivery of the system into multiple increments or parts of iterative completion
Key features of the incremental model include:
Incremental delivery: Divide the development and delivery of a software system into multiple increments. Each increment is a complete, operational collection of subsystems or functions. After each increment is complete, it can be delivered to users and get feedback.
Iterative development: Develop in an iterative manner. Each increment is an iterative cycle that includes stages such as requirements analysis, design, development, testing, and delivery. Each iteration adds new features or improves existing ones.
Priority assignment: In the incremental model, the development priority of each increment is adjustable. Each increment can be prioritized based on factors such as user needs, degree of risk, and system complexity.
Incremental integration: As each increment is completed, incremental integration testing is performed to ensure the interaction between increments and the normal operation of the overall system. This helps to detect and resolve integration issues early.
User Engagement: Emphasizes user engagement and feedback. Users can review and test each increment after completion and provide feedback on system functionality and performance
agile method
Individuals and interactions are more important than processes and tools: Emphasize that in software development, communication and cooperation between individual members are more important than processes and tools. Meaning that team members should focus more on effective communication, collaboration and interaction rather than relying solely on tools and processes.
可用的软件重于完备的文档：敏捷方法注重交付可用的软件产品，而不是过多强调繁琐的文档编写
客户协作重于合同谈判：强调与客户的紧密合作和持续反馈。团队和客户之间的协作和沟通比起相对僵硬的合同谈判更能推动项目成功
响应变化重于遵循计划：敏捷方法认识到需求是会变化的，因此强调对变化灵活响应
敏捷方法中后者并非没有价值，只是相比于前者是次要的
scrum三大角色
-
产品经理（Product Owner）：代表利益相关者、客户或用户，并负责管理产品待办列表。他们与团队密切合作，明确产品需求、优先级和发布计划。产品负责人还参与冲刺计划会议、冲刺回顾会议和冲刺评审会议，确保团队交付符合用户期望的功能。
-
研发团队（Scrum Team）：是一个跨职能的自组织团队，负责开发、测试和交付产品的增量。团队成员通常包括开发人员、测试人员和其他必要的技能。研发团队在冲刺计划会议中承诺完成的工作，并通过日常站会进行协调和信息共享。他们负责根据产品待办列表中的任务完成工作，并在冲刺回顾会议和冲刺评审会议中展示和讨论已完成的工作。
-
项目经理（Scrum Master）：是团队的敏捷教练和迭代过程的卫道士。他们致力于促进Scrum方法的实施和持续改进。项目经理负责移除团队面临的障碍，确保团队遵守Scrum的规则和实践，并促进团队的自组织和跨功能性。还组织和引导冲刺回顾会议和日常站会，以及培训新成员加入Scrum团队。
流程
产品经理（收集用户需求）->项目经理（对需求进行优先级划分，计划项目日程）->每日站会（汇报昨天工作是否完成以及遇到的问题，今题的工作计划）->项目演示
测试模型
V模型
需求分析与系统设计：验证产品所给的软件需求是否正确；确定编程语言，使用框架
概要设计：设计项目结构
详细设计：设计每个接口，库表，定时任务
编码： 代码编写
此时测试人员介入进行后续测试
单元测试：java中测试每一个方法，类
集成测试：将许多方法集成到一起测试
系统测试：测试模块和模块之间是否有影响，测试所有功能
Acceptance test: Before the project goes online, check and accept the product and operation
Features: On the left is the development process, on the right is the testing process (similar to the waterfall model)
Pros: The testing process is divided into many types
Disadvantages: The testers intervene late, and it is too late to find the problem.
W model
Also called double V model
Features: develop a V, test a V
Advantage: testers can intervene in requirements earlier
Disadvantages: Testers and developers are still serial to a certain extent; because it is similar to the waterfall model, the requirements document is determined from the beginning, and the V model and W model cannot embrace change and cannot be applied to agile