51Testing软件测试网

 
 

常用链接

  • 我的随笔
  • 我的评论
  • 我参与的随笔

留言簿(3)

  • 给我留言
  • 查看公开留言
  • 查看私人留言

随笔档案

  • 2021年6月 (1)
  • 2021年3月 (1)
  • 2020年9月 (1)
  • 2020年3月 (1)
  • 2020年1月 (2)
  • 2019年12月 (3)
  • 2019年11月 (5)
  • 2019年10月 (1)
  • 2019年9月 (2)
  • 2019年8月 (14)
  • 2019年7月 (20)
  • 2019年6月 (15)
  • 2019年5月 (12)
  • 2019年4月 (19)
  • 2019年3月 (20)
  • 2019年2月 (9)
  • 2019年1月 (16)
  • 2018年12月 (17)
  • 2018年11月 (21)
  • 2018年10月 (16)
  • 2018年9月 (20)
  • 2018年8月 (22)
  • 2018年7月 (3)
  • 2018年6月 (1)
  • 2018年5月 (7)
  • 2018年4月 (1)
  • 2018年3月 (3)
  • 2018年2月 (6)
  • 2018年1月 (2)
  • 2017年9月 (8)
  • 2017年8月 (28)
  • 2017年7月 (3)
  • 2016年11月 (1)
  • 2016年6月 (1)
  • 2016年4月 (1)
  • 2016年2月 (2)
  • 2015年7月 (1)
  • 2015年5月 (1)
  • 2015年4月 (2)
  • 2015年3月 (1)
  • 2015年2月 (2)
  • 2015年1月 (6)
  • 2014年12月 (3)
  • 2014年11月 (3)
  • 2014年10月 (3)
  • 2014年9月 (2)
  • 2014年8月 (8)
  • 2014年7月 (16)
  • 2013年12月 (5)
  • 2013年11月 (1)
  • 2013年10月 (3)
  • 2013年9月 (2)
  • 2013年8月 (2)
  • 2013年7月 (3)
  • 2013年5月 (1)
  • 2013年4月 (2)
  • 2013年3月 (2)
  • 2013年2月 (3)
  • 2013年1月 (4)
  • 2012年12月 (4)
  • 2012年11月 (4)
  • 2012年10月 (3)
  • 2012年9月 (4)
  • 2012年8月 (3)
  • 2012年7月 (4)
  • 2012年6月 (2)
  • 2012年5月 (2)
  • 2012年4月 (1)
  • 2012年3月 (2)
  • 2012年2月 (2)
  • 2012年1月 (1)
  • 2011年12月 (3)
  • 2011年11月 (2)
  • 2011年10月 (1)
  • 2011年9月 (4)
  • 2011年8月 (3)
  • 2011年7月 (2)
  • 2011年6月 (4)
  • 2011年5月 (4)
  • 2011年4月 (2)
  • 2011年3月 (4)
  • 2011年2月 (4)
  • 2011年1月 (7)
  • 2010年12月 (7)
  • 2010年11月 (5)
  • 2010年10月 (4)
  • 2010年9月 (7)
  • 2010年8月 (7)
  • 2010年7月 (3)
  • 2010年6月 (3)
  • 2010年5月 (4)
  • 2010年4月 (4)
  • 2010年3月 (5)
  • 2010年2月 (3)
  • 2010年1月 (4)
  • 2009年12月 (3)
  • 2009年11月 (3)
  • 2009年10月 (1)
  • 2009年9月 (3)
  • 2009年8月 (2)
  • 2009年7月 (3)
  • 2009年6月 (1)
  • 2009年5月 (2)
  • 2009年4月 (4)
  • 2009年3月 (5)
  • 2009年1月 (1)
  • 2008年11月 (2)
  • 2008年7月 (5)
  • 2008年6月 (4)

文章分类

  • 行业资讯(45) (rss)
  • 软件业务知识(43) (rss)
  • 软件开发知识(33) (rss)
  • 软件测试工具(39) (rss)
  • 软件测试技术(157) (rss)
  • 软件测试管理(40) (rss)
  • 软件测试职业发展(57) (rss)

51testing软件测试网

搜索

  •  

最新评论

  • 1. re: 淘宝后台技术大揭秘,不看这篇你双十一要损失几个亿!
  • 关注官方公众号“Atstudy网校”,点击中间菜单栏“双11”,领取双十一技术内幕资料。
  • --51testing
  • 2. re: 软件测试流程的一点感悟
  • 提交缺陷时只需要描述现象即可,过多的分析可能会误导开发
  • --凡客诚品
  • 3. re: 软件测试流程的一点感悟
  • 阿达宿建德江阿斯顿
  • --凡客礼品卡
  • 4. re: 手机软件测试的经验总结
  • 很好啊~不错
  • --乐蜂网
  • 5. re: 手机软件测试的经验总结
  • 很好啊~
  • --罗莱家纺

阅读排行榜

  • 1. 软件测试流程的一点感悟(1090)
  • 2. 5年经验之谈:月薪3000到30000,测试工程师的变“行”记!(939)
  • 3. 测试自动化及软件测试工具的比较(856)
  • 4. 银行线上信贷系统如何做好接口测试?手把手教你接口工具Postman(825)
  • 5. 软件为什么要做异常测试?测试员必知的22个测试点总结!(806)

评论排行榜

  • 1. 软件测试流程的一点感悟(4)
  • 2. 软件测试的原则和经验 (4)
  • 3. 嵌入式软件测试技巧(2)
  • 4. 手机软件测试的经验总结 (2)
  • 5. 常用软件测试工具的分析与比较(1)

Powered by: 博客园
模板提供:沪江博客
IT博客 | 首页 | 发新随笔 | 发新文章 | 联系 | 聚合 | 管理

40年后《哪吒》刷爆朋友圈:不认命,就是我们这一代的命!

这几天,无论是朋友圈、微博还是各大论坛,都会冷不丁的跳出那个“黑眼圈烟熏妆”丑萌丑萌的小孩,无数人奔走相告。

趁着闲暇之余,我也去看了《哪吒之魔童降世》,我想很多人会跟我一样,抱着看神话故事的心态开始,结束时却老泪纵横。


小时候,我觉得哪吒叛逆任性,不服父母管教,甚至与天下为敌;长大后,我才明白,渴望被理解,自尊心强,事事不服输,在生活中摸爬滚打的我们,又何尝不是另一个哪吒呢?

