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. 测试自动化及软件测试工具的比较(858)
  • 4. 银行线上信贷系统如何做好接口测试?手把手教你接口工具Postman(825)
  • 5. 软件为什么要做异常测试?测试员必知的22个测试点总结!(807)

评论排行榜

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

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

如何对软件支付流程进行测试?才能更安全的买买买!

现在有不少测试朋友做的项目中,可能也会涉及到支付相关的功能。比如:做商城的,做游戏的以及其他在线交易的网站、APP等。如果支付出了问题,或者用户拿少的钱通过篡改请求数据购买大金额的商品,如果是实物的话,发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。

所以,不管是实物也好,虚拟商品也好,涉及到支付功能时,大家在测试的过程中一定要重视,否则,会造成很大损失。

前几天也有小伙伴在评论区留言问我:支付这一块如何进行测试?

那我们今天就来说说支付流程的测试点,废话不多说,来进入我们今天的正题吧。

第一步基本测试

1、安全权限检测 

登录或不登录

2、 选择的支付方式

①网上银行(借记卡和信用卡)直接支付,网上账号支付(通过充值后再支付),第三方平台支付(支付宝,云网,快钱等);

②借记卡未开通网上银行有无提醒,每家银行的接口测试(国有四大银行、招行等其他及国外银行); 

③信用卡是否开通网上银行,有无当天支付限额;、 

④借记卡与信用卡是直接输入卡号、密码、验证码、卡上专用码,还是直接使用用户名和密码加动态密码支付; 

⑤ 直接支付考虑充值费用与所支付费用是否平衡,是否包含一定手续费; 

⑥系统帐号支付:将银行卡或第三方钱转到系统帐号进行支付,检测账户余额不足时是否提示;是否有当天限额;

⑦第三方平台支付,接口的测试;

⑧是否支持批量支付; 

⑨是否需要身份验证、手机短信提示,找他人代付功能;

3、收款功能  提现(转到银行卡或公司账户)功能

4、 账户管理

5、账单查询 

6、打印,传真,邮件提醒功能 

第二步异常情况

1、网络带宽问题 

2、无法正常充值,网上银行充值有问题,如银行服务器忙等

3、 并发用户多 

4、充值、支付成功,但数据未更新

第三步测试方法

1、流程图  画支付流程图,依据业务流程进行功能全覆盖测试

2、接口测试  对支付接口进行重点测试(因支付方式多样,所以选择性广)

3、功能测试  采用黑盒测试策略应采用黑盒测试策略,使用等价类划分、边界值分析、因果图法、判定表法等测试用例设计方法的原理与实现,分别对支付系统的功能、账户和交易风险监控、系统性能及安全性等测试指标项进行测试。黑盒测试法应制订覆盖全部功能模块的测试用例,通过执行测试用例以实现系统功能、业务流程和其它质量特性的测试。

4、安全性测试 

①URL有参数的手动修改参数,看是否得到其他用户的信息和相关页面;

② 在登录输入框的地方输入“or 1=1--”看是否有SQL注入

③在注重SQL注入的同时,一般在有输入框的地方输入

④输入的数据没有进行有效的控制和验证

⑤ 直接输入需要权限的页面地址可用访问

5、性能测试  带负载情况下的响应时间和吞吐率,在某个时间段内同时访问系统的用户数量,或是在线数据处理的数量。

必须重视软件的安全性测试

用户购买100元游戏币时,前往第三方支付跳转进行金额的篡改由100元改成0.01元,结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果,损失比较大。

大家在测试的过程中一定要注意对服务端进行校验,支付时数据的篡改一定要有校验。
当同步、异步通知都存在的情况的,异步通知(第三方支付成功后台通知),没有到账,导致部分用户充值不到账,引起客户投诉。当同步、异步并存的时候,一定要分别对同步和异步进行检验,确保都能正常到账。
我们所做的绝大多少的互联网产品都会涉及到第三方支付,所以支付功能必然是重要的,作为测试互联网产品的一员,我们必须要做好支付的安全性。

最后,如果我们志趣相投,你也对软件测试有着浓厚的兴趣,可以加我qq一起探讨学习 3394781259。

 

posted @ 2018-07-27 17:49 51testing 阅读(288) | 评论 (0) | 编辑 收藏
 
