测试 笔记

 1.谈一谈你对测试的理解？​​

1. 我认为测试不仅仅是找出错误，而且还包括验证软件的功能、性能、可靠性以及用户体验等方面，发现其中的问题并及时解决。
2. 测试可以提前发现和修复缺陷，能减少未来的维护成本，对于保障软件的质量和提升用户满意度十分重要。
3. 我了解多种测试方法，比如功能测试、性能测试、安全测试等，知道多种测试工具的使用。

​​

2. 测试开发需要哪些知识？​​

1. ​​编程技能​​：测试人员需要掌握至少一种编程语言，如 Java、Python，能够编写自动化测试脚本和工具。
2. ​​测试基本知识​​：理解不同类型的测试（单元测试、集成测试、系统测试、验收测试），掌握黑盒测试和白盒测试的原理和适用场景。
3. ​​测试需求分析​​：能够设计有效的测试用例和测试计划。
4. ​​工具和框架​​：熟悉常用测试工具和框架，例如 Selenium、JMeter、Jenkins 等。

​​3. 讲一下你们的测试流程​​

参与项目和实习中的测试流程通常按照下面这些步骤进行：

1. ​​需求分析​​：测试首先要对软件需求有深入的理解，我们会开需求评审会议，分析和讨论需求。
2. ​​制定测试计划​​：明确测试的范围、方法、资源分配、时间表和目标。
3. ​​测试用例设计​​：基于测试计划，设计详细的测试用例，覆盖所有功能点（包括正常情况和边界情况）。
4. ​​测试用例评审​​：确保用例的完整性和有效性。
5. ​​搭建测试环境 & 执行测试​​：
   • 配置合适的测试环境。
   • 执行测试用例，记录结果并报告缺陷（Bug）。
6. ​​回归测试​​：代码更改后执行回归测试，确保新修改不影响现有功能。
7. ​​性能测试​​：评估系统的响应时间、稳定性和扩展性。
8. ​​预生产环境测试​​：将项目部署到预生产环境（Staging）进行最终验证。
9. ​​编写测试报告​​：总结测试覆盖率、发现的缺陷及未解决的问题。
10. ​​上线复盘​​：项目上线后，根据用户反馈进行总结和优化。

4.黑盒测试（功能测试）​​

​​核心思想​​：
“像用户一样测试”，只关心​​输入与输出​​，不关注内部实现。

​​关键方法​​：

• ​​等价类划分​​：将输入数据分类（有效/无效），每类选代表测试。
• ​​边界值分析​​：测试输入范围的边界（如最小值、最大值）。
• ​​因果图法​​：分析输入条件与输出结果的逻辑关系。
• ​​状态转换测试​​：验证系统在不同状态下的行为。

​​举例​​：
测试游戏时，玩家只关心：

• 点击“开始”按钮能否进入游戏？
• 角色移动是否符合操作预期？
• 无需知道游戏如何渲染画面或处理数据。

​​适用场景​​：
系统测试、验收测试、功能验证。

---

​​5. 白盒测试（结构测试）​​

​​核心思想​​：
“像开发者一样测试”，需了解​​代码内部逻辑​​，验证程序结构。

​​关键方法​​：

• ​​路径覆盖​​：测试代码中的所有执行路径。
• ​​条件覆盖​​：确保每个逻辑条件（如 if 语句）的真/假都被测试。
• ​​循环覆盖​​：验证循环体在边界次数（0次、1次、多次）下的行为。
• ​​语句覆盖​​：确保每行代码至少执行一次。

​​举例​​：
游戏开发者需要检查：

• 角色跳跃功能的代码是否正确处理重力参数？
• 碰撞检测算法是否覆盖所有边界情况？

​​适用场景​​：
单元测试、集成测试、代码逻辑验证。

---

​​对比总结​​

