01 2021 档案

摘要:#1~100的奇数和,偶数和'''sum = 0n = 99while n > 0: sum = sum + n n = n - 2print(sum)i=1sum=0while i<=100: if i%2==0: sum+=i i+=1 else: i+=1print(sum)'''#偶数sum 阅读全文
posted @ 2021-01-07 14:34 噫吁嚱。 阅读(107) 评论(0) 推荐(0)
摘要:输入输出:等甲类 边界之 输入域覆盖 输出域覆盖 条件组合:因果图 正交试验 判定法 过程处理: 流程分析 状态迁移 其他: 错误猜测 异常分析 阅读全文
posted @ 2021-01-04 09:19 噫吁嚱。 阅读(145) 评论(0) 推荐(0)
摘要:虽然在表面看来分阶段测试在成本和进度比不分阶段测试大,但实际测试分阶段进行原因是各个阶段都有它不同的关注点,这样可以尽早发现缺陷,不会导致因为局部缺陷导致全局瘫痪。 如果不分阶段,那么缺陷的放大效应导致修复成本将变的异常庞大,修复进度将不可预测。 除此之外分阶段测试因为分工明确也会很大程度上提高产品 阅读全文
posted @ 2021-01-04 09:18 噫吁嚱。 阅读(120) 评论(0) 推荐(0)
摘要:规模(size) 工作量(effort) 进度(schedule) 质量-缺陷(quality-defect) 阅读全文
posted @ 2021-01-04 09:16 噫吁嚱。 阅读(71) 评论(0) 推荐(0)
摘要:黑盒:被测对象当作一个黑盒子,参考与SRS,站在用户立场上进行测试,方便与功能测试、验收测试、易用性测试等。 白盒:玻璃盒,基与代码测试,参考与LLD,HLD在了解程序的内部数据结构和逻辑结构的基础上展开的更适合于单元测试、集成测试等。 阅读全文
posted @ 2021-01-04 09:14 噫吁嚱。 阅读(214) 评论(0) 推荐(0)
摘要:Plan 计划 (计划设计) Do 执行 (实施执行) Check 检查 (检查检测) Act 改进 (纠正措施) 阅读全文
posted @ 2021-01-04 09:13 噫吁嚱。 阅读(274) 评论(0) 推荐(0)
摘要:SQA和测试的关系: SQA从过程上保证软件质量 测试从技术上保证软件质量。 SQA的主要工作范围是什么? 保障制度体系顺利执行。 促进过程改进。 指导项目实施。 增强项目的可视度(进度、质量、过程)。 评审工作产品。 审核工作产品。(核心工作)。 协助问题解决。 提供决策支持。 缺陷预防(提高产品 阅读全文
posted @ 2021-01-04 09:11 噫吁嚱。 阅读(415) 评论(0) 推荐(0)
摘要:功能性 适合性 准确性 互操作性 保密安全性 功能性的依从性 可靠性 成熟性 容错性 易恢复性 可靠性的依从性 易用性 易理解性 易学性 易操作性 吸引性 易用性的依从性 效率 时间性 资源利用性 效率依从性 维护性 易分析性 易改变性 稳定性 易测试性 维护性的依从性 可移植性 适应性 易安装性 阅读全文
posted @ 2021-01-04 09:07 噫吁嚱。 阅读(129) 评论(0) 推荐(0)
摘要:流程:针对不同的需求选用不同的软件流程模型图。 技术:包括开发技术、测试技术以及美工工艺的技术。 组织:一组特性及特性之间的关系,它提供规定质量需求和评价质量的基础。 流程:从计划到策略的实现,流程就是按照这种思维方式指导软件开发的,并且流程来源于成功的经验,可以指导项目少走弯路,从而提高软件质量, 阅读全文
posted @ 2021-01-04 09:05 噫吁嚱。 阅读(634) 评论(0) 推荐(0)
摘要:符合需求的规格:符合开发者明确定义的目标,即产品是不是符合需求规格。 符合用户显示需求:符合用户所明确说明的目标。 符合用户实际需求:符合用户明确说明的和隐含的目标。 阅读全文
posted @ 2021-01-04 09:04 噫吁嚱。 阅读(390) 评论(0) 推荐(0)
摘要:缺陷引入的原因 : ⑴开发过程缺乏有效的沟通,或者没有进行沟通 ⑵ 软件复杂度越来越高 ⑶ 编程中产生错误 ⑷ 需求不断变更 ⑸ 项目进度的压力 ⑹ 不重视开发文档 ⑺ 软件开发工具本身隐藏的问题 阅读全文
posted @ 2021-01-04 09:03 噫吁嚱。 阅读(493) 评论(0) 推荐(0)
摘要:需求管理:对软件开发中的需求进行管理,包括需求分配、需求评审、建立需求基线、需求跟踪、变更控制。 配置管理:配置管理是通过对在软件生命周期的不同的时间点上的软件配置进行标识,并对这些被标识的软件配置项的更改进行系统控制,从而达到保证软件产品的完整性和可溯性的过程。 缺陷跟踪:对软件开发过程缺陷的发现 阅读全文
posted @ 2021-01-04 09:02 噫吁嚱。 阅读(85) 评论(0) 推荐(0)
摘要:瀑布模型:应用的最为广泛的一种模型,也是最容易理解和掌握的模型,然而它的缺陷也是显而易见的。 优点: – 强调开发的阶段性 – 强调早期计划及需求调查 – 强调产品测试 缺点: – 依赖于早期进行的需求调查,不能适应需求变化 – 由于是单一流程,开发中的经验教训不能应用于本产品过程 – 测试在后期才 阅读全文
posted @ 2021-01-04 09:01 噫吁嚱。 阅读(321) 评论(0) 推荐(0)
摘要:证明:证明软件的可用性 检测:发现软件中存在的错误 预防:管理软件的质量,可维护性能 阅读全文
posted @ 2021-01-04 08:59 噫吁嚱。 阅读(112) 评论(0) 推荐(0)
摘要:61、 usability testing 可用性测试 62、 backup testing 备份测试 63、 robustness testing 健壮性测试 64、 documentation testing 文档测试 65、 online help testing 在线帮助测试 66、 sta 阅读全文
posted @ 2021-01-04 08:58 噫吁嚱。 阅读(85) 评论(0) 推荐(0)
摘要:41、 validation 确认 42、 alpha testing α测试 43、 beta testing β测试 44、 top-down testing 自顶向下测试 45、 bottom-up testing 自底向上测试 46、 isolation testing 孤立测试 47、 a 阅读全文
posted @ 2021-01-04 08:57 噫吁嚱。 阅读(116) 评论(0) 推荐(0)
摘要:21、 Operability 易操作性 22、 Attractiveness 吸引性 23、 Time behavior 时间特性 24、 Resource utilization 资源利用性 25、 Efficiency compliance 效率依从性 26、 Analyzability 易分 阅读全文
posted @ 2021-01-04 08:54 噫吁嚱。 阅读(102) 评论(0) 推荐(0)
摘要:1、 Debug 调试 2、 Test case 测试用例 3、 Siral model 螺旋模型 4、 Software life cycle 软件生命周期 5、 Initial 初始级 6、 Repeatable 可重复级 7、 Defined 已定义级 8、 Managed 已管理级 9、 O 阅读全文
posted @ 2021-01-04 08:53 噫吁嚱。 阅读(115) 评论(0) 推荐(0)
摘要: 阅读全文
posted @ 2021-01-04 08:52 噫吁嚱。 阅读(43) 评论(0) 推荐(0)
摘要:1、 覆盖率概念: · 覆盖率是用来度量测试完整性的一个手段。覆盖率是测试技术有效性的一个度量。覆盖率=(至少被执行一次的item数)/item的总数; · 覆盖率大体可以划分为两大类:逻辑覆盖和功能覆盖; · 测试用例设计不能一味追求覆盖率,因为测试成本虽覆盖率的增加而增加。 2、 逻辑覆盖主要类 阅读全文
posted @ 2021-01-02 23:16 噫吁嚱。 阅读(224) 评论(0) 推荐(0)
摘要:2.1 计划阶段 明确what目标、why测试目的、when可控时间、where测试范围、how如何开展.主要活动有:参与开发人员软件需求的分析,SRS评审,通过后写ST计划,进行ST计划评审。 • 入口准则:SRS完成并确定需求规格基线 • 输入:SRS|SDP|SVVP • 出口准则:ST计划评 阅读全文
posted @ 2021-01-02 23:15 噫吁嚱。 阅读(110) 评论(0) 推荐(0)
摘要:1.11 备份测试(可靠) 恢复性测试的一个补充,验证软件或硬件失败中备份他数据的能力。 1.12 健壮性测试(可靠) Robustness Testing 用于测试系统在故障时,是否能够自动恢复或者忽略故障继续运行。 1.13 文档测试 Documentation Testing 测试文档的正确性 阅读全文
posted @ 2021-01-02 23:13 噫吁嚱。 阅读(118) 评论(0) 推荐(0)
摘要:• 定义: 容错性测试。通过人工干预手段产生异常,能检验系统的容错、恢复能力,是系统可靠性评价的重要手段。 • 异常处理 1.系统自动处理。 2.人工干预处理。 • 注意 1.系统的异常还与系统的指标测试有关,当系统的服务能力大于系统的设计指标时,也属于系统的异常情况。 2.系统的可靠性是设计出来的 阅读全文
posted @ 2021-01-02 23:11 噫吁嚱。 阅读(137) 评论(0) 推荐(0)
摘要:• 定义: 系统在各种软硬件配置、不同参数配置下系统具有的功能和性能。 • 目标: 验证全部配置的可操作性,有效性。 阅读全文
posted @ 2021-01-02 23:10 噫吁嚱。 阅读(227) 评论(0) 推荐(0)
摘要:• 定义: 根据软件测试特性列表、软件安装、配置文档,设计安装过程的测试用例,发现软件在安装过程中的错误。 • 被测对象: 1.软件本身。 2.软件安装文档。 1.8.1 安装测试前要检查的工作 1.安装文档是否齐全。 2.安装软件的程序文件是否齐全。 3.被测软件的安装文件是否齐全。 4.软件的安 阅读全文
posted @ 2021-01-02 23:08 噫吁嚱。 阅读(349) 评论(0) 推荐(0)
摘要:• 定义: Usability Testing--为检测用户在理解和使用系统方面到底有多好。 • 目标: 1.考虑产品是否符合实际应用情况。 2.是否符合用户习惯或特殊要求。 3.操作方式是否方便合理、设备和用户见交互信息是否准确易于理解、是否遵从行业习惯、外观/界面是否美观等。 • 一般关注的可用 阅读全文
posted @ 2021-01-02 23:07 噫吁嚱。 阅读(140) 评论(0) 推荐(0)
摘要:定义: Graphical User Interface Testing--针对软件系统的界面进行的测试。 • 目标: 1.界面实现与界面设计的吻合情况。(界面设计) 2.确认界面处理的正确性。(针对不同的控件分析) • 相关自动化测试工具 1.WinRunner 2.SilkTest 3.QaRu 阅读全文
posted @ 2021-01-02 23:06 噫吁嚱。 阅读(160) 评论(0) 推荐(0)
摘要:• 定义: Security Testing--验证集成在系统内的保护机制能否在实际应用中保护系统不受到非法的侵入。 • 目的: 保证系统安全性,数据的完整性、保密性。 1.5.1 数据 完整性 • 数据存储的完整性。 • 数据保密的完整性。 保密性 • 数据存储的保密性。 • 数据访问的保密性。 阅读全文
posted @ 2021-01-02 23:05 噫吁嚱。 阅读(197) 评论(0) 推荐(0)
摘要:• 定义: Stress Testing--系统在其资源超符合的情况下表现。 • 目标: 在极限或者恶劣的环境下,系统的自我保护能力。主要验证系统的可靠性。 • 实施: 1.同一时间,大量的用户登陆。 2.引入大量的操作。 • 目的: 1.是否存在内存泄露。 2.验证系统可靠性。 3.测试后给予用户 阅读全文
posted @ 2021-01-02 23:04 噫吁嚱。 阅读(420) 评论(0) 推荐(0)
摘要:• 定义: Performance Testing--测试该软件在集成系统中的运行性能。(大多使用工具测试) • 目标: 度量系统相对与预定义目标的差距。 • 实施: 1.性能指标定义明确。 2.构造性能测试研究数据。 3.构造不同的性能测试场景。 4.执行性能测试 (一般>90%就通过)。 5.性 阅读全文
posted @ 2021-01-02 23:03 噫吁嚱。 阅读(306) 评论(0) 推荐(0)
摘要:• 定义: function Testing--依据SRS和测试需求列表验证产品的功能是否实现和是否符合产品需求规格 • 目标: 1.是否有不正确或遗漏了的功能? 2.功能是实现是否满足用户需求,和系统设计的隐式需求? 3.输入能否正确接受?能否正确输出结果? 阅读全文
posted @ 2021-01-02 23:02 噫吁嚱。 阅读(87) 评论(0) 推荐(0)
摘要:•定义 System Testing--是将已经集成好的软件系统,作为整个计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际运行使用的环境下,对计算机系统进行系列的测试活动; •对象 1.产品级--软件+硬件 2.项目级--软件(也可能包含硬件) 阅读全文
posted @ 2021-01-01 23:46 噫吁嚱。 阅读(227) 评论(0) 推荐(0)
摘要:优点: A.底层组件得到较早验证 B.测试初期可以并行集成,效率高 C.由于驱动模块是额外编写的,对被测模块的可测试性要求较低 D.减少了开发桩的工作量 E.定位问题容易,支持故障隔离 缺点: A.需要开发大量的驱动,工作量、成本同样很高 B.对高层的验证太晚了,设计上的缺陷不能被及早发现 C.集成 阅读全文
posted @ 2021-01-01 23:44 噫吁嚱。 阅读(127) 评论(0) 推荐(0)
摘要:子策略: • 深度优先(Depth-First) • 广度优先(Broadth-First) 优点: A.主控模块(高层组件)得到较早验证 B.深度优先策略能够较早验证一个完整的功能,增强了开发信心 C.基本不需要开发驱动,减少了这部分的工作量 D.和高层设计顺序一致,方便并行开展 E.定位问题容易 阅读全文
posted @ 2021-01-01 23:43 噫吁嚱。 阅读(157) 评论(0) 推荐(0)
摘要:优点:方法简单、效率高 缺点: • "急于求成",成功率不高 • "大海捞针",导致即使发现问题也难以定位(无法故障隔离) • "囫囵吞枣",许多内部接口的错误被漏测 适用范围: • 小项目、维护型项目 • 软件结构不清晰的系统 阅读全文
posted @ 2021-01-01 23:41 噫吁嚱。 阅读(102) 评论(0) 推荐(0)
摘要:1 测试过程的制定 1.1 计划 根据SVVP制定ITP 1.2 设计 根据ITP制定IT方案 1.3 实现 根据IT方案制定IT用例 1.4 执行 根据IT用例进行集成测试,提交Bug Report,……,回归测试 0.2 采用的测试方法 0.3 灰盒测试 随集成层次不同,灰度随之相应变化 0.4 阅读全文
posted @ 2021-01-01 23:39 噫吁嚱。 阅读(307) 评论(0) 推荐(0)
摘要:• 子系统间集成(系统内集成) • 模块间集成(子系统内集成) • 函数间集成(模块内集成) 阅读全文
posted @ 2021-01-01 23:38 噫吁嚱。 阅读(88) 评论(0) 推荐(0)
摘要:集成测试所处的测试过程: A.测试准备活动在开发活动时可以并行开展,如开始做HLD设计时就可以开始做ITP了 B.测试执行活动在单元测试的基础上进行 阅读全文
posted @ 2021-01-01 23:36 噫吁嚱。 阅读(309) 评论(0) 推荐(0)
摘要:• 开发人员做 A优势:一般来说,编程能力稍强 B劣势:Protect(就像变形金刚的汽车人),心理上不愿意否定自己的劳动成果,职责是保护程序 • 测试人员做 A优势:Destroy(就像变形金刚的霸天虎),心理上追求完美,职责是挑刺、破坏程序 B劣势:目前的现状,大部分tester编程能力不够 阅读全文
posted @ 2021-01-01 23:34 噫吁嚱。 阅读(344) 评论(0) 推荐(0)
摘要:一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。 • 程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。 • 虽然已经有了IT和ST,但IT和UT、ST关注点不一样,它们互为补充 • 反分解性公理:为一个被测模块获得的覆盖并不能覆盖他所调用的模块。 • 反组合性 阅读全文
posted @ 2021-01-01 23:32 噫吁嚱。 阅读(266) 评论(0) 推荐(0)
摘要:集成测试(Integration Testing) 集成测试也叫组装测试、联合测试、部件测试、子系统测试 • 集成测试测什么 1.外部接口:各件结合在一起后表现的功能 2.内部接口:各件间的接口是否正确Ä • 集成测试的目的 验证软件的组件对概要设计说明书的符合度 • 集成测试的评估基准: 接口覆盖 阅读全文
posted @ 2021-01-01 23:30 噫吁嚱。 阅读(482) 评论(0) 推荐(0)
摘要:测试计划: 完成单元测试计划; 测试设计:完成单元测试方案; 测试实现:完成单元测试用例、单元测试规程、单元测试脚本及数据文件; 测试执行:执行单元测试用例,修改发现的问题并进行回归测试,提交单元测试报告。 阅读全文
posted @ 2021-01-01 23:29 噫吁嚱。 阅读(179) 评论(0) 推荐(0)
摘要:方法:先对模块调用层次图上最低层的模块进行单元测试,模拟调用该模块的模块做驱动模块。然后再对上面一层做单元测试,用下面已被测试过的模块做桩模块。以此类推,直到测试完所有模块。 · 优点:可以节省桩函数的开发工作量,测试效率较高。 · 缺点:不是纯粹的单元测试,底层函数的测试质量对上层函数的测试将产生 阅读全文
posted @ 2021-01-01 23:27 噫吁嚱。 阅读(141) 评论(0) 推荐(0)
摘要:方法:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块。其次对第二层进行测试,使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。 · 优点:可以节省驱动函数的开发工作量,测试效率较高。 · 缺点:随着被测单元一个一个被加入,测试过程将变得越来越复杂,并且开发和维护的成本将增加。 阅读全文
posted @ 2021-01-01 23:25 噫吁嚱。 阅读(131) 评论(0) 推荐(0)
摘要:方法:不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和 驱动模块。每个模块进行独立的单元测试。 · 优点:该方法是最简单,最容易操作的。可以达到高的结构覆盖率。该方法是纯粹的单元测试。 · 缺点:桩函数和驱动函数工作量很大,效率低。 阅读全文
posted @ 2021-01-01 23:24 噫吁嚱。 阅读(131) 评论(0) 推荐(0)
摘要:在于发现各模块内部可能存在的各种错误主要是基于白盒测试。 · 验证代码是与设计相符合的;· 发现设计和需求中存在的错误; · 发现在编码过程中引入的错误。(和设计不相符 / 和设计相符,但是由于编码疏漏引起) 单元测试的常见错误:1.单元接口 2.局部数据结构 3.独立路径 4.出错处理 5.边界条 阅读全文
posted @ 2021-01-01 23:23 噫吁嚱。 阅读(75) 评论(0) 推荐(0)
摘要:控制流相关概念:程序元素、控制流关系、控制流图、控制流矩阵。 控制流分析能发现的问题:转向并不存在的标号;没有用的语句标号;从程序 入口进入后无法达到的语句;不能达到停机语句的语句。 数据流相关概念:数据的定义;数据的引用。 数据流分析的左右:分析代码中关于数据定义和引用方面的错误;进行代码优化。( 阅读全文
posted @ 2021-01-01 23:21 噫吁嚱。 阅读(430) 评论(0) 推荐(0)
摘要:测试人员需要了解软件的实现; 可以检测代码中的每条分支和路径; 解释隐藏在代码中的错误; 对代码的测试比较彻底; 实现代码结构上的优化; 白盒测试投入较大,成本高; 白盒测试不验证规格的正确性。 阅读全文
posted @ 2021-01-01 23:20 噫吁嚱。 阅读(371) 评论(0) 推荐(0)
摘要:1、 什么是白盒测试: · 白盒测试是依据被测软件分析程序内部构造,并根据内部构造设计用例,来对内部控制流程进行测试,可完全不顾程序的整体功能实现情况; · 白盒测试是基于程序结构的逻辑驱动测试; · 白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试。 2、 为什么进 阅读全文
posted @ 2021-01-01 23:19 噫吁嚱。 阅读(227) 评论(0) 推荐(0)
摘要:黑盒测试的优点:·对于更大的代码单元来说(子系统甚至系统级)比白 盒测试效率要高;· 测试人员不需要了解实现的细节, 包括特定的编程语言;· 从用户的视角进行测试,很容 易被大家理解和接受;· 有助于暴露任何规格不一致或 有歧义的问题。 黑盒测试的缺点:· 没有清晰的和简明的规格,测试用例是很难设计 阅读全文
posted @ 2021-01-01 23:17 噫吁嚱。 阅读(640) 评论(0) 推荐(0)
摘要:黑盒测试把被测对象看成一个黑盒,只考虑其整体特性,不考虑其内部具体实现; 黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等。 黑盒测试又可以被称为基于规格的测试。 阅读全文
posted @ 2021-01-01 23:16 噫吁嚱。 阅读(309) 评论(0) 推荐(0)
摘要:软件质量保证(SQA)和测试: SQA从流程方面保证软件的质量、测试从技术方面保证软件的质量、只进行SQA或者只进行测试活动不一定能产生好的软件质量。 SQA的主要工作范围: 1.保障制度体系。2.促进过程改进。3.指导项目实施。4.增加透明度。5.评审项目活动。6.审核工作产品。7.协助解决问题。 阅读全文
posted @ 2021-01-01 23:13 噫吁嚱。 阅读(119) 评论(0) 推荐(0)
摘要:功能性:当软件在指定条件下使用时,软件产品提供满足明确和隐含需求的功能的能力。包括:适合性;准确性;互操作性;保密安全性;功能性的依从性。 可靠性:在指定条件下使用时,软件产品维持规定的性能级别的能力。包括:成熟性;容错性;易恢复性;可靠性的依从性。 易用性:在指定条件下使用时,软件产品被理解、学习 阅读全文
posted @ 2021-01-01 23:09 噫吁嚱。 阅读(123) 评论(0) 推荐(0)
摘要:检视代码,评审开发文档; 进行测试设计,写作测试文档(测试计划、测试方案、测试用例等); 执行测试,发现软件缺陷,提交缺陷报告,并确认缺陷最终得到了修正; 通过测试度量软件质量 阅读全文
posted @ 2021-01-01 23:08 噫吁嚱。 阅读(359) 评论(0) 推荐(0)