做为一名多年的软件开发人员,软件质量一直是心口的一块石头,一直压抑着自己,因为软件质量的高低关乎我们每一个软件企业的生存和发展。
事实证明软件的问题消灭在萌芽状态是成本最低的一种方式,因此在开发阶段需要进行大量的测试才能保证软件的质量。
因此,我认为比较理想的开发模式为“测试驱动开发”,即在开发前首先设计测试用例,在测试用例的基础上进行开发。
但是如此以来,项目的整体开发周期会加长,而且很多程序员从内心认为编写单元测试会增加自己的工作量,有编写单元测试的时间还不如编写代码能获得更高的效率,因此测试驱动开发往往达不到预期的效果。
那么如何提高单元测试的效率呢?根据人类几千年的发展变迁史来看,提高效率的方式只有一种——使用工具。
So,我们要想提高单元测试效率的方式就一种,制造一种自动化的单元测试工具,该工具应该可以进行下面的一些工作:
1. 实现多项目的管理。一个测试驱动的平台应该可以管理多个项目。
2. 实现项目基础开发框架的生成。根据项目的包名自动生成springmvc+mybatis+spring的开发框架。
3. 测试用例管理。测试用例包含持久层测试用例、服务层测试用例、控制层测试用例。
4. Mock系统的生成,对于无法测试的第三方系统可自动生成mock对象,最终能够基于mock对象完成测试。
5. 集成测试管理。测试系统可配置复杂情况下的集成测试。
6. 测试代码生成。系统可根据设置的测试用例自动生成单元测试代码并执行。
7. 测试报告管理。测试完成后可通过界面阅读测试报告。
8. 基于git的托管。系统可以将生成的项目发布到git中,以实现对系统版本的控制。
10. 界面模板管理。系统可生成界面基础模板及模板使用说明文档,第三方前端可提交自己的模板,该模板可以与生成的系统进行整合。
11. 数据模型定义。后期可定义数据模型,根据数据模型自动创建数据库,支持导入pdm文件。
12. 系统文档生成。系统能够自动写文档模板,包括:用户手册、管理员手册、测试报告、api接口、数据字典。
13. 系统可实现压力测试。系统可以使用jmeter实现压力测试报告。
14. 系统菜单的定义。可定义系统菜单。
15. 系统原型生成。
16. 持续集成系统。
17. 安全扫描。
想象一下,有了这套工具,我们在后面进行项目开发时的场景吧:
1. 搞清楚用户的需求。可使用系统用例图(user case)进行捕获。
2. 创建一个项目,指定项目需要使用的数据库、系统包的规划。
3. 创建数据模型,建立好数据模型(可导入pdm文件哦)
4. 定义系统功能菜单。
5. 生成系统基础框架。
6. 定义单元测试用例。
7. 程序员根据单元测试编写代码,实现业务逻辑。
8. 编写集成测试用例。
9. 生成jmeter压力测试文件并运行。
10. 安全漏洞扫描。
11. 生成系统文档。
12. 交付,放心的交付吧,因为测试做了很多遍了,不会有问题的。
理想中的软件建模方法,谁有兴趣呢?留言联系我一起讨论讨论。
9 条评论:
后面可以增加用例自动分析功能,即通过一段需求描述文字或用例调研表实现对用例的自动捕获及实体的自动捕获
再后面引入报表设计系统(类似于fastreport)等可以直接与系统对接
再下来就是大数据挖掘及数据分析了,引入一些人工智能的东西
最后再在平台建立需求收集系统,及代码外包系统,实现程序员的自由及客户可以得到高质量、低价格的软件。最后再把运维和实施给客户包了。整个平台生态就很完整了。
后续再实现app的自动化开发平台
测试报告的编写(可以参考github上问题的汇报)
第一步:使用测试驱动模式开发一个应用系统(可开发目标管理系统)
第二步,在此基础上进行总结和完善。形成开发套路
第三步,抽象单元测试,为后面的项目做好准备。
发表评论