phpstorm或vscode使用psr2规范

  • 安装composer
  • 全局安装phpcs
composer global require squizlabs/php_codesniffer

vscode直接插件搜索phpcs安装

phpstorm

全局安装phpcs后,会在C:\Users{user name}\AppData\Roaming\Composer\vendor\bin下生成一个phpcs.bat,后面会用到
- phpstorm -> setting
- languages & Frameworks->PHP->Code Sniffer点击Configuration右侧的按钮
- 找到刚才的phpcs.bat,点击Validate,确认
- Editor->Inspection->PHP
- 双击PHP Code Sniffer validation,点击Coding standard右侧的刷新按钮,然后选择psr2,确定

参考链接: 如何优雅地使用phpstorm?

postman 实现API自动化测试

编 写:袁 亮
时 间:2017-01-16
说 明:postman 实现API自动化测试


一. 实现目的

  1. 接口开发调试工具
  2. 自动化测试
  3. 接口用例团队内共享
  4. 降低接口文档编写成本

二. 实现流程

  1. 团队使用同一份文档
    测试文档存入代码仓库
    使用前从代码仓库拉取导入
    修改完之后,重新导出,并更新代码仓库
    ps:后续为了降低代码层级,可以将API分成很多个collection,前期先合并成同一个

  2. 使用工具产生文档
    postman:界面gui模式
    newman:服务端cli模式

三. postman产生文档

  1. 通用层实现 在collection上做
    • 所有接口都先放在同一个collection,后期根据模块拆分
      方便在同一个collection上实现一些通用逻辑
    • 环境变量支持
      appid: 10101
      appsecret: 8e2160ec2b07f1faca9055be530bf09d
      host: http://api.shop.ci123.com/
      maxtime: 300
    • pre-request中实现签名
    • tests中实现统一的校验
      http状态码 200
      返回json,并且需要包含state和mess字段
      接口超时时间
      签名出错
  2. 目录层级规范
    • 根据模块不同,创建不同的文件夹
    • gui展示的原因,目录层级最多3层
    • 每一个接口,都是一个文件夹 (所以实质上除了collection只有2层目录)
    • 最底层的文件夹下,所有请求都是同一个接口的不同用例
  3. 具体实例实现
    • url地址
      {{host}}/Item/getSkuByItemId?appid={{appid}}
    • post参数增加两行
      expire {{expire}}
      mdstr {{mdstr}}
      ps:因为request只读的原因,不能追加,只能在每个地方都写一次这个
    • 填入其他请求参数,构造每一种apiReturn的情况
      一个用例只实现一个对应apiReturn,这个return可能有多种情况,放在examples里
    • 每个用例,必须增加tests,来告知是否通过
      除了最终成功的那个请求,其他请求的tests主要就是校验state状态码即可
    • 执行成功的用例校验
      写请求:一般是校验对应的id是否正确,比如订单id,商品id等
      读请求:解析对应的json数据格式,是否包含什么样的字段等等
      ps:后续谁有空可以看下,是否可以自己定义模板,现在看到的那些模板只能选择使用,不能自己创建
  4. 开发调试规范
    • 从代码仓库把文档导入到postman
    • 接口编写过程中,使用这个来进行调试,所有情况必须测到
      有多少个state返回,就最少有多少个接口用例
    • 接口全部写完之后,必须通过runner来确保所有用例全部跑通
      不要出现改到后面,前面的跑过的用例又跑不了
    • 写完之后,把postman里的数据导出到git仓库中

四、自动化测试 todo

  1. 安装newman环境
  2. 定时或者在git的钩子里设置
  3. 拉取对应的文档,执行测试
  4. 测试结果入库
  5. 展示报警
    工作台展示
    邮件、短信报警

五、postman常用操作

  1. 设置
    皮肤设置
    返回值解析设置:json auto的时候,没有自动识别是json
  2. 环境变量设置与使用
  3. 数据导入导出
    collection导入导出
    整体导入导出
  4. 复制修改
    用例复制,文件夹复制等
  5. examples使用
    可以配合做mock server
  6. runner使用
  7. console控制台调试
  8. 搜索
  9. API文档发布
    免费版有限制,可以大概看看
  10. 官方文档,可以快速看一遍
  11. 错误提示
    特别是全局变量中的
  12. runner里执行的时候,一定要注意request的是要保存里的,不然更改了是无效的
    send本身是直接起效
  13. ctrl + s保存修改
  14. Codeception

