单元测试

1. HTML测试报告 对测试人员来而言，测试的产出很难衡量。换句话说，测试人员的价值比较难以量化和评估，相信这一点对软件测试人员来说深有体会。我们花费了很多时间与精力所做的自动化测试也是如此。所以，需要一份漂亮且通俗易懂的测试报告来展示自动化测试成果。显然，一份简单的Log文件是不够的。 HTMLTestRunner是Python标准库unittest单元测试框架的一个扩展，它生成易于使用的HTML测试报告。HTMLTestRunner是在BSD许可证下发布的。 下载地址： http://tungwaiyip.info/software/HTMLTestRunner.html 这个扩展非常简单，只有一个HTMLTestRunner.py文件，被选中后单击鼠标右键，在弹出的快捷菜单中选择另存为，将它保存到本地。安装方法也很简单，将其复制到Python安装目录下即可。 Windows：将下载的文件保存到...\Python36\Lib目录下。pycharm中不能使用，就找到pycharm的lib目录，将文件粘贴进去。 Linux：以Ubuntu为例，首先需要打开终端，找到Python的安装目录。打开终端后，输入Python命令进入Python交互模式，通过sys.path可以查看本机python的安装目录。以root身份将HTMLTestRunner.py文件复制到/usr

unittest的属性： 该文以思维导图的形式描述unittest的重要属性。 其中前四个是unittest最核心的三个属性。 testcase：测试用例； testsuite：测试套件，多个测试用例组成一个测试套件； test runner：执行测试用例，该类中的run()方法会执行testsuite/testcase中的run()方法。测试的结果会保存在testresult中。 还有一个很重要的就是fixture，看着是挺陌生的，其实就是一个测试用例执行之前环境的准备和执行之后环境的销毁。 三、实例： 首先准备一些待测方法，functions.py： def fun_div(x): return x/2 def fun_add(x): return x+2 def fun_minus(x): return x-2 def fun_multi(x): return x*2 接下来写一些测试用例来测这些方法，test.py import unittest from functions import fun_add,fun_minus,fun_multi,fun_div class TestFun(unittest.TestCase): times = 0 @classmethod def setUpClass(cls): print('setUpclass') def setUp

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

TestNg TestNg 是java的一个自动化单元测试框架 参考：http://testng.org/doc/index.html 环境准备 既然是java 的自动化单元测试框架，就必须要有java的环境了，这里使用的编辑器是Eclipse,已经安装过TestNg 插件，如果环境准备好就可以开始了 代码实例 代码结构如图 新建一个java项目，之后添加一个TestNg类，之后会生成一个测试类，和一个xml文件 （如果发现TestNg编辑是出错，无法调用TestNg的标签函数，那么导入TestNg.jar.可以右键点击项目，之后BuildPath ->add Libary->选择TestNg 即可） 简单地TestNg类 package TestNgDemo; //使用TestNg 测试框架 import org.testng.Assert; import org.testng.annotations.Test; import org.testng.annotations.BeforeClass; import org.testng.annotations.AfterClass; public class NewTest { //测试开始前执行一次 @BeforeClass public void beforeClass() { System.out.println(

浅谈单元测试和重构 隐喻 年纪大了，腿脚不利索，拄着拐杖走路，走的稳不说，还能预防跌倒。 但如果真的跌倒了呢？ 跌倒后有没有人敢扶？扶起来还能不能走？如果能走，走得还能不能像以前那样快？如果不能走，是不是要去医院？ 没了拐杖，产生了灾难性的骨牌效应。 意义 单元测试之于开发人员，相当于老人的拐杖，离开拐杖，也能走，但就是深一脚浅一脚，而且还有随时跌倒的危险，跌倒之后还会产生一系列的问题，搞的人焦头烂额。 在没有单元测试支撑的情况下写代码，你不会知道代码里面有没有逻辑 BUG ，是否符合预期，不能发现编码过程中引入的错误，更不能发现设计和需求中存在的问题。 我曾经所在的一家公司，开发人员是不写测试的，他测试自己代码的方法，是写完之后运行一下，点点看有没有问题，效率低下容易漏测不说，还很业余，简直侮辱软件工程师这个高大上的职业（看我鄙视的眼神）。 假设你写了一个服务，每写一个方法你都写单元测试将方法中的路径全覆盖掉，如异常， if-else, switch 语句等，刚准备提交，突然接到通知，需求变了，你不得不改动编码逻辑，这个时候怎么办呢？首先要跑一遍单元测试，确保你当前功能的测试全跑通，然后分析需求，按照要求对相应的代码进行了修改，之后，修改或增加单元测试对改动代码进行覆盖，你点下了开始按钮，看着所有测试都打了绿色的对勾（ ✔），你从容淡定的提交了代码，拿起菜刀，哦不，端起水杯