是什么让初级工程师走投无路?
   虽然有非常多的初级工程师,但是并没有非常多的职位给他们。
 几个月前,我参加了一场针对技术领域女性的活动。很多参加者中是新的开发者,毕业于编程学校或者计算机科学课程。几乎所有人都告诉我,她们在获得第一份工作时遇到了麻烦。
  我很幸运。我在大学的第一份“真正”工作是 2010 年哥伦比亚大学的“初级应用程序开发人员”。现如今,甚至找不到一个招聘初级开发者岗位的招聘帖。发这些招聘帖的人说他们被淹没在了简历中。然而优秀的公司又抱怨找不到好的工程师。
  我想知道这是为什么?
  我不知道这样做,具体来说能够为我们节省多少成本,毕竟我不参与公司的运营。但是我知道很多公司对我说过:「我们不雇佣初级工程师的原因是,让高级工程师花时间给他们提供指导,对我们来说成本太高了。」我已经了解高级工程师的价格,因为我就是其中之一,并且为了预估项目预算,项目经理曾让我给项目分配时间。我知道的价格区间是 190 ~ 300 美元每小时。这就是很多公司认为雇佣初级工程师是一笔损失的原因。
  我并不这么认为:没有高级工程师能够一直高效工作一整天。公司对人力成本的焦虑就像鳄鱼的眼泪,(至少以我的观点来说)他们刻意不去思考浪费在很多事物上的时间,比如开会。
  但让我们来做个假设,他们将初级开发者的职位重新加入到团队。另一个问题出现了:高级工程师根本没有与初级工程师合作或者培训他人的经验。当我第一次开始与初级工程师合作时,我不知道该如何去做。我感到迷茫和困惑。我所待的公司基本上就是这样的态度:“让他们有事可做,让他们可以从中学到东西。”但是,这样做真的不可持续。
  我寻找资源,但是并没有找到。如果你知道任何资源,请在留言中通知我。我最终拼凑了各种课程和不同作业。
  但令人惊叹的是,我在做这件事时学到了很多东西。直到我必须解释 Javascript 语言的特性,我才觉得我真的深入地理解了它们。我为教学开发的一些工具最终付诸于项目。
  现在,有一些时候令我感到沮丧。特别是当项目经理或其他经理不了解现实状况的时候。他们总觉得,这些人教了就马上能够进行开发,但这之间有个消化和理解的过程。
  我认为我想说的是:整个软件开发生态系统需要初级工程师以保持健康。培训他们有成本,但也有好处。
  我建议那些想要再次招聘初级工程师的公司,投入一些时间用来制定一个大纲,用来帮助高级工程师以及任何与他们合作的人员有效地辅导。并且说明下这个严峻的现实。
  就像并不是所有初级工程师能够成为成功的开发者。那样的话,你会做什么呢?抱怨辅导你的高级工程师?或者追逐那些奋斗于通往成功领域(如项目管理、销售工程师或者其他非开发的角色)的人。在这些领域,软件技能也是非常重要的。
  并且并不是所有的高级工程师能够成为成功的导师。很多杰出的工程师不具备这一特质。他们应该避免扮演这样的角色。对于那些必须担任导师这一角色的人,如果他们没做好,我们也不应该苛责他们。我曾在一个团队中给初级开发者提供大部分的指导。与其他工程师所做的工作相比,这被认为不是“真正”的工作,这后来也让我不太愿意担当这个角色。是的,我会将性别考虑进去,因为我是一位女性,并且当女性担任类似这种角色,受刻板印象的影响,她们总被认为是“训导员”。那意味着更低的声誉,更低的声誉意味着更少的工资。
  话虽这么说,但如果没有提及一些其他阻碍初级工程师的经济问题,我不足以写下这篇文章。最近,因为一个活动,我拜访了一家公司,他们大概的意思就是说,现在所有“容易”的工作都已外包给另一个国家。这些工作以前都是初级工程师做的。之后有了自动化。我还是初级工程师时许多需要亲自做的工作,现在都可以自动化处理了。
  对于那些初级工程师,找到你的第一份工作正变得越来越困难。你可能不得不做一些我不愿意推荐的事,比如免费给各种项目打工。如果你确实选择了一个非常好的开源项目,你可以将它写到简历上。我不太倾向于推荐为“创业公司”免费打工。
  你也要寻找你自己的导师。现场见面会是最好的方式,虽然我明白并不是每个人都喜欢这样,因此你可以试试 Slack 和 Discord 聊天应用。不过就像很多约会一样,这也会变得糟糕。你将被多次的拒绝。你将做一些糟糕的、甚至完全失败的项目,因为和商业项目的人员相比,免费项目的工作人员一般有点更古里古怪。就像一个初级工程师告诉我的:他们不再去某个见面会,因为他们之前做的项目彻底地失败了。我不得不告诉他们应该继续寻找项目,但心中要明白大多数项目都不是完善的。
  对我而言,我很高兴为参加见面会的人提供辅导。在这些背景下,我也要努力地制定一份更正式的导师计划。
  我不确定整个行业的解决方案是什么。我不确定缺乏初级工程师的公司是不平衡的还是聪明的。实际情况是,大多数软件开发人员不会长时间呆在一个地方,所以也许投入大量资源来培训人员是没有意义的。或者说,这个行业也许应该问问自己,为什么人们不停地跳槽?也许是因为大多数公司都很糟糕,或者对我们很多人来说,这是提高薪水的唯一途径。我可以等待一个愚蠢的、毫无意义的年度“绩效评估”让我涨 1% 的工资。或者投递简历,通过面试,拿到 10% 或更多的工资涨幅。
  这不仅仅是个别公司不够完善的信号,也是整个行业不够完善的信号。
