《软件测试52讲》
1、测试基础知识篇——（0~11讲）
2、GUI自动化测试篇——（12~21讲）
持续更新中~
测试基础知识篇
01——你真的懂测试吗？从“用户登录”测试谈起
从“用户登录”测试谈起，“用户登录”功能作为测试对象
作为测试工程师，你的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以你需要考虑的测试用例就需要更多、更全面。
等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
基于等价类划分和边界值分析方法，设计的测试用例
显式功能性需求和非功能性需求
显式功能性需求：软件本身需要实现的具体功能
非功能性需求：安全性、性能、兼容性
安全性测试用例包括：
1、用户密码后台存储是否加密；
2、用户密码在网络传输过程中是否加密；
3、密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4、不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
5、密码输入框是否不支持复制和粘贴；
6、密码输入框内输入的密码是否都可以在页面源码模式下被查看
7、用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
8、用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
9、连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10、同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11、同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
性能压力测试用例包括：
1、单用户登录的响应时间是否小于3秒；
2、单用户登录时，后台请求数量是否过多；
3、高并发场景下用户登录的响应时间是否小于5秒；
4、高并发场景下服务端的监控指标是否符合预期；
5、高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6、长时间大量用户连续登录和登出，服务器端是否存在内存泄露。
兼容性测试用例包括：
1、不同浏览器下，验证登录页面的显示以及功能正确性；
2、相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3、不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4、不同分辨率的界面下，验证登录页面的显示以及功能正确性。
测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测试的。“穷尽测试”，是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。
在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
02——如何设计一个“好的”测试用例“
好的”测试用例必须具备哪些特征？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
具体到测试用例设计本身的设计，两个关键的点：
1、从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
2、对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
用例设计的其他经验
1、只有深入理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
2、必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
3、需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
03——什么是单元测试？如何做好单元测试
单元测试
单元测试是批，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。
如何做好单元测试？
第一，代码的基本特征与产生错误的原因
第二，单元测试用例详解（单元测试的用例是一个“输入数据”和“预计输出”的集合。）
第三，驱动代码，桩代码和Mock代码（驱动代码是用来调用被测函数的，而桩代码和Mock代码是用来代替被测函数调用的真实代码的。）
驱动代码、桩代码和Mock代码三者的逻辑关系。
驱动代码（Driver）指调用被测函数的代码，在单元测试过程中，驱动模块通常包括调用被测函数前的数据准备、调用被测函数以及验证相关结果三个步骤。
桩代码（Stub）是用来代替真实代码的临时代码。
Mock代码和桩代码的本质区别是：测试期待结果的验证（Assert and Expectiation）
实际项目中如何开展单元测试？
1、并不是所有的代码都要进行单元测试，通常只有底层模块或核心模块的测试中才会采用单元测试。
2、你需要确定单元测试框架的选型，这和开发语言直接相关。Java（Junit和TestNG），Python（Pytest、Unitest）
3、为了能够衡量单元测试的代码覆盖率，通常你还需要引入计算代码覆盖率的工具。Java（JaCoCo）
4、最后你需要把单元测试执行、代码覆盖率统计和持续集成流水线做成集成，以确保每次代码递交，都会自动触发单元测试，并在单元测试执行过程中自动统计代码覆盖率，最后以“单元测试通过率”和“代码覆盖率”为标准来决定本次代码递交是否能够被接受。
04——为什么要做自动化测试？什么样的项目适合做自动化测试
自动化测试
自动化测试是，把人对软件的测试行为转化为由机器执行测试行为的一种实践
什么样的项目适合自动化测试？
第一，需求稳定，不会频繁变更
第二，研发和维护周期长，需要频繁执行回归测试
第三，需要在多种平台上重复运行相同测试的场景
第四，某些测试项目通过手工测试无法实现，或者手工成本太高
第五，被测软件的开发较为规范，能够保证系统的可测试性
第六，测试人员已经具备一定的编程能力
第六点的阻力：
（1）前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助，此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试；
（2）测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践中，而忽略了测试用例的设计，这将直接降低软件整体的质量。
05——你知道软件开发各阶段都有哪些自动化测试技术吗？
单元测试的自动化技术
第一，用例框架代码生成的自动化
第二，部分测试输入数据的自动化生成
第三，自动桩代码的生成
第四，被测代码的自动化静态分析
静态分析主要指代码的静态扫描，目的是识别出违反编码规则或编码风格的代码行。目前比较常用的代码静态分析工具有Sonar和Coverity等
第五，测试覆盖率的自动统计与分析
Web Service测试的自动化技术
Web Service测试，主要是指SOAP API和REST API这两类API测试，最典型的是采用SoapUI或Postman等类似的工具。但这类测试工具基本都是界面操作手动发起Request并验证Response，
所以难以和CI/CD集成，于是就出现了API自动化测试框架。
Web Service测试自动化包括：
第一，测试脚本架代码的自动化生成
第二，部分测试输入数据的自动生
第三，Response验证的自动化
Response验证自动化的核心思想是自动比较两次相同API调用的返回结果，并自动识别出有差异的字段值，比较过程可以通过规则配置去掉诸如时间戳、会话ID（Session ID）等动态值。
第四，基于SoapUI或者Postman的自动化脚本生成
GUI测试的自动化技术
GUI自动化测试主要分为两大方向：传统Web浏览器和移动端原生应用（Native Appp）的GUI自动化。附加（小程序）
传统Web浏览器的GUI自动化测试：Selenium、Puppteer
移动端原生应用：Appium
06——你真的懂测试覆盖率吗？
测试覆盖率
测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。
需求覆盖率
需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。
代码覆盖率
代码覆盖率是批至少被执行了一次的条目数占整个条目数的百分比。
三种代码覆盖率指标
代码覆盖率的价值
统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
代码覆盖率的局限性
总结来讲，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能保证软件的质量。
代码覆盖率工具
JaCoCo是一款Java代码的主流开源覆盖率工具
Javascript的代码覆盖率：JSCoverage和Istanbul
07——如何高效填写软件缺陷报告？
一份高效的缺陷报告主要由哪些部分组成及各部分的关键点。
1、缺陷标题
缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”，的模式。
2、缺陷概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。
3、缺陷影响
4、环境配置
5、前置条件
6、缺陷重现步骤
7、期望结果和实际结果
8、优先级（Priority）和严重程度（Severity）
9、变通方案（Workaround）
10、根原因分析（Root Cause Analysis）
11、附件（Attachment）
08——以终为始，如何才能做好测试计划？
一份好的测试计划要包括：
1、测试范围
明确“测什么”和“不测什么”
2、测试策略
明确“先测什么后测什么”和“如何来测”
（1）功能测试（2）兼容性测试（3）性能测试 等
3、测试资源
明确“谁来测”和“在哪里测”
4、测试进度
明确开始时间、所需工作量、预计完成时间、上线发布时间
行为驱动开发，BDD，最典型的框架是“Cucumber”
5、测试风险预估
明确如何有效应地各种潜在的变化
09——软件测试工程师的核心竞争力是什么？
测试开发岗位的核心其实是“测试”，“开发”的目的是更好地服务于测试
传统测试工程师的核心竞争力
1、测试策略设计能力
（1）测试要具体执行到程度；
（2）测试需要借助于什么工具；
（3）如何运用自动化测试以及自动测试框架，以及如何选型；
（4）测试人员资源如何合理分配；
（5）测试进度如何安排；
（6）测试风险如何应对。
2、测试用例设计能力
提高测试用例设计能力，平时要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，不断总结、归纳、举一反三。
3、快速学习能力
4、探索性测试思维
5、缺陷分析能力
6、自动化测试技术
7、良好的沟通能力
测试开发工程师的核心竞争力
1、测试系统需求分析能力
2、更宽广的知识体系
10——软件测试工程师需要掌握的非测试知识有哪些？
1、网站架构的核心知识
2、容器技术
Docker和Kubernetes
3、云计算技术
Sauce Labs 测试执行环境公有云服务
Appium+Selenium Grid集群 搭建移动终端设备的测试执行私有云
4、DevOps思维
Jenkins
5、前端开发技术
11——互联网产品的测试策略应该如何设计？
发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程
传统软件产品的测试策略设计
互联网产品的测试策略设计
互联网产品的菱形测试策略（重量级API测试、轻量级GUI测试、轻量级单元测试）
1、以中间层的API测试为重点做全面的测试。
2、轻量级的GUI测试，只覆盖最核心直接影响主营业务流程的E2E场景。
3、最上层的GUI测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
4、单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。