$hello = "hello";
var_dump($hello['abc']);
var_dump($hello['0']);
var_dump($hello['1abc']);
var_dump($hello['12abc']);

输出的结果就不说了，简单运行一下就可以知道，我想原因是由intval这个东东引起的，时间关系，没有去确认zend的代码，不过下面代码的运行结果页说明了一些问题

var_dump(intval('abc'));
var_dump(intval('0'));
var_dump(intval('1abc'));
var_dump(intval('12abc'));

这个东东，对code review或者测试时候是一个很有杀伤力的bug，如果一个函数设计的返回值不好，有时候返回数组，有时候返回字符串，在使用之前，就一定要先判断返回结果是否为数组，否则就会在这个bug上杯具

您可能会喜欢:

1. php中getopt的缺陷及修复
2. php反射效果:基类访问子类数据
3. php中set names与mysql_set_charset

1.沟通

这里所说的问题，是指测试团队qa之间的沟通。就像《人月神话》里面谈到的问题一样，测试团队中成员之间的沟通，也是要消耗时间的，有时候还会存在信息丢失。比如工作的交接，模块A以前是甲测试的，现在要交接给乙。如果甲所做的工作没有形成足够详细的文档（通常文档都不会是足够详细的，尤其是在互联网企业），那么甲乙之间必定会消耗时间在沟通上面。不过这个东东是可以通过规范化文档来缓解的：比如测试用例的描述，可以用一些规范的格式；测试脚本的部署执行，可以使用一个测试框架来解决。

2.自动化

这个应该是个永恒不变的话题了，效率永远没有最好。对于测试工程师来说，使用自动化回归测试用例，能够在很大程度上提高效率。有的时候自动化也是没有好处的，比如一个系统，半年都不升级一次，要自动化回归，反而会更加消耗时间与经历。对于经常升级改动的系统，自动化的好处就不用说了，但是自动化的测试用例也是需要维护的，不维护的用例失效后反而浪费了创建用例的时间。

3.测试部署

现代软件系统通常都是很多子模块之间相互依赖的，而经常都是升级的这个模块，还会依赖于系统中另外的很多模块，这个问题在rd开发时候，遇到的问题可能更严重，经常遇到的情况就是环境中都是坏数据，连调困难。qa遇到的问题要比rd的简单很多，毕竟提测的东西都是rd调试过的，所以集成环境的问题是一个简单的问题，只要控制环境中的版本部署以及数据修改即可。但因为很多原因（比case的前置条件，避免损坏集成环境的数据等）会导致需要把模块不放在环境中测试，提供一些自动化部署的东东也能够节省很多时间。这个在有些大公司，是直接有软件支持测试的，也可以自己开发一个测试框架来解决问题

opentest在一定程度上解决或者缓解了上面三个问题，但是与此同时，也带来了一些问题，有些case的检查点越来越多，比如核心系统的，要检查1000项数据，这样的case，很明显，对于测试工程师的工作量需求是巨大的，不过幸好case的描述是标准化的，可以借助工具生成case，进一步提高效率。

您可能会喜欢:

1. opentest之路
2. 怀念
3. 软件测试-了解被测对象

1.了解系统架构。这个应该是前提条件，一个新同学入职到项目组后，肯定是要先了解现有系统才行，不了解现有系统，很难清楚团队中的设计风格与习惯。了解了系统架构，才能知道自己要测试的模块处在什么位置，为系统提供什么样的功能，系统对它有什么要求。清楚了这些，才能知道自己要做事情的针对性。

2.明确需求。需求一般是由pm提出的，一般会组织需求评审，在评审过程中，明确pm的当前需求，对未来可能的需求进行估计。明确需求后，就能知道现有系统需要做哪些改动，对大致的工作量与项目的时间有一个估计。有时候，需要改变或者拒绝需求，比如对于一个支付系统来说，如果pm提出的需求对账户安全有影响，就应该坚持原则，对此提出质疑，要求改变需求。

3.参与系统设计流程。这个时候一般是开发(rd)同学自己先设计一套或者多套方案，随后进行设计评审。评审过程中，qa同学也是要多多参与的，在把握需求的基础上，对设计提出一些建议与意见，与此同时，对测试方面的工作量也能进一步细化。有时候，采用好的建议可以同时节省开发与测试双发的工作。在此过程中，qa同学应该自己从rd的角度思考，不要被动接受rd的设计，可以想象成，如果需求摆在自己面前，自己会怎么做，这样才能充分理解设计，为自己的测试工作打下良好的铺垫。同时多了解系统内部，也有利于自身的职业发展。

