软工个人作业1.1

项目	内容
这个作业属于哪个课程	首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问 - 作业 - 2025年春季软件工程（罗杰、任健） - 班级博客 - 博客园
我在这个课程的目标是	体验软件开发的整个流程，对软件工程有更深的了解
这个作业在哪个具体方面帮助我实现目标	让我对软件开发的流程有了初步的了解；清楚了团队各成员的功能职责，如PM、开发、测试人员；对各种测试方法有了基本概念，不止局限于黑箱白箱测试。

问题一

我看了这段文字：

软件开发过程很大程度上是一个探索和实验的过程, 不同的 re-work 能帮助工程师深入了解项目的各个难点, 尽早交付原型, 找到最优解决方案，等等. 因此 re-work 是有价值的。

我的问题是re-work就一定能提高软件最终的质量吗？

根据我过往的实践经历，re-work其实有主动和被动之分，主动的re-work是在项目开发过程中受人启迪或根据问题的迭代发展来改变自己的程序架构，这种re-work虽然看似增长了软件开发的时间，但最后能得到一个功能更强、框架更清晰的软件项目。但也不能否认存在被动re-work，这种一般是遇到无法解决的问题，才不得不改变原有的软件架构，而这种改变往往不够彻底、也不够高明，有些甚至还是在原有的程序上打补丁。因此我觉得在软件开发过程中，对re-work要有辩证的看法。

问题二

我看了这段文字：

个人的劳动成果有序地组织起来, 就是团队的流程。这里说的“有序”, 并不是“无争论”, 在大部分成功的软件团队模型中, 各个角色（开发, 测试, 项目管理等）考虑问题的出发点是有区别的, 不同意见的冲突在所难免, 一个好的团队流程能把冲突的积极方面 (各自尽力把自己的工作做好，说服别人) 释放出来, 而避免消极方面 (因为冲突而产生的消极，抵触情绪等)。

我的问题是能针对积极冲突提出一些具体的建议吗？

根据我过往的经验，小组内大家各有自己的想法，互相说服的过程中总有人的想法不被采纳，长此以往可能会有人丧失信心和积极性。因此我的困惑是，在这篇讲义中对“冲突”的积极和消极方面描述得太笼统、也太理想化了，可以针对冲突积极化提出一些具体的建议，以供我们小组合作时参考吗？

问题三

我看了这段文字：

单元测试必须覆盖所测单元的所有代码路径。

问：啊！这样岂不是要写很多啰里啰唆的测试方法？

答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉。

我的问题是所有软件工程的单元测试都要保证100%的覆盖率吗？

我联想到了老师课上的提问，对于一个用户极低概率会使用的功能，我们要将其实现吗？和这里的问题类似，如果一个错误处理路径很难到达，还是要坚持100%的测试覆盖率吗？对于此好像没有标准答案，我自己也不太能抉择是否要投入庞大的时间去维护测试的覆盖率，或许我在之后的软件开发过程中会有更深体会。

问题四

我看了这段文字：

PM 太多了以后, 由于大部分决定都是经过平等而反复的讨论协商折中的到的, 一个后果是 “design by committee”, 一些产品不能很快跟上市场变化, 在需要个人特色的方面, 如设计/UI, “committee”设计出来的东西大多中规中矩, 但是很多方面了无新意。

在PM主导的产品中，“不犯大错”成了一个特点，微软的很多产品在长期的竞争中， 靠“不犯大错”，从第三版开始，赶上并超越对手。这也是一个了不起的能力。

我的问题是在PM主导下、全体组员的讨论下完成的软件工程“不犯大错”，但似乎也陷于中规中矩，那这样一个看似没有很大创新的产品是如何能在竞争中赶超对手的呢？

通过阅读该博客，我初步认识到了PM主导和“committee"平等商议、共同设计软件的重要性，但对PM制度产生的产品竞争力仍有困惑，对微软靠“不犯大错”赶超对手也有困惑。

问题五

我看了这段文字：

一些人对“测试”这一工作还有很多误, 解例如下面的似是而非的观点:

测试在项目的最后进行就可以了。

这是远远不够的。当你在项目后期发现了问题，问题的根源往往是项目早期的一些决定和设计，这时候，再要对其进行修改就比较困难了。这要求测试人员从项目开始就要积极介入，从源头防止问题的发生。有人会说，我是一个小小的测试人员，项目开始的时候我能做什么？这就是小小测试人员努力的方向。

我的问题是：测试人员确实需要很强的前瞻性，才能跟进整个软件开发流程不落队，那测试人员在软件开发的前期中期能做什么准备工作呢？

我查了资料，一般软件测试人员可以提前准备脚本及场景，比如测试组负责测试脚本的开发与场景策略的设计，包含“基准场景、单接口/单功能场景、混合场景、容量测试场景、稳定性场景”等。还可以提前准备基础数据和测试数据。但我仍有疑问，这种泛泛的准备工作最后能在软件测试中发挥作用的有多少，要如何避免测试人员只能参与到最后的测验环节、而在软件开发的前中期无法融入的局面？