一、前期准备
前期在未进入项目的时候,需要明确项目将会进行单元测试,明确到每个开发工程师都需要对自己开发的代码进行单元测试。
同时通过单元测试计划,以书面的形式确定以下方面的内容,让单元测试有统一的指导思想:
l 测试目的
l 测试策略
l 测试范围
l 影响
l 测试方法
l 测试通过/失败的标准
l 测试技术/工具
l 交付物
l 角色职责
l 进度检查
l 风险与应急
通过单元测试计划,项目中成员会比较理解将要进行的工作,项目成员会很清楚单元测试进行的方式,验收标准等等。另外增加了冒烟测试提交的条件之一就是单元测试代码要100%通过,这得到了项目组成员的一致认同,这就对后期的单元测试工作的展开非常重要。
二、代码编写阶段
单元测试基础代码,环境问题的解决
项目中进行过程中需要有专人来为单元测试保驾护航,例如单元测试基础代码编写,环境问题排查,Hudson集成脚本的编写和平台的构建和每日运行检查的工作。这部分工作对单元测试的开展非常重要,很多同学怕麻烦,怕复杂就放弃了,同时他们也有理由不进行单元测试了。
单元测试基础代码和技术问题的排解在项目中我认为应该由技术经理或者对单元测试技术相对熟悉的同学担任。它的进展关系单元测试是否顺利。
我们摸索出了一种比较合适的测试框架组合,Spring Test+JMockit+Junit 4.5 (但统一用3.8的写法,JUnit4和Spring 2.5.6 TestContext框架不兼容)+封装过的DbUnit代码+自主开发的Tag测试基础代码来适应Hudson和Maven Surefire。
其他项目可以参考下,也可以使用下其他新的框架如JTester和其他版本。
单元测试代码的运行
单元测试代码的持续构建运行需要一个计划,一个规范。这个需要在项目过程中严格执行,这个的责任人在项目里面由测试同学担当。
单元测试的规范是包括运行规范,运行结果中失败修改时间点的约定,运行结果发送的规范,单元测试运行结果报告应该重点阐述什么内容,相信所有支持进行单元测试的同学,都不会仅仅把目光放在覆盖率上,还有运行中出现的失败的点,需要分析原因,运行中列出来的复杂度和一系列指标比较高的点,需要分析是否需要实现优化,还是需要增加用例保证质量,这个运行的结果,我们是可以进行分析的,需要大家的关注。
单元测试的代码也需要进行Review,保证测试代码的质量。单元测试的目的就是要尽早发现问题,如果测试代码质量不高,就无法有效保证业务代码的正确性。项目对测试代码仅进行了部分的Review,主要从测试代码正确性,消除有SMELL的测试代码,统一的测试代码基础方面。业务方面的Review测试相对少一些。
单元测试代码责任人需要保证对应单元测试代码运行通过。
三、测试执行阶段
根据单元测试计划,对于发现的Bug,项目组需要讨论是否有必要进行单元测试覆盖,或者是否需要增加测试用例去覆盖。在这个方面,项目组做的比较好,开发的同学是积极配合,补充了相关的测试用例。
四、项目发布后
项目发布后,虽然对单元测试已经没有明确的要求了。可是我发现有部分同学在持续的补充单元测试用例,继续改良测试用例的设计,还有同学学习他人编写的测试代码。这是我意料不到的。我想应该是同学们在项目中持续的受到了单元测试的影响,所以形成了自动的行为。这也提醒我们,不但要在项目中保证好的测试代码,在项目后期也要不断的维护它。
五、好的方面
1、 项目前期项目组对单元测试的开展思想一致。进行了单元测试计划,单元测试用例设计指导文档来指导后续的开发。
2、 项目组在思想和行动上对单元测试逐步重视的,也很积极配合这方面的工作。
3、 单元测试有专人跟进,清除技术问题,方便开发同学开展单元测试。项目过程中,与开发同学逐个商谈单元测试的难处,问题并且跟进解决。
4、 对单元测试代码进行了部分Review。
5、 对曾经产生过Bug的代码进行了检查和讨论,并为部分的Bug增加或者补充了单元测试代码。
6、 对单元测试代码有Owner心态,力求单元测试不会运行出错,也持续的改进。
六、需要改进的地方:
1、 单元测试的时间在前期没有得到很好的保障,在第一次迭代的时候没有做到单元测试计划的要求。
2、 项目约定中需要进行单元测试功能特性点比较粗,不好把控。
3、 单元测试代码很多时候是在开发代码完成的阶段才去编写,应该在开发过程中就边开发边编写测试代码来保证功能的完好性。
4、 对单元测试代码在业务上是否正确的Review做的比较少。
七、总结
总的来说,在项目单元测试做了一个比较好的尝试,虽然暂时不能直接看到单元测试带来的收益,但是无形中增强了我们的质量意识。我相信,只要在维护阶段有产品功能的修改或者代码的重构,现有的单元测试代码就可以很快的做一个功能的回归,保证代码的质量,这样就会逐步提高我们的信心。
分享到:
相关推荐
【说明该单元测试报告在整个项目周期的适用范围】 测试用例清单 模块 目标类 级别 用例类 用例描述 执行结果 备注 【被测的代码类】 【代码级别】 【Junit测试类1】 【意图描述】 【P/F】 【Junit测试类2...
单元测试又称模块测试,针对软件设计中的最小单位——程序模块,进行正确性检查的测试工作。 集成测试 集成测试又叫组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增测试。重点测试不同模块的...
总结个人在项目开发中进行单元测试的方法 ActivityInstrumentationTestCase2 ServiceTestCase android.test.InstrumentationTestRunner 等开发日志
软件测试的 各种测试的方法和文档 有白盒黑盒 集成 系统 单元
11.6_单元测试和总结|首页功能|Node.js-Koa2框架从零开发仿新浪微博项目实战
7.6_单元测试和总结|创建微博|Node.js-Koa2框架从零开发仿新浪微博项目实战
9.4_单元测试和总结|广场页|Node.js-Koa2框架从零开发仿新浪微博项目实战
10.6_单元测试和总结|关注和取消关注|Node.js-Koa2框架从零开发仿新浪微博项目实战
12.4_单元测试和总结|@和回复功能|Node.js-Koa2框架从零开发仿新浪微博项目实战
13.6_单元测试和总结|@提到我的|Node.js-Koa2框架从零开发仿新浪微博项目实战
在实际项目开发中,企业开发不仅要保障业务层与...本文是工作中的开发经验总结,使用的SpringBoot+MockMvc+H2数据库 编写自动化单元测试的开发过程,附带成功运行截图,以及完整的配置文件代码,分享给大家做个参考吧!
1/ 9 保密申明:秘密级 信息系统测试总结报告 {项目名称} 信息系统测试总结报告 编号:BH-{项目名称缩写}-流水号 版本:X.X 作者: 日期: 审批: 日期: 2/ 9 保密申明:秘密级 信息系统测试总结报告 变更记录 ...
此测试用例文档,为本人几次项目的总结,包含了Web测试最基本的测试用例
项目测试报告模版; 目录:测试结果及缺陷分析,总结及建议等
本文是最近在学习Node.js测试方面的总结,包括单元测试、集成测试、基准测试以及代码覆盖率测试等多方面的的内容。对于中大型项目,完备的测试用例有助于保证项目的持续集成能力和代码的健壮性。 UnitTest 单元...
实际总数大于1848个)2015-08(主要测试jobbroker与appform的集成、70所的定制项目、核九院定制项目以及JHSecurity前期单元测试)
Jim Newkirk和Brad Wilson这两位xUnit.net的创造者,从NUnit和其他单元测试框架的经验中总结出来以下改进:为每个测试方法产生一个对象实例取消了[SetUp]和[TearDown]取消了[ExpectedException]类似于Aspect的功能...
之前的项目使用的是 react@15.x 的版本,使用 enzyme 配合 jest 来做单元测试毫无压力,但新项目使用的是 react@16.8 ,编写单元测试的时候,遇到不少阻碍,因此总结此篇文章算作心得分享出来。 配合 enzyme 来进行...
火龙果软件工程技术中心 本文内容包括:TestNG的示例代码运行TestNG的Ant脚本重新运行前次运行失败的测试用例分布式测试特性TestNG的多线程支持总结参考资料关于作者随着项目的成长,单元测试的数量会迅猛增长。...