“我命由我不由天!哪吒的命就是不认命”

1、偏见,可以杀死人

哪吒出生时就注定了他的与众不同,肉身是一团火球,出生自带魔法,一身傲骨,桀骜不驯,因其异于常人,陈塘关的百姓惧他、怕他、疏远他、憎恶他,甚至有人诅咒他“怎么不去死!”哪吒一出生就被冠上了妖魔的称号,人们认为“妖就是妖”,认为他早晚会是祸害人间,即使他内心多么的孤单无助,即使他只是个天真无邪的孩子。


耳边一直回响着申公豹的那句话“人的成见是一座大山,任你怎么努力,也休想搬动。”没错,这句话也只有申公豹说得出口,因为天尊的不公平,他一出生就注定是妖,因为人们的偏见,他注定被驱赶。成见这座大山足以把每个人困死在命运的轮盘中,你只能被肆意定义,无法选择。

偏见让哪吒自暴自弃,

偏见让敖丙自甘堕落,

偏见让申公豹蜕化变质,

电影中的很多人都或多或少的被命运的枷锁禁锢,被妄断为异类,有的选择与命运抗争,无论成败至少努力过,有的则选择束手就擒,甘被命运打败。这就是人世间赤裸裸的写照。


折射到现实生活,偏见其实无处不在:

你上学成绩没有隔壁小王好,你长大肯定没出息;

女生30岁不结婚,肯定心理或者生理有问题;

年轻人靠自己闯出一番事业,他家里肯定很有钱;

女孩靠自己升职加薪,她和老板肯定有一腿;

他爸爸是小偷,他肯定也不是什么好人……

偏见可能只是一句不怀好意的冷笑话,但偏见的的确确能够刺痛一个人的内心,决定一个人的命运,要知道,偏见可以杀死人。

没错,哪吒打破了既定的命运,奋起反抗,以一己之力拯救了陈塘关的民众,成为了真正的英雄,但这需要莫大的勇气。回到现实,又有多少人依然被成见死死困住,被折磨得遍体鳞伤。

该奋斗的年纪,我希望你不要因此被偏见打败,不要活在别人的看法里,听从内心的声音,为自己而活。每个人都是哪吒,我们终将成为自己的英雄!


“ 世间有人谤我、欺我、辱我、笑我、轻我、贱我、恶我、骗我,该如何处之乎?”

“ 只需忍他、让他、由他、避他、耐他、敬他、不要理他、再待几年,你且看他 。”

若命运不公,那就和它斗到底

哪吒、敖丙、申公豹都曾遭遇命运的捉弄,但最终都没有被命运摆布。不认命,才能改变宿命。

魔丸转世,幻化成妖,祸害人间,辗转三年,天雷诛之,便是哪吒的命。但他偏要逆天改命,以一己之力,拯救了整个陈塘关;

父亲的期待、全族的希望,这是敖丙的命,但他最终遵从内心,匡扶正义,最后选择牺牲自己;

生而为妖,世人唾弃,不得重用,便是申公豹的命,但他努力修炼,用尽全力往上爬,无论结果好坏,他曾努力过。

我们常常会思考一个问题“什么是命?”很多人认为人的骨子里都有一种“命运观”,也就是“尽人事,听天命”,努力做自己想做的事,其他的交给命运。顺理成章,人的出生、人的成长、人的遭遇都是命中注定的,只要顺着生活的轨迹,遵循既定的命运,便是最好的安排。其实有一部分人曲解了这句话,他们认为只需等着命运安排,时间决定一切,把努力奋斗全然抛在脑后,殊不知,此时面对偏见面对不公,认命才是人生中最毒的毒药。


“生而为魔,又能怎样?”

“我命在我,不由天,是魔是仙,我自己说了算!”

“就算天要亡我,我也绝不认输!”

不认命,打破世俗的偏见,我的命运我说了算,哪吒身上有80、90、00后的影子。

我们无法选择自己的出身、相貌、智商,没错,我们就是这么普通,但普通人也有两种活法,

有的人一生碌碌无为,得过且过,他们把这归罪于命运的不公,而有的人认为人生只有一次,没有努力过绝对不认输,就像哪吒一样不认命。


我见过山沟里的贫困学生,起早贪黑、翻山越岭、发愤图强,最后考入一线城市成家立业,改变家乡命运;

我遇到过父亲病倒,母亲改嫁,还要照顾弟妹的姑娘,靠一己之力撑起一个家,最后成为知名企业高管;

我面试过相貌普通、学历一般、看起来准没戏的小伙子,出乎意料,他站在我们面前镇定自若,回答如流。后来才知道他每天定时看数十篇技术文章,基础知识、语言、工具等更是得心应手,没有理由不录取这么优秀又努力的员工。

倘若这一生你没有为自己认真地努力过、拼搏过,就请别抱怨自己一无所有了。


3、不认命,就是我们的命

作家麦家说过:

“你是你人生的导演,趁年轻,趁还没有老朽前,干吗不给自己安排几场癫狂的激情戏?”

人生如此短暂,如不孤注一掷,放手去试,你怎么知道自己不行?

40年过去了,回忆一整个青春,哪吒长大了,我们也长大了,哪吒不再是动画片中的小孩,他更是警醒我们成年人的标杆。

“如果你问我,人能否改变自己的命运,我也不晓得,但我晓得,不认命,就是我们这一代的命。”


面对突如其来的需求变更,项目组所有程序员24小时不间断开发,只为按时交付项目;

APP上线前,测试员需要测试几十种机型,一个设备上出现问题,需要在另外的设备上进行校验,排查会不会出现同样的问题,他们一遍遍耐心的找bug,只为可以顺利上线;

大学阴差阳错的被调剂到了化学专业,但我从未改变对IT行业的热爱,一边认真完成学业,一边从零基础开始专研软件测试,从语言到自动化工具再到项目实践,苦点累点只因我喜欢,毕业后,我顺利地进入了大厂。

你可以接受自己是普通人的事实,但心中难凉的热血,终究会带你去想去的远方,成为理想的自己。 

你呢?你敢为了仅有一次的人生放手一搏吗?

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

posted @ 2019-08-01 18:17 51testing 阅读(101) | 评论 (0) | 编辑 收藏
 