​   
posted @ 2018-06-01 14:33 51testing 阅读(124) | 评论 (0) | 编辑 收藏
 
成为技术老大技术管理篇一技术演变史
上一篇我们聊了操作系统为高效利用网络IO,提供的几种解决方案。今天,我们继续聊一下Web和应用服务器的设计。
  先说一下Web服务器和应用服务器啥区别。早期互联网时代,信息大部分就是静态的Html,这时候对服务器来说,最大的问题就是解决大量网络请求的接入。后期随着互联网深入到我们生活的方方面面,信息已经开始动态化和个性化,这需要我们经过业务逻辑的处理后再返回动态信息。
  业务处理逻辑和网络处理逻辑怎么整合到一起呢。显然,我们是想让服务器能作为中间件独立出来的,这就需要为业务逻辑模块抽象出一个统一的接口,这就是CGI(通用网关接口)的由来。
  业务代码只要实现CGI的要求,就可以被Web服务器掉起。业务代码是逻辑比较复杂的,这也催生了各种开发语言的诞生,从C到php、.Net、Java,其实本质上是提供了更多的数据结构和算法支撑,提供更深的抽象层次。让业务代码编写和扩展更容易。
  有了CGI,我们再具体看Web服务器怎么接入这些不同的语言代码。像php/.Net/Java这些语言都需要一些解析器或者运行时来支撑,最简单的方式就是将这个运行时作为一个module直接和Web服务器编译在一起。但是这样也有问题,如果业务代码出错,可能整个Web服务器也会出问题,影响其他业务请求的处理。
  再有一种方式,就是把解析器或者运行时作为一个程序单独运行,当Web服务器有请求到达的时候,直接调起解析器进程,把请求参数传递过去。但是这样做也有问题,想象下有1000个并发的话,就需要1000个进程来处理,能同时处理的并发不会太高。另外,每次请求都需要启动一个进程,性能也会有问题。
  我们在第二种方式基础上再优化一下,每次请求完成后,该进程不退出,继续运行着,当有新的请求来的时候,继续处理。这样就避免了每次开启进程的开销。
  我们可以看到,这几种方式都是直接启动进程来处理的,优点是,每次请求是独立的,如果出现了故障,也不会影响整个服务器;缺点是启动进程的代价有点大,性能不高,而且高并发支持并不好。我们可以用线程这种方式来解决,进程和线程互相配合,每个进程有一个线程池并行处理,当请求过多的时候,再启动新的进程。这就是FastCGI的方式。
  说到这里,我们看到Web服务器已经不仅仅只处理网络请求了,也有了处理复杂业务的能力。随着Java等技术的发展,逐渐出现了Tomcat等JavaEE的解决方案,他把Web请求和复杂业务的处理能力结合在了一起,提供了完整的解决方案。这种服务器我们叫做应用服务器。
  其实,无论是Web服务器,还是应用服务器,还是单独的网络解决方案包,解决的问题一样,方案也有类似的地方。单独的服务器代码比较复杂,大家可以去看看网络包的代码,如ACE、Java的Netty等等,可以继续深入研究。
  总结一下,互联网从只提供静态信息,到提供个性化、动态化的信息和服务,极大的改变了我们生活的方方面面。技术永远为问题而生,这也催生了Web服务器逐渐发展成为应用服务器。
​
posted @ 2018-05-29 10:53 51testing 阅读(104) | 评论 (0) | 编辑 收藏
 
