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

评论排行榜

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

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

只需4步,LoadRunner轻松实现大负载测试!省时省力

敏捷的技术时代需要测试开发者在提高产品质量的同时,能够缩短发布时间和精简工作流程。研发人员们现在正在短时间内自己完成端到端的周期,并不断发布新的修复和功能。

测试开发人员节省时间的方式之一是尽可能多的重复使用现有的脚本。这节省了创建新脚本的时间,并且还实现了自动化。

通常情况下,你可以通过很多可用的工具来对一个应用软件进行测试并可以得到有关性能级别和临界点等方面的报告。像大多数工具一样,你要先退出你所运行的东西并对测试做彻底的准备。我们今天就来聊一聊一个常用工具LoadRunner如何在大负载下进行测试?

首先,什么是负载测试?

负载测试是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足性能指标的情况下,系统所能承受的最大负载量的测试,例如,访问一个页面的响应时间规定不超过1秒,负载测试就是测试在响应时间为1秒时,系统所能承受的最大并发访问用户的数量。

负载测试的目标是确定并保证系统在超出最大预期工作量的情况下仍能正常运行,还能评估系统的性能特征。

下面介绍一下关于负载测试的几个基本概念:

吞吐率:服务器并发处理能力的量化描述(单位reqs/s),单位时间内处理的请求数。

并发连接数:某一个时间点允许最大的请求数量,这个常用来衡量系统的并发处理请求的能力,应该区分与下面的并发用户数。

并发用户数:一个用户可能会产生多个并发连接,例如IE8目前支持6个并发连接。

用户请求平均时间:大量用户请求从发起到接收到处理结果的一个平均时间,在web页面默认不超过3秒是最佳的用户体念。

服务器平均处理请求时间:处理完成一个请求所用的平均时间,这个指标可用来衡量业务逻辑复杂度和机器的性能指标。

再来了解下,什么是LoadRunner?

LoadRunner是一款适用于多种软件体系架构的负载测试工具,从用户关注的响应时间、吞吐量,并发用户数和性能计数器等方面来衡量系统的性能表现,辅助用户进行系统性能优化。

原理:LoadRunner通过模拟成千上万用户实施并发负载及实时性能监测的方式来确认和查找问题,优化性能和加速应用系统的发布周期。

组成:LoadRunner主要包括三个前台功能组件,分别为VuGen(虚拟用户脚本生成器)、Controller(测试控制器)和Analysis(结果分析器)。系统会自动调用后台功能组件LG(负载生成器)和Proxy(用户代理)来完成性能测试工作。

如何使用LoadRunner实现大负载测试?

第一步:配置系统参数

大并发用户的情况下,会出现如下问题:

1)当采用netstat命令时,看到很多Socket处于“WAIT”状态

2)负载增大时连接失败

3)mmdrv的句柄数 随着虚拟用户的运行而增加

4)当建立连接时出现"No buffer space available"错误信息

解决方法

编辑以下注册表项:

1.为了避免出现“No Buffer Space Available”的错误,需要进行如下配置:
1)修改注册表:
* 设置“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Par
ameters\TcpTimedWaitDelay”为 30
* 设置“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Par
ameters\MaxUserPort”为 65534
* 在“HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session
Manager\Sub Systems\Windows”设置SharedSection 为 4096 
2)通过在每个脚本的开头添加如下函数来设置“SHUTDOWN”模式为"ABRUPT"
web_set_sockets_option(“SHUTDOWN_MODE”,”ABRUPT”)

第二步:配置LR

1)脚本运行时设置

消息处理时勾选"send message only when error occurs"

禁用snapshot on error

"define each step as a transaction"取消勾选

取消"simulate browser cache"勾选, 勾选“simulate new user on each iteration”和它的子选项

2)将脚本中web_url函数中的"Mode=HTML"默认方式改为"Mode=HTTP",这将减小LG机器上的压力(不解析HTML)

3)将在controller的diagnostics->configuration中,禁止web page breakdown

4)在Controller通过Tools > Options > Run-Time Settings限制同一时间在所有LG上初始化虚拟用户的数值,设置会被每台LG获得,这样做的目的是为了避免在脚本执行的初始阶段LG系统资源的过度利用.

5)限制controller在运行时存储的错误数.通过修改wlrun.ini中的[output]项来实现:
• FlagLimitOutputMessages=1
• MaxNumberOfOutputMessages=<errors count> (default is 10,000)

6)在Controller通过Tools>Options>Monitors修改monitor的采样率,这将减小测试运行时Controller的CPU利用率,如下图所示:

7)修改wlrun7.ini中的ExportMessagesToFile=1重定向输出信息到.txt文件而不是到MDB文件

此外:关闭Controller和LG上的防病毒,防间谍软件,关于运行在以上电脑上不要的Windows服务;在Controller不要运行虚拟用户;不要频繁打开Error/Output窗口,因为这将增加额外Controller上额外的数据库连接数这些都是对进行成功的大负载测试的有益的建议。

第三步:修改脚本

1)在负载测试时,保证Controller和Generator的网络通信非常重要,大量的信息(error message,output message)大并发负载测试有着很大的负面影响

如以下两例

把脚本中所与打印信息的脚本去掉.如下面的代码每次迭代都会调用一次,对大量并发用户的运行产生负面的影响.


Controller处理所有虚拟用户的信息,这样会大大降低Controller的性能. 如下是类似的代码:

这些语句都仅仅应该出现在脚本调试时而不应该出现在负载测试时的脚本中,在正式的负载测试前,注释掉这些语句。

2)去掉脚本中所有的sleep()的调用,用lr_think_time()来代替.lr_think_time给LR让出控制,即LR能够在Vuser休眠的时候去做其他有用的事情.不要去掉lr_think_time:使用该函数能更准确的模拟负载,对LG产生相对小的压力

3)web_reg_save_param和web_reg_find()函数:
在 web_reg_save_param() 中添加“Notfound=empty” 参数.
在 web_reg_find() 添加 "Savecount=some_parameter_name". 如果你想知道它是否成功可以使用atoi(lr_eval_string("{some_paramater_name }"))来衡量.

第四步:设置组策略

大负载测试时会有以下情况发生:

●产生很多错误,数据量大于1GB

●假如每秒产生1000条左右错误的话,Controller的行为将很难预测

●压力测试产生很多运行数据

这些问题可以通过设置一个合理的组策略避免,以下举一个例子说明

场景为1000个虚拟用户,用一个Group运行

这时把这个Group分为两个Group:

G1-〉100 Vusers

G2-〉900 Vusers

这两个组可以跟原始的组产生一样的负载,对于G2在组命令行中添加如下参数:
-disable_data -disable_messages
_disable_data : 让这个组不发送任何信息,不发送任何online信息,不写任何offline信息.
_disable_message: 让这个组不给Controller发送任何信息(错误,日志)
注意:使用上面的命令行选项会使该LG不给congtroller发送online和offline信息.这样这个组上的虚拟用户的分析数据就收集不到了.

总结:

