1. Basic concepts of software testing
1.1 Requirements
In an enterprise, requirements are mainly divided into user requirements and software requirements~
User needs:
It can be simply understood as the requirements put forward by Party A. If there is no Party A, then it is the task that the end user must complete when using the product; user requirements are generally relatively simple, without certain restrictions (various)~
For example: If there is a voice-activated light now, then there can be multiple user requirements: the voice-activated light is in the shape of a panda, the voice-activated light is made of gold, and the voice-activated range of the voice-activated light is the distance from the stairs... ..
It can be seen that user needs are varied and cannot be used as a basis for reference (technically, input costs, benefits...), it is necessary to extract and analyze user needs~
Software Requirements:
Also known as functional requirements, this requirement will describe in detail the software functions that developers must implement~
Software requirements are the basis for testers to carry out testing work~
As an example, explain the difference between user requirements and software requirements:
npy put forward a demand: I just want to drink milk tea (this is a user demand)~
So I can pick it up and buy it myself, but I need to check with npy repeatedly: Which store is it? Which milk tea is it? Is it hot or iced? Do you want to add some ingredients? (This is the software requirement)~
1.2 Test Cases
Test cases are a set of basis for testers to perform tests. Testers need to write test cases before performing tests. The quality of test cases has a great relationship with the quality of product testing~
Test cases should be as broad as possible~
After that, you can test one by one according to the test cases~
If there is no test case, then you can only use your mind to test and memorize when testing, and you will get confused about what you have tested in the end~
Therefore, the existence of test cases can guide orderly testing, improve test coverage, and prevent the risk of "missing tests"~
Of course, although there is a saying in the test that "it is impossible to do a complete test", the testers should try their best to avoid "missing tests" and ensure that there will be no obvious problems on the line~
The emergence of test cases mainly solves two problems: what to test and how to test ~
A test case is a set of sets provided to the system under test for the purpose of implementing the test. This set of sets includes: test environment, operation steps, test data, expected results, etc.~
For example, the first test case above can be written like this:
However, if it is for a certain function, it is very troublesome to design dozens or even hundreds of test cases~
In fact, today's Internet companies mainly use the "mind map" method to write test cases, such as:
1.3 BUG
The origin link of the first BUG - from Zhihu
If and only if the specification exists and is correct, the mismatch between the program and the specification is an error, that is, BUG~
When the function is not mentioned in the requirement specification, the judgment standard is based on the end user: when the program does not meet the functional requirements reasonably expected by the end user, it is a BUG~
BUG example:
For example, when implementing the user login function, the requirements specification clearly stipulates that the shortest password input is 6 digits, and the longest password is 15 digits; however, in fact, if the input is 5 digits, it can also pass, then this is a BUG ~
For example, when sharing information with other people, sometimes it displays the style of a default component, and sometimes it displays a picture; at this time, the sharing function is normal, but the display is not good when it is sent to others , you can also mention BUG at this time (but it may not be mentioned in the requirements document)~
2. Development model and test model
2.1 Development Model
The development model can be understood as the development process/project promotion process~
Common development models include: waterfall model, spiral model, incremental model, iterative model, agile model, etc.~
Of course, it can also be understood as the software life cycle (the period from the beginning to the end of the software). The software life cycle can be divided into six stages: requirements analysis, planning, design, coding, testing, operation and maintenance~
Let's give an example to better understand these six stages:
If a house needs to be built now, what is the life cycle of the house?
Requirements analysis stage:
First of all, we need to clarify why we want to build a house~
Is the house for commercial or residential use?
If you need to build a commercial house, where and how many floors do you need to build~
Is the ratio of construction investment to income too large~
......
计划阶段：
什么时候开始建造房子~
房子什么时候动工，房子什么时候竣工~
大概需要一年的时候来建造，2023年1月1日开始动工，2024年竣工并投入使用~
......
设计阶段：
先出设计图，对房子有一个明确的布局，
如：谁来负责打地基，谁来负责建筑框架，谁来负责砌墙，谁来负责粉刷~
......
编码阶段：
脚踏实地的按照需求和计划一步一步的建造房子~
......
测试阶段：
等到房子交付的日期了，就要进行房子的验收测试，
如：房子有没有漏水，房子有没有偷工减料，房子是否按照规定的样子来建造~
......
运行维护阶段：
房子交房之后，用户也已经住进去了，后期也许会出现一些异常的情况，
如：房子漏水，墙皮掉落~
需要用户自己来进行维护~
通过上述建造房子的例子，就可以更好地理解软件的各个生命周期~
软件生命周期 各阶段需要进行的 部分内容 如下：
如上，软件开发有它自己的整个生命周期，
其实 软件测试也有着它自己的生命周期：它诠释了 测试人员在软件 整个生命周期里面，在各个阶段需要做的事情~
软件测试的生命周期 5个阶段：
需求分析 -> 测试计划 -> 测试设计与开发 -> 执行测试 -> 测试评估
ps：
需求分析：软件测试人员往往是最了解需求的人~
测试计划：测试人员也需要编写 测试计划文档，明确标注了：有多少个测试人员，什么时候开始测试~
测试设计与开发：测试人员需要借助 需求文档 + 技术文档 来编写测试用例~
2.1.1 瀑布模型
瀑布模型
需要注意的是，瀑布模型 不重视测试的，即：在编码及之前的几个阶段，都不涉及到测试的动作（当然，也是包含前面的测试 5个阶段）~
这就意味着，瀑布模型 更看重于前面的几个阶段~
瀑布模型 很容易的可以看出，它是一个线性结构：这就意味着 前一个阶段结束之后，后一个阶段才会开始~
这就意味着，在最终测试的时候，发现的错误 可能不仅仅是 编码阶段的错误，前面阶段 也可能会出现错误~
这就埋下了一个隐患：风险 往往会 延迟 到后期的 测试阶段 才会显露，因而 失去 及早纠正 的机会~
特别是，测试被后置， 就说明需要把足够的时间留给测试，如果最后留给测试的时间有限，那么 测试就可能不充分，最终就可能会把一些问题暴露给用户~
当然，瀑布模型的最大缺陷就在于：
由于瀑布模型是一个线性模型，所以项目需要实现的所有功能 必须要在一个周期里面完成~
而如果是一个大型项目的话，每一个阶段都要经历很久，到最后 用户在很晚之后才可以看到~
但是，我们不可能保证，在这一段时间内，用户的需求会不会发生变化（某一段时间很急需某个需求A，当时没有上线；等已经不需要需求A了，才上线）~
当然，瀑布模型 在软件工程中占有着重要的地位，它是所有其他模型的基础框架，后面的其他模型都是在瀑布模型的基础上不断优化的~
瀑布模型适用场景：需求固定的小型项目（不能很好的迎接需求的变化）~
2.1.2 螺旋模型
螺旋模型
螺旋模型 是在 瀑布模型 的基础上进行优化的，在每个阶段都增加了 风险分析（把那条曲线拉直）~
发现有风险了，消除风险之后，会生成新的原型~
但是，这种模型一定是耗时耗力的，成本大，需要去找专门的风险分析人才~
螺旋模型适用场景：需求不确定，变化的可能性很大的大型项目~
2.1.3 增量模型、迭代模型
ps：计划之类的阶段就没有画出来了
增量模型：使项目进行模块化，每个模块都可以进行独立的开发和上线~
优势：产品可以在较短的时间内尽快的交付给用户去使用~
迭代模型：假如说一个产品有A、B、C三个功能，迭代模型 会先完成这三个功能的基础版本，之后再经历一期又一期的迭代优化，直到这三个功能非常的优秀~
总之，增量模型 和 迭代模型 是通常混为一谈的，但是其实它们是有区别的~
增量模型一定是逐块建造的，可以先开发功能A，也可以先开发功能B、功能C~
迭代模型一定是在基础的版本上进行 更新优化，是精益求精的过程~
2.1.4 敏捷模型
在敏捷模型中，没有强调类似于其他模型中 重流程 的一些东西~
提出了《敏捷宣言》：通过身体力行和帮助他人来揭示更好的软件开发方式，形成了如下价值观：
敏捷宣言
ps：
敏捷模型 强调了 团队内部人员需要尽可能的进行高效的沟通~
强调了 最终的标准就是：可交付的软件；至于 开发软件过程中 写了多少份文档 并不是特别在乎，而在一个周期结束之后，需要给一个结果：或有一个新的功能，或有一个新的产品 等等~
强调了 须把客户的需求 放在第一位，与客户之间需要有一个高效的协作；如：之前客户有需求A，以合同的形式告诉；后来客户有需求B，那就需要去实现需求B了~
强调了 需要时刻响应变化，而不是和前面几个模型一样，一直不变，否则如果出现问题的话，开发的成本就会越来越高了~
即：敏捷宣言的特点是：轻流程、轻文档、重目标、重产出~
2.1.4.1 scrum模型
敏捷开发有很多种方式，其中 scrum模型 是比较流行的一种~
在 scrum模型 里面，需要了解三个重要的角色 和 五个重要的会议~
三个角色
scrum 由 产品经理、项目经理、研发团队 三个角色组成~
产品经理：收集用户需求，转变成软件需求，推动研发团队去进行功能的开发~
项目经理：很多企业是 没有项目经理 这一角色的，此时由 产品经理 承担，其职责是 在合理的周期内，去推进项目可以如期的进行；如 在计划阶段规定了项目什么时候开始，什么时候结束，项目经理就需要检查到了这段时间 计划的有没有完成，如果遇到项目问题 就需要去协调解决问题，召开会议，为研发团队服务；可以简单的理解——项目经理就是催加班、催进度的~
研发团队：由不同技能的人员组成（如 前端、后端、测试人员 等等），通过紧密协同，完成每一次迭代的目标，交付产品~
基本流程
2.2 测试模型
除了敏捷模型之外，其他几个模型都把测试阶段放到了后期，说明并不重视测试~
而在后续的发展中，测试就被重视起来了~
这里就介绍两种测试模型：V模型、W模型~
2.2.1 V模型
V模型
特点：
明确了测试有不同的类型，而且每个类型和前期的开发工作之间有对应关系~
缺陷：
测试后置~
2.2.2 W模型
W模型
特点：
测试从一开始就介入（软件测试贯穿于软件的整个生命周期），有利于尽早地全面的发现问题~
缺陷：
开发和测试虽然是同步的，但是仍然存在这前后的线性关系~
不支持敏捷模型（太重文档了）~