成为技术老大技术管理篇一技术演变史
上一篇我们聊了操作系统为高效利用网络IO,提供的几种解决方案。今天,我们继续聊一下Web和应用服务器的设计。
  先说一下Web服务器和应用服务器啥区别。早期互联网时代,信息大部分就是静态的Html,这时候对服务器来说,最大的问题就是解决大量网络请求的接入。后期随着互联网深入到我们生活的方方面面,信息已经开始动态化和个性化,这需要我们经过业务逻辑的处理后再返回动态信息。
  业务处理逻辑和网络处理逻辑怎么整合到一起呢。显然,我们是想让服务器能作为中间件独立出来的,这就需要为业务逻辑模块抽象出一个统一的接口,这就是CGI(通用网关接口)的由来。
  业务代码只要实现CGI的要求,就可以被Web服务器掉起。业务代码是逻辑比较复杂的,这也催生了各种开发语言的诞生,从C到php、.Net、Java,其实本质上是提供了更多的数据结构和算法支撑,提供更深的抽象层次。让业务代码编写和扩展更容易。
  有了CGI,我们再具体看Web服务器怎么接入这些不同的语言代码。像php/.Net/Java这些语言都需要一些解析器或者运行时来支撑,最简单的方式就是将这个运行时作为一个module直接和Web服务器编译在一起。但是这样也有问题,如果业务代码出错,可能整个Web服务器也会出问题,影响其他业务请求的处理。
  再有一种方式,就是把解析器或者运行时作为一个程序单独运行,当Web服务器有请求到达的时候,直接调起解析器进程,把请求参数传递过去。但是这样做也有问题,想象下有1000个并发的话,就需要1000个进程来处理,能同时处理的并发不会太高。另外,每次请求都需要启动一个进程,性能也会有问题。
  我们在第二种方式基础上再优化一下,每次请求完成后,该进程不退出,继续运行着,当有新的请求来的时候,继续处理。这样就避免了每次开启进程的开销。
  我们可以看到,这几种方式都是直接启动进程来处理的,优点是,每次请求是独立的,如果出现了故障,也不会影响整个服务器;缺点是启动进程的代价有点大,性能不高,而且高并发支持并不好。我们可以用线程这种方式来解决,进程和线程互相配合,每个进程有一个线程池并行处理,当请求过多的时候,再启动新的进程。这就是FastCGI的方式。
  说到这里,我们看到Web服务器已经不仅仅只处理网络请求了,也有了处理复杂业务的能力。随着Java等技术的发展,逐渐出现了Tomcat等JavaEE的解决方案,他把Web请求和复杂业务的处理能力结合在了一起,提供了完整的解决方案。这种服务器我们叫做应用服务器。
  其实,无论是Web服务器,还是应用服务器,还是单独的网络解决方案包,解决的问题一样,方案也有类似的地方。单独的服务器代码比较复杂,大家可以去看看网络包的代码,如ACE、Java的Netty等等,可以继续深入研究。
  总结一下,互联网从只提供静态信息,到提供个性化、动态化的信息和服务,极大的改变了我们生活的方方面面。技术永远为问题而生,这也催生了Web服务器逐渐发展成为应用服务器。
​
posted @ 2018-05-29 10:53 51testing 阅读(71) | 评论 (0) | 编辑 收藏
 
一位博士后教我如何做软件需求分析
  今天公司的高级顾问刘博士与产品经理们进行座谈,以提问回答的形式以点带面来解答、探讨大家在平时工作中碰到的一些问题,主要是针对软件方面。过程中,我向刘博提出两个问题。
  一、如何更好地做好需求落地?
  背景:来公司这1年多时间里,负责做了大大小小五、六十个项目的需求分析,大多都是各业务大区提过来的项目需求,在这过程中面对不同项目的需求,不断地锻炼需求转化能力,关于如何更好地让需求落地看能不能从牛人身上学习到更好的方法论。
  回答:产品经理在日常的工作中,既要面对客户也要对接研发人员,在这中间充当着桥梁的作用,将业务需求与开发需求给连接起来,不同级别层次的产品经理,区别就在于“修”好这座桥的质量和效率如何。在拿到原始需求时,要有能力去甄别筛选它们,可以采用结构化方式对需求进行梳理,然后排好他们的优先级别,这样在心中对接下来要做什么事情有个比较好的认识。经过第一阶段的梳理,大概清楚要做什么事情后,接下来是将业务需求转化为系统功能的阶段,可以采用用例图(UML)的方式,将什么东西要做什么事情和如何去做给表达出来,一层层的剖析下去直至达到需求细化的程度。让开发人员知道怎么去研发。举个例子:(他拿起手中的iphone)现在我要对按下音量下键的这个需求去做分析,怎么做呢?首先我会识别出按下音量下键这个需求的合理性和必要性做个识别,清楚我为什么要去按音量下键这种场景?然后,将它转化为在系统中进行表现。在按下后,我会对软件的哪些模块进行数据的交互以及如何与用户进行交互?这就是产品经理对接开发的时候要去做的事情,同时也是让需求如何去做落地流程?
  结论:其实,过去的2年工作中,我一直都是在重复着刘博士回答的这个需求落地的过程。然后我跟他说明了这个情况后,问有没有更好的需求分析方法。比较尴尬的是,他直接回答说没有,软件的需求转化过程基本都是以这种方式进行,本质上没有太大的差异。
  二、在评审过程中,如何衡量抉择最终的方案?
  背景:在日常进行需求评审的过程中,由于不同人员看待同样的问题方法会不一样,在评审过程中偶尔会出现开了N久的会议没有最终拍板的方案,作为产品经理面对这种情况,要如何去衡量最终的方案?
  回答:随机应变。无论怎么去讨论,其本质不能变的就是要满足用户需求。再有的是出现这种情况,几种实现的方式都已经可以满足用户需求,但实现的方式不一样。针对这点,产品经理要通过博弈的方式,识破出各种方案的破绽,来引导大家形成统一的共识,做出最终方案地敲定。
  结论:上面的问题其实更像是程序员与产品经理的日常撕逼。产品经理作为用户的代表,要多为用户争取更大的利益,在衡量抉择最终方案过程,多模拟应用场景来摆明依据。要是实在不行,只能这么说:方案就这么定,后果我来承担。担当的越多,责任越大,这应该也是一位成熟的产品经理在团队内的表现。
  其他同事提出的问题:在您日常接触那么多产经经理过程中,觉得哪一点素质对产品经理是最重要的?刘博士答道:持续学习。社会瞬息万变,逆水行舟,不进则退。产品经理在做好分内的事情完,要再花时间去了解行业内的发展趋势,不断地学习其他优秀产品好的地方,吸其精华,弃其糟粕,不断地完善自己,与时代共成长。
  刘博士建议,在产品团队中要建立起知识库,内部定期做技能、经验相关的分享。库是死的,通过分享的方式,可以让里面的知识活起来,形成产品圈特有的氛围和默契,让团队成员能够共同学习共同成长。
