首页 > 其他 > 详细

测试与优化

时间:2018-09-27 22:40:36      阅读:198      评论:0      收藏:0      [点我收藏+]

学号1:211606367 姓名:林恩 学号2:211606445 姓名:肖志豪

一、预估与实际

PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 30 30
? Estimate ? 估计这个任务需要多少时间 30 30
Development 开发 690 650
? Analysis ? 需求分析 (包括学习新技术) 70 50
? Design Spec ? 生成设计文档 50 70
? Design Review ? 设计复审 20 30
? Coding Standard ? 代码规范 (为目前的开发制定合适的规范) 30 20
? Design ? 具体设计 185 185
? Coding ? 具体编码 185 185
? Code Review ? 代码复审 30 30
? Test ? 测试(自我测试,修改代码,提交修改) 120 120
Reporting 报告 60 50
? Test Repor ? 测试报告 30 30
? Size Measurement ? 计算工作量 10 10
? Postmortem & Process Improvement Plan ? 事后总结, 并提出过程改进计划 10 20
合计 780 730

二、需求分析

需要了解Junit如何使用以及相关要求:

测试要求

  • 测试方法上必须使用@Test进行修饰
  • 测试方法必须使用public void进行修饰,不能带任何参数
  • 新建一个源代码目录来存放我们的测试代码
  • 测试类的包应该和被测试类保持一致
  • 测试单元中的每个方法必须可以独立测试,测试方法间不能有任何的依赖
  • 测试类使用Test作为类名的后缀(不是必须的)
  • 测试方法使用test作为方法名的前缀(不是必须的)

测试失败的两种情况

  • Failure一般由单元测试使用的断言方法判断失败所引起的,这经表示测试点发现了问题,就是说程序输出的结果和我们预期的不一样
  • error是由代码异常引起的,他可以产生于测试代码本身的错误,也可以是被测试代码中的一个隐藏的bug
  • 测试用例不是用来证明你是对的,而是用来证明你没有错

执行顺序

@BeforeClass - @Before - @Test - @After - @AfterClass

@BeforeClass:它会在所有方法运行前被执行,static修饰

@Before:会在每一个测试方法被运行前执行一次

@Test:将一个普通的方法修饰成为一个测试方法

xx.class为捕获异常类

@Test(expected = xx.class)

@Test(timeout = 毫秒)

@Ignore:所修饰的测试方法会被测试运行器忽略

@RunWith:可以更改测试运行器 org.junit.runner.Runner

@After:会在每一个测试方法运行后被执行一次

@AfterClass:它会在所有方法运行结束后被执行,static修饰

  • @BeforeClass修饰的方法会在所有方法被调用前被执行
  • 而且该方法是静态的,所以当测试类被加载后接着就会运行它
  • 而且在内存中它只会存在一份实例,他比较适合加载配置文件
  • @AfterClass所修饰的方法通常用来对资源的清理,如关闭数据库的连接
  • @Before@After会在每个测试方法的前后各执行一次
  • @Before@After会在每个测试方法的前后各执行一次
  • @Before@After会在每个测试方法的前后各执行一次

测试套件(批量执行测试用例)

测试套件就是组织测试类一起运行的

写一个作为测试套件的入口类,这个类里不包含其他的方法

更改测试运行suit.class

将要测试的类作为数组传入Suite.SuiteClasses({})

@RunWith(Suite.class)

@Suite.SuiteClasses({TaskTest1.class,TaskTest2.class,TaskTest3.class})

Junit参数化测试

更改默认的测试运行器为RunWith(Parameterized.class)

声明变量来存放预期值和结果值

声明一个返回值为Collection的公共静态方法,并使用@Parameters进行修饰

为测试类声明一个带有参数的公共构造函数,并在其中为之声明变量赋值

三、设计

1. 设计思路

说明你如何设计这个程序

设计单元测试的思路

  • assertEquals()和assertRaises(),比对方法返回值和逻辑值的差别,来检验方法的是否执行有效成功
  • 若是有的方法没有返回值,则先实例化,然后比对方法中的值和逻辑值的差别也是可以的
  • 有些需要赋予某些其它的初始值

单元测试

  • 部分单元测试代码

