学习完软件构造之后，实验之后我们知道在软件测试过程中，“测试用例的数目”、“测试的覆盖度”、“测试的效率”三者之间存在一定的关系。我们要让三者有一个合适的折中，保证性能达到最优。

一、基本定义

1.测试：在规约下对程序进行操作，目的是发现程序错误，为以后调试bug做准备，并对其是否能满足设计要求进行评估的过程。

2.测试用例：为检测软件是否有效而构造的一组测试输入、执行条件以及预期结果，以便测试某个程序路径是否满足规约。

3.覆盖度：
（1）.代码覆盖度：基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。
（2）.输入空间覆盖度：参照模块的规格说明，测试用例占总输入空间的比例。

4.效率： 测试结果/测试时间空间

二、敏捷思想对软件开发带来的优势

首先敏捷思想的内容：

1. 个体和互动高于流程和工具：团队应该自我进行组织和沟通，一个协作沟通的开发团优于一个孤立运行的专家团队。

2. 工作的软件高于详尽的文档：一款工作的软件能比一份厚重的文档更能向用户呈现开发结果。

3. 客户合作高于合同谈判：由于软件开发初期开发人员（甚至客户）都很难知晓真正的需求，所以开发团队应该直接接触用户或代理，从中获取反馈，并在此基础上不断明确、改变需求和开发方向。

4. 响应变化高于遵循计划：软件开发的重点应该是相应市场变化而不是死板遵循合同。

其次传统开发的特点：

1. 强调文档对于团队成员的指导作用，开发人员是在不知道项目细节的情况下进行开发的。

2. 将开软件开发过程分为可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护七个阶段，每个阶段的输出是下一个阶段的输入。

3. 开发计划一开始就已经订好，没有大量同客户的沟通交流。

最后优势：

1.以人为本，强调客户和开发团队间的有效沟通和紧密协作，使得客户需求得到满足（可以等有价值的信息出现或对技术优化后才去决定）。

2.适应性较强，接受开发过程中需求的频繁修改，能有效地应对市场需求的变更。

3.通过增量迭代，每次都优先交付那能产生价值效益“不完全”功能，及时抢占竞争激烈的市场。并最大化单位成本收益。

三、一些软件构造的模型：

瀑布模型：线性，通过一系列确定过程完成项目，容易使用，但是开发后期的改动开销会很大，同时无法拿出早期版本。

增量模型： 线性，将项目分成各个小项目，逐次按照优先程度完成，但并不能在完成小项目以后看到一个早期版本，同时小项目开始开发后其要求就被“冻结”，无法从客户获得新的反馈。

原型模型：迭代，先构造一个项目原型，在该原型的基础上，逐渐完成整个开发工作。即首先建造一个快速原型，实现客户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

在实验过程中，我意识到本人缺少开发经验，对开发平台不了解，项目时间紧迫，后续扩展要求多，依然带领小组获得了项目开发权

四、在面向对象的设计原则SOLID中，“依赖转置原则(DIP)”与“开放封闭原则(OCP)”之间的内在的联系？

1.依赖转置原则(Dependency inversion principle)

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

2.开闭原则( Open/closed principle)

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

开闭原则就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性。

综上，实现依赖倒置原则的实现其实就体现了开闭原则，例如当我们想添加C类功能时，由于类A依赖的是一个抽象接口，我们只需要依照结构添加一个新的类C即可（对扩展开放），而不是改动类A的代码（对修改关闭）。

标签：依赖,测试,折中,性能,细节,客户,抽象,开发
来源： https://blog.csdn.net/sbj001/article/details/118345415