2012-12-10 14:30:18 wuyanhong1985 阅读数 725
  • 机器学习实战训练--业务实践之路

    本系列课程为您讲述如何使用机器学习算法解决业务问题,会以实际业务作为出发点,所有实验都提供实验流程以及实验数据,帮您用短的时间学习机器学习的原理与使用方法。充分理解如何在业务问题上是同数据挖掘。

    10294 人正在学习 去看看 李博

   在学校学习过计算机的一些理论知识,比如C++JAVAVB,数据库等等,但都是懂个大概。接触软件测试是从今年九月份开始的,主要是看测试理论以及数据库方面的知识,动手实践很少,所以刚开始对测试一窍不通,感觉很迷茫。后来有机会接触了一个商城的测试,才稍懂软件测试是怎么一回事。

   进入公司一周了,为了了解公司现在的项目,首先看了软件需求规格说明书,接着是边熟悉业务边测试。

一、经过几天的测试工作,发现:

  1.软件测试一定要动手实践,也许刚开始什么都不懂,像我刚开始一样感觉很迷茫,但真正实践过了,你会有豁然开朗的感觉。

  2.在动手测试之前要先了解业务的流程。不要为了测试而测试,也许你测试工作做得很好,但不熟悉业务流程,就无法达到真正覆盖。

  3.要正视团队协作,软件测试不是单个人可以完成的,要及时的与测试人员以及开发人员甚至部门主管沟通,这样既会提高工作效率,也有利于团队的和睦。

  4.Bug提交要及时,应及时将发现的bug提交上去,这样有利于提高项目的进度。

二、不足之处:因我所在的公司是刚刚成立不久,所以一些程序执行起来还不太正规:

  1.进入公司之前所看的软件测试流程都是:测试计划—>测试用例—>测试执行—>测试评审。而现在公司测试人员做的是先测试,再编写测试用例。

  2.测试工作不被重视,有时发现了问题,找开发人员沟通,他们因赶进度,无暇顾及。因此bug就会一直堆积起来。

  3.Bug没有专门的工具进行管理,公司用的是excel表格管理。所以当提交新的 bug,还要挨个发给每个人。现在测试人员都是把一天发现的bug集中一起,在下班之前发给每个人。这样就没有做到及时更新bug,很难提高bug修复率。

三、接下来要做的事:

  虽然公司的一些运作不正规,但是自己还是要学习正规流程,提高测试技能,不能局限于某一块。

  1.熟悉测试计划的内容并学习测试计划的编写。

  2.学习测试用例的编写方法。

  3.学习软件测试方法。

  4.学习缺陷报告的编写。

 

2018-04-02 20:42:00 weixin_30412013 阅读数 0
  • 机器学习实战训练--业务实践之路

    本系列课程为您讲述如何使用机器学习算法解决业务问题,会以实际业务作为出发点,所有实验都提供实验流程以及实验数据,帮您用短的时间学习机器学习的原理与使用方法。充分理解如何在业务问题上是同数据挖掘。

    10294 人正在学习 去看看 李博

记录一些软件测试工作中的想法。

1)软件测试岗位价值在IT行业里是比较低的,为了更好的体现自身价值,我认为软件测试从业者应该比业务更懂技术,比技术更懂业务。同时具备很好的沟通协调能力。让自己变成万能胶。

 

2)软件测试体现价值的点:

1.发现bug

2.提供信心

3.提供信息

4.预防缺陷

 

3)软件测试一定要考虑测试的覆盖率

 

4)测试工作要体现测试技术,而不是测试工作量

转载于:https://www.cnblogs.com/yaoyinjun123/p/8697215.html

2019-10-06 10:28:52 minzhung 阅读数 49
  • 机器学习实战训练--业务实践之路

    本系列课程为您讲述如何使用机器学习算法解决业务问题,会以实际业务作为出发点,所有实验都提供实验流程以及实验数据,帮您用短的时间学习机器学习的原理与使用方法。充分理解如何在业务问题上是同数据挖掘。

    10294 人正在学习 去看看 李博

测试人员参与需求评审?

1. 熟悉需求

首先要熟悉需求,这是测试阶段必要的过程。

测试人员对需求不熟悉,是无法完成好测试的。业务越复杂的系统,要想做好测试,对业务就必须熟悉。

