个人感想
先把个人感想列出来吧，全文很长，耐心看，可能要20分钟+，部分内容会比较详，阅读体验可能会比较差，因为都是文字为主；
总的来说，这个课程值这个价格，看完了之后，觉得知识面广了很多，不一定对实际工作有用，但是用来扩展知识面，是一个很不错的课程，同时也了解其他企业是怎么做的，建议小伙伴都看一下；
通过这个课程目录，其实也可以看得出，很多大公司的测试工程师，并不带带是业务测试，具备开发能力是必要条件，因为也希望能给自己一个警惕；
如果非要推荐，第5章的自动化测试工具跟35章的数据构建值得一看，里面的内容很丰富；
这个课程，陆陆续续看了好久，看的很认真，包括评论都不放过，因此看到有意思的评论，都会贴出来；
下面的内容都是亲手打出来的，因为jb依然相信，自己写/打出来的东西，印象会加深~
经历过的变革：
- 自动化测试用例设计与开发
- 测试框架选型
- 测试框架自行研发
- 测试框架架构设计
- 测试服务化
趋势总结：
- 自动化测试在软件质量工程中的地位发生了质的变化，从原来的已自动化测试为辅，但现在以自动化测试为主
- 产品迭代周期缩短，需要一套完善的高并发测试执行基础架构支持
- 合格的测试工程师关注的是纯粹的测试，优秀的测试工程师关心的是整体交付的质量
- 如何构建低维护成本，可以灵活组装的自动化脚本，涉及到分层设计模型
1）真的懂测试吗用户登录测试谈起
测试场景
输入用户名和密码，点击确认按钮，验证是否登录成功即可
最常用黑盒测试方法
等价类划分
将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，这样的子集就构成一个等价类；
边界值分析
是选取输入、输出的边界值进行测试； 简单描述就是正好等于、刚刚大于、刚刚小于；
边界值算是对等价类划分的补充
穷尽测试
指包含了软件输入值和前提条件所有可能组合的测试方法，完全穷尽测试的系统里应该不残留任何未知的软件缺陷；
但这种做法不实际，因为受时间成本，一般采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例；
显式功能性测试用例
显式功能性需求指的是软件本身需要实现的功能；
基于等价类划分和边界值分析方法：
其他场景用例：
非功能性需求
主要涉及安全性、性能和兼容性测试；
安全性测试用例：
性能压力测试用例：
兼容性测试用例：
小结
1）用例设计需要考虑明确的显示功能性需求，还要考虑兼容性、安全性、性能等一系列的非功能性需求；
2）用例设计是不可穷尽的，受限于时间成本，因此需要兼顾缺陷风险和研发成果之间的平衡；
2）如何设计一个“好的”测试用例
能够覆盖所有等价类以及各种边界值的用例都是好用例；
好的测试用例必须具备的特征
整体完备性
是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求；
等价类划分的准确性
对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过；
等价类和的完备性
保证所有可能的边界值和边界条件都已经正确识别；
3种最常用测试用例设计方法
等价类划分
等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果；
边界值分析
错误推测方法
如何才能设计出好的测试用例
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，再针对每个测试需求点设计测试用例；
比如selenium的代码可以通过录制生成，TestNG框架代码由自动化工具生成；
部分测试输入数据的自动化生成
这部分是指，自动化工具能够根据不同变量类型自动生成测试输入数据；
自动桩代码的生成
自动桩代码的生成是指自动化工具可以对被测试代码进行扫面分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制；
那什么是抽桩单元测试阶段，假如函数A内部调用的函数B是桩代码，那么在代码级集成测试阶段，希望函数A不再调用假的函数B，而是调用真是的函数B，这个用真实函数B代替原本桩代码函数B的操作，就成为抽桩；
被测代码的自动化静态分析
静态分析主要指代码的静态扫描，目的是识别出违反编码规则或编码风格的代码；
通常这部分工作是结合项目具体的编码规则和编码风格，由自动化工具通过内建规则和用户自定义规则自动化完成的；
常用的静态代码分析工具有Sonar和Coverity；
测试覆盖率的自动统计与分析
单元测试用例执行结束后，自动化工具可以自动统计各种测试覆盖率，包括代码行覆盖率、分支覆盖率、MD/DC覆盖率等；
这些自动统计的指标，可以帮助衡量单元测试用例集合的充分性和完备性，并可以为你增补测试用例以提高测试覆盖率的依据；
代码级集成测试的自动化技术
简单的说，代码级集成测试是指将已经开发完成的软件模块放在一起测试；
代码级集成测试与单元测试最大的区别是，代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试仲允许使用桩代码来模拟内部调用的其他函数；
Web Server测试的自动化技术
Web Server测试，主要是指SOAP API和REST API这两类API测试，最典型的是采用SoapUI和Postman等类似的工具；
但这类测试工具基本都是界面操作手动发起requests并验证response，所以难以和CI/CD集成，于是乎就出现了API自动化测试框架；
如果采用API自动化测试框架来开发测试用例，那么这些测试用例的表现形式就是代码，如下：
下图所示为每个Java文件内部详细的代码覆盖率情况，绿色行表示已经被覆盖，红色行表示尚未被覆盖，黄色行表示部分覆盖； 左侧绿色菱形块表示该分支已经被完全覆盖、黄色菱形块表示该分支仅被部分覆盖；
实现代码覆盖率的统计，最基本的方法就是注入(Instrumentation)； 注入就是在被测代码中自动插入用于覆盖率统计的探针（Probe）代码，并保证插入的探针代码不会给源代码带来任何影响；
对于Java代码来说，根据注入目标的不同，可以分为源代码（Source Code）注入和字节码（Byte Code）输入两大类； 基于JVM本身特性以及执行效率的原因，目前主流的工具基本都是使用字节码注入，注入的具体实现采用ASM技术；
ASM是一个Java字节码操纵框架，能被用来动态生成类或者增强既有类的功能，直接直接产生class文件，也可以在类被加载入JVM之前动态改变类行为；
根据注入发生的时间点，字节码注入又可以分为两大模式： On-The-Fly注入模式和Offline注入模式；
On-The-Fly注入模式
特点在于无需修改源代码，也无需提前进行字节码插桩，适用于支持Java Agent的运行环境；
优点是可以在系统不停机的情况下，实时收集代码覆盖率信息，缺点是运行环境必须允许使用Java Agent;
实现 On-The-Fly 模式，主要有两种技术方案：
- 借助Java Agent，利用执行在main()方法之前的拦截器方法premain()来插入探针，实际使用过程中需要在JVM的启动参数中添加”-javaagent”并制定用于实时字节码注入的代理程序，这样代理程序在装在每个class文件前，先判断是否已经插入了探针，如果没有则需要将探针插入class文件中，目前主流的JaCoCo就是使用这种方式；
Offline注入模式
Offline 模式也无需修改源代码，但是需要在测试开始之前先对文件进行插桩，并事先生成插过桩的class文件；
这种方式适用于不支持Java Agent的运行环境，以及无法使用自定义类装载器的场景；
优点是JVM启动时不再需要使用Java Agent额外开启代码，缺点是无法实时获取代码覆盖率信息，只能在系统停机时下获取；
Offlinne模式根据是生成新的class文件还是直接修改原class文件，又可以分为Replace和Inject两种不同模式；
和On-The-Fly注入模式不同，Replace和Inject的实现是在厕所运行前就已经通过ASM将探针插入了class文件，而在测试的运行过程中不需要任何额外的处理；
Cobertura就是使用Offline模式的典型代表；
小结
测试覆盖率通常被用来衡量测试的充分性和完整性，包括面向项目的需求覆盖率和偏向技术的代码覆盖率；
而需求覆盖率的统计方式不再适用于现在的敏捷开发模式，所有现在谈到的测试覆盖率，大多是指代码覆盖率；
高的代码覆盖率不一定能保证软件的质量，因为代码覆盖率是基于现有代码，无法发现那些未考虑某些输入已经未处理某些情况形成的缺陷；
7）如何高效填写软件缺陷 告
缺陷 告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出，把发现的缺陷准确无歧义地表达清楚，是测试工程师最基本的一项技能；
准确无歧义的表达就意味着，开发工程师可以根据缺陷 告快速理解缺陷，并精确定位问题；开发经理可以准确预估缺陷修复的优先级；产品经理可以额了解缺陷对用户或业务的影响以及严重性；
缺陷 告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员写作的有效性；
缺陷标题
缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常使用”在什么情况下发生了什么问题“的模式；
描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述；描述的同时还必须清楚地表述发生问题的上下文，也就是问题出现的场景；
而且缺陷的标题不易过长，对缺陷更详细的描述应该放在缺陷概述里；
缺陷概述
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化；
缺陷概述的目的，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质；
缺陷影响
缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度；
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity）,开发经理会以此为依据来决定修复该缺陷的优先级；产品经理会以此为依据来衡量缺陷的严重 程度，并觉得是否要等该缺陷被修复后才能发布产品；
准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验；
环境配置
环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息，比如操作系统类型和版本、被测软件软包、浏览器的种类和版本、被测软件的配置信息、集群的配置参数等等；
需要注意的是，环境配置的内容是按需描述，就是只描述那些重现缺陷的环境敏感信息；
前置条件
前置条件是指测试步骤开始前系统应该处在的状态，目的是减少缺陷重现步骤的描述，排除不必要的干扰，使其更有针对性；
缺陷重现步骤
缺陷重现步骤是整个缺陷 告中最核心的内容，目的在于用简洁的语言像开发工程师展示缺陷重现的具体操作步骤；
需要注意的是，操作步骤通常是从用户角度出发来描述，每个步骤都应该是可操作且连贯的；
在写缺陷重现步骤时，要反复执行这些步骤确认：
- 确保缺陷的可重现性；
- 找到最短的重现路径；
而对于缺陷重现步骤的描述，应该要避免3个场景问题：
- 笼统的描述，缺乏可操作的具体步骤；
- 出现与缺陷重现不相关的步骤；
- 缺乏对测试数据的相关描述；
期望结果和实际结果
在描述重现步骤的过程中，需要明确说明期望结果和实际结果； 期望结果来自于对需求的理解，而实际结果来自于测试执行的结果；
优先级（Priority）和严重程度（Severity）
根据百度百科的解释，缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度；
严重程度是缺陷本身的属性，通常确认后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动；
那缺陷优先级和严重程度是什么关系/p>
- 缺陷越严重，优先级越高；
- 缺陷影响的范围越大，优先级也会越高；
- 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但优先级高的问题；
- 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况；
变通方案（Wordaround）
变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者一同决定；
变通方案的有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据；
根原因分析如
如果在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升；
附件
附件通常是为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI测试的执行食品等；
小结
一份高效的软件缺陷 告，应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前提条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、原因分析、附件这几大块；
其他想说说
如何对一个阶段的BUG进行统计、分析并 告/p>
这种属于测试缺陷统计，bug趋势分析，bug收敛情况，bug模块分布，bug发现阶段统计等等，属于面向管理层和质量流程保障团队，一般这种都是利用缺陷管理系统的自带功能来生成类似的 告；
除了上面所需要的内容，还需要以下内容：
- 缺陷模块，方便后期统计；
- 能准确指派BUG给具体负责人，最简单说，先确认是后端还是前端的问题；
- 出现的概率；
- 对比性炎症；
8）以终为始，如何才能做好测试计划
在早期的软件工程实践中，软件测试计划的制定通常是在需求分析以及测试需求分析完成后开始，并且是整个软件研发声明周期中的重要环节；
没有测试计划会怎么样/h3>
如果没有测试计划，会带来什么问题/p>
- 很难确切地知道具体的测试范围，以及应该采取的具体测试策略；
- 很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行，而有些测试则被遗漏的问题；
- 测试的整体进度完全不可控，甚至很难确切知道母亲测试的完成情况，对于测试完成时间就更难预估准确的时间节点；
- 整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件；
从这些问题，可以逆向思维推导出，一份好的测试计划要包括以下几点： 测试范围、测试策略、测试资源、测试进度和测试风险预估；
测试范围
顾名思义，测试范围描述的是被测对象以及主要的测试内容；
测试范围的确定通常是在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步校验，有助于在早期阶段发现潜在的测试遗漏；
测试策略的话题
测试策略简单来讲就是需求明确”先测什么后测什么”和”如何来测”两个问题；
测试策略会要求明确测试的重点，以及各项测试的先后顺序；
测试策略还需要说明，采用什么样的测试类型和测试方法；不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法；
功能测试
根据测试需求分析的思维导图来设计测试用例；
这里需要注意，要先实现主干业务流程的测试自动化；
对于需要手工测试的测试点，要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据；
还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口；
兼容性测试
Web测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体IOS/Android的版本等；
那怎么确定需要覆盖的移动设备类型以及IOS/Android的版本列表/p>
- 如果旧产品，通过产品统计数据分析历史数据，得出Top30%的移动设备机型及版本信息，兼容性覆盖这批固件即可；
- 如果是一个新产品，可以通过类似TalkingData这种 站来查看目前主流的移动设备，分辨率大小、IOS/Android等信息来确定测试范围；
一般来说，兼容性测试是功能测试的后期，等功能基本稳定后，才会开始兼容性测试；
假如是接入一些新框架，这时候就需要评估接入新框架的信息，此时就需要先进行兼容性测试，以确保后期不会引入无法解决的兼容性问题；
而兼容性用例
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！