1.参与需求评审

业务，开发，测试三者看似是不同的个体，但实际上的工作是紧密相连的。测试人员往往在开发阶段才拿到业务需求说明书开始编写测试案例，这无疑会降低测试效率。需求评审环节有助于快速全面了解客户需求，它会节省后续测试人员了解业务需求的时间，并且测试重点难点都可以借此机会在会上阐明，经过讨论找到解决方法。

点击添加图片描述（最多60个字）

2.借助业务流程图编写测试案例

　　对于一些比较复杂的需求，由于其分支路径较多，测试时容易忽略个别情况。这时尽量根据业务需求绘制业务流程图，或者询问开发人员在编码时是否有参考相关业务流程图。业务流程图能够直观清晰的表现出各个分支路径的情况，有效的避免了测试案例不全面的现象。

　　例如，我在进行对公账户冻结相关交易优化的测试工作时，根据短短几行的业务需求，绘制出了及其复杂的业务流程图。下图是简易版本，着重描述了部分冻结强制扣划分支的业务逻辑，相关公式和数字用字母替代。对于这样的需求，如果不绘图或者制表，很难设计出全面且正确的测试案例。但是经过和业务人员、开发人员讨论，确定详细的业务流程图后，测试案例的编写自然而然不会有任何遗漏。所以，对于多分支的业务需求，应该善于绘图，利用图表明确测试思路。

点击添加图片描述（最多60个字）

　　冻结扣划流程图

3.业务关联系统分析

　　在测试领域，关联系统分析不充分是发生变更的重要原因之一。服务方系统接口有变动，相关消费方系统调用该接口的功能都要根据情况有所调整，或者进行全量回归。因为跨系统调用，往往涉及多个开发人员，大家对彼此的系统了解度不够，进行关联性分析时要格外严谨。

4.完整的业务场景

　　业务流程往往会形成一个闭环，开户-启用-销户、冻结-续冻-解冻、签约-维护-解约，因此业务场景尽量要完整。例如，开销户在设计时逻辑可能会有所差异，在开户时对新开账户和转出账户的客户号一致没有进行判断，但是在支付和销户时却要求客户号一致才能进行交易，因此存在可以开户但是不能销户和进行其他操作的风险。所以在进行案例设计时，虽然改造点是开户交易或者签约交易，但是应尽量对一个完整的业务流程进行测试工作。

5.日期

　　日期在测试时是一个非常重要的因素，也许当天能够做成的交易，切换一下会计日期或者修改一下交易日期就会失败。例如，在测试多级账簿余额调整时，原交易日期为当前会计日期，则交易信息正确，原交易日期小于当前会计日期，则收付款方多级账簿号则显示有误，原因是不同的交易日期对应的程序分支不一样。因此，在设计案例时要充分考虑时间因素对交易的影响，分析是否需要设计各种日期取值。

6.缓存数据

当对测试数据有严格的要求时，例如涉恐信息，应当注意缓存数据的影响。比如先输入一组有效的数据，进行提交，交易进行到一半时终止交易，这时交易信息不会清空，然后修改为无效的测试数据，再进行提交，则有成功的可能性，而这是与业务需求相违背的。因此，当对输入内容有限制时，应确保缓存数据会及时清空或者更新。

点击添加图片描述（最多60个字）

7.测试数据类型

　　测试数据种类要丰富，例如本次改造涉及已到期临时户的情况，那么未到期临时户、已到期基本户、已到期一般户、已到期专用户、注册验资户、已到期外汇账户等等都要进行验证。往往缺陷都发生在关联要素上，而不是改造点本身，因为开发人员在编码时只对改造点进行单元测试，而关联要素则容易被忽略。

8.凭证回单

　　凭证回单一定要清晰直观，因此在交易成功后需要检查凭证回单的显示情况。重点应检查当交易信息量较大时用省略号替代的交易信息是否为重要信息，比如金额、账号等，以及印章是否会遮挡住部分重要信息，客户签字是否有足够的空间等问题。

加我VX：atstudyIT  回复关键词“测试”领取限量软件测试学习资料哦~~

拿到一个性能测试任务的时候，我们首先需要明确我们的测试目标和输出结果是什么；没有计划的开始注定是失败的。做性能测试需要一个规范的流程，划分清各个阶段需要做哪些工作，这样我们在接到一个任务时就不会手忙脚乱。

性能测试流程大致分为一下几个阶段：

1、测试准备

2、脚本开发与调试

3、测试执行

4、测试结果评估

5、测试后跟踪

测试准备包括：

1、测试目标：

从需求文档或者用户获取：并发用户数，事务吞吐需求，响应时间需求，系统占用资源需求，可扩展性需求等；

2、应用软件：

从开发人员获取：系统整体架构（BS/CS），采用开发语言，通信协议，动态session，验证码等；

3、系统部署平台：

从运维人员获取：物理部署（局域网/虚拟机），硬件架构（CPU/MEM/IO），操作系统，数据库（版本/启动参数/存储布局），中间件（参数配置），部署模式等；

4、系统负载模型：

通过调研获取：从业务层面选取关键用例吞吐率以及用户行为习惯，确定测试流程及流程业务比例；从系统负载方面了解高峰/平常场景吞吐率；

5、制定测试计划和测试方案

测试脚本是做好性能测试的基础，监控结果是性能测试的关键；扎实的代码基础和熟练掌握监控结果的收集和分析是性能测试的保障；系统上线后，对实际负载与性能情况和测试过程中做比较总结经验也是学习提高的好方法。

在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？
Bs结构程序一般会关注的通用指标如下（简）：
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况
当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。

一般软件可以按照系统架构分成几种类型：
c/s
client/Server 客户端/服务器架构
基于客户端/服务器的三层架构
基于客户端/服务器的分布式架构
b/s
基于浏览器/Web服务器的三层架构
基于中间件应用服务器的三层架构l
基于Web服务器和中间件的多层架构l

总结：

总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这才是测试工程师最重要的能力。

还是那个观点，思想才是根本。

​

欢迎加入  51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ                    群：                   755431660

　　更重要的是要因材施教，针对不同的测试产品采用不同的测试方法，用努力提高效率的心态去分析测试对象，选择测试工具，才能保证你在测试工作中的付出与收获能成正比。

前几年测试刚刚火起来的时候，要求确实比较低，所以不少人都看中了这个行业，随之而生的各种测试培训班也成功地帮助不少人转行到了测试。可是经过这两年的检测，发现了培训班出来的人员能力有限，慢慢的就提高了要求。说实话，培训班就是快餐生产方式，他可以帮你从其他行业快速来转到测试这个行业来，只个领路人，给你展示一下测试都是怎么做的，需要哪方面的技术 ，可是如同读一本书，你只看书本就以为读懂了或是掌握了书的内容，那是很可笑的。

在我工作当中也遇到了不少从培训班出来的同学，整体来说他们有如下的共同点：

1，计算机基础知识比较差，不少计算机的正常操作都是他们的障碍。

2，不能清醒地认识自己，在培班班跟着老师写了一些儿程序，以为自己就会了，其实只是模仿而且，完全没有自己的思路，还自我感觉良好。

3，缺乏学习能力，证明自己的方法错误。有不少同学知识自己的能力差，为了表现自己就花大时间来做需求，可是就不出成绩，没有找到学习的方向。

4，由于能力有限，不能好好地表达问题。由于自己的能力有限，不能很好地定位问题，与其他人合作的时候表达不清，造成项目延迟，相关人员都要加班。

