[软件工程基础]第 1 次个人作业

阅读教材后的疑问

编写单元测试的原则

此问题源于 P25 “2.1.2 好的单元测试的标准”。

在实际操作过程中，一个代码片段可能就是对于一段功能的极简描述，试图从外部验证其是否完成了指定功能本身就很困难。

比如 DLX 中覆盖一列的操作 ，如果对该函数进行单元测试，就要验证其是否准确删除了一列及其对应的若干行，完成这项验证有两种方法：

1. 以类似 的逻辑写一遍验证，但这本质上是循环论证，没有意义。
2. 准确描述删除之后应该具有的状态，这需要以复杂的方法编码一个双向循环链表的状态，编写的测试的过程本身容易出错。

以上两点或许不是全部的解决方法，但是思考其它做测试的方法所花费的时间以及复杂度可能远远大于这个函数本身。

另一方面，该算法解决的精确覆盖问题却是较易验证的，只需要验证解是否构成一个精确覆盖即可，但是这就是在一个更大的层次上进行测试，并没有对 进行单独的单元测试。

在类似这种难以对微观结果做描述，宏观结果易验证的情况下，是否还要执着于微观结果的单元测试p>

此外，在 “单元测试应该覆盖所有代码路径” 中，提出了条件的覆盖。文中只是抛出了分支覆盖不等同于条件覆盖，那么我们在实际操作中究竟是否应该重视条件覆盖何时应该重视呢p>

总的来说，当单元测试会对开发造成极大负担的时候，该以何种原则找到二者之间的平衡点p>

团队模式选择

在第 5 章 “团队和流程” 中，介绍了许许多多的软件团队的模式，这其中各有利弊，但作为经验十分不足的我们，该如何选择团队模式如何通过一个高效、低错误代价的流程确定较为适合的模式p>

关于共同远景

在 7.2 “MSF 基本原则” 中提到为“共同的远景而工作”，但在长时间的开发流程中，可能因为现实世界的变化导致远景不再现实，或者过程中的琐碎细节冲淡了对于这份远景的激情。而这一条又是 MSF 基本原则中维持团队凝聚力的重要一环，那么此时该通过什么方式强化团队的凝聚力呢p>

关于会议

在 9.4 “领导力——高效的团队讨论” 中，提出了一些关于有效开会的一些阶段性流程，但实际列举到的手段较少，只有一个好主意停车场。考虑到在讨论的时候领导者可能自己也会深陷讨论不可自拔，有没有一些更加具体且有效的手段监控整个会议的流程定时是否是一个好的选择p>

关于源代码管理

在 11.6 “实战中的源代码管理” 中，提出了若干场景，但是没有答案只有一些问句，潜台词是否是说这些方面是需要考虑的，但是在实际的生产生活中并没有一个较为公认的方法解决各个场景吗有一些具体的解决方案的例子说明各种方案之间的优劣p>

请问 “软件” 和 “软件工程” 这些词汇是如何出现的 – 何时、何地、何人h2>

软件：最早的已知的使用记录是 1953 年八月由 Richard R. Carhart 在一次 Rand Corporation Research Memorandum 中做出的。具体发明时间、发明人不详。

软件工程：由 Margaret Hamlton 在开发阿波罗 11 期间发明，时间大约在 1968 年附近。

大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事h2>

在 1990 年 1 月 15 ，由于 AT&T 公司一行代码中的错误，导致 7500 万电话呼叫无响应，造成该公司 6 万美元的电话收入损失，其它间接损失未知。来自这里。

Microsoft TFS

优点：分布/集中式版本控制，适用于敏捷开发，持续集成

缺点：多人时价格较贵

参考资料

Git

优点：分布式版本控制，易使用的分支、合并，易调整的工作流，高效率，开源，免费

参考资料

Mercurial

优点：高扩展性，易移植，商业支持

缺点：不能合并，非脚本化的

参考资料1

参考资料2

GitHub

优点：便于管理开源软件，使用 Markdown 做记录，有良好的帮助文档

缺点：稍陡的学习曲线

参考资料

Bitbucket

优点：易于使用

缺点：不可以搜索源代码

参考资料1

参考资料2

Trac

优点：易用的项目管理功能

缺点：对大多数版本控制软件没有原生支持

参考资料1

参考资料2

Bugzilla

优点：开源，易用，集成了测试管理、邮件系统，可自动化生成文档

缺点：复杂的界面

参考资料

Rational

优点：自动化测试

缺点：价格昂贵，对生态系统外的支持不友好，较缓慢的开发周期

参考资料

备注

用户量很难找到相关资源（即时是估计），故未填写。

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览35042 人正在系统学习中 相关资源：基于Slide的露天矿高陡岩坡失稳滑移方量估算-其它代码类资源-CSDN…