看有赞测试团队的读后感

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

软件测试的心理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

承担软件的发布权利

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

扮演过程改进成员的角色

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

客观独立的测试心理

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

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

设计功能和界面测试用例

1.1 文本框、按钮等控件测试

1.1.1 文本框的测试

如何对文本框进行测试

a,输入正常的字母或数字。
b,输入已存在的文件的名称;
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
d,输入默认值,空白,空格;
e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
g,输入特殊字符集,例如,NUL及\n等;
h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示

在测试过程中所用到的测试方法:

1,输入非法数据;
2,输入默认值;
3,输入特殊字符集;
4,输入使缓冲区溢出的数据;
5,输入相同的文件名;

命令按钮控件的测试

测试方法:

a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;
c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;

单选按钮控件的测试

测试方法:

a,一组单选按钮不能同时选中,只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;

up-down控件文本框的测试

测试方法:

a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;
b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
c,直接输入超边界值,系统应该提示重新输入;
d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试;
e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法:

a,条目内容正确,其详细条目内容可以根据需求说明确定;
b,逐一执行列表框中每个条目的功能;
c,检查能否向组合列表框输入数据;

复选框的测试

测试方法:

a,多个复选框可以被同时选中;
b,多个复选框可以被部分选中;
c,多个复选框可以都不被选中;
d,逐一执行每个复选框的功能;

列表框控件的测试

测试方法:

a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
b,列表框的内容较多时要使用滚动条;
c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;

滚动条控件的测试

要注意一下几点:

a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
c,单击滚动条;
d,用滚轮控制滚动条;
e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

a,控件间的相互作用;
b,tab键的顺序,一般是从上到下,从左到右;
c,热键的使用,逐一测试;
d,enter键和esc键的使用;

在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
案例演示:打开word中的”替换”对话框
测试本功能有通过测试和失败测试两种情况
通过测试:

1,输入内容直接查找,或查找全部
2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过”测试用例”,再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

失败测试:
1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

替换测试大体相同.
关于编辑操作窗口的功能测试的用例:
1,关闭查找替换窗口.不执行任何操作,直接退出;
2,附件和选项测试.假如,设定”精确搜寻”,”向后”搜索等附件选项等等来测试;
3,控件间的相互作用.如,搜寻内容为空时,按钮”搜寻全部”,”搜寻”,”全部替换”,”替换”都为灰色.
4,热键, Tab键.回车键的使用.

插入操作
1,插入文件
测试的情况
a,插入文件;
b,插入图像;
c,在文档中插入文档本身;
d,移除插入的源文件;
e,更换插入的源文件的内容;

2,链接文件
测试方法:
a,插入链接文件;
b,在文档中链接文档本身;
c,移除插入的源文件;
d,更换插入的源文件的内容.

3,插入对象
要测试的内容
a,插入程序允许的对象,如,在word中插入excel工作表;
b,修改所插入对象的内容.插入的对象仍能正确显示;
c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

编辑操作
编辑操作包括剪切,复制,粘贴操作.

测试剪切操作的方法
a,对文本,文本框,图文框进行剪切;
b,剪切图像
c,文本图像混合剪切
复制操作方法与剪切类似.

测试时,主要是对粘贴操作的测试,方法是:
a,粘贴剪切的文本,文本框及图文框;
b,粘贴所剪切的图像;
c,剪切后,在不同的程序中粘贴
d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
e,利用粘贴操作强制输入程序所不允许输入的数据.

界面测试用例的设计方法
1,窗体
测试窗体的方法:
a,窗体大小,大小要合适,控件布局合理;
b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

2,控件
测试方法:
a,窗体或控件的字体和大小要一致;
b,注意全角,半角混合
c,无中英文混合.

菜单

进行测试时要注意
a,选择菜单是否可以正常工作,并与实际执行内容一致;
b,是否有错别字:
c,快捷键是否重复;
d,热键是否重复;
e,快捷键与热键操作是否有效
f,是否存在中英文混合
g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
h,鼠标右键快捷菜单

特殊属性
1,安装界面应有公司介绍或产品介绍,有公司的图标
2,主界面及大多数界面最好有公司图标
3,选择”帮助”->”关于”命令,应看见相关版权和产品信息