4.case设计步骤。根据rd的设计文档，设计测试用例。在这个环节中，沟通与文档是两个重要内容，遇到不清楚的细节，一定要与rd沟通，不要自己猜，否则会造成杯具。如果rd没有文档，可以自己记录个邮件，避免忘记和rd反悔的现象。

5.提测。除了上面几步确认的内容，还要再确认一下rd有没有“顺手”做了其它地方的改动。如果有的话，一定要在送测流程单里面写清楚，同时qa也要与rd沟通清楚，避免出现漏测的情况。

您可能会喜欢:

1. opentest的几个效率改进关注点
2. 事情不是这么做的
3. 冲动是魔鬼

没错，自动化测试是有代价的，多数情况下也会导致首次测试时消耗的时间变长，但提高case书写的效率还是很有必要的。opentest在这件事情上面，可以分为三步走：

1.校验数据的生成。在执行case的时候，帮助qa生成需要校验的数据，这样qa同学只需要将它cp到case文件中就可以了。但这样做是有一定风险的，生成的数据是根据核心系统结果来做的，如果过于自动化，出来的数据又错误，又不注意看，就会造成漏测，所以需要在里面内置一些校验规则，对于不满足规则的数据报错，避免出现漏测的情况

2.自动机生成case。对于“创建-支付-确认”这样一个简单的例子来说，支付的前提数据条件就是创建的结果，qa同学只需要画出自动机，由工具生成case文件，将case文件放在opentest中跑一下即可达到测试目的了。而opentest的case文件因为是格式化的，天然的支持这样case生成工具的编写。

3.结合fuzz测试。fuzz测试可以是框架的进一步发展，第二步能够保证关键的正常流程是ok的，使用fuzz测试，不用qa同学思考各种测试用例的情况，直接向被测模块发送各种可能的数据情况。其实fuzz测试是一个很有效的东东，可以测试出很多非常难以发现的问题。

这三步做完后，我想opentest也可以成为一个比较完善的测试框架了，能够在很大程度上提高测试效率。

您可能会喜欢:

1. opentest的几个效率改进关注点
2. Opentest测试框架
3. 什么样的测试用例是好的

1.分析能力。软件测试的核心其实应该就是设计测试用例了（具体啥样的用例设计，请参见《什么样的测试用例是好的》），而设计测试用例，就是依赖与分析能力了。这里我们不说那些常用的设计方法，从一个稍高的层面上来讲，可以说就是怎么将一个复杂的系统进行抽象，分析拆成几个不同的维度，结合维度可能出现的情况进行有选择的组合，以最小成本获取最大的收益。无法将一个复杂系统拆解成简单的维度，是没法做好用例设计的

2.编程语言。语言其实就像说话一样，只不过我们常说的英语日语之类是与人沟通，计算机语言就是与计算机进行沟通的。对于测试工程师来说，精通一门语言，熟悉其它几门语言是有必要的。对于不同语言编写的被测程序，是有不同特点的，如果对实现的语言不了解，无法进行白盒测试，没法看代码diff（结合代码diff做测试）来提高效率。对于特点不了解，可能也会导致自己漏掉部分内容。

3.设计能力。不要认为设计能力就是开发工程师的事情，拥有好的设计能力，就可以在设计评审的时候多提意见，促进开发工程师使用好的设计，不仅对开发有好处，对测试也是很有好处的。这样才能防患于未然，不仅自己的劳动力，也节省团队的劳动力。

4.对业务的理解。对业务的理解越充分，就越能够理解最终用户的需求，促进产品设计使用好的方式，促进产品成功。难道你想做一大堆不成功的项目么，那样是多么没有成就感的一件事啊。

5.自动化相关的考虑。随着项目越来越多，系统的测试项目也会积累的越来越多，每次有新功能了，难道要用手工来回归一下原有的case么。自动化测试是提高回归测试效率的唯一解决方案（如果你说还有解决方案就是不回归，我…），以高效率促进高质量，才是一个良性循环的发展方式啊。

嗯，以高效率促进高质量，我觉得很有很有道理。

您可能会喜欢:

1. opentest的几个效率改进关注点
2. opentest之路
3. 结合代码diff做测试

1.提高旧有case回归的效率。从代码diff里面，可以看到旧有功能哪些地方没有任何改动，这样就可以增加信心，节省对旧有功能回归测试的工作量。当然，如果升级导致旧有功能的前置条件产生变化，还是需要注意的

