《软件测试52讲》——测试基础知识篇

《软件测试52讲》

一、测试基础知识篇——（0~11讲）

二、GUI自动化测试篇——（12~21讲）

持续更新中~

测试基础知识篇

01——你真的懂测试吗？从“用户登陆”测试谈起

从“用户登陆”测试谈起，“用户登陆”功能做为测试对象

　　做为测试工程师，你的目标是要保证系统在各类应用场景下的功能是符合设计要求的，因此你须要考虑的测试用例就须要更多、更全面。

　　等价类划分方法，是将全部可能的输入数据划分红若干个子集，在每一个子集中，若是任意一个输入数据对于揭露程序中潜在错误都具备同等效果，那么这样的子集就构成了一个等价类。后续只要从每一个等价类中任意选取一个值进行测试，就能够用少许具备表明性的测试输入取得较好的测试覆盖结果。

　　边界值分析方法，是选取输入、输出的边界值进行测试。由于一般大量的软件错误是发生在输入或输出范围的边界上，因此须要对边界值进行重点测试，一般选取正好等于、刚刚大于或刚刚小于边界的值做为测试数据。

基于等价类划分和边界值分析方法，设计的测试用例

显式功能性需求和非功能性需求

　　显式功能性需求：软件自己须要实现的具体功能

　　非功能性需求：安全性、性能、兼容性

安全性测试用例包括：

　　一、用户密码后台存储是否加密；

　　二、用户密码在网络传输过程当中是否加密；

　　三、密码是否具备有效期，密码有效期到期后，是否提示须要修改密码；

　　四、不登陆的状况下，在浏览器中直接输入登陆后的URL地址，验证是否会从新定向到用户登陆界面；

　　五、密码输入框是否不支持复制和粘贴；

　　六、密码输入框内输入的密码是否均可以在页面源码模式下被查看

　　七、用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；

　　八、用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；

　　九、连续屡次登陆失败状况下，系统是否会阻止后续的尝试以应对暴力破解；

　　十、同一用户在同一终端的多种浏览器上登陆，验证登陆功能的互斥性是否符合设计预期；

　　十一、同一用户前后在多台终端的浏览器上登陆，验证登陆是否具备互斥性。

性能压力测试用例包括：

　　一、单用户登陆的响应时间是否小于3秒；

　　二、单用户登陆时，后台请求数量是否过多；

　　三、高并发场景下用户登陆的响应时间是否小于5秒；

　　四、高并发场景下服务端的监控指标是否符合预期；

　　五、高集合点并发场景下，是否存在资源死锁和不合理的资源等待；

　　六、长时间大量用户连续登陆和登出，服务器端是否存在内存泄露。

兼容性测试用例包括：

　　一、不一样浏览器下，验证登陆页面的显示以及功能正确性；

　　二、相同浏览器的不一样版本下，验证登陆页面的显示以及功能正确性；

　　三、不一样移动设备终端的不一样浏览器下，验证登陆页面的显示以及功能正确性；

　　四、不一样分辨率的界面下，验证登陆页面的显示以及功能正确性。

 　　测试的不可穷尽性，即绝大多数状况下，是不可能进行穷尽测试的。“穷尽测试”，是指包含了软件输入值和前提条件全部可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。

　　在绝大多数的软件工程实践中，测试因为受限于时间成本和经济成本，是不可能去穷尽全部可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

02——如何设计一个“好的”测试用例“

好的”测试用例必须具有哪些特征？

 　　在具体的用例设计时，首先须要搞清楚每个业务需求所对应的多个软件功能需求点，而后分析出每一个软件功能需求点对应的多个测试需求点，最后再针对每一个测试需求点设计测试用例。

具体到测试用例设计自己的设计，两个关键的点：

　　一、从软件功能需求出发，全面地、无遗漏地识别出测试需求是相当重要的，这将直接关系到用例的测试覆盖率。

　　二、对于识别出的每一个测试需求点，须要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。

用例设计的其余经验

　　一、只有深刻理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。

　　二、必须深刻理解被测软件的设计与实现细节，深刻理解软件内部的处理逻辑。

　　三、须要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

03——什么是单元测试？如何作好单元测试

单元测试

　　单元测试是批，对软件中的最小可测试单元在与程序其余部分相隔离的状况下进行检查和验证的工做，这里的最小可测试单元一般是指函数或者类。

如何作好单元测试？

　　第一，代码的基本特征与产生错误的缘由

　　第二，单元测试用例详解（单元测试的用例是一个“输入数据”和“预计输出”的集合。）

