看有赞测试团队的读后感

看了他们的团队介绍,不由得感叹有赞团队是个很优秀的团队,有很多值得我们学习的地方。
项目流程方面,有赞的测试人员从需求评审开始介入,设计用例,提测用例,用例自动化,到由测试进行发布,全面把关产品质量。而我们的测试多数时间是用来进行功能测试,测完立刻上线,之后用例自动化主要由于鹏进行,很多是上线以后才开始进行。发布阶段,我们是由运维进行发布,并且有些项目的开发到发布测试人员不参与,应该跟有赞一样,由测试人员进行用例编写交给开发自测,这样能提高产品的质量,也能提高开发自己的代码能力。
人员技能方面,有赞测试人员需要具备白盒测试能力、CodeReview能力、业务功能测试,而我们在这方面的能力还有所欠缺,我们也应该提升自己各方面的能力。
我们和他们这样高效的团队之间确实是有差距的。所以我们要吸取对我们有用的经验,提高效率,快速进步。

有赞测试团队–读后感

看了有赞测试团队的分享内容,了解到了团队与团队之间的差别;

1.团队把所有精力都投资在接口自动化层面,有效的减少了ui层面的工作量
youzan1
2.项目周期中,测试人员较早介入
3.测试用例开发人员辅助添加,开发人员应该是最了解业务逻辑及代码逻辑的,会相对容易挖掘出一些隐藏的业务逻辑、或者异常场景;
4.前期的自动化接口测试,有效保证了项目的提测质量,大大缩减冒烟测试,ui层功能测试时间
5.线上监控开发、安全扫描、性能测试能够有效的测出有些手工测试无法达到的测试场景
6.持续集成平台实现了可流程化配置业务应用发布顺序并与测试自动化相结合的工作流,同时提供自动运行及外部触发的运行模式
youzan2
7.测试质量报告及风险评估,可以起到在迭代中加强对某部分功能的关注

《有赞.测试团队介绍》读后感

读完《有赞测试团队介绍》有了一点小感想,之前一直做黑盒测试,公司需要的时候会做一些性能和自动化,还未曾接触过白盒测试。现在测试开发职位也越来越多了,之前也一直苦于没有这样的机会,如今部门日益壮大,测试开发还是很有必要的。希望以后我们的日常工作也能像有赞一样。白盒测试能力、CodeReview能力或许现在我们还不具备,但是我们可以跟部门一块成长,总有一天会越来越成熟。

虽然暂时不能达到有赞的水平,但是我们可以一点点实现,首先做好第一步也就是有赞的2.1,然后在效仿后面的,相信会有很大的改善,让我们一起努力吧!

具体项目测试:

有赞的项目分为标准需求项目、技术重构项目、优化项目、缺陷修复项目。有限的测试资源通过不同策略支持着绝大部分业务产品的测试工作。
第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。PTM需要确保所有需求点都拆分到各个业务测试同学手里,跟踪相关测试同学按时提交标准测试方案。当测试方案汇总后,PTM需要评估后续测试过程中,测试人员如何投入。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。
第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要设计测试方案并完成测试用例落地即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。
第三、对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
有赞测试同学拿到具体需求后,按照有赞测试对需求分析和测试方案统一要求,完成相关工作。

                                                   有赞.项目协作图

 

 

有赞测试团队读后感想

下边这张图,从需求评审到代码编写再到提测后的测试结束上线,这个来看是相对很完整的一个开发测试流程,从开发阶段到上线阶段,测试人员是不断在跟进,其实这么来做能在提测时解决掉大部分的bug,可以大幅度减轻测试人员在页面功能方面的测试压力,这个是很值得学习的。也能充分深入了解需求,更深入的挖掘潜在的bug,提升产品交付的质量。
1
在文章中也提到了自动化部分,有赞测试团队采用金字塔分层比例的方式来分配自动化涉及部分,从他们的比例来看,和人们所认识的的金字塔有相似有区别,区别在于最底层的单元测试是由开发来做,这个也有好处,开发自身开发的代码,自身最了解,但是也有弊端,自己开发的代码,发现问题也是比较难的。再说接口测试部分,有赞团队90%的精力都在接口层部分,而且还是分接口的上层和底层,这样在开发做完单元测试的基础上,来实现接口测试或接口测试的自动化方式来检测代码的入参以及返回是否是按照预定的要求来返回的。这样就会发现在接口层出现的一些数据传输之间的问题。那么到做UI测试时候大部分就只停留在处理页面一些显而易见的问题了。
2
3
现阶段我们处于一个基本的功能测试以及少部分的页面功能自动化的实现阶段,在后期一定需要改善这种工作模式,接口的测试加入到测试部分,自动化部分能更深入到接口层,更深入的发现更多的问题,更有效的提升测试效率和质量。

