第九周咱们讲一些软件工程领域常见的概念吧！
Code walkthrough（代码走查）和Code Review（代码审查）
Code walkthrough（代码走查）和Code Review（代码审查）都属于静态代码分析，即在代码执行前对其进行分析的方法。它们都是软件开发过程中的重要质量保证措施。让我们详细了解一下它们的区别和特点：
Code walkthrough (代码走查)
- 定义：代码走查是一种非正式的代码审查过程，通常是由代码的作者来主导，他会向一个或多个同事解释代码的功能、结构和实现逻辑。
- 目的：主要是为了教育和知识传递，确保团队成员对代码的理解是一致的，同时也能找到潜在的问题。
- 过程：通常是线下进行，如在会议室用投影仪展示代码或在开发者的工作站前进行。
- 反馈：由于它是非正式的，所以反馈通常是即时的，与参与者之间的互动密切。
Code Review (代码审查)
- 定义：代码审查是一种更正式的过程，其中一位或多位开发者独立地审查某个开发者的代码，查找错误或改进点。
- 目的：主要是为了确保代码的质量、可维护性和与团队的编码标准的一致性。
- 过程：通常使用工具（如GitHub的Pull Request、GitLab的Merge Request等）在线进行。审查者独立地查看代码并提供反馈。
- 反馈：反馈是文档化的，可以是评论、建议或请求更改的形式，需要作者对其进行响应。
两者的区别：
- 形式上，代码走查是非正式的，主要侧重于知识传递和代码逻辑的解释；而代码审查是正式的，更注重代码质量和标准的执行。
- 交互性上，代码走查是即时和互动的；代码审查可能不是实时的，并且反馈是文档化的。
找到的软件缺陷越多，背后存在的缺陷更多？
这句话的真实性依赖于多个因素。这个观点基于以下假设：
质量指标：如果在初步测试或代码审查中发现了大量缺陷，这可能意味着代码的质量较低，因此还可能存在更多未被发现的缺陷。
表面与深度的关系：初步发现的缺陷可能只是“冰山一角”。如果在表面（即初步测试）上就存在明显的问题，那么在深入检查时可能会发现更多的问题。
开发和测试的质量：如果开发阶段缺乏充分的代码审查或单元测试，可能会导致更多的缺陷进入后续阶段。
然而，这并不总是成立的：
高缺陷发现率：在某些情况下，高缺陷发现率可能是因为测试团队非常出色，而不是因为代码本身有太多的问题。
高质量的开发过程：在某些高质量的开发流程中，初步的高缺陷发现率可能是因为开发团队已经找到并修复了大部分问题，而剩下的问题是难以发现的边缘案例。
测试阶段和覆盖率：缺陷发现的阶段和测试的覆盖率也很重要。例如，如果在集成测试或系统测试阶段仍然发现大量基本功能相关的缺陷，那么这确实可能意味着还有更多的隐藏问题。
结论：虽然“找到的软件缺陷越多，背后存在的缺陷更多”是一个合理的启发式方法，但我们不能单纯地依赖这个观点。软件质量的评估需要综合考虑多个因素，包括开发和测试的过程、缺陷的类型和严重性以及测试的深度和覆盖率。但其实，对于像作者这样刚入门学习的学生来说，保持这种观点还是比较谦逊的。
软件众测平台
软件众测平台是一种利用众包方式进行软件测试的平台。这种平台通常聚集了大量的测试人员，允许开发者或公司发布自己的软件或应用，然后由这群测试人员进行真实环境下的测试。众测平台的主要优势是能够在多种设备、操作系统和使用场景下对软件进行全面的测试，帮助开发者快速发现和修复潜在的问题。
以下是软件众测平台的一些特点和优势：
多样性：由于参与众测的人员使用的设备、操作系统、网络环境、地理位置等都有所不同，这使得软件能够在各种真实的环境中被测试。
成本效益：与传统的软件测试相比，众测通常更加经济高效。开发者只需要为发现的有效缺陷支付奖励，而不需要雇佣全职的测试团队。
快速反馈：众测平台上的测试人员数量众多，这意味着开发者可以在短时间内收到大量的反馈。
真实使用场景：众测人员可能会在真实的使用场景中测试软件，这有助于发现传统测试方法可能忽略的问题。
全球范围：对于希望在全球推出产品的公司，众测提供了一种在不同国家和地区进行测试的方式，帮助开发者理解不同地域用户的需求和问题。
然而，软件众测也有其限制和挑战：
难以管理：与传统的测试团队相比，众测人员更难管理和协调。
质量不一：虽然有些众测人员非常专业和有经验，但也有些人可能仅仅是为了奖励而参与测试。
隐私和安全性：将未发布的软件暴露给大量外部测试人员可能存在隐私和安全风险。
难以复制缺陷：有时候，众测人员发现的问题可能难以复制，这可能使得问题的定位和修复变得复杂。
不同的众测平台可能提供不同的服务和特点，例如专注于移动应用的测试、游戏测试或网站测试等。如果公司或开发者希望利用众测平台，建议详细研究和比较不同的平台，以选择最适合自己需求的平台。