bug来源与如何避免

前提更要:从初来乍到,到熟悉业务核心代码。总有一天我们要去更改或者升级核心内容,对于逻辑复杂业务繁多的功能模块或者是流程,如何能够完成更改或者升级,且避免bug的出现,保正新旧业务流程能够正常使用。
目录

bug来源与如何避免
目录
一、修复现有的bug
二、首次开发新项目
三、二次开发
栗子:

优惠券使用经历4次bug修改
满减赠的二次开发:增加N元任,选前台购买涉及到分摊优惠,对分摊优惠进行重新整理(在尽量不改的原有的其他功能的逻辑的基础上,对代码整合个更改,便于可读和后期的再次开发)
抢购超卖的问bug,库存不足,则返回生成订单失败
一、修复现有的bug

步骤:bug怎么产生的 -> 快速定位 -> 熟悉代码 -> 改bug ->测试bug

开发前须知:
1.1 bug是如何提出来源:用户、不正常的数据、运营、开发人员操作
1.2 快速定位:(apache的错误日志、重现操作、数据库错误数据)
1.3 熟悉原有的代码逻辑,清楚了解如何更改现有的代码
开发后测试
2.1 该bug是否对原有的逻辑流程或者数据造成影响(较难,主要是细心)
2.2 除了此bug外,造成bug的因素是否还存在一定的潜在影响
2.2 改完后,会不会导致其他的功能不能正常使用,(必须测试)
例子一:优惠券分摊不均衡,10元优惠券分摊到两个价格相同的商品上,分摊金额是2.5 :7.5 应该是 5:5
例子二:检查订单是否能使用某张优惠券,以用户已经领取到的优惠券为判断依据
coupon,user_coupon
ps:优惠券使用经历4次bug修改

二、首次开发新项目

开发前须知
1.1 熟悉需要开发的内容
1.2 列需求文档、api接口
开发后测试
2.1 测试各个接口
2.2 所有需要走的逻辑流程是否正确
优点:对开发内容和功能了如指掌,确保接口程序无误即可
缺陷:初次开发,考虑简单需求,虽尽可能完善,但仍会有某些功能忽略掉,后期会进行二次开发
三、二次开发

难点:必须熟悉项目整理流程

开发前须知:
1.1 熟练掌握现有的功能和代码逻辑
1.2 了解二次开发目的和内容
1.3 清楚二次开发的程序如何写,且尽可能不影响原有的功能(是在原有的基础上扩充还是另写,或者合并)
开发后测试
2.1 局部测试:新增的功能是否能正常使用,所更改的代码是否对原有的逻辑造成影响
2.2 全局测试:对原有的功能进行测试,
缺点:对原有的功能块和程序逻辑不熟悉;若代码逻辑负责,业务繁琐,修改很容易出错;因新增加功能,对代码进行整合,也很容易出问题
注意:逻辑过于复杂的话,测试时不可能每种情况都测试到,所以需要自己审核代码

及时反馈

1、任何事情,做之前,请预估相应的时间,并告知相应人员需要多久完成

2、做到一半或者2/3时候,觉得做不完,请提前告知相应人员,现在是什么进度,预计还要多久时间,不要出现时间到了,别人来问,结果说没完成

3、请主动反馈进度和结果,不要等其他人来催,催你基本上是代表了对方对你不信任和不满

每周四,分享会要求

1、每周四下午4点半到6点,团队进行技术分享会

2、按顺序,每人主持一周

3、主持者每周一,预定会议室

提前一天,收集所有成员的分享内容,并了解他们需要什么环境演示

会议结束后,需要对这次会议做邮件总结,并发送给所有参与人员

4、任何人不得以任何理由借故不来,或者说事情没做完,不能开会

5、新人从第三周开始参与,前面两周看看其他人是怎么做的

开发部署上线流程

袁亮,15:37 2014-2-13,开发部署上线

