自从从事软件测试工作以来,前前后后,大大小小也参与过了四个项目,同时也和四个做事风格迥然不同的项目经理合作过,如何成为一个做事让Leader满意的tester呢?
测试的价值是保证软件的质量,而不仅仅是找bug,作为接口测试人员的我们也深有体会。我相信,持续集成和有效的接口测试流程,我们更有信心把接口测试做好,保证软件的质量。
我们决定是否修复一个bug并不是,也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”.
国内的测试行业属于新兴行业,还没有很多规范可言,除了那些大的公司,还有一些外资企业比较正规外,其它的公司的测试规范都可以说是鱼龙混杂,与此对应,软件测试工程师的面试也会出现很多不规范的东西。
所谓认证,就是建立确信某物或某人是真实的这么一个过程,authentication来自于希腊语,即真实的,可信的。认证本身依赖于多个认证因子,在计算机安全领域,认证意味着验证通讯发起者的数字身份,常见的认证过程就是用户登录认证,所谓认证测试就是理解系统中的认证机制并找到方法绕过该认证机制。
真的是万事开头难,但我觉得更难的是,每天都坚持做同一件事情。在不被强迫的情况下(如:上班、吃饭、睡觉...),在可自由支配的时间里,现在我每天坚持做的貌似只有GoogleReader。希望我的测试感悟系列也能坚持下来。
回顾即将逝去的2009,作为危机与机遇并存的一年,软件测试这个中国的新兴领域同样雕刻出非凡的印记。懂得珍惜,人生便是一种永恒。一起来回顾领略下中国软件测试这不平凡的2009
什么是场景,就是一段假想出来的在现实中可能发生的故事(有联系的连续行为),用来帮助人们理解一个问题或者系统。举一个简单的例子说明:玩家背包满时去领取道具,这就是一个场景。
软件测试报告作为对测试工作和项目情况的总结,对测试成果的体现,有着很重要的意义。通常来讲,我们会在测试过程中,由测试经理定期写工作汇报给上级,在测试结束后,写一份包罗万象的软件测试报告,然后发给上级、成员、或者客户。这是普遍的做法,但经过这几年的总结,我开始根据不同的对象,写不同的报告。
国内的测试行业属于新兴行业,还没有很多规范可言,除了那些大的公司,还有一些外资企业比较正规外,其它的公司的测试规范都可以说是鱼龙混杂,与此对应,软件测试工程师的面试也会出现很多不规范的东西。
最近研究证明用户对滚动相当接受,而且在某种情况下他们会期望滚动到页面的底部。很多用户喜欢滚动胜过分页,而且对很多用户来说页面的最重要的信息并不是必须放在“折叠线上面”(这是因为各种大量的可见的显示方案是无用的,拒用)。所以将你的布局分割成段以方便浏览是个很不错的主意,使用一些空白分开它们吧。
智能机可能在安装上不会出现比较明显的问题,小容量机就比较明显,受制于容量和处理器,在安装的时候很容易会造成死机,或者安装成功后不能游戏。还有一类问题,就是当测试机已经有一个此游戏的老版本,再覆盖安装新版本的时候,可能会出现一些奇怪的问题,不过发生几率比较低。
前段时间参与了XX项目,这个项目需要用到外部系统提供的接口,因为对接口依赖性较大,测试环境外部接口问题给测试工作造成了很大的困难。经过资源协调,通力合作,还是较圆满的完成了项目,但回过头来看看,在整个流程中还是有几点可以改善的。
可用性的实现,尤其是一些细节上的东西,往往会跟产品的开发周期和Schedule形成相互的制约,怎么在这种相互的制约下达到一个最好的平衡,也是一个要在实践中反复体会的话题。
缺陷跟踪过程是软件工程中的一个极其重要的过程。本文介绍了如何使用两个经典的分析模型,来控制缺陷跟踪的过程。这两个模型叫做《活动bug走势图》、《bug打开关闭图》。
提到如何设计有效的测试计划?测试计划中应该注意哪些问题?听了大家很多的分享,会后自己也整理了一份,当然是按照我自己的思路整理出来的,可能每个人所关注的方面不一样,我最为关注的就是有什么简单、方便、易懂的方式轻松定位如何设计测试计划,是一个量化的方式,理论的内容过于抽象,有时候能力也并为达到能分析的地步,而这个时候我们需要通过什么方式达到分析后同样的效果呢?
Rolling Build,我把它翻译为“滚动生成”,即当TFS检测到在它所监控的范围内有任何新的代码变化被check in的时候,它就启动对最新的代码库(code base)进行Build验证。之所以称之为“滚动”,因为它是在一个Build验证操作完成后再去探测有没有新的check in发生,对Build验证期间发生的check in,会被积累到下一个Build验证。