十年,初心不变!51Testing受邀参加第十届CSTQB国际软件测试峰会

2019年7月20日,由中国软件测试认证委员会(CSTQB)、TMMi基金会中国分会(TMMiCN)、国际需求工程委员会中国分会(CREB)、南京市建邺区人民政府联合主办的第十届中国国际软件质量工程(iSQE)峰会在南京国际博览中心成功召开。

来自军工、航空、金融、卫星和通讯、银行保险、医疗器械、汽车行业、工业制造等多个领域的近600名国内外企业代表、行业协会及科研院所等相关行业代表齐聚一堂,共同分享行业前沿动态。博为峰51Testing作为CSTQB官方合作机构之一,特别受邀出席此次峰会。

本届峰会以“软件世界,质量护航,聚焦需求,赋能产业”为主题,上午开设主会场,邀请众多国内外权威专家做精彩主题分享;下午分别开设“软件测试”、“(测试)过程改进”和“需求工程”3种类型共计4个分会场,分设22个研讨班。针对不同细分专题,由国内外的权威专家学者、名企高管技术精英带来高端报告、专题演讲,分享探讨关于软件质量保障的热点话题及各关键领域内的应用实践和解决方案。

峰会期间,作为国际唯一权威软件测试资质认证机构“ISTQB”(国际软件测试认证委员会)的中国分会——“CSTQB”(中国软件测试认证委员会)特别组织召开了“2019年合作机构讲师交流会”,对2019年的认证及培训工作进行了阶段性的总结。在本年度报告中,博为峰51Testing依旧是中国地区内ISTQB认证培训规模最大,认证通过学员数量最多的官方授权机构。

随着信息技术的飞速发展,软件产品已应用到社会的各个领域,软件质量成为软件产品的灵魂,软件质量的保障变得尤为重要。软件测试人才在软件质量工程方面发挥着重要保障作用,测试人才的紧缺已成为制约我国软件产业发展的最大瓶颈。

自2004年成立以来,博为峰51Testing就一直致力于培养、输送专业的软件测试职业人才。2012年,博为峰51Testing正式成为ISTQB在中国地区的认证和培训合作伙伴,定期开设ISTQB基础级、高级测试经理的认证培训和考试。同时,作为首家将“在线模式”引入ISTQB培训,并面向全国范围每月开设培训和考试的培训认证机构,博为峰51Testing无论是培训规模,还是通过认证的学员数量,都已连续多年位列ISTQB中国地区官方授权机构之首。

发展至今,博为峰51Testing每年为7000多家国内外企业培养并输送上万名优秀毕业学员。今后,博为峰51Testing将继续秉承“践行良心教育,铺就职业坦途”的企业理念,不断顺应产业变迁和技术革新,培养更多、更优秀的应用型、创新型、技能型软件产业人才,推动企业发展和产业进步。

51Testing最新ISTQB考试时间安排:

CTFL(基础级):8月25日(上海、武汉、成都、北京)

CTFL(基础级):9月22日(北京、上海、成都、武汉、南京、重庆、广州、深圳、杭州)

CTAL-TA(高级测试分析师):8月25日(北京)

CTAL-TTA(高级技术测试分析师):8月25日(北京、上海)

CTAL-TM(高级测试经理):8月25日(北京)

CTAL-TM(高级测试经理):9月22日(上海)

私聊或微信18918179853,获取ISTQB考纲及免费咨询服务。

posted @ 2019-07-31 18:12 51testing 阅读(99) | 评论 (0) | 编辑 收藏
 
Appium使用技巧三步走,助你快速入门iOS移动端自动化测试

Appium介绍

Appium是一个开源、跨平台的测试框架,可以用来测试原生及混合的移动端应用。Appium支持iOS、Android及FirefoxOS平台。Appium使用WebDriver的json wire协议,来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。Appium对iOS系统的支持得益于Dan Cuellar’s对于iOS自动化的研究。Appium也集成了Selendroid,来支持老Android版本。

Appium进行自动化测试的两个好处

(1) Appium在不同平台中使用了标准的自动化APIs,所以在跨平台时,不需要重新编译或者修改自己的应用。这里,跨平台的意思是指可以在不同的系统上用相同的方式编写测试脚本,而不是指用于Android系统的测试脚本可以完全不用修改的应用于iOS系统上。事实上,Android和IOS应用几乎需要独立的进行编写。

(2)Appium支持Selenium WebDriver支持的所有语言,如java、Object-C、JavaScript、PHP、Python、Ruby、C#、Clojure,或者Perl语言,更可以使用Selenium WebDriver的Api。Appium支持任何一种测试框架。如果只使用Apple的UIAutomation,我们只能用javascript来编写测试用例,而且只能用Instruction来运行测试用例。同样,如果只使用Google的UIAutomation,我们就只能用java来编写测试用例。

Appium的系统需求

Android自动化测试可以在Windows、Mac、Linux上进行,需要安装Android SDK、Node等工具。而iOS的自动化由于需要Xcode的支持,只能在Mac上运行,需要安装Xcode、Node等工具。此外,由于Appium ios自动化的底层使用的是UI Automation,因此在使用Appium之前必须搭建iOS开发环境。

一、搭建Appium环境

目前Appium测试iOS设备,要求Mac操作系统的最低版本是mac OS 版本10.7,本机使用的开发环境是Xcode 9.4.1, Mac x 10.13.3。由于时间有限下文截图可能不太清晰,请谅解。

1)安装brew

在终端输入命令 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2)安装libimobiledevice

brew install libimobiledevice --HEAD

3)安装carthage

brew install carthage

4)安装node.js , https://nodejs.org/en/download/, 下载.pkg文件安装

5)安装cnpm https://npm.taobao.org/

npm install -g cnpm --registry=https://registry.npm.taobao.org

6)安装ios-deploy

sudo cnpm install -g ios –deploy

7)安装xcpretty

gem install xcpretty

安装的版本为xcpretty-0.3.0

8)安装Appium1.10.0

sudo cnpm install -g Appium@1.6.3

9)安装Appium-xcuitest-driver依赖

(1)安装WebDriverAgent

首先要搭建WebDriverAgent编译环境,首先需要安装如下的软件:

Homebrew

carthage

python

node.js

Xcode8.0+(IOS9.3,Xcode8.0+才能正常编译)

安装Homebrew

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

安装WebDriverAgent