《有赞.测试团队介绍》读后感想

何为质量把控?如何进行有效且高效的质量把控?在读这篇文章之前,我对测试的认识还停留在简单的理论认识阶段,了解了有赞测试团队的工作后,对测试组的工作目标有了更加清晰的认识。这个团队对质量把控做到了业内领先的地步。

先来看看他们的项目协作图(与我们团队相关的协作工作日常可以做个比较)

15029627816175

先说协作,他们有“提测用例”,用来检查提测质量,约束研发的产品质量;再说流程,他们有“测试评审”,对测试用例的设计进行检查和规范(他们已经积累了很多规范),将测试这个事情提高到一定高度。此图中没有画出来,但有赞和我们一样,测试组一样会参与需求评审。

再说自动化测试,最打动我的就是这块,此前也看到很多关于自动化测试的理论文章,但没有看到哪一家真的可以落地到这么好的,在实施层面,有赞在自动化测试这块做的很不错。下面是有赞.自动化分布图:

2

这个金字塔下面还有一层,是mock测试,这图没有列出来。

让测试来负责发布,而不再是运维来发布,我觉得这个在当下来说,是非常正确的,符合质量把控原则。这并不是否认运维同事的工作,而是运维同事搭建好自动化发布平台后,有测试组来操作和管理发布。关于他们的发布系统,也有一个亮点,就是合并分支发布。这对“单项目”高频发布的发布系统来说,是个必然的产物,但也是非常有用的产物。

前面都是理论,但工欲善其事必先利其器,没有好用的工具,想的再美好也是瞎掰。有赞在各个环节上,都自研了很多有用的系统,不得不说他们的测试研发团队很强大。

数据,对于质量把控来说,犹如眼睛一般重要。没有数据汇总,没有数据分析,质量把控就会成为盲人过河一般只能摸索前进。这块也是和工具一样的重要。

1505283244927

最后,附上原文链接:有赞.测试团队介绍

有赞测试分享读后感

认清差距,方能追赶

通过有赞测试团队的分享,我深受鼓舞,指明了我们测试组未来的发展方向,让我知道一个测试团队可以做到这么强大。下面我简单分析一下我的看法

1.有赞是一个纯粹的互联网企业,在开发、技术方便很重视,这一点,从测试人员质量就可以看的出来,需要具备白盒测试能力、CodeReview能力、业务功能测试的测试工程师,而且必须是BAT团队出来的。这点我想我们是可以看得出差距的。可是这种人员的差距怎么缩小呢?假设,我们有两种方法:1.统一招BAT团队的资深测试工程师,2.选团队最优测试工程师给整个团队业余时间培训,公司给与支持,然后培养成具备这种能力的工程师。那么我想,第二种方法是最优解,培训成本较低、人力成本低,现有测试人员业务熟练。可以快速介入测试。

2.对于测试日常工作分配,我觉得可以学习有赞团队,将项目细分成标准需求项目、技术重构项目、优化项目、缺陷修复项目。第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入;第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要通过doclever设计测试用例即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。 第三、对于线上反馈、缺陷修复项目,如如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。

3.对于测试流程,如果是现在功能测试为主,那现在的测试流程相对之前,还算比较完整合理,但是提测质量不高,所以我们也需要在接口完成时介入编写接口自动化用例,但是有赞团队所说的:“需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。”对于敏捷开发,那启动开发的时间其实很紧急,没有那么多时间去评审风险和业务缺陷,流出更多是时间去写自动化用例兼其他测试项目的功能测试。

