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博客 | 首页 | 发新随笔 | 发新文章 | 联系 | 聚合 | 管理

软件测试常见问题种种

【摘要】软件测试看似简单,但真正做好并不容易,其实任何工作都是如此。本文就软件测试中常见问题进行归纳总结,并就有关问题谈下个人观点。

【关键词】软件测试、bug

关于概率性问题

软件测试中常见的一个问题就是概率性问题,概率性问题无论对软件测试人员还是对开发人员而言都是比较头疼的一个问题。这种概率性问题在测试中该如何处理呢?

首先,概率性问题也是问题,这种我们千万不能一笑而过,在这种情况下测试人员要将这些问题记录下来,多做测试,看能否找出问题产生的规律。

其次,我们要对所出现的问题进行评估,看这种问题的严重性,如果是比较轻微的问题,对用户使用没什么影响,也不会影响到软件其他方面正常工作,那在这种情况下如果开发人员很随手就可修改的话,那就进行修改;如果修该起来耗时耗力的话,则可征得有关人员同意后进行keep.

再者,对于比较严重的概率性问题,如死机、系统崩溃等情况,在记录下问题的同时要及时通知相关开发人员,测试人员和开发人员商量解决如何再现并最终解决问题。对于这样的问题一定不能放过,记得以前在给佳能做传真机测试的时候,遇到一个出现系统自动重起的问题,结果为了抓这个问题,几个测试人员专门盯着这个问题反复的测试,为了这个问题整整测了一个星期,好在问题最后得一解决。

第四,有些问题用语言文字描述可能很难描述清楚,对于这样的问题,测试人员再进行描述的时候,有条件的话可以抓图和提供测试log.当然,如果有再现的话,最好通知开发人员,让开发人员确认问题的现象,毕竟百闻不如一见!

第五,概率性问题产生的原因可能是累积性问题,是一系列复杂操作引起的,而有些可能是时间点的问题,只有在某个瞬间进行操作才能出现,过了那个时间点进行操作时就不会出现问题,这样的问题测试人员在测试时和记录时都要注意采取合适的测试策略。

本文转载自51testing软件测试网,查看全文:

http://www.51testing.com/html/94/n-6694.html

posted @ 2010-08-13 13:19 51testing 阅读(132) | 评论 (0) | 编辑 收藏
 
软件测试工程师的视野
    HR告诉我们要把个人的活动同公司的商业目标对齐。这句话说起来显得“假大空”,其实呢对我们软件测试工程师来说真正是有意义的。关键我们要理解,如何对齐,在哪些方面对齐。

  对一名负责任的软件工程师来说,很自 然,眼光盯在软件测试上,想得是如何测试更全面,更有效率,发现更多的bug,这没有问题,也是必须的。但这还不够,我们还要把眼光放得更远一点。从我现 在的理解来说,我觉得软件工程师的视野有这样三个层次

  1、软件测试:测试技术,方法,设计testcase的思想,方法,bug数 量......

  2、质量保证:缺陷趋势,测试过程,测试组合,测试效率......

  3、成功的产品:用户愿不愿意买 单,能不能及时抢占市场,和竞争对手的比较,哪些缺陷是可以接受的......


本文选自51Testing软件测试网

查看全文:http://www.51testing.com/html/08/n-218208.html

posted @ 2010-08-09 13:27 51testing 阅读(78) | 评论 (0) | 编辑 收藏
 
软件测试园地

• 软件测试自动化的概念

软件测试自动化,是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来,专心从事有意义的测试设计等活动。如果采用自动比较技术,还可以自动完成测试用例执行结果的判断,从而避免人工比对存在的疏漏问题。设计良好的自动化测试,在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下,软件测试自动化可以减少开支,增加有限时间内可执行的测试,在执行相同数量测试时节约测试时间。

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具,可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成,但通常的工作方式为人工设计测试用例,使用工具进行用例的执行和比较。

软件测试自动化的设计并不能由工具来完成,必须由测试人员进行手工设计,但是在设计是却必须考虑自动化的特殊要求,否则无法实现利用工具进行用例的自动执行。为此,就必须在测试的设计和内容的组织方面采取一些特殊的方法。

对于软件测试自动化的工作,大多数人都认为是一件非常容易的事。其实,软件测试自动化的工作量非常大,而且也并不是在任何情况下都适用,同时软件测试自动化的设计并不比程序设计简单。

• 自动化测试的优点

通过自动化测试,可以使某些任务提高执行效率。除此之外,还有其它优点:

①对程序的回归测试更方便。这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的。由于回归测试的动作和用例是完全设计好的,测试期望的结果也是完全可以预料的,将回归测试自动运行,可以极大提高测试效率,缩短回归测试时间。

............

全文链接:http://www.51testing.com/html/20/n-6520.html
posted @ 2010-08-04 15:25 51testing 阅读(121) | 评论 (0) | 编辑 收藏
 
软件测试概论
  软件测试是任何一种旨在评价一个程序和系统的属性和能力的活动,以及判定程序或系统是否满足了所要求的结果。尽管测试对于软件质量是很关键的,且被程序员和测试工程师广泛使用,但是软件测试仍然还是一种艺术,其原因还是对于软件原理的理解有限。软件的测试的难处来自于软件的复杂性:我们甚至不能对一个中等复杂程度的程序进行完整的测试。测试不只是排错(debugging)。测试的目的可以是质量保证,验证和确认,或者可靠性估计。测试也可以用来作为通用的度量数据。纠错测试和可靠性测试是测试的两个主要方式。软件测试在预算、时间和质量要求上取得平衡。

  一、概述

  软件测试是这样的一个过程,它执行一个程序或一个系统,目的是发现错误。或者,它包括这样一些活动,只要这些活动是评价一个程序(或系统)的属性和能力、以决定程序或系统是否满足了要求。软件和物理加工不一样,物理加工接受了输入,就产生输出。软件不一样的地方在于它的失效方式不同。绝大部分物理系统以固定(通常比较少)的方式失效。然而,软件却有多种奇异的失效方式。检测所有的失效模式,通常是行不通的。

  和大多数物理系统不同,软件中的大部分缺陷是设计的错误,不是制造上的缺陷。软件不会用坏,也不会磨损—一般地说,若不升级和退市,它就不会改变。所以,软件一旦发布了,设计上的缺陷或者叫bug就会埋入到软件之中并一直留在那里,直到有一天它会被触发而发作。

  在一个中等大小的软件模块里,软件的bugs几乎总是存在的。这不是因为程序员的粗心和不负责任,而是因为软件的复杂性通常是不可处理的,人管理复杂性的能力是有限的。还有一点,对应复杂系统,设计的缺陷是不可能根除的。

  全文链接:http://www.51testing.com/html/54/n-217754.html
posted @ 2010-07-29 09:20 51testing 阅读(172) | 评论 (0) | 编辑 收藏
 
软件测试者的基本要求
  软件开发者和软件测试者对软件测试往往有着完全不同的立场。前者希望软件测试成为表明软件产品中不存在错误的过程,验证该软件已正确的实现了用户的需求,确立人们对软件质量的信心;后者则是从用户的角度出发,希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑最终用户是否可以接受该产品。

  因此,在软件测试过程中,测试者务必要注意以下几点:

  1.测试者不可以是开发者本人,也就是说开发者不应参与设计和执行测试。开发者的测试往往是用来证明软件的正确性的,违背了软件测试的目标。

  2.要始终相信bug一定存在。即使开发者跟你承诺提交的是一个完美的版本,不会有任何问题。因为,现实中的完美是不存在的,同样完美的软件也不存在。任何时候都不能因为开发者的话语而放松对bug的警惕。

  3.在时间和精力允许的情况下,任何时候不要停止测试。不要在发现了很多bug以后很有成就感,觉得不会再有其他bug出现了,就停止测试,这个时候更应该分析bug出现的规律,总结自己的测试结果,更进一步的去发现更深层次的bug。

  本文转载自51Testing软件测试网:http://www.51testing.com/html/70/n-133270.html
posted @ 2010-07-20 10:04 51testing 阅读(151) | 评论 (0) | 编辑 收藏
 
软件测试,是成本还是投资?

  很多的软件公司都认为软件测试很重要,但基本上国内大部分的软件公司都只是象征性的请一到两个软件测试人员负责所有项目的测试。因为影响软件测试的因素太多了,时间限制、资源短缺、预算不足等等。于是就开始来减少软件测试的投入了。那么我们不禁要问一句,软件测试到底是成本花费呢,还是一种长期的软件投资呢?

  一、引言

  随着软件市场的成熟,人们对软件作用期望值也越来越高,软件的质量、性能、可靠性等方面也正逐渐成为人们关注的焦点。目前,中国软件产业在产品功能和性能测试领域都存在着严重不足,中国软件企业已开始认识到,软件测试的广度和深度决定了中国软件企业的前途命运。

  软件测试并非传统意义上产品交付前单一的“找错”过程,而是贯穿于软件过程的始终,是一个科学的质量控制过程。国外成熟软件企业,1个软件开发工程师对应1-2个软件测试工程师,而国内软件企业,平均8个软件开发工程师才对应1个软件测试工程师,比例严重失衡。