使用git clone命令将WebDriverAgent项目克隆到本地

git clone https://github.com/facebook/WebDriverAgent

(2)安装Appium-xcuitest-driver依赖,进入WebDriverAgent安装目录,运行bootstrap

Cd/usr/local/lib/node_modules/Appium/node_modules/Appium-xcuitest-driver/WebDriverAgent

mkdir -p Resources/WebDriverAgent.bundle //执行脚本

sh ./Scripts/bootstrap.sh

如果出现报错,则关闭终端再打开,执行

9)下载WebDriverAgent-master

(1)Xcode打开WebDriverAgent.xcodeproj,修改配置:

选择菜单files->open,路径/usr/local/lib/node_modules/Appium/node_modules/Appium-xcuitest-driver/WebDriverAgent

(2)双击WebDriverAgentLib,设置后进行编译

按如下进行修改

Bundle ID改为com.ming.wda.WebDriverAgentLib

修改配置WebDriverAgentRunner后编译

10)真机的udid通过iTunes—摘要,点击序列号,出现UDID,右键拷贝即可。

安装Appium-python-client

二、运行与测试

(1) Xcode 菜单栏选择目标设备,Scheme 选择 WebDriverAgentRunner,最后运行Product -> Test。一切正常的话,手机上会出现一个无图标的 WebDriverAgent 应用,启动之后,马上又返回到桌面。这是正常的。

此时控制台界面可以看到设备的 IP。如果看不到的话,使用这种方法打开 view-debug area-activate console

出现上图,表示成功了

(2) 安装 Appium-doctor

确定所有依赖是否安装成功,可通过 Appium-doctor 验证,首先安装 Appium-doctor(sudo npm install -g Appium-doctor),然后在终端运行 Appium-doctor,如下图,都是打勾状态就证明环境正常。

(3) brew install – HEAD libimobiledevice

(4) 运行 Appium

终端执行 Appium – p 4723

三、启动 APP

第一步,Xcode 打开 WebDriverAgentRunner,scheme 选择它,菜单 Project->Test,

build 成功后在手机里装上 WebDriverAgent;第二步,手机连接 Mac 电脑;第三步,启动 Appium desk,start desired session;就可以自动测试 App 了。
欢迎加入 51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试工具安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长!期待你的加入: QQ                     群:                    755431660

posted @ 2019-07-31 17:27 51testing 阅读(107) | 评论 (0) | 编辑 收藏
 
使用Xpath定位元素实例:为Web元素创建最终XPath的20种最佳方法
     摘要: 使用于任何Web元素类型的XPATH定位的前20种方法(XPATH永远不会无效):Web应用程序由不同类型的Web元素组成,例如用于单击按钮Web元素,输入以键入文本的Web元素,下拉列表,单选按钮等。这些Web元素也称为标记或节点。在自动化Web应用程序时,首先要编写一个自动化脚本,该脚本将找到Web元素,对其执行操作,例如,单击按钮,在输入框中输入文本,选择复选框,选择单选按钮,向上或向下滚动...  阅读全文
posted @ 2019-07-30 17:27 51testing 阅读(82) | 评论 (0) | 编辑 收藏
 
如何走出自动化测试第一步?这11道“开胃小菜”才是最好的敲门砖

1、我想问一下关于自动化测试工具Selenium和QTP的区别。假如一个系统现在需要一款自动化测试工具,要求可以重复提交表单进行功能性测试,不用纯手工去做(因为工作量过大),现在有两个工具(Selenium和QTP),哪个比较适合?

这个要看情况:

1、你们公司是不是土豪,可以买qtp,可以买就用qtp。不能买,敢不敢用盗版?敢用,就用qtp。

2、页面元素的识别麻烦不?如果qtp搞不定,就只有努力学习,提升自己的编码能力,使用selenium去操控底层的页面元素来实现。如果页面元素不麻烦,想偷懒,请参考第一条。


2、目前很多项目自动化最多就是跑冒烟测试,所以更大的意义在哪里呢?求解

冒烟测试也是很有意义的,可以在最短的时间内验证程序是否跑得起来,而且因为测试用例少,实施起来门槛低,容易实现。比如我要做的一个windows客户端程序,冒烟测试就只有登录和3个基本功能。如果登录失败,则可以第一时间发现平台环境(包括数据库)是否正常。测试好立即恢复环境,以免影响后续测试工作。

3、毕业一年半一直做功能测试,想转自动化测试,不知道怎么开始第一步?老师有没有什么建议?

其实才毕业,任务安排还不能随心所欲,要听老大的。做好老大安排的任务是最基本的。功能测试技术含量听起来不高大上,但是可以深入了解自己公司产品的业务流程。业务流程对测试人员来说才是最重要的。

如果一定想转学自动化测试,可以先自己自学,等待老大给机会。自动化测试对一般公司来说还是比较奢侈的(哈哈),需要等待机会。希望你好运。

4、如果想要把自动化发挥更多更广阔的地方,应该是朝哪个方向呢?

冒烟测试的基础上,下一步就是要实现基本功能的自动化回归测试了。

基本功能测试用例集的确定非常重要,一定是那些最基本最核心最稳定的功能。基本功能用例集实现自动化测试后,这些测试用例会被反复执行(特别是在每日构建流程中),所以性价比是最高的。

下一步就是将更多的功能加入自动化测试。这些非基本功能可能不会每次都自动化回归。但是在一个开发周期中可能会被反复执行。所以也很重要。

5、想请教一下,如果测试场景中,涉及到输入验证码,能实现自动化吗?

基本上这个很难。如果自动化测试能够绕开验证码,那这个验证码得多笨。

这种情况下,一般都需要开发配合,提供去掉验证码的测试版本。

6、自动化测试后是否还要提交给单独的测试部进行系统测试?

这是必须的。千万不要以为自动化测试是万能的。即便微软、谷歌等公司也不是这样。

记住,自动化测试只能用于回归测试,而且要在脚本通过了长期验证,证明没有问题的情况下。

刚刚做自动化测试的同事,常常碰到一个问题,自动化测试脚本其实也是代码,开发写的代码靠自动化测试脚本来保证质量,那自动化测试脚本靠谁来保证质量呢?只能靠脚本编写人员的能力来保证,和长时间的实践来检验了。

7、看了好多jenkins自动化测试的配置,都是说在构建的时候执行测试用例,可是构建的时候,连服务都没有怎么可能测试成功啊?  

