刘捷 曾任BEA中国专业服务部 高级架构师顾问
现任职Oracle架构咨询顾问,帮企业诊断架构性能问题,曾任职BEA(中国)资深软件架构师,十余年的企业软件架构、开发和管理经验, 侧重于企业应用软件架构设计.主要负责客户大型项目的架构设计和研发。
作为技术专家保证项目的成功实施,运行和维护。参加过全国/全省多个大型的计算机应用项目,擅长的领域包括电信,金融、税务,大型互联网web2.0应用等。此前就职于IBM,任软件架构师。 在此之前曾任日本东京一家软件企业的资深技术顾问。
技术能力:
DB,UNIX,J2EE,SOA,WebLogic Server, WebLogic Integration, WebLogic Portal相关的架构设计。
课程背景
你是否有过这样的感觉:
今天,大多数人都已经承认单元测试是开发者的职责,而不是QA职责. 比如Google就将单元测试推到上游的、以及内建质量的意识,优秀的自动化测试实践成为我们的榜样。然而现在我们天天讨论单元测试,试图将单元测试引入组织流程时.却会面临一系列的问题? 单元测试价值究竟何在? 什么是好的单元测试? 如何设计单元测试用例? 单元测试覆盖率到底应该多少? 这么多的依赖怎么才能编写单元测试? 怎样提高设计与代码的可测试性? 历史遗留系统代码还有必需去写单元测试吗?单元测试真是我们的银弹吗? 怎样才能坚持编写单元测试?
在该课程之中,我们将揭开这些问题的背后的原因。本课程不单单是单元测试基本概念的技能讲解,而是把技能和问题的场景结合,关注如何应用单元测试解决问题,尤其关注需要通过经验积累的高级技能。课程中的理论和经验来自于对大量开发人员常犯错误与所遇问题的归纳、分析与总结,有针对性的给出解决方法,课程将重现这些问题的经典案例,通过实例讲解,并对应到学员的实际工作问题,使学员能够把传授的经验和自己的问题结合起来,有效的启发思路、激发兴趣、并掌握解决问题的基本方法。
培训对象
各类软件研发机构的软件研发管理者、架构师,软件设计师、程序员。对于怀有设计疑问和问题,需要梳理解答的团队和个人,效果最佳。
备注:传统的手工测试人员,和不写代码的测试工程师不建议参加,该课程主要面向开发人员而不是一般的测试工程师。
学员基础
学员学习本课程应具备下列基础知识:
1) 了解Java/C#/C++/C语言(最好了解面向对象基本概念);
2) 简单了解XUnit框架的任何一种;熟悉一种开发工具IDE下单元测试环境(比如JUnit/Nunit/MSTest/CppUnit/TestNG/GoogleTest等,我们课程不关注具体的工具的使用)。
培训内容(标准课程内容较多,上课时根据学员需求进行定制安排)
授课内容 |
单元测试基础 |
内容一:理解单元测试
|
理解单元测试框架—XUnit工具 |
内容一:理解单元测试XUnit 框架使用—(以Junit为案例介绍,其他简单介绍)
|
单元测试设计 |
内容一:构思单元测试
内容二:单元测试设计—黑盒测试
内容三:单元测试设计—白盒测试
|
单元测试坏味道 |
内容一:测试代码坏味道
内容二:测试行为的坏味道
内容三:测试项目的坏味道
|
测试覆盖 |
内容一:逻辑覆盖
内容二:统计测试覆盖--(以Junit为案例分析)
|
单元测试模式 |
内容一:单元测试结果验证模式
内容二:单元测试替身模式
|
单元测试之中如何解耦依赖 |
内容一:利用Stub解除依赖关系
内容二:通过Mock对象交互测试
内容三:Mock与Stub区别
|
增强设计与代码的可测试性 |
内容一:设计和代码的可测试性
|
企业级系统的单元测试 |
内容一:企业级系统的单元测试最佳实践
|
编写好的单元测试 |
内容一:好的单元测试测试标准-A-TRIP
内容二:如何编写好的单元测试测试
|
TDD测试驱动开发基础 |
内容一:TDD测试驱动开发
|
历史遗留系统如何编写单元测试 |
内容一:遗留系统代码环境下如何编写单元测试
|
单元测试组织和管理 |
内容一:组织和管理测试
|
在研发团队如何引入单元测试 |
内容一:将测试引入到你的组织中
|