4.对于提测分支冲突问题,我们也可以学习有赞团队的搭载公交车发布模式,每一个服务都可以拉出一个test测试分支,所有开发提测时都把自己代码合并到test分支,以后解决bug也要同步自己分支,如果没问题了,可以把自己分支合并master,可以独立上线。

5.对于测试,分为三部分,第一部分是单元测试,这部分属于白盒测试,介于测试代码能力不足,这部分可以由开发自测;第二部分为接口自动化测试,这部分属于灰盒测试,测试会通过开发在doclever写的接口文档编写接口自动化,可以由测试介入进行接口集成测试;第三部分为UI自动化测试,由robotframework实现,同时做手动UI测试,验证功能展示效果和一些边界测试,测试完成后,验收通过上预发布测试,测试通过,上线上正式环境后通过UI自动化测试实现业务全覆盖。

6.对于压力测试,介于对服务器的要求高,所以我们最后通过第三方压测平台实现,如果后期资源到位,可以使用压测工具在测试环境实现。

7.对于线上环境监控,主要又运维来做好,比如宕机监控、服务挂点监控,sql超时监控等等。

好了,罗马不是一天建成的,我们只要重视了,并且有推进,就一定会有成绩,虽然我能力自愧不如,但是我愿意去学习,和测试组一同成长。

 

jenkins的一些其他必要设置(三)

接上次的继续聊…
这次说说jenkins的一些配置
1、先说系统管理中的系统设置
1
点击系统管理后,显示页面,在此页面中可配置需要的JDK、Maven、git等基本信息
2
配置JDK有两种方式:第一种、选择电脑本身已安装的jdk路径
17
第二种、可选择自动安装
3
在git插件安装好后,在此页面会有git配置栏
4
2、接着来配置一个在构建之后自动化发送邮件的基础设置
5
此处设置jenkins地址以及发送邮件人的邮箱
6
点击高级按钮,页面展开,填写以上必要的信息。可使用下边的邮箱验证来进行邮箱是否是通的
7
在具体的项目中,增加构建步骤中选择邮件设置(该选项也是在安装了对应的插件才显示的)
Project Recipient list 一栏填写被发送人的邮箱名称
8
点击advanced Settings出现高级设置
9
添加一项Recipient list后点击高级
10
在此填写相关人员的邮箱名称,以及发送邮件的标题和内容和相应的执行结果页面,点击应用保存生效,此时在giant项目执行之后,就会发送相应的邮件来通知相关人员,此次构建是否成功
3、Configure Global Security设置一项
11
选择随机选取,或者可以指定端口,默认是禁用,这会导致一个问题,随后来解释…
保存后
4、进行管理节点的设置
我们在日常工作中,所看到的晋中、秦皇岛…机器,这这就体现为节点设置,我们现在新建一个节点
进入管理节点后,点击左侧新建节点
12
输入对应的节点名称,选择第一项,点击OK 如果有需要可选择第二项来进行复制
13
填入远程工作目录,启动方法选择…java web start,这个选择项呢是在Configure Global Security设置中选择了指定端口或者随机端口才会出现的,这个有什么作用呢,接着看…
点保存之后,双击该节点
14
此处有两种方式来使用该节点
第一种,复制截图中下边的命令到指定的.bat文件中,可启用该节点(可用于windows或者linux)
15
第二种,点击Launch下载该节点的slave-agent.jnlp文件到指定的地方,启用(适用于windows系统)
16
这两方式都可以指定使用该节点的项目在指定的机器来运行项目。
下次再会…

testng套件测试

测试套件的测试是为了测试软件程序的行为或一系列行为的情况下,是一个集合。在TestNG,我们不能定义一套测试源代码,但它代表的套件是一个XML文件执行特征。这也允许灵活的配置要运行的测试。套件可以包含一个或多个测试和被定义由标签。 
testng.xml中有根标签。它描述了一个测试套件,这反过来又是由多个区段组成。 
下表列出了所有的可接受合法属性。 
属性:name 描述:此套件的名称。这是一个强制性的属性。 
属性:verbose 描述:这个运行级别或冗长。 
属性:parallel 描述:由TestNG 运行不同的线程来运行此套件。 
属性:thread-count 描述:使用的线程数,如果启用并行模式(忽略其他方式)。 
属性:annotations 描述:在测试中使用注释的类型。 
属性:time-out 描述:默认的超时时间,将用于本次测试中发现的所有测试方法。 
以下例子为有两个Test1 & Test2测试类一起运行测试套件。