我认为的过程应该是:(1)提交代码;(2)构建编译;(3)自动部署(4)自动化测试,求大神解释一下,jenkins怎么做到我说的过程的?

如果是代码级的单元测试  集成测试,可以在自动部署前,构建的时候运行。不过我还是建议单元测试 集成测试和构建分开为两个步骤。

如果是系统测试,就只能在自动化部署后。你的理解是正确的。

8、我正在学习web开发,哪一个版本的火狐浏览器适合做web开发测试?

用chrome吧,chrome浏览器比较常用一些

9、我在学习QTP,我用的版本是UFT12,为了实现拖动浏览器的滚动条,网上查到的脚本代码是Browser().Page().Object.body.doScroll("scrollbarDown") ,但是我在编写这条代码时,Object的属性和方法里却没有body,是什么原因?

没有实际环境,我也不好回答你。不过这种找不到属性的问题在QTP使用的时候是常事。这也是我喜欢sikuli的原因之一。我建议一个偏方,你试试发送page-down键盘消息看看呢。

10、为何国内的前端对自动化测试好像不是很看重?

自动化测试的重点不是实现自动化测试或者把它加入到开发上线流程中,而是要对用例做收集管理,借助丰富的用例来保证代码质量。而用例的收集管理是否可以成功,取决于业务是否稳定可预测。现阶段国内的IT行业还处于高速增长期,业务善变不稳定。尤其是UI的变化更是频繁。此时收集管理用例成了西西弗斯的惩罚,消耗人力不说,还无法用来保证代码质量。对于与业务无关的底层框架、库来说,自动化测试一直是存在的。但正如他们所处的位置,相对公司范围,只会是小范围小团队对其它有依赖,难以扩大影响,在频繁变更的业务线也无法推广。所以,我想,等高速增长期结束了,业务趋于稳定后,它才有可能被普遍重视吧。

11、APP UI自动化测试框架都包含哪些内容?

所有的自动化测试框架都牵涉到3个阶段:setup, execution, teardown。setup阶段你需要想好你的case执行策略和之间的关联关系如何解决(支持并发执行吗?case需不需要做前后关联?关联的话并发执行如何解决?),数据准备,配置(包括环境如何分隔)。execution阶段需要考虑调用测试代码如何实现,肯定会包括你的执行机制和验证结果机制如何做能让用的人比较方便。teardown阶段就是最麻烦的地方了,牵涉到数据结果收集,展示,异常处理机制。前端的话你只要做到上面3点,再做到UI元素库的封装就行,一般的话都是用的POM。其实一般不要一个人去造这种轮子,累不说,做完了可能还不如开源项目,不如二次开发通用型测试框架。比如Robot Framework和Gauge这种。

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

posted @ 2019-07-29 17:45 51testing 阅读(89) | 评论 (0) | 编辑 收藏
 
甭做啦,软件测试已死……

曾几何时,听到团队评价测试人员的工作就是页面上“点点点”;刚起步的项目团队,产品人员、开发人员也会参与页面上的“点点点”工作;难道测试人员的工作就果真这么没有技术含量吗?再这么发展下去,软件测试由项目中的其他角色人员担任,“软件测试已死”的观点不就真的应验了吗?但问题的根本在于,软件测试真的没有、或者不需要技术含量吗?下面就自己一些经验和感悟,聊聊自己的一些体会。


一、背景

相信很多人大概早就听过“软件测试已死”的论调了。放眼当前国内的互联网公司,无论是成熟的大公司、还是处于创业时期的小公司,对于大多数从事软件测试的同学来说,都面临测试普通技术含量低,大多数以功能测试为主,日常工作就是在页面进行“点点点”… 所以,对于工作了几年,却一直在做功能测试的人来说,不仅在公司内部没有什么竞争优势,几乎处于分分钟可以被换掉的处境中;也看不到未来的方向,想跳槽,去其他公司面试也几乎没有优势可言。

对于纯做功能测试的人员来说,由于本身即是含量低,入门门槛低,所以,有条件的公司都会将其包给外包公司来做,让QA同学专注于质量的其他方面了。但就目前大多数的功能测试而言,还是QA同学的本职工作。虽然很多公司招聘QA的时候,都将其职位标为:测试开发工程师。但实际QA的工作,还是以功能测试为主,或者说,QA想要做些有技术含量的工作,还要自己“发愤图强”。

举个例子,A同学负责部门的一个新业务,每天业务测试忙到吐血,几乎没时间搞其他东西。B同学负责部门比较成熟的一个业务,项目压力不大,每天搞搞自动化、写写工具等等。到最后晋升、绩效评估的时候,大多数情况下B同学会比A同学有优势。究其原因,不外乎:

1、A同学工作的技术含量不如B同学。A同学的工作入门门槛低,几乎可以分分钟被其他同学接手;反观B同学的工作技术含量较高。

2、A同学产出不如B同学。A同学除了业务产生,再无过多其他,反观B同学,有业务、自动化、工具等产出

假设部门要裁员,大概率的情况下,相比B同学,A同学走人的概率要大得多。那么问题来了,如何让自己的工作更加倾向于B同学,而非A同学呢?更进一步说,如何更大范围内,发挥自己作为测试同学/QA同学的价值呢?

二、测试同学/QA同学的价值高低如何体现?

如同其他工种一样,评价一位测试同学/QA同学的价值高低,可以大致从以下范围考虑:

1、站在测试同学/QA同学的角度,尽可能多的在测试岗位体现自己的价值

1)从业务层面来说,测试同学/QA同学的价值就是:最大可能保证业务质量,避免业务的损失。

当然了,保证业务质量的手段就是——通过各种手段找bug。这里的bug不是狭义范围内的找功能bug,而是广义范围内的找业务bug,包括功能bug,性能bug,一致性bug,兼容性bug等等,也包括使用风险、业务风险等的风险类bug,流程中的bug,故障预防类bug,监控类bug,故障恢复类bug等等。广义范围内认为,一切影响/干扰用户使用的直接、间接问题都是系统的bug。

2)提升自己的核心竞争力,提高自己被取代的难易程度,让自己不容易被取代

为了提高自己被取代的难易程度,就要提高自己日常工作的入门门槛,增加自己工作的技术含量。这样,一方面,对自己的晋升/绩效有直接的收益,另一方面,哪怕日后对自己跳槽也能成为自己的优势。

