交流心得

期望：
稳定（不要等到crash了才去优化），
安全（涉及用户信息的密码及隐私信息
1、都不能明文存储--防止拖库；
2、都不能明文传输，要进行hash
3、管理平台的登陆密码不能自定义，只能由使用系统提供的符合密码强度的。
）

几个常用的英语口语：overhead,go ahead,

 

DEV: Development System
SIT:  System Integration Testing 系统集成测试
PET: Performance Evaluation Test 性能评估测试
UAT: User Acceptance Testing 用户验收测试



测试的顺序一般为: 
SIT--> PET--> UAT

SIT(System Integration Testing)系统集成测试，也叫做集成测试，是软件测试的一个术语，在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。
内部测试SIT :System   Integration   TestCase  
根据用例描述测试每一个场景，优化系统性能，提交数据库性能excution plan给DBA review。对系统进行压力测试（必要情况下提交到APCC的压力测试组进行测试）。里程碑：完成内部测试报告和得到DBA的上线批准。
集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。

UAT(User Acceptance Testing)用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。
用户根据用例描述测试每一个场景，反馈系统issue。开发人员基于issue对系统影响和对业务impact判断，适当的修正系统或记录业务需求，根据业务优先等级，集成进下一个演进阶段。 里程碑：UAT Sign off。用户签收当前系统功能

区别与联系：
SIT是集成测试
UAT是验收测试
从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。
从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试。
它们两个之间的专注点是不一样的.UAT主要是从用户层面这些去考虑和着手测试,而SIT主要是系统的各个模块的集成测试
http://blog.csdn.net/kaiwii/article/details/9446243

 

根据项目特点，将核心关注定位于：安全、稳定
通过在云上扩展，来解决并发量大的问题。通过云服务商提供的路由级DDOS防御措施，来提高系统的稳定性和安全性。
请求黑洞：ddos的一个请求发到服务器后，服务器不再响应。就像所有物质遇到黑洞后，都有去无回

黑洞路由
黑洞路由，便是将所有无关路由吸入其中，使它们有来无回的路由，一般是admin主动建立的路由条目。
提到黑洞路由就要提一下null0接口。
null0口是个永不down的口，一般用于管理，详见null0的词条
admin建立一个路由条目，将接到的某个源地址转向null0接口，这样对系统负载影响非常小。
如果同样的功能用ACL（地址访问控制列表）实现，则流量增大时CPU利用率会明显增加。
所以，设置黑洞路由一直是解决固定DOS攻击的最好办法。
相当于洪水来临时，在洪水途经的路上附近挖一个不见底的巨大深坑，然后将洪水引入其中。
黑洞路由最大的好处是充分利用了路由器的包转发能力，对系统负载影响非常小。
在路由器中配置路由黑洞完全是出于安全因素，设有黑洞的路由会默默地抛弃掉数据包而不指明原因。
一个黑洞路由器是指一个不支持PMTU且被配置为不发送“Destination Unreachable--目的不可达”回应消息的路由器。
可以这样看:
如果一个路由器不支持PMTU并且配置为不发送ICMP Destination Unreachable消息数据包，那么源主机可能发送一个永远得不到路由的大数据包。因为路由器没有给源主机发回应消息，主机不能确定PMTU就是问题的所在。但如果源主机端启用了PMTU，则源主机在重试几次大的MTU之后，如果还收不到路由器的应答，那源主机自动将PMTU设置为576bytes.

http://blog.csdn.net/hbu_dcf/article/details/6387453
http://blog.csdn.net/dszgf5717/article/details/50244237

请求转发和日志管理，使用了nginx在收到请求时打日志，然后elk来收集Nginx记录的日志。nginx相关知道要重点熟悉一下

redis的问题，并发量比较高redis连接会不够用，这时云服务提供商redis服务的价格比较贵了，需要自己搭建主从结构的redis缓存。这个搭建及使用的相关需要熟悉一下。自己搭建redis服务，为了保证可能性，需要使用KeepAlive来自启动

 

因为java应用使用apache commons pool来管理redis连接。这个开源组件需要深入了解下。java应用到redis服务器的一个连接，对应ObjectPool里的一个PooledObject,如果的确是连接不够用，则自己搭建redis服务器，使用ssd盘，再配一块好的网卡，通过内网连接即可。