说明:
1、本流程主要适用于工作一年内的新人,半个小时内就能搞定的,可以不用按完整的流程来,其他的都需要遵守
2、时间不是太急的情况下,老员工也尽量按该流程来,以降低风险
3、另外,每个程序员都是这么一路犯错下来的,你的水平基本上跟你犯过的错误是成正比的(同一个问题一犯再犯那就另说),所以我们需要学会犯错之后学会去避免它,并且善于从别人的错误教训中吸取经验。

一、需求确定
1、开发之前,必须要明确本次开发的目的,以及实现的方法
a、每个人提出需求的时候,一般都会根据自己的理解、现有的水平,给出相应的解决方案,至于这个方案好还是不好,那就很难说了,所以开发之前,涉及到的相关人员必须要清楚,这次做的根本原因是什么?有没有更好的方法?
b、需求的确定决定了这次开发是否能顺利完成的80%,很多时候,一个很小的改动,可能会减少你们50%以上的工作量。

2、需求的分期完成
a、我们有太多的工作是做的差不多了没上线,或者做着做着就没音讯了,大部分的原因都是因为需求不合理,以及任务分期不合适,总想着事情能一步到位,这会导致开发成本过高,系统太复杂,不敢上线(影响太大),复杂度上升导致bug过多,或者达不到预期,从而导致一堆人花了很长时间的努力全部白费。
b、要学会将一件大的事情,分割成多个小的、可快速完成的事情来实施,快速迭代开发。
c、开发的工作日尽量不要超过3天,1个星期的工作量的就已经是很容易半途而废的了。

3、需求确定之后,开发过程中,不要随意更改、添加
a、在需求讨论的时候,可以把以后可能会扩展的尽量想到,最终的目标等都可以讨论,这个时候需要尽量的详细
b、但在一期开发的时候,只做最核心、最急的几件事情,要做的东西太多,最终只会导致什么都做不了
c、达成共识之后,请需求发起方将讨论确定下来的内容通过邮件的形式发送给相关人员,邮件标题需要有统一前缀,例如【违禁词汇后台改版】- 第一期需求

二、开发过程
1、线上项目修改,必须要有svn,并确认正式版上的相应文件是否已经提交到svn中,并在测试版进行同步
2、开发新功能,必须先在测试机上开发,严禁在正式服务器直接修改
3、需要有相应的测试版数据库,可以找运维组的同学帮忙
4、开发过程中,有不清楚的,需要及时跟需求方进行沟通、反馈
5、必须有修改记录,修改记录里需含有:
a、数据库结构变化,注释
b、新增了哪些文件,做什么
c、修改了哪些文件,分别是为什么
d、各个功能对应哪些文件
6、开发完成之后,需要发送测试确认邮件给需求方,测试之后需要通过邮件回复正式确认,例如【违禁词汇后台改版】- 测试确认

三、部署上线
1、发送邮件,请求运维组同学帮忙备份程序、数据库,并帮忙观察下监控情况,例如【违禁词汇后台改版】- 上线前备份监控
2、将上线步骤通过邮件形式发送给相关人员,没有异议之后,开始下述上线操作。【违禁词汇后台改版】- 上线部署步骤
3、备份完成之后,部署程序到正式版,所有文件更改必须通过svn来更新,不允许直接copy过去上线
4、数据库结构修改部署,先于程序,更改之后马上看下页面以及相应监控是否正常
a、新增:一般不影响旧程序,可以在程序上线之前改,特殊情况自己考虑
b、修改:改了数据库结构之后,旧程序会报错,怎么办?
c、删除:可以在程序上线运行正常之后再删
5、程序文件部署
a、确认正式版的对应文件没有人直接在服务器上修改,如果有,则将正式版的提交,然后在测试版up,再重新进行测试
b、文件新增的,可以在程序上线前更新到正式版
c、更改旧有文件的,如果是后台的,可以先更新后台的,观察没问题之后,前台的如果耦合度不高,可以一个模块一个模块的上线测试
6、上述几步没问题之后,让相关人员在正式版把各个功能都测试一下,并看看其他地方是否会受影响
7、查看相应的数据统计及监控(页面访问、51yes统计、cnzz统计、运维监控、用户反馈)