可能你会问,哪些工作是有比较高的技术含量的呢?对于这个问题,其实你可以完全自己找答案,找你自己需要的答案。具体的来源可以是招聘信息、高职级的具体要求、身边的牛人等等。当然了,有技术含量的工作除了有入门门槛外,还需要考虑自身的条件、职业发展等,自己有所取舍地选择适合自己的。

3)确保自己的专属价值,即除了你之外,其他人一般干不了。

专属价值的入门门槛更高。例如,那些专攻某个领域的技术牛人,往往能拿到 special offer,薪资是普通技术人员的2倍、甚至更多,究其原因,就是因为这些技术牛人有了自己的专属价值。

2、站在团队/部门的角度,尽可能多的影响其他人

只有你有更多的影响力,你才能对别人产生更多的价值,你对别人来说才是有用的。因而,从考虑影响更多人这个角度,可以考虑其他人到底需要什么,如何影响到其他人。

比如,你可以通过分享、提供工具给其他人用、解决普遍存在的一类问题、让自己的工作成为行业标杆等等,让其他人收益。

3、站在公司的角度,尽可能多的“为公司创造价值”

为公司创造更多价值,是提升自身价值、为团队/部门创造更多价值的结果。

当然了,非高管等职位,谈到为公司创造价值,往往会显得空洞,但可以从实际业务出发,来考虑。比如,所负责的业务直接/间接服务了多少用户、带来了多少收入、点击量等

三、测试领域对从业人员的要求浅谈

近几年互联网行业对于测试人员的招聘要求来看,各个公司对技术的要求是越来越高了!甚至在具体的面试中,对于有经验的测试人员,很少问具体的测试问题了,更多地在考察技术问题。目前不会写代码的测试人员,几乎找不到太好的工作了。圈中的同行也大多在讨论技术,比如,自动化、XXX框架的编写、某某业务工具、各种辅助工具的开发等等。

从当前测试领域的趋势来看:测试领域对从业人员的要求越来越侧重技术能力了,而非测试思维。从测试人员的薪资也可以看出一二来,纯做功能测试人员的薪资,几乎不可能达到测试开发人员的薪资。因而,要想让自己在今后较长的一段时间,拥有竞争力,提升自己的技术能力,甚至达到一名资深开发人员的水平,是工作中的重中之重。

我曾经写过两篇文章:

1、《当公司今天找你谈话,明天让你走人时意味着什么》:http://www.51testing.com/html/00/n-4461400.html

2、《为什么互联网公司需要测试人员》:http://www.51testing.com/html/01/n-4461401.html

想来,测试领域的从业人员需要时刻保持警惕,避免陷入“温水煮青蛙”的舒适区中。努力提高自己的核心竞争力,让自己“分分钟”能找到更好的下家,这样的你,一方面即便公司裁员的时候,也不会轻易轮到你;另一方面,即便裁员轮到你,你也可以分分钟找到下一个落脚处。

四、写在最后

回到“软件测试已死”了吗的话题,个人认为,软件测试不会死,而且会一直存在。所谓专业的事情应该交给专业的人去做,软件测试领域中存在众多的技术方向,并且真正的软件测试应该是技术活,而非“体力活”。 如果你感觉一直、或经常在做体力活,那不妨,静下心来好好想想,是不是你目前努力的方向与测试领域的主流方向有所偏差呢?

测试领域中,每个从业人员职业生涯的长短并不是绝对的,也不是一成不变的,关键看从业人员能否跟得上主流方向的要求。假如今天的你,还在疲于奔命与“功能测试”,再无其他技术特长外,或许,可以看得见的将来,你的测试生涯也就结束了。但如果你始终围绕主流的方向开展测试工作,那么可以预见,测试生涯就是软件生涯!

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

posted @ 2019-07-26 17:43 51testing 阅读(96) | 评论 (0) | 编辑 收藏
 
测试工程师必备:掌握这5种设计方法快速编写测试用例~思路分析

一四年我在YX公司带测试团队,一个用例评审的会议上,一不小心超常发挥,结果卡在了一个用例设计方法上,印象非常深刻,当时的业务场景是支付方式的选择和优惠方案。

在后来的工作中,也曾几次遇到需要选择合理的设计方法来写用例,不过每次在网上都是搜索了半天,也找不到令人满意的答案。很多简单的问题被复杂化,然后给出的解题思路更是令人百思不得其解。

网络资源下,任何一个问题都不缺答案,更多的时候缺的是个让人一目了然的答案。


测试前准备

作为一个测试人员,软件测试的流程首先是要非常熟悉的,何时何地都能脱口而出,避免一切翻车的可能。需要注意的是流程没有唯一答案,具体由项目决定。所以给出的只是一个还算通用的参考流程。

我们要熟知的测试流程:


总结一下:在测试流程中,有6个部分,其中3个部分涉及到了用例,可见写好用例的重要性。

所以,结合这些年吃过的亏,我来给大家缕缕,如何快速的get到测试用例的设计方法。

5种常见的测试用例设计方法

一、等价类划分

1)概念

某个输入域的集合,在这个集合中每个输入条件都是等效的,如果其中一个的输入不能导致问题发生,那么集合中其它输入条件进行测试也不太可能发现错误。

关于等价类划分的两个重要概念:

有效等价类:有效等价类是程序规格说明有意义,合理的输入数据。

比如用正确的用户名和密码来登录系统就是有效等价类。

无效等价类:无效等价类是程序规格说明无意义,不合理的输入数据。

比如用不存在的用户名和密码来登录系统就是无效的等价类。

2)等价类法设计测试用例的步骤

为每个输入划分等价类,得到等价类表,为每个等价类规定一个唯一编号

设计一个测试用例,使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤,使得有效等价类均被测试用例所覆盖设计一个测试用例,使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖。

假设上面的文字你都没有看懂,那么做个题目就懂啦。

3)案例来了

程序规定:输入三个正整数作为三边的边长构成三角形。请用等价类方法设计测试用例分别判断输入3个整数时的三角形为一般三角形、等腰三角形、等边三角形时情况:

提示:

需求提取:

1、三条边需求:整数/3个数/非零数/正数

2、一般三角形的要求:二边之和大于第三边

3、等腰三角形:二二边相等且满足二边之和大于第三边