创建一个类
创建一个Java类进行测试 MessageUtil.java 在 C:\ > JUNIT_WORKSPACE
/*
* This class prints the given message on console.
*/
public class MessageUtil {
private String message;
// Constructor
// @param message to be printed
public MessageUtil(String message) {
this.message = message;
}
// prints the message
public String printMessage() {
System.out.println(message);
return message;
}
// add “Hi!” to the message
public String salutationMessage() {
message = “Hi!” + message;
System.out.println(message);
return message;
} }

创建测试用例类
创建一个Java类文件名 Test1.java 在C:\ > TestNG_WORKSPACE
import org.testng.Assert;
import org.testng.annotations.Test;
public class Test1 {
String message = “Manisha”;
MessageUtil messageUtil = new MessageUtil(message);
@Test
public void testPrintMessage() {
System.out.println(“Inside testPrintMessage()”);
Assert.assertEquals(message, messageUtil.printMessage());
} }

创建一个Java类文件名 Test2.java 在C:\ > TestNG_WORKSPACE import org.testng.Assert; 
import org.testng.annotations.Test;  
public class Test2 { 
    String message = “Manisha”; 
 
    MessageUtil messageUtil = new MessageUtil(message);  
  
    @Test 
    public void testSalutationMessage() { 
        System.out.println(“Inside testSalutationMessage()”);        
 message = “Hi!” + “Manisha”; 
        Assert.assertEquals(message,messageUtil.salutationMessage());     
} } 

写入testng.xml 在C:\ > TestNG_WORKSPACE ,将包含标签如下: 
 
 
   
     
 
             
   
 
        
 
             
   
 
   
 
Suite1 包括 exampletest1 和 exampletest2. 

所有Java类编译使用javac。 
C:\TestNG_WORKSPACE>javac MessageUtil.java Test1.java Test2.java 
现在运行 testng.xml,将运行提供的测试用例类中定义的测试用例。 
C:\TestNG_WORKSPACE>java -cp “C:\TestNG_WORKSPACE” org.testng.TestNG testng.xml 
验证输出。 
Inside testPrintMessage() Manisha 
Inside testSalutationMessage() Hi!Manisha 
=============================================== Suite1 
Total tests run: 2, Failures: 0, Skips: 0 =============================================== 
您也可以检查测试输出文件夹;下Suite1文件夹中,可以看到两个HTML创建的exampletest1.html 和 exampletest2.html 

linux中搭建redis服务器

1.在虚拟机新建一个目录,比如/usr/local/redis

2.在目录下执行:

wget http://download.redis.io/releases/redis-2.8.17.tar.gz

解压:tar –zxvf redis-2.8.17.tar.gz

解压完成后,执行make命令

cd /redis/redis-2.8.17

make

make完成后,进入src目录,发现多了两个redis-server 和redis-cli文件

启动redis:cd/src–>./redis-server