2.明确case的重点。知道变动的内容，就可以根据修改的代码设置case，有针对性的测试。

3.辅助定位发现的问题。

4.直接发现bug或者代码设计上的问题。

5.测试人员的经验积累。经常看别人的代码diff，积累经验，就能加深自己对项目的理解，判断大致什么地方容易出现问题，提高职业素养。

diff少的时候，就可以直接发现问题了，这个非常有用，可以极大的提高效率。如果对被测对象的了解比较深入，通过查看diff即可知道新功能修改的是否到位，也可看出新增加的地方是否处理很山寨，不具备通用性等。另外比如实现细节上，看看申请的内存是否会溢出等也可以在这里处理。

有的时候，代码diff很多，看diff可以只关心重点内容：

1.if语句。新增或者修改的if标志着新旧功能点所走的不同逻辑分支。通过查看修改点的判断参数来设计case覆盖不同的分支。另外也要关注是否条件出现问题，程序走到错误分支的情况。

2.新增的函数。这种情况下，新增的函数通常都是为了满足新功能增加的部分逻辑，这时就设计case重点照顾一下新增的函数。

3.循环。比如修改了循环的条件，里面增加了break等也是属于流程分支改变的情况。

结合代码diff的作用很明显，但貌似总结这个的文章也很少，而实际用到的也是比较细小，零碎的东东，在这里先暂时列出一些，开启话题，逐渐补充吧。

您可能会喜欢:

1. 软件测试-了解被测对象
2. 软件测试工程师的职业素质
3. 难道神州真的不适合人类生存了?

在此之前，我们需要明确测试工程师的工作原则：用最小的成本找出最多的问题。

1.用例覆盖程度

毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。

2.用例是否已经达到工作量最小化

在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。

3.用例的分类以及描述是否足够清晰

用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。

用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。

4.用例是否表明了测试目的

写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。

5.测试用例的易于维护性

如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，就需要修改这两个。当然，这两种情况不能绝对的说哪种好，是需要看实际使用时候的情况进行取舍的。不过，通过一些系统性的工具支持，也会出现一种做法绝对性的好于另外一种的情况，情况很多，做法也有很多，在这里就不多说了。

说了这么多，其实这个第二步，还是严重依赖于第一步的，如果对测试对象的需求，实现等都不了解，设计用例也就无从谈起了。

您可能会喜欢:

1. opentest的几个效率改进关注点
2. opentest之路
3. 软件测试工程师的职业素质

1. Opentest的用途

Opentest是一个开放式的测试框架，目的是用于具备规范接口模块自动化回归测试（不太适用于网页展示上的测试）。测试框架遵从简单可依赖的原则，实现不同功能的子模块功能简单，扩展方便。框架使用依赖注入的方式，将实现不同功能的子模块组织起来，完成测试所需的工作。

opentest框架中，使用测试数据与逻辑相分离的方式进行组织。测试数据在不同的逻辑之间具有一定程度的通用性。

2. Opentest的使用

现阶段opentest部署了一个较简单的逻辑，用于支持支付组各server测试中的绝大多数用例，用例的逻辑比较简单，做下面几件事情：

对于测试来说，需要做的就是在配置中提供测试用例执行所需要的数据，不必在做其它的开发性工作。下面就以这个流程为例，说明一下做测试需要进行的工作。

2.1. 目录结构与建立个人配置

目录结构如上图所示。测试用例放置于cases目录中，其中sample文件夹下的是opentest测试用例的示例。在testmods目录中，部署各被测模块，以<程序名>.<版本号>形式部署。

用户配置位于confs文件夹中的用户目录(yanp)中，在这个目录中，存在一个framework_defaults.conf.php文件，这个文件是opentest框架中提供的各工具服务的配置信息，描述了mcpack接口的client与server，数据库与log的配置信息，作为用户自己的配置。在用户目录(yanp)中，还包含了被测模块的配置文件，opentest在执行用例时，将会以指定用户的配置文件启动被测模块。

即使是同一模块，不同用户的端口号与数据库配置也可以不同，例如用户可以配置opentest发送pack的client 向11003端口发送，同时使用固定的端口11003启动所有的server，可以免去每次回归测试环境配置的烦恼。

2.2. 编写并部署测试用例

在opentest中，测试用例只包含测试逻辑所需要的数据。测试用例以类的形式部署，支持继承。这样就可以在基类中部署初始化操作与通用的逻辑，避免在具体的用例数据中编写编写重复的内容。