4、等边三角形:三条边相等

参考答案


答案解析:符合的需求条件的即是有效等价类,比如,等腰三角形,那么要求至少有两条边相等,所有有效等价类就包括a=b b=c a=c ,那么不符合条件的就是无效等价类包括a!=b b!=c a!=c

二、边界值分析

1)概念

边界值分析方法的理论基础是假定大多数的错误是发生在各种输入条件的边界上,如果在边界附近的取值不会导致程序出错,那么其它的取值导致程序错误的可能性也很小。

2)边界值分析法设计用例的步骤

分析输入参数的类型:从测试规格中分析得到输入参数类型

等价类划分(可选):对于输入等价类划分方法进行等价类的划分

确定边界:运用域测试分析方法确定域范围的边界(上点、离点与内点)

相关性分析(可选):如果存在多个输入域,则需要运用因果图、判定表方法这些输入域边界值的组合情况进行进一步分析

形成测试项:选择这些上点、离点与内点或者这些点的组合形成测试项

3)案例来了

假设存在以下的测试场景,某个网站的登录页面:


1、用户名:1—20个字符,包括1和20,其他不考虑

2、密码:6个数字,其他不考虑

现要求用边界值分析法测试用户名和密码这两个输入框。

参考答案

边界值分析方法如下:


答案解析:密码这个字段的范围是闭区间【1-20】,用边界值设计用例,那么去找这两个数的左邻右舍+自己,1则是0和1和2,20则是19,20,21。

三、判定表

1)概念

判定表是分析和表达多种输入条件下系统执行不同动作的工具,它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确 。

2)判定表法设计用例的步骤

列出所有的条件桩和动作桩

填入条件桩、条件项

填入动作桩、动作项

化简,合并相似规则

将每条规则转化为用例

3)案例来了

假设有以下逻辑:


运用判定表设计用例。

参考答案


答案解析:判定表的解题思路就是先列出所有条件,然后列出每个条件的取值,最后如上图,一列就是一条用例。

四、正交试验法

1)概念

正交试验设计(Orthogonal experimental design)是研究多因子多水平的又一种设计方法,它是根据正交性从全面试验中挑选出部分有代表性的点进行试验,这些有代表性的点具备了“均匀分散,齐整可比”的特点。

关于正交试验表的两个重要概念:

1、所有参与试验、影响试验结果的条件称为因子。

2、影响试验因子的取值或输入叫做因子的水平。

如何选择正交表:

1、考虑因子的个数

2、考虑水平的个数

3、考虑正交表的行数

4、取行数最少的一个

2)案例来了

有如下用户登录页面,三个登录条件:用户名、密码、验证码,考虑填写或不填写,用正交表设计测试用例。


参考答案

分析因子数,以及因子水平值:

3因子2状态


经过组合合并之后的对应用例


补充:


答案解析:正交试验法主要在于选取因子数和水平值,将两者结果列出再合并,工作中用的不多,但是合适的业务逻辑下可以选择。

五、流程分析法

1)概念

流程分析法是将软件系统的某个流程看成路径,用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合,使得流程的各个分支都能走到。

2)流程分析法设计用例步骤

1、画出业务流程图

2、设置功能路径优先级

3、确定测试路径

4、选取测试数据

5、构造测试用例

3)案例来了

案例:安装 QQ,安装系统之家版 QQ。

参考答案


对应的测试用例



答案解析:看起来非常复杂的流程图和用例,设计的核心其实就两个方向,一个是正常流程,即安装安装向导一直点击【下一步】直到完成。另一个方向则是每个判断条件选择【否】的场景,那么这样的话,就会产生很多条其他分支的用例。

结尾篇

测试用例设计方法不止上面提到的5种,但是工作中遇到的业务场景基本可以通过上述的方法来得到解决。等价类划分和边界分析方法较为简单,很多时候可以结合起来一起用。正交实验表和判定表一般用在需要将多个输入组合起来测试的情况。流程分析法顾名思义就是存在不同分支流程的时候选用。希望上述的方法能够帮助到大家。

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

posted @ 2019-07-25 17:31 51testing 阅读(161) | 评论 (0) | 编辑 收藏
 
面试时如何摆脱嘴笨带来的困扰?能力表达正在摧毁我们的前途

职场如战场,既是挑战自己的无穷潜力,又是与企业的对弈,更是千军万马过独木桥的较量,即使你是“天子骄子”,不过桥一样没有工作,没有饭吃,所以孰胜孰败,只取决于面试的刹那间。


古人云:“知彼知己,百战不殆;不知彼而知己,一胜一负;不知彼,不知己,每战必殆。”由此可见,无论是古代还是现代,想打一场胜仗,想谋一份称心如意的差事,想讨一个升职加薪的机会,清楚他人的实力和了解自己的实力,事先做好充足的准备是极其重要的。

如果你能在笔试中得心应手,出类拔萃,那么你已经离目标职位不远了,剩下的就要看你的面试能力了,试着了解面试对手、企业和面试官,根据不同的情况快速切换进攻策略,你必将赢得最终的胜利。

对于即将踏入面试征程的朋友们,我有一些经验要分享给你们:笔试中的技巧完全依靠于平时自己的积累,多学习多研究多做题,并不是一件难事,我也不用再多说。下面我主要为大家准备了一份面试技巧,通篇熟读后,你必将驰骋面试场,名企offer拿到手软!

首先我们从一个测试朋友的案例聊起,他的问题是这样的:

软件测试技术什么的我都会了,但是一到面试就表达不出来,或者在面试官面前出于紧张,我总喜欢把简单的东西复杂化,以至于说不到重点,屡屡面试失败。

一、其实遇到这个难题的朋友不在少数,究其原因,主要有两个:

1、表达的心理

性格内向

缺乏信心

紧张

2、表达的技术

避免讲流水账

要有重点

要有吸引力

如果“技术都会了”,但逻辑表达能力不行,闷头干,不善与人沟通,作为一名测试人员,测试出来的产品敢发布生产吗?反思下,你的技术真的过关了吗?所以,能力表达至关重要,不容忽视!

二、那解决这一问题的根本方法是什么?如何提高能力表达呢?

1、尽快备齐库存

提升自己各方面的测试技能

2、去除贪心

表达目标要明确,主要表现为四个方面:清楚、真实、有重点、有吸引

