linglong911224的博客

原创 二十、quality-erp-dal源码（三）

【代码】二十、quality-erp-dal源码（三）

原创 二十四、quality-erp-webapp源码（二）

【代码】二十四、quality-erp-webapp源码（二）

原创 二十三、quality-erp-webapp源码（一）

org.example.webapp.controller.sys 接入前端接口。

原创 二十二、quality-erp-service源码（二）

【代码】二十二、quality-erp-service源码（二）

原创 二十一、quality-erp-service源码（一）

org.example.service.sys 接口类。

原创 十九、quality-erp-dal源码（二）

【代码】十九、quality-erp-dal源码（二）

原创 十八、quality-erp-dal源码（一）

【代码】十八、quality-erp-dal源码（一）

原创 测试工程师能力考核表（六）样表

负责程度，如果设计等有问题有隐患等，会不会及时提出疑问，还是照做不误。对于口头确定的规则，能否及时补充或提醒有关人员补充到相应文档。总结经验，已有的成果能否在下次开发类似功能时利用。认真负责程度，对于简单任务的完成能够让人放心。认真程度，已经检查过指出的问题会不会再犯。敬业程度，上班时间是否有做与工作无关的事。日报及其他工作记录文档的正确及详细程度。敬业程度，是否能够利用业余时间学习提高。日报及其他工作记录文档的及时填写。附表一：BUG严重程度扣分。附表二 工作态度的考评表。

原创 十七、quality-erp-common源码（二）

一、security。

原创 二十七、matplotlib制图之柱状图

【代码】二十七、matplotlib制图之柱状图。

原创 测试工程师能力考核表（五）管理能力

管理能力。

原创 十六、quality-erp-common源码（一）

三、JSONResult。一、config源码。

原创 二十六、matplotlib制图之饼图

【代码】二十六、matplotlib制图之饼图。

原创 测试工程师能力考核表（四）职业素养

职业素养。

原创 十五、基本功能框架介绍

前面的代码很多都是截图。自测完成之后会按照框架的内容逐一发布源码出来。--:UserDetailsServiceImpl.java, 重写框架的UserDetailsService。--:SysUserBasicDOMapper.java, 用户关联个人信息表接口。--:SysUserSecretDOMapper.java, 用户关联密码表接口。--:SysUserRoleDOMapper.xml, 用户关联角色相关sql。--:SysUserRoleDOMapper.java, 用户关联角色表接口。

原创 二十五、时间系列之两个时间差

返回两个时间相差的秒数。

原创 测试工程师能力考核表（三）业务能力

业务能力。

原创 十四、Swagger在线接口文档

三、启动类加上接口文档。四、访问在线接口文档。

原创 二十四、时间系列之解析时间戳

解析时间戳返回年月日时分秒。

原创 测试工程师能力考核表（二）技术水平

原创 十三、security 认证

我们把权限相关的内容都放在common模块，加入security组件依赖。二、sringboot 集成了 security组件来做认证。重写几个鉴权返回自己的要的json。一、接口请求认证逻辑。四、security。

原创 二十三、时间系列之生成时间戳

返回当前的时间戳或者自己传入的时间对应的时间戳。

原创 第三章 软件测试分类 3.5 按测试流程方式分

其严格定义为:冒烟测试是从抽象层次验证软件的基本功能是否已经实现来确定是否需要更多的测试.若测试失效，软件不再进行其他测试,直接返回给开发人员。，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的。制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求。把设计的用例全部执行的过程就是全量测试。

原创 测试工程师能力考核表（一）考核说明

考核过程全部匿名，请确保不要透露自己对他人的考核过程及结果信息，如有对考核标准存疑的部分请联系你的直属领导或HR部门，电话：XXXXXXXX。我们将KPI考核采取打分制度，考核负责人需要从多角度对被考核人员进行评定。注：管理能力属于管理岗任职人员专有考核，非管理岗无需考核，请删除相关数据。三个层级考核完毕后，根据预先定义的权值计算，得出最后考核结果。本次考核将从专业技能，业务能力，职业素质，管理能力四个层级展开。考核结果将被考核人划分为5个等级，详见考核等级说明。请保证评分尽可能的公正以及客观。

