-
软件测试的原则包括:
- 对象:程序、数据和文档
(1)所有的软件测试都应该追溯到用户需求。
(2)尽早地和不断地进行软件测试。穷举测试是不可能的,测试需要终止 ,但测试时间不足不应作为停止测试的依据。
(3)应由不同的测试人员对测试所发现的缺陷进行确认。
(4)测试无法显示软件潜在的缺陷。
(5)充分注意测试中的集群现象。
(6)程序员应避免检查自己的程序。
(7)尽量避免测试的随意性。一般情况下测试应采用增量测试,由小到大。
(8)测试是一项协同完成的创造性的工作。
-
测试执行过程阶段:
- 初测期——测试主要功能和关键的执行路径,排除主要障碍。
- 细测期——依据测试计划和测试用例,逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等;预期可发现大量不同性质、不同严重程度的错误和问题。
- 回归测试期——系统已达到稳定,在一轮测试中发现的错误已十分有限;复查已知错误的纠正情况,未引发任何新的错误时,终结回归测试。
-
测试用例应该包含的重要信息:标识符、测试项、输入说明、输出说明、环境要求、特殊过程要求、用例之间的依赖性。不包括实际输出
-
《软件工程产品质量》统一了多种质量模型。软件使用质量描述
(A) 它测量用户在特定环境中能达到其目标的程度,不是测量软件自身的属性
(B) 使用质量的属性分为四个特性:有效性,生产率,安全性和满意度
(D) 使用质量的获得依赖于取得必需的外部质量,而外部质量的获得则依赖于取得必需的内部质量
-
对需求说明书评测的内容:
①系统定义的目标是否与用户的要求一致
②被开发项目的数据流与数据结构是否足够、确定
③与所有其他系统交互的重要接口是否都已经描述
④主要功能是否已包含在规定的软件范围之内,是否都已充分说明
-
加密和解密:
RSA:最为常见的非对称加密算法,512位密钥(或1024位密钥)、计算量极大、难破解。
DES:是应用最为广泛的一种对称加密算法,它的密钥长度为56位,每次运算对64位数据块进行加密,该算法运行速度快、密钥易产生。
SHA:是一种常用的消息摘要算法,它的散列值分别为128和160位,由于SHA通常采用的密钥长度较长,因此安全性较高。
AES:是一种典型的对称加密算法,它采用了可变长的密钥体制。
-
软件可能出现的问题:
软件错误(error):是指在软件生命周期内的不希望或不可接受的人为错误,其结果将导致软件缺陷的产生。
软件缺陷(defect):是存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差,其结果是软件运行于某一特定条件时,将出现软件故障。
软件故障(fault):是指软件运行过程中出现的一种不希望或不可接受的内部状态。故障是一种状态行为,是指一个实体发生障碍和毛病。没有补救措施,可能产生软件失效。
软件失效(failure):是指软件运行时产生的一种不希望或不可接受的外部行为结果。软件失效时系统行为对用户要求的偏离,是一种面向用户的概念。软件的失效在整个计算机系统失效中的比例比较高;
-
法律法规:
- 合理使用是指可以不经著作权人许可,不需支付报酬,使用其作品;
- 许可使用是指在获得著作权人许可后使用其作品;
- 强制许可使用也称为强制许可或非自愿许可,是指国务院专利行政部门依照法律规定,可以不经专利权人的同意,直接允许申请人实施专利权人的发明或实用新型专利的一种行政措施;
- 法定许可使用是指法律明文规定,可以不经著作权人许可,以特定的方式有偿使用他人已经发表的作品的行为,并且这种使用应当尊重著作权人的其他各项人身权和财产权。
- 著作权保护对象:计算机程序及其文档。
-
专利法意义上的发明人必须是:
- 第一,直接参加发明创造活动。在发明创造过程中,只负责组织管理工作或者是对物质条件的利用提供方便的人,不应当被认为是发明人;
- 第二,必须是对发明创造的实质性特点作出创造性贡献的人。仅仅提出发明所要解决的问题而未对如何解决该问题提出具体意见的,或者仅仅从事辅助工作的人,不视为发明人或者设计人。有了发明创造不一定就能成为专利权人。
- 第三,发明人或设计人是否能够就其技术成果申请专利,还取决于该发明创造与其职务工作的关系。一项发明创造若被认定为职务发明创造,那么该项发明创造申请并获得专利的权利为该发明人或者设计人所属单位所有。如果没有书面合同or合同未作明确约定的,其著作权由创作方享有。
-
根据专利法规定,职务发明创造分为两种情形:一是执行本单位的任务所完成的发明创造,二是主要是利用本单位的物质技术条件所完成的发明创造。
- 《专利法实施细则》对“执行本单位的任务所完成的发明创造”和“本单位的物质技术条件”又分别作出了解释。所谓执行本单位的任务所完成的发明创造是指:①在本职工作中作出的发明创造;②履行本单位交付的本职工作之外的任务所作出的发明创造;③退职、退休或者调动工作后一年内所作出的,与其在原单位承担的本职工作或原单位分配的任务有关的发明创造。职务发明创造的专利申请权属于发明人所在的单位,但发明人或者设计人仍依法享有发明人身份权和获得奖励报酬的权利。
-
需求的特征包括完整性、正确性、可行性、可验证性等。
- 完整性指需求的描述清楚完整,包括了设计和实现的所有必要信息;
- 正确性指每一项需求都必须准确地陈述要开发的功能;
- 可行性指每一项需求必须是在已知系统和环境的权能和限制范围内可以实施的;
- 可验证性指检查每项需求是否能通过设计测试用例或其他的验证方法来确定产品是否确实按需求实现了。如果需求不可验证,则确定其实施是否正确就成为主观臆断,而非客观分析了。一份前后矛盾,不可行或有二义性的需求也是不可验证的。
-
模块之间的耦合有七种类型,根据耦合性从低到高为非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合和内容耦合。
- 如果一个模块访问另一个模块时,彼此之间是通过数据参数(不是控制参数、 公共数据结构或外部变量)来交换输入、输出信息的,则称这种耦合为数据耦合;
- 如果一组模块通过数据结构本身传递,则称这种耦合为标记耦合;
- 控制耦合:两个模块彼此间传递的信息中有控制信息。
- 外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息。
- 若一组模块都访问同一个公共数据环境,则它们之间的耦合就称为公共耦合;
- 若一个模块直接访问另一个模块的内部数据、一个模块不通过正常入口转到另一个模块内部、两个模块有一部分程序代码重叠或者一个模块有多个入口,上述几个情形之一发生则两个模块之间就发生了内容耦合。(一个模块需要涉及到另一个模块的内部信息)
-
逻辑覆盖法:语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件-组合覆盖、路径覆盖、修正条件覆盖
- 语句覆盖(SC):使被测试程序中每条语句至少执行一次
- 判定覆盖(DC,分支覆盖):使程序中每个判定至少都获得一次“1”或“0”
- 条件覆盖(CC):使得判定中每个条件获得各种可能的结果,即条件至少一次“1“和”0“
- 判定-条件覆盖:使得判定中每个条件的所有可能(0/1)至少出现一次,并且每个判定版本的结果(0/1)也至少出现一次
- 条件-组合覆盖(覆盖准则最强):使得被测程序中每个判定中条件结果的所有可能组合至少执行一次
-
类之间的关系从宏观上可以分为关联、依赖、继承,而其中关联又有两种特例:聚合和组合软件维护一般包括正确性维护、适应性维护、完善性维护和预防性维护。