通过一段时间的学习发现,结合LR自带的使用手册,以及在网上找的N多资料,多看学习视频,然后多动手操作。慢慢的LR的一些操作步骤就会做的,所谓熟能生巧就是这回事情,至于分析结果这块所涉及的东西很多,这个要靠长期的经验的积累和学习。坚持做做多学多问,就很收获良多。加油!

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

posted @ 2018-10-31 17:33 51testing 阅读(86) | 评论 (0) | 编辑 收藏
 
最新调查:10类排名最高的软件安全性测试工具汇总

软件安全性是一个广泛而复杂的主题,每一个新的软件总可能有完全不符合所有已知模式的新型安全性缺陷出现。要避免因安全性缺陷问题受各种可能类型的攻击是不切实际的。在软件安全测试时,运用一组好的原则来避免不安全的软件上市、避免不安全软件受攻击,就显得十分重要。

一、软件安全性测试基本概念

软件安全性测试包括程序、网络、数据库安全性测试。根据系统安全指标不同测试策略也不同。

1.用户程序安全的测试要考虑问题包括:

① 明确区分系统中不同用户权限;

② 系统中会不会出现用户冲突;

③ 系统会不会因用户的权限的改变造成混乱;

④ 用户登陆密码是否是可见、可复制;

⑤ 是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统);

⑥ 用户推出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统。

2.系统网络安全的测试要考虑问题包括:

① 测试采取的防护措施是否正确装配好,有关系统的补丁是否打上;

② 模拟非授权攻击,看防护系统是否坚固;

③ 采用成熟的网络漏洞检查工具检查系统相关漏洞;

④ 采用各种木马检查工具检查系统木马情况;

⑤ 采用各种防外挂工具检查系统各组程序的客外挂漏洞。

3.数据库安全考虑问题:

① 系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求);

② 系统数据的完整性;

③ 系统数据可管理性;

④ 系统数据的独立性;

⑤ 系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)。

多年以来,有很多人列出了最佳渗透测试和网络安全评估工具,但是我想用一种不同的方法,按分类列举最佳测试工具。废话不多说,下面根据调查分出10类,基本反映了安全测试工具的使用现状:

最受欢迎的软件测试工具有哪些?

1. 从总体看,(静态的)代码分析工具和(动态的)渗透测试工具应用还是比较普遍,超过60%,而且渗透测试工具(73.68%)略显优势,高出10%。模糊测试工具,可能大家感觉陌生,低至16%,但它在安全性、可靠性测试中还是能发挥作用的。从理论上看,代码分析工具应该能达到95%以上,因为它易用,且安全性已经是许多公司的红线,得到足够重视。希望以后各个公司能够加强代码分析工具和模糊测试工具的应用。

2. Java代码安全性分析工具前三名是:IBM AppScan Source Edition(42.11%)、Fotify  Static Code Analyzer(36.84%)、Findbugs(26.32%)。

3.C/C++代码安全性分析工具前三名是:C++Test(38.89%)、IBM AppScan Source Edition(38.89%)、Fotify  Static Code Analyzer(27.78%)、Visual Studio(27.78%)。可能LDRA Testbed比较贵,关键的嵌入式软件采用比较多,所以没有进前三。

4. JavaScript代码安全性分析工具应用最多的是Google's Closure Compiler,其次是JSHint,也有的公司用Coverity来进行JS的代码分析。

5. Python代码安全性分析工具应用最多的是Pychecker,其次是PyCharm,而Pylint使用比较少,也有几个公司用Coverity来进行Python的代码分析。

6. Web应用安全性测试的商用工具中,IBM AppScan异军突起,高达70%的市场,其它商用工具无法与它抗衡,第2名SoapUI和它差距在50%以上,HP webInspect 不到10%。

7. Web应用安全性测试的开源工具中,Firebug明显领先,将近50%,比第2名OWASP ZAP高12%,第三名是Firefox Web Developer Tools,超过了20%。

8.Android App的安全性测试工具中,Android Tamer领先,将近30%,比第2、3名AndroBugs、Mobisec、Santoku高15%左右。

9. 网络状态监控与分析工具中,Wireshark遥遥领先,超过70%。其次就是Tcpdump、Burp Suite,占30%左右。网络状态监控与分析工具挺多的,但从这次调查看,越来越集中到几个工具中,特别是Wireshark功能强,覆盖的协议比较多,深受欢迎。

10.SQL注入测试工具排在前三位的:SQLInjector、SQL Power Injector、OWASP SQLiX,三者比较接近,差距在6%左右。其它两项工具Pangolin、SQLSqueal也占了10%。

总结:

这些工具将安全测试员从手动审核的工作中解放出来。它们也使审核的过程变得更为快速有效。执行有力的安全测试评估并不意味着简单地从列表中选择一个工具。相反,它意味着评估组织结果,以及评估信息、要求和所涉及的利益相关者。这个过程将有助于构建一个理想的策略,包括使用工具来有效和高效地识别和解决安全漏洞。

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

posted @ 2018-10-30 17:47 51testing 阅读(154) | 评论 (0) | 编辑 收藏
 
Linux 用户必知:一分钟掌握14个常用Linux命令行快捷键

前几天有个朋友给我发消息:"问你个问题,Linux 命令行有没有快捷键一下从行末会到行头?经常敲了很多命令发现忘加 sudo 了,然后把命令删了重新敲一遍"。

正好借此机会给不知道的朋友总结一下:

首先说说历史记录个数的 "HISTFILESIZE" 和 "HISTSIZE"的区别

默认情况下 HISTFILESIZE 和 HISTSIZE的值都是 500,表示可以记录 500 条命令记录。

· HISTFILESIZE 表示记录在文件中的命令条数

· HISTSIZE 表示记录在内存中的命令条数

当我们在 shell 命令行执行命令的时候,最近的 HISTSIZE 条命令被保存在内存当中可以使用上下光标或者 ctrl+p,ctrl+n 上下查找命令。

当退出 shell 时 HISTFILESIZE 条命令被保存到历史命令文件中,下次登录 shell 时会从历史命令文件中读取命令道内存历史命令道中。

当网络中断等异常时,你会发现之前的历史命令,下次登录时用上下光标找不到上次的历史命令,所以要正常退出或者发送探测包保持 shell 在线。

如果想增加历史命令保存的数量,可以在 ~/.bash_profile 中手动修改 HISTFILESIZE 和 HISTSIZE 这两个变量的值。

必须知道的Linux命令行

我想提一下一些快捷键可能依赖于你使用的 Shell。 Bash 是最受欢迎的 shell,所以列出的快捷键集中在 Bash。 如果你愿意,你也可以称其为 Bash 快捷键列表。

注意我在键盘快捷键中使用了大写字母,但这并不意味着你在使用快捷键时必须按下 shift 键。

常用

1. Tab

这是你不能没有的 Linux 快捷键。它将节省你 Linux 命令行中的大量时间。

只需要输入一个命令,文件名,目录名甚至是命令选项的开头,并敲击 tab 键。它将自动完成你输入的内容,或为你显示全部可能的结果。

