- 浏览: 7847059 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (2425)
- 软件工程 (75)
- JAVA相关 (662)
- ajax/web相关 (351)
- 数据库相关/oracle (218)
- PHP (147)
- UNIX/LINUX/FREEBSD/solaris (118)
- 音乐探讨 (1)
- 闲话 (11)
- 网络安全等 (21)
- .NET (153)
- ROR和GOG (10)
- [网站分类]4.其他技术区 (181)
- 算法等 (7)
- [随笔分类]SOA (8)
- 收藏区 (71)
- 金融证券 (4)
- [网站分类]5.企业信息化 (3)
- c&c++学习 (1)
- 读书区 (11)
- 其它 (10)
- 收藏夹 (1)
- 设计模式 (1)
- FLEX (14)
- Android (98)
- 软件工程心理学系列 (4)
- HTML5 (6)
- C/C++ (0)
- 数据结构 (0)
- 书评 (3)
- python (17)
- NOSQL (10)
- MYSQL (85)
- java之各类测试 (18)
- nodejs (1)
- JAVA (1)
- neo4j (3)
- VUE (4)
- docker相关 (1)
最新评论
-
xiaobadi:
jacky~~~~~~~~~
推荐两个不错的mybatis GUI生成工具 -
masuweng:
(转)JAVA获得机器码的实现 -
albert0707:
有些扩展名为null
java 7中可以判断文件的contenttype了 -
albert0707:
非常感谢!!!!!!!!!
java 7中可以判断文件的contenttype了 -
zhangle:
https://zhuban.me竹板共享 - 高效便捷的文档 ...
一个不错的网络白板工具
http://www.searchtb.com/2011/03/good_test_cases.html
测试工程师有一样很重要的工作就编写测试用例。测试用例是对需求的另一种描述,它能引导大家进一步加深对系统的理解和对特性的全面关注,从而帮助产品和开发重新审核需求的合理性和一致性,所以应该是测试工程师最重要的一项产出。一般的测试用例分为输入,行为,和希望结果三个部分。这三个部分通常的测试用例都能满足,但是怎样的测试用例才能算上优秀的测试用例呢?基于以往之测试经验,我总结了优秀测试用例的几个特点。
1:正确性:毫无疑问,测试用例必须是需求的正确描述。但是我们往往忘记了多想一步:这是用户正确需要的吗?我曾经有个一个失败的testcase,当一个条件输入异常的时候系统返回-1给前端接口,然后前端返回错误信息,这是当时对异常的处理需求,可是如果多想一步,当一个条件异常的时候难道我们不能返回满足部分条件的结果给用户吗?让用户的体验更加良好吗?
2:完整性:就测试用例本身而言,是无穷尽的,只要是键盘的任意组合都可以算作测试用例。而一个优秀的测试工程师就是从无穷中找到最能保证质量,最能发现bug的测试用例出来,发现无穷的最小集,通常功能测试用例的找寻方法有等价类和边界值是最简单的方法,建议结合使用,先划分等价类,再把等价类中的边界值找出来。我见过很多在=和>=之间徘徊的bug。正交法出来的用例一般太多,所以需要测试工程师在正交法的结果中再做组合,建议结合错误定位法减少用例的执行。状态图在数据统计,结算中的使用概率最高。每个状态和流程都需要一一考虑正常和异常的分支,正常的流程一个靠谱的开发能自己保证,但是异常的分支很少有开发考虑清楚,这就是体现测试工程师价值的地方了。但是完整性绝不仅仅是功能测试,除了功能测试之外,常见的还有性能测试,安全测试,兼容性测试,安装友好测试,地域语言测试和用户体验测试(usability)。
3:输入具体:对于这三个部分我们都希望它是固定的,具体的,比如输入框的输入,我们可以写成具体“诺基亚”,但是不要写“正确的输入”,或者“中文的输入”,这些都会导致测试用例的不确定性。模糊的输入应该在具体输入的上一级结构,作为测试的思路和分类使用。
4:用词无歧义:很多词在不同场景会有不同的含义,比如价格一词在不同的表中就代表不同的价格,甚至在同一表中也有原始价格和卖出价格,所以应该尽量具体的描述关键词的具体信息,如果能贴上专用的id和原始表中的item会对避免歧义有很大的帮助。
5:用例细化:输入的一种组合,或者一条流程线对应一个测试用例,尽量不要在一个用例中融和多种情况,在自动化测试的脚本中为了提高效率我们会在一个自动化脚本中融入各种情况的输入,然后一个动作,所有的输出一次生成,针对这种情况,建议在脚本中对各种输入对应的案例一一备注说明,运行失败的时候也方便新人定位问题。
6:判断点准确无歧义:我经常看到这样的检查点:“结果正确”,“速度合理”,这些检查点对其他人没有丝毫的帮助。所以应该尽量做出让机器也能识别的检查点,比如输出“8”,或者“rt<30m”。
7:合理区分优先级:在Bugfree中有4个级别的优先级,从1到4,1表示最重要的测试用例,4表示最不重要的测试用例。不同的缺陷管理平台对优先级的定义会有不同,但是都会有优先级的概念。在时间紧张的情况下,优先级的作用会特别大,我们会优先执行比较重要,对系统功能,用户体验影响大的测试用例,将级别比较低的测试用例留在后期或者指派给一些新人来执行。
加分点:
1:用例自动化:有自动化脚本的地址能够一一对应,对于淘宝的bugfree就已经和自动化框架mmt打通,通过测试用例可以直接链接到脚本,方便对用例的理解。
2:记录每轮的测试结果:对于有些功能的测试用例,结果只是简单的pass我们不需要记录,但是对于性能测试这些结果不确定的测试用例,如果能保留每次测试的结果对于之后的测试是很有帮助的。对于fail的部分用例,如果能和bug产生一一对应关系对之后的回归也产生很大的便利。
3:对检查点进行逻辑说明:很多用例有了结果的检查点,但是为什么是这个结果,对于新人来说必须重新翻看需求或者设计文档才能理解。尤其对于算法的测试,理解需求和逻辑是一个比较痛苦的过程,如果能够对每个结果进行一些备注和逻辑上的说明,会和方便自己今后以及新人对用例的理解。
以上是对测试用例特性的一些总结,真正编写测试用例的时候,mm图由上到下的树形结构会对测试用例的结构和思路提供很大的帮助,在测试用例评审的时候也方便展示和说明,所以强烈推荐作为附件上传。而且对系统越加深入的了解越能写出完善的测试用例,很多开发错误的理解测试工程师只需要知道需求就可以了,不需要对程序有代码级别的了解,但是无数的实践证明测试工程师越了解系统的设计,编码的逻辑越能发现潜在的bug和风险。Unit test通常由开发完成比较高效,但是Integration Test开始就必须有测试工程师开始真正介入,这期间能发现很多潜在的问题,如果把风险全部留到System Test的阶段风险是很大的,大量case的回归和问题的定位都会变得更加复杂,成本更加的巨大。所以在时间允许的情况下毫无疑问是前期的测试越完善整体效率越高
测试工程师有一样很重要的工作就编写测试用例。测试用例是对需求的另一种描述,它能引导大家进一步加深对系统的理解和对特性的全面关注,从而帮助产品和开发重新审核需求的合理性和一致性,所以应该是测试工程师最重要的一项产出。一般的测试用例分为输入,行为,和希望结果三个部分。这三个部分通常的测试用例都能满足,但是怎样的测试用例才能算上优秀的测试用例呢?基于以往之测试经验,我总结了优秀测试用例的几个特点。
1:正确性:毫无疑问,测试用例必须是需求的正确描述。但是我们往往忘记了多想一步:这是用户正确需要的吗?我曾经有个一个失败的testcase,当一个条件输入异常的时候系统返回-1给前端接口,然后前端返回错误信息,这是当时对异常的处理需求,可是如果多想一步,当一个条件异常的时候难道我们不能返回满足部分条件的结果给用户吗?让用户的体验更加良好吗?
2:完整性:就测试用例本身而言,是无穷尽的,只要是键盘的任意组合都可以算作测试用例。而一个优秀的测试工程师就是从无穷中找到最能保证质量,最能发现bug的测试用例出来,发现无穷的最小集,通常功能测试用例的找寻方法有等价类和边界值是最简单的方法,建议结合使用,先划分等价类,再把等价类中的边界值找出来。我见过很多在=和>=之间徘徊的bug。正交法出来的用例一般太多,所以需要测试工程师在正交法的结果中再做组合,建议结合错误定位法减少用例的执行。状态图在数据统计,结算中的使用概率最高。每个状态和流程都需要一一考虑正常和异常的分支,正常的流程一个靠谱的开发能自己保证,但是异常的分支很少有开发考虑清楚,这就是体现测试工程师价值的地方了。但是完整性绝不仅仅是功能测试,除了功能测试之外,常见的还有性能测试,安全测试,兼容性测试,安装友好测试,地域语言测试和用户体验测试(usability)。
3:输入具体:对于这三个部分我们都希望它是固定的,具体的,比如输入框的输入,我们可以写成具体“诺基亚”,但是不要写“正确的输入”,或者“中文的输入”,这些都会导致测试用例的不确定性。模糊的输入应该在具体输入的上一级结构,作为测试的思路和分类使用。
4:用词无歧义:很多词在不同场景会有不同的含义,比如价格一词在不同的表中就代表不同的价格,甚至在同一表中也有原始价格和卖出价格,所以应该尽量具体的描述关键词的具体信息,如果能贴上专用的id和原始表中的item会对避免歧义有很大的帮助。
5:用例细化:输入的一种组合,或者一条流程线对应一个测试用例,尽量不要在一个用例中融和多种情况,在自动化测试的脚本中为了提高效率我们会在一个自动化脚本中融入各种情况的输入,然后一个动作,所有的输出一次生成,针对这种情况,建议在脚本中对各种输入对应的案例一一备注说明,运行失败的时候也方便新人定位问题。
6:判断点准确无歧义:我经常看到这样的检查点:“结果正确”,“速度合理”,这些检查点对其他人没有丝毫的帮助。所以应该尽量做出让机器也能识别的检查点,比如输出“8”,或者“rt<30m”。
7:合理区分优先级:在Bugfree中有4个级别的优先级,从1到4,1表示最重要的测试用例,4表示最不重要的测试用例。不同的缺陷管理平台对优先级的定义会有不同,但是都会有优先级的概念。在时间紧张的情况下,优先级的作用会特别大,我们会优先执行比较重要,对系统功能,用户体验影响大的测试用例,将级别比较低的测试用例留在后期或者指派给一些新人来执行。
加分点:
1:用例自动化:有自动化脚本的地址能够一一对应,对于淘宝的bugfree就已经和自动化框架mmt打通,通过测试用例可以直接链接到脚本,方便对用例的理解。
2:记录每轮的测试结果:对于有些功能的测试用例,结果只是简单的pass我们不需要记录,但是对于性能测试这些结果不确定的测试用例,如果能保留每次测试的结果对于之后的测试是很有帮助的。对于fail的部分用例,如果能和bug产生一一对应关系对之后的回归也产生很大的便利。
3:对检查点进行逻辑说明:很多用例有了结果的检查点,但是为什么是这个结果,对于新人来说必须重新翻看需求或者设计文档才能理解。尤其对于算法的测试,理解需求和逻辑是一个比较痛苦的过程,如果能够对每个结果进行一些备注和逻辑上的说明,会和方便自己今后以及新人对用例的理解。
以上是对测试用例特性的一些总结,真正编写测试用例的时候,mm图由上到下的树形结构会对测试用例的结构和思路提供很大的帮助,在测试用例评审的时候也方便展示和说明,所以强烈推荐作为附件上传。而且对系统越加深入的了解越能写出完善的测试用例,很多开发错误的理解测试工程师只需要知道需求就可以了,不需要对程序有代码级别的了解,但是无数的实践证明测试工程师越了解系统的设计,编码的逻辑越能发现潜在的bug和风险。Unit test通常由开发完成比较高效,但是Integration Test开始就必须有测试工程师开始真正介入,这期间能发现很多潜在的问题,如果把风险全部留到System Test的阶段风险是很大的,大量case的回归和问题的定位都会变得更加复杂,成本更加的巨大。所以在时间允许的情况下毫无疑问是前期的测试越完善整体效率越高
发表评论
-
ISO/IEC9126中软件质量品质小结
2019-02-03 08:00 1405ISO9126软件质量模型,是评价软件质量的国际标准。6个特性 ... -
管理学中的瓜子理论
2018-11-06 16:58 1443管理学中有一个“瓜子 ... -
起点学院的产品经理资料合集
2018-09-04 16:38 3576链接:https://pan.baidu.com/s/1dvM ... -
每日站会的注意点
2018-06-22 21:00 437https://www.uperform.cn/what-to ... -
敏捷中开发中的承诺解析
2018-06-16 10:05 553敏捷中的 promise 和 从com ... -
一页纸项目管理图书和简单模板
2018-06-13 08:27 2723之前听了个讲座,是提到老美的一页纸项目管理,看了下简单易懂,用 ... -
精益画布和商业模式画布
2018-05-16 22:05 29801 商业模式画布,关心的: 1) 重要伙伴 2)关 ... -
(转载)公开,公正,公平,区块链的试金石
2018-02-03 23:39 570https://mp.weixin.qq.com/s/VFz4 ... -
(转)Kano模型:一种产品经理适用的方法论
2017-10-31 23:02 627Kano 模型是狩野纪昭教授发明的对用户需求分类和优先排序的一 ... -
来自腾讯设计师的一篇不错的文章
2017-10-11 11:15 418来自腾讯设计师的一篇不错的文章 《服务设计思维》 https: ... -
走近比特币:一个故事看懂“区块链”
2017-07-08 09:20 495(转),不错的科普文 http://www.4hou.com/ ... -
来自美团的测试模版
2016-05-01 08:44 1099来自美团的测试模版,从各个方面给了不错的范例, 适合中小团队快 ... -
如何对待用户的意见
2014-12-20 19:36 850如何对待用户的意见? 1 根据目标用户考虑,提出要求的用户 ... -
sonarqube笔记之--代码注释行的量度
2014-02-13 14:25 7997在sonarqube中,关于文档方面的度量有以下方面: ... -
sonarqube 笔记1
2014-02-08 14:49 1358sonarqube 笔记1 sonarqube中,对于代码 ... -
高内聚中的LCOM4指标衡量
2013-12-15 11:13 2285经常说的软件“低耦合,高内聚”,哪么如何衡量高内聚呢?其实原来 ... -
一个不错的网络白板工具
2013-05-24 18:46 5847一个不错的网络白板工具http://t.cn/zHqoPT4, ... -
电梯演讲展示产品优势特点
2012-12-29 09:31 1702电梯演讲,其实核心是在短短的时间中,向风险投资人或客户介 ... -
搞IT的就要多交流,国内技术大会小结
2012-06-15 12:40 2搞IT的就要多交流,这个应该成为大家的共同认识,比如国内目前有 ... -
收藏一个结队编程的好工具
2012-05-05 21:06 1307http://xpairtise.sourceforge.ne ...
相关推荐
测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例测试用例示例
对于测试工程师而言,一个优秀的测试用例资源合集就像是一把锋利的剑,能够助力他们披荆斩棘,高效地完成测试任务。这份合集不仅包含了丰富多样的测试用例,还提供了清晰的测试步骤和预期结果,使得测试工作更加系统...
如果问测试工程师测试用例如何编写,就好象是问程序员如何编写代码一样,每个人都会给出不同的方法,但是实用的测试用例却象优秀的程序一样困难。 本章针对上面的问题,主要讲解在企业实际工作中,如何有效...
一个优秀的测试用例,应该包含以下信息: 1 ) 软件或项目的名称 2 ) 软件或项目的版本(内部版本号) 3 ) 功能模块名 4 ) 测试用例的简单描述,即该用例执行的目的或方法 5 ) 测试用例的参考信息(便于跟踪和...
如果问测试工程师测试用例如何编写,就好象是问程序员如何编写代码一样,每个人都会给出不同的方法,但是实用的测试用例却象优秀的程序一样困难。 本章针对上面的问题,主要讲解在企业实际工作中,如何有效划分测试...
如果问测试工程师测试用例如何编写,就好象是问程序员如何编写代码一样,每个人都会给出不同的方法,但是实用的测试用例却象优秀的程序一样困难。 本章针对上面的问题,主要讲解在企业实际工作中,如何有效划分测试...
如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。 目前国内,测试工程师却时常要面对“已经延期几倍...
第-章-软件自动测试和测试用例生成优秀文档.ppt
设计登录Web登录界面测试用例设计软件测试1、一个好的用例的表述要点,即用例中应当包含的信息一个优秀的测试用例,应该包含以下信息:1)软件或项目的名称2)软件或项目的版本(内部版本号)3)功能模块名4)测试用例的...
集成测试用例的模板,设计方法,本资源主要介绍了如何设计一个优秀的单元测试用例
但没有一个测试用例在任何方面都很优秀。人们软件测试中如何来评价一个测试用例是好的设计好的测试用例是一门复杂的艺术。其复杂性有三个原因:测试用例能帮我们发现信息。不同类型的测试对不同类型的信息有效。可以...
第-章-软件测试用例的设计优秀文档.ppt
一大早,一个年轻的程序员问大师:“我准备写一些单元测试用例。代码覆盖率应该达到多少为好?”大师回答道:“不要考虑代码覆盖率,只要写出一些好的测试用例即可。” 一大早,一个年轻的程序员问大师: “我准备...
详细的叙述了设计测试用例时所需要了解的知识,以便能写出优秀的测试用例。
如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。目前国内,测试工程师却时常要面对“已经延期几倍计划...
软件测试中如何设计编制软件测试用例一、测试用例是软件测试的核心软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司...
一、测试用例是软件测试的核心 软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或...
火龙果软件工程技术中心 篇首语本文假设读者已经熟悉单元测试及JUnit工具的使用,如果对单元测试及JUnit尚不了解请先学习单元测试及...纵览网上流行的优秀开源框架,无一不提供完整的单元测试用例。Spring框架便是
测试工作也从简单测试演变为包括:编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之,并有向第三方专业测试公司...