软考中级软件设计师教材精讲17 – 第5章第2讲
大家好,我是枯燥的工程师。
近几年软考的命题趋势显示,考查范围越来越广,细节要求越来越高。仅靠学习传统的“重点难点”,已难以覆盖所有考点,系统性遗漏的风险在增加。因此,我对《软件设计师》教材进行了全面梳理,预计200余个具体知识点,逐一整理、编号、解读。建立完整的知识体系,是应对当前考试最扎实的方法。也欢迎大家扫描文末二维码加入学习交流群!
从2月份开始,我将以每周更新三次的频率,严格按教材顺序分享知识点,预计四月下旬完成。
今天我们继续分享第5章:
知识点19.系统测试概念
系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。系统测试原则如下
(1)应尽早并不断地进行测试。
(2)测试工作应该避免由原开发软件的人或小组承担。
(3)在设计测试方案时,不仅要确定输入数据,而且要根据系统功能确定预期输出结果。
(4)在设计测试用例时,不仅要设计合法的输入条件,也要包含非法的输入条件。
(5)在测试程序时,不仅要检验是否做了该做的事,还要检验是否做了不该做的事。
(6)严格按照测试计划来进行,避免测试的随意性。
(7)妥善保存测试计划、测试用例,作为软件文档的组成部分,为维护提供方便。
(8)测试例子都是精心设计出来的,可以为重新测试或追加测试提供方便。
2.测试过程
(1)制订测试计划。
(2)编制测试大纲。
(3)根据测试大纲设计和生成测试用例,产生测试设计说明文档。
(4)实施测试。
(5)生成测试报告。
知识点20.传统软件的测试策略
1.单元测试
单元测试也称为模块测试,在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试,一般用白盒测试法。单元测试的测试内容单元测试主要检查模块的接口、局部数据结构、重要的执行路径、出错处理、边界条件等。
单元测试过程由于模块不是独立运行的程序,各模块之间存在调用与被调用的关系。在对每个模块进行测试时,需要开发两种模块。
驱动模块。相当于一个主程序,接收测试例子的数据,将这些数据送到测试模块,输出测试结果。
桩模块。桩模块用来代替测试模块中所调用的子模块,其内部可进行少量的数据处理,目的是为了检验入口,输出调用和返回的信息。
2.集成测试
集成测试就是检查模块之间,以及模块和已集成的软件之间的接口关系,并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。包括:
1)自顶向下集成测试:先测试整个系统,需要编写桩程序,而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
2)自底向上集成测试:从最底层模块开始测试,需要编写驱动程序,而后开始逐一合并模块,最终完成整个系统的测试。优点是较早的验证了底层模块。
3)回归测试:重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。
4)冒烟测试:软件构建后的基础验证,用于快速确认核心功能是否正常工作,从而决定是否需要进行更全面的测试。
3.确认测试
主要用于验证软件的功能、性能和其他特性是否与用户需求一致。
根据用户的参与程度,通常包括以下类型:
内部确认测试:主要由软件开发组织内部按照SRS进行测试。
α测试:用户在开发环境下进行测试。
β测试:用户在实际使用环境下进行测试,通过改测试后,产品才能交付用户。
验收测试:在真实的用户工作环境下,检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。
4.系统测试
测试对象是完整的、集成的计算机系统;测试的目的是在真实系统工作环境下,验证完成的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。
主要内容包括:
1)恢复测试;
2)安全性测试;
3)压力测试;
4)性能测试;
5)部署测试。
知识点21.面向对象软件的测试
对于面向对象软件,测试的基本目标仍然是在现实的时间范围内利用可控的工作量找出尽可能多的错误,但是其本质特征的不同使得测试策略和技术也发生了变化。
1.单元测试:面向对象软件中单元的概念发生了变化,封装导出了类的定义。
2.集成测试:由于面向对象软件没有明显的层次控制结构,因此面向对象环境中的集成测试有两种策略:(1)基于线程的测试。(2)基于使用的测试。
知识点22.测试Web应用
由于WebApp位于网络上,并与很多不同的操作系统、浏览器、硬件平台、通信协议及其他应用系统进行交互作用,错误的查找是一个重大的挑战。
1.质量维度。
为了了解 Web 工程环境中的测试目标,必须考虑 WebApp 质量的多种维度。
(1)内容。 (2)功能。(3)结构。(4)可用性。
(5)导航性。 (6)性能。 (7)兼容性。(8)安全性。
2.WebApp测试策略
(1)对WebApp的内容模型进行评审,以发现错误。
(2)对接口模型进行评审,保证适合所有的用例。
(3)评审WebApp的设计模型,发现导航错误
(4)测试用户界面,发现表现机制和导航机制中的错误。
(5)对功能构件进行单元测试。
(6)对贯穿体系结构的导航进行测试。
(7)在各种不同的环境配置下实现WebApp,并测试WebApp对于每一种配置的兼容性。
(8)进行安全性测试,试图攻击WebApp或其所处环境的弱点。
(9)进行性能测试。
(10)通过可监控的最终用户群对WebApp进行测试,对他们与系统的交互结果进行以下方面的评估,包括内容和导航错误、可用性、兼容性以及WebApp的安全性、可靠性及性能等方面的评估。
知识点23.测试方法
1.方法分类:
(1)静态测试。静态测试是指被测试程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。包括①人工检测。②计算机辅助静态分析。
(2)动态测试。动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。
2.黑盒测试
也称为功能测试,在完全不考虑软件的内部结构和特性的情况下,测试软件的外部特性。
常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。
(1)等价类划分。把所有的数据按照某种特性进行归类,而后在每类的数据里选取一个即可。设计原则:设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。例如招聘系统。
(2)边界值分析。将每类的边界值作为测试用例,边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值。例如环境温湿度监控系统。
(3)错误推测。没有固定的方法,凭经验而言,来推测有可能产生问题的地方,作为测试用例进行测试。
(4)因果图:由一个结果来反推原因的方法,具体结果具体分析,没有固定方法。
3.白盒测试
白盒测试也称为结构测试,根据程序的内部结构和逻辑来设计测试用例,对程序的路径和过程进行测试,检查是否满足设计的需要。白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括:
①语句覆盖。语句覆盖是指选择足够的测试数据,使被测试程序中的每条语句至少执行一次。语句覆盖对程序执行逻辑的覆盖很低,因此一般认为它是很弱的逻辑覆盖。
②判定覆盖。判定覆盖是指设计足够的测试用例,使得被测程序中的每个判定表达式至少获得一次“真”值和“假”值,或者说是程序中的每一个取“真”分支和取“假”分支至少都通过一次,因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
③条件覆盖。条件覆盖是指构造一组测试用例,使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
④判定/条件覆盖。判定/条件覆盖是指设计足够的测试用例,使得判定中每个条件的所有可能取值(真/假)至少出现一次,并使每个判定本身的判定结果(真/假)也至少出现一次。
⑤条件组合覆盖。条件组合覆盖是指设计足够的测试用例,使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。
⑥路径覆盖。路径覆盖是指覆盖被测试程序中所有可能的路径。
知识点24.调试
调试发生在测试之后,其任务是根据测试时所发现的错误找出原因和具体的置,进行改正。调试工作主要由程序开发人员进行,谁开发的程序就由谁来进行调试。测试是发现错误,调试是找出错误的代码和原因。
调试的方法有:试探法、回溯法(从出错的地方开始,向回找)、原因排除法(找出所有可能的原因,逐一进行排除,具体包括演绎法、归纳法、二分法)。
5.6运行和维护知识
知识点25.系统转换
新旧系统之间的转换方式有直接转换、并行转换和分段转换。
(1)直接转换。启用新系统,终止旧系统运行。
(2)并行转换。新旧系统并行工作一段时间后,新系统正式替代旧系统。
(3)分段转换。以上两种转换方式的结合,在新系统全部正式运行前,一部分一部分地代替旧系统。
知识点26.软件维护
软件维护是软件生命周期中的最后一个阶段,处于系统投入生产性运行以后的时期中,因此不属于系统开发过程。软件维护是在软件已经交付使用之后为了改正错误或满足新的需求而修改软件的过程,即软件在交付使用后对软件所做的一切改动。
系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度。系统可维护性的评价指标包括:
(1)可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。
(2)可测试性。诊断和测试的容易程度取决于易理解的程度。
(3)可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。
系统维护包括硬件维护、软件维护和数据维护,其中软件维护类型如下:
正确性维护:发现了bug而进行的修改。
适应性维护:由于外部环境发生了改变,被动进行的对软件的修改和升级。
完善性维护:基于用户主动对软件提出更多的需求,修改软件,增加更多的功能,使其比之前的软件功能、性能更高,更加完善。
预防性维护:对未来可能发生的bug进行预防性的修改。
知识点27.系统评价
系统的评价按照评价时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成立项评价、中期评价和结项评价。
对于系统评价的指标从以下几方面综合考虑,建立起一套指标体系理论框架。
(1)从信息系统的组成部分出发,所以可以按照运行效果和用户需求(人)、系统质量和技术条件(机)这两条线索构造指标。
(2)从信息系统的评价对象出发,对于开发方,他们所关心的是系统质量和技术水平;对于用户方,关心的是用户需求和运行质量;系统外部环境则主要通过社会效益指标来反映。
(3)从经济学角度出发,分别按系统成本、系统效益和财务指标3条线索建立指标。

夜雨聆风