• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

(一)典型测试错误

发布: 2009-5-27 09:59 | 作者: 不详 | 来源: 测试时代采编 | 查看: 54次 | 进入软件测试论坛讨论

领测软件测试网

 1. file a bug report documenting a usability problem, with the expectation that it will be assigned a reasonably high priority (because the fix is clearly useful to everyone, important to some users, and easy to do)? 

        写一个 bug 报告,记录一个可用性问题,希望能够分配一个合理的高优先级(因为这个修复很明显对每个人都很用,对有部分用户来说还非常重要,并且也容易修改)?

  2. file a bug report with the expectation that it will be assigned "enhancement request" priority and disappear forever into the bug database? 

        写一个 bug 报告,希望它被分配为“功能提升请求”优先级并永远从 bug 数据库中消失?

  3. file a bug report that yields a "works as designed" resolution code, perhaps with an email "nastygram" from a programmer or the development manager? 

        写一个 bug 报告,产生一个“按设计工作”解决码,可能还加上一个来自程序员开发经理的“不同意”电子邮件?

  4. not bother with a bug report because it would end up in cases (2) or (3)? 

        不打算费事去写 bug 报告,因为它将以情况(2)或(3)结束?

  If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn't either.

        如果可用性问题不认为是有效的 bug,那么你们的项目将测试任务定义得太狭窄了。测试员严格限制为检查产品是否按预期工作,而不管这种预期是否有效。客户不关心这个区别,测试员也不应该关心。

  Testers are often the only people in the organization who use the system as heavily as an expert. They notice usability problems that experts will see. (Formal usability testing almost invariably concentrates on novice users.) Expert customers often don't report usability problems, because they've been trained to know it's not worth their time. Instead, they wait (in vain, perhaps) for a more usable product and switch to it. Testers can prevent that lost revenue.

        测试员经常是组织中唯一像专家一样大量使用系统的人。他们会注意到专家会看到的可用性问题。(形式上的可用性测试几乎不可避免地集中于没有经验的用户。)专家客户常常不会报告可用性问题,因为他们已经被训练的知道不值得花时间去这样做。相反,他们(也许是徒劳地)等待下一个可用的产品然后切换过去。测试员可以避免这个损失。

  While defining the purpose of testing as "finding bugs important to customers" is a step forward, it's more restrictive than I like. It means that there is no focus on an estimate of quality (and on the quality of that estimate). Consider these two situations for a product with five subsystems.

        将测试的目的定义为“找到对用户重要的 bug ”是向前进了一步,但与我所喜欢定义相比仍有限制。这意味着没有集中于质量评估(以及这种评估的质量)。考虑一下测试含有五个子系统的产品的两种情况。

  1. 100 bugs are found in subsystem 1 before release. (For simplicity, assume that all bugs are of the highest priority.) No bugs are found in the other subsystems. After release, no bugs are reported in subsystem 1, but 12 bugs are found in each of the other subsystems. 

        在发布前,在子系统1中找到了100个bug 。(为了简单起见,假设所有的 bug 都是最高级别的。)在其他子系统中没有发现 bug 。在发布后,在子系统1中没有报告 bug ,但在其他每个子系统中都报告了12个 bug 。

  

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

43/4<1234>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网