​      当然如果有任何疑问,欢迎添加qq群测试入门到大神 755431660 共同学习~
​​
posted @ 2018-05-16 15:36 51testing 阅读(126) | 评论 (0) | 编辑 收藏
 
一个一直“朝九晚五”的程序员
  我近来一直在思考Safia Abdalla所发的一条的推特——
  一个可能不受欢迎的观点(还有一点讽刺):
  要成为一个伟大的工程师,你不需要写博客,也不需要致力开源,更没必要进行技术演讲或者做任何其他事情。
  你可以把代码扔在办公室,这完全没问题。
  ——Safia Abdalla (@captainsafia), 2018年1月13日
  这段文字让我心头一动,虽然我也认识到其中的讽刺意味。自从我因拒绝加班而被炒鱿鱼之后,我对潜在雇主说过的一件事就是我不愿意加班。至少,别是定期加班。我偶尔会经历那么几次“地狱周”,这个时候我们会要么进行特定的编程,要么修复特定的漏洞,问题解决了之后,我就拍拍屁股走人。
  Abdalla女士的推文比这更进一步,正因为如此,我突然更好地认知到了自己的思维过程。看,我选择了这种心态(出现,搞定问题,拍屁股走人),很大程度上是为了保护我自己的理智。如果我没有明确界定什么时候可以考虑工作问题,我就会一直考虑这些问题,对于那些我还没做或者没有解决办法的事情,这的确是个有效的方法。我是不是个专心致志的程序员,这种明确界限的行为可以帮我控制冲动的想法。
  界限与沮丧感
  问题在于我们根本解决不完问题。对于像我这样渴望思考的人来说,我看编程全都是尚待解决的问题,而我又的确可以找到让人们心满意足的解决方案。没错,我是解决了一个问题!恩,太酷了!可那又怎样呢?这只会让人抓狂、沮丧。
  由于我思维和大脑的失控,我不得不设定界限,我不得不离开工作岗位,我不得不成为一个朝九晚五的程序员。
  我知道有很多程序员都患上了冒名顶替综合症。你可能在某个时候也有过这种症状:它让你感觉自己是个骗子,根本不知道自己在做什么,只是假装在做什么而已。我的问题是,如果我不设定这些界限,如果我允许自己继续工作、探索和解决问题,我冒名顶替综合症只会变得更糟。我想知道所有的事情,但很明显我没法知道所有的事情,因为我实在是想得太多了。
  所以,我必须设定界限,比如像“工作就是工作”和“休息就是休息”这样的界限。设定界限可以使我帮助我保持清醒,理智在线。很久以来我都觉得这导致我不像是一个程序员。我不能一连串编16个小时的程,因为到最后我根本就没法做任何事了,我还有心爱的妻子和三个孩子,他们需要我关心他们,爱护他们。而现实就是,我们亲手编写的代码永远不会爱我们的。但是,我还是想做得更好,做一个更好的程序员,就像那些我尊敬的人一样,我痛恨自己没有能力做到这一点。
  在这个问题上,推特和其他社交媒体可以说是最糟糕的。那些很聪明的程序员——说实话,我很欣赏他们的工作——会自豪地宣称他们编程只是花了一整天的时间而已,他们还宣称这样很有成就感。而我呢?我就只能坐下来,对我为什么不能像他们那样感到无比地绝望。为什么我不能在这方面努力呢?该死的大脑!你为什么不让我像他们一样高产呢?我可以做到像他们一样好,只要你别挡我的道!
  我花了很长时间才意识到我的大脑并不能这样运作。我永远也没法进行连续16小时的编码,我也永远都不可能熬个通宵还能把事情做完,我永远也不会像Twitter上那些人所说的那样“富有成效”。没办法,我就是做不到。而且,作为一个工作了11年的专业的软件开发人员,我发现其实这也没什么大不了的。
  的确没关系,因为每天工作八小时我仍然可以解决问题,我仍然可以完成我的工作,而且完成的相当出色,我仍然可以有效地领导我的团队,我仍然可以用有趣的解决方案来解决有趣的问题。我只需要把一切都在我设定的边界之内摆平就行。关键是要意识到,这并没有让我比那些推特的程序员们黯然失色,反而会让我更加与众不同。
  做“朝九晚五”的程序员
  我敢打赌有一群可以被称为“沉默的大多数”的程序员,他们只想干自己的活,然后就拍屁股走人回家。这些人不会在晚上熬夜,以试图解决困扰他们几个星期的问题。这些人也不写博客,也不致力开源项目,更不会进行技术会谈或者对编程以外的其他工作表现出一丁点儿兴趣。这些人有时被戏谑地称为“朝九晚五的程序员们”。我要在这里告诉这些人,尽管我们是所谓的“朝九晚五的程序员”,但我们依然相当地出彩。
  如果你是一个朝九晚五的程序员,那么这不仅不会使你成为一个糟糕的程序员,反而会使你成为一个优秀的时间管理者。
  我不是来告诉你哪条路更好的,我只能告诉你怎么做对我有效——很简单,那就是成为一个朝九晚五的程序员。我只想做我的工作,而且想把工作做好,然后回家做其他事情(比如写这篇博客)。我需要这样做来保持头脑清醒。你也可以,即使你的大脑和我的不一样!你真的没必要用数不胜数的编程结果来证明自己是一个好的程序员。你只需要深入思考问题,有一份想把工作做好的心就好。
  你猜怎么着?如果你现在正在读这篇文章,那你已经做得很好了。该回家就回家,没事儿,我保证,明天活照样干,码照样编~