用例文件sample_case_init.php

class sample_case_init{     static $TESTMOD_NAME = ‘fake_listener’;     static $TESTMOD_VER  = ’1.0.0.0′;     static $DB_INIT = array(         //写上数据库表中的具体内容，将会truncate对应的表         //如果不写上表中的具体内容，将会truncate所有的分表（根据数据将数据分到不同表中的情况）         ‘truncate’ => array(             ‘table’                 => ‘t_accounts’,             ‘F_user_id’             => ’100000′,             ‘F_sub_account_type’    => ’1′,             ‘F_currency’            => ’1′,         ),      );  }

用例文件sample_case1_case.php

require_once(dirname(__FILE__).’/sample_case_init.php’); class sample_case1_case extends sample_case_init{     static $CLIENT_PACK = array(         //发送到被测模块的pack         ‘send’  => array(             ‘cmd’       => ‘hello’,         ),          //期望从被测模块接收的pack         ‘recv’  => array(             ‘result’    => ’0′,         ),      );  //…还有另外一些内容，为节省空间，在此省略… }

sample_case1_case是opentest需要执行的测试用例，在类中使用静态数组的方式提供进行具体操作的数据。在sample_case类中的一部分数据，可以通过它的基类sample_case_init.php提供。opentest通过反射的方式解析各测试用例。如果测试用例中没有提供对应的数据，根据逻辑的定义，可能认为case失败或者跳过对应的流程。

Opentest支持提供文件名字或者目录的方式指定测试用例，提供目录后，将会执行目录中的所有用例（以_case.php结尾的文件被认为是需要执行的）。

执行用于演示的测试用例：

账户：testframe@jx-testing-eb18.jx.baidu.com

cd test_framework/framework/ ./bin/run_sample.sh

3. Opentest的模块结构与开发新功能

Opentest使用一种松散耦合的方式进行组织，case执行逻辑所使用的数据与工具都由组装模块进行依赖注入。比如checker就可以在使用时候注入松散检查或者严格检查不同类型的工作类。目前已经支持数据库操作与mcpack接口，如果需要不同的case执行逻辑，可以通过继承原有的类或者添加一个新的类。

目前opentest�
��模块结构如下图，各模块都比较简单，主要功能如下：

1. ctrl

a) 解析用户请求，将各功能组件进行组装

b) case执行逻辑，各种不同的case执行逻辑部署在这里，用于组装

c) caseloader，用于解析case配置文件，被组装模块调用，提供所需的数据

d) checker，用于检查测试结果数据域case中预定义的是否相符

2. client:各种发送请求的client，目前有mcpack的与http的

3. server:各种接收请求的server，目前只有mcpack的

4. dbop:用于操作数据库，case文件中指定表名即可，分库分表逻辑在dbop中内置

5. conf:管理用户的配置信息与被测模块的配置信息，附赠一个启动被测模块的能力

4. 附录：

得益于simpletest，目前支持html格式或者text格式的输出，其它功能正在扩展中，目前opentest支持的启动参数

Usage:

-c case_full_name like "/home/test/test.php" or "/home/test". if a dir is given, framework will try all the file in the dir as a case

-o html|text output result as html or text, default is text

-n conf name which you want to use

您可能会喜欢:

1. 分层次管理tag文件
2. svn安装备份完全解决方案
3. sql运行简单封装

1.可文本描述：包括各子系统之间，子系统之中各模块之间的接口，以及个模块及子系统所需要的数据定义。

2.可检查：模块的产出能够进行精确检查，子系统内部各模块之间的通信（在一定程度上，属于产出的一部分）能够进行精确检查，模块产生的日志能够进行检查。

3.能够适应不同类型的被测模块：服务型，批处理型等

4.用户接口友好，测试可能涉及多种功能实体的配置，如一次测试可能需要模拟多个下游桩模块，配置数据等。所有的命令与数据都可以在同一个配置文档中进行配置说明

5.提供一定的附加能力用于模拟异常情况：如kill进程，切断数据库连接，构造磁盘不足等

按照目前的情况看来，1，2，3每一点都已经能够提供约50%的能力，4还需要等待1，2逐渐完善才能开始着手。5不是迫切需求。

永远不要一开始就尝试做一个大且完善的系统，着手在小的地方逐渐增强，有一天你会突然发现，原来各个部分组合协作起来，已经是一个不错的系统了

您可能会喜欢:

1. Opentest测试框架
2. wordpress插件之持久化链接
3. 更换域名为www.mirecle.com