　　第三，驱动代码，桩代码和Mock代码（驱动代码是用来调用被测函数的，而桩代码和Mock代码是用来代替被测函数调用的真实代码的。）

驱动代码、桩代码和Mock代码三者的逻辑关系。

　　驱动代码（Driver）指调用被测函数的代码，在单元测试过程当中，驱动模块一般包括调用被测函数前的数据准备、调用被测函数以及验证相关结果三个步骤。

　　桩代码（Stub）是用来代替真实代码的临时代码。

 　　Mock代码和桩代码的本质区别是：测试期待结果的验证（Assert and Expectiation）

实际项目中如何开展单元测试？

　　一、并非全部的代码都要进行单元测试，一般只有底层模块或核心模块的测试中才会采用单元测试。

　　二、你须要肯定单元测试框架的选型，这和开发语言直接相关。Java（Junit和TestNG），Python（Pytest、Unitest）

　　三、为了可以衡量单元测试的代码覆盖率，一般你还须要引入计算代码覆盖率的工具。Java（JaCoCo）

　　四、最后你须要把单元测试执行、代码覆盖率统计和持续集成流水线作成集成，以确保每次代码递交，都会自动触发单元测试，并在单元测试执行过程当中自动统计代码覆盖率，最后以“单元测试经过率”和“代码覆盖率”为标准来决定本次代码递交是否可以被接受。

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——如何高效填写软件缺陷报告？

一份高效的缺陷报告主要由哪些部分组成及各部分的关键点。

　　一、缺陷标题　　

　　　　缺陷标题一般是别人最早看到的部分，是对缺陷的归纳性描述，一般采用“在什么状况下发生了什么问题”，的模式。

　　二、缺陷概述

　　　　缺陷概述一般会提供更多归纳性的缺陷本质与现象的描述，是缺陷标题的细化。

　　三、缺陷影响

　　四、环境配置

　　五、前置条件

　　六、缺陷重现步骤

　　七、指望结果和实际结果

　　八、优先级（Priority）和严重程度（Severity）

　　九、变通方案（Workaround）

　　十、根缘由分析（Root Cause Analysis）

　　十一、附件（Attachment）

08——以终为始，如何才能作好测试计划？

一份好的测试计划要包括：

一、测试范围

　　明确“测什么”和“不测什么”

二、测试策略

　　明确“先测什么后测什么”和“如何来测”

　　（1）功能测试（2）兼容性测试（3）性能测试 等

三、测试资源

　　明确“谁来测”和“在哪里测”

四、测试进度

　　明确开始时间、所需工做量、预计完成时间、上线发布时间

　　行为驱动开发，BDD，最典型的框架是“Cucumber”

五、测试风险预估

　　明确如何有效应地各类潜在的变化

09——软件测试工程师的核心竞争力是什么？

　　测试开发岗位的核心实际上是“测试”，“开发”的目的是更好地服务于测试

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

　　一、测试策略设计能力

　　　　（1）测试要具体执行到程度；

　　　　（2）测试须要借助于什么工具；

　　　　（3）如何运用自动化测试以及自动测试框架，以及如何选型；

　　　　（4）测试人员资源如何合理分配；

　　　　（5）测试进度如何安排；

　　　　（6）测试风险如何应对。

　　二、测试用例设计能力

　　　　提升测试用例设计能力，平时要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，不断总结、概括、触类旁通。

　　三、快速学习能力

　　四、探索性测试思惟

　　五、缺陷分析能力

　　六、自动化测试技术

　　七、良好的沟通能力

测试开发工程师的核心竞争力

　　一、测试系统需求分析能力

　　二、更宽广的知识体系

10——软件测试工程师须要掌握的非测试知识有哪些？

一、网站架构的核心知识

二、容器技术

　　Docker和Kubernetes

三、云计算技术

　　Sauce Labs 测试执行环境公有云服务

　　Appium+Selenium Grid集群 搭建移动终端设备的测试执行私有云

四、DevOps思惟

　　Jenkins

五、前端开发技术

11——互联网产品的测试策略应该如何设计？

　　发布流程一般包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程

传统软件产品的测试策略设计

 互联网产品的测试策略设计

 互联网产品的菱形测试策略（重量级API测试、轻量级GUI测试、轻量级单元测试）

　　一、以中间层的API测试为重点作全面的测试。

　　二、轻量级的GUI测试，只覆盖最核心直接影响主营业务流程的E2E场景。

　　三、最上层的GUI测试一般利用探索式测试思惟，以人工测试的方式发现尽量多的潜在问题。

　　四、单元测试采用“分而治之”的思想，只对那些相对稳定而且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会作少许的单元测试。