-
维护:
- 正确性维护是指改正在系统开发阶段已经发生而在系统测试阶段尚未发生的错误。
- 适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
- 完善性维护为扩充功能和改善性能而进行的修改。
- 预防性维护是为了改进应用软件的可靠性和可维护性,为了适应未来的软硬件环境的编号,主动增加预防性的新的功能,以使应用系统适应各类变化而不被淘汰。
-
瀑布模型、原型模型、V模型、螺旋模型、喷泉模型、W模型、H模型
- 瀑布:适用于需求明确的开发,没有明确说明早期测试,项目失败风险低。
- 原型:需求不确定、且动态变化
- V模型:瀑布模型基础上细化了测试,测试在编程后“线性”进行
- 螺旋:瀑布+原型,适合大型项目的开发
- 喷泉:面向对象技术进行开发
- W模型:强调双V原理,将开发和测试过程独立开来,测试伴随整个开发周期
- H模型:将测试活动完全独立,测试与其他流程并发的进行
- X模型:试图引导项目的全部测试
-
单元测试、集成测试、系统测试、确认测试和验收测试
- 单元测试是针对软件程序模块进行正确性检验的测试工作;
- 内容:模块接口测试;局部数据结构测试;路径测试;错误处理测试;边界测试。
- 集成测试是检验程序单元或部件的接口关系,即针对软件体系结构的构造进行的测试;
- 集成测试的集成方式包括:一次性集成、自底向上、自顶向下、混合式
- 系统测试是为验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试;
- 确认测试是检验与证实软件是否满足软件需求说明书中规定的要求;
- 验收测试是按照项目任务书或合同、约定的验收依据文档等进行的整个系统的测试与评审,决定是否接收或拒收系统。
-
功能基线、分配基线、产品基线
- 功能基线指在系统分析与软件定义阶段结束时,在经过正式评审和批准的系统设计规格说明书中对开发系统的规格说明,功能基线是最初批准的功能配置标识。
- 分配基线指在软件需求分析阶段结束时,经过正式评审和批准的软件需求规格说明。分配基线是最初批准的分配配置标识;
- 产品基线指在软件组装与系统测试阶段结束时,经过正式评审和批准的有关软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。
-
负载测试、压力测试
-
对称加密和非对称加密(记住非对称得了)