流程分析法

流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计,是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种很重要的方法。在白盒测试中,路径就是指函数代码的某个分支组合,路径覆盖法需要构造足够的用例覆盖函数的所有代码路径。在黑盒测试中,若将软件系统的某个流程看成路径的话,则可以针对该路径使用路径分析的方法设计测试用例。

  采用路径分析的方法设计测试用例的好处:

1、降低测试用例设计的难度。即只要清楚程序流程、看懂程序流程图,就可以设计出质量较高的测试用例;

2、是在测试资源紧张的情况下,可以据此有选择的执行测试用例,而非全部依靠经验做取舍。

使用流程分析法的具体实施步骤:

步骤1:画出业务流程图;

步骤2:定义状态节点和条件分支;

步骤3:确定测试路径;

步骤4:选取测试数据,构造测试用例。

  例子:

  一、需求:使用ATM机取款

  二、分析:

1、测试需求分析:

a)用户向ATM取款机中插入银行卡,若银行卡合法,取款机提示用户输入密码;

若插入无效银行卡,取款机提示用户“银行卡无效”,并自动退卡。

b)用户输入银行卡密码,取款机将密码传至银行主机进行校验。若密码正确,取款机提示用户输入取款金额,

提示信息:“请输入取款金额:”若密码错误,取款机提示用户:“密码错误!”,并退回输入密码界面。

当三次输入密码错误时,自动退卡,锁卡。提示:“密码错误,密码输入次数超限!”。

c)用户输入取款金额,系统校验金额正确。即取款机余款大于用户取款金额。提示:“请确认取款金额为XX!”。

用户按下确认键,确认取款XX。若用户输入取款金额不正确,提示:“输入错误!”。

此处为分析方便忽略输入取款金额错误的各种情况下的异常流程处理,降低分析的复杂度。

d)系统同步银行主机,点钞票,输出给用户并减去用户卡中相应数目的存款金额。

若卡内余额小于用户取款金额,则提示:“余额不足!”,并退回输入取款金额界面。

若取款机与银行主机通信超时、通信中断、传输错误等情况,提示:“连接超时,本次操作取消”。

若主机已经做了数据库操作,减去了用户存款余额,则要做回退操作。

e)用户取款,银行卡退卡。用户拔出银行卡。取款机恢复初始界面。正常取款操作结束。

若用户未按时拿走取出的钱款、用户未按时拔出银行卡,则取款机做相应异常处理操作。

2、测试设计方法分析(流程分析法):

根据需求,画出业务流程图,如下:

  定义状态节点和条件分支:

  上面的业务流程图中,只描述正常流程-取款成功的情况。异常流程未做描述,是为了分析方便,实际中异常流程必须在业务流程图中描述清楚状态、分支等。

  3、用例设计(确定测试路径):

  需求描述及流程图中,ATM取款机的提示信息对应于测试用例中的预期输出部分,用户的操作对应测试用例中的测试步骤部分。原则是一条有效路径使用一个测试用例覆盖。

  依据业务流程图确定测试路径,即需要测试的业务流程。其主要包含三个方面:

  a)正常流程,取款成功(基本流程):对应一次性取款成功;

  b)异常流程,取款失败(分支流程):对应取款失败,包括退卡、吞卡;

  c)异常流程,取款成功(循环流程):对应取款中间出现意外,比如密码输入错误,但是最终成功取钱的情况。

           不要只是为了证明程序能够正确运行而去测试程序。相反,应该一开始就假设程序中隐藏着错误(这种假设几乎对所有的程序都成立),然后测试程序,发现尽可能多的错误事实上,如果把测试目标定位于要证明程序中没有缺陷,那么就会在潜意识中倾向于实现这个目标。也就是说,测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。另一方面,如果把测试目标定位于要证明程序中存在缺陷,那么就会选择一些容易发现程序缺陷的测试数据。而后一种态度会比前者给程序增加更多的价值。

  三、用例详细(选取测试数据,构造测试用例):

  根据上一步确定的测试路径,写出用例详细。

  流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等。

  流程分析法重点在于测试流程。因此,一般每个流程用一个测试用例验证。但是,流程测试没有问题并不能说明系统功能没有问题,还需要针对单步功能进行测试。对于包含复杂流程的系统,只有功能点和处理流程都进行测试覆盖,才算是比较充分的测试。

