我不清楚你的情况，但我很容易分心。我查看自己的邮箱，查看我的Facebook，查看我的Linkedin。我们生活在一个信息可以通过多种渠道推送给我们的世界。我认为这是件很棒的事—但这有时候会导致你效率低下。这里有4件事能够帮助你成为一个更高效率的测试者。不要同时进行多项任务你也许是世上最擅长同时进行多项任务的人。然而，这代表着你在每个任务上分配的就少了。在测试过程中需要相当的专心和注意力。这在进行
作者认为这是最具争议的项目,他认为这是一个神话:"测试人员只需要一点,或是没有程序撰写的知识".这是行不通的,可是很不幸的,这是目前一般常见的状况.这里作者提出两个主要原因(1)测试人员是在测试软件程序,没有程序设计的知识,他们无法洞察bugs真正的原因,找出最可能发生问题的地方.测试通常没有足够的时间,去达到真正测试的"完整",所以软件测试是需要在现有资源
考虑到所有相关的条件，下列哪一项设计，将有助于包装披萨？我指着画在纸上的三种形状（圆形，五角形和正方形），并问应试者。有着两年半的软件测试经验的测试者原本期待会问有关测试（类似测试定义,不同优先级和严重程度,以及缺陷生命周期）的问题。他想了一会儿，然后回答说，按他的看法所有的三种设计均适用于比萨饼包装。我让他考虑如成本，安全和交付等条件，他的回答是仍然一样。采访结束了。在我将近十年从事软件测试的职
之前曾经post一篇有关于"别让不懂营养学的医生害了你"的文章,它主要提到很多医生擅长治疗疾病,可是却不太懂的预防生病的方法.医生都知道怎样用药物,如抗生素来消灭病毒,虽然有他的效用,但是在过份滥用下,导致抗药性越来越高,反而让人们生病后不容易变好.可是说到要事先预防保养,常常没有书籍,媒体或是医生大力宣传,现在即使大家有心想要开始预防,也往往不知道要如何下手.同样的在我们软件
作者是ASP.NETQA团队的人,他和我们分享了他们的测试经验以前旧的时代(.NET1.0,1.1,2.0)当作者加入时,.NET1.1正要release,而团队正要开始进行2.0版.那时候QA的流程是这样的:1.当QAteam结束对1.1版的测试,并且签字画押可以发行时,下一版本正在顺利开发中.这时候通常有一个"stabilization"的时期,QAteam正在撰写自动化测
几个月前，LinkedIn推出了在多种平台上一个全新的移动体验，包括本地应用和HTML5的web应用。在后台，我们在客户端大量运用JavaScript和HTML5并在服务器端使用了Node.js。为了能够迅速开发，测试和发布，我们建立了持续集成的自动化流水线。在这篇文章中，我将告诉你LinkedIn的移动CI是如何工作的。概述下面是对LinkedIn的移动架构的高度概括：LinkedIn移动架构我
编写足够的代码使测试通过程序员告诉我，当他们有一些代码和测试提交。我们过一遍代码和相关测试（主要是“unit-integration”的测试）流程，讨论了验收标准覆盖面，然后我便抽离了对程序员软件的探索。我尝试了几个这些边界情况下，我正在考虑和几个错误举例测试，以检查测试的有效性。也有机会向客户展示软件来检查我们是否满足了期望。失败的测试的这种反馈循环，代码演示然后提交一般花费数小时而不是几天。根
TDD对我这个测试人员而言的意义?我有在开发团队作为测试员并且使用TDD的工作经验，但我从未真正思考过TDD对我有什么样的影响，直到有人明确的问我：测试驱动开发（TDD）是一种以编程为主驱动的做法，那么你作为一个测试人员对此有何看法？真是一个好问题！我当时的回答是，TDD使我能够理解该软件，以及相关的测试，所以我可以更好的完成设计决策、抛出运营风险和潜在对GUI/验收测试的影响。本文试着详细解释我
微软在测试方面提出一个practice:bugbars.也就是说他们会设定一个magicnumber,当RD身上所负责的bugnumber超过这个数字,他必须要停下手中的工作,立即把bugnumber降到这个数字已下,或者是全部解完.它的目的是希望bug早点找到,就能够尽早被处理.避免bug影响之后其他功能.此外若是这bug很久之后才解,容易被忘记它到底是怎么发生,或者是要根据哪个版本的sourc
TheFeatureCrewModel在.NET2.0release之后,开发团队对开发软件的方法,做了一个很大的转变.这个改变是从上到下,作者称它为"FeatureCrewModel".整个开发部门为了这个方法做了很多准备,花了几个月的时间去开发许多工具以及infrastructure.这个model主要概念如下:1.在开发部门中,每个ProductUnit(PU)会把要re
热门文章