在需求过程中,一般产品经理会下发需求,让团队成员熟悉需求,再召集全员进行需求评审会议。

在收到需求第一时间就通读需求,不懂不明白的地方都做好记录,等评审会议上一并解决。

2. 测试需求

需求是由产品经理收集用户需求后转化为软件需求。在转化过程中,会因为产品经理个人思维的局限(技术层面的实现、测试的考量等)而造成需求不完善、描述有歧义、逻辑不够清晰。

人对自己的成果天然的包容性,一些显而易见的问题容易被忽略掉。

那么通过需求评审,借助团队的力量弥补产品经理个人思维的不足,从而达到完善需求的目的。

2.1 解决需求歧义

比如给你一个需求:

这是一个活动,满300-50, 用户只要购买活动商品,自动扣减订单金额,每张订单只扣减一次。

这个需求未描述同一个账户是否可重复多次参与,那么就容易产生歧义了。作为一个用户,是否可以拆成多个订单来购买,达到多次参加活动的目的呢?

2.2 需求描述不完整

在需求中,某些重要的功能,只有输入没有对输出结果的描述。

2.3 不可测

主要针对数据来源不明确的情况。

比如某模块数据来源第三方,但是第三方没有提供测试环境等。

2.4 站在用户和业务角度,觉得不合常理

比如某电商系统中,未登录不能添加购物车。

2.5 不符合行业规范和法律法规相关规定

需要测试人员要有意识了解行业业务规范。

如增值税票开票信息中,纳税人识别号非必填。

2.6 业务知识

每个行业都是该行业的专业知识,通过对行业知识的学习,可以提高对软件隐性需求的理解。可以提高测试人员在需求过程中的参与度。

2013-02-25 11:26:52 fen0707 阅读数 453
  • 机器学习实战训练--业务实践之路

    本系列课程为您讲述如何使用机器学习算法解决业务问题,会以实际业务作为出发点,所有实验都提供实验流程以及实验数据,帮您用短的时间学习机器学习的原理与使用方法。充分理解如何在业务问题上是同数据挖掘。

    10294 人正在学习 去看看 李博

不知不觉已经从事软件测试六年了,2006毕业到进入外包公司外包给微软做软件测试, 到现在加入著名的外企。六年的时间过得真快。 长期的测试工作也让我对软件测试有了比较深入的认识。但是我至今还是一个底层的测试人员,我的看法都比较狭隘,如有错误还请批评改正。

阅读目录:

  1. 软件测试人员应该居安思危
  2. 测试人员应该比开发人员更熟悉业务需求
  3. 学会如何和开发人员相处
  4. 测试人员应该懂一些基本的编程
  5. 测试人员搭建开发环境
  6. 写文档是测试人员的核心能力
  7. 测试后期应该做两天交叉测试
  8. 测试人员的瓶颈
  9. 尽量实现自动化
  10. 自动化测试VS手动测试
  11. 自动化测试的技术和开发用到的技术相差太远
  12. 最郁闷的是无法听懂开发人员讨论技术
  13. 优秀的测试人员非常稀少
  14. 大部分的测试经理都是有开发背景的
  15. 软件测试的确非常枯燥,需要花费大量精力
  16. 英语是测试人员的救命稻草
  17. 尽量少用UI自动化测试,多使用单元测试,接口测试

软件测试人员应该居安思危

每当经济不好,公司业绩不好的时候,公司都可能进行裁员。 首先裁的就是测试人员。 因为测试人员的技术水平相对来说比较低,容易被替代,招起来也比较容易。 公司往往先拿测试人员开刀。

身为测试人员,虽然我们平常的工作大部分都比较安逸。 但是千万不能温水煮青蛙。 应该自强不息, 要像开发人员一样, 不断学习,提高自己的编程水平。这样就算被裁也能很快找到新的工作。

 

 

测试人员应该比开发人员更熟悉业务需求

测试人员的水平主要体现在测试用例的设计上。 要设计出全面,覆盖广的测试用例,需要测试人员对自己所测试的项目的业务需求非常熟悉,甚至要比开发人员还要熟悉。

如果是测试银行系统,通信行业,或者ERP软件。 这些业务知识非常有用的,学习起来比较有激情。

要做到精通业务需求谈何容易。