自动化测试的学习方向

自动化测试是一个很广义的概念,一般说来所有能替代人工测试的方式都属于自动化测试,我们一般说的单元测试就是自动化测试的一种,单元测试很多人称之为“毫秒级的自动化测试”。

自动化测试是很难的,从某种意义上来说比性能测试更难。性能测试可以依仗的东西很多,比如LR等,而自动化测试的工具很多情况下只是一个半成品,比如selenium webdriver,你需要花很多时间去使用代码编写用例,并且维护这些用例,这一过程是漫长而艰辛的,特别对一些没有开发经验的测试同学来说,这个过程非常痛苦,每天的工作内容好像是自虐,而且自虐一段时间后信心基本崩溃,从此谈自动化色变,把所以的错归结于自动化测试策略与技术,而不从本身去找问题。

不过相比于性能测试而言,自动化测试的实践者往往是更加幸运的。最简单的例子是一般的性能测试人员离开了工具基本上就无所作为了,而自动化测试人员则可以利用自己掌握的语言知识与代码知识自己创造工具,说实在的,这是一件很有成就感的事情,乙醇自己就在写工具,从简单的cli工具到复杂的web工具,一切都是托以前自动化测试实践的福。
自动化测试很难,那么我们为什么要坚持自动化呢?
单元测试是保证代码质量最基本也是最根本的途径,单元测试是自动化测试的一种,因此自动化的重要性不言而喻;
集成测试在很多情况下非常适合使用自动化的手段去运行,最明显的例子是rails里的integration test;
当你的单元测试和集成测试都没做好,甚至是没有做的情况下,UI级的自动化测试可以扮演救火队员的角色,尽管成本很高,但是可维护的UI测试代码是回归测试的福音,也是提高测试生产力的重要手段;
自动化测试可以培养团队,一个团队如果可以把自动化测试做好,那么他们的开发水平一定不低,而且如果这些人去做开发,代码的质量反而比一般的开发人员要高,原因很容易理解,测试人员坚信没有测试过的东西就是不可信的,代码如果没有被测试过,那么代码自然是不可信的,不可信的代码就需要用单元测试去覆盖,因此这可以从根本上提高代码的质量。
下面是一下学习自动化测试应注意的问题,由大神总结,我摘过来的
一:大神,帮帮忙啊,救命啊,老是搞不定啊
这句话我经常看到,一般来说有时间的话,我会教你怎么去解决这个问题。不过几天后,类似的问题出现了,你还是解决不了。首先,大神很忙。有些大神愿意分享,他们贡献的资料很多,但是,你不查,你不看,你总是认为”不耻上问”最直接,但大神帮你解决问题的同时又增加了你的惰性和依赖性,结果你进步的很慢,一直没有自信,后来问题太多,直接放弃。
遇到问题不要害怕,去网上搜一下,很多人会遇到同样的问题,大概看一下别人怎么解决的,然后自己举一反三,不仅解决了问题,而且还能有所进步,这才是正道。
后来有人问我问题,我一般的回答是”去网上搜一下XXXX”,不是我不愿意帮你,我是在教你,无论做什么事,最后你只能靠自己。
一般遇到这种节奏的人学习能力恐怕是不强的,如果自动化测试交给这些人来做,那么作死是可以预期的到的。
提高自己的学习能力与纠错能力,遇事不慌,有一套比较好的解决问题的方法,坚持下去,慢慢的改进,慢慢的提升自己,这样就可以了。

