# 引言

拥有一台自己的Linux云服务器 的价值：
1. 随时随地，通过xshell工具，连上自己的服务器玩耍。
2. 随时随地，练习Linux命令。
3. 可以部署自己的个人博客系统。
4. 可以部署各种自己想体验的系统，比如 zentao/testlink/redis/mysql/Jmeter /Jenkins/Git等。



# 国内云服务器

国内，云服务器厂商很多，比如：阿里云、腾讯云、华为云、UCLOUD 等。
但考虑  1）稳定性，2）市场占用率，3）客服响应速度等，推荐阿里云。

重点是：从价格对比来看，几家云厂商差不多，甚至阿里云更便宜点。

阿里云，针对新用户，常年都有各种不同的优惠，[点击购买](https://www.aliyun.com/minisite/goods) （个人学习，购买最低配就行；年费只需100多点、甚至经常有活动不到100，以点开看到的最新为准）

![image.png](https://resource.isxiao.top/isxiao-blog/2023/04/e36621a7c256f9b8e4774ea3a32ee699.webp)

记住：去掉所有的加购项目，选ECS即可（不确定买哪款的，可微信 254814842 找我咨询）

另外，阿里云也提供免费试用三个月：[免费试用](https://free.aliyun.com/?crowd=personal&spm=5176.28117011.J_9980031080.1.7d216817MlVlyA)

![image.png](https://resource.isxiao.top/isxiao-blog/2023/04/3c8dc0b98ad7335bf6aaccbc7421c914.webp)

# 海外云服务器
以下是几个可靠的海外云服务器提供商，指定机型可以白用一年，详情可以百度：

- Amazon Web Services (AWS)：亚马逊AWS是全球领先的云计算服务提供商之一

- Microsoft Azure：Azure是微软推出的云计算平台，提供全面的云计算服务

- Google Cloud Platform (GCP)：GCP是谷歌推出的云计算平台，提供全面的云计算服务

- Vultr：Vultr是一家提供高性能云服务器的云计算提供商，提供全球多个数据中心的服务，包括计算、存储、数据库、网络和安全等方面

- RackNerd：RackNerd是一家新近成立的美国VPS和独立服务器提供商，提供24/7的客户支持和监控服务，以确保用户的服务和数据安全

本网站部署的服务器是RackNerd（[直接购买](https://my.racknerd.com/aff.php?aff=7835&pid=681)），目前价格20.98USD/year，支持支付宝购买

# 备注
1. 选ECS即可（RDS、OSS等别买，个人学习无需），在ECS安装一个mysql即可
2. 其他需要另外费用的，一律不勾选（个人学习，那些都没用）
3. 云服务器地域、带宽等，都可以选默认
4. 操作系统，选Centos 7.x

如何选择一台适合日常学习的Linux云服务器

# 软件测试基础

软件测试是软件开发生命周期（SDLC）中的一步关键过程，用于确保软件产品的质量和可靠性。它涉及对软件系统或组件的评估，以识别缺陷或错误，并验证其是否符合指定的要求。有效的软件测试有助于识别和修复软件缺陷，提高软件质量，并增强用户满意度。



## 软件测试的重要性

软件测试之所以重要，原因如下：

- **缺陷检测**：软件测试帮助识别软件系统中的缺陷或错误，确保其在发布给最终用户之前及时发现并修复潜在问题。

- **质量保证**：软件测试确保软件满足指定的要求，并按预期执行。它有助于验证软件的功能、性能、可靠性和安全性，从而确保高质量和可靠性。

- **风险缓解**：软件测试有助于缓解与软件故障或缺陷相关的风险。它最小化了由于软件缺陷可能导致的财务损失、声誉损害和法律责任的风险。

- **客户满意度**：有效的软件测试确保软件满足最终用户的需求和期望，从而提高用户满意度。它有助于识别和修复可能影响用户体验的问题，从而改善用户满意度。

## 软件测试的关键概念

在软件测试中，有几个关键概念构成了有效的软件测试的基础：

### 测试层次

软件测试可以在不同的层次上进行，包括：

- **单元测试**：测试单个代码单元，以确保其功能和正确性。

- **集成测试**：测试软件不同组件或模块的集成，以确保其正确的交互和整体功能。

- **系统测试**：测试整个软件系统，以确保其功能、性能和与目标环境的兼容性。

- **验收测试**：测试软件以确保其符合指定要求，并已准备好由最终用户接受。

### 测试分类
软件测试方法可以根据不同的分类方式进行分类。以下是一些常见的分类方法：

#### 按照测试目的分类：
- **功能测试（Functional Testing）**：验证软件的功能是否符合需求和规格，包括单元测试、集成测试、系统测试、验收测试等。

- **性能测试（Performance Testing）**：验证软件在不同负载条件下的性能表现，包括性能测试、负载测试、压力测试等。 

- **安全测试（Security Testing）**：验证软件的安全性，包括安全漏洞测试、授权测试、认证测试等。 

- **兼容性测试（Compatibility Testing）**：验证软件在不同环境和平台下的兼容性，包括浏览器兼容性、操作系统兼容性、设备兼容性等。 

- **可靠性测试（Reliability Testing）**：验证软件的可靠性和稳定性，包括容错测试、恢复性测试、稳定性测试等。

#### 按照测试方法分类：
- **黑盒测试（Black Box Testing）**：测试人员不了解软件内部结构和实现，只关注软件的输入和输出，验证软件的功能和行为。

- **白盒测试（White Box Testing）**：测试人员了解软件的内部结构和实现，对软件的代码进行测试，验证软件的内部逻辑和处理过程。

- **灰盒测试（Grey Box Testing）**：介于黑盒测试和白盒测试之间，既关注软件的输入和输出，也了解软件的内部结构和实现，综合进行测试。

#### 按照测试阶段分类：

- **单元测试（Unit Testing）**：对软件的最小单元（如函数、类、模块等）进行测试，通常由开发人员自行进行。

- **集成测试（Integration Testing）**：将多个单元或模块组合起来，测试它们之间的交互和集成是否正常。

- **系统测试（System Testing）**：测试整个系统的功能和性能是否符合需求和规格。

- **验收测试（Acceptance Testing）**：由用户或客户进行的测试，验证软件是否满足用户需求和规格要求。

#### 按照测试手段分类：

- **自动化测试（Automated Testing）**：使用测试工具和脚本来执行测试任务，提高测试效率和准确性。

- **手动测试（Manual Testing）**：通过人工操作来执行测试任务，灵活性高但测试效率较低。

这些分类方法可以根据具体的项目需求、测试目标和资源限制来选择合适的测试方法和技术，以确保软件的质量和稳定性。不同的测试方法可以相互补充，综合应用可以提高测试的全面性和深度，从而更好地发挥软件测试的作用。在实际项目中，通常会根据测试目标、测试资源、项目进度等因素，选择不同的测试方法或将多种测试方法进行组合使用，以达到最佳的测试效果。

### 软件测试的步骤

软件测试通常包括以下步骤：

- **测试计划**：制定测试计划，包括测试目标、测试资源、测试进度和测试策略。

- **测试设计**：根据需求和规格，设计测试用例和测试数据，覆盖不同的功能和情况。

- **测试执行**：执行测试用例，记录测试结果，包括缺陷和错误。

- **缺陷管理**：对于发现的缺陷和错误，进行记录、分类、跟踪和解决。

- **测试报告**：生成测试报告，包括测试结果、缺陷统计和测试总结。

- **测试验证**：验证修复后的缺陷，确保软件符合指定的要求和标准。

### 软件测试的最佳实践

以下是软件测试的一些最佳实践：

- **早期测试**：尽早开始测试，包括在软件开发生命周期的不同阶段进行不同层次和类型的测试。

- **全面测试**：覆盖不同的功能和情况，包括正常和异常情况的测试。

- **合适的测试环境**：创建合适的测试环境，包括硬件、软件和网络配置，以模拟实际使用环境。

- **测试用例和测试数据管理**：设计和管理有效的测试用例和测试数据，确保全面和高效的测试覆盖。

- **缺陷管理**：有效地记录、分类、跟踪和解决发现的缺陷和错误。

- **自动化测试**：使用自动化工具和脚本执行测试，提高测试效率和准确性，尤其对于重复性较高的测试任务。

- **团队合作**：测试团队和开发团队之间的紧密合作，包括对需求的理解和交流，以确保软件的质量。

- **版本控制**：使用版本控制系统管理测试代码和测试数据，确保版本的一致性和可追溯性。

- **持续集成**：将测试集成到持续集成和持续交付流程中，确保在每次代码变更后进行自动化测试。

- **性能测试**：对于涉及大量数据和用户的软件，进行性能测试，以确保其在高负载和高并发情况下的稳定性和性能。

- **安全测试**：对于涉及敏感信息和数据的软件，进行安全测试，以发现潜在的安全漏洞和风险。

## 结论

软件测试是确保软件质量和可靠性的重要步骤。通过不同层次和类型的测试，可以发现并修复软件中的缺陷和错误，从而提高软件的稳定性、性能和安全性。采用软件测试的最佳实践，如早期测试、全面测试、合适的测试环境、测试用例和测试数据管理、缺陷管理、自动化测试、团队合作、版本控制、持续集成、性能测试和安全测试，可以有效地提升软件的质量和可靠性。

希望本文对您了解软件测试的基础知识和最佳实践有所帮助。在实际软件开发过程中，合理应用软件测试，将有助于提高软件的质量和用户满意度。

软件测试理论基础

# 引言

随着AIGC的发展，越来越多的公司在推出自己的智能产品/应用，随着Chat公司的一系列封号动作，转向其他平台/产品的越来越多。本文旨在普及如何使用Claude。



# 第一步，注册登录 Slack 工作空间

注册登录你的Slack工作空间，超级简单注册。

- 打开浏览器，访问slack.com网站

![注册登录Slack](https://resource.isxiao.top/isxiao-blog/2023/05/0ac7306a1f5066cc16e1da5e7a0424da.png)

推荐使用outlook邮箱注册，也就是点图中的圈2。

- 输入验证码

![验证码](https://resource.isxiao.top/isxiao-blog/2023/05/d9769cda11778ab74155005838a6cfb4.png)

- 创建工作空间

![空间名称](https://resource.isxiao.top/isxiao-blog/2023/05/f30b37b6759b5cdd7432f02ff8046777.png)

![邀请可跳过](https://resource.isxiao.top/isxiao-blog/2023/05/b74bae3a4a299ffd73e9fd6b61b767c4.png)

![随意输入](https://resource.isxiao.top/isxiao-blog/2023/05/48f15121b19b40135162fa929b3283e0.png)


# 第二步, 将Claude添加到 Slack

打开Anthropic的网站，点击“添加到Slack”按钮。Claude会要求你授予一些权限来读取消息与回复信息，授权即可

- 添加到Slack

![add to slack](https://resource.isxiao.top/isxiao-blog/2023/05/0dd6abb5fe7420ea1a2db9081c4c8645.png)

- 允许权限
![](https://resource.isxiao.top/isxiao-blog/2023/05/4877d271ce953c0ec2e7f12e84be3348.png)

# 第三步， 使用Claude

如下：Claude Bot已经成功添加到你的Slack工作空间啦!你可以在Slack上直接@Claude来询问问题或要求帮助。Claude会自动回答你或提供信息概览。

- 对话之前，可以先设置一下头像等属性

![](https://resource.isxiao.top/isxiao-blog/2023/05/af636bad86200edde6694075b8ce5c91.png)

- 开启与Claude的对话

![](https://resource.isxiao.top/isxiao-blog/2023/05/86c3154831b2ed9490b81740c9c5f348.png)

让Claude成为你的职场小助手，只要三步!

# 测试金字塔模型
本文基于网络素材收集和整理，如有侵权，请及时告知！

自动化测试金字塔最早是由Mike Cohn在2009年的著作《Succeeding with Agile: Software Development using Scrum 》（《Scrum敏捷软件开发》）中提出。最早提出来的是一个三层金字塔，从上到下分别是UI界面/Service测试/单元测试。



这里的单元测试和UI测试相信没有任何疑问，而Service测试，可以理解成「集成测试」，实际指的是：API「应用程序接口」、微服务、数据库等测试。

![](https://resource.isxiao.top/isxiao-blog/2023/05/620c2733d90cac1eda563ec90a381a61.png)

这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例，越接近底层的单元测试建议的投入最多，接口测试居中，界面层建议的投入最少。

Martin Fowler关于测试金字塔有这样一段评论：“GUI测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。你可以放弃录制的方法来解决这个问题，通过写GUI测试代码，但是这样效率非常低。就算你已经很精通了GUI测试代码的编写，GUI测试用例也很容易出现不可预期结果的问题，因此，基于GUI的自动化测试是脆弱、耗时（包括用例维护和执行）的。

所以测试金字塔要表达的是：底层应当有更多的单元测试和接口测试和逻辑测试，GUI测试用例能覆盖到主业务流程即可。”

从测试效果上看，接口测试和UI/单元测试相比，有很多优势。 对于单元测试来说，通常单元测试是针对代码进行的测试，而接口测试是在测试一个动态系统。更重要的是，很多情况下，绝大部分通过UI完成的业务操作完全可以通过API端完成。


- 层次越靠上，运行效率越低，延缓持续集成的构建-反馈循环。
- 层次越靠上，开发复杂度越高，如果团队能力受限，交付进度受影响。
- 端到端测试更容易遇到测试结果的不确定性。
- 层次越靠下，单元隔离性越强，定位分析问题越容易。

# 金字塔反模式

原则上单元测试需要开发人员承担，很多团队中开发人手不足，优先保障功能的实现，在单元测试的投入不够，并且很多开发人员的单元测试经验不足，导致很多团队中不做单元测试或者被动执行流于形式，有人提出了金字塔结构的反模式：蛋筒冰激凌模式、纸杯蛋糕模式、沙漏模式。

## 蛋筒冰激凌模式
蛋筒冰激凌模式由Alister Scott在2012年提出，金字塔中界面测试和单元测试的比例倒置形成倒金字塔，界面测试之上有大量的手工测试。

反模式不是建议模式，但却是实际团队中大量存在的。

![](https://resource.isxiao.top/isxiao-blog/2023/05/333e6e0d22310fe0b9fac557efbb50a0.png)

团队初期没有自动化测试，完全依赖手工测试，然后结合业务模式，从界面功能测试自动化入手，产生了一些界面自动化测试用例。这种由外向内进行自动化测试的建设方式，导致了这样的反模式。

这样的模式在测试效率、测试用例可维护性角度讲，均存在一些问题，但又往往是很多团队自发进行测试自动化能力建设过程中的必经路径，问题积累到一定阶段需要逐步向测试金字塔方向演进。

## 纸杯蛋糕模式
ThoughtWorks 公司的博客上，介绍了「纸杯蛋糕反模式」。
![](https://resource.isxiao.top/isxiao-blog/2023/05/0ba62b921afaf2eb2b53738447ef10be.png)

不同的团队编写不同层级的自动化测试，开发人员正在编写单元、集成和组件测试，而自动化测试工程师正在将手动回归测试转换为「E2E」自动化测试。还有另外一个团队手工执行测试用例。 

这可能导致所有团队都在重复测试。，虽然更多的测试没有带来什么伤害，但它一定是低效的。团队将无法专注于更复杂的测试问题，因为每个人总是有很多事情要做。


## 沙漏模式
沙漏反模式来自于KHUSHI，写于2019年的一篇博客。
![](https://resource.isxiao.top/isxiao-blog/2023/05/511967246c55a7af6a92039b5ac46d5c.png)

在这种反模式下，开发团队正在编写单元测试，并且 QA 团队正在编写 UI 测试。 没有人编写服务/中间层测试。 尽管这种反模式比「蛋筒冰激凌模式」好得多，但仍旧不如「测试金字塔」。


# 问题
1. 你的团队陷入了哪种反模式，以及你正在做什么实践，以帮助你的团队迈向测试金字塔？
2. 应该做哪些实践，以解决纸杯蛋糕模式中的重复测试？

测试金字塔及反模式

# 1. 软件测试过程中，给开发的冒烟用例，开发经常未执行完全，或拒不执行，怎么处理？
  参考：这种情况，大部分是流程不规范造成，测试团队可以考虑以下几种方法来解决：
  - 首先检查准入流程是否存在：如果你是组员，反馈给你的leader，让他推动准入流程运作起来。如果你是leader，需要与开发经理、项目经理等沟通，强调冒烟测试的重要性，把L0、L1级别用例作为冒烟用例提供给开发，并纳入开发提测前的验收标准中，制定流程并落地
  - 与开发人员沟通：除提供冒烟用例外，需要与开发人员沟通了解，用例执行是否存在问题，赋能开发人员等
  - 自动化测试：测试团队有开发资源，则可以将冒烟用例纳入自动化测试计划，编写测试脚本来执行这些用例，并将它们添加到CI/CD 流程中
  - 持续优化：每个迭代周期结束，测试团队可以评估本次测试结果，及冒烟用例执行情况，以便持续优化测试流程和测试用例



# 2. 假如你是测试组长，估算测试时间时，项目经理和管理层总是想压缩测试时间，但这样一来，新需求来不及熟悉需求，测试分析和测试用例准备比较匆忙。这种情况你如何处理？
  参考：作为测试组长，我首先会与项目经理、管理层进行沟通，强调测试的必要性以及测试流程，并解释清楚测试不仅仅是为了发现缺陷，也是为了保证产品的质量和用户体验，以及减少后期维护成本。同时，我也会与各开发团队负责人沟通，尽可能提前了解新需求并进行需求测试分析，确保测试工作能够顺利进行。
  
  如果时间仍然很紧张，我会考虑采用一些测试策略来尽可能缩短测试时间，例如：
  - 优先测试风险较高的功能或模块，确保至少覆盖了重要的测试点
  - 并行测试，可以考虑将测试需求拆分成多个部分（如前后端分别介入）并行测试，以缩短测试时间
  - 优化测试计划和测试用例，去除冗余的测试点，采用脑图或其他可视化工具输出测试用例
  - 自动化测试，利用自动化测试工具测试，提高测试效率和准确度

# 3. 新入职一家公司，只有我一个测试，什么流程都没有，完全不知道如何开始工作，怎么办？
  参考：一般建议多与老大沟通，避免期望不一致，下面给出一些具体建议：
  - 做好心理准备：一般这类公司，测试可有可无，给你一个软件包，可能连需求都不清楚在哪
  - 与直接领导面对面沟通：确定你的职责和定位，了解测试的具体目标及重点测试范围，以便开展测试工作
  - 落地简易测试流程：了解当前研发流程，整理一套可落地的测试流程，不用太复杂，多方达成一致即可，以便提高测试覆盖率等
  - 主动学习业务和测试技能：深入业务&融入团队，了解技术架构，结合测试技能，提升测试效率和质量
 
# 4. 对于一些难以复现的bug，该如何处理？
  参考：处理难以复现的 bug，下面是一些可能有用的建议：
  - 确认该 bug 是否真的存在：首先要确定这个 bug 是否确实存在。有时候测试人员可能会将某些情况误解为 bug，因此需要仔细地检查和确认
  - 收集更多信息：如果确认属于 bug，则需要重现步骤，并尝试收集更多相关信息，例如错误消息、日志文件等。这些信息可能有助于帮助开发人员定位问题
  - 分析代码：如果重现步骤相同，但仍然无法复现 bug，则可能需要进一步分析代码并调试以找出问题所在。这可能需要与其他开发人员合作，或者可能需要使用特殊工具进行分析
  - 评估严重等级：与开发、产品等团队成员沟通，评估该 bug 对系统的影响程度。如果这个 bug 是严重的，可能会导致系统崩溃或数据丢失，那么最好是不要发布版本，直到问题被解决
  - 记录问题：缺陷管理系统，详细描述问题现象、操作步骤、缺陷截图、问题出现时的日志等
  - 暂时忽略：多方评估后，认为问题等级低，且对用户影响不大，可以发版，但后续迭代版本，要继续尝试复现或进行多轮验证，一般连续两轮迭代，未复现问题，建议更新问题状态为“推迟解决”或“未复现关闭”
  
  总之，在软件测试中遇到难以复现的 bug 时，应尽可能多地收集信息并与团队成员一起分析问题。在决定是否发布版本之前，应该评估问题的严重等级等
  
# 5. 测试执行阶段，每天发送测试进展，不知道写什么内容？具体以什么形式展现？
参考：了解老大关注哪些，比如一般关注测试执行时有哪些风险，提给开发的bug是否有修改风险等。
举个例子：

总体进度：目前测试进度已完成60%，进度正常，暂无风险。
- 继续进行接口测试，共执行了20个测试用例，其中12个通过，8个失败，失败用例已录入缺陷管理系统，并通知开发人员进行修复
- 进行UI测试，测试覆盖率达到80%，已发现3个缺陷，已录入缺陷管理系统
- 进行版本回归测试，已执行30个测试用例，全部通过，未发现新的缺陷
- 上个版本迭代遗留3个问题已全部验证通过，下个版本继续跟进


# 6. 软件测试发现缺陷需要修复，但修复缺陷的开发并不靠谱，修复不完整，漏修复，Bug多，做事拖拉，怎么办？
  参考：作为一名软件测试职场人，怎么可能不会遇到几个不靠谱的开发呢，建议可以采取以下措施来应对开发人员不靠谱的问题：
- 充分记录缺陷：在发现缺陷时，要充分记录并详细描述缺陷，包括重现步骤、影响范围、优先级等信息，并将其及时汇报给开发人员
- 强化沟通：与开发人员建立良好的沟通渠道，及时反馈缺陷信息，了解开发人员修复缺陷的进度和问题，与开发人员一起讨论解决缺陷，并制定解决方案
- 搭建测试流程：建立明确的研发测试流程，包括测试计划、测试用例、测试执行、缺陷跟踪、提测等环节，确保测试过程的规范和完整性，以便开发人员更清楚地了解缺陷的情况
- 建立质量标准：建立严格的质量标准，包括代码规范、测试标准、文档规范等，确保开发人员遵循研发规范，从而减少缺陷的数量和出现率
- 建立奖惩机制：与直接领导、开发经理及项目经理反馈，并建议建立细化的奖惩机制，对开发人员的工作进行评估和考核，对表现优异的开发人员给予奖励，对表现不佳的开发人员进行惩罚，从而激励开发人员改进工作质量
- 寻求领导支持：寻求领导的支持，与领导沟通，向领导汇报缺陷修复的情况，提出建议和改进措施，争取领导的支持和资源，以帮助解决开发人员不靠谱的问题

# 7. 如何通过面试来了解自己的直属领导做事风格和测试团队氛围？
  在面试过程中，可以通过以下几个方面来观察和提问，以了解面试你的测试领导的做事风格： 
- 询问自己的第一印象：面试交流过程中，总结一下自己的感觉，你是否喜欢这种交流沟通方式，交流过程是否愉快，如果回答是否定的，基本不用考虑了，大概率进去后马上撤退
- 问一下测试部门规划：询问公司或部门的主要业务，以及领导对团队发展的看法和计划。这可以帮助你了解领导是否关注公司或部门的长期发展，并且是否有能力和愿望支持团队的成长
- 问一下公司/部门测试流程和方法：询问关于测试流程和方法的看法和经验，以了解他们是否有系统的测试流程和方法，通过对比领导的答案和你对测试流程和方法的理解，来了解领导的专业能力和水平
- 问一下测试工作内容：除业务测试外，团队是否有用到一些测试工具，团队是否会涉及测试开发或自动化测试的工作内容等
总之，在面试过程中，反问环节是非常重要的，可以帮助你了解领导的做事风格和团队氛围，进而做出是否加入这个团队的决策。

# 8. 开发提测版本，开发未提及版本改动点，测试不知道如何才能尽可能避免漏测？
参考：
- 与开发加强沟通交流，以获取变更提测点：可以让开发在git commit 中注明改动内容，可以要求提测，邮件附上变更清单，包含每个提交的变更点及其影响范围
- 看git 代码提交记录，有余力和资源的情况下，可以使用现成的工具去针对性的比对
- 新需求用例完全覆盖，继承核心功能要回归测试