三、自我介绍表达训练

无论是谁,与面试官对弈的第一个问题就是自我介绍,这是面试官对你的第一印象,也是你们的第一步棋。

1、项目实践

2、完善简历

3、标记重点、难点问题

举例说明:


4、整理对应的工作成果

5、自我介绍表达训练


四、面试表达误区

1、是综合分析题

不是选择填空判断题

2、重点技能不要超过3个

不要所有技能都讲

3、要有一定团队协作内容的描述

不要只讲个人能力

4、多讲工作或技术问题

不要过多讲流程

五、自我训练任务分解


六、发音训练素材

除了上述的能力表达的技巧,还要注意回答问题时候的语气、语调和语速,可以多听听弟子规、心经,进行发音训练,面试中可以为自己加分。

七、最后我们来看看老师还有哪些建议给大家参考:

1.平时多注意深度和广度的培养,有可能多会一点,就比别人多点机会

2.平时多和同事沟通交流,比如这次的岗位推荐也是以前的同事帮忙的

3.认准的事就积极点,人事好几天没有通知录用结果,自己还特别在意,就主动沟通了下,等待的滋味不好受

4.诚实,不要把面试官当傻子,每天面试那么多人,我们想什么他们都知道的

5.每一次面试第一项都是自我介绍,好好准备准备,给面试官留下好的印象,个人认为这一点很重要。

6.每次面试后总结不足的地方,更新更新简历,面试前尽可能做好调查等等,最后还是看机遇,公司和我们都是在互相选择,最后我们等待的是一份offer,之前的失败与等待都是为之准备的过程。

面试并不可怕,只要保持实力,信心满满,把平时的专业技能,工作经验组织好语言表达出来。曾经的屡屡失败算什么?一次次的努力,会不断增加自己的筹码,有这种精卫填海般的坚持,有这种对软件测试行业的执着,成功可能会迟到,但早晚会来报到!

 

posted @ 2019-07-24 17:28 51testing 阅读(101) | 评论 (0) | 编辑 收藏
 
案例分享,Appium+Python实现APP启动页跳转到首页
     摘要: 下面以 MSN news 为例,实现启动APP后跳转到首页的功能,包含使用list进行元素定位、try except else 进行是否首次启动APP判断,logging 进行日志记录等功能。一、场景:1.启动APP后连续跳过welcom、interest 、what’s new页面到首页2.判断是否是首次启动,如果首次启动通过出现welcom页面,如果不是首次启动则直接进入inter...  阅读全文
posted @ 2019-07-23 17:27 51testing 阅读(241) | 评论 (0) | 编辑 收藏
 
如何做好自动化测试?揭秘测试项目团队的自动化实践过程……

稍具测试规模的项目团队皆想引进自动化测试,然而动手实现自动化测试的团队却不多,未能真正实施的原因多种多样,有扼杀在摇篮里的,有写了后弃之不用。那么是不是所有的业务都适合自动化测试呢?下面就介绍下自己在项目中怎样实施自动化测试。


我所在项目组将自动化测试应用于项目中已经有三年多,自动化脚本应用至今,按每月执行两次的频率,至今已经执行有七十二次有余。由于系统的GUI 足够稳定,这期间发生了两次由于句柄(hwnd)引发的脚本维护,由于规律性极强,也只花费了十人日来维护所有的脚本,维护脚本的资源和时间成本较低。下面就简单记录下自动化测试实现和运用时的一些要点。

自动化测试引进实施的背景主要有两个方面客户投诉和系统改版。客户投诉的主要原因是系统的数据计算不稳定,发布的新版本对低版本的系统产生的数据计算错误。系统改版需要兼容已发布的系统的数据,保证改版后的数据计算与已发布的系统的数据一致。

自动化测试的实施,最重要的是自动化工具的选择。由于系统的GUI 是图形界面,不能获取每个单元格的内容,TestComplete、QTP 等考虑过,写了一两个基本功能的脚本,验证后实施起来有困难,TestComplete 的通过图片的形式来进行结果的对比产生的误差比较大,运行的测试结果不稳定;放弃其它测试工具的原因就不一一描述了。最后使用的自动化测试工具是公司的开发人员基于系统框架开发的,提供了一些获取系统单元格和其他数据的函数,保证了自动化测试的顺利进行。

自动化测试工具确定之后,主要是测试脚本的培训和开发。由于自动化测试脚本语言和系统使用的二次开发语言相通,在二次开发人员的帮助下,测试人员很快掌握了测试脚本语言的使用方法。

接下来就是确定自动化测试的范围。如果系统能达到100%的自动化测试,当然这是最好的。项目的实际情况是有些功能的 UI 变化大和测试结果数据变化频繁,这些都不在自动化测试脚本开发的范围内。因此,我们最后确定的自动化测试的范围是版本迭代时验证系统的核心功能。

紧接着就开始自动化测试脚本的开发。开发第一个脚本是最费时间的,首先需要确定读取的配置文件格式及参数内容,参照数据的存放形式(Excel、Access、XMl 或其他文件格式),实现的功能脚本,测试结果的存放形式(html、txt、Excel 或其他文件格式)。开发脚本完成后,就是调试,在调试的过程中遇到问题时若三十分钟不能解决,则应向有经验丰富的同事请教,以免耽误脚本开发进度。第 1 个脚本开发完成后,接下来的开发工作可以在第 1 个脚本的基础上进行修改,并将常用的函数存在公共函数文件中,这样会大大提高开发效率。

自动化测试脚本的应用。每次版本迭代时,手工测试完成,需求变更等功能趋于稳定,这时运行自动化测试脚本的时机相对来说比较合理,这样保证了发布的系统的核心功能的准确性和稳定性。

最后要做的事就是自动化测试脚本的维护。系统GUI 变化,自动化测试范围的增加,这些皆应在系统定版后安排进行,待下一次版本迭代时,用于验证系统功能的正确性。

经过这几年的自动化脚本用于项目的实战经验,我的个人看法是自动化测试并不能完全替代手工测试。每个系统都会发生需求变更,若系统的核心功能不变,则可以将不变的核心功能用自动化测试来替代,其他功能手工完成,这才是有效利用资源和时间的最佳方式,才能获得良好的ROI。

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

posted @ 2019-07-19 17:39 51testing 阅读(75) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: 1 2 3 4 5 6 7 8 9 Last