zoukankan      html  css  js  c++  java
  • 【软件构造】课程提纲(5)

    第七章

    1. 健壮性和正确性

    (1)健壮性:处理各类情况的能力

    (2)正确性:正确实现规格说明的能力

    (3)测量:平均故障间隔时间(MTBF)、残余缺陷率(软件发布后留下的bug

    2. Throwable:有两个子类,即errorexception

    (1)error:程序无法处理的错误,通常是JVM的问题,不需要catch

      ·处理策略:预先阻止、错误中恢复、优雅地退出

      ·处理方式

        - 返回中立值

        - 替换下一个有效数据

        - 返回与前一次相同的答案

        - 代替最接近的法律价值

        - 将警告消息记录到文件

        - 返回错误代码:设置状态值 -> 返回状态值 -> 利用异常机制

        - 调用一个错误处理例程/对象

        - 显示错误信息

        - 在本地处理错误

        - 关掉程序

    2exception:程序自身可以处理,代码可以通过异常机制将错误或异常事件传递给调用它的代码,Java无法以正常方式完成其任务时允许每种方法都有一个替代退出路径

    3. Runtime 异常、其他异常

    (1)Runtime异常:程序员自己的错误,如空指针、数组越界、类型转换等

    (2)其他异常:通常为IOE异常,即找不到文件路径等

    4. Checked 异常、Unchecked 异常

    (1)Checked 异常:每个调用者都应知道并处理的错误

      ·处理机制

        - 抛出:声明是throws,抛出时throw

        - 捕获(try/catch):try出现异常,忽略后面代码直接进入catch;无异常不进入catch;若catch中没有匹配的异常处理,程序退出;若子类重写了父类方法,父类方法没有抛出异常,子类应自己处理全部异常而不再传播;子类从父类继承的方法不能增加或更改异常

        - 处理:不能代替简单的测试,尽量苛刻、不过分细化、将正常处理与异常处理分开、利用好层次结构、早抛出晚捕获、避免不必要的检查

        - 清理现场、释放资源(finally):finally中语句不论有无异常都执行

    2Unchecked 异常:JVM抛出,如空指针、数组越界、数据格式、不合法的参数、不合法的状态、找不到类等

    5. 自定义异常类:继承自Exception,在构造函数中可通过super(key)修改默认值

    6. 断言

    1)作用:允许程序在运行时检查自己,测试有关程序逻辑的假设,如前置条件、后置条件、不变量等,可将黑盒测试转换为白盒测试

    2)应用场合

      ·输入/输出参数落在预期范围内

      ·程序运行/结束时文件流的打开和关闭

      ·程序开始(结束)时文件处于开始(结束)

      ·文件流以只读、只写或读写方式打开

      ·输入变量的值不被方法改变

      ·判断指针不是空值

      ·判断数据结构是否是指定长度

      ·判断真值表是否初始化

      ·当一个方法开始执行时(或完成时)容器是空的(或满的)

      ·高度优化的复杂方法的结果与较慢但清晰编写的例程的结果相匹配

    3)注意

      ·编译时加入-ea选项运行断言,-da关闭断言

      ·条件语句或开关没有涵盖所有可能的情况,最好使用断言来阻止非法事件

      ·可以在预计正常情况下程序不会到达的地方放置断言:assert false

      ·在开发和调试阶段设置断言,在软件发布时禁止断言

      ·断言有代价,需慎用,一般用于验证正确性,处理绝不应该发生的情况

      ·不能作为公共方法的检查,也不能有边界效应

    7. 调试(Debugging

    1)进攻式编程:在开发阶段让异常显现出来,而在产品运行时让其自我恢复

      ·产品版与开发版:开发版只要开发顺利可以放肆一些,产品版必须克制

      ·做好计划,避免调试代码和程序代码纠缠不清

      ·使用存根例程

      ·开发中希望错误尽可能明显,发布后希望错误尽可能不明显

      ·确定程序的哪些部分能够承受未检测出错误而造成的后果,哪些不能,如果后果微不足道,可通过make或版本控制删除检测代码(不是物理删除)

      ·如果您的程序包含检测潜在致命错误的调试代码,可将代码保留在其中,以使程序稳妥地崩溃

      ·考虑在产品代码中留下调试代码,但改变他们的行为,以便适合生产版本

    (2)Bug的状态

      ·被发现提出(New-> 被审核批准(Open-> 被分配给开发者(Assign-> 被解决/修正/测试(Resolved/Fixed/Test-> 重新测试(Retest-> 通过测试(Verified-> 修复后仍存在问题(Reopen-> 成功修复(close

      ·若bug优先级低,推迟到下一个版本,有时可能需要无限推迟

      ·如果开发人员认为系统的特定行为(测试人员报告为错误的行为)必须相同,并且错误无效,那么该错误将被拒绝并标记为“等待拒绝”

      ·如果bug无法通过QA的报告中给出的步骤重现,则开发人员可以将该错误标记为“CNR”, QA需要采取措施来检查是否重现了bug,并且可以向开发人员分配详细的重现步骤

    (3)基本过程:重现问题 -> 找到原因(95%-> 进行修正 -> 反思

    (4)方法

      ·重现问题 

        - 找到一个产生失败的小的可重复测试用例(保持复现bug的前提下降低输入规模)

        - 消除因版本、环境、配置等不同引起的差异(通过构建软件实现),确定bug出现的环境(通过程序模拟硬件平台的细节,实现不同的操作系统环境)

        - 利用逆向设计推断导致错误的输入

        - 若无法重现,则无法观察以证明分析和修补的正确性

      ·诊断错误(插桩、分治、VCS、寻找特例、学习他人)

        - 从假设开始,构造实验,证明它是对的或者错的

        - 从不符合理论的观察结果开始,修正理论

        - 查看导致错误的测试输入,以及错误的结果,失败的断言以及由此导致的堆栈跟踪

        - 提出一个与所有数据一致的假设,说明错误发生的位置或错误发生的位置,设计实验测试假设

        - 收集实验数据,减少错误可能出现的范围,做出新的假设

        - 设计不同的实验:检查内部状态、修改运行方式、改变本身逻辑

        - 每次只做一个修改、做好记录、不忽略细节、运行不同的测试用例、设置断点、用可实现相同功能并且被证实无问题的组件替代当前组件 

      ·修复bug

        - 确保从干净的源代码树开始

        - 运行现有的测试,并证明它们通过

        - 添加一个或多个新测试,或修复现有测试,以演示错误

        - 修复错误、发现可改进之处

        - 证明你的修复工作正常且没有引入回归(以前通过的测试现在失败)

        - 如果引入回归,通过回顾以前的版本来找出确切的变化

    (4)调试工具

      ·语法和逻辑检查

      ·源代码比较器

      ·内存堆转储

      ·打印调试/记录

      ·堆栈跟踪

      ·编译器警告消息

      ·调试器

      ·执行分析器

      ·测试框架

    8. 黑盒测试用例的设计

    (1)黑盒测试:在没有任何内部实现知识的情况下检查功能,而无需查看源代码

    (2)测试用例:围绕规范和要求构建,一般来自软件的外部描述,包括规范,要求和设计参数,主要是功能性的

    (3)等价类划分:将程序的输入域划分为可导出测试用例的数据类

      ·若一组对象自反、对称、传递,则为等价类

      ·可产生相似结果的输入集合中的一个可代替整个集合

      ·同理,对输出也可以划分等价类

      ·两个极端:每个分区只有一个测试用例,覆盖所有分区

    (4)边界值分析:错误通常隐藏在边界中,如一位偏移、边界值需单独处理等

    9. 以注释的形式撰写测试策略

    (1)在测试类的顶端写策略

       

    (2)在每个测试方法前说明测试用例是如何选择的

       

    10. JUnit 测试用例写法

    (1)@Before:每个测试方法前执行一次

    (2)@After:每个测试方法后执行一次

    (3)@Test:表明测试方法,内含Assert语句

      ·@Test(expected=*.class):对错误的测试,expected的属性值是一个异常

      ·@Test(timeout=xxx):测试方法在制定的时间之内没有运行完则失败

    (4)@ignore:忽略测试方法

    11. 测试覆盖度

    (1)通常无法完全覆盖,因此只需尽量提高

    (2)代码覆盖率高的程序在测试期间执行了更多的源代码,与低代码覆盖率的程序相比,包含未检测到的软件错误的可能性较低

    (3)基本覆盖标准:函数、语句、决策或分支、条件或谓词、路径

    (4)覆盖强度:路径 > 分支 > 语句

  • 相关阅读:
    在maven工程指定java版本并指定编码格式
    Spring boot 静态资源访问
    Spring Boot 11 : Redis
    Java 计算均值
    Spring Boot 12 : AOP
    Spring Boot 11 : 配置文件读取
    Java文本标签处理
    Spring Boot 10:处理Json数据中的null值
    Spring Cloud 7:Gateway
    Spring Cloud 6:服务消费
  • 原文地址:https://www.cnblogs.com/zhangyushuqing/p/9175278.html
Copyright © 2011-2022 走看看