链接地址:http://www.51testing.com/html/20/n-70620.html

posted @ 2010-07-08 10:25 51testing 阅读(159) | 评论 (0) | 编辑 收藏
 
请不要把测试工具当饭吃

近年几年,无论是行业聚会还是猎头招人。无不体现着这一理念,软件测试工作越发被机械化Coding化,很多企业招人时也不乏喜欢给自己的软件测试人员提些要求QTP/Loadrunner/Winrunner/RTF/Rebot一系列软件测试工具被列入正规、精益的代名词。于是我们投入了大量人力物力来实现我们心中挥之不去的理想与抱负,每日Build成了很多软件测试经理追求的梦想。

加之软件测试行业领袖们的吹捧,行业新兵薪水的大幅提升,一些不明真相的人们正大步迈入这个陷阱。我们做软件测试工具开发、软件测试工具应用,根本的意义是提升工作效率,降低产品成本,提升团队的核心竞争力。从目前行业来看,很多用人单位和培训机构鼓励大批新入职的软件测试人员走向测试开发、自动化职业生涯。我们先不论报酬薪资,单从这种不负责任的态度与做事方式来讲,个人觉得这些是不利于新人成长。

一个入门的软件测试人员,他应该先做好本职工作,充分了解系统,充分了解需求,能为后续产品提出新的价值关联,能知晓其它同类产品的特点,本套产品的优势,架构特点等等问题。软件测试工具并不是解决问题的唯一办法,根据产品的测试策略、测试需求很多产品都不能完全按照第三工具的标准进行开发,这也是中国目前的现状。你需要短期内,毫无计划的提需求,解决这些历史问题也是及不现实的。我们能做的是,给新人更宽的思路,更灵活的思维方式,让他们从工具中受益。而不是盲目的使用工具,把一件事变的更复杂。我们提倡的是效率,提倡的是工作效率,并不是代步工作。

请不要把软件测试工具当饭吃,而是真正理解测试工具的思维方式和软件测试方法。在某种层面来说,只有每一个员工、一个团队乃至一个部门,对这种思想有了充分理解的时候。真正意义上的高效才能体现。流程、工具无非只是我们改进工作过程的一种手段,而不是吃饭的家伙。请正视自己的职业,不要把软件测试工具当饭吃。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/74/n-96974.html

posted @ 2010-06-28 11:16 51testing 阅读(121) | 评论 (0) | 编辑 收藏
 
软件测试组成

软件测试工作可以分为六个方面:

* 软件测试组织和管理:建立软件测试队伍,设计不同功能或完全不同任务的测试小组,对测试用例,软件缺陷,测试执行,软件测试文档等进行管理,当然,也可以把它看作是软件质量管理的一部分。

* 软件测试计划:独立的测试组织负责定义软件测试的方法与规范。开发组织负责编写单元测试计划和说明。测试组织主要负责编制其他各测试阶段的测试计划和说明。

* 设计测试用例:为了更有效进行测试,需要设计测试用例。

* 测试实施:按测试计划与测试说明的定义对测试对象进行相应的测试,填写测试报告中相应的表格。

* 测试结果分析:对测试结果进行定量和定性的分析,以检查测试工作执行的状态。

* 测试评审与报告:依据软件测试评审准则在各测试阶段评审时提交类型完整的测试文档。

PDCA模型:

PDCA代表(plan),实施(do),检查(check)和措施(action),

* 计划就是设定可以达到的目标,决定那些事需要完成,那些事可以做到,那些资源可以利用。

* 实施(do):有了计划后,接着就是要去作,以执行计划中一定义的各种任务。

* 检查(check):对所有做的结果进行检查,以确认是否达到预期的结果。做了但不检查结果,就不知道是否按事先制定的计划去执行了,通过检查发现计划或执行的问题。

* 措施(action):如果检查发现错误或执行中的问题,就需要采取纠错的措施,从而在制定下一步计划中有所改善,制定的计划会更切和实际,更合理了。

软件测试也一样,先要制定测试计划,软件测试计划是做好软件测试工作的前提。在做任何软件测试之前,我们应给制定好,良好的,切实可行的测试计划并且要严格的执行,最主要的是确定测试策略和测试目标。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/24/n-170224.html