二:我看了,这些代码我都看过了,但是这个项目到底怎么做啊
这是典型的光说不练。有一本书叫做webdriver实用指南,里面有很多代码,涵盖了ruby/python/java/watir-webdriver等。有人一再问我书里面提到的问题,我的回答总是:”这些代码你敲过了吗?”,答曰:”没,但是我有看过了”。对此我只能哭笑不得,看过不等于做过,自动化测试项目说白了就是代码实践,光看不写是学不会堆代码的。因此,在做项目的时候,一定要多做,别只是在收集别人的意见,比如”你觉得我这个项目适合做自动化吗?”, “我应该用什么工具做自动化啊?”,别人总是旁观者,只有你亲自实验得出的结果才是准确的,不要把别人的意见当作圣旨箴言,自己实践才是第一要务。
对于自动化测试,我的理解是先把代码敲熟练了。如果一个工具或者代码不能掌握到得心应手的程度,那么做起项目来应该是困难重重的。还有,自己多写代码,多去理解错误提示,很多问题你自己就能顿悟了,不要遇到一点点小问题就去问别人,别人不但不会帮你,也许心里还会鄙视你,真的,我以前就被鄙视过。
看过不等于做过,这点很重要。就算你看过岛国所有一线女优的片子,但如果没做过的话,你仍然只是个可怜的处男,连逆袭的机会都没有。

三:大神,为什么出错了啊
这是太言简意赅了。我很想帮你,但是在帮你之前我会先问一串:”你用的是什么工具,什么操作系统,什么编程语言之类”,当然了,这是在我心情好的时候,有时候心情不爽,直接拉黑,整个世界就清静了。提问是有艺术的,把问题描述清楚,别人才好去帮你,不然没人会理你。然后你感到自己被忽略了,然后你伤心了,然后你吐槽了,然后你无力吐槽了,最后你放弃了。一样的作死的节奏。其实,只要你把问题描述清楚,然后去网上搜索一下,基本就能得到答案。记住,google是你最好的朋友,大神不是。

四:我只要会xxx语言就可以了,其他的语言不需要
理论上这是正确的,但是语言说白了还是工具,在做一件很复杂事情的时候,单一的工具往往是难以很好的完成任务的。任何语言都有其擅长的部分,不擅长的地方,取长补短才是王道。我用过很多的语言,但是在做前端UI自动化的时候,我发现ruby+watir webdriver很方便,于是一直用,项目一直在做,几年了都没失败。但如果当年用的是java的话,我估计我们的产品在改版几次以后,这个自动化项目就要寿终正寝了。多学一点语言其实没坏处,不过如果你选择专注,那么你有你的道理,你可以坚持,没人会责怪你。

稍微总结一下自动化应该怎么做。

原则一:能力使然
这个能力是指的综合能力。首先你要会测试,自动化测试毕竟是在用代码写用例。其次你要会写代码,你要把用例翻译成代码。不要迷信于录制回放工具,光用这个基本上做不成项目。而且会录制回放对你来说也没什么意义,任何一个人学习个一天一定能学会录制回放。做自动化测试实际上是对自身能力一个很好的提升,一定要抓住这个机会,不要去弄没啥技术含量的录制回放,学会了有什么用,大家都会录,凭什么让你录。
做自动化测试其实挺难的,会有很多困难,毕竟前端UI的东西是最容易变化的,但是如果你能力足够强大的话,这些变量对你来说总会有办法去克服。比如UI老是变,就可以封装一些page object的思想,让UI修改变得容易一些。还有用例老是跑出错,不如在代码里加入自动截图,一眼就能定位问题,代码维护起来自然就容易不少。
没有一个成功的自动化项目是菜鸟做成功的,当你做成功了一个项目以后,你自然就从菜鸟变成了高手。

原则二:不变应万变
UI总是在变,比孙悟空还会变。但是在变的过程中一定有一些东西是不变的,我们做自动化测试的时候要尽量用这些不变的东西。比如表单元素的name,一般不会频繁变动,相对稳定。另外数据是会变的,比如你进入一个工单的列表页面,有时候会有10条数据,有时候会有20条。有时候第一条数据的内容是A,有时候是B,这是因为数据在变化,这时候你只要让数据能固定住,这样进入工单列表后一定只有10条数据,第一条数据永远是A,那么你的用例写起来自然是神清气爽,难度不高,也容易维护。