其实不管你是怎么进行测试这个行业的，有的是走培训班，有的是自己找工作的，这都不重要，重要的是你能为公司带来什么？你在工作中有没有成长？现实社会是很残酷的，如果你不成长，不学习，早晚会淘汰你的。下面我就从个人角度出来，来说一说非计算机专业的测试之路应该如何走才会轻松些儿：

1，理清思路，明确方向。

不管你以前是从事什么行业的，既然你选择了要做测试，就一定看中了测试的特点。无论是工作相对轻松，还是工资稍好一些儿，那就要为了这个目标而去努力，天下没有白吃的午餐，只做日常的工作是很能提升的，要有针对性的提升自己。首先我们要有这个理念，然后才能有明确的行动。

　2，认清自我，切忌盲目。

测试行业是入门容易，想走远比较难。而我们自己也要反思一下，自己会什么技术，听说过或是在培训班学习的东西，扪心自问，你真的会了吗？现在的培训班为了工作需要一般都会讲手工测试，测试工具的使用，自动化相关的测试，压力测试，服务器的搭建与使用，内容是不错的，但是短短的两三个月你真能都学会吗？任何一项测试都要花费上几年来不断完善的，学会和会用是两码事。

3，低调做人，有计划地成长

在你的技术能力有限的情况下，面试的时候就不要骄傲了，凡是自我感觉良好，目空一切；而没有真才实学的，根本不可能面试成功的。低调一下，态度良好，就有可能获得工作的机会。不管你以前学会什么，在工作的时候一定要踏实。可以理一下，按下面的顺序有计划地提升自己：

· 掌握计算机基础知识，操作系统的日常使用，windows or linux;文档办工之类的软件使用，千万不能因为这些儿知识影响了你的工作。

· 工作方法，与人交流的能力等软技能，不要小看这些儿，它们比技术更重要。说话听不懂，表意不清，生活习惯不好等都会影响你的工作。

· 常用测试软件的使用。软件只是工具，你不可能掌握所有工作的使用，但是你也不可能不会使用，如果工作需要有快速学习的能力。

· 基本语言的学习，如python，java，shell等。如果你有能力和兴趣，还是要学习一下的，不用太深，但也不能不会。

· 开源框架的学习，如webdriver，appium还有其他的一些儿框架，会使用这些解决工作中遇到的问题。

· 时常与公司的大牛交流学习，本来这个行业就是需要不断学习，跟着牛人学习比自己摸索学习的要快的多。

　4，要有危机感，防止温水煮青蛙

很多情况下我们通过自己的努力找到了一份工作，然后在工作中就按公司的要求来不断完成自己的任务。不过这远远不够，平时的工作只是你的本职工作，保质保量地完成是必须的。不过还要时刻想着提升一下自己，不然几年后你就会发现，只会公司的相关业务，使用公司的平台和工具，离开了这些你还有什么呢？公司不会管你以前做过什么工作，只会看中你以前的工作能为公司带来什么。明白了这一点儿，你就应该明白要做什么了。

最后社会和公司是不相信苦劳的，如果你不能很好地完成工作，影响了项目进度；或是其他人与你合作的时候严重受影响，大家就会给上级反馈情况。当你做到了你部门的人员都不愿意与你合作，提起你来就直摇头的时候，你就离离开公司不远了。就我们公司而言，外包人员三个月不符合要求，就随时可以换掉你；正式员工在试用期不合格，直接走人的。

如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~

从需求到用例设计

在项目中我们从拿到产品需求到最后的用例设计完成，都要经历哪些事情，包括今天要讲的用例设计方法是在哪个阶段使用，下面的图会告诉你答案。

设计用例方法

1.等价类

定义：把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类数据一般分为有效等级类和无效等级类。

构造测试用例方法：

1）明确需求

2）分析需求中包含功能数

3）确认每一个独立功能具有多少输入

4）确认每个输入的规则

5）针对每个输入设计等价类表：有效数据和无效数据。以三边是否能组成三角形为例 

  6）构造测试用例：输入和操作进行组合

2.边界值

定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充。这种情况下，其测试用例来自等价类的边界。

与等价划分的区别:

       1）边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。 

    2）边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

       构造测试用例方法：

       1）针对每一个输入规则设计等价类边界值表

       2）增加边界值数据：上点、离点

  注：上点是边界上的点；离点是指距离上点最近的点，开区间在域内，闭区间在域外。

3.判定表

定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

判定表的组成：

判定表通常由四个部分组成如下图所示：  

 1) 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次 序无关紧要。

 2) 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺 序没有约束。

 3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的 真假值。

 4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

 5）规则及规则合并

  A 规则 ：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

 B 化简 ：就是规则合并 。

 a.  有完全相同的动作桩；

 b.  条件桩中只有一个不同项

 构造测试用例方法：

 1 ）需求中 找到 条件桩：输入参数要满足的条件

 2 ）需求中 找到 动作桩：满足条件后得到的结果

 3 ）组合所有的条件桩形成2的n次方个组合，n代表条件桩的个数

 4 ）分析需求 中提到的 每一组条项桩所对应的一个或多个动作桩

 5 ）查看是否可以合并， 但合并时要谨慎，因为合并后容易发生漏测

 6 ）写测试用例，每一列对应一条测试用例（不存在的结果可以忽略，因没有数据可取）

 以下 是形成 普通 三角形 的判定表 ：

4.流程分析法（场景设计）

简介：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。类似于白盒测试中的路径覆盖，通过画流程图分析功能的路径。

  如下图所示，用例经过的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。    

快速画流程图方法：

1 ）从需求 中找到 判定条件（如果，假如，当）

2 ）将这些判定框罗列到流程图中（可以暂时不用考虑顺序），注意挖掘SRS中没有提到的隐性判定条件

3 ）先画基本流（正常路径），再画备选流（分支）

构造测试用例方法：

1 ）分析业务，画出流程图

2 ）根据基本路径写基于业务场景的测试用例（用例 数= 判定条件个数+1）

5.正交试验

简介：把影响实验指标的条件称为因子。影响实验因子的条件叫因子的状态（水平）。利用正交试验设计方法设计用例时,首先要从需求中找出影响其功能实现的操作对象和外部因素,把他们当作因子。而各个因子的取值当作状态。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

构造 测试用例方法：

1）从需求中找出因子（输入参数）

2）从需求中找出因子状态（输入参数对应的取值）并编号，画出因子状态表

3）合并或补充因子状态表，代入正交表

4）拆分正交表，替换成文字，一行是一条用例，以打印机功能为例，正交试验表如下：

6.因果图

定义 ： 是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

构造测试用例方法：

1）需求分析找出原因，然后给原因编号

2）需求分析找出结果，然后给结果编号

3）根据需求分析文档，分析原因与结果之间的关系

4）根据需求分析文档，分析原因与原因之间的关系

5）根据需求分析文档，分析结果与结果之间的关系

6）根据需求分析文档，画因果图

7）依据因果图去除判定表中不存在的组合

8）判定表中每一列对应一条测试用例

7.输入域覆盖

简介 ： 输入 的数据包含一些 易 引出内存溢出和内存泄露（区别，定义）的 类型边界 ， 或者一些特殊 值 如电话号码等。

构造测试用例方法：

1 ）SRS分析对应的输入参数是否存在特殊值和类型边界

2 ）若存在，则补充特殊值和类型边界的测试数据（检查是否会出现内存溢出）

8.输出域覆盖

简介：分析输出结果的形式（提示信息，输出的显示结果，数据库的记录等）

构造测试用例方法：

1 ）通过与开发的沟通，明确对应功能所有可能的输出结果有哪些

2 ）逐一罗列（输出的形式主要针对提示信息和显示结果）

3 ）检查对照现有测试用例是否已经覆盖了所有的输出

