单元测试

软件=程序+软件工程 （程序=数据结构+算法） 软件工程的核心：构建管理、源代码管理、软件设计、软件测试、项目管理。 结合企业得到的推论：软件企业=软件+商业模式。 软件工程包括的领域：软件需求分析、软件设计、软件构建、软件测试和软件维护。 软件的特殊性：复杂性、不可见性、易变性、服从性、非连续性。 软件工程的目标——创造“足够好”的软件，即包括用户的满意度、可靠性、软件流程的质量、可维护性。 什么是bug？ 简单地说，就是软件的行为和用户的期望值不一样，就叫bug。 有实际用处的同时又是完美的软件，在世界上是不存在的。 单元测试也能帮助程序员记录这个模块的历史和设计变更的理由。 单元测试应该准确、快速地保证程序基本模块的正确性。 最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语句。 单元测试不能解决所有的问题，不能期望它会发现所有的缺陷。 一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。 单元测试应该覆盖所测单元的所有的代码路径，包括错误处理路径。 100%的代码覆盖并不等同于100%的正确性。 回归测试最好要自动化，因为这样就可以对每一个构建快速运行所有回归测试，单元测试是回归测试的基础。 工程师在"需求分析"和“测试”这两方面明显要花更多的时间。 如何保证质量——回归测试。 个人感受： 过去只知道，程序=数据结构+算法

在VS2010中，在类中点击右键，有一个创建创建单元测试命令，可以很方便的生成单元测试项目和代码。但不知道为什么VS2012反而没有这个功能。 网上搜了一下，好在这个功能是可以通过配置打来的。 传送门： http://www.cnblogs.com/WilsonWu/archive/2013/05/22/3092584.html 但作者用的是英文的VS，我们来个汉化版本的。并说明一下需要注意的地方。 1 打开 工具--自定义 2 选择 上下文菜单--编辑器上下文菜单|代码窗口 3 在这里我们可以看到“创建单元测试”这个菜单了，将它移到运行测试菜单下面 4 关闭VS并重启 重启后再对着类名，点击右键，发现上下文菜单中已经出现了“创建单元测试”按钮，但它是灰色的，并不能使用。但我们离成功不远了。 重启很重要，如果不重启，菜单出不来。 5 解决方案中右键，添加--新建项目，添加一个单元测试项目。 如图： 6 右键单元测试项目， 添加--单元测试 哈哈，此时大功告成，你再返回非测试项目项目中，对着类名点击右键，就可以看到“创建单元测试”可以用了。 PS：好像重新打开项目的时候，“创建单元测试”都会是灰色的，但重新执行一下步骤6就OK了。 来源： https://www.cnblogs.com/Gyoung/p/3143438.html

今天打算写一个单元测试,但是已经有写好的单元测试无论怎么弄都提示文件不存在,自己一度以为是启动方式不正确.这里简单记录一下处理过程 1 异常信息: Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [spring/spring.xml]; nested exception is java.io.FileNotFoundException: class path resource [spring/spring.xml] cannot be opened because it does not exist at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:344) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)

[引用自]@菩提树下的杨过 文章《 maven学习（上）- 基本入门用法 》 文中介绍了： 一、下载及安装 二、创建项目“骨架” 三、编译项目 四、单元测试 五、项目打包 六、项目运行 以及相关后续步骤 我的实操使用的是“Java version: 1.8.0_40”+“apache-maven-3.6.3”。 需要注意的一点是，Maven初次运行时需要从中央仓库下载文件，对于大陆用户而言官方站点速度简直无法接受，可以将%MAVEN_HOME%/conf/settings.xml文件中添加阿里云的镜像，以实现速度飞跃。 <mirrors> <mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> 来源： CSDN 作者： 皓月如我 链接： https://blog.csdn.net/fm0517/article/details/103644595

JUnit使用 JUnit主要用于白盒测试和回归测试。 检测JUnit依赖 如果是Spring Boot项目默认已经加入了JUnit框架支持，可在pom.xml中查看： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> 如果Maven项目中没有添加JUnit依赖，可参照如上代码，手动添加。 基础使用 简单的测试代码如下： @RunWith(SpringRunner.class) @SpringBootTest public class SimpleTest { @Test public void doTest() { int num = new Integer(1); Assert.assertEquals(num, 1); } } 注解说明 注解列表 @RunWith：标识为JUnit的运行环境； @SpringBootTest：获取启动类、加载配置，确定装载Spring Boot； @Test：声明需要测试的方法； @BeforeClass：针对所有测试，只执行一次，且必须为static void； @AfterClass：针对所有测试，只执行一次