1. 要熟读功能需求文档, 任何有疑问的地方都要去和PM确认。

2. 把自己当成最终用户, 经常使用自己所测试的软件。模拟用户的行为。

3. 熟记软件的每个功能。

假如倒霉碰到一些又没用,又繁琐的软件, 真的是不想去学习它的业务(出了这个公司就再也用不到的业务)

 

 

学会如何跟开发人员相处

测试人员必须跟开发人员密切合作, 所以跟开发人员搞好关系是相当重要的。

1. 和开发人员成为朋友。

熟悉了干啥都方便

2. 不要打扰开发人员

看到开发在聚精会神写代码的时候,千万不要去打扰人家。 写代码需要集中精力,如果被打扰,就会中断思考。

3. 集中问问题。

把需要问的问题都总结起来, 集中起来问开发,这样能节省大量的时间。

4. 写好Bug,不被开发人员烦。

如果开发人员看到一个Bug 描述不清楚,还无法重现,他肯定会骂测试人员。 所以测试人员一定要写好Bug,描述精确,简洁,没有歧义,详细简洁的重现步骤,加截图。

 

 

测试人员应该懂一些基本的编程

你的产品是用C# 开发的,那测试人员应该有C#的入门知识。  你测试web程序,你起码要了解HTML,CSS, Javascript, Jquery吧,否则你测了一两年web程序,都不知道这东西是怎么做的,悲剧了吧。

只有懂代码你才能和开发人员交流,不被开发鄙视。

 

 

测试人员搭建开发环境

产品的代码是最好的学习资料了,我们不能总跟在开发屁股后面做测试,不能老是等开发build一个版本后,我们就测试这个版本,开发check in了什么代码,测试人员一点都不知道。偶尔我们应该了解下产品代码是怎么设计的,了解下开发人员是如何修复bug的。说不定编程水平高了,还能帮开发做code review.

使用源代码工具把产品代码check out到本机。 经常看看代码,经常看看开发修复bug时候提交的代码.

 

 

写文档是测试人员的核心能力

我记得我以前的test lead说,之所以她能当lead, 是因为她很会写文档发邮件。 写文档需要总结归纳的能力,还要逻辑清晰。 她非常擅长分析几十页的Spec,写出几十页的测试计划。 她还非常擅长汇总测试报告。 每天将完整,清晰,漂亮的测试报告发给各个组, 让公司所有的人都能清晰的看到测试组的工作。

在她的带领下,我们总结出很多文档,比如,"New hire checklist",   "on boarding traning", 测试工具使用的文档,等等。

写多了博客后我发现我写文档能力提高了很多。

 

 

测试后期应该做两天交叉测试

交叉测试,就是指两个测试工程师,互相交换下测试的项目。 这样做有很多好处。

1. 有利于找出bug, 测试工程师测久了自己的项目,容易形成眼盲。会对一些Bug熟视无睹。

2. 有利于知识和业务共享,避免人员离职,请假,造成无人测试的情况。

3. 测试思想不一样,可以互相找出很多问题

 

 

测试人员的瓶颈

手动测试工作做个两三年,基本上就能掌握测试需要的大部分知识,如果没有爬到test lead的位置, 很多人就感觉到发展瓶颈了,每天重复测试,学不到东西,很快就会对测试工作失去激情。

学不到东西,技术水平低下,是测试这个行业最大的毛病。

如何突破瓶颈? 我也不知道。

 

 

尽量实现自动化

一点要抽时间尽量把自己的测试工作实现自动化,可以节省测试的时间,提高自己的技术水平,也可以避免老是重复测试。

 

 

自动化测试VS手动测试

现在很多公司招测试的要求越来越高,很多好公司招senior QA,都要求5年工作经验以上,掌握一门编程语言,有丰富的自动化测试经验。当然自动化测试的待遇也会比手动测试好很多。

自动化是趋势, 只会做手动测试的人,以后肯定会失去竞争力。

 

 

自动化测试的技术和开发用到的技术相差太远

以前很多同事想由测试转开发,现在几年过去了,还是没转成,他们原先想利用自动化测试的技术积累,转去做开发。哪知道自动化测试用到的技术跟开发用到的技术相比,实在是相差太远。

测试转开发? 难

努力学习编码,然后用于测试,才是正道

做测试最郁闷的是无法听懂开发人员讨论技术