4 ）若没有完全覆盖，则根据输出结果要求，倒推补充测试用例  

9.异常分析

  定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性  的设计测试用例的方法

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。如网络异常、断电、服务器宕机等

构造测试用例方法：

1）根据需求分析文档，构造环境异常（网络、电源、服务器、程序关闭） 

2）补充异常测试用例

适用范围

通过上述的介绍，设计用例的方法这么多，如何选择使用哪种方法呢？文章开篇中的流程图，处理过程为什么用流程分析而不用状态迁移法呢？下面小编总结了各种方法的优缺点以及适用范围，希望可以帮助大家。

 我们在实际工作中，可能一个功能会存在多种情况，所以大家要灵活使用方法，必要时设计用例方法要进行组合使用，设计出的用例才能更全面。一般情况下，一份用例最少用到2种以上方法才能全面覆盖测试点。

如果有任何疑问，欢迎添加qq群测试入门到大神 755431660 共同学习~

主要关注点在：缺陷数，缺陷密度，缺陷修复时长 

目的：通过指标来判断 开发的质量从而进行分析改进，通过修复时效来 管控 开发对于BUG的响应及时性。

这是一个不错的改进开发过程中的质量的手段。

以下为一个实例：

​

一家主要是做一款APP的公司，公司技术部门有三个组：爬虫组、服务端组和APP客户端组。

事实回放：

1）每次运营或产品提出一个BUG给到测试工程师后。

2）测试工程师就会凭感觉和经验（而不是技能判断）判断这个BUG是哪个组，判断之后就会把这个BUG指派给该组的负责同事A。

注意：我们的绩效是按照每个团队每位同事产生的生产BUG去扣分的。

3）接收到这个BUG的开发同事A开始排查问题，花了半小时排查完之后发现这个BUG不是我这边的问题，于是就又丢给测试工程师，同时责备测试不应该把不是他的BUG指派给他，一来浪费他的时间，二来又影响他的绩效。

4）测试根据开发同事A的各种排查描述，得知这个BUG可能（是的，可能）是另一个组的开发同事B的问题，于是测试就把这个BUG指派给开发同事B。

5）接收到这个BUG的开发同事B开始排查问题（每个组的开发排查方式未必相同），顺利的情况下，最后排查得出这个BUG确实是我的。

6）开发同事B开始处理BUG，处理完之后给到测试验收，直到BUG关闭。

流程图如下图1：

图1

在这个过程中，还有隐形的多种问题：

1、验收在接收到测试工程师指派的无法确定是否是需要我处理的这类BUG时，会一直让这个BUG挂机在那不做处理，原因很简单，我花半小时去排查这个BUG，很有可能这个BUG不是我的。

2、开发经常性怼测试工程师，你怎么证明这个BUG就是我的？我就是不处理！还有你为什么总是把不是我的BUG指派给我？而测试工程师的回怼总是无力的“我怎么知道这个BUG是不是你的？”。

3、在互相扯皮的过程中，严重降低了“测试-研发”的合作效率。

　处理方案：

孔子曰“其身正，不令而行；其身不正，虽令不从”，对于测试工程师来说，打铁还需自身硬。提高测试工程师排查BUG的能力势在必行。

当测试工程师拿到一个BUG时，可以通过APP抓包和查找数据库表的方式排查这个问题到底是那个开发工程师的。

举例：在APP上有一张图片无法正常呈现出来，而这个图片是由爬虫工程师采集过来的。

　处理：

1）测试工程师先通过抓包的方式找出这个图片相关的HTTP请求内容，如果这个请求内容里面的图片URL为空，那么这个BUG很可能就是爬虫在采集数据或入库数据时出了问题，找出共性和规则给到爬虫工程师去处理。

2）如果这个图片URL是有值的，并且这个URL可以正常打开，但是这个URL的格式不是OSS的格式（服务端会把外面的图片保存到我们的OSS环境中），那么这个问题就是服务端在保存图片时出了问题，找出共性和规则给到服务端工程师去处理。

3）如果这个图片URL的格式是OSS，并且可以正常打开，但是只是在APP上无法呈现，那么这个问题就是客户端在显示图片时出了问题，找出共性和规则给到客户端工程师去处理。

如果测试工程师可以做到这样的话，BUG提交和处理的流程变成如下图2所示：

图2

当然，在这个过程中，测试工程师一要提高自己排查BUG的准确度，二要提高自己排查BUG过程可以给开发做参考的可用度。

扩展：

“作为一名软件测试工程师，需要具备哪些能力？”需要具备的能力很多，但是我觉得排查BUG能力是最重要，最有效，也是最容易被忽视的一点。

测试工程师的主要职责包括质检和质控，质检的东西大家都说的很多，质控的就比较少啦，我在这里也提一下。

质控一：上游工作质控

在产品刚立项、进行需求确认的时候，测试人员就会参与进去，仔细地Review需求，看需求是不是完整、有没有漏洞，这个时候还没有进入正式开发，修改需求对于项目组来说代价是最少的。在这个环节，测试人员凭借缜密的推演、发散性的思维，往往能发现很多需求的漏洞，提高了项目的整体效率。

另外，测试人员在完成测试计划、测试用例以后，会邀请开发、产品一起评审测试用例，在这个环节，由于测试人员把每个需求如何细化测试都体现在了用例里面，就相当于再次把需求分析了个透，往往还能发现很多需求的漏洞。这也是提早发现需求漏洞的有效环节。

质控二：下游工作质控

在产品完成了测试以后，就是发布的环节了，测试人员在发布的环节也能发挥作用。首先，测试人员为了部署测试环境，研究自动化部署的技术，可以把上线部署的环节也自动化，以前需要2个小时的部署环节压缩到半个小时甚至更少，而且更加准确可靠。

如果有些版本修改比较多，上线的质量风险大，测试人员会跟产品一起制定灰度发布的方案并在技术上进行实现，让版本先面向一小部分用户开放，如果发现Bug了，影响的用户也比较小，Bug改掉以后，再逐渐扩大用户范围。

另外，优秀的测试人员还会发动项目组的其他人一起来保证项目质量，比如推动开发进行代码Review；引入冒烟自测流程，让开发先自测以后再提交给测试做冒烟测试；通过在项目组分析Bug，让开发提高自测，降低Bug数量等；引入策划、交互、视觉在测试阶段进行走查等等各种措施。

转载：http://www.51testing.com/html/09/n-3725309.html

无论我去过多少家公司，工作到最后都会变糟。在我工作过的技术公司里面，早晚都会出现一些问题，这些问题要么需要做出管理方面的改变，要么需要对现有的管理风格迅速做出极端改变。但通常这些需要的改变都不会发生，然后我开始换地方，希望能遇到更好的管理。

   作为独立贡献者，我已经在大中小规模都有的好几家技术公司当过web后端软件工程师。我想通过本文卑微的努力把我所见到的事情、问题出在哪里、以及可能的解决方案是什么说清楚。我写这个是为了梳理自己的思路，同时也希望有人能从这些故事当中找到熟悉的东西，并且了解到并不是只有他自己才体会到这些。在某些情况下，这些看起来似乎是开发者的问题，但是开发者是在管理层创造的环境下工作的，所以我也把它们列进来了。

   如果你很忙的话，我已经把要点标出来了。不过，知道这些要点是什么意思会更好一些。

1、计划