原创 第三章 软件测试分类 3.5 按测试流程分

其严格定义为:冒烟测试是从抽象层次验证软件的基本功能是否已经实现来确定是否需要更多的测试.若测试失效，软件不再进行其他测试,直接返回给开发人员。，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的。制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求。把设计的用例全部执行的过程就是全量测试。

原创 二十二、时间系列之年月日时分秒

【代码】二十二、时间系列之年月日时分秒。

原创 十二、用户相关接口

三、sql xml文件。

原创 第三章 软件测试分类 3.4 按执行方式分

手工测试就是由人去一个一个的执行用例，然后观察记录测试结果。自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。2）手工测试执行过程和实际生产用户的操作过程相识度非常高。所不能发现的问题，这也是为什么自动化测试取代不了手工测试的原因！3）有些复杂的场景手工执行远比自动化测试效率高。，评估运行结果，预先条件应包括正常条件和异常条件。1）只适合需求变动不频繁的项目。1）整体和自动化相比效率过低。1）对测试人员要求比较低。2）对测试人员技能要求高。1）回归测试效率极高。3.4.1 手工测试。

原创 二十一、时间系列之年月日时分

格式返回：2000-12-13 18:58。

原创 十一、角色相关接口设计

一、新建接口类二、sql接口三、sql xml四、实现接口五、接口控制类。

原创 第三章 软件测试分类 3.3 按测试技术分

这两种测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。6）修改条件判断覆盖每一个判断的所有可能结果都出现过、每一个判断中所有条件的所有可能结果都出现过、每一个进入点及结束点都执行过、判断中每一个条件都可以独立的影响判断的结果。白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试。1）只有一小部分可能的输入被测试到，要测试每个可能的输入流几乎是不可能的。

原创 二十、时间系列之年月日时

返回2000-01-01 18 这种格式。

原创 十九、日期系列之获取2个日期差的天数

【代码】十九、日期系列之获取2个日期差的天数。

原创 十、菜单相关接口

一、接口类二、sql 接口三、sql文件四、接口实现五、接口控制。

原创 第三章 软件测试分类 3.2 按测试环境分

因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，只有当α测试达到一定的可靠程度时，才能开始β测试。，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是部署软件之前的最后一个测试操作。

原创 九、部门相关接口

一、接口类设计二、sql接口类三、sql xml四、实现接口类五、接口控制类。

原创 第三章 软件测试分类 3.1 按开发流程分03

性能测试可以发生在测试过程的所有步骤中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统所有成分都集成到一起之后，才能检查一个系统的真正性能。一般来说，GUI活动的结果在系统不同的状态上是不同的。功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。GUI是一个分层的图形化的软件前端，它从一个固定的事件集中接受用户产生的和系统产生的事件，并且产生确定的图形输出。

原创 十八、日期系列之周所有日期

数据统计、测试计划等经常以周为单位来统计数据。所以该方法也经常用到。

原创 八、字典值相关接口

二、涉及的sql接口类。三、sql xml文件。

原创 第三章 软件测试分类 3.1 按开发流程分02

也就是说，在集成测试之前，单元测试已经完成，并且集成测试所使用的对象应当是已经经过单元测试保证了的单元，如果不经过单元测试，那么集成测试的效果将受到影响，并且会付出更大的代价。针对集成测试过程来说。该集成的一个最基本的策略就是把最早可获得的代码拿来立即进行集成，必要的时候开发桩模块和驱动模块，在最大程度上保持与开发的并行性，从而缩短了项目集成的时间。：基于风险的集成是基于这样的一个假设，即系统风险最高的模块间的集成往往是错误集中的地方，因此尽早的验证做这些接口有助于加速系统的稳定，从而增加对系统的信心。