• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• DataMigration们的唱K

  2008-7-26

  昨晚去了DM的庆功会,虽说不是我们项目,但是R姐毕竟下星期一去USA了,想着能为R姐饯行一下也好,想不知R姐提早退场了,得番一行人K歌,喝酒,一众人玩着,不知竟到了一点多,想走,无奈被PM挡住.可惜,STAR作为DM的成员,竟然没去,很多做过DM的成员都没去...

  昨晚郁闷得很,想着我们TTMD内部的内耗,就TMD就郁闷,一个项目内部,一些成员仗着自己的老资格,根本不尊重别人~~~很多事情根本不是从项目的角度去想...

  但是转过来一想,毕竟不是每个人都是抱着我这样敬业的想法,平时众多人上班玩QQ,看电影~~~每个人的出发点不同,自己无法改变这事实,或许对于管理层来说,这些并不重要.

  在年初的大会上,HEAD说要今年的业绩达到150万美金,我很怀疑我们究竟能不能达到这目标,目前来说,似乎在我们手中的项目并不多~~~不明白,不是管理层,哈哈.这也不是我应该要担心,有点狗拿耗子的味道.

  查看(11) 评论(0)

• 当前做的项目遇到过的一些问题

  2008-7-25

  貌似我们项目有些问题和以下是相关的

  外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外还包括对输入/输出格式错误理解，对输入数据不合理的容错等等。

  *我们在打印的时候遇到这样的BUG,打印出来的页面脚部丢失.我们的软件与外部的连接并不多,就是EMAIL, 截图,保存文件到网络路径上,协议的话因为是桌面程序,暂未遇到相关的问题.呵呵,不知道是不是我想不出来.

  　　内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入/输出格式错、数据保护不可靠、子程序访问错等。

  *国际化测试时遇到的一些问题属于此类,支持的语言字符在输入软件保存后,在其他语言下打开,有时会有一些乱码的现象.NND,前几天还发现一个BUG与系统的小数点的设置格式有关,之前设计用例的时候忽略了这点.

  　　硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。

  *在我们的测试机器上,作为一个桌面应用程序,主要作用是使用的功能上,没有功能联系到显卡,但多个文件打开在同一个地方综合去看,会遇到程序运行较慢,这与系统的CPU和内存有关,没有用过更多的其他硬件试过程序的运行性能. 这程序之前版本的性能就和现在差不多,而且客户方并没有提出明显的性能要求,程序瓶颈并不在处理多用户上,反正觉得不太慢都可以接受了.

  　　操作系统错误：这类错误主要是由于不了解操作系统的工作机制而导致出错。。当然，操作系统本身也有错误，但是一般用户很难发现这种错误。

  *可能会有一些问题是由于系统的更新引起的,现在暂未发现些问题.之前遇到过在一些类型的用户下无法运行程序的问题,后来解决了,把每个文件夹的权限修改就OK了.

  　　软件结构错误：由于软件结构不合理或不清晰而引起的错误。这种错误通常与系统的负载有关，而且往往在系统满载时才出现。这是最难发现的一类错误。例如，错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定不会发生中断而导致不能封锁或开中断；错误地假定程序可以绕过数据的内部锁而导致不能关闭或打开内部锁；错误地假定被调用子程序常驻内存或非常驻内存等等，都将导致软件出错。

  *这问题发生过,在打开多个文件(超过100个文件)时,产生内存溢出的问题,但是后来定位时又没出现了.NND, 只在一台机上出现过,而且一旦出现,重现率竟然为100%,重启了机器也如此.在其他相同配置的机器上没出现过,后来减少了系统物理内存,依然没出现.

  　　控制与顺序错误：这类错误包括：忽视了时间因素而破坏了事件的顺序；猜测事件出现在指定的序列中；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。

  *暂未没有发现过此类问题.

  　　资源管理错误：这类错误是由于不正确地使用资源而产生的。例如，使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接在错误的队列中等等。

  *在一些特定的操作下,系统会被占用100%的CPU和具大的内存,一段时间后程序报错,自动关闭.

  查看(25) 评论(0)

• 测试人员容易遗漏一些隐藏的缺陷

  2008-7-22

  通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

  　　1、安装缺陷

  　　通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

  　　2、配置文件

  　　有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

  　　3、网页安全缺陷

  　　现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

  　　网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

  　　4、判断顺序/逻辑缺陷

  　　对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

  　　5、调试语句和冗余信息

  　　维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

  　　同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

  　　6、不可重现的故障

  　　新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

  　　7、多节点的逆向流转缺陷

  　　当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

  　　8、输入框缺陷

  　　试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

  　　输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

  　　9、界面布局缺陷

  　　曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

  　　界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

  　　10、版本和补丁包的环境问题

  　　理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

  　　11、用户管理缺陷

  　　用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

  　　另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

  　　12、常识缺陷

  　　从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

  　　尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

  查看(38) 评论(0)

• 打印尾部丢失的问题

  2008-7-22

  今天遇到一个之前报过的BUG,用我们的软件打印,脚部部分丢失了,而当把系统的度量单位改为metric,却又可以了,用作测试的系统是通过一台服务器连接到打印机(WIN 2000),上面装了几种printer的Driver;

  我很纳闷别的XP EN-US不会出现,而只会出现在特定的系统下~~~还跟度量有关~~~~

  暂还没有试过别的打印机,没有多余的打印机了~~~资源短缺之一,郁闷~~~感觉今天没什么成就感的,就回归验证一些BUG,就花了一天时间~~~大部分时间都用在这上面了~~~

  查看(21) 评论(2)

• Good bug report art

  2008-7-21

  Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：

      组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。

      重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。

      隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

      归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

      对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

      总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

      精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

      消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

      中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。

      检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。

      以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下：
          对管理层来说，是清晰明了的，特别是在概要这一级；
          对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息
      可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。
  

  查看(29) 评论(0)

• 关于工作态度

  2008-7-20

  在实际的工作中,并不是每个人的态度都是积极的~~~而当团队中存在这些影响工作的因素,质问或者侧面提醒是否是一个很好的方法,PL是否有一个责任去提高团队成员的士气???

  同时也意识到在一个团体里,很多资历老的人有时很牛,在这情况下,可以先在表面上不和他们冲突,装作顺从,而自己该做什么还是该做什么,答应别人的事情要做到....希望这态度是正确的...

  查看(61) 评论(1)

• 国际化和本地化测试

  2008-6-30

  http://www.51testing.com/?114226/action_viewspace_itemid_10149.html

  查看(28) 评论(0)

我的主题

• 与美术人员的沟通交流

我的最新图片

• 

  公司同事