关于覆盖率,网络上最常见的两个词应该是“测试覆盖率”(Test Coverage)和”代码覆盖率“(Code Coverage)。今天就来探探这两个东西。
在上一篇文章里面我们介绍了测试覆盖率的分类,举例揭示了需求覆盖率,语句覆盖率,分支覆盖率很条件覆盖率这些问题,在这篇文章里面,则主要介绍为什么要千方百计来找“测试覆盖率”。(关于上一篇文章,参见测试覆盖率之一——测试覆盖率分类)
1、测试覆盖率100%是一个理想的情况,是很难达到的;2、测试覆盖率100%不能说明我们做了完全的测试;3、较低的测试覆盖率能说明我们的测试还不够,反之是不成立的,参考第二条;4、同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试;5、测试覆盖率达到多少要考虑到软件整体的覆盖率情况,以及项目成本,包括人力,时间等等。
由于本人对于测试覆盖率工具的使用仅限于.NET相关的,所以对于其他语言相关的测试覆盖率工具没有经验,因此也少了发言权,这片文章就只能算作对于各种工具的一种简单的介绍罢了,主要内容都来自于google百度,笔者做简单的整理之后发表出来,希望对大家有所帮助。
这篇文章中,主要讨论的是如何提高测试覆盖率的相关问题。其实,提高测试覆盖率最基本,甚至是唯一的办法就是增加测试用例,但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢?
很多人问我说怎么样才能在面试过程中获得成功?一般我都会把这个问题反过来再问他们,大家经常都会认为要想面试成功尤其是技术岗位,一定是技术要素占第一位!其实不然,技术岗位比如软件测试岗位一定不能脱离技术,这是没有任何争议的,但是是不是只要有了过硬的技术,面试就一定没有问题呢?
有个测试同仁让我帮她看看她的简历,看完简历后我的直觉就是“这位测试同仁两年的测试白干了”。简历是一块敲门石,但这块敲门石是什么材质的,恐怕人见人智,然而什么样的简历才能是一块金质敲门石呢,下面是我的一个些个人见解,希望能给正在或正准备寻找更好发展机会的测试同仁们有所帮助。
之所以中立,需要考虑什么是“取代”?是人员的取代还是职位的取代?如果说是职位的取代,就是说撤销测试,没有测试,都由开发人员担当, 那显然是不行的,但题目似乎说的是后者。
开发与测试的关系似乎总是那么的微妙。“强势”的开发,“弱势”的测试,这种状态似乎一直没有转变过,也一直成为测试行业内最想扭转的一个目标。如何有效的摆脱开发的控制?
1、阅读需求文档,深入了解系统,磨刀不误砍柴工,不要还没弄清需求就开测了;2、熟悉测试用例;3、记住自己在工作中扮演的角色是测试而不是开发;4、一旦发现缺陷,应立刻提交;5、新版本发布;6、如果版本未更新;7、严格按照缺陷提交说明提交BUG;8、测试没有空闲。
如果你进入测试行业,你肯定是要么成功要不就是失败的,我觉得要是你想成功的话一定要做到下面这些1)自己自学测试知识;2)坚决不要上班的时候聊QQ.MSN的聊天工具;3)向有经验的测试同事学习;4)将自己学到的知识与别人分享。
项目的开发风险来自于对需求的误解,来自于设计与开发过程及产品的缺陷,只有尽早发现这些缺陷,才能降低并控制项目风险。基于这种思想,软件业出现了一些新的测试思路。
我觉得做测试的那份经验,是自我的一种心态的成熟.从刚开始的时候,遇到一个很小的程序,认为点吧点吧就完事的,根本不会多放精力去关注.到之后,一看几百页的需求文档,认为我根本没办法搞懂的,也随便点吧点吧,反正不报错误框就可以.
优秀测试人员的四种思维:Technical thinking: the ability to model technology and understand causes and effects;Creative thinking: the ability to generate ideas and see possibilities;Critical thinking: the ability to evaluate ideas and make inferences;Practical thinking: the ability to put ideas into practice