软件工程导论(四)软件编码测试与维护

一、软件编程

1.1良好的编程习惯

变量命名有意义并且使用统一的命名规则
编写自文档代码（序言性注释 or 行内注释）
提前进行可维护性考量（可以用常量的方式存在的数值最好以变量的方式存在）
良好的视觉安排可以提高代码的可读性(缩进/空行)

1.2代码集成

1.2.1一次性集成

驱动模块和存根模块

问题：

1. 格外的驱动存根编写
2. 错误隔离

1.2.2系统集成（SQA团队）

自顶向下集成

bfs和dfs的过程都是可以的
bfs更加方便控制系统的逻辑结构
dfs能够尽早的实现某一个分支的功能

广度优先：控制整个系统的逻辑结果

深度优先：能尽早实现某个功能

优点：

• 错误隔离
• 存根模块不被浪费
• 逻辑正确
• 能够尽早发现设计（顶层）的错误
• 逻辑组件的测试更加充分

缺点：

• 较低层的软件测试的比较晚，而且测试不够充分

自底向上

bfs和dfs的过程都是可以的

优点：

• 充分测试底层的重用概论非常大的操作组件
• 驱动模块不用编写
• 错误隔离

缺点：

• 设计错误可能会发现的比较晚

三明治集成

逻辑组件自顶向下集成
操作组件自底向上集成
最终二者在接口处集成

面向对象过程中对对象进行自底向上，其他进行自顶向下

二、软件测试

软件测试过程遵循“自底向上，逐步集成”的方式，即从小规模测试开始，逐步进行大规模测试。

2.1软件测试分类

• 黑盒测试

按照规格进行测试 (数据驱动、功能性测试或输入/输出驱动测试)，忽略代码 - 使用规范来选择测试案例

• 白盒测试

测试到代码 (逻辑驱动、结构化或面向路径的测试）- 忽略规范 - 使用代码来选择测试案例

通过工件的每个路径必须至少执行一次

检测了所有路径也不能证明程序就是正确的

结论

规格测试，代码测试，随机测试都不可靠

2.2黑盒测试（用户）

避免数据覆盖带来的庞大测试量（单元测试）

• 等效值测试
• 边界值分析测试

基于黑盒测试进行功能测试

2.3白盒测试（开发者）

• 语句覆盖

选择足够多的测试数据，被测试程序中的每条语句至少执行一次

• 分支覆盖

不仅每个语句至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次

• 条件覆盖

不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果

• 分支+条件覆盖

选择足够多的测试数据，使判定表达式中的每个条件都取到各种可能的结果，而且每个判定表达式也都取到各种可能的结果。它同时满足判断覆盖和条件覆盖

• 条件组合覆盖

选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。满足条件组合覆盖，也一定满足判定覆盖、条件覆盖和判断/条件覆盖

• 路径覆盖

选取足够多的测试数据，使程序的每条可能路径都至少执行一次，如果程序图中有环，则要求每个环至少经过一次

总结

原则上进行语句覆盖，即每个处理数据的语句都覆盖一遍

语句覆盖和分支覆盖都不能检查出逻辑判断存在的问题

用例满足能条件覆盖又能分支覆盖，但是还是不能检查出逻辑判断存在问题

2.4单元测试

 2.5集成测试

2.6确认测试

2.7测试管理

SQA软件质量保证小组

• GUI集成测试：鼠标点击、键盘输入
• 产品测试：从用户的角度对整个产品进行测试，基于模拟数据
• 验收测试：基于真正的用户数据（正确性、健壮性、性能、文档）（有效性）

三、软件维护

3.1移交后的维护

广义上：整个软件声明周期过程中的维护过程
狭义上：软件完成递交之后发生的软件维护过程

• 改正性维护：一些错误没能在验收和测试中发现，但是被用户或者维护人员发现了
• 完善性维护：进一步提升质量引起的维护（增加功能、运行速度、优化模块的内聚耦合、优化文档、优化代码）
• 适应性维护：因外部环境变化导致的（新的编译器、新的操作系统、新的平台）

维护工作难度最大，要求从业者了解软件全部生命周期

• bug：小缺陷，不希望的偏差
• defact：软件不能正确的完成需求
• error & fault：故障，组件中异常的情况，error容易解决
• failuer：失效，软件不具备设计的时候要求的功能
• vulnerability：缺陷，存在于软件架构和设计中

缺陷报告：用户或维护人员需要将错误的表现和具体操作过程等信息填写到缺陷报告

3.2软件维护的特点

（1）结构化维护和非结构化维护差别巨大

• 非结构化维护：唯一成分是程序代码，维护活动从艰苦地评价程序代码开始，需要付出很大代价
• 结构化维护：有完整的软件配置存在，维护工作从评价设计文档开始

（2）维护的代价高昂（了解）

（3）维护存在很多问题（了解）

3.3维护管理工作

缺陷报告

由于人力物力的原因，每个缺陷有时候不能立即修复，需要进行调查管理过程

• 提交缺陷报告
• 查阅之前的缺陷报告，如果之前有过就直接反馈，如果没有过就修复并且找到解决方法，之后将缺陷报告、修改清单、设计文档、用户使用手册进行归档
• 建立缺陷报告副本，并且分发给所有从业人员（修复的时间等信息），方便相同问题的统一解决

  

对软件产品的变更授权

改正性维护：

• 指定维护人员进行分析和修复
• 对修改进行测试，需要进行回归测试
• 修改文档
• 更新代码的序言注释

完善性维护 和 完善性维护：

• 需求变更报告（需求的功能性或者性能方面的变更）

最后产品分发之前必须由SQA小组进行测试，必须遵循基线和私有副本原则

软件逆工程是一个从具体到抽象的过程。