平顶山腾达职业培训学校：软件测试师零基础入门知识要点！
软件测试工程师是使用人工操作或软件自动进行的方式来检验他是否满足规定的用户需求或弄清预期结果与实际结果之间的差别与过程。它在一个软件生命周期当中最重要的一环，担负着把控、监督软件质量的重任。
接下来，给我5分钟时间，让零基础的你了解软件测试师的入门知识要点。
1
什么是bug?
所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。
软件的Bug：狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
仅就狭义概念而言，软件出现Bug的原因有：对各种流程分支考虑不全面；对边界情况的处理不到位；编码时的手误。任何软件在发布时都不可能是绝对的零Bug。
在软件过程管理中通行的CMM（能力成熟度模型）中规定的软件质量标准是（Bug个数/千行源码）：CMM1级 11.95、CMM2级 5.52、CMM3级 2.39、CMM4级 0.92、CMM5级 0.32
当且仅当，程序规格说明书(软件需求)存在并且合理，如果软件功能和软件规格说明书不相符合，我们就说是软件错误。当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不相符合，就说明是软件错误；软件测试的阶段：整个软件开发的生命周期，需求阶段介入验证需求的合理性和正确性。
2
bug的生命周期+管理流程
（软件测试流程）需求分析——测试计划——测试设计/开发——测试执行——测试报告
需求分析：分析需求，验证需求的正确性、合理性；细化需求，根据需求去提炼
测试计划：确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境
测试设计/开发：开发测试用例测试执行：开发人员已经提交了代码，执行测试，提交BUG
测试报告：对本次迭代的测试情况进行分析和总结；写了多少测试用例执行了多少；发现了多少BUG，修改了多少，剩余多少BUG没有解决；方案；测试的覆盖率；上线风险评。
3
测试中的需求是什么？
用户的期望和满足合同（文档，规则，标准）的规定所需要的条件和权限。软件需求是用户需求转换而来的，它是用户需求的细化，是用户需求的具体实现细节和规范。
用户需求比较粗略，直接实现会有困难，因为没有细节，所以需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体的可实现的过程文档。
4
常用测试用例的方法
黑盒测试：
等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
基于等价类划分和边界值分析方法，设计的测试用例:
因果图法：
因果图法主要涉及的是因果关系类内容的测试，在写测试用例时，我们要区分清楚“恒等、或、非”关系，还要区分出各类约束。因果图可以用于描述输入与输出的相互关系。但是其绘制过程比较繁琐。因果图可以转化成决策表。建议在测试过程中，尽量直接绘制决策表。
（比如：E约束(异；异或)：a，b最多有一个可能为1，不能同时为1；
I约束(或；包含)：a，b，c中至少有一个必须为1，不能同时为0；
O约束(惟一)：a和b必须有一个且仅有一个为1；
R约束(要求)：a是1时，b必须是1，即a为1时，b不能为0；
M约束：对输出条件的约束，若结果a为1，则结果b必须为0）
决策表测试：仅适合对输入域展开分析，不适合对输出域展开测试。
错误推测法：这种办法优点是可以充分发挥测试人员的经验和潜能，命中率高；缺点也非常明显，就是难以保证覆盖率。
另外，黑盒测试方法设计的测试用例，可能存在漏洞和冗余，但一般情况下，测试人员很难对其进行评估。所以，测试人员还可利用白盒测试的覆盖指标，来衡量黑盒测试方法的漏洞和冗余情况。
白盒测试：
一类是静态测试。
这类测试主要侧重于源代码检查和优化。其基本测试方法都是不需要设计测试用例，直接查看源代码和模拟执行代码就行。通过提出结构设计优化的意见和有关测试重点的建议，就能完成相应的测试工作。
另一类则是动态测试。
这类测试主要侧重于关键程序结构的测试，其基本测试方法是通过对导致程序结构复杂度的判定表达式、执行路径和循环结构，来设计相应的测试用例。从而达到某种程度的测试覆盖，确保测试的测试完备性和无冗余性。
那么，这两类测试的典型测试方式是什么呢？静态测试的典型方法是：同行评审、静态结构分析、代码质量度量和对变量的数据流测试。而动态测试的方法则有很多，包括：基于逻辑表达式覆盖指标的判定测试；基于全路径覆盖的独立路径测试；以及基于循环过程覆盖的对循环的测试等等。
5
如何设计一个好的测试用例?
好的”测试用例必须具备哪些特征？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
具体到测试用例设计本身的设计，两个关键的点：
①从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
②对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
用例设计的其他经验：
①只有深入理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
②必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
③需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
6
软件测试员常用的测试模型
软件测试V模型：
特点： 每一个阶段独立性强；左边每一个阶段都是右边测试阶段的依据；和右边阶段每一个测试阶段一一对应。
缺点：编码后才进行测试；串行的过程，测试是在编码后有的，测试的介入比较晚导致前期的错误后期才发现，后期测试发现时，已经失去了错误及时纠正的最好时机。
软件测试W模型：
又称双V模型
特点：每一阶段独立性强；测试一开始就介入；可以保证前期的问题及时发现和纠正；测试和开发并行。
缺点：每一阶段都是串行的过程；一个阶段完了之后就进行下一个阶段。不适合需求频繁变更的项目，不支持敏捷(拥抱变化)开发。
7
什么是测试覆盖率?
测试覆盖率
测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。
需求覆盖率
需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。代码覆盖率代码覆盖率是至少被执行了一次的条目数占整个条目数的百分比。
三种代码覆盖率指标
代码覆盖率的价值统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。代码覆盖率的局限性总结来讲，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能保证软件的质量。
代码覆盖率工具JaCoCo是一款Java代码的主流
开源覆盖率工具Javascript的
代码覆盖率：JSCoverage和Istanbul8
以终为始，如何才能做好测试计划?
一份好的测试计划要包括：
①测试范围明确“测什么”和“不测什么”
②测试策略明确“先测什么后测什么”和“如何来测”
（1）功能测试（2）兼容性测试（3）性能测试等
③测试资源明确“谁来测”和“在哪里测”④测试进度明确开始时间、所需工作量、预计完成时间、上线发布时间行为驱动开发，BDD，最典型的框架是“Cucumber”⑤测试风险预估明确如何有效应对各种潜在的变化
9
互联网产品的测试策略应该如何设计
发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程。
传统软件产品的测试策略设计
互联网产品的测试策略设计
互联网产品的菱形测试策略（重量级API测试、轻量级GUI测试、轻量级单元测试）
1.以中间层的API测试为重点做全面的测试。
2.轻量级的GUI测试，只覆盖最核心直接影响主营业务流程的E2E场景。
3.最上层的GUI测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
4.单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。
软件测试工程师是使用人工操作或软件自动进行的方式来检验他是否满足规定的用户需求或弄清预期结果与实际结果之间的差别与过程。它在一个软件生命周期当中最重要的一环，担负着把控、监督软件质量的重任。
接下来，给我5分钟时间，让零基础的你了解软件测试师的入门知识要点。
1
什么是bug?
所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。
软件的Bug：狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
仅就狭义概念而言，软件出现Bug的原因有：对各种流程分支考虑不全面；对边界情况的处理不到位；编码时的手误。任何软件在发布时都不可能是绝对的零Bug。
在软件过程管理中通行的CMM（能力成熟度模型）中规定的软件质量标准是（Bug个数/千行源码）：CMM1级 11.95、CMM2级 5.52、CMM3级 2.39、CMM4级 0.92、CMM5级 0.32
当且仅当，程序规格说明书(软件需求)存在并且合理，如果软件功能和软件规格说明书不相符合，我们就说是软件错误。当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不相符合，就说明是软件错误；软件测试的阶段：整个软件开发的生命周期，需求阶段介入验证需求的合理性和正确性。
2
bug的生命周期+管理流程
（软件测试流程）需求分析——测试计划——测试设计/开发——测试执行——测试报告
需求分析：分析需求，验证需求的正确性、合理性；细化需求，根据需求去提炼
测试计划：确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境
测试设计/开发：开发测试用例测试执行：开发人员已经提交了代码，执行测试，提交BUG
测试报告：对本次迭代的测试情况进行分析和总结；写了多少测试用例执行了多少；发现了多少BUG，修改了多少，剩余多少BUG没有解决；方案；测试的覆盖率；上线风险评。
3
测试中的需求是什么？
用户的期望和满足合同（文档，规则，标准）的规定所需要的条件和权限。软件需求是用户需求转换而来的，它是用户需求的细化，是用户需求的具体实现细节和规范。
用户需求比较粗略，直接实现会有困难，因为没有细节，所以需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体的可实现的过程文档。
4
常用测试用例的方法
黑盒测试：
等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
基于等价类划分和边界值分析方法，设计的测试用例:
因果图法：
因果图法主要涉及的是因果关系类内容的测试，在写测试用例时，我们要区分清楚“恒等、或、非”关系，还要区分出各类约束。因果图可以用于描述输入与输出的相互关系。但是其绘制过程比较繁琐。因果图可以转化成决策表。建议在测试过程中，尽量直接绘制决策表。
（比如：E约束(异；异或)：a，b最多有一个可能为1，不能同时为1；
I约束(或；包含)：a，b，c中至少有一个必须为1，不能同时为0；
O约束(惟一)：a和b必须有一个且仅有一个为1；
R约束(要求)：a是1时，b必须是1，即a为1时，b不能为0；
M约束：对输出条件的约束，若结果a为1，则结果b必须为0）
决策表测试：仅适合对输入域展开分析，不适合对输出域展开测试。
错误推测法：这种办法优点是可以充分发挥测试人员的经验和潜能，命中率高；缺点也非常明显，就是难以保证覆盖率。
另外，黑盒测试方法设计的测试用例，可能存在漏洞和冗余，但一般情况下，测试人员很难对其进行评估。所以，测试人员还可利用白盒测试的覆盖指标，来衡量黑盒测试方法的漏洞和冗余情况。
白盒测试：
一类是静态测试。
这类测试主要侧重于源代码检查和优化。其基本测试方法都是不需要设计测试用例，直接查看源代码和模拟执行代码就行。通过提出结构设计优化的意见和有关测试重点的建议，就能完成相应的测试工作。
另一类则是动态测试。
这类测试主要侧重于关键程序结构的测试，其基本测试方法是通过对导致程序结构复杂度的判定表达式、执行路径和循环结构，来设计相应的测试用例。从而达到某种程度的测试覆盖，确保测试的测试完备性和无冗余性。
那么，这两类测试的典型测试方式是什么呢？静态测试的典型方法是：同行评审、静态结构分析、代码质量度量和对变量的数据流测试。而动态测试的方法则有很多，包括：基于逻辑表达式覆盖指标的判定测试；基于全路径覆盖的独立路径测试；以及基于循环过程覆盖的对循环的测试等等。
5
如何设计一个好的测试用例?
好的”测试用例必须具备哪些特征？
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
具体到测试用例设计本身的设计，两个关键的点：
①从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
②对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。
用例设计的其他经验：
①只有深入理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
②必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
③需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
6
软件测试员常用的测试模型
软件测试V模型：
特点： 每一个阶段独立性强；左边每一个阶段都是右边测试阶段的依据；和右边阶段每一个测试阶段一一对应。
缺点：编码后才进行测试；串行的过程，测试是在编码后有的，测试的介入比较晚导致前期的错误后期才发现，后期测试发现时，已经失去了错误及时纠正的最好时机。
软件测试W模型：
又称双V模型
特点：每一阶段独立性强；测试一开始就介入；可以保证前期的问题及时发现和纠正；测试和开发并行。
缺点：每一阶段都是串行的过程；一个阶段完了之后就进行下一个阶段。不适合需求频繁变更的项目，不支持敏捷(拥抱变化)开发。
7
什么是测试覆盖率?
测试覆盖率
测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。
需求覆盖率
需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。代码覆盖率代码覆盖率是至少被执行了一次的条目数占整个条目数的百分比。
三种代码覆盖率指标
代码覆盖率的价值统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。代码覆盖率的局限性总结来讲，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能保证软件的质量。
代码覆盖率工具JaCoCo是一款Java代码的主流
开源覆盖率工具Javascript的
代码覆盖率：JSCoverage和Istanbul8
以终为始，如何才能做好测试计划?
一份好的测试计划要包括：
①测试范围明确“测什么”和“不测什么”
②测试策略明确“先测什么后测什么”和“如何来测”
（1）功能测试（2）兼容性测试（3）性能测试等
③测试资源明确“谁来测”和“在哪里测”④测试进度明确开始时间、所需工作量、预计完成时间、上线发布时间行为驱动开发，BDD，最典型的框架是“Cucumber”⑤测试风险预估明确如何有效应对各种潜在的变化
9
互联网产品的测试策略应该如何设计
发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程。
传统软件产品的测试策略设计
互联网产品的测试策略设计
互联网产品的菱形测试策略（重量级API测试、轻量级GUI测试、轻量级单元测试）
1.以中间层的API测试为重点做全面的测试。
2.轻量级的GUI测试，只覆盖最核心直接影响主营业务流程的E2E场景。
3.最上层的GUI测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
4.单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。