如果你只记一个快捷键,这将是必选的一个。

2. Ctrl + C

这些是为了在终端上中断命令或进程该按的键。它将立刻终止运行的程序。

如果你想要停止使用一个正在后台运行的程序,只需按下这对组合键。

3. Ctrl + Z

该快捷键将正在运行的程序送到后台。 通常,你可以在使用 & 选项运行程序前之完成该操作, 但是如果你忘记使用选项运行程序,就使用这对组合键。

4. Ctrl + D

这对键盘快捷键将使你退出当前终端。如果你使用 SSH 连接,它将会关闭。 如果你直接使用一个终端,该应用将会立刻关闭。

把它当成"退出"命令。

5. Ctrl + L

你怎么清空你的终端屏幕?我猜是用 clear 命令。

你可以使用 Ctrl+L 清空终端,代替输入 C-L-E-A-R。得心应手,不是吗?

6. Ctrl + A

该快捷键将移动光标到所在行首。

假设你在终端输入了一个很长的命令或路径,并且你想要回到它的开头, 使用方向键移动光标将花费大量时间。注意你无法使用鼠标移动光标到行首。

这是 Ctrl+A 节省时间的地方。

7. Ctrl + E

这对快捷键与 Ctrl+A 相反。 Ctrl+A 送光标到行首,反之 Ctrl+E 移动光标到行尾。

8. Ctrl + U

输入了错误的命令? 代替用退格键来丢弃当前命令,使用 Linux 终端中的 Ctrl+U 快捷键。 该快捷键会擦除从当前光标位置到行首的全部内容。

9. Ctrl + K

这对和 Ctrl+U 快捷键有点像。 唯一的不同在于不是行首,它擦除的是从当前光标位置到行尾的全部内容。

10. Ctrl + W

你刚才了解了擦除到行首和行尾的文本。 但如果你只需要删除一个单词呢?使用 Ctrl+W 快捷键。

使用 Ctrl+W 快捷键,你可以擦除光标位置前的单词。 如果光标在一个单词本身上,它将擦除从光标位置到词首的全部字母。

最好的方法是用它移动光标到要删除单词后的一个空格上, 然后使用 Ctrl+W 键盘快捷键。

11. Ctrl + Y

这将粘贴使用 Ctrl+W,Ctrl+U 和 Ctrl+K 快捷键擦除的文本。 如果你删除了错误的文本或需要在某处使用已擦除的文本,这将派上用场。

12. Ctrl + P

你可以使用该快捷键来查看上一个命令。 你可以反复按该键来返回到历史命令。 在很多终端里,使用 PgUp 键来实现相同的功能。

13. Ctrl + N

你可以结合 Ctrl+P 使用该快捷键。Ctrl+N 显示下一个命令。 如果使用 Ctrl+P 查看上一条命令,你可以使用 Ctrl+N 来回导航。 许多终端都把此快捷键映射到 PgDn 键。

14. Ctrl + R

你可以使用该快捷键来搜索历史命令。

Ctrl+左右键:在单词之间跳转

Alt – d :由光标位置开始,往右删除单词。往行尾删

说明

Ctrl – k: 先按住 Ctrl 键,然后再按 k 键;

Alt – k: 先按住 Alt 键,然后再按 k 键;

M – k:先单击 Esc 键,然后再按 k 键。

移动光标

Ctrl – a :移到行首

Ctrl – e :移到行尾

Ctrl – b :往回(左)移动一个字符

Ctrl – f :往后(右)移动一个字符

Alt – b :往回(左)移动一个单词

Alt – f :往后(右)移动一个单词

Ctrl – xx :在命令行尾和光标之间移动

M-b :往回(左)移动一个单词

M-f :往后(右)移动一个单词

编辑命令

Ctrl – h :删除光标左方位置的字符

Ctrl – d :删除光标右方位置的字符(注意:当前命令行没有任何字符时,会销系统或结束终端)

Ctrl – w :由光标位置开始,往左删除单词。往行首删

Alt – d :由光标位置开始,往右删除单词。往行尾删

M – d :由光标位置开始,删除单词,直到该单词结束。

Ctrl – k :由光标所在位置开始,删除右方所有的字符,直到该行结束。

Ctrl – u :由光标所在位置开始,删除左方所有的字符,直到该行开始。

Ctrl – y :粘贴之前删除的内容到光标后。

ctrl – t :交换光标处和之前两个字符的位置。

Alt + . :使用上一条命令的最后一个参数。

Ctrl – _ :回复之前的状态。撤销操作。

Ctrl -a + Ctrl -k 或 Ctrl -e + Ctrl -u 或 Ctrl -k + Ctrl -u 组合可删除整行。

Bang(!)命令

!! :执行上一条命令。

^foo^bar :把上一条命令里的foo替换为bar,并执行。

!wget :执行最近的以wget开头的命令。

!wget:p :仅打印最近的以wget开头的命令,不执行。

!$ :上一条命令的最后一个参数, 与 Alt - . 和 $_ 相同。

!* :上一条命令的所有参数

!*:p :打印上一条命令是所有参数,也即 !*的内容。

^abc :删除上一条命令中的abc。

^foo^bar :将上一条命令中的 foo 替换为 bar

^foo^bar^ :将上一条命令中的 foo 替换为 bar

!-n :执行前n条命令,执行上一条命令: !-1, 执行前5条命令的格式是: !-5

查找历史命令

Ctrl – p :显示当前命令的上一条历史命令

Ctrl – n :显示当前命令的下一条历史命令

Ctrl – r :搜索历史命令,随着输入会显示历史命令中的一条匹配命令,Enter键执行匹配命令;ESC键在命令行显示而不执行匹配命令。

Ctrl – g :从历史搜索模式(Ctrl – r)退出。

控制命令

Ctrl – l :清除屏幕,然后,在最上面重新显示目前光标所在的这一行的内容。

Ctrl – o :执行当前命令,并选择上一条命令。

Ctrl – s :阻止屏幕输出

Ctrl – q :允许屏幕输出

Ctrl – c :终止命令

Ctrl – z :挂起命令

重复执行操作动作

M – 操作次数 操作动作 : 指定操作次数,重复执行指定的操作。

总结:

在 Linux 下使用命令操作的时候,光标的移动令人头痛。命令输入完了,执行之后发现缺少权限,然后不得不移动光标到行首,而命令又极长……以上是一些每个 Linux 用户必须使用的键盘快捷键。使用命令行时,这些 Linux 快捷键将提升你的工作效率和效率。

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

posted @ 2018-10-29 17:18 51testing 阅读(89) | 评论 (0) | 编辑 收藏
 
双十一购物节将至,电商首页、支付功能测试刻不容缓!

万众期待的双十一购物节即将到来,各位剁手党又开始摩拳擦掌,准备在那个瞬间清空自己的购物车,然后花上两个星期等待“宝贝们”的到来。但此时,对于各大电商网站而言,除了赚钱的快感,还应多做测试,避免突发故障影响用户体验度和造成不必要的损失。

