1. 从「用户登录」开始谈测试

1.1.将「用户登录」测试用例分分类

等价类划分和边界值分析方法是最常用、最典型、也是最中要的黑盒测试方法（2.3.中会详细说明）

等价类划分：是将所有可能的输入数据划分成若干个子集，在每个子集中任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成一个等价类。
边界值分析方法：是选取输入、输出的边界值进行测试。

用户登录测试用例.png

优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、便于发现问题的测试用例。

1.2.穷尽测试

所谓的“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。
软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平衡。

2. 如何设计一个“好的”测试用例？

2.1. 什么是“好的”测试用例？

“好的”测试用例一定是一个完备的集合，他能够覆盖所有等价类以及各种边界值，而跟否发现缺陷无关。

2.2. “好的”测试用例具备那些特征

整体完备性：“好的”测试用例一定是完备的整体，是有效的测试用例组成的集合，能够完全覆盖测试需求。
等价类划分的准确性：值的是对于没个等价类都能保证只要其中一个输入测试通过，其他数据也一定测试通过。
等价类集合的完备性：需要保证所有可以的边界值和边界条件都已经正确识别。

2.3. 三种常用的测试用例设计方法

测试用例的设计方法：比如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方方法、形式化方法、扩展有限状态机方法等等。

我们以身份证中的7～14位日期是否有效设计测试用例

等价类划分方法：
- 有效等价类：年按人类最高年龄120岁推算，有效年份应为2019～1899年中间；月应为1～12月；日应为1～31日；
- 无效等价类：年小于1899年或大于2019年；月等于00或大于12；日等于00或大于31日；
边界值分析方法：选取闰年非闰年20040229以及20050228；大小月日期20000630以及2000731；
错误推测方法：身份证号不可重复；数据库链接失败；

有了上述的三种方法后，如果要对身份证号码有效性设计全面的设计用例，将所有位的有效性都考虑到的话，首先要去具体了解了身份证编码规则后去做对应的有效验证。

具体到测试用例本身的设计，有两个关键点需要你注意。

从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。

最后，如果想设计一个“好的”测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。

3. 单元测试（Junit）

3.1. 为什么要做单元测试？

很多公司都不会做单元测试，包括我，现阶段也不做单元测试。主要原因是现在的开发要求速度的要快，迭代要快，不做单元测试可以节约很大的时间成本以及人力资源。
但放在长远的时间线上来看，不做单元测试会存在出现Bug不知道那块代码出了问题（因为不停的在迭代会让原先成立的接口出现一些因为原先需求开始忽略，而导致不知道是那里出了问题）
这时候单元测试的作用就体现了，每次迭代的功能代码与测试代码对应，跑一遍测试代码就知道哪里出了问题，可及时修改。

3.2. Java中使用的测试框架Junit5

由于我也是初学者，就不展开说了，下面是Junit5的学习链接：JUnit 5 Jupiter API
以及Junit官方文档：官方文档

学习中多理解注释（Annotations）与断言（Assertions）的内容。后续对Junit的学习内容单独写文章说明。

总之，测试用的框架与工具是其次，重要的是先弄清楚要测什么！

4. 自动化测试

4.1. 为什么要自动化测试？

自动化测试的本质是用一段代码去测试另一段代码的过程。由此可见，自动化测试的代码编写是费时费力的（这里依然推荐用Junit）。
自动化测试使用比较多的场景如下：

回归测试（再次测试原先已完成的功能代码）
持续运行测试系统稳定行及高并发场景的压力测试。
保证每次执行测试的操作以及验证的一致性。
此类较机械化操作的测试场景，需要用到自动化测试

4.2. 什么样的项目适合自动化测试？

需求稳定，不会频繁变更
研发和维护周期长，需要频繁执行回归测试
- 软件产品比软件项目更适合做自动化测试。
- 对于软件项目的自动化测试，就要看项目的具体情况了。最终目标是用20%的精力去覆盖80%的回归测试。
需要在多种平台上重复运行相同的场景
某些测试项目通过手工测试无法实现，或者手工成哥太高
被测软件的开发较规范，能够保证系统的可测试性
测试人员已经具备一定的编程能力

总之，测试用例的设计是至关重要的，在这之前，不要花太多的精力在自动化测试上。如果维护自动化测试的代价高过了节省的测试成本，那么在这样的项目中推进自动化测试就会得不偿失。

5. 软件开发各阶段的自动化测试

这一讲的专业词汇较多，不懂的词汇多搜索了解下！

下面图中展示的是软件开发的各个阶段以及对应会使用到的技术、工具：

测试技术、工具.png

6. 什么是测试覆盖率？

测试覆盖率.png

需求覆盖率：需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。

代码覆盖率：代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。

这篇还是看原本较好，明白代码覆盖率是什么？该怎么做？

7. 如何高效填写软件缺陷报告？

7.1. 什么是缺陷报告？

缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。

7.2. 缺陷报告的组成部分

缺陷报告.png

8. 测试计划

8.1. 没有测试计划会怎么样？

很难确切地知道具体的测试范围，以及应该采取的具体测试策略；
很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行而有些测试则被遗漏的问题；
测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间就更难预估准确的时间节点了；
整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件。

8.2. 做测试计划中要解决那些问题？

测试计划.png

9. 软件工程师的核心竞争力

9 .1. 测试工程师的基础知识

测试基础知识.png

9.2. 传统测试工程是的核心竞争力

传统测试工程师的核心竞争力.png

9.3. 测试开发工程师

首先既然是测试开发工程师，那么代码开发能力是最基本的要求。

测试系统需求分析能力
更宽广的知识体系

10. 测试工程师需要掌握的非测试知识

与开发工程师相比，你需要了解的技术种类要多得多，视野也要宽广很多，只是在每类技术的深度方面不如开发工程师。

你可以参照下面这个比喻，来理解开发工程师和测试工程师的对知识的要求：开发工程师通常是“深度遍历”，关注的是“点”；而测试工程师通常是“广度遍历”，关注的是“面”。

非测试知识.png

11. 互联网产品测试策略

11.1. 传统软件测试策略设计

重单元测试

传统测试策略.png

11.2. 互联网产品测试策略

重API测试

互联网测试策略.png

软件测试52讲学习笔记（测试基础篇）