单元测试

NUnit 分三篇文章介绍，入门者可阅读文章，有基础者直接参考 官方文档 。初次写博客，望大家指点。 导航： 单元测试之NUnit一 单元测试之NUnit二 单元测试之NUnit三 本文介绍常用的NUnit属性特性和断言。 常用属性 更多属性参考官方文档 1. Test Attribute 标记一个方法为测试方法。 /// <summary> /// 简单标记方法为测试方法 /// </summary> [Test] public void Add() { Assert.AreEqual(4, 2 + 2); } /// <summary> /// 添加说明内容，等同于DescriptionAttribute属性 /// </summary> //[Test(Description = "这是说明内容")] [Test,Description("这是说明属性")] public void Add() { Assert.AreEqual(4, 2 + 2); } // 标记异步方法 [Test] public async Task AddAsync() { /* ... */ } // 如果测试方法有返回值，要使用ExpectedResult校验 [Test(ExpectedResult = 4)] public int TestAdd() { return 2 + 2; } //

web应用程序测试方法和测试技术详述 1. 概述 l 随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多， 很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。 l 测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。 l 相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。 2. 测试方法 说明：测试方法的选择取决你的测试策略。 l 一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 l 当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 l 有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 2.1 界面测试 l 现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 l 方法上可以根据设计文档

Android单元测试 http://blog.csdn.net/stevenhu_223/article/details/8298858 通过JUnit进行Android单元测试：http://www.open-open.com/lib/view/open1328152424546.html 如何进行Android单元测试 ：http://www.cnblogs.com/feisky/archive/2010/07/23/1783826.html Android学习笔记：对Android应用进行单元测试 http://blog.csdn.net/duancanmeng/article/details/7458851 行为触发之Android自动化测试instrumentation（一） :http://blog.csdn.net/xbalien29/article/details/21295125 Android单元测试 ：http://blog.csdn.net/stevenhu_223/article/details/8298858 android单元测试Activity(转) ：http://mxq824.blog.163.com/blog/static/1221185620115299419709/ Android单元测试

　　 先来看看功能测试如何进行的：编写测试用例，测试用例当中最主要的是测试步骤和预期结果；测试人员根据测试用例执行操作步骤，然后通过眼睛和思考判断实际结果与预期结果是否相等。如果相等，测试通过；如果不相等，测试失败。 　　自动化测试要做的事情与功能测试是一致。这里的自动化主要包含三个层面的自动化，单元测试自动化，接口测试自动化和web测试自动化。当然，不同层面的自动化关注点是不一样的。 　　单元测试自动化，调用被测试的类或方法，根据类或方法的参数，传入相应的数据。然后，得到一个返回结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，这里单元测试关注的是代码的实现与逻辑。元测试是测试中的最基本的测试， 也是测试中的最小单元， 它的对象是函数对象，也可以包含输入输出， 针对的是函数功能或者函数的内部逻辑方面。 并不包含业务逻辑。 　　接口测试自动化，根据接口文档，到底是传get请求呢？还是post请呢？调用被测试的接口，构造相应的数据（id=1,name=zhangsan），得到返回值，是200成功，并返回查询结果。还是10021，用户名不能为空。不管输入的参数是怎样的，我们都将得到一个结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，接口测试关注的是数据。只要数据正确了，功能就做成大半

摘自：https://www.jianshu.com/p/80270b93082a 如果定义一个如下的 update 函数，那么这个函数的返回值到底是啥意思呢？是受影响的行数吗？ 验证之前我们先看看数据库中的数据记录。总共两条数据记录！ 数据库链接配置为： jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/ssm jdbc.username=root jdbc.password=123456 下面看看我们的单元测试类。 我们根据 ID 获取记录，然把用户名由 root 改为 root001。如果说返回值是影响的行数的话，那么应该返回 1.跟我们的预期结果 1 是相符的。单元测试会通过。 单元测试通过，我们看看数据库中的记录有没有变化。 看起来貌似没有任何问题。单元测试通过，数据库的确是只有一条记录更改了。这说明 mybatis 的 update 操作返回值的确是受影响的行数。 真的是这样吗 我们知道当数据库中的记录被修改之后，我们在次执行相同的 update 语句将不会影响到数据记录行数。 按照这个逻辑来讲的话，在此执行此单元测试，返回值应该为 0，跟我们的预期值 1 不同，单元测试应该不通过。再次运行单元测试： 我去，单元测试居然神奇般的通过了。。。请注意看，我们在命令行执行 update