每一个网站在上线之前都会进行内测,但是测试什么内容,如何进行测试呢?比如你是资讯工具类网站,你测试的重点要放在阅读体验这个点上;如果你是互动交流类网站,你测试的重点应该放在交互性这个点上;如果你是电子商务类网站,你测试的重点则应该是购物流程这个点上,因此,不同的网站要做不同的分析。

下面我们就来聊一聊电商首页测试、支付功能测试的要点。

如何对电商首页和购物流程进行测试?

首页测试分为两个比较重要的模块,UI测试和搜索功能测试。

UI主要测试:

页面排版布局是否整洁美观,每个商品的信息,文字和图片是否显示正确,图片有没变形等,点击链接能否跳转到正确的页面,有没有空链接,首页的输入框,下拉框,多选框,按钮功能是否正常,js动画效果,鼠标悬停时,轮播图是否正常,页面的加载速度是否正常,是否兼容不同浏览器,是否支持移动端访问。

搜索功能测试:

分为商品搜索和店铺搜索:
搜索框是否对字符类型和长度限制,是否有提示信息,
输入完整商品信息,是否搜索出匹配信息的商品,
点击为空的搜索框是否有搜索历史提示
搜索框是否有提示信息,提示信息能否选中,点击提示信息能否显示匹配信息的商品,
输入关键字搜索能否正确搜索匹配输入的商品
当不输入的时候能否搜索到商品,
没有搜索到商品是是否有提示,有没有返回首页的链接。
店铺搜索和商品搜索类似

购物车:
界面测试:
·打开页面后,页面的布局是否合理,显示是否完整;

功能测试:
·所有页面链接功能正常,可以点击到正确页面;
·从商品信息页面添加的商品能显示在购物车中;
·购物车页面打开的同时,在其他页面添加了商品,购物车页面刷新后,新的商品能显示;
·若未登录,点击购物车,则提示用户输入用户名和密码,或者提示其他的非注册用户购物方式;
·商品未勾选的状态下,结算按钮是灰色无法点击的;
·勾选商品后,已选商品的总价会显示,结算按钮变高亮可点击工作;
·勾选商品,点击结算按钮后,进入确认订单信息页面;
·购物车页面中,可以对添加的商品信息做信息的修改,并自动保存成功;
·购物车有商品降价或者库存告急的,是否有对应提示,缺货商品能否添加购物车;
·购物车能添加的商品种类是有数量上限的;
·不要的商品,可以删除;
(其他特有的功能不做赘述,只讨论常见通用功能)
性能测试:
·打开购物车页面要多久;
可用性测试:
·快捷键功能知否支持
兼容测试:
·不同浏览器上的测试功能是否正常;
·app上测试

填写订单信息:
收货信息:
新增、修改、删除、收货信功能是否正常。
最多可以添加多少个收货信息。
新增收货信息中有限制,输入框对字符类型和长度是否有限制。必填项为空能否保存收货信息
保存成功之后能否在列表正确显示。后台能否查看到保存的信息。
没有收货信息能否提交订单。
收货信息能否多选。
支付方式:
每种支付方式是否功能正常。比如说选择货到付款,还需不需要支付。
第三方支付是否支持。
能否选择同时选择多种支付方式。
商品信息:
商品的图片,数据,金额等信息是否正确
发票信息:
添加发票信息时对字符类型和长度是否限制,添加成功后显示是否正常,后台能否查询到正确的发票信息。
优惠券、红包、积分:
优惠券、红包、积分显示是否正确,是否与后台匹配。
优惠券、红包、积分能否正常使用,能否叠加使用。
优惠券、红包、积分使用后支付金额是否相应减少。后台优惠券、红包、积分是否也相应减少
提交订单:
提交订单和支付成功后,后台是否能查询到订单信息,
异常场景:
金额不够的情况下,能否购买,是否有提示
支付过程中断网,断电,对支付是否有影响
在弱网情况下,能否正常支付

如何对支付功能进行测试?

支付功能测试考虑点

支付功能在很多软件应用中常常涉及到。支付功能的测试关注点是有没有出现资损和事务的一致性。

在支付金额上

1、金额的最小值 :如0.01

2、无实际支付意义的金额:如0元订单

3、支付金额错误:格式错误 、数字错误(支付金额为负数)

4、超大金额 :设置的最高金额上限。(如微信红包单个最大值为200等)

5、余额小于实际需要支付的金额

6、银行卡或其他设置当日消费金额或者是单笔消费金额超限

支付接口上

关于支付会设计到很多第三方接口的相关的事件。比如:支付宝 、微信、网银系统 、手机银行等。

支付的操作问题上

1、指纹支付

2、免密支付

3、账号+密码支付

4、动态获取支付验证码支付

5、银行卡号+密码绑定支付

6、信用卡可能会设计到支付码等

如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的。

产品的容错性上(异常处理)

1、如何处理退款

2、支付时出现断网

3、支付失败之后 如何补单和退单

4、支付金额不足的情况下 ,充值后 是否可以继续支付

5、持续点击 是否会出现多次扣款

6、如果发生多次扣款,如何退款到支付账号

产品后台处理上

成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。

总结:

测试对电子商务来说至关重要,因为电子商务网站不仅业务关键同时对其用户可视度很高,任何的故障、错误都会立即造成昂贵的收入的损失,甚至在更长时期里,如果未受影响的用户寻找替代网站,就是更昂贵的代价损失。

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

posted @ 2018-10-25 17:42 51testing 阅读(102) | 评论 (0) | 编辑 收藏
 
老菜鸟带你皮一下:你从来没有想过的Monkey测试!

Monkey,也就是猴子,hin皮,所以Monkey测试,顾名思义也就像猴子一样在软件上乱敲按键来测试。猴子什么都不懂,只知道乱按。Monkey原理也是类似,通过向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等),实现对应用程序的测试。

我相信,大多数测试员都知道Monkey测试,甚至都用过,但是你可能不敢说自己对Monkey测试有多熟悉。看着好像很简单,但是我们如何快速的去熟悉Monkey测试呢?

一、Monkey测试的基本方法

今天,想简单地分享点Android的Monkey测试。亲测了一波,Monkey测试作为辅助测试,还是可以用用的,简单不费力。

Monkey是Android中的一个命令行工具,可以运行在模拟器里或实际设备中。只要安装了adb,就可以进行Monkey测试了。

在做Monkey测试前,需要先安装adb(adb的环境配置,网上有很多教程,此处不做详细描述)。然后手机连接上电脑,打开菜单,输入“cmd”打开,输入命令行“adb devices”来确定设备是否连接成功。若连接成功,会显示设备序列号,参考下图。

还有,测试人员需要知道测试app的包名。可以通过使用“uiautomatorviewer.bat”工具(后期文章中描述)来获取包名,也可以直接询问提供app的开发人员,或者直接使用adb命令获取包名。