​       如果有任何疑问,欢迎添加qq群测试入门大神 755431660 共同学习~
​​
posted @ 2018-05-15 10:37 51testing 阅读(129) | 评论 (0) | 编辑 收藏
 
项目开发中遇到的Bug解决经验总结
今天在项目开发中遇到了两个很难解决的bug,我把我的思路记录下来,以供之后遇到bug时,提供一些思路:
  编译通过,但总结"core dumped"
  这个是写一个数据包捕捉函数的时候,程序编译通过,但是总是在实际执行的过程中总是出现"core dumped"
  这个算是我最害怕遇到的问题,总找不到错的原因.后来给捕捉的数据包编号之后发现,有的数据包就是一个"NULL"
  导致处理函数处理数据包的时候发生了错误.
  给我的教训:
  每写一个函数,必须要参数检查,千万不要想当然,认为不可能出现什么情况,但实际上就会出现什么情况
  每当在出问题的地方,一些简单的测试方法说不能就能找出问题,比如说简单地给数据包编号
  编译的过程出现"XXX"未定义的引用
  这个如果说经历过这样的错误的人很容易就能搞清楚为什么出现这样的错误,可能是某些头文件没有#include到,但实际上我
  找了半天也没发现不包括什么样的头文件.
  我解决的过程就是将该功能孤立出来,做一个简单的程序,发现不存在这样的问题,后来通过重现编译过程,才发现是cmake文件
  并没有添加一个文件夹
  给我的教训:
  出现问题,尽量把问题控制在足够小的范围,如果还没有找出来,那就单独写一个小程序,复现这个问题函数的错误过程,如果还没有发现问题,就尝试编译过程是否出现错误,这样一次检测下来,应该能够发现问题.
如果有任何疑问,欢迎添加qq群测试入门大神 755431660 共同学习~
​​
​
posted @ 2018-05-11 11:58 51testing 阅读(183) | 评论 (0) | 编辑 收藏
 
