【测试员浏览产品的组成和工作方式有很高的价值，但不能算测试。测试员与游客之间的差别在于，测试员把精力放在评估产品上，而不只是见证产品。】
刚开始主管给了我个STB，让我自己熟悉系统功能。因为在学校时做需求比较多，拿到系统后首先做得就是，分模块写功能需求。写完后我意识到我现在的角色是测试员，那么作为一个测试员在拿到一个系统后会做什么，会有哪些方面的考虑？在这里，我貌似就扮演了一个游客的角色（一个勤奋的游客），关心的问题是系统能实现哪些功能，然后一个个见证并记录了这些功能。而作为一个程序员要做的显然要多得多，要在了解系统的基础上对系统进行评估 。目前我对这一点的理解是评价系统的好坏，特别是找出其中存在的问题。而从哪些方面找问题，怎样找出问题就涉及到理论知识中所学的测试分类和测试方法了。所以我要做的是，首先熟悉和了解系统的各功能及定义，然后开始找出系统中的问题。我要回答的不是系统实现了什么，而是系统有没有正确实现以及可不可以更优化实现。
所有测试员都试图回答某些问题【所执行的所有测试，都是要回答有关现实的产品和应该得到的产品之间关系的问题。在任何测试活动中，都要问自己什么样的问题应该推动自己评估测试策略，否则就会更像是游客，而不是测试员。】
所有测试都基于模型【测试员在设计测试时，头脑中可能会有一个想象的图景，也可能有功能清单或某种图表。测试员会有谁是用户、用户关心什么的一些概念。所有这些都是模型。不管模型是什么，测试都主要基于产品模型进行，而不是实际产品。有缺点的模型就会产生有缺点的测试。学会一种对产品建模的新方法，就是学会了一种观察产品的新方法。】
“现实的产品和应该得到的产品之间关系”这里的 现实的产品 指的是实际要测试的软件系统，而 应该得到的产品 应该就是上面所说的模型了。也就是说，每个测试员在测试一个系统之前首先要为这个系统建立相应的模型，这个模型描述了系统的实现方式及一些标准。可以说这个模型就是之后开展测试的依据，通过判断实际系统是否符合模型来对系统进行评估。模型的建立应该是一个长久的、积累的过程，而模型也是对测试人员十分重要的经验财富。
需求是“重要人物所关心的质量或条件”【作为测试员，必须认识到谁的关于质量的观点最重要（并不是每个人的观点都同等重要）。然后了解对于产品他们要什么，不要什么。对于测试，产品应该具备或满足的任何质量或条件都是需求。不同客户通过产品要得到不同的东西，他们不一定知道要什么，而且所要的东西随时都会发生变化，这使测试员的工作更具挑战和意义。】
通过会议、推导和参照发现需求
【我们所经历的最好的情况，需求文档是不完整、不准确的，尽管需求文档提供了信息并且是有帮助的。我们所看到的最差的情况，需求文档是不完整、不准确的，需求文档没有提供信息并且是没有帮助的。
测试员把项目文档看做是唯一需求来源会影响其测试过程。需求信息到达测试员主要有三种方式：
（1） 会议：找出对有关质量意见具有影响力的人，与他们交流，了解他们最关心什么。
（2） 推导：通过外推已知的项目和产品的其他信息，确定什么需求最重要。
（3） 参照：既发现显示，也发现隐式规格说明，并以此作为测试的基础。
搜寻测试所需的信息，是测试员的工作。】
既要使用显式规格说明，也要使用隐式规格说明【并不是包含测试所依赖重要信息的所有参照都是显示的提供给测试员的：
显式规格说明：是有用的需求信息源，经过客户的权威认证（这就是规格说明，是产品描述）。
隐式规格说明：是没有经过客户的权威认证的有用的需求信息源（这不是规格说明，但有意义）。
隐式规格说明的威信来自其内容的说服力和可信性，而不是客户的批准。在大多数情况下
只有部分隐式规格说明与当前产品有关。
当产品与显式规格说明冲突时，测试员可以明确的报告：“产品违反了规格说明，因此产
错了”。当违反的是隐式规格说明时，测试员的报告必须详细一些，如：“在Microsoft Office
中，功能键F4固定用于重复命令。除非我们也这样定义，否则在日常工作中也使用Office
的用户会感到困惑。”虽然没有人说Microsoft Office是这个产品的规格说明，但是客户可能
会同意采用与Office一致的用户界面会提高可用性。在此，Office就是一个隐式规格说明。
为什么设计人员不把所有有用的信息都放入显式规格说明？虽然这样做方便了测试员，但是
很昂贵。客户相信测试员能够使用所需的各种参考资料快速找出重要的问题。】