简单地介绍一种:通过adb命令获取包名。首先要先打开手机中需要获取包名的app。然后分别输入命令即可。如下图,该app的包名是“com.screeclibinvoke”。

1、adb shell

2、dumpsys activity | grepmFocusedActivity

然后输入一句简单的Monkey命令,即可开始测试。

adb shell monkey -p com.screeclibinvoke 1000 (指定包名是“com.screeclibinvoke”的应用,随机执行1000个模拟事件)。

二、Monkey的常用命令

下面列出了Monkey可以使用的参数。

基本参数

--help打印帮助文档

-v命令行中的每一个-v将增加反馈信息的级别。Level 0(也是默认值)除启动提示、测试完成和最终结果之外,其他的信息很少。Level 1提供较为详细的测试信息,如逐个发送到Activity的事件。Level 2提供更加详细的设置信息,如测试中被选中的或未被选中的Activity,例子adb shell -v -v 500

-s伪随机生成器的种子。如果seed值一样,那么产生的monkey事件,序列也是一样的

--throttle <毫秒>在事件之间加入固定时间延迟,单位毫秒。如果不加,monkey会尽可能快地产生事件

--pct-touch调整触摸事件的百分比(触摸就是一个点击事件)

--pct-motion调整动作事件的百分比,(动作事件指一个down事件,一系列随机事件,然后一个up事件)

--pct-trackball调整轨迹事件的百分比,(轨迹事件由一个或多个移动组成,有时伴随点击事件)

--pct-nav调整基本导航事件的百分比,(导航事件就是方向键,上下左右)

--pct-majornav调整主要导航事件的百分比(这些导航事件通常引发图形界面中的动作,如5-way键盘的中间按键,回退按键,菜单按键)

--pct-syskeys调整系统按键事件的百分比(这些事件由系统保留,如Home、Back、Start、Call、End Call及音量控制键)

--pct-appswitch调整启动activity的百分比。在随机间隔里,Monkey将执行一个startActivity()调用,作为最大程度覆盖保重全部Activity的一种方法。

--pct-anyevent调整其他类型事件的百分比。包含了所有其他类型的事件,如按键、其他不常使用的设备按键、等。

操作约束

-p如果使用该参数指定了一个或几个包,monkey将只允许启动这些包中的activity。如果你的程序,需要访问别的activity(如联系人界面),那必须将联系人的包也指定一下,否则无法访问。如果没有指定包名,monkey将允许启动安装在手机上的所有包。如果要指定多个包,需要多个-p选项,每个-p指定一个包。

-c如果使用此参数指定了一个或多个类别,Monkey将只允许系统启动被这些类别中的某个类别列出的Activity,如果不指定任何类别,Monkey将选择下列类别中列出的Activity:

Intent.CATEGORY_LAUNCHER或Intent.CATEGORY_MONKEY。要指定多个类别,需要多个-c选项。

调试选项

--dbg-no-event设置此选项,Monkey将执行初始启动,进入到一个测试Activity,然后不再产生事件。为了得到最佳结果,把它与-v,一个或几个包约束,以及一个保持Monkey运行30秒或更长事件的非零值联合起来,从而提供一个环境,可以监视应用程序所调用的包之间的转换。

--hprof设置此选项,将在Monkey事件序列之前和之后立即生成profiling报告。这将会在data/misc中生成大文件(5M),所以小心使用。

--ignore-crashes通常,当被测app崩溃或者发生任何失控异常时,Monkey将停止运行。如果设置此选项,Monkey会继续向系统发送事件,直到计数完毕。

--ignore-timeouts通常,当被测程序出现未响应时,Monkey会停止运行。如果设置此选项,Monkey会继续运行,直到结束。

--ignore-security-excuptions通常,当被测程序发生可允许错误(如启动一个需要授权的Activity)时,Monkey将停止运行。如果设置此选项,Monkey将继续运行,直到结束。

--kill-process-after-error通常,当Monkey由于一个错误而停止运行时,出错的应用程序将继续运行。如果设置此选项,将会通知系统停止发送错误的进程。注意:程序正常结束,该程序并没有被停止。设备只是在结束事件后,简单保持在最后的状态。

--monitor-native-chrashes监视并报告Android系统中本地代码的崩溃事件。如果设置了–kill-process-after-error,系统将停止运行。

--wait-dbg停止执行中的Monkey,直到有调试器和它相连。

三、Monkey的实例

我使用如下命令做一波Monkey测试,最终在电脑D盘生成a.log日志文件。

adb shell monkey -p com.screeclibinvoke --throttle300 --ignore-crashes --ignore-timeouts --ignore-security-exceptions--ignore-native-crashes --monitor-native-crashes -v -v -v 10000>D:\a.log

在Monkey测试过程中可能会出现程序崩溃(CRASH)和程序无响应的情况(ANR)。CRASH即崩溃信息,程序在运行中非正常退出。设置忽略crashes等情况,当运行如上命令之后,在生成的日志中搜索关键字“CRASH”或“NAR”,可直接根据log日志定位bug并修复,也可根据seed值来完成bug的复现。

​

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

posted @ 2018-10-24 17:39 51testing 阅读(93) | 评论 (0) | 编辑 收藏
 
软件测试工程师—中国“隐形富裕人口”的职业发展路线图!

前段时间有个叫“隐形贫困人口”的词特别火,指的就是那些看上去生活特别滋润,实际上却很贫困的人。

而与之相反的恐怕就是“隐形富裕人口”了。那么哪种行业或者职业属于此类呢?收入水平高于市场上大部分职业,却并不爱炫富的软件测试员无疑是“隐形富裕人口”的典型代表。

但与此同时,也有很多人认为软件测试员最容易在中年之前就开始焦虑。他们认为“测试员是吃青春饭的”,“30岁还没做公司中层领导说明快被企业淘汰了”,“过了30岁年薪还没破20W+就该考虑转行了”……诸如此类的声音不绝于耳。

那么,对于中国的“隐形富裕人口”软件测试员来说,如何规划自己的职业生涯,才会一直“富裕”下去,而不是吃了几口“青春饭”就被淘汰呢?

首先谈谈我在软件测试行业的亲身经历

我的一位同事曾经很认真地问过我一个问题,他说他现在从事软件测试工作已经4年了,但是他不知道现在的工作和自己在工作3年时有什么不同,他想旁观者清,也许我能回答他的问题。此外他还想知道他做软件测试工作到第5年或第6年会怎么样。后来他在工作到第5年的时候转岗了。虽然他已经转岗了,但是最近联系时,他依然问我这个问题,似乎这个问题困惑他很深、很久了。

这件事情对我的触动很大,我相信这个问题是带有一定普遍性的,我也开始系统思考这个问题。

软件测试是一个缺乏发展空间、做到一定阶段后只能通过“转岗”来寻找发展机会的职业吗?

肯定不是。

Martin Pol,欧洲业界公认的“Test Guru”(大佬,精神领袖),1998年欧洲第一届杰出测试贡献奖获得者,并获得英国骑士勋章。Martin在测试领域已经几十年,最后在测试工作上名利双收。而且,据说他的大女儿和小女儿都是做测试的,这是名副其实的“测试世家”。