QA与RD、PM沟通——测试过程中,遇到的问题
 在测试过程中,经常遇到需要和RD、PM沟通的问题。
  1、写case时,对需求文档内容存在疑问。
  解决办法:
  1)先找之前参与需求评审的QA,询问;
  2)问开发该需求的RD:查看RD排期,是否已经,或即将开始开发,若RD未开始开发,很多时候,他们也不是很了解需求内容。
  3)若影响case的编写,可在企业微信上,直接问PM。若问题较多,可直接找PM当面询问。
  4)若不影响case的编写,可在case里做标记,在case评审时抛出,请PM回答。
  2、在开始测试的前一天,找RD确认是否能正常提测。有时RD反馈无法正常提测。
  解决方法:
  1)一定要确认影响提测的原因,如果当前自己排期内可消化,可在与其他RD沟通,并在自己排期内做调整。
  2)一定要确认可以提测的时间点,如果是由于server端导致delay,是否可以让端上RD给个入口,端上先mock数据先测。
  3)若端上或server有delay,一定要告知直接领导。
  4)delay有可能导致风险,一定要及时抛出,若需要报risk,一定告知RD,一定及时在Jira提risk。
  5)若严重delay,且server或端没有配合尽快解决,可邀请领导加入微信群,催促大家尽快完成;若问题非常严重,可邀请领导的领导加入微信群(谨慎邀请),催促大家尽快完成。
  3、在测试过程中,遇到RD无法解决的bug,同时无法解决的bug数量不多。
  解决办法:
  1)告知PM:bug详情、RD反馈无法解决。
  2)若PM表示不修改,则在Jira上对应的bug上备注并关闭bug(备注中要标明具体PM)。
  3)若PM表示要修改,在企业微信上拉群:QA、RD、PM,在群里告知该问题,@RD和@PM,反馈实情,让RD和PM商量,并给出最终结果。
  4、在测试中,若遇到RD无法解决的bug,同时QA感觉该问题比较影响体验,可告知PM且与PM达成一致后,拉微信群,@RD,反馈bug,让RD修改。
  5、若QA感觉需求设计有问题,可与RD达成一致后,与RD共同反馈给PM。
  6、在测试中,遇到RD无法解决的bug,同时无法解决的bug数量较多。
  解决办法:
  1)将问题一一统计,在企业微信上拉群:QA、RD、PM,在群里告一一抛出问题,@RD和@PM,反馈实情,让RD和PM商量,并给出最终结果。
  若遇到特殊情况:
  1)很多bug,RD反馈无法解决,PM反馈要修改,但RD和PM僵持不下,没有结果。
  2)有的bug,QA感觉严重影响体验,但RD反馈无法解决,PM反馈当前版本不修改。
  3)当前需求无法解决问题太多,严重影响用户体验。
  4)若严重delay,且server或端没有配合尽快解决。
  解决办法:
  1)告知直接领导当前情况。
  2)发邮件:列表格,将各个bug一一记录,加上RD的反馈,和PM决定当前版本是否修改,将表格添加到邮件中,在测试结束前,发邮件,邮件里@RD和@PM,使其在某个时间点前作出回复确认当前情况。邮件抄送给直接领导、QA全员。
  3)如果问题很严重:严重影响用户体验,告知直接领导当前情况,找明明说明当前情况。
  4)可邀请领导加入微信群,督促大家尽快处理当前问题;若问题非常严重,可邀请leader加入微信群,督促大家尽快处理当前问题。
  7、在参加需求评审前,先阅读一遍需求文档,如果有疑问,需要记录下来,可在wiki的需求文档上直接对有疑问的地方备注提出问题,在参加需求评审时,直接提出,问PM。
  若在需求评审上,有未确定的内容,在需求评审的checklist上,是否通过一栏,填写:“未通过”,并备注未通过原因,以及未确定的内容。需求评审后继续跟进,督促PM对会上未确定的内容作出解答,或开二次评审,需求上有更改、添加、删除的内容,督促PM在wiki上做相应的更改。
  8、在测试过程中,PM作出的需求更改、需求添加,都要及时督促PM更新到wiki文档上。
  9、向RD询问bug引入原因的时候(尤其是以前没有该bug,最近都没有对该部分作出修改,但是测试中发现了该bug),有些RD不配合查找bug引入原因。
  沟通方法:
  1)一定耐心告知RD“查找bug引入原因”的目的,不要引起误会。
  2)一定不要和RD产生争执。
  3)从RD和QA的利益共同点出发,详细告知我们这么做的目的,以及我们的收益,和最终希望达成的效果。
  11、在测试过程中,即使是需求小改动,也要告知直接领导,只要没有排期,不允许上线及测试,没有排期不允许修改。
  12、RD在代码上作出的修改,是否免测由QA说了算:
  1)有些RD会告知没有影响,无需测试;
  2)有些PM告知他已验收,无需测试;
  以上2种情况都不可,是否免测由QA说了算。
​        如果有任何疑问,欢迎添加qq群测试入门大神 755431660 共同学习~
​​
posted @ 2018-05-08 14:02 51testing 阅读(182) | 评论 (0) | 编辑 收藏
 