​​维度​​	​​黑盒测试​​	​​白盒测试​​
​​测试视角​​	用户视角（外部行为）	开发者视角（内部逻辑）
​​知识需求​​	无需懂代码	需阅读并理解源代码
​​测试重点​​	功能正确性、用户体验	代码覆盖率、逻辑完整性
​​典型方法​​	等价类、边界值	路径覆盖、条件覆盖
​​适用阶段​​	系统测试、验收测试	单元测试、集成测试

---

​​如何选择？​​

• ​​黑盒测试​​：验证“软件是否做对了事”（功能是否符合需求）。
• ​​白盒测试​​：验证“软件是否正确地做事”（代码是否无缺陷）。

​​实际项目中​​：两者结合使用（如黑盒测功能，白盒测核心模块）。

6.等价类划分​​

等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类划分认为：

• ​​如果一个测试用例在某个等价类中的一个值上通过测试，那么它在这个类中的其他值上也会通过​​。
• 适用于输入数据较多的情况，有助于减少测试用例的数量并保证覆盖率。

​​分类​​：

• ​​有效等价类​​：符合规格说明的输入条件（用于验证系统正确性）。
• ​​无效等价类​​：不符合规格说明的输入条件（用于验证系统健壮性）。

---

​​7. 边界值法​​

软件错误往往发生在输入或输出范围的边缘，因此边界值分析专注于测试输入数据的边界条件，而不是中间值。

​​测试范围​​：

• ​​正常边界值​​：最大值、最小值。
• ​​异常边界值​​：最大值+1、最小值-1。
• 适用于测试对输入数据有明确范围或限制的功能

8. 等价类划分的难点是什么​​

1. ​​正确定义等价类​​

   • 难点在于准确理解需求和规格说明。若需求理解不全面，可能导致等价类定义错误，影响测试覆盖率和有效性。

2. ​​识别有效和无效的等价类​​

   • 需同时识别：
     • 有效等价类（符合规格说明的输入条件）
     • 无效等价类（不符合规格说明的输入条件）

3. ​​处理复杂的输入条件​​

   • 当输入条件复杂或相互依赖时，定义清晰的等价类难度增加。

---

​​9. 接口测试用例的编写需要注意哪些要点​​

1. ​​明确接口规格​​

   • 包括：功能、输入/输出参数、数据格式、请求方法（GET/POST/PUT/DELETE）、预期行为。

2. ​​返回值验证​​

   • 测试正常输入和异常输入下的响应内容是否正确。

3. ​​业务逻辑与功能​​

   • 验证接口是否按业务需求正确处理逻辑。

4. ​​数据库校验​​

   • 检查接口操作是否准确更新数据库（如插入、修改、删除数据）。

5. ​​性能测试​​

   • 关注接口TPS（每秒事务数）、响应时间等指标。

6. ​​安全性​​

   • 敏感信息加密、权限控制（如未授权访问拦截）。

10.性能测试关键指标​​

1. ​​TPS（每秒事务数）​​

   • ​​定义​​：系统每秒能成功处理的事务数量（如订单提交、API调用）。
   • ​​意义​​：直接反映系统吞吐量，TPS越高性能越强。
   • ​​示例​​：电商大促时，系统需支持10,000 TPS才能避免崩溃。

2. ​​平均响应时间​​

   • ​​定义​​：从发送请求到接收响应所需的平均时间（单位：毫秒）。
   • ​​意义​​：影响用户体验，时间越短体验越好。
   • ​​示例​​：用户登录接口响应时间应≤500ms。

3. ​​并发数​​

   • ​​定义​​：同时向服务器发起请求的虚拟用户数（通过进程/线程模拟）。
   • ​​意义​​：测试系统在高负载下的稳定性。
   • ​​示例​​：1,000并发用户测试时，系统需保持TPS不骤降。

4. ​​错误率​​

   • ​​定义​​：失败请求数占总请求数的百分比（如HTTP 5xx错误）。
   • ​​意义​​：超过阈值（如1%）可能表明系统存在瓶颈。
   • ​​示例​​：错误率突增至5%时，需检查数据库连接池或代码异常