但是Martin的例子并不能解决“软件测试本身有哪些发展”这个问题。作为“精神领袖”,Martin只能让我们看到最美好的结果,让我们知道这条路是能走通的。有人已经成功了,这给了我们信心和希望。

那么软件测试的职业发展方向有哪些?作为软件测试工程师,又该如何为自己制订职业发展规划?

软件测试职业生涯有主要分为七个发展阶段,如下:

第一阶段:初级测试工程师

初级测试工程师基本上是初入行具备计算机专业学位或一些手工测试经验的个人。具体做一些执行测试用例,记录bug,并回归测试,通过测试工具录制回归测试脚本,并执行回归测试脚本的工作。如果此阶段的测试工程师向发展到下一个阶段的话就需要学习开发测试脚本并且开始熟悉测试生存周期和测试技术。

第二阶段:程序分析员或者测试工程师

此阶段的测试人员基本有了1~2年工作经验。具有初步的自动化测试能力,完善自动化测试脚本。主要工作是设计和编写测试用例,编写自动测试脚本程序且担任测试编程初期的领导工作。此阶段的测试人员想发展的下一阶段必须拓展编程语言、操作系统、网络与数据库方面的技能 。

第三阶段:程序分析员或者高级测试工程师

此阶段的测试人员基本有了3~4年经验的测试工程师或程序员。具有一定的行业业务知识,储备系统分析员的能力。此阶段工作主要是帮助开发或维护测试或编程标准与过程,分析软件需求,获得测试需求。确定测试需求相应的测试方法,获得测试策略方案。参与同行的评审(软件需求,软件测试计划等),并为其它初级的测试工程师或程序员充当顾问。如果想继续往上发展必须继续拓展编程语言、操作系统、网络与数据库方面的技能。

第四阶段:测试组负责人

此阶段的测试工程师有了4~6年经验的测试工程师或程序员。具有丰富的行业业务知识,具有系统分析员的能力,专长性能测试。工作中主要负责管理1~3名测试工程师或程序员。集中于技能方面,担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因,为开发团队提供bug解决策略。如果想往上晋升需要深度学习性能测试等测试技能。

第五阶段:资深安全或性能测试工程或测试高级负责人

此阶段的测试工程师有了6~10年经验的测试工程师或程序员。工作中主要负责负责管理8~10名技术人员。性能测试整体方案设计,软件系统性能问题定位和性 能优化内存及分析数据溢出等,分析系统的安全漏洞等,负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。如果想再往上发展,需要开发自己一些特定领域的技术专长。

第六阶段:测试/质量保证/开发(项目)、经理

此阶段的工程师已经有了10多年的工作经验。工作中主要负责管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工。

第七个阶段:(公司级质量总监)计划经理

此阶段的工程师至少有15年以上开发与支持(测试/质量保证)活动方面的经验。主要负责管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

总结:

随着互联网的飞快发展,IT行业出现了日新月异的变化,新的技术会不断出现,你熟练掌握的软件测试技术很快就过时了。慢慢地,你就会发现,之前的技术已经无法应付越来越复杂的项目,你该怎么办才能保证自己不被淘汰呢?当然是不断学习了!“学如逆水行舟,不进则退”,技术大牛都在努力提升自己,更何况我们呢?!

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

posted @ 2018-10-23 17:47 51testing 阅读(89) | 评论 (0) | 编辑 收藏
 
测试管理篇:新晋Leader与测试组员沟通的9大法门!

一个高效的团队离不开leader和组员之前,组员和组员之前的通力合作。而合作的基础便是彼此之间的商讨与协调,意见的统一,进而在达成共识的前提下行动。那么如何才能和组员达成共识呢? 和组员之间的沟通必不可少。

1、做好沟通前的准备

孔子说:"言未及之而言,谓之躁;言及之而不言,谓之隐;未见颜色而言,谓之瞽(gǔ)。"意思是说:话还没说到那儿,你就出来发表意见了,这叫草率;话已经说到这了,你本来应该自然而然地往下说,可你却吞吞吐吐,遮遮掩掩,这叫有话不说;不看别人的脸色,上来就说话,叫做盲目。可见沟通并不是简简单单的只是表达想说的话。做好前期准备至关重要。

2、沟通地点的选择

和组员的沟通并不是一定要在会议室进行,不同的沟通场景,不同的人员特点可以选择不同的沟通地点。例如,想和组员拉近距离谈心,可以选择相对宽松惬意的咖啡馆,

3、沟通时机的选择

沟通的首要目的就是要提高人员沟通的意愿度,当组员状态不好的时候尽量避免沟通。例如,组员今天出了个线上事故正郁闷,Leader还把组员叫过去了解之前布置的技术调研的事情,这种情况下组员显然没有心情和你沟通这些事情,不妨过几天组员心态平稳了再说。

4、沟通内容的准备

和组员沟通首先要把沟通的目的想清楚,这次找组员沟通到底是为了什么,沟通过程紧扣主题。准备好沟通的素材,例如想指出组员的问题就要提前搜集好组员问题的具体事例和组员聊的时候更容易信服。组员可能问的问题要提前做好准备,想好如何解答,避免出现回答不出来或者回答的不够完美的尴尬场面影响沟通效果。

和组员沟通过程中的注意事项

5、消除组员的紧张感和防卫心理。

当Leader找组员沟通时组员通常比较紧张,有的是对Leader本身的恐惧,有的是对将要沟通的内容一无所知感到紧张。且上下级之之间的沟通组员会天然的构筑防线保护自己。如何才能让组员消除紧张和防卫心理呢? 上面提到的适合的沟通地点和沟通环境可以缓解紧张气氛,沟通时的座位选择也很重要。两个人做的相对近一些,例如坐在一个桌角两边或者找一个小桌子面对面而坐会感觉比较轻松,相反如果两个人做在长长的会议桌两端组员会感觉到Leader高高在上盛气凌人。

适当的肢体接触也可以起让组员放松下来,例如轻拍肩膀等(和异性组员沟通慎用)。

6、耐心倾听

倾听反映了管理者的基本素质。不会倾听他人的诉求,就不可能和他人有效沟通。耐心倾听需要管理者创造良好的倾听环境,保持冷静的心态,要面带微笑,让诉求者感到轻松自如;同时不要随意打断对方的倾诉,不要挑毛病,不要当场表达自己的不同意见,更不要与对方争论,要尽量避免使用否定性或者评论性的回答,应该努力理解诉求者的每一句话,必要时重复对方的语言;倾听时最好利用眼神、表情、手势等身体语言,表达出自己的认真倾听的状态,鼓励诉求者。

7、充分尊重组员

注意自己的言行举止。沟通过程中眼睛要注视对方,要有眼神上的交流。避免一些小动作,例如跷二郎腿,扣指甲之类。端正坐姿,尽量避免靠在椅子上,更不要趴在桌子上和组员沟通。