java 应用方面，可能需要在使用redis连接方面进行优化。事务是否能降低对redis的连接具体代表什么意思，因为一个事务中要多次向redis服务器请求，这个连接的复用到底是什么含义，是指Commons pool中不再新创建PooledObject，使用已有的，还是Commons Pool中每个PooledObject是保持与redis服务器的一个长连接。

确定事务中降低java应用到redis连接的确切含义，看看降低的是什么连接。 Commons pool中的PooledObject是否与redis服务器保持长连接。

 

 

关于互联网公司对接口测试的看法：

（1）好处：一个接口测试人员，可以成为app和后台的防火墙，能提高app的联调效率。
理由是：接口测试人员已经会测出一些bug，这样后台接口提供给app使用时，就会提高效率
（2）看格局：app 后台接口开发完成-->接口测试人员（有一台接口测试人员的测试环境）-->app开发人员使用的环境（准生产环境的测试环境）-->发布到生产环境

产品提出的需求，需要测试人员，开发人员共同了解（大多数情况下了解的并不一致),这中间就会扯皮。经过接口测试，肯定还有bug，app开发人员发现bug，反馈给测试或开发，测试开发更改后，发布到SIT，然后测试人员测试完成后，再发布到UAT，由app开发人员使用。

app发现bug，到修复，至少要部署两次，测试两次（开发人员的那次也算吧。从流程上看，开发人员的代码质量堪忧！！）


现在暴露的问题：
（1）从开发完成到app开发人员能用，链条比较长，周期也比较长。换而言之，就是开发人员不行嘛

一个是开发人员开发习惯或能力不行；开发人员、测试人员、产品 三者之间对同一个功能点理解可能 都不一样。中间的扯皮也很耗时间
（2）app开发时发现bug，到修复完成，需要的时间比较长。原因见上

作为业务不是很复杂的小公司，小项目，没必要搞接口测试人员。
理由如下：
参与的人越多，对同一功能点的理解分歧的地方越多，内耗（浪费时间）也越多
小公司项目开发要快速迭代，缺的就是时间，因此少一个环节，就可以提高效率

下一个问题：
开发人员开发质量的问题，如果自己都搞不清楚相关逻辑，怎么可能开发正确。
需要调整开发习惯，提高开发质量。

提到的“秒懂”的问题，的确是一个问题，与人打交道的确是一个问题，遇到官僚习气比较重的人，需要怎么处理呢。  少搭理，根据岗位做自己该做的，其它的不与其它产生交集即可。

不讲办事方式和方法的领导力，就是耍流氓。的确。


Leader需要具备的物质：领导力，沟通能力，执行力

领导力：不知道在说什么，不就是顶着一个头衔
所谓的领导力，体现在沟通能力上，不就是看人下菜碟。也就是君君臣臣的逻辑，买的一方，会对卖的一方，多一点迁就。表示出现的就是热情的称兄道弟，在话语上，对方怎么爽，怎么拍而已。

沟通能力，是不是就是按照对方能懂的方式，把相关意图，让对方能明白？？  只要能达到这个目标即可

执行力，具体在开发上，会纠结于一些细节，而忽略了具体是要做什么了。按照敏捷小步快走的逻辑，就是手推车、自行车、摩托车、三轮车、小轿车

喜怒不形于色，和什么人都能打交道。是因为目标明确，只要不影响目标的因素，都可以自动忽略掉，把目标完成后，就结束沟通即可。  格局。

 

沟通不是说话，是完成一个目标。  说话仅仅是沟通的一个途径，一种表现形式

听到不喜欢的，喜欢皱眉 

我懂你很难，改变你也不容易，那就让你懂我，这样相对而言容易的多

满足虚荣心，拿好听话甜乎


面对有权势的人，巴结一下，也很正常嘛

高层，需要正常规划和分解所有的工作，发放到下面去
然后由公司各个阶层的人，完成这些工作，
创造出利润，才能给股东一个交待

公司所有员工 围绕的轴心是什么？
工作

轴心就是工作

上司看到的不是员工之间发生了什么，也不关注这个工作是谁完成的

没有检查前面的内容，但在最后签字，这就代表要为所有的内容负所有的责任

签字意味着承担所有的责任