　没有路线图，或者路线图很虚

  对成功应该是什么样没有想法或者想法很少的话，你是永远也无法实现的。项目的想法模糊会导致写出来的代码也含糊，运行“晚”（没有路线图的话你怎么知道呢？），以及各种沮丧。

  解决方案：制订路线图。

   路线图不以现实为基础（没有找工程师/利益攸关者进行估计，过程中没有检查点）

  管理层决定了一系列他们想要的事情，并且决定这个季度就要完成。但如果没有来自执行那些工作的人提供输入的话，那些设想可能就是空中楼阁。没有检查点去了解事情的进展情况的话，项目就会完成得很迟，往往太迟了以至于要重新确定范围，希望能完成点有意义的事情。

  解决方案：强迫那些负责做事的分解时间表，并且要合理化。让他们暂停写代码（很多开发者认为只有写代码才算生产力），先做完这个。对于好的、周密的估计要激励。

  路线图制订得太迟（在开发期间）

  先做项目，上路后才制订路线图。突然才意识到正在做的项目毫无意义。时间和精力还有士气都没了。

  解决方案：在开始工作前花时间制订路线图。你不需要预测每一种可能的未来，但是当你了解形势时就更容易把握好方向不至于撞车。

  路线图的极端改变不是因为环境变化，而是因为短视或者原先的计划缺乏周密性。

  某一天商业团队一觉醒来决定另一个项目的优先级应该更高，因为这样才可能有高速发展的走势，只是他们一开始没有事先花时间确定好事情的优先级。几个月的努力变成白费功夫，而这其实是完全可以避免的。

解决方案：认真对待路线图。好好确定优先级。除非商业方面发生了极端的变化，路线制订好就要坚定走下去。犹豫不决造成的损失比坏决定还要糟糕。致力于你说自己要做的项目。那是可以衡量的生产力。如果你对上一个优先级感到后悔的话，下个季度别再犯同样的错误了。

2、所有权

项目缺乏直接负责人

  项目是建立了，也分配给团队了。也许某人下达跟踪要完成工作的工单。一些人想起来的时候就去处理这些工单。经理偶尔会在邮件里面问问进展情况。开发者都是各自回答问题。结果表明该项目严重滞后，而且很多工作都没做好。

  解决方案：选定1个人，其工作是确保项目取得进展。这个人有权力跟经理去谈，如果必要的话可以申请更多的资源，但到头来回答关于进展情况并且推动事情发展的都是这个人。

  某个大项目只有一位工程师孤军作战

  每个人都忙着做项目。一个人有点空闲，然后被分配去做一个重要的项目。并行主义万岁对吧？错。这位工程师试图知道事情是怎么做的，但是得到的帮助寥寥，因为别人都很忙。没人审核她的工作。他们问什么地方耽误了她也回答了，但是没人对答案感到满意。她请求帮助但是被告知没有人有空。

  解决方案：除非你是在初创企业，已经快没钱，再过几周就要死掉，否则的话一个项目至少要分配2个人，理想的话3个最好。他们会提出问题的可能性要高得多，因为相互之间可以讨论工作，一起推进事情前进。而引入第三个人可以在设计决策和代码审核方面打破僵局。

  代码评审缺乏责任担当，不够彻底，指责代码作者

  来了一个pull请求。你很忙，这个人可能知道他们在做什么，只需要同意就可以继续你的事情了。轻而易举的同意谁不喜欢呢，对吧？再想想。看都没看只能说明你是个懒人。而且你还给别人开了先例，行啊，我以后也可以不审核代码了。当别人写的代码出问题时人家会说你不是看过了吗？代码是你批准的，负责也有你一份。

  解决方案：认真对待代码评审。如果你没有时间，把它分配给别人，或者问问pull的请求者是不是能够等久一点因为自己还没时间。我向你保证，你会对自己的所谓感到高兴的。

技术债务

  没有采取合适行动让旧系统退役，重写及/或撤除现有遗留系统

  到了一定时候，某个遗留的单一程序规模达到了像利维坦巨兽那样的地步，而且给web带来的灾难之严重已经到了妨碍开发的地步。现有的资深开发者处理相关事情的时候都有困难，新的开发者更是骂骂咧咧了好几个月才稍微提高了一点效率，奇怪的崩溃潜伏着，导致你的客户时不时会出现莫名的问题。但管理层总是优先考虑产品，并没有意识到技术债务拖累了他们非常渴望的产品功能研发。

  解决方案：企业必须赋予技术债务足够的优先级。遗留系统中最臭名远扬的问题必须优先处理。重写的工作必须按照规模大小依次处理。这会给将后的功能开发带来时间红利，连开发者的幸福感和寿命都会增加。大家常说开发者离开的不是自己的工作，而是他们的老板，但我认为很多时候，开发者离开的也是他们的代码库。

　开发没有必要写的系统

  “你有没有听说过那门很酷的新语言？我用周末的时间学了，现在想看看用到生产过程里面会怎么样。我听说挺棒的。”然后，一个用新语言开发的新系统做出来了，结果发现它做的东西跟某个现成的开源库非常类似，只是针对了比较特殊的用例，而且支持的开发者比较少。这个项目迟早都会延误，开发者离开了那家公司，可是在这个系统上已经浪费了很多大可不必的时间，但其实这些本来可以用在对业务很关键的工作上的。

  解决方案：这个问题比较棘手。需要有一位老练的经理知道什么对这种项目亮红灯，转而采用现成的解决方案，以及什么时候开绿灯。你当然不希望打压好的开发者，但是你也不想浪费时间精力。最好是让那位开发者写一份详细的建议书说清楚实现细节，然后进行详细的审查。也就是说，这是招到经验欠缺的经理可能会遇到的陷阱之一。

  把错全都归咎到遗留系统上面

  差点忘记，遗留系统。人人都喜欢喷原有代码，指责往往已经不在那里的开发者，因为对方无法还击。情况变得这么糟糕一定是因为那帮人太烂了，但我们比他们好。当然我们不会去修改原来的东西，我们的额外修改是必要，但我们比他们好，真的，我们保证。在别人的东西基础上增加修改要容易多了，它会让你琢磨为什么要有原来的东西。这会创造出一种抱怨没完没了的有毒环境，最终受害的将是代码质量和团队和谐。

  解决方案：尽管对原有的确质量不高的系统没完没了的抱怨可能会很有吸引力，但是请记住，正是因为原先的代码才让公司走到了现在，而那些有疑问的涉及决定也许是几次变更、商业决策以及紧急灾难共同造成的结果，这在任何快速成长的企业里面都是很常见的事情。某个东西很糟糕？做出具体计划改进它。要行动而不是抱怨，哪怕你的举措是慢慢削弱旧系统。你后面的人（可能也是你自己）会对此感激不尽的。

3、设计

  如果你在绕开系统弱点上面用的代码量多过利用其优点的代码量的话，就是坏设计

  有人有一个很棒的新设计，他们想实现这个设计，因为它比原来的那个好多了，原来的设计太糟糕。只是这么做会需要到处修补一下，但这完全是可以接受的，因为整体上新设计更好。直到后来才发现需要的修补的地方太多了，但是你已经全力以赴，没法走回头路了。

  解决方案：重新开始。沉没成本谬论是真的。你已经犯了一个错误，没关系，你可以吸取教训然后做出更好的。不要无奈地接受混乱。

  如果致力于这一代码库的大多数人都遇到了同样的问题，并且这些问题采用不同的架构时可以避免的话，就属于糟糕设计

  你会注意到同一段代码被拷贝粘贴到系统的每一个被牵涉到的地方。你问某人为什么，他们解释说“哦，那是因为这个系统因为某个原因预计要做这个，其实这不是真的，但听起来不错，所以大家只好跟着做。”你不知道为什么他们要这么做，但你很忙，所以就把这段代码粘贴进去然后继续自己的事情了。

  解决方案：我说的话听起来会很痛苦，但是，还是重构吧。重构整个东西，把那些拷贝粘贴都去掉。付出会有回报的。