组员表达完毕后要适当的给予赞赏和鼓励,对好的一面要给予肯定。

Leader在表达时要顾忌组员感受。避免用尖锐,刻薄的词语,避免人身攻击。

尊重组员隐私。组员个人,家庭等事情等,如果组员不愿意说不要死气白咧的问个没完,会引起组员的反感。

8、Leader调整好心态

避免自私,自大,自我。例如,因为你的失误导致我被领导骂,别影响我的绩效之类完全自私自利的言论。

不要表现的对组员漠不关心。例如,你的问题要你自己解决和我有什么关系,没事儿别来找我之类。

平等的沟通,避免我是权威。例如,你是Leader还是我是Leader,这个事儿我说了算。别废话,按我说的来之类。

控制情绪。和组员沟通始终应该在平和的气氛下进行,Leader要控制过激行为,注意沟通时的语调,注意不要想组员发泄不满。

9、与组员促进坦诚

沟通过程尽量直接了当。Leader与组员沟通可以适当铺垫,但是要就事论事儿,直接了当的表达内心最直接的感受和想法,不要拐弯抹角的暗示让组员猜疑。

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

posted @ 2018-10-19 17:29 51testing 阅读(109) | 评论 (0) | 编辑 收藏
 
视觉回归测试—UI自动化的最后一公里

视觉回归测试

我们认为如果一个界面通过第一次的人工验证并发布之后,它就是一个正确的标准界面,并且是包含了人工测试价值的资产。当下一次测试的时候,这部分价值就应该被保留并重用起来,用于减少新的一次测试的时间,从而实现界面的快速回归测试。

视觉回归测试包含以下几个主要的测试步骤:

回归和感知测试流程差不多只是差异值要更小一点,并且只有效果图需要替换内容。

视觉测试用于评估Web应用程序跨浏览器的响应能力。通过执行视觉测试,您可以查看前端的UI / UX组件,以决定受测试的应用程序是否可以适配于各种浏览器,设备和屏幕分辨率,因为它们都提供了不同的体验。

据《The Selenium Guidebook》的作者Dave Haeffner介绍:

视觉测试是一种验证应用GUI是否正确地展示给用户的操作。测试目标是找出应用在可视化上存在的软件缺陷,例如,字体、布局和渲染问题。这使得所发现的软件缺陷可在被最终用户看到前得到修正。

此外,视觉测试可用于验证页面的内容,非常适用于一些提供图形功能(例如图表、仪表盘等)的站点。如果使用传统的自动化功能测试工具,那么实现此类验证是非常具有挑战的工作。

视觉测试在本质上是十分复杂的,其中需要考虑的因素很多,例如Web浏览器、操作系统、屏幕分辩、响应设计、国际化等。

之前业界里面对视觉测试的最佳实践就是: 截图比较用于视觉验证。

视觉回归测试包含以下几个主要的测试步骤:

1、对于产品版本进行截图(线上环境或者类线上环境)

首先人工完成第一个软件版本的测试并部署上线,在第二个版本需要进行测试的时候首先对第一个版本的所有界面进行截图形成基线。

2、对于新的发行版进行截图(比如测试环境)

然后对第二个需要进行测试的版本的所有界面也进行截图。

3、配对URL(忽略hostname)

通过配对URL,对所有的截图按照相同的URL进行分组。当然有时候会出现新的界面,有时候老的界面会被删除。对于新的界面就需要人工进行首次验证测试 。

4、像素级别的图形比较

对于分组之后的截图进行像素级别的比较并生产差别图。有时候为了降噪,可以只对局部关心的组件进行比较。

5、人工查看所有不同

最后通过人工审查差别图报告完成测试。

实质上,视觉回归测试就是用于图像比较的工具。比较好一点的图像比较工具还需要允许用户可以将需要忽略的区域设置为使用动态组件,从而避免误报。比如你的项目需求为开发只是改了一个CSS样式,而测试人员需要检查应该只影响一个点的布局更改时(例如,当您需要跨多个设备/屏幕分辨率进行跨浏览器测试和验证应用程序时),这将非常有用。 (例如当产品的小姐姐希望只有下图中的中间字体变化时)

修改1.png

(最后发现,网站中的另外的不希望变化的网页也被变化了)

修改2.png

比较有名的视觉回归测试的开源框架有: - AET 基于Java的视觉回归测试工具 还在更新中 - Gemini 基于Selenium的 还在更新中 - Dpxdt 用Python编写的,忧伤的是最新的更新也是2016年的了。

商用的比较火的就是以下这家咯: - Applitools Eyes 云服务加AI的视觉回归测试工具,Applitools公司在2017年7月获800万美元B轮投资,到目前为止,它已经获取到了1500万美元的风投,也成为了2018年全球最值得关注的100家AI公司之一。

​

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

posted @ 2018-10-18 17:53 51testing 阅读(169) | 评论 (0) | 编辑 收藏
 
测试架构师10年经验分享:测试小工到资深专家必备这5项技能!

这两天一直在和朋友聊软件测试的发展:这一行的变化确实蛮大,从开始最基础的功能测试,到现在自动化测试岗位需求逐渐增多,测试架构师的岗位也随之兴起。我也在软件测试这行摸爬滚打了十多年了,正好有朋友问我:如何快速成为资深的测试架构师呢?趁着最近终于有了些闲余时间,遂总结了下测试架构师的成长线路图和职业必备技能,希望可以帮助各位少走弯路、破茧成蝶、迈向成功。

一、测试架构师成长线路图

第一步,成为互联网时代合格的测试工程师。

如果你是入行不满3年的测试工程师,一定对此有迫切需求。此时,你必须迅速掌握被测软件的业务功能与内部架构,并在此基础上运用各种测试方法,尽可能多地发现潜在缺陷,并能够在已知缺陷的基础上进一步发现相关的连带缺陷。

从知识体系上看,除了全面的计算机基础知识,你还需要了解互联网的基础架构、安全攻击、软件性能、用户体验和常见缺陷等知识。

从测试技术上看,你需要能够使用常见的测试框架或者工具,需要具有一定的自动化测试脚本的开发能力,这可以把你从大量重复的工作中解放出来。

第二步,成为互联网时代优秀的测试工程师。

如果你想从“合格”变为“优秀”,那你必须完全明白这两者之间的差别。

1、合格的测试工程师关注的是纯粹的测试,而优秀的测试工程师关注更多的是软件整体的质量,需要根据业务风险以及影响来制定测试策略,有效控制测试的时间和成本,并且能够对测试框架以及工具做出适合项目需求的选型。

2、优秀的测试工程师不仅可以娴熟地运用各类测试工具,还非常清楚这些测试工具背后的实现原理,以及多个同类测试工具各自的优缺点和适用场景。同时,你很有可能会接触到一些代码级的测试,这就要求你具有一定的开发背景,并能够很好地理解代码级的测试技术。

3、随着自动化测试用例的不断增长,自动化测试的关注点也从原本的“如何把手工测试步骤用自动化脚本实现”变成了“如何构建低维护成本,可以灵活组装的自动化脚本”,这就要求你理解自动化脚本的分层设计、页面对象模型以及业务流程模型,并且能够把这些设计应用到你的测试框架里。