四、部署出错处理
1、出现问题之后,立即通知相关人员,特别是需要告知自己的leader,协助修复,如果预估修复的时间超过10分钟,项目较重要,则请运维组的同事帮忙进行恢复
2、恢复到旧版本之后,在测试版排查是什么原因导致
3、重新发送新的上线部署步骤邮件,再重新部署
4、没问题之后,邮件告知大家,什么原因导致部署失败,以及如何避免

五、上线后的观察、维护
1、将整个开发过程的开发记录添加到tech后台
2、上线后的一周内,都要时不时的抽时间去了解下相应情况(使用情况、效果如何、用户反馈、有什么不足等)
3、将收集到的情况做相应记录,并记录到后台,为后续开发做准备

php代码规范以及项目开发规范

袁亮,2014-08-26,php代码规范以及项目开发规范,mysql规范

一、命名
1、文件夹、文件名
1.1 只允许小写字母,数字,下划线组成,不允许出现其他字符
1.2 以统一的功能模块名加操作类型命名
1.3 比如:user_add.php,sub/user_add_sub.php
1.4 add_user.php sub/add_user_sub.php 这种写法是不友好的,不要这么写
2、类名
2.1 只允许英文字母,数字组成
2.2 驼峰规则,每个单词的首字母大写
2.3 比如:class BlogPosts{}
3、函数名
3.1 只允许英文字母,数字组成
3.2 驼峰规则,同类名,第一个单词首字母小写
3.3 比如:function postAdd();
3.4 命名以模块名+动作类型命名,比如postDetailGet();而不是getPostDetail,并且将同一个模块的函数尽量放一起
4、变量名
4.1 只允许小写字母,数字,下划线组成
4.2 单词之间以_连接,除循环中之后,不允许出现单字母变量
4.3 善于临时变量,有些变量使用1-2次之后,马上就没用的,可以使用$tmp来命名,减少想变量名的苦恼
4.4 所以的sql语句,都用$sql命名,并且最好是定义完就使用,后面不会再次用到
4.5 常用变量名:
$page:分页页码
$limit:每页显示多少条
$ip:用户ip地址
$dated:当前时间
$ms:mysqls操作类实例
$pager:存放分页的html代码
$data:当前页面主要的数据
$user_id:用户id
$username:用户名
$nickname:用户昵称
5、全局变量
5.1 命名规范同变量,但加前缀g_标示这是一个全局变量
5.2 比如:global $g_username; $g_username = 'yuanliang847';
6、常量名
6.1 只允许大写字母,下划线,数字组成
6.2 比如 define("USER_PASS_MDSTR",'D123#!@ax?DSAD');
#7、session名称

二、php最后结束符
1、不要使用短标签<??>
2、每行后面必须加;号结束
3、纯php文件,最后不要加?>结束符,防止因为最后的空行等输出导致bug

三、单引号、双引号
1、纯字符串的时候,使用单引号
2、字符串中有变量的时候,使用双引号,并且变量必须以{}包含起来,比如$show = "你好{$nickname}!";
3、数组中,非数组下标,一定要加单引号,比如$data['username'] = 'yuanliang847';
4、sql语句中的变量值,以单引号包含起来,比如$sql = "select * from `users` where `username`='{$username}' limit 1";

四、括号使用
1、所有大括号的开始部分都跟在关键字的后面,没有例外,比如:
function getRow($sql){

}
foreach($data as $k=>$v){

}
class Mysqls{

}
2、小括号跟关键词相连,不需要额外的空格
if(1 == $a){

}else if(2 == $b){

}else{

}
3、函数参数左右不需要额外空格
function test($a,$b = 1){

}

五、空格、缩进、大数组缩进
1、所有缩进,均以tab进行缩进,不要使用多个空格
2、空格使用情况:
2.1 $username = 'yuanliang';变量赋值,前后加空格
2.2 比较操作符、算术操作符、逻辑操作符,前后加空格
+= , >= , <= , ==
+ , - , * , %
&& , ||
2.3 一元运算符,不需要空格
++ , -- , ! , &
2.4 对象运算符,不需要空格
$this->test();
parent::test();
3、大数组缩进方式,前面通过tab缩进到 同一层次,=>后面的是一个空格,数组只有1-2个值的时候,不需要写成这样
$data = array(
'user_id'    => 1535917,
'username'    => 'yuanliang847',
'nickname'    => '暗夜御林',
'head'        => 'http://i.ci123.com/153/1535917.png',//这种最后一定要加逗号,否则容易出错
);
$uinfo = array('username'=>'yuanliang847','nickname'=>'暗夜御林');