有时候跟开发人员一起开会, 会议上开发人员都热烈讨论。 而我做为测试人员基本上听不懂这群开发在说什么,根本插不上话。 很多会议我甚至都没说过一句话。

 

 

优秀的测试人员非常稀少

想把测试做好非常不容易, 优秀的测试人员需要很广的知识面,良好的沟通能力(不但要和开发人员和项目经理打交道,还要跟其他组的人交流)。  丰富的测试经验,对测试工作有极大的热情, 耐心。还需要测试人员有丰富的业务知识,还要会写代码。

代码写得好的人,肯定就不会做测试,而是做开发去了。

 

 

大部分的测试经理都是有开发背景的

我发现我的几任上司都是由开发转来做测试的。 他们都是有几年的开发经验,然后不知道什么原因转行做测试经理了。他们既能开发又能测试,啥都会,能给手下的测试人员提供技术支持。

假如一个测试经理啥技术都不懂,对内hold不住手下的人,对外其他组的人不鸟你。

 

 

软件测试的确非常枯燥,需要花费大量精力

不可否认测试工作需要耗费大量的精力,所以欧美才会把大量的测试职位外包给中国, 一遍又一遍的重复测试,不停地执行测试用例, 测得天昏地暗, 头发晕。

我还记得我以前测试过一个程序的各个版本在Windows update中的升级,  先安装老版本的程序,然后Windows update 重启后看看有没有升级,最后卸载。 然后又安装,又卸载。最后测的差点吐血。

 

 

英语是测试人员的救命稻草

技术上已经不如开发了。 在英语上一定占有一些优势。

同等的技术水平下,英语好的测试人员可以进外企,比一个英语不好的测试人员的待遇要高不少。

 

 

尽量少用UI自动化测试,多使用单元测试,接口测试

能找到bug的自动化测试,才是有用的,否则就是个噱头

UI自动化测试比较不稳定,对于测试结果的分析也困难。 而且UI改动也大。 所以应该尽量多做一些底层的的自动化测试,比如ASP.NET MVC 中UI和逻辑分开了,针对逻辑的自动化测试就比较好做了。

 

转载:http://www.cnblogs.com/TankXiao/archive/2012/08/27/2576962.html

2015-01-29 09:09:00 weixin_30263277 阅读数 11
  • 机器学习实战训练--业务实践之路

    本系列课程为您讲述如何使用机器学习算法解决业务问题,会以实际业务作为出发点,所有实验都提供实验流程以及实验数据,帮您用短的时间学习机器学习的原理与使用方法。充分理解如何在业务问题上是同数据挖掘。

    10294 人正在学习 去看看 李博

细说软件产品和业务& 业务过程(流程) & 业务逻辑

 

by:授客 QQ1033553122

 

作为一名测试人猿,需要懂产品,不懂产品的测试猿不是好测试猿猴。而业务逻辑是软件产品的支柱,所以,要懂产品,就必须懂业务逻辑。

 

介绍业务逻辑之前,先介绍下相关的一些概念。

什么叫业务?

从企业的角度来讲,业务是企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务,并以此为企业带来利益的行为。

举例:

对服装企业来说,业务一般是生产服装;对银行企业来说,业务可以是办理贷款;对软件公司来说,业务可以是开发某种类型的软件,比如开发防火墙软件;对医院来说,业务可以是提供医疗服务。

 

什么叫业务过程?

“业务流程”和“业务过程”是两个经常出现的词,含义相似,但有轻微区别,这里暂且不做区分,都统一叫做业务过程。

 

1)业务过程开始于客户需求,终止于客户需求的满足,为客户创造价值。

 

2)业务过程是为了产生产品或服务而设计的一系列步骤,一些过程的结果可能是由组织外的客户所接受的产品或服务,称为主要过程;另一些过程的产出不为外部客户所见,但是有效管理所必须的,称为支持过程。

 

举例:

业务过程,对于服装工厂来说,可以是产出可穿戴衣物的一系列活动;对医院来说,可以是提供医疗服务的一系列活动;对软件公司来说,可以是开发出满足客户需求的软件产品的一系列活动。

 

软件产品和业务过程

软件产品具有它的特殊性,通常情况下,企业提供的软件产品、服务,主要用于外部组织、用户实现其业务过程。

