【课堂练习】

练习1：
同学们用本小组项目中实际的例子来重现如下问题：

1、代码覆盖率对于“应该写但是没有写的代码”无能为力。

（例如代码申请了内存 或其他资源，但并没有释放。又如，代码中并没有处理错误情况。或者没有处理 和文件、网络相关的一些异常情况，例如文件不存在、权限有问题，等等。）

2、代码中有效能问题，虽然代码执行了，并且也正确地返回了，但是代码效率非常低。

（有些情况下，可以针对代码效率写一个单元测试。）

3、多线程环境中的同步问题

（这个问题和代码执行的时序、共享资源的锁定有关）

我的答案:
A1：应该写但是没有写的代码
异常处理和资源管理
在数据库操作、文件操作或网络通信等代码中，通常需要考虑异常处理和资源管理。例如，在StuScoresService和SysUserService等服务层代码中，如果涉及到数据库操作，应确保在操作失败时能够正确处理异常，并且及时释放数据库连接等资源。
异常处理：代码中应该有更明确的异常处理逻辑，比如使用try-catch块捕获可能的异常，并进行适当的处理，如记录日志、回滚事务等。
资源管理：对于数据库连接、文件流等资源，应确保在使用完毕后能够及时关闭，避免资源泄露。Java 7 引入的try-with-resources语句提供了自动管理资源的便捷方式。
A2:效能问题
数据库操作的性能考虑
批量操作：在处理批量数据时（如批量删除、批量插入），应确保使用数据库的批处理能力，减少数据库访问次数。例如，在SysLogininforMapper中的deleteLogininforByIds方法，如果处理大量ID时，应考虑使用批处理技术，而不是循环单条处理。
查询效率：对于查询操作，需要确保使用高效的查询语句，并且合理使用索引。例如，在SysMenuMapper中的查询方法，如果涉及到复杂的查询条件或者大量数据的查询，应确保SQL语句的优化和索引的使用。
2. 对象的创建和销毁
在一些场景下，频繁地创建和销毁对象可能会影响性能，尤其是在高并发的环境下。虽然现代JVM的垃圾回收机制已经非常高效，但是在性能敏感的场合，仍然需要注意对象的创建频率。例如，对于SysLogininfor等实体类，如果在处理大量数据时频繁创建实例，可能需要考虑对象池等技术。
3. 资源使用和管理
资源泄露：在数据库连接、文件操作等场景中，未能及时释放资源可能导致资源泄露，进而影响系统性能。虽然提供的代码片段中没有直接的示例，但在实际开发中需要注意确保所有资源在使用完毕后都能被正确关闭。
A3:多线程环境中的同步问题
项目前后端分离，难以体现多线程。

练习2：
请举出你在本小组项目的测试用例中，BICEP 是如何达到的？要写多少测试用例才够呢？

Right-BICEP方法：

Right－结果是否正确？

Border Condition－是否所有的边界条件都是正确的?

Inverse Relation: 能查一下反向关联吗？

Cross check: 能用其他手段交叉检查一下结果吗？

Error－你是否可以强制错误条件发生？

Performance－是否满足性能要求？

看大部分代码是否被覆盖了

我的答案:
根据Right-BICEP原则来讨论如何设计测试用例以确保代码的质量和稳定性。Right-BICEP是一种测试原则，旨在确保软件的正确性、边界条件处理、反向关系、交叉检查、错误处理和性能。下面是根据这些原则，针对提供的代码片段的一些建议：

Right－结果是否正确？
测试用例：为每个功能（如新增、查询、更新、删除操作）编写测试用例，确保操作的结果符合预期。例如，对于SysLogininforMapper的insertLogininfor方法，确保登录信息能正确插入数据库。
Border Condition－是否所有的边界条件都是正确的?
测试用例：针对每个方法的输入参数设计边界条件测试用例。例如，测试ID为最小值、最大值、空值等情况下的处理逻辑。对于批量操作，测试空列表、只有一个元素的列表、以及包含多个元素的列表。
Inverse Relation: 能查一下反向关联吗？
测试用例：对于涉及到关联数据的操作，测试反向关联是否正确。例如，删除一个角色后，验证是否还能查询到该角色的权限信息。
Cross check: 能用其他手段交叉检查一下结果吗？
测试用例：使用不同的方法或工具来验证操作的结果。例如，使用直接查询数据库的方式来验证通过SysMenuMapper添加的菜单项是否真的存在。
Error－你是否可以强制错误条件发生？
测试用例：设计测试用例来模拟错误条件，如数据库连接失败、输入参数无效等，确保系统能正确处理这些错误情况。例如，模拟数据库连接失败时，系统应返回适当的错误信息而不是崩溃。
Performance－是否满足性能要求？
测试用例：设计性能测试用例，如模拟高并发场景，确保系统在负载较高时仍能正常工作，并满足性能要求。例如，测试在并发插入大量登录信息时SysLogininforMapper的性能。
测试用例数量
测试用例的数量取决于代码的复杂性、功能的多样性以及风险评估。理论上，为了全面覆盖所有的逻辑路径、边界条件和异常情况，可能需要编写大量的测试用例。但在实际操作中，应根据项目的实际情况和资源限制，通过优先级排序来决定哪些测试用例最重要，从而实现有效的测试覆盖。