4、编码

  随意编码。没有测试，或者测试糟糕。没有处理极端情况，而主要是编写基本逻辑（happy-path）代码

  “这里是初创企业，我们没有时间做这个，晚点再处理。这是可以接受的，”这些年来很多开发者都这么说，每个人都为最后的混乱局面贡献了自己的力量。未经测试就上线代码，产品出问题晚点再修复，哪怕写测试也只是测基本逻辑，或者甚至连这个都不做。

  解决方案：管理层可以强制要求测试的覆盖面，不过其实这并不是代码库测试是否到位的好的衡量手段。有效的办法是让周密的人对这些代码进行评审，让那些代码评审只是做表面文章的走人。不幸的是，不幸的是，当你招进来的工程师缺乏经验或者不够尽责的时候就会出现这种情况，所以招人的时候要擦亮眼睛。

　5、会议

  没有日程，或者日程不明确，没有可衡量的输出

  你查看日程发现自己有个叫做“系统讨论会”要参加，但是要干什么并没有描述，只知道邀请了10个人，要进行1个小时。身为好员工的你出席了，但是绝大部分时间内都是默不作声，只有其中的2个人在那里漫谈，到会议最后的时候，组织者拍拍那两个人的后背中断了同名的谈话，并且威胁着要再举行一次会议。大家的时间被白白浪费掉了，一点收获都没有。

  解决方案：在全公司范围强制执行一项政策，要求所有会议都要有日程，有可衡量的输出，只让必须参加的人出席，而且要有备忘录，看看会议的结果是否达到预期。一旦目标达成或者时间到马上结束会议。任何违背这些原则的会议，要么允许大家走人，要么允许将来不再出席。这样就会迫使大家做出改变。

  可以邮件或者私聊解决的会议

  你参加了一个会议，会议有可衡量的输出（耶！），但这只是一个只需简单回答是与否的问题，通过邮件或者私聊完全就可以解决。

  解决方案：是的，就用邮件或者私聊。用好你的常识，以及合适的媒介。

  该参加的人不参加不该参加的人却参加的会议

  你参加了一个有10个人出席但是主要设计师缺席的会议。大家都举手说了点东西，但到最后，所有的东西都被负责的人拒绝了。那天晚些时候，因为某些原因你出息了一个有工程负责人参加的会议，为的是审查了一下底层代码决策的事情，可是他在不了解背景的情况下对东西吹毛求疵，浪费了大家的时间（也包括他自己的）。

  解决方案：邀请每一个人参加会议都要有个好的理由。如果你想不出好理由，那就别邀请那个人。如果某件事情的主要决策者应该参与，那就邀请他。最重要的是，不要把可来可不来的人加进来。如果某个人是可选的话，那就不要邀请。就这么简单。这是一场公司会议，不是技术研讨会。

  为了开会而开会（站立会议，你究竟想从中得到什么？）

  你在参加每天的站立会议？大家讨论的都是你没有想法或者不在意的事情。你分享的东西可能跟他们也毫无关系。跟你有关系少数人你早就在会下交流过了，然后你报告说你们已经在私下交流过了，而且还会继续在会下跟他们讲。等一下，为什么我们还要站在这里呢？

  解决方案：如果你绝对必须知道其他人在做什么，把它写成文字以聊天或者邮件形式进行。但你会说：“哦，但是没人会看。”对。那是因为没人在意。可是你以为大声说出来他们就会在意了吗？作为这种日常仪式的结果你现在就会做得更好了吗？未必。不要再浪费别人的时间了，把焦点放在结果上面。要消灭一切无用的会议，尤其是那些重复性的、主要是出于惯例进行的会议。

  开会太早或者太晚。注意力广度很低，愤怒情绪高涨。你不会从这些会议中收获好结果的。

  现在是下午6点，有人还在开会。你的手紧紧握住了当天的第三杯咖啡并且祈祷这次会议要么有个好结果要么很快就会结束。很可惜，一件事情都没有通过。第二天早上你意识到有人已经安排了早上8:30的会议。你握住手里当天的第一杯还没喝完一半的咖啡希望有个好结果。有人问了你一个yes/no的问题，然后会议结束了。没开玩笑吧？

  解决方案：认真点。很多时候我们考虑事情都忽略了人的因素了。不要把会议安排得太早或者太晚，要安排在核心时间段。如果会议很重要，就需要马上进行。否则的话，没有什么事情是不可以等1天或者几个钟头的。那样的话，大家会更愿意出席，更愿意参与，你也更有可能得到想要的结果。

　6、流程

不评估当前情况就盲目遵守流程

  冲刺！谁不喜欢冲刺呢？我们行动敏捷。你什么意思敏捷可不是名词。我给它大写，必须这样。不管怎样，让我们大概一周左右都要冲刺一下，让大家弄清楚自己都在做什么。我怎么知道这么做有效？因为我们每周都要开始新的冲刺啊。什么？结果怎么衡量？我们创建并完成了很多工单。你还想要什么？

  解决方案：流程是个好东西。流程指导工作，引导得到路线图（你当然要有！）上想要的结果。然而，无法衡量你是否离目标更近或者是否实现了目标的流程要么是不必要的、要么是错误的、浪费时间的，或者以上都是。永远都要评估你的流程，看看它能给你带来什么，又会让你失去什么，并且确保前者永远比后者更多。

  民主过度导致优柔寡断

  每个人的意见都很重要。因为我们不是专制的，对吧？我们听听工程部门所有人的意见。等一下，有两个人不同意，这可不好。其中一位工程师虽然跟项目没有关系，但是他很有经验啊！我们还是搞定他再继续吧。别管期限了，我们需要把事情做对！正确才是最重要的。

  解决方案：企业不是政府，这里不应该民主。又快又好的决定可以拯救公司，决策慢的话无论好坏都会毁掉一家公司。如果你让某人负责这个项目，他们就有最后的话语权，他们会迅速做出决定。争端可以在更加私下的场合解决，不用把整个工程部门都牵扯进来。关注你的人，这样可以让结果最大化。让他们每个人都有话语权的话，你就会毫无理由地陷入僵局。

  过分微观管理，经理不去关心更大的局面，IC沮丧，糟糕的工作出现

经理是管人的人，他跟你在一个战壕上。在不知道是什么原因导致你做出这个决定的情况下，他问你这行代码为什么不换种写法。你用了一个小时的时间才跟他解释清楚，最后他就说了一句“哦”然后同意你了。与此同时，路线图已经延误而且跑偏了，工程师愤怒了，但是该解决这些真正的问题的时候经理却不见了。

  解决方案：要相信人。如果你无法信任他们，那就开除对方。微观管理是任何组织的丧钟，会阻止任何团队扩大。如果经理不去处理真正高层的决策，一行代码是起不到作用的，因为当房子都已经着火的时候你却在跟木匠争吵新椅子的问题。要站得高一点，用鸟瞰的视角来做出好的决策，即便底层会出现一些低效的事情，但大船仍然朝着正确的方向航行。

越级管理

   你在做某件事情，你的老板问你情况怎样，于是你提供了一个更新。然后你的老板的老板又问，你给出同样的回答只是没说那么详细。然后他的老板问，你就说“不错。”然后一位跟你的团队毫无关系的经历又来问，你开始猜测发生了什么事。你决定写一封全公司范围的报告，说清楚进展情况，这浪费了你的时间，因为你要向那些不应该有其他考虑的经理解释清楚事情。

  解决方案：就像过去说的那样，企业不是一般社会。层级的存在不是为了压制下级，而是为了保持秩序和效率。如果3级经理定期询问非直接下属项目的进展情况，这就是微观管理或者管理层级太多的迹象。这些问题的解决方案也很明显。