第三步,成为互联网时代的测试架构师。

当你经历了各种类型的测试项目,你会发现很多东西是相通的。

比如,面对大量测试用例的执行,无论是GUI还是API,都需要一套高效的能够支持高并发的测试执行基础架构。

如果你已经能够站在这样的高度看待软件测试,那么恭喜你,你已经具备了测试架构师的视野。当然,你还必须对一些前沿的测试方法和技术有自己的理解,并能够在恰当的时候、因地制宜地把它们应用到实际项目中。

二、测试架构师必备职业技能
1、必备基础


linux作为越来越多使用的服务器搭配的系统,成为了不管是测试还是运维还是开发,都需要会的内容。通过一系列常规的Linux系统的使用和操作,强化该系统的实战操作,未测试功底打下坚实的基础。

Mysql作为最具有代表性的数据库之一,掌握一系列测试所需要的数据库知识不管是功能测试,性能测试,都是必要的技能。

2、接口测试技术

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系。接口测试作为目前最火的技术之一,且内容满足行业当前甚至几年内的需求,从初级攀升至高级的必经之路,让BUG无处可藏。

3、自动化技术

自动化测试作为测试行业需求最大的技术点,进阶高级测试工程师必会点之一。什么?你不会代码?学!什么?你代码基础薄弱?学!一句话,如果你连自动化都不会,那么你敢说自己是高级测试工程师?

4、性能测试技术

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。

5、TestOps架构技术

揭开TestOps的神秘面纱,持续集成Jenkins框架烂熟于心。

如果能将测试,自动化测试融入到整个开发,运维的整体流水线中,达到完整的过程自动化构建,部署并快速得到测试验证结果,那么这将是完美的测试形态。

总结:

想要成为优秀的测试架构师,首先你得从人群中冒出来,要想冒出来,你就必须做到与众不同,要做到与众不同,你就要会得更多! 成为技术大牛梦想虽然很美好,但是要付出很多,都需要花费时间、金钱和精力,测试理论知识、缺陷管理规范、测试流程、设计及编写测试用例这些都是必备的技能,只要你想学习,完全可以参照我前面的学习路线图来执行哦。

学习是无止境的,机遇也是自己创造的,前提是你是否真的了解软件测试是什么,你是否真的感兴趣并且能坚持刻苦。我期待对测试感兴趣的人,都能成为软件测试生力军~

没有过不去的火焰山,没有吭不掉的技术难题,只要你敢,肯下功夫,都会取得最终的胜利。

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

posted @ 2018-10-17 17:27 51testing 阅读(264) | 评论 (0) | 编辑 收藏
 
一篇文章4条总结,快速了解持续集成测试的基本知识!

2017年8月开始接手做持续集成平台的工作,该平台包含打包发布,每日构建,稳定测试。做这个的初衷是为了能够提早的暴露出问题,同时使开发在打包上尽可能少出错,提高效率。

首先收集现状,源码管理混乱,底层打包空间共用,apk打包在本地,没有稳定性测试,专项测试。需求整理,需要做源码管理,分离底层共用的空间,打包统一使用服务器打包,增加自动化测试,稳定性测试,专项测试。

下面说下我们的每日构建跟稳定性测试:

1.客户端每日构建


1.1、单元测试

单元测试主要是由开发负责编写的,主要是因为开发对产品更加的了解,同时测试开发团队人太少了,要做的事情好多,优先做其他的。关于框架选择,最初想要使用的方案是robolectric + junit4 + mockito + dagger2,然后被项目经理及总监否定了,选择了android自带的测试框架,主要原因相对与互联网公司我们公司的平台也是自己开发的,所以更需要在真机上执行测试。

执行过程,每天的凌晨会有定时任务去svn 上check out代码,连接设备,然后使用gralde命令执行测试生成测试报告。

1.2、集成测试

在这里我们的集成测试跟单元测试很像,在用例设计上主要是是按业务流程去执行的单元测试。

对于集成测试,可以加入ui自动化测试,比较喜欢的一个自动化测试是macaca。

1.3、静态代码分析

静态分析的话会在服务器上安装sonar-scanner,执行扫描后将结果上传到sonaerqube上,代码规则的的配置会在sonarqube上,最初开始做静态代码分析不建议开启很多的规则项,需要给开发团队适应的过程,规则如果一开始就开很多,开发估计就直接不改了吧,而且自带的规则会有一定的误报率,需要人工筛查。

1.4、报告邮件通知

执行失败或者成功都回给开发测试发送邮件通知。

2、客户端稳定性测试

稳定性测试主要是为了暴露apk的性能问题,提高产品的稳定性。

执行流程,凌晨定时任务会去拉取svn上的代码,代码更新好后,会使用脚本sed命令去把leakcannary加入到代码当中,接着执行apk打包,固件打包,将生成的固件通过OTA升级,(ota升级:将包放到指定的服务器,在通过接口配置由哪个版本到哪个版本的升级,应用本身有个server去检查,从而实现升级)。执行monkey命令,第二天去查看monkey日志,oom日志,已经是否存在.prof文件该文件是leakcannary生成的,拿到prof文件后可以使用MAT或者Android Studio去分析。

对于性能测试需要关注网络,io,流量,内存,cpu,而对于我们的产品更加的关注内存,对于其他的指标我们会在功能测试的时候去关注这块。

3、服务端每日构建

对于服务端的每日构建主要是做部署,接口测试,静态代码分析。服务端使用的语言是php,它的部署较为简单,只需要从使用git pull就可以,部署完成后执行接口测试,静态代码分析。接口测试我们使用的是robotframework+requestlibrary,封装出公共的关键字,写testcase的时候使用该关键字。静态代码分析使用sonar-scanner,扫描结果在sonarqube上展示。最后发送邮件测试报告给开发/测试。

4、其他

4.1、不足

对于我们的整个流程缺乏ui方面的自动化

静态代码分析规则不够完善

单元测试用例太少了

稳定性测试缺乏cpu,io,网络等的监控

部分接口业务无法覆盖(eg:支付)

4.2、躺过的坑

旧的服务器谁都能上去改东西...

同个服务器使用多个版本的gradle打包

底层源码(sdk)管理混乱,开发随意更新源码

不支持接口更新ota配置

源码管理混乱,分支无规范,非主干开发

总结:

在做持续集成的工作中,开始做流程的优化,优化功能测试流程,自动化流程;接触了较多的工具,开始做方案的分析,去做整体的架构设计跟实现,去跟项目经理沟通,沟通是一个很大的学问,当中你可能会遇到脾气好的同时也会遇到脾气差的,遇到脾气不好的告诉自己多笑笑,多找他几次也许问题就能解决。开始更加关注代码的质量,去了解专项测试。

​

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

posted @ 2018-10-16 18:01 51testing 阅读(173) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 15 16 17 18 19 20 21 22 23 Last