[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13365
我在这个课程的目标是	锻炼开发大型软件项目能力，掌握软件工程相关知识
这个作业在哪个具体方面帮助我实现目标	了解软件工程相关理论知识

问题1：PM为什么不领导开发测试人员

问：既然PM这么厉害，为什么不让他们领导开发人员和测试人员，这样PM工作起来不就是更有利了么?

答：首先，我们认为好的产品设计是在平等讨论(甚至争论)的基础上产生和完善的，如果讨论的一方同时又是另一方的老板，则无法进行平等和无拘束的讨论。

其次，PM的产品是规格说明书(Spec),PM要凭自己的能力，把用户的需求展现成其他成员能够理解和执行的语言，从而赢得同伴的信任和尊敬。如果PM同时又是其他人的老板，则不必写太好的Spec,用命令即可说服别人。再次，PM不一定是很好的行政经理(管人的),硬把管理不同专业人员的任务加到PM头上，反而会坏事。

• 书中认为产品设计需要在平等讨论的基础上进行，但在实际团队协作中，是否真的能做到完全平等的讨论？如果没有明确的决策者，可能会导致决策效率下降，最终影响项目进度。
• 文章认为 PM 不应该是开发和测试的领导，而是通过写好 Spec 来赢得尊重。但在实际项目中，如果 PM 缺乏领导权，是否可能导致团队执行力不足？尤其在大规模项目中，PM 需要一定的管理权力来确保产品方向的一致性，而不仅仅依赖个人影响力。

问题2：修改集集成到代码库中的疑问

现在开发人员手头上有不少修改，分别属于不同的具体任务，那如何将这些修改签入源代码控制系统呢?具体步骤如下：

1.根据场景和开发任务来决定集成的次序

2.互相依赖的任务要一起集成

3.在测试场景时，要保证端到端的测试

4.场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”

• 书中提到互相依赖的任务要一起集成，那么该如何处理任务间的依赖呢？
• 网上一些资料提到可以使用 Feature Flags（功能开关） 来管理依赖，使得未完成的任务不会影响整体集成；还有的建议采用 分支合并策略，比如 GitFlow 或 Trunk-Based Development，以减少集成冲突。此外，还有一种做法是 Stub 和 Mock，即在依赖任务尚未完成时，使用模拟实现进行测试，避免集成受阻。
• 如果某个任务的依赖项开发进度落后，而整个项目又有固定的发布时间，应该如何权衡 等依赖完成 vs. 先行集成未完成部分？如果提前集成，如何保证不会影响已有功能的稳定性？

问题3：单元测试独立性

独立性--单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。
如果其他的模块很不稳定，或者其他模块运行比较费时(如进行网络操作)，而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据，以保证单元测试的独立性。

• 单元测试的独立性意味着需要人为构造数据，而代码的复杂逻辑往往依赖于数据库、外部 API 或其他模块的返回值。在这种情况下，如何在保证测试独立性的同时，又能确保测试的真实性和可靠性？

• 在OO课中，我使用了JUnit对类进行测试；在数据库开发网站后端时，我会使用 JUnit 的 Mock 机制来模拟数据库查询和外部 API 的返回值，这样可以确保测试独立性。但有时候，Mock 的逻辑可能与真实环境的行为有所出入，导致测试通过但在实际运行中出现问题。此外，全面覆盖所有代码路径有时会带来维护成本上升的问题，特别是在代码频繁变化时，测试用例的调整成本较高。

• 如果单元测试完全依赖 Mock，是否会导致测试结果过于理想化，难以发现真实环境中的潜在问题？另外，对于某些涉及多线程、异步调用或时间依赖的代码路径，单元测试该如何确保覆盖并保持稳定？

问题4：用例设计如何平衡清晰与复杂？

通过讲简单的故事来传递信息

讲故事是最有效的人与人交流信息的途径，通过讲故事(UseCase)，团队成员能对需求有统一的了解。当我们用自然语言讲故事的时候，我们不自觉地会把复杂的系统当作一个黑盒子，把重点放在用户的愿望、行动上面，这种做法非常有利于我们找到用户的需求和软件的功能点。当然，故事要包含具体的行动(Actionable)，并且是可以验证的(Testable)，所以讲故事也要有技巧

• 在用例设计中，如何确保主要成功场景既能清晰表达用户需求，又不会因技术细节的加入而变得复杂？
• 根据Use Case 2.0的原则，主要成功场景应聚焦用户目标，使用自然语言描述交互步骤，避免涉及系统内部逻辑。但是，我实际开发过程中，技术约束和户需求常常是并存的，如果忽略技术细节，往往会造成场景描述的不清晰。
• 例如，在“用户登录”用例中，主场景描述为“用户输入账号密码后进入主页”，但实际开发中需明确身份验证接口的调用逻辑。如何在扩展场景中补充技术约束，同时保持主场景的简洁性？是否有工具或方法能动态关联主场景与扩展场景，避免文档臃肿？

问题5：压力测试

压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况下，是否仍能返回正常结果，没有产生严重的副作用或崩溃。

• 在Web项目开发中，压力测试主要是指高并发测试，主要需要解决的问题一方面是对数据库高并发访问，另一方面是高并发情况下的线程安全。
• 有时候可能会牺牲并发量进行请求限流、加锁来限制并发量保证安全性，也可以选择放弃部分安全性提高并发量，这种时候要如何权衡，是改由技术人员衡量还是由产品经理衡量？
• 书中提到了沿着时间轴增长，但是现代web应用中，后端只需要处理前端的请求，那么沿着时间轴增长这一压力测试方法仍然有效吗，又该怎么实现？