原则三:团结一切可团结的力量
对我来说,很多时候我总是一个人在战斗。开发努力改一个迭代,改出若干新功能和若干bug,然后我更新对应的自动化用例。因为我的框架扩展性还不错,所以开发改两周的UI,我两天就能改完,不过如果老是我一个人在改,那么我一定会非常孤独吧。这时候不如让手工测试人员帮我一起改,对他们来说自动化是福音,能节约其回归的时间,所以改用例对他们来说是很有必要的一件事情,然后我教他们怎么改,他们学会了以后我就可以放手去做其他事情。现在我已经基本不做自动化了,原因就在这里,有人帮我做,而且比我更有动力去做。

原则四:把成果展示出来
我专门写了个报告平台来展示自动化的测试报告。一定要让团队成员知道你在干什么,报告是最简单的途径。成功的项目一定有很不错的报告,这点不容置疑。

原则五:可维护的代码
代码要容易读,容易改。看看我写的lazyman框架里的示例代码吧,再看看原生的webdriver代码,你应该会有所感触。记住,原生的webdriver代码一定是不太好维护的,没有框架支持和封装,原生的webdriver代码一般很难规模化,很难达到成百上千个用例的规模。好的框架可以使你事半功倍,不要迷恋原生代码,可以用,但不够用。

最后是学习路线

1.学习python基本语法。

2.上w3cschool这个网站,学习HTML/CSS下的html、xml、webservice三个教程。

3. 然后下一个python的requests库学习写最简单的网络爬虫。知乎上爬虫教程一大堆。3是第一个里程碑,学写简单爬虫一方面有一定的成就感,一方面又知道了接口到底是怎么回事。同时还学到了怎么解析一个页面。

4.学习python的测试框架unittest,知道怎样用unittest和python的mock模块写一个小单元测试。

5.把3和4结合起来,你掌握http自动化接口测试。

6.学selenium的库和页面对象模式

7.把2、4、5、6结合起来,你应该能写既支持web测试又支持接口测试的自动化测试脚本了。

8.学robotframework,你可以把自动化测试变成关键字驱动和数据驱动的了。

9.学python的高级一点的语法。如装饰器、线程进程协程。你可以让测试并行执行,并自动记录测试步骤到log文件里了。

10.学jenkins,测试不再需要你手工去启动了。测试也可以分步式运行到多个环境上了。

11.学docker、git、gitlab等的简单使用,从此测试脚本不用再人肉更新、测试环境也不用人工搭建。这里也要学linux的简单使用,

12.回到w3cshool,学习javascript、ajax、jquery、bootstrap。至此你可以写50%以上简单网站的前端了。

13.学习python的flask库,学mysql或mongodb是怎样和flask一起用的。至此你可以写简单网站的后台了。你还可以快速开发webservice接口了。

14.综合12和13,你可以开发一些测试管理工具了。比如写一个管理很多jenkins master的ci调度平台。也可以写一个提供统一样式的测试报告的web展示平台。写一个监控所有测试情况的看板。写帮你生成测试文档的脚本。写测试环境的管理工具。

并且14是一个里程碑,你可以理解开发人员的一些思路了,比如为什么开发人员老是不愿意好好写单元测试、老是说这不是bug、老是说几点干完但却拖到半夜还做不完,特别是你做的东西交给别人测的时候。你也可以理解web测试的接口测试、单元测试怎样做比较好,因为如果不好,你是不愿意用到自己写的网站工具上的,你会觉得浪费时间。

15.学压测工具locust、jmeter等,7里写的框架可以支持压力测试了。同一套接口测试脚本,既做自动化测试又做压测了。

16.想做app测试的话,学一个appnium之类的框架。

17.补课时间,好好把计算机网络补起来,这个是真有用

18.java补起来。没办法,用java的单位多。要找工作机会也多。现在流行java+python都要会。其实都差不多,举一反三。

19.不知道后面再怎么学了。再提高提高web开发能力。前端框架学一个,以后开发一些更漂亮更炫的前端页面。再学下什么消息中间件之类的

这些步骤不用走完,写这些步骤的人也才到14,但是可以做个参考

粗谈Patton的《软件测试》