posted @ 2010-06-22 11:20 51testing 阅读(119) | 评论 (0) | 编辑 收藏
 
软件测试的现状和未来

软件测试是软件工程的重要组成部分,又是软件开发不可或缺的环节。就软件测试的现状和未来问题,软件质量专家,《自动化测试》的作者张瑾先生展开作了描述。

张先生说,软件质量的重要性已经无可非议,但软件测试人员的工作并没有像软件质量一样得到重视和认可。许多企业平时可能认为软件测试人员不是利润的直接创造者,不愿意投入太多精力给予其培训和学习的机会,一旦软件质量出了问题,第一个追究的却是软件测试人员的责任,这是由于企业领导对测试工作的性质不了解所造成的。

当编辑问及张先生为什么会出现这种问题时,张先生说,其实软件测试和软件开发人员没有本质上的区别,只是由于分工不同,侧重点不同而已,软件开发人员有自己的开发平台、开发工具和开发语言,其编写出来的内容称为代码,代码是给客户使用的,是可以为企业创造利润的。软件测试人员也有自己的软件测试平台、软件测试工具和测试类开发语言,其编写出来的内容称为脚本,脚本是给公司内部使用的,是为通过提高企业产品质量来创造利润的。

软件开发人员钻研开发技术,在业务方面,由于设计、编码都是开发人员完成的,因此他们非常熟悉自己负责模块的业务逻辑。软件测试人员则强调的是综合能力,不但要掌握编程技巧,使脚本适应不同情况,而且还要精通软件产品的整体业务流程。软件测试讲究的是覆盖率,因此测试人员需要熟悉整个软件的业务逻辑,在这一点上,张先生认为对软件测试人员的知识与技术要求要高于开发人员。

当编辑问到软件版本更新很快,作为软件测试人员如何体现价值这个问题时,张先生作了精要的回答。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/28/n-95828.html

posted @ 2010-06-03 10:43 51testing 阅读(134) | 评论 (0) | 编辑 收藏
 
为什么选择软件测试

很多人问我为什么会选择“软件测试”作为自己的方向?坦白的讲,刚开始我也不知道。但现在有一些感触,觉得有必要将“软件测试”继续下去。

先说说软件测试的现状吧!

很多公司都会招聘大专生来做测试,测试工作门槛低,谁都能做。软件测试工作,就是别人把软件创造出来后,用一下;或者别人写完代码后,将东西扔过来验证一下,测试人员就是帮着开发人员打打下手。测试工作做好做坏,没有人关心,或者测试人员到底做什么,也没有人关心。

这就是国内大部分公司的现状,也许有些公司说测试要保证产品质量,测试人员很重要。只是口头上说说而已,而从实际行动上,当然是开发第一,测试第n。实际行动有哪些?很多:待遇、测试人员的来源、培训的机会、工作的分工、多方矛盾的化解,等等。

为什么会出现这种现象?

原因之一:软件产品成熟度的问题。记得产品的竞争力分为多个层次:人无我有、人有我优、人优我廉、人廉我转。先保证产品存在,然后谈产品的质量,质量好价格低的产品更畅销,质量好、价格低、服务好是用户追求的目标。以前的软件大多属于形象工程,有就行了。现在越来越多的软件用起来了,质量自然提上了日程。怎无奈,花钱的客户不是使用产品的用户,客户不懂产品质量,但他懂价格,导致的问题就是让开发商拼价格,降低成本。如果有一天,产品的质量对于软件的销售起决定作用的时候,开发商才会想办法提升质量。

原因之二:软件的质量并不完全依赖于测试水平。软件的缺陷是由开发人员引入的,如果少一点引入缺陷,即使没有测试,软件的质量也会很高。这是一个不错的观点。开发人员自身水平的提升对产品质量的影响是第一位的。ok,站在这个角度来讲,测试人员的存在是对产品质量提升的一个补充。

原因之三:测试人员没有争取。测试人员往往在公司的位置较低,同时他们却选择了逆来顺受,听之任之的态度。大多数软件测试人员的水平的确不行,连代码都看不懂,与开发人员根本没有办法交流,当然开发人员瞧不起你。

原因之四:高水平的测试人员都不做测试。水平高了,为了追求好的待遇,转开发了、做管理了,让自己的测试技能浪费了。

那“软件测试”还有救吗?是不是命中注定就是软件开发的“次要角色”?先提一些观点。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/31/n-92531.html

posted @ 2010-05-31 11:21 51testing 阅读(171) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 45 46 47 48 49 50 51 52 53 Last