请展示一段程序的关键代码,并解释代码的作用

    @Test
    public void testMain() {
        String[] args = {"-n", "100", "-grade", "3"};
        MathExam math = new MathExam();
        math.main(args);
        assertEquals(true, math.output_boolean);
    }

测试方法上有@Test才会进行测试运算。先实例化,然后传参,math.output_boolean初值为false,执行完代码后math.output_boolean会赋值为true,代表执行完成。这时候只需要判断下值是否为true,即可代表main()是否执行成功。

要对各种可能的值进行测试,确保能够实现方法的各种可能

  • 单元测试得到的测试覆盖率截图

    技术分享图片

结构优化

  • UML类图:

技术分享图片

  • 程序运行流程图
    技术分享图片

程序做出重构的部分,与重构的原因

  • 重构了关于两个数字的计算与判断,在原先代码里关于数字的计算判断大量重复,所以我将它生成为一个方法类与生成式子的类合并
  • 将生成式子的类从原先类中提取出,专门生成个类来生成式子以及判断,为了让每个类的模块与功能都更加精准、

重构后每个模块的功能

  • MathExam类(主类,自身负责生成和写入文件,以及调用其它方法类来生成式子)
  • Two_Numbers类(负责生成一年级和二年级式子以及子式判重,防止生成重复的式子包括子式,在生成三年级式子时调用Calculation类)
  • Calculation类(负责三年级式子,转成中缀表达式以及后缀表达式求和)

性能调优

  • 贴出优化前效能分析工具的结果截图

技术分享图片

  • 描述程序的性能瓶颈
    • 在代码中存在着大量的重复代码,有些代码冗余无法行之有效实现功能
  • 给出优化方案
    • 进行了一定量的代码缩减提取,删减某些无用或者重复的代码
  • 贴出优化后效能分析工具的结果截图

技术分享图片

2. 实现方案 写出具体实现的步骤

分为三个步骤:

单元测试

  • 针对程序架构,进行单元测试,确保每个模块能够达到预期的要求

结构优化

  • 把具有相似功能的代码封装在一起
  • 思考代码应该怎么进行结构优化
  • 每当代码的一个模块完成了重构,就需要commit
  • 为了保证每次重构后代码的正确性,我们需要先进行回归测试,再commit代码

性能调优

  • 测试并改进程序生成四则运算算式的效率
  • 帮我们分析找到代码中执行效率最差,也就是所谓 效能瓶颈 的部分。就可以把精力花费在改进瓶颈上,从而高效快速地提升程序性能

四、编码

调试日志

记录编码调试的日志,请记录下开发过程中的 debug 历程
比如:

  • 在代码的什么位置,代码出现了什么问题,问题会导致什么结果,怎么解决的
    • 在调试代码时,一旦更改代码,也需要在测试代码处进行及时的相对应更改
    • 对参数的传递方式,有两种,值传递和引用传递,在方法传递的参数中是值传递,更改子方法中的的值是不会修改到父方法相对应的值
  • 请说明你如何按照设计思路进行编码,并记录你在开发中遇到的问题,与解决过程

    • 在写测试时,查找到有两种方法assertEquals()和assertRaises()。了解到这两种方法各自作用,通过比较object判断不同来返回测试结果,如果相同,测试通过;反之,不通过。这对方法的模块化程度有着一定的要求。后来我想了些方法,不必通过一定要有方法返回值来判断。因为实现方法后,方法内的某些参数必然改变,这时候只要检验到这个方法的应该实现的内容达到逻辑上的值即可。
    • 需要对代码的命名,意义,规范有着很深的认识,毕竟不仅仅是自己一个人在编程,需要让其他人看懂读懂,了解代码。也方便自己后期阅读,修改,重构。

    • 关于计算机题目查重特点,总结了几个:

      • 题目完全相同

      • 题目不同,但是顺序式子顺序不同,只是改变了形式,其实实质是相同的,结果相同
      • 比如a + b和b +a,a x b和b x a,
      • 最终决定在生成式子时,加上一个采集子式的集合用来判断子式是否重复

测试与优化

原文:https://www.cnblogs.com/mumuyinxin/p/9716045.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!