1、软件工程学概述 软件危机 软件工程 软件生命周期 软件工程 2、可行性研究 可行性研究的任务 系统流程图 数据流图 数组字典 3、需求分析 需求分析的任务 分析建模与规格说明 4、总体设计 设计原理 高内聚，低耦合的系统有什么好处呢？ 面向数据流的设计方法 5、详细设计 设计问题 过程设计的工具 程序复杂程度的定量度量 计算环形复杂度的方法 6、实现 软件测试基础 单元测试 单元测试 白盒测试技术 黑盒测试技术 调试 7、维护 软件维护的定义 软件的可维护性 8、面向对象方法学引论 面向对象方法学的优点 面向对象的概念 对象模型 用例图 9、综合其他章节 建立对象模型 软件重用 工作量估算 能力成熟度模型 10、简答题 来源： https://www.cnblogs.com/gede/p/11148120.html

UT:单元测试 梳理: 测试的方法: 按照是否执行:静态/动态 按照测试手段:手动/自动 按照测试对象分析: 黑盒(系统功能测试): 优点简单,缺点介入时间晚,发现重大bug难以修复 覆盖率100% 灰盒(系统模块间的接口): 优点介入时间相对于黑盒早缺点,需要相应的代码能力 接口覆盖率 白盒(代码函数): 优点介入时间早,缺点需要相应的代码能力 逻辑覆盖率:语句覆盖率/分值覆盖率/条件覆盖率/路径覆盖率/分支-条件覆盖率 UT开展: 1.UT计划 ①确定单元测试范围:使用频率高/代码复用性低/开发人员背景(技术能力低/业务不熟悉)/复杂度高的 ②逻辑覆盖率---给定用例:执行了多少个/全部语句多少个 语句覆盖率:非分支判断(被测试的语句/全部的语句) 分值覆盖率:if语句的分支(被测试的分支个数/全部的分支个数) 条件覆盖率:一个条件两个结果/短路效应(被测试条件数量/全部条件数目) 路径覆盖率: 从开始到结束的过程(被测试路径数/路径总数) 分支-条件覆盖率:分支和条件组合(被测试分支+被测试条件/全部分支+全部条件) 2.UT设计 ①测试策略:自顶向下(打桩函数)/自底向上(打桩函数)/孤立策略 3.UT实现 ①将测试的单元转换为流程图 ②流程图转换为流图 ③流图描述的是程序的复杂程度 ④每条路径就是一个测试用例(if条件的个数+1 ,while) 举例:三角形的判断 程序-

import unittestclass study(unittest.TestCase): def testXia(self): self.assertEqual((3*4),20) def testHong(self): self.assertEqual(2,2)if __name__=="__main__": unittest.main()注意：1.方法的命名以test开头；2.查看unittest的用法，help(unittest);3.查看**的属性，dir(unittest.TestCase); 来源： https://www.cnblogs.com/canglongdao/p/11966851.html

本文分别在VS2008和VS2010 With Parallel，进行了相同代码的单元测试，其中使用Parallel后，性能的提升还是比较令人满意的，示例中包含了使用Parallel(TestStrBTest()用例)和使用普通foreach的测试用例，感兴趣的同学可以下载来跑一下。 http://files.cnblogs.com/isline/TestApplication.rar 概要 单元测试是一种辅助开发的测试方法，是在开发阶段进行的，测试人员与开发人员可以分别对需要的模块进行单元测试。 单元测试的对象，在函数式变成语言中可以是过程，在OOP语言中可以是类。 类的划分与建立是否合理，是单元测试是否能顺利进行的关键，建模很大意义在上决定了单元测试的适应度。 单元测试是一种白盒与黑盒都适用的方法，与其紧密相关联的环节有代码的复审、走读、静态分析与动态分析，所以单元测试是白盒测试或灰盒测试。开发人员为主要测试实施者，进行白盒测试，测试人员进行灰盒测试。二种角色在实施单元测试时没有过多的交集，且要保持彼此的隔离。我写的是程序人员进行的白盒单元测试。 这篇文档主要为大家介绍与开发人员相关的动态分析单元测试。 单元测试是一种偏向白盒测试的方法，由于测试人员很难使用相应的语言编写单元测试用例，并对代码进行高覆盖度的测试，所以单元测试一般由程序人员本着“尽可能早”的原则完成

TestNG的基本注解与执行顺序 在类里编辑程序时，在@Test后面，摁 alt+回车，选择对应的插件，可以把目前用到的插件自动添加到 pom.xml 文件中，如下面的testng，每摁一次，就多添加一次 当使用的类里，用到的方法没有导入类包时，可以在 类的大括号 后面，摁 alt+回车 ，可以自动导入目前的类中，需要用到的类包，如 import org.testng.annotations.Test; 1、注解实战BeforeMethod和AfterMethod @BeforeMethod，在每次测试方法运行之前运行； @AfterMethod，在每次测试方法运行之后运行。 比如： 运行结果为： 2、注解实战BeforeClass和AfterClass @BeforeClass，每次当前类运行之前，运行一次； @AfterClass，每次当前类运行结束后，运行一次。 public class BasicAnnotation { //最基本的注解，用来把方法标记为测试的一部分 @Test public void testCase1(){ System.out.println("这是测试用例1"); } @Test public void testCase2(){ System.out.println("这是测试用例2"); } @BeforeMethod public void