2007年08月
关于变更控制，我常常会产生自相矛盾的想法，一方面，我希望为改进和更好的创意打开“水闸”；但是另一方面，我又想通过限制更改保护现有的产品质量。阅读全文>
发表于 @ 2007年08月25日 14:10:00|评论(loading...)|编辑
ET测试（Exploratory testing）强调测试设计和执行同步进行。但是我们如何组织我们的思想以便我们想到值得去做的测试呢？一种方法是使用启发术和记忆术。启发术是“经验方法、简化或有根据的推测”。例如，从门口地毯下面找钥匙的想法就是一个启发。记忆术，就是“词语、节奏或其他帮助记忆的东西，就是简单易记的东西用于帮助联想起复杂的、很多的信息”。记忆术和启发术帮助我们在压力下很好地解决问题阅读全文>
发表于 @ 2007年08月24日 20:45:00|评论(loading...)|编辑
当程序员或经理对测试做出一些无知的解释时，你会有什么感觉？你不喜欢？但是我喜欢，因为至少他们说出来了。我的经验是：我的大部分非测试员同事，无论他们在自己的工作方面有多优秀，他们对我的工作的认识都比较模糊。但是如果他们什么也不说，我也对此束手无策。所以，在某种程度上，我会感觉好些，在我听到他们说一些类似这样的话：“你就是操作每个功能看它是否工作而已，对吧？这有什么难的？” 阅读全文>
发表于 @ 2007年08月23日 20:29:00|评论(loading...)|编辑
几天前，我意识到当我在测试时我会感觉像一个超级英雄。我在做探索性测试时感觉就像驾驶着飞机飞过一个产品，使用我的X光视力去寻找bug。我能像Clark Kent一样，假装成一个普通人，但是当我需要的时候我能跳过很高的楼。拥有仿生耳，超强的力量，能扭曲时间和控制自然力量等。阅读全文>
发表于 @ 2007年08月23日 20:23:00|评论(loading...)|编辑
探索性软件测试是一种强大和有趣的测试方法。在某些情况下，它比剧本化的测试更高效。其实，每个测试员都在不知不觉地在用到探索性测试方法，但是很少有人学习和重视这种方法。现在是时候认识一下探索性测试方法了：科学的实时的思考。阅读全文>
发表于 @ 2007年08月20日 21:18:00|评论(loading...)|编辑
如果你也和我一样发现探索性测试值得一用，那么问题就来了：什么时候使用它？如何融入到软件生命周期中？阅读全文>
发表于 @ 2007年08月19日 13:01:00|评论(loading...)|编辑
Test Complete主要是一个功能测试工具，利用其对GUI控件的识别、动作记录、回放等脚本技术实现替代部分的人工测试的执行。但是它同时还提供很多机制让我们在功能测试的同时记录性能。阅读全文>
发表于 @ 2007年08月18日 20:37:00|评论(loading...)|编辑
有些测试员会问：“我怎么知道我的测试做得足够了？”很遗憾，对于这一样一个问题，没有很客观或严谨的答案。但是我们可以在尝试回答问题前识别出来那些因素应该加以考虑。我们至少可以建立一个围绕这个问题的启发模型。阅读全文>
发表于 @ 2007年08月17日 20:55:00|评论(loading...)|编辑
我们的测试员和测试经理通常很难控制工作的上下文。甚至很难控制工作本身。当测试过程的控制权在测试组之外，会导致更低的效率和有效性。这个模型设计假设有三个元素是你可以控制的：测试策略、测试资源调度和测试结果阅读全文>
发表于 @ 2007年08月12日 18:58:00|评论(loading...)|编辑
要回答“测试计划定得好不好？”这个问题，就要回答测试计划应该是怎样的。虽然有很多测试计划文档格式模板，但是它们不区分好的计划和差的计划。这个模型识别基本的概念和测试计划应该有的功能，测试计划应该满足的标准，并且提供一些启发以帮助判断测试计划的功能是否满足标准。阅读全文>
发表于 @ 2007年08月12日 16:38:00|评论(loading...)|编辑
这个测试策略启发模型是测试策略的设计模式的子集。目的是提醒测试员在创建测试时应该考虑什么东西。最终目的是为了专业测试员能否对它进行个性化和使用在对话讨论中，自我指导学习和更充分的有意识的测试。阅读全文>
发表于 @ 2007年08月12日 13:56:00|评论(loading...)|编辑
当你在开发一个产品时，如果中间包含一些因素是你没有什么经验的，例如新的技术，你将遇到很多意想不到的问题。这些问题需要新的工具，新的技能，或者需要足够的时间来解决。阅读全文>
发表于 @ 2007年08月11日 13:41:00|评论(loading...)|编辑
我们越是能控制它，测试越能被自动化和优化你能看到的都是能被测试的为了测试它，我们需要了解它越简单，需要的测试越少越少改变，对测试的影响越少了解越多的信息，我们将测得更巧妙阅读全文>
发表于 @ 2007年08月10日 14:08:00|评论(loading...)|编辑
需求开发不是在项目启动时一次搞定的。实际上，需求是贯穿在项目生命周期中的两方谈判。一方在问：我们需要什么？而另一方则在问：我们能构建什么？这两方对话的质量帮助决定产品的最终质量。我把需求理解成众多想法的集合，它们共同为特定产品定义质量。我把测试定义成开发一套评估系统的过程，用于对产品质量进行评估。阅读全文>
发表于 @ 2007年08月09日 23:15:00|评论(loading...)|编辑
本文提供若干实用的建议，帮助项目组开发出可测性更强的软件产品。本文对可测性（Testability）的定义为可见性和可控制性。可见性是我们能观察被测软件的状态、输出、资源利用和其它影响的程度；可控制性是我们能向被测软件输入或把它设置到某个特定状态的程度。阅读全文>
发表于 @ 2007年08月03日 20:08:00|评论(loading...)|编辑