缺乏有用的检查点

  项目结束时我们会知道。我们以工单完结数来汇报项目状态。当然，尚未完结的工单数是会随时间转移而变化，但那只是粗略的估计，对吧？直到根据安排需要2周的事情最后拖到了6个月完成。

  解决方案：增加检查点。“这些那些应该要在第二周结束时完成。”如果检查点任务未达标，必须进行重新评估， 可能还要给项目多分配资源如果其优先级比较高的话。否则的话，你的项目范围和时间就会不断膨胀，超出你的控制。

  工程师陷入困境的时候不去拉他们一把

  每个人都知道Jacike在做住这个长期项目，而且已经做了一段时间了。你经常会想了解他的进展情况。管理层似乎并不关心他是否延误，因为嘿，你知道的，这个项目很困难。时间过去了，没人介入进去。他时不时会请求帮忙，但被告知大家都很忙。项目就这么一直搁置下去了。

  解决方案：管理层应该对项目状态有一定的了解。如果某件事情明显拖得太久了的话，那么到了一定时候，管理层介入找出缺失了什么信息，或者是否需要加人等是完全适合的。这不是微观管理，这是管理的核心部分，但害怕微观管理的经理往往赋予的自由度太高了，根本就没有起到管理的责任。是，当然这种权衡是有点像走钢丝线，但这是好的管理的标志。

   注：从下面内容开始我就只列表了，因为实在抽不出时间展开讲了，但希望列出的东西能够不言自明。如果确实很重要并且时间允许的话，我会展开说一下。

　7、沟通

   过度沟通。出于所谓的透明性，事无巨细都邮件给一大群人。收件箱堆满了信，大家就会有意识地过滤掉，导致对此漠不关心。

   沟通不足。你要进行大改很可能会有影响到其他团队，但是却没有通知对方。

　8、评估

  经理没有让直接下属来评估

  对如何改进的描述很含糊，经常说那个人从来都没有超过期待这样的话来打压别人工资，但是又从来没有明确这是什么意思

  奖励所谓的“灭火队员”，也就是那些对糟糕的代码部署做出迅速响应的人，而不是那些设计和编码都很仔细，设法避免问题出现的人

  没有清晰的发展路径

　9、宣传

  “公司是个大家庭。”不，不是，如果是的话，很多公司都像虐待孩子的父母，只有孩子不断付出，而父母却一直都只有期望和惩罚。

  “利用社交媒体来传播公司的文章。”这往好里说顶多算是不够诚实。希望利用大家的个人关系来推销公司就是不拿工作和个人生活当两回事了。这是手伸过头的表现。如果员工喜欢公司所为的话，他们自己会传播的。

　10、面试

  流程与目标不一致：面试的目标是要找到那份工作跟公司和团队都很搭的合适人选。

  工程师负担过重，经常要进行面试，跟工作一样频繁。

  强调雇佣更多的人，而没有把焦点放在留住现有人才上（如果你的工程师感觉没有被公司好好对待的话，他们又会如何介绍你的公司给别人呢？）。

11、酒精

  常规活动也提供酒精饮料。喝酒带来的纯粹是压力，不好的健康习惯，不良的工作环境。

  宣扬喝酒文化，把它正常化

　12、歧视

  种族主义、性别歧视、LGBT歧视、年龄歧视。虽然这方面的培训很多，但是出现了一些微妙的歧视形式。

  多元化水平很低

13、员工福祉

  工作过度、紧张过度或者忽视劳累的明显迹象，美其名曰“勤奋的员工”。

  忽略了员工也是人。无视人际关系问题、健康问题等。

转载：http://www.51testing.com/html/62/n-3725162.html

​

网页测试留意的细节

1、每次测试之前都需要代码更新、清理缓存。

2、各模块的信息归类是否正确。比如进入一级栏目或二级栏目的列表页，查看左侧栏目名称，右侧文章标题及内容是否正确。

3、Logo图片是否正确显示，比如大小、位置和图片的相关说明等。

4、所有文章标题、图片、导航等链接跳转是否正确。

5、查询： 1）精确查询还是模糊查询；

2）输入存在的信息，正确搜索出结果；

3）输入特殊字符，搜索不出结果或者给出相应提醒信息；

4）输入空格，搜索不出结果或者给出相应提醒信息；

5）不输入任何内容，搜索出全部信息或者给出相应提醒信息。

6、分页： 1）分页的总页数及当前页数显示是否正确；

2）是否正确跳转到指定的页数；

3）翻页后，列表中的数据是否按照指定的顺序进行排序。

7、导入：导入条件不符合时，能否给出提示； 导入信息符合时，是否成功导入。

8、导出：导出信息是否正确（全部导出和筛选过后的导出）。

9、输入框： 1）必填项的判断是否准确；

2）数据边界值、超边界值的处理；

3）对于特殊字符的处理是否正确，特别要注意单引号和&符号；

4）字符长度是否有限制；

5）输入超长字段，输入框是否被撑开。

10、下拉框的数据是否显示正确，比如添加了一条信息，下拉框中的数据是否也增加。

11、前后台交互的部分，数据传输是否正确。

12、提示、警告或错误提示信息是否清楚易懂，用词准确。

13、页面中错别字和乱码的检查。

14、切换窗口大小，将窗口缩小后，页面是否按比例缩小或其他合理处理方式，文字或图片是否窜行。

15、系统是否支持Enter键、Tab键等。

16、浏览器的前进、后退、刷新按钮，系统是否正确处理。

17、主流浏览器是否兼容。

20年前，互联网就把每个人带到了电脑前。最开始，媒体和其他企业开始排斥互联网和相关概念，称无关紧要或者是虚拟泡沫。故事到后来发生了变化，互联网涌现了数百万个企业，并不断有创新的故事涌现。

什么是区块链技术

这是当前高热门的话题。但对于大多数人来说，这仍然是一个似懂非懂的概念。

简言之，区块链是一个具有分布式数据库的分类账本，这些数据库在互联网上自动更新。网络用户可以看到这些数据库。

因此，区块链网络可以是私有也可以是公共的。

私有区块链网络的工作方式类似于内部网，成员权限受到限制，而公共网络可供所有人访问。但是我们可以大可放心，无论使用的网络是什么，安全性都是有保证的。易受攻击的中间人机制会被淘汰。

由于信息没有集中存储，所以不可能从一个源头进行破坏或窃取重要数据。在黑客对一个区块进行任意形式的攻击后，犯罪分子需要同时侵入该区块链网络中的每一个分类账（近数百万条信息），这是根本不可能的。

区块链技术的核心特征

分布式系统

用通俗的话来讲，区块链不只存储在一台电脑上，通过分布式表征分散特征。随着交易完成，这些分布式节点不断更新，为您提供安全性和匿名隐私。

数据认证

数据可以以各种格式存储在区块链中，其优点是整个区块链都有相同的安全措施。在数据被访问之前，技术确保每个用户都被彻底审查，以防止欺诈。认证方法是创建提供签名的公私密钥对。

利用区块链技术赋能&提升行业

众筹

对于初创企业来讲，资金短缺问题普遍存在，创始人必须解决从适合的渠道筹集资金的问题。及时完成这项任务也是一件艰巨的任务，但区块链技术的出现可谓是应对这些挑战的灵丹妙药。

通过采用分布式筹集资金的制度，解决了与风险投资商长期会面、金融机构错综复杂的问题，还有其它造成时间延误的因素。

有了这项技术，企业就可以加速增长，可以获得所需的资金，有助于企业快速执行和提供更优秀的解决方案。隐私保护的严格遵守确保安全交易过程无缝完成。