11.功能测​试用例一般包含哪些内容​

1. ​​测试用例ID​​：一个唯一标识符，用于区分和引用测试用例。
2. ​​测试用例标题​​：简短描述测试用例的目的或主要功能。
3. ​​功能模块​​：指明此测试用例所属的软件功能模块或部分。
4. ​​测试目的/描述​​：对测试用例的目标和测试内容的详细描述。
5. ​​前置条件​​：执行测试用例之前需要满足的条件，如特定的系统状态或配置。
6. ​​测试步骤​​：详细描述如何执行测试，包括用户如何与系统交互，每一步应该输入什么数据，选择哪些选项等。
7. ​​测试数据​​：在测试中使用的具体数据，包括输入值和需要验证的输出值。
8. ​​预期结果​​：描述在成功执行测试步骤后预期的系统行为或输出。
9. ​​实际结果​​：在执行测试后记录的实际结果，用于与预期结果进行比较。
10. ​​通过/失败标准​​：定义何种条件下测试用例被认为是通过或失败。
11. ​​测试环境​​：描述执行测试用例所需的软件、硬件、网络配置等环境信息。
12. ​​备注信息​​：任何额外的信息，比如相关的依赖、特殊注意事项等。
13. ​​缺陷/问题ID​​：如果测试失败，关联的缺陷或问题的标识符。

12. 设计测试用例的方法​​

​​黑盒测试方法​​：

1. ​​等价类划分法​​

   • 将输入数据划分为不同的等价类，每个等价类都有相似的行为。然后从每个等价类中选择测试用例。

2. ​​边界值分析法​​

   • 关注输入值的边界情况，测试接近边界值和边界之间的情况。

3. ​​因果图法​​

   • 使用因果图来识别和描述系统中各种因果关系，辅助设计测试用例。

4. ​​决策表测试​​

   • 创建决策表，列出不同的输入组合和相应的输出，确保所有可能的组合都得到测试。

5. ​​状态转换测试​​

   • 适用于有状态的系统，测试系统在不同状态下的行为和状态之间的转换。

​​白盒测试方法​​：

1. ​​语句覆盖​​

   • 确保每个源代码语句都至少执行一次。测试用例的目标是覆盖代码的所有语句。

2. ​​分支覆盖​​

   • 确保每个分支语句都至少执行一次，以测试代码中的条件语句。

3. ​​路径覆盖​​

   • 通过执行代码的所有可能路径来测试系统，包括所有可能的条件分支和循环。

4. ​​条件覆盖​​

   • 测试代码中条件表达式的所有可能取值，以确保所有条件的不同情况都被覆盖。

5. ​​循环覆盖​​

   • 确保测试覆盖了循环的不同情况，包括循环的入口、中间和退出。

13 bug 的生命周期​​

1. ​​New（新的）​​
   　当某个"bug"被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。

2. ​​Assigned（已指派的）​​
   　当一个bug被认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为"Assigned"。

3. ​​Open（打开的）​​
   　一旦开发人员开始处理bug的时候，他(她)就将这个bug的状态设置为"Open"，这表示开发人员正在处理这个"bug"。

4. ​​Fixed（已修复的）​​
   　当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为"Fixed"并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。

5. ​​Pending Reset（待在测试的）​​
   　当bug被返还到测试组后，我们将bug的状态设置为"Pending Reset"。

6. ​​Reset（再测试）​​
   　测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为"Reset"。

7. ​​Closed（已关闭的）​​
   　如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为"Closed"。

8. ​​Reopen（再次打开的）​​
   　如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为"Reopen"。

9. ​​Pending Reject（拒绝中）​​
   　如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为"Pending Review"。

10. ​​Rejected（被拒绝的）​​
    　测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为"Rejected"。

11. ​​Postponed（延期）​​
    　有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为"Postponed"。