四、安全
1、需要过滤的外部数据:$_GET,$_POST,$_COOKIE,$_SESSION(session因为有可能存储了用户输入的内容,从而导致危险)
2、如果接收的是整形数据,一律以intval强制转为整形
2.1 比如 $user_id = isset($_GET['user_id'])?intval($_GET['user_id']):0;
3、如果是字符型,则需要调用防止sql注入的函数,进行过滤,该函数,在通用的function.php中就有
3.1 比如 $username = isset($_POST['username'])?stripSql($_POST['username']):'';
3.2 stripSql第二个参数,默认会调用stripTags,防止xss攻击,如果内容允许html等,则给定第二个参数
3.3 如果大串用户输入的内容,是会显示在页面的,比如文字内容等,可以使用htmlspecialchars将html实体化
4、接受外部参数的地方要在页面头部,或者函数开始位置全部获取所有可能接受的外部参数,该段代码之后,不允许再直接使用外部数据
5、如果是旧项目,需要改的地方太多,可以引入360的过滤文件,对所有外部危险输入进行过滤,并记录
该文件慎用,特别是在重要项目中,容易导致误判

五、功能块

六、注释

其他:
1、不要使用复杂的异或等逻辑判断(考验运算优先级的)
2、三元表达式只用做最简单的不赋值,不要做复杂的代码
3、不要让代码读起来有歧义,尽量简洁明了
4、不要写非常“巧妙”的代码,而是要让很二的人一眼就能读懂
5、不要使用or and,使用&&和||代替,优先级不同
6、少用while循环,太容易造成死循环
7、switch case 每个环节必须有break,否则会出错
8、理解清楚return continue break的意思,不要乱用
9、包含文件,一律使用include_once
10、嵌套层次最多4层,消除嵌套方法
11、循环中不要计算数量,有些计算能放在循环外面就不要放在循环里计算
11、大括号不可省略
12、使用construct 和 destruct,不要用与类同名的函数初始化 __get __set __autoload禁用
13、只用die,不要使用exit
14、不要使用嵌套式的赋值
if($a = ($c = getName())

做事优先级

dear tech4:

一、多件事情,怎么确定优先级
1、5分钟内就能搞定的事情,优先搞定,不要拖着
2、其他事情,按事情的重要程度来安排处理
3、更上级安排的事情,优先处理,比如员工群里,程总发现的问题或者南哥直接安排的事情
4、安全漏洞以及服务器出问题,需要迁移,请务必当成最重要的事情去做

二、同一件事情的处理优先级
1、第一优先级,东西是可用的
2、第二优先级,东西是好用的,包括代码的健壮、高效、易维护等
3、最后,才是自己是搞的很清楚的
因此,做事情前,必须要先去看看别人是怎么做的,不要想着什么都从头开始做,包括我们自己网站的内部资源,其他比较好的网站是怎么做的,百度或者google找到别人的demo,然后开始去处理。
给我看东西之前,都需要做好准备,我会问你“其他人是怎么做的?”,最好是能主动给我一个满意的答案

周报要求

13:14 2014-3-13,袁亮,周报要求

时间:每周日中午12点前
标题:【2014-02-24至2014-02-28】周报-袁亮
内容:
	一、本周做了什么?
		ps:主要工作记录下来即可,不要细化到改个链接什么的
	二、最有成就感或者最不爽的事?
		ps:学到了一个比较牛逼的东西,或者做了一个有意思的东西,或者做了一件自己觉得不想干的事等等
	三、有什么不足或者需要改进的?
	ps:自己的个人疑惑,或者自己哪方面还需要加强?团队中哪方面不合理的?个人或者团队内部的都可以

	其他:
	1、周报内容写在邮件正文里,可以提供附件作为备份参考,但不允许出现只有附件,没有正文的
	2、邮件的排版,参考看下其他人的邮件是怎么写的,不要写的乱七八糟,包括换行,缩进等,归纳总结
		如果自己都不能写的有条有理,那这个总结效果必然很一般
	3、周报发送给自己的直属领导,抄送我