软件测试中的“黑盒”与“白盒”
 软件测试中,最常听到“黑盒测试”与“白盒测试”,它们是软件测试中最基本的测试方法。
  那么究竟何为“黑盒”,何为“白盒”呢?下面就对其概念与常用方法进行一下介绍。
  黑盒测试:
  也称功能测试、数据驱动测试,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试。
  概念:黑盒测试是从一种从软件外部对软件实施的测试,也称功能测试或基于规格说明的测试。其基本观点是:任何程序都可以看作是从输入定义域到输出值域的映射,这种观点将被测程序看作一个打不开的黑盒,黑盒里面的内容(实现)是完全不知道的,只知道软件要做什么。因无法看到盒子中的内容,所以不知道软件是如何实现的,也不关心黑盒里面的结构,只关心软件的输入数据和输出结果。
  检测软件功能能否按照需求规格说明书的规定正常工作,是否有功能遗漏;
  检测是否有人机交互错误,是否有数据结构和外部数据库访问错误,是否能恰当地接收数据并保持外部信息(如数据库或文件)等的完整性;
  检测行为、性能等特性是否满足要求等; 检测程序初始化和终止方面的错误等。 
  优点: 
  ① 与软件具体实现无关,如果软件实现发生了变化,测试用例仍可用; 
  ② 设计黑盒测试用例可以和软件实现同时进行,因此可压缩项目总开发时间。
  黑盒测试常用方法
  等价类划分
  边界值分析
  因果图
  决策表分析
  等价类划分
  完全不考虑程序的内部结构,只根据程序规格说明书对输入范围进行划分,把所有可能的输入数据,即程序输入域划分为若干个互不相交的子集,称为等价类,然后从每个等价类中选取少数具有代表性的数据作为测试用例,进行测试。
  划分原则:区间、数值、数值集合、限制条件或规则、细分等价类
  边界值分析
  边界值和等价类密切相关,输入等价类和输出等价类的边界是要着重测试的边界情况。在等价类的划分过程中产生了许多等价类边界。边界是最容易出错的地方,所以,从等价类中选取测试数据时应该关注边界值。
  在等价类划分基础上进行边界值分析测试的基本思想是,选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据,而不是选取等价类中的典型值或任意值做为测试数据。
  对于一个n变量的程序,边界值分析测试会产生4n+1个测试用例。
  因果图
  (1)确定软件规格中的原因和结果。分析规格说明中哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件),并给每个原因和结果赋予一个标识符。 
  (2)确定原因和结果之间的逻辑关系。分析软件规格说明中的语义,找出原因与结果之间、原因与原因之间对应的关系,根据这些关系画出因果图。 
  (3)确定因果图中的各个约束。由于语法或环境的限制,有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。 
  (4)把因果图转换为决策表。 
  (5)根据决策表设计测试用例。
  决策表分析
  在所有的黑盒测试方法中,基于决策表的测试是最严格,最具有逻辑性的测试方法。
  决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。 
  它能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。
  步骤: 
  (1)列出所有的条件桩和动作桩。 
  (2)确定规则的个数。 
  (3)填入条件项。 
  (4)填入动作项,得到初始决策表。 
  (5)简化决策表,合并相似规则。
  对于n个条件的决策表,相应有2n个规则 
  决策表合并原则:即若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。
  白盒测试:
  也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。
  白盒测试常用方法
  基本覆盖标准:逻辑驱动、循环、基路测试等,主要用于软件验证。
  “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
  “白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。
  原因: 
  第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。 
  第二,穷举路径测试不可能查出程序中因遗漏路径而出错。 
  第三,穷举路径测试可能发现不了一些与数据相关的错误。
  白盒测试逻辑驱动方法
  语句覆盖
  判定覆盖
  条件覆盖
  判定/条件覆盖
  条件组合覆盖
  路径覆盖
如果有任何疑问,欢迎添加qq群测试入门大神 755431660 共同学习~
​​
posted @ 2018-05-07 11:27 51testing 阅读(111) | 评论 (0) | 编辑 收藏
 
Jmeter跨线程组传值实例

转载:http://www.51testing.com/html/01/n-3725501.html​​
​Jmeter
是一个工具,一个很好用的工具,对于它我们用来做压力测试后,还可以用来做自动化测试,但是作自动化的时候我们

需要考虑到流程的流转和顺序排版,那么此时我们该怎么做?

对于模块的分割我们或许可以用控制器来分割,但是有时为了将某个模块独立出去,我又需要用线程组来分割,但是线程组与

线程组之间有些参数的数值需要传递,该怎么办?

PS:Jmeter的线程组之间是独立的

已登录接口返回的token值为例,在这里我用了一个后置器和一个前置器结合使用,如下图:

1.1、登陆后先获取到token值,(用正则表达式获取到token值,根据调试可看出token成功获取)

1.2、在http请求后面添加后置处理器BeanShell PostProcessor,如下图所示:

1.3、在BeanShell PostProcessor中编写脚本:

1.4、在测试计划用添加前置处理器BeanShell PreProcessor,如下图所示:

1.5、在BeanShell PreProcessor中编写脚本,如下图所示:

1.6、引用usertoken的值,看是否被成功跨线程组传递

请求:

结果:如下图,usertoken的值被成功获取:

PS:为了让每个线程组不背混乱执行请在测试计划中勾上独立运行每个线程组

posted @ 2018-04-03 11:35 51testing 阅读(371) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 21 22 23 24 25 26 27 28 29 Last