Ron Patton的《软件测试》是一本经典的软件测试方面的书籍,作者是一位有着多年软件测试经验的测试工程师,他深入浅出的讲了许多他对软件测试的见解与知识。虽然这是一本十多年前出版的老书,许多技术已经被更替,但是他对于测试的讲解还是令我受益匪浅,我总结了一些可能对大家有用的部分。
首先我们了解一下Patton对软件缺陷做的定义,他认为符合下面5个规则的才能叫软件缺陷:
1.软件未实现产品说明书要求的功能。
2.软件出现了产品说明书指明不应该出现的错误。
3.软件实现了产品说明书未达到的功能。
4.软件未事先产品说明书虽未明确提及但应该实现的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
那么为什么会出现软件缺陷
1.首先可能是产品说明书不够全面,经常更改,或者整个开发小组没有很好的沟通。为软件做计划是极其重要的,这一步没做好就可能会产生上述第4、第5类的缺陷。
2.然后可能是设计,这是程序员规划软件的过程,这个过程好比是建筑师规划蓝图的过程,这个过程产生缺陷的原因跟产品说明书是一样的–随意,易变,沟通不足
3.最后是编码错误,通常代码错误可以归咎于软件的复杂性、文档不足、进度压力或者普通的低级错误。
软件测试的目的就是找到软件的缺陷,但是书中却说软件是不可能完美的,软件测试也不仅仅是技术的问题。
1.完全测试是不可能的。主要有以下4个原因:
a.输入量太大
b.输出结果太多
c.软件执行路径太多
d.软件说明书是主观的,而使用者是客观的
2.软件测试是有风险的行为。
软件测试不可能测试所有的状况,不完全测试的地方又有可能存在软件缺陷。软件终归是要发布的,所以测试需要停止,但如果过早的停下来,就还有一部分没有测试到。那么选择一些关键的部分测试就是冒险的行为。测试员就要学会一个关键的思想:如何把巨大规模的测试减少到可控制的范围,以及针对风险做明确的抉择。
3.测试无法显示潜伏的软件缺陷。
就像除虫公司来家里杀虫不能把房子里所有的虫子杀完–总有些虫子藏在墙里没有找到。软件测试也没办法找到一些隐藏起来的缺陷。
4.找到的缺陷越多,就说明软件缺陷越多
很多时候中找到一个缺陷,就会接二连三地找到更多。其原因是:
a.程序员也有心情不好的时候,烦躁的人容易犯一些自己无法发现的小错误。一个缺陷的出现很可能表明附近还有更多的缺陷。
b.程序员容易犯同样的错误,每个人都有自己的习惯,在没有发现这个习惯性错误之前,程序员可能已经造成好几个一样的缺陷。
c.某些缺陷很可能是冰山一角,一个找不到原因的、不明显的错误很可能后面隐藏了一个巨大的缺陷。
5.杀虫剂怪事
就像虫子会对杀虫剂产生抗体一样,测试员用同样的方法测程序也会漏过新的错误,所以测试员要不断编写新的、不同的测试程序。
6.并非所有软件缺陷都要修复,有许多原因会使一个团队放弃修复某些缺陷:
a.没有足够的时间,产品必须要马上上线,但还有一些缺陷没有修复。
b.不算真正的软件缺陷。测试可能错误的把某些缺陷当作功能看待,而没有上报。
c.修复风险太大。当软件本身脆弱复杂时或者产品发布迫在眉睫,修复一个缺陷很肯能导致新一个甚至更多个缺陷,而这个缺陷又不会造成太大的危害。那么放弃修复这个缺陷无疑是明智的选择。
7.产品说明书从没有最终版
IT行业竞争太大,更新太快,所以我们的产品也在不断的更新,测试也要不断的测试新的功能并且保证以前的功能没有发生新的缺陷。
8.软件测试员在团队中不受欢迎
测试的目标就是寻找程序员的错误,不断的否定同事成果的人总是不受欢迎的。那么就需要我们做到以下几点:
a.早点找出缺陷,尽早的找出缺陷,使其产生的影响尽量减小。
b.控制情绪,诚然,测试员喜欢自己的工作,找出缺陷时非常大兴奋,但是也不能兴冲冲的去找同事:“你的程序出bug了”,更不能到处宣扬,他肯定会不高兴的。
c.不要总是报告坏消息,当同事做出一个厉害的功能时,应该毫不吝啬的夸奖。
希望我总结的一些内容能对大家有一点帮助。