启动redis后如图FA@TBU3YH9IW[YMT7~6D3PX

启动redis客户端:另外打开一个xshell窗口,进入安装目录下的src路径(cd /usr/local/redis/redis-2.8.17/src)执行命令

./redis-cli启动后如图:

0BZSOWMQ%7S2LNW3SC4N4AJ

验证连接:

ping

结果应该显示PONG

set name nihao

get name

结果应该是‘nihao’

如果上面一切都顺利,说明已经搭建成功了,然后就是关闭redis客户端

quit或者exit

然后关闭redis服务:./redis-cli shutdown

有没有很简单?

 

 

软件测试的心理

角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢?这没有统一的答案。因为,这与软件公司的规模,软件项目管理制度,公司领导和项目经理的管理风格,以及具体软件项目自身的特点有很大关系。而且,测试工程师也有普通和高级之分。

设置软件测试环境,安装必要的软件工具。运行软件,发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。对软件整体质量提出评估,确认软件达到某种具体标准

以最低的成本,最短的时间,完成高质量的测试任务; 在这其中,最重要的是要明确,程序员的责任和目标。在执行任何具体测试任务前,都要在项目组内对于责任和目标达成共识,以免带来后续工作的相互推诿。

另外一个值得注意的方面就是工作效率和质量,或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此,有什么可以借鉴的诀窍吗?请尝试以下方法,保证不会是您失望。

首先测试程序的核心功能,然后测试辅助功能。

首先测试功能,然后测试性能。

首先测试常见情况,然后测试异常情况。

首先测试经过变更的部分,然后测试没有变更的部分。

首先测试影响大的问题,然后测试影响小的问题。

首先测试必须测试的部分,然后测试可选或没有要求测试的部分

需要强调的一点是,无论你是多么高级的测试工程师,都要明白无论测试需要的工具多么复杂,测试步骤多么冗长,测试工程师在软件项目开发中始终都是扮演服务员的角色,这是由测试工作的特点决定的。任何服务都有被服务对象—客户,软件测试工程师的服务对象有哪些呢?

最重要的客户是软件的用户。测试工程师需要站在客户的使用和需求角度测试软件,报告问题。项目经理也是客户。测试工程师需要报告测试工作进度和发现的问题,尤其是严重的问题。程序员是最经常打交道的客户。为了便于程序员重复报告的错误,尽量提供良好的软件问题报告,以便程序员可以更快的修复软件错误。技术文档工程师、市场开发人员和技术支持工程师也都是测试工程师的服务对象。

前文已经指出测试工程师应该明确角色,明确任务和责任。知道哪些是自己份内的事,哪些是不属于自己的事。一定要尽最大努力完成份内的事,不要做不属于自己的事情,以免弄巧成拙。 为了更好的扮演软件测试工程师的角色,尽量避免犯下面的错误:

承诺完成测试的软件没有质量问题

软件测试只是保证质量的一种方法,软件测试工程师的工作不会直接提高软件质量,因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误,不能保证软件没有错误,不可能找出全部软件错误。个人的能力和对质量的影响范围很小,软件质量的提高要靠软件项目团队全体成员的共同努力。

承担软件的发布权利

不要因为软件中存在还没有修复的错误,而试图提出更改软件发布的计划。也不要认为已经完成了测试计划,自己决定可以发布软件。因为,改变软件发布计划可能要失去进入市场的良机和很多客户,对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外,软件发布后,如果用户发现了新的软件错误,公司领导或项目经理可能将过错加在软件测试人员的头上,因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。

扮演过程改进成员的角色

软件测试工程师必须报告错误,有时也要分析错误的类型、特征和产生错误的原因。但是,不要主动提出改进软件过程的具体改进措施,更不要直接干涉程序员的工作方式,以免出力不讨好,影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情,这是他们的本职工作。

客观独立的测试心理

采用独立测试方式,无论在技术上还是管理上,对提高软件测试的有效性都具有重要意义。

客观性
对软件测试和软件中的错误抱着客观的态度,这种客观的态度可以解决测试中的心理学问题,既能够以揭露软件中错误的态度工作,也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。
专业性
独立测试作为一种专业工作,在长期的工作过程中势必能够积累大量实践经验,形成自己的专业优势。同时软件测试也是技术含量很高的工作,需要有专业队伍加以研究,并进行工程实践。专业化分工是提高测试水平,保证测试质量,充分发挥测试效用的必然途径。
权威性
由于专业优势,独立测试工作形成的测试结果更具信服力,而测试结果常常和对软件的质量评价联系在一起,由专业化的独立测试机构的评价,更客观、公正和具有权威性。
资源有保证
独立测试机构的主要任务是进行独立测试工作,这使得测试工作在经费、人力和计划方面更有保证,不会因为开发的压力减少对测试的投入,降低测试的有效性,可以避免开发单位侧重软件开发而对测试工作产生不利的影响。