智能合约

智能合约是如何工作的

电子合同已经存在了一段时间，区块链技术的出现扩展了其应用范围。这些自动执行的程序避免了传统业务交易的固有问题。

采用区块链技术可以保证系统不会停机，同时检查欺诈和其它数据损坏手段等措施。您的合同会被安全存储，并且可根据事件发送给相关收件人。

还有一个好处是，区块链技术可以保证交易成本降低，因为我们已经成功绕过传统金融交易相关固有的冗长流程。

供应链管理

我们消费的每一件SKU商品都是多种力量共同完成的产物，无论是活着的还是无生命的，这个过程都涉及多方采购和供应链服务商提供。与此相关的问题是，人为因素往往导致过程拖延且较难于进行处理。

区块链技术可以帮助您的企业采取主动的方式。我们可以轻松提供不可变的数字记录，并且不会被伪造，从而减少人为干预，错误或贿赂的发生亦会减少。

分布式云存储

目前企业和个人每年都会消费数十亿美元以上购买存储空间。这种系统的主要缺点是，数据集中存储在一个数据中心，服务器非常容易受到攻击。如果发生这种情况，黑客可以获得有价值的数据，用这些信息欺骗你或你的客户。

而且，集中存储的高成本令人吃惊。当我们应用区块链技术时，通过利用您用户的额外空间，您管理的存储空间额度将扩展到30,000%以上。

区块链存储的数据是加密的，只有拥有密钥的人才能访问。区块链解决方案不仅更便宜，也更安全。

下图是比较几个基于区块链的P2P云存储和内容交付平台的对照：

快速安全付款

如果您的企业是全球型企业，每天做国际贸易，那么您就非常熟悉收发资金的压力了。有时，这些订单交易需要几天才会生效到账，这对许多企业来说也是一种负担。

连接智能设备

一些公司已经实现自动连接设备、小型配件等想法，实现数据和信息的安全共享。区块链技术为该系统奠定了基础，充当许多设备的公共账本。

通过这种区块链技术，我们创建了一个自治的网络，它负责设备到设备的通信，设备管理与更新，自主决策等。设备可以自主日常维护，不会导致用户停机。

转移到设备自处理，这项技术也更加节省成本。整个办公室由于互联互通，管理得当，节省大量的时间和成本。

应用程序进化无止境。互联网以类似的方式改变了每一个行业，区块链技术更是如此。许许多多的公司正在利用区块链技术，取得了惊人的收益。

“攻城狮们”，还不来一试：）

​

大量用户登录游戏产生的“洪荒之力”往往会对游戏服务器产生巨大的压力，游戏上线之前对服务器的承载能力做测试是必须要做的事。本文从腾讯游戏服务器性能测试的经历出发，对服务器性能测试的原理、指标和方法进行了介绍，并介绍了内部目前流行的一些工具和使用技巧。

在四年磨一剑的奥运会，要想成功，必须顶住压力，在0.13秒错失400米自由泳金牌之后，孙杨在200米自由泳比赛中后来居上，夺回冠军；傅园慧靠着自己的“洪荒之力”，反复刷新自己的最好成绩。

那么，同样也是多年磨一剑，游戏开发者精心制作的游戏在面对大量用户的“洪荒之力”时，服务器应该怎样顶住压力，高效运转？

先来看看用户的洪荒之力能产生什么样的后果？

1、面对开服压力，服务器宕机

版本上线之后，新的服务器开放或者服务器更新，面对大量玩家的涌入，如果服务器的性能不好，就会发生登录失败的问题。

2、运营期压力，玩家体验损失

服务器的一个外网活动，比如副本双倍掉落，可能就会造成玩家在某个场景堆积，此时副本玩家就会比平时高很多，对于服务器而言副本这个业务请求会产生比平常高很多的压力，就极容易引发相关的性能问题。

据数据公司预测，获得苹果推荐的价值相当于200万美元左右的推广费用。法国工作室Ankama Games研发的游戏Tactile Wars拿到了苹果50多个国家(几乎是所有上线的地区)的首页“最佳新游戏”推荐，而且曾一度达到了美国iPhone免费榜第二名，日均下载量突破25万，而一个月后该游戏在美国的下载排名已经降到了475，并且有持续下滑的趋势。归根结底是因为开发商没有应对大量玩家涌入服务器的准备，服务器卡死、宕机，闪退让玩家失望选择离开。在这之后Ankama花了两个月的时候才优化服务器逐步挽回了局面。

我们团队也曾经接入过一款代理游戏，有百万级的在线人数预估，当时进行了服务器性能测试，测试结果是当时对方的服务器只能承受1500人的同时在线，如果一套服务器只能承载1500个用户，该游戏要上线需要多少服务器？需要1000套，这无疑是一个巨大的浪费。

面对用户的“洪荒之力”，惨痛的经历一次次的发生，外网问题无小事，游戏发行、渠道对服务器承压情况越来越重视，很多都会要求CP提供服务器性能测试报告作为凭据。

然而目前市场上还没有针对游戏的服务器性能检测工具，无论是开源还是商业软件都不能很好的满足游戏的专项测试需求，与此同时受限于开发周期短以及人力的问题，中小型CP往往采取编写模拟机器人进行简单的压测，测试的覆盖面窄，无法保证并发请求，造成潜伏的问题遗漏到线上。

同样是百万级的游戏，有的公司需要上千台服务器，而有的公司只要几百台服务器，巨大的服务器采购运维成本差异皆因各家公司做服务器性能测试乃至性能调优的能力参差不齐。

那么问题就来了，服务器性能测试是什么？要怎么做才最有效呢？

什么是服务器性能测试？

提到服务器性能测试，不得不提到很多术语。为了让大家更容易理解，举个生活中的例子：

你中午去“海底捞”吃饭。

我们可以把“海底捞”这个酒楼看成一个被测系统。

你去吃饭，就是对这个被测系统发起请求，对这个系统造成了一定的负载。你带去的人越多，那么这个餐馆就越繁忙，可以说餐馆承受的负载就越大。

你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时，其他桌有的在吃菜，有的在等菜，这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括：点菜，下单，上菜，买单四个步骤。对于一个C/S的系统来说，可以对应于：建立连接，发送请求，接受应答，断开连接。

影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面：

1.一个顾客请求的处理耗时，从下单到上菜中间等待的时间，我们称之为响应时间。

2.这个餐馆同时为多名顾客上菜的频率，我们称之为吞吐量。

很多因素会影响上菜速度，比如服务员的个数、厨师的个数。对于一个C/S的系统，服务员相当于是接入层，厨师相当于是后台服务。假如服务员太少，下单很慢，后面的厨师都闲着，那么上菜速度也快不了；假如服务员够多，下单足够快，但是厨师太少，下的单来不及做，同样上菜速度也很慢；如果服务员很多，厨师也很多，但是来的客人很少，那么大部分的服务员和厨师都闲着，资源全部浪费掉了。因此，接入层和后台服务进程个数、以及资源配比，都是需要根据实际情况进行调优的。

来多少顾客，这是酒楼自己无法控制的，但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量，当来的客人超过了这个峰值，那么这些客人就会等位，或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务，希望找到这样一个客流量对酒楼产生一定的负载，这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的，还可以对这个酒楼人员配置和餐位设置等进行调优，以期达到一个最理想的资源利用率和效率。

客流量跟进来的客人多少有关，也跟餐馆的接待能力有关。单方面增加来就餐的顾客，遭到投诉的可能性就越大，上错菜的可能性也越大。

性能测试的核心概念主要包括两部分：正确的测试方法，正确的评价性能的指标。测试方法会告诉你用什么样的套路去执行测试；性能指标是告诉你如何用数值来描述你的测试对象的性能。