举例:

假设有两家公司,A公司和B公司。A公司的业务是提供医疗服务;B公司是开发医疗相关的软件。A公司找到B公司说,我需要你们帮忙开发一个系统,实现XXX功能。这时,B公司考虑的不仅是自己的业务过程:产品,设计,测试,开发,运维等怎么配合去做这件事情,而且还要考虑A公司的业务过程:病人挂号,就诊,住院,缴费结算等等。

 

什么是业务逻辑?

业务逻辑是系统架构中体现核心价值的部分,典型的三层结构模型中(如下图),介于表现层和数据访问层之间。

 

 

 



通俗的讲,业务逻辑就是个“怎么做”的问题,是产品的灵魂,它的关注点主要集中在业务流程的实现,业务规则的定制等与业务过程相关的。

 

细说业务逻辑

1.业务实体

2.业务实体完整性约束

3.业务流程(业务过程)

4.业务规则

 

业务实体

关键业务相关的动态的概念性对象

比如,电商企业,业务过程中的买家,商品,就是业务实体,软件实现过程中先将其抽象为概念模型(通常用E-R图表示),然后对其建立结构模型,展现在计算机世界中,可能表现为买家表中或商品表中的一条表记录。

 

实体业务完整性约束(Validation

业务实体完整性约束简单说就是对业务实体的约束,比如对商品实体,商品编号必须唯一

 

注:关于业务实体和业务实体完整性约束,可以看下数据库的相关资料,理解会比较深刻一点

业务流程(业务过程)

如果把产品比作一个人,那么这个业务过程就是产品的骨架。产品只有实现了这个流程,用户才能用它来实现业务。

例子:购物网站为例子

购买者登录网站 -> 浏览商品 ->下单 -> 结算 -> 确认收货 -> 评价

 

例:以学校申请助学金为例子

学生登陆终端 -> 提交申请 -> 班主任审批 -> 分院负责人审批 -> 学工处审批 -> 资领处审批

 

业务规则

定义1:业务规则是与特定行业中的特定业务功能有关的决策逻辑的表示形式

定义2:业务规则是对业务的某些方面进行定义和约束的声明

1:以学校申请助学金为例子

“申请助学金的学生必须是贫困生”,这便是一条业务规则,对申请助学金的做了一个前提申明。

那又为何说是决策逻辑呢?程序中,实现经常会这样:

if 学生 is not 平困生

then 拒绝申请

 

2:以购物网站为例子

未登录顾客点击购买商品时,提示先登录

 

3:以购物网站为例子

买家下单后,通知卖家商品被拍下。

 

从上面的例子可以看出,业务规则它不会告诉你怎么做,仅是“决策”,告诉你要做什么,而不会告诉你怎么做。比如,上面的贫困生的例子,它不会告诉你怎么申请贫困生,但是会告诉你要去申请贫困生,再如,上面购物网站的例子,它约定说要去通知卖家,但是不会告诉你怎么通知卖家(通过邮件、电话、短信还是其它??)

 

小知识点:

一般做系统,都避免不了数据验证,完整性约束是业务逻辑的一部分,按理应该放在业务层。但是实际不然,不提倡在表示层的服务端放置过多完整性验证。因为,表示层的职责应该仅仅是接收数据并传递给业务层,不应对数据是否合法负责。过多的数据验证,不但令表示层代码臃肿,而且使得表示层职责变得不明确。

可以在表示层的服务端放置一些简单的验证,如空值验证,两次输入密码是否一致等,但业务关系紧密的验证,最好放在业务层,甚至有些验证只能在业务层验证,如当前用户名不能与已有用户名重复,这种验证需要访问持久化数据,需要由业务层完成。

这里之所以强调表示层的服务端,是因为一般在B/S系统中,都会在JavaScript里加入一些基本的数据验证,如空值检查,格式正则匹配 等。这主要是为了减轻服务器负担,将大多数显然包含不合法数据的请求拒绝掉,而不发给服务端验证。当然,因为可能会出现JS被屏蔽或黑客恶意攻击行为,所以,所有验证不论JS中是否验证过,服务端(可能是表示层的服务端部分或业务层)一定要再进行验证。

 

转载于:https://www.cnblogs.com/shouke/p/10157915.html

没有更多推荐了,返回首页