软件测试-测试基础知识篇

00 合格的测试工程师-优秀的测试工程师-测试架构师

每个阶段需要做什么，定目标，然后去执行。目前我的目标就是成为一个合格的测试工程师。

01小小的登录功能

涉及到的测试用例真的不少，除了用测试方法设计的，还有很多很多需要补充。
1.显示功能性需求：
测试方法设计的+经验
2.非功能性需求-安全性，性能，兼容性 决定软件质量的关键因素

A:用这些测试点，对找个网站对登录功能进行测试。

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

好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
“好的”测试用例必须具备哪些特征？
整体完备性
等价类划分的准确性
等价类集合的完备性
（这只是说一般的考虑功能性需求的方法吧，其他的用这个也判定不出来）
对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。

如何设计出好的测试用例？
面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
具体到测试用例本身的设计，有两个关键点需要你注意。
【1】从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
【2】对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。

用例设计的其他经验除了上面介绍的方法外，我再跟你分享三个独家“秘籍”，希望能够帮你设计出“好的”测试用例集。
【1】只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，
比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。
【2】必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。单单根据测试需求点设计的用例，只能覆盖“表面”的一层，
往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。
【3】在具体实践中，你可以通过代码覆盖率指标找出可能的测试遗漏点。
同时，切忌不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用例。
需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。 关于什么是需求覆盖率和代码覆盖率，
我会在后续的文章中详细介绍。

03 | 什么是单元测试？如何做好单元测试？

单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。
单元测试通常由开发工程师完成。
单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。问题是如何测？

04 | 为什么要做自动化测试？什么样的项目适合做自动化测试？

什么样的项目适合自动化测试？
第一，需求稳定，不会频繁变更。
第二，研发和维护周期长，需要频繁执行回归测试。1. 在我看来，软件产品比软件项目更适合做自动化测试。
对于一些中长期项目，我的建议是：对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试，
最终目标是用 20% 的精力去覆盖 80% 的回归测试。
第四，某些测试项目通过手工测试无法实现，或者手工成本太高。-性能和压力测试

以缺陷数量来衡量测试的绩效是不可取的，而且还会激化测试和开发之间的矛盾。

05 | 你知道软件开发各阶段都有哪些自动化测试技术吗？

【单元测试】：
【代码级集成测试】：关注点，更多的是软件模块之间的接口调用和数据传递。
（上面这两个级别的自动化测试现在对我来说就是盲区）

【Web Service 测试】：Web Service 测试，主要是指 SOAP API 和 REST API 这两类 API 测试，最典型的是采用 SoapUI 或 Postman 等类似的工具。
但这类测试工具基本都是界面操作手动发起 Request 并验证 Response，所以难以和 CI/CD 集成，于是就出现了 API 自动化测试框架。
（soap API和rest API是 什么意思？）
我发现这个课讲得都是些上层思想，而不是实操。

【GUI 测试阶段的自动化技术】：两大方向，传统 Web 浏览器和移动端原生应用（Native App）的 GUI 自动化
于传统 Web 浏览器的 GUI 自动化测试，业内主流的开源方案采用 Selenium
对于移动端原生应用，通常采用主流的 Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso。
测试脚手架是什么？
自动化测试是为了提高测试效率，节约成本。解放重复劳动。所以在工作的任意阶段，只要符合这些要求，都可以用自动化来做。
我们采用robot framework+requestslibrary的方式来做API自动化测试。个人觉得比较适合团队编程能力不是太强的团队。
目前公司用的是jmeter接口自动化初级阶段，想要更进阶的，跟着进步学习中（我也要学习下Jmeter做接口自动化）

06 | 你真的懂测试覆盖率吗？

测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。
通常采用 ALM，Doors 和 TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率。（我几个我都没用过）
（三种代码覆盖率，可是还是觉得很虚，怎么计算出来呢？）
在软件企业中，只有单元测试阶段对代码覆盖率有较高的要求。因为从技术实现上讲，单元测试可以最大化地利用打桩技术来提高覆盖率。
代码覆盖率工具：JaCoCo 是一款 Java 代码的主流开源覆盖率工具

A：了解下c,C++,Java对应的代码覆盖率工具，以及如何使用？

07 | 如何高效填写软件缺陷报告？

好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。
缺陷标题：通常采用“在什么情况下发生了什么问题”的模式。标题应该尽可能描述问题本质，而避免只停留在问题的表面。
缺陷描述：晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。
缺陷影响：缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity）
环境配置：环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息
前置条件：前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述
缺陷重现步骤：
期望结果和实际结果：
优先级和严重程度：缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
根原因分析：提高修复效率，开发认可测试技术
（做为测试工程师，你很有必要去深入学习一门高级语言，这将帮助你体系化地建立起编程思想和方法，这样在之后的工作中，无论你是面对开发的代码，还是自动化测试代码和脚本都能做到得心应手，应对自如）
（继续学习Python和Java）
附件（Attachment）
（系统，模块，人天，应该明确让IT写出每个bug修复方法， 测试可以积累经验，也方便下次出现类似问题解决）

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

一份好的测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一部分都要给出应对可能出现问题的解决办法。
测试范围描述的是被测对象以及主要的测试内容。测试范围中需要明确“测什么”和“不测什么”。 功能需求/非功能需求
测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题。功能、兼容性、性能
测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。测试人员、任务分配、测试环境
测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。
测试风险评估：通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因。
（我还没有写过测试计划，以后一定要写）

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

必须要深入理解业务，但是业务知识不能等同于测试能力。

测试开发岗位的核心其实是“测试”，“开发”的目的是更好地服务于测试，我们看重的是对测试的理解，以及在此基础上设计、
开发帮助测试人员提高效率并解决实际问题的工具，而不是一个按部就班、纯粹意义上的开发人员。

测试工程师要具备的七项核心竞争力，包括：测试策略设计能力、测试用例设计能力、快速学习能力、探索性测试思维、缺陷分析能力、
自动化测试技术和良好的沟通能力。

你可以有针对性地提升自己某方面的能力，去获取更大发展空间的“敲门砖”。

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

网站架构、容器技术、云计算技术、DevOps 思维，以及前端开发技术的核心知识以及实践。

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

传统软件产品的测试策略设计 金字塔模型 unit test-API test–GUI test
对于互联网产品来说，迈克的金字塔模型已经不再适用。
互联网产品的测试策略设计
第一，GUI 测试
互联网产品的 GUI 测试通常采用“手工为主，自动化为辅”的测试策略，手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，
而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。所以，GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景。
第二，API 测试
对于互联网产品来说，把测试重点放在 API 测试上，才是最明智的选择
互联网产品的测试策略更像是个菱形结构的原因。遵循“重量级 API 测试，轻量级 GUI 测试，轻量级单元测试”的原则。

传统软件通常采用金字塔模型的测试策略，而现今的互联网产品往往采用菱形模型。菱形模型有以下四个关键点：
以中间层的 API 测试为重点做全面的测试。
轻量级的 GUI 测试，只覆盖最核心直接影响主营业务流程的 E2E 场景。
最上层的 GUI 测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。

本文地址：https://blog.csdn.net/seanyang_/article/details/107312034