hit LAB1

Chapter 1 Views and Quality Objectives of Software Construction
1.1 Multi-Dimensional Views of Software Construction
1、软件构造中的多维视图
2、视图之间的联系
1.2 Quality Objectives of Software Construction
1、外部质量与内部质量
2、外部质量的具体方面
3、内部质量的具体方面
4、折中处理
5、五个关键的质量指标
二、软件测试与测试优先编程
1.测试的特点
2.测试用例
3.代码覆盖度
4.两类测试

Construction)
1.1 Multi-Dimensional Views of Software Construction
1、软件构造中的多维视图

·Moment维度关注于程序在某一时刻的表现,而Period关注的是程序在一段时间内的表现。
·Build-time维度关注程序还未被投入运行,编码阶段的表现,而Run-time维度更关注于程序运行时的表现;
·Code-level维度关注程序的语句层面,Component-level维度更关注于一段代码,当作一个块观察比如一个包、一个库。

(1) Build-time, moment, and code-level view 关注的是源码的组织情况,可在词汇(源码)、语法(抽象语法树)、语义(类图)三个层面分别分析。

(2) Build-time, period, and code-level view 关注的是代码的变化(Code churn代码变化)

(3) Build-time, moment, and component-level view 关注的是包/库,而且是静态链接库

(4) Build-time, period, and component-level view 关注代码的更迭,与(2)中不同的是,这个维度下更关注文件版本的变化,而不是具体语句的变化(2中关注的是哪一行代码被修改了)----VCS的引出

(5) Run-time, moment, and code-level view 关注的是程序在某个时间点内存中的情况,如代码快照图(Code Snapshot)、内存信息转储(Memory dump)。

(6) Run-time, period and code-level view 关注的是代码的执行情况,执行跟踪

(7) Run-time, moment, and component-level view 关注的也是包/库,但却是在代码执行过程中的情况,如动态链接库

(8) Run-time, period, and component-level view 关注的是系统的使用情况,使用日志查看

2、视图之间的联系

①从无到有,写出了代码,就进入了Build-time维度,开始只是单个的没有任何联系的代码文件,所以是在moment+Code-level维度;
②此时随着时间的推移,代码删删改改,就属于Period+Code-level了,而代码越写越多成为了一个包,甚至形成了一个库,于是就属于moment+Component-level维度了;
③但是随着时间的推移,库文件由于需求的变化发生了变化,所以就属于Period+Component-level;
④代码写好了,投入运行,进入Run-time维度,观察的如果是某一句代码的执行后结果,那就是moment+Code-level维度,但如果看的是代码执行的轨迹,那就是Period+Code-level维度,而如果看的是一个库文件的连接情况等,那就是moment+Component-level维度了;
⑤如果看的是线程或进程的执行过程,也就是通过日志等手段查看一段时间内系统都做了什么事情,那么就是Period+Component-level了。

1.2 Quality Objectives of Software Construction
1、外部质量与内部质量
外部质量因素影响用户,内部质量因素影响软件本身和它的开发者,外部质量取决于内部质量。

2、外部质量的具体方面
(1)正确性(Correctness):至高无上的质量指标,按照预先定义的“规约”执行。一个可用的软件一定是正确的,所以首要保证软件的正确性,其他的都可以做妥协、让步,但只有这一项不可妥协。
(2)健壮性(Robustness):是对正确性的补充,即在出现“规约”定义之外的情形的时候,软件要做出恰当的反应,通俗地说就是出现异常时不要“崩溃”。
但软件的“正常”与“异常”是主观而非客观的,所谓的“异常”,取决于spec的范畴,那些未被“规约”覆盖的情况即为“异常情况”。
(3)可扩展性(Extendibility):进行扩展使得程序能够应对变化。简约设计主义与分离设计主义
(4)可复用性(Reusability):一次开发进行多次使用,容易发现程序的共性。
(5)兼容性(Compatibility):在不同的环境下都是可用的,容易集成设计开发
(6)效率(Efficiency):不要过早的优化,性能在没有正确性保障的条件下是没有意义的。“过早优化是万恶之源!”
(7)可移植性(Portability):软件可方便的在不同的技术环境之间移植
(8)易用性(Easy of use):学习成本低,结构简单、清晰,易于使用。
(9)功能性(Functionality):功能过多会导致易用性的降低。主要功能要首要提升质量。

3、内部质量的具体方面
代码行数(LOC)、圈复杂度、结构:高内聚低耦合、可读性、可理解性、整洁度、大小

4、折中处理
①正确的软件开发过程中,开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来;
②当某一项满足的足够好的时候有可能其他项的表现极差,此时需要做权衡,使得各部分的表现都较好,在某些特定要求下也可以放弃优化其他项而做到某一项的极致;
③虽然需要折中,但“正确性”绝不能与其他质量因素折中。

5、五个关键的质量指标
·Elegant and beautiful code:代码要容易理解,通过统一变量/方法的命名标准、代码的风格、注释、包组织结构、必要时重构代码等方式让代码尽可能的容易理解。
·Design for/with reuse:ADT/OOP、接口、继承(Overload、Override)、多态、泛型、框架等技术可用于提高代码的可复用性。
·Low complexity:当复杂度较低的时候,代码就容易被扩展新的功能,所以要高内聚低耦合,遵从SOLID原则、OO设计模式、使用VCS控制代码版本
·Robustness and correctness:使用测试驱动的开发、异常处理、Assertion机制、防御式编程等技术保证程序的健壮性和正确性。
·Performance and efficiency:使用设计模式、并行/多线程等技术提升性能。

二、软件测试与测试优先编程
认可“测试”的价值,搞清楚“测试优先”的哲理

1.测试的特点
测试:
–> 在规定的条件下对程序进行操作,以发现程序错误,衡量软件品质,并对其是否能满足设计要求进行评估的过程。

①测试跟其他活动的目标相反:破坏、证错、“负能量”,即我们希望发现“错误”,要转变心态,用“让其出错”和“尽快出错”作为写高质量代码的日常法宝;
②要认识到即使是再好的测试也不能保证程序里不存在错误

2.测试用例
测试用例 = 输入+执行条件+结果
最主要的方法——单元测试:针对软件的最小单元模型开展测试,隔离各个模块,容易定位错误和调试。
基于等价类划分的测试:将被测函数的输入域划分为等价类,从等价类中导出测试用例。

此外还要注意边界值分析方法的补充,即在进行等价类划分的时候,需要把边界也作为等价类之一加入考虑。

3.代码覆盖度
覆盖度:
1.代码覆盖度
–> 基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。
2.输入空间覆盖度
–> 参照模块的规格说明,测试用例占总输入空间的比例。
效率:
–> 成果(测试结果)/资源(测试时间空间)

代码覆盖度越低,测试越不充分,但要做到很高的代码覆盖度,需要更多的测试用例,测试代价高。

测试效果:路径覆盖 > 分支覆盖 > 语句覆盖
测试难度:路径覆盖 > 分支覆盖 > 语句覆盖

4.两类测试
黑盒测试:黑盒测试:用于检查代码的功能,不关心内部实现细节。检查程序是否符合规约

白盒测试:要考虑内部实现细节,根据程序执行路径设计测试用例。一般比较早执行

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值