常用的性能指标

在介绍测试方法之前，先来了解一下关于服务器性能测试的一些指标含义。

●吞吐量：固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数，单位：事务/秒（tps）。

●平均吞吐量：一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

●峰值吞吐量：一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

●最低吞吐量：一段时间内吞吐量的最小值。如果最小值接近0，说明系统有“卡”的现象。

●70%的吞吐量集中区间：通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。区间越集中，吞吐量越稳定。

●响应时间：一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔，单位：毫秒。

●平均响应时间：一段时间内响应时间的平均值。无法体现响应时间的波动情况。

●中间响应时间：一段时间内响应时间的中间值，50%响应时间，有一半的服务器响应时间低于该值而另一半高于该值。

●90%响应时间：一段时间内90%的事务响应时间比此数值要小。反应总体响应速度，和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

●最小响应时间：响应时间的最小值。反映服务最快处理能力。

●最大响应时间：响应时间的最大值。反映服务器最慢处理能力。

●CPU占用率：1-CPU空闲率，表示CPU被使用情况，反映了系统资源利用情况。

常用的测试方法

关于服务器性能测试，目前常用的测试方法有这些：

1、现网数据预估

现网数据预估是根据压力测试过程中的部分数据，对未来大量用户访问的情况机型预估。图中的横轴代表现网吞吐量，纵轴代表CPU压力。

图中绿色的部分代表当前的服务器压力，当收集一段时间数据之后，可以模拟一条曲线。假设对服务器的上线成本预估是80%，可以通过曲线拟合的方式推测出现网的能力是多少，也从而推断出最大上限是多少。

缺点：通常游戏服务器都是比较复杂的，这种方式只适合简单的服务器拟合，复杂服务器数据就不太准确。

2、真人压测

真人压测就是通过邀请一定数量的真实用户来玩游戏，从而对服务器达到一个测试效果。这种方式他最大特点在于用户的行为相对是最真实的，因为用户的使用完全不会受到限制，和线上一个真实用户一样。目前游戏上线过程中的“封测”，就可以被认为是一种真人压测，可以帮助开发者发现一些性能问题。

但是这种方式也存在着弊端：

●暴露出的性能问题有限

许多经过封测的游戏到上线还会产生问题，原因之一就是封测人数通常还是太少，虽然有几百或者几千用户在玩，但是并发并不够，不足以暴露服务端性能问题；

●不适合调优

服务器性能测试不光需要暴露服务器的问题，暴露问题之后还需要不断的回归调优，但是真人是无法完全重复这些行为方式的。

3、接口测试

服务器方面的接口测试与传统意义上的接口测试略有不同，当开发人员需要对一套服务器进行评估，但是又时间不足的情况下，我们可以考虑选择一些具有代表性的功能，以及一些高风险功能进行测试，通过以小见大的方式，来评估整套服务器性能。

当然这个方法的主要问题就是无法遍历整个服务器的接口，难以避免一些微小的问题。

4、录制回放

这里面包含两部分，“录制”就是通过抓取数据包的方式，来获取游戏时的协议，比如用户登录游戏时抓取登录包；“回放”即把这些捕获的协议重新发送给服务端，这样理论上就可以通过工具放大协议量级达到性能测试的目的，比如将之前录制的登入协议扩大1w倍给服务器，这样就模拟了1w人同时登入的情况。

这个方法存在的问题是，游戏的协议交互非常复杂，如果只是单纯的放大数据包，对于服务器是产生不了多大的压力的。这类方法比较适合固定输入输出服务类型的测试。

5、机器人模拟

机器人模拟测试是对以上各种测试做了一个平衡， 通过高还原真实玩家的用户行为，模拟高并发场景，从而得到类似很多人同时游戏的测试效果。机器人模拟有三个优势：

高还原游戏玩法，深度模拟真实用户行为：

1. 并发性不受限制，从1W到10W，压力能够自主设置；

2. 可以反复执行，便于性能调优回归；

3. 实现7*24小时不断监控，在开发提交代码之后，版本在自动编译之后就跑新的测试，这样每天都能进行性能监控，在调优方面，完全地进行一个重复性测试，可以不断的进行回归和调优。

这个方法的问题就在于机器人模拟需要专人开发，对测试者的开发能力，分析能力都有一个比较高的要求。

说到这里，我们对之前所有的服务器性能测试方法进行了一个总结：

我们可以发现，速度与准确性始终是对立的，如果游戏开发者队友服务器测试有一个明确的规划，对服务器压测有一定的时间预留，机器人模拟的效果是非常好的。

如何实现机器人模拟

那么我们到底是如何来开发一款进行服务器性能测试的机器人呢？

整个开发过程主要可以概括为三大步骤，建模， 分析， 开发。

第一步，建模。

建模是什么呢，建模是为了模拟真实玩家行为，分为两种方法：

1）探索典型玩家关键路径

通过大量玩家数据的支撑，选择最多的行为路径，设计机器人模拟的行为。

2）通过封测过程中的运营数据，生成专家视图

这个方法就是通过去测试服中搜集用户的协议数据，并对这些协议数据进行分析，确定各自是什么行为，把用户的这些协议数据还原成为用户行为的操作过程就像是把一块块散乱的拼图重新组织起来一样。

在这个过程中，最简单的是按比例组织，通过数据分析，发现用户登录，战斗各自占据多少比例，以这个比例来分配一定的人数进行登录和战斗。但是这个方式并不太适合游戏，对于游戏本身来说，一百个人不断的重复登录的行为，一百个人同时重复游戏的行为，显然是不符合逻辑的。

那么在分析的过程中，采用概率的方式，是更加贴近一个真实用户的行为的。当模拟一个真实用户登录之后，有一定的可能性会重新登录，还有一部分可能性就进行战斗，例如机器人有10%概率重新登入，50%概率进行战斗。 同时我们还需要考虑对角色身上的装备数据， Cache的命中，数据库容量等等，目的是让机器人更接近真实用户，更加符合一个真实用户的行为。

第二步，分析。

那么我们会对客户端进行行为交互和协议分析。一方面，为后续协议开发实现做准备；另外，在登入的过程中，会产生大量的协议，如果没有对客户端进行分析，可能只是调用了登录的协议，从实际的协议交互上来说，一次登录可能包含了很多其他的协议信息，那这时我们实现登入就不能仅仅是个简单的登录协议，可能还包含拉取邮件信息，拉取好友信息等协议，两者之间对登入的性能差异影响非常大。

第三步，代码开发。

主要包含两部分：

1）协议的开发，包括协议的实现，协议的解包等；

2） 业务逻辑的组织，主要对上述游戏模型进行实现。

服务器性能测试工具的使用

不过令人遗憾的是，对于游戏开发者的实际情况来说，充足的测试时间并不是每次都可以保证的，而且对于模拟机器人的开发过程本身又是一个很大的投入，对于一些通用场景，如果能够有通用的平台代码可以调用，相信对于游戏开发者是一种极大的解放。

对于服务器性能测试来说，好的测试要做到这样几点：

业务场景模拟。可编码解析任意协议，实现复杂业务场景。

发现瓶颈。支持使用场景中复杂的数据传输行为，比如“登录”“查看个人信息”等，更加真实的模拟用户行为，发现服务器问题；

持续压力。实现7*24小时一定量级的服务器压力；

触达极限。短时间内触达服务器的压力上限。

灵活自定义。对于类似游戏的复杂混合场景，可以结合在线代码开发IDE，实现对任何标准或自定义协议的通信。

转载：http://www.51testing.com/html/22/n-3725022-2.html