引言 单元测试是软件开发过程中重要的质量保证环节。单元测试可以减少代码中潜在的错误，使缺陷更早地被发现，从而降低了软件的维护成本。软件代码的质量由单元测试来保证，而单元测试自身的质量与效率问题也不容忽视。提高单元测试的质量与效率，不仅能够使软件代码更加有保证，而且能够节省开发人员编写或者修改单元测试代码的时间。衡量单元测试质量与效率的指标多种多样，代码覆盖率是其中一个极为重要的指标。一般而言，代码覆盖率越高，单元测试覆盖的范围就越大，代码中潜在错误的数量就越少，软件质量就越高。本文首先介绍代码覆盖率的统计指标类型及常用统计工具，然后重点选取具有代表性的行覆盖率进行分析，介绍两种方法用于提高代码的行覆盖率。 回页首 代码覆盖率的统计指标 代码覆盖率指的是一种衡量代码覆盖程度的方式，通常会对以下几种方式进行统计分析： 行覆盖。它又被称作语句覆盖或基本块覆盖。这是一种较为常用且具有代表性的指标，度量的是被测代码中每个可执行语句是否被执行到。 条件覆盖。它度量的是当代码中存在分支时，是否能覆盖进入分支和不进入分支这两种情况。这要求开发人员编写多个测试用例以分别满足进入分支与不进入分支这两种情况。 路径覆盖。它度量的是当代码中存在多个分支时，是否覆盖到分支之间不同组合方式所产生的全部路径。这是一种力度最强的覆盖检测，相对而言，条件覆盖只是路径覆盖中的一部分。 在这三种覆盖指标中，行覆盖简单

　　单元测试是很重要的一个步骤。写代码的都应该会这个技能，自己写的代码自己测！ 　　本文说的是java的单元测试，用的是JUnit通过注解的方式来识别测试方法 JUnit目前支持的注解有： 下面基于IDEA介绍JUnit的基本应用 1.首先先新建一个java项目，我们编写一个Calculator类，做一个简单的计算机功能，里面有加减乘除的方法。然后进行单元测试： public class Calculator { private static int result; // 静态变量，用于存储运行结果 public void add(int n) { result = result + n; } public void substract(int n) { result = result - 1; //Bug: 正确的应该是 result =result-n } public void multiply(int n) { } // 此方法尚未写好 public void divide(int n) {//除法 result = result / n; } public void square(int n) { result = n * n; } public void squareRoot(int n) { for (; ;) ; //Bug : 死循环 } public void

软件生命周期 软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内，无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中，总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。 测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划，需求分析比较重要。 清晰的工作流程，便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程，存在巨大的风险。 依赖于早期的需求调查

winAMS -- 嵌入式软件单元测试 / 集成测试工具 CoverageMaster winAMS : 适用于嵌入式目标机代码的单元测试工具 全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具 不需要HookCode 直接使用目标机代码进行单元测试 联合静态解析工具[CasePlayer2]，提供C1,MC/DC用优化测试计划（test case）制作功能 已取得第三方认证机构TUVSUD对适用于汽车机能安全ISO26262软件工具的认证 产品概要 [Coverage master winAMS]是以嵌入式软件的函数为单位，实施模块单元测试以及C0/C1/MCDC覆盖率测试（coverage test）的嵌入式软件自动化单元测试工具。目标机源代码通过交叉编译器生成目标机执行代码，通过跟实际处理器同样的模拟处理器环境进行单元测试，不需要对执行代码做任何变动，使高信赖性的模块测试成为可能。在汽车控制软件这样的对安全性要求极高的领域，单元测试已经成为不可缺少的一部分。使用目标机代码进行单元测试也是为了符合汽车行业中ISO26262功能安全认证标准。 产品特长 全面支持嵌入式微机！验证嵌入式C/C++软件 实施以模块为单位的自动化单元测试工具 作为能够检验出仅凭系统测试以及整体测试无法发现的[潜在错误]的检测方法，[单元测试]在嵌入式开发领域受到广泛重视

步骤： 1. 选中当前工程 — 右键选择，build path — add libraries — JUnit 4 — 下一步 2. 创建Java类，进行单元测试。 　此时的Java类要求：①此类是public的 ②此类提供公共的无参的构造器 3. 此类中声明单元测试方法。 此时的单元测试方法，方法的权限是public，没有返回值，没有形参 4. 此单元测试方法需要声明注解，@Test，并在单元测试类中导入，import org.junit.Test; 5. 声明好单元测试方法以后，就可以在方法体类测试相关代码。 6. 写完代码后，左键双击单元测试方法名，右键：run as — JUnit Test 说明： 1. 如果执行结果没有任何异常，绿条 2. 如果执行结果出现异常，红条 来源： https://www.cnblogs.com/wuliking/p/11921795.html