单元测试：测试程序在各种数据下的准确性 基准测试（压力测试）：测试程序的速度及弹性 testing包被专门用来进行自动化测试，日志和错误报告。并且还包含一些基准测试函数的功能 测试文件必须满足 *_test.go这种格式*代表源文件的名字（测试代码和业务代码分开了） _test程序不会被普通的Go编译器编译。只有gotest会编译所有的程序（普通和测试） 测试文件（测试源代码）中必须导入import testiong 测试函数必须以TestZzz为格式（Zzz是函数名，如TestAdd（t *testing.T）） T是传给测试函数的结构类型，用来管理测试状态，支持格式化测试日志，t.Log,t.Error,t.ErrorF 以下函数用来通知测试失败： func (t *T)Fail()//标记为失败，并继续执行 func (t *T) FailNow()//标记为失败并终止此文件的执行，继续下一个文件 func (t *T) Log(args ...interface{})//args 被用默认的格式格式化并打印到错误日志。 func (t *T) Fatal(args ...interface{})//先执行第三个，在执行第二个（上面两个的综合） go test来编译测试程序，并执行程序中所有的TestZzz函数，所有的测试都通过会打印出PASS

pytest 用法和调动 1、设置失败次数后停止 pytest - x 失败一次后停止 pytest - maxifle =2 失败两次后停止 2、pytest 可以选择测试/指定测试 1、运行模块 pytest test_load.py 2、可运行目录 pytest case/ 3、匹配关键字执行 pytest -k test_one 匹配所有测试用例中的test_one函数 4、执行模块中制定的函数 　　1、模块中的函数　　pytest test_load.py::test_create_file 　　 　　2、模块中类的函数 pytest test_loan.py::TestClass:test_one 来源： https://www.cnblogs.com/ioan/p/9785569.html

Tessy 源自戴姆勒- 奔驰公司的软件技术实验室，由德国Hitex 公司负责全球销售及技术支持服务，是一款专门针对嵌入式软件进行单元/ 集成测试的工具。它可以对C/C++ 代码进行单元、集成测试，可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告，其多样化的测试用例导入生成方式和与测试需求关联的特色，使Tessy 在测试组织和测试管理上也发挥了良好的作用。目前Tessy广泛应用在汽车电子主流客户中。 主要特点 在V 模型开发中，Tessy 主要应用在单元测试和集成测试阶段。单元测试通过运行代码检测出函数中错误，比如算法错误、接口问题等；集成测试则在单元测试的基础上验证单元之间接口的正确性。基于越早发现bug 开发成本越低的原则，在进行代码功能验证的过程中，按照V 流程右半部分先完成单元测试再进行集成测试的测试顺序更为有效。 另外，Tessy 也可以满足各类标准（ 如ISO26262、IEC61508、EN 50128/50129 等）对测试的需求，比如Tessy 可以满足ISO26262 中各等级对单元/ 集成测试的要求，当然Tessy 本身也通过了TUV 的认证，证明该软件是安全可靠的，可以在安全相关的软件研发过程中使用。 主要功能 • 自动生成测试环境、一键执行及评估结果 Tessy 可以自动生成驱动程序、桩函数，帮助测试人员提高单元测试效率。 Tessy

本篇只介绍了单测的实现，想了解更多可以访问官网： http://www.mars-framework.com 1.在test目录下新建单测需要的类,并继承 MarsJunit 2.把mars.yml文件拷贝到test目录下的resource目录，并修改里面的内容为测试环境的配置，如果不需要改的话，拷贝过来即可，不需要动 3.在单测的类里 需要做如下事情，请看图 /** * 单测必须 继承 MarsJunit */ public class TestServiceTest extends MarsJunit { /** * 正常使用注入 */ @Resource("testService") private TestService testService; /** * 这个方法必须实现，这个注解也必须要加 */ @Before public void before(){ /* 这里必须调用，并传入Main方法所在的包名 */ init("com.test"); } /**** 下面的用法就是junit的用法 ****/ @Test public void testSelectList(){ List<Map<String,Object>> list = testService.selectList(); for(Map<String,Object> map : list){

实际上“单元测试不可测试那些类（无抽象、静态类、静态方法）”是个伪命题，因为事实是：无抽象、静态类、静态方法都是不可单元测试的。那么，如果我们要写出可测试的代码，又要用到这些静态类等，该怎么办，实际上我们需要两个步骤： 1：为它们写一个包装类，让这个包装类是抽象的（继承自接口，或者抽象类，或者方法本身是Virtual的）； 2：通知客户端程序员，使用包装类来代替原先的静态类来写业务逻辑； 实际上，微软也是这么干的，我在上一篇博文《 单元测试WebForm的UI逻辑及文件上传 》写到，最典型的不可测试类，那就是WebForm架构的网站中，对Response等的模拟。查看Response这个类： namespace System.Web { public sealed class HttpResponse { ... } } 很明显，如果我们在某个WebForm的后台方法中，直接使用它的话： protected void Page_Load(object sender, EvengArgs e) { this.Response.Write("test u"); } 该后台代码逻辑就无法进行单元测试了，因为类似MOQ的框架所依赖的是代码本身具有可被重写行，如果某个类本身是静态的，就无法在运行时用模拟类替换掉实际类。 所以，写一个包装类吧，我们看到微软为Response写了一个包装类