《第16章、软件测试经验分析（讨论课）》由会员分享，可在线阅读，更多相关《第16章、软件测试经验分析（讨论课）（28页珍藏版）》请在金锄头文库上搜索。
1、测试计划与软件缺陷,第十六章 软件测试经验分析,2/28,本章学习目标,回顾学习过的知识 经验交流，提高测试水平,3/28,内容进度,知识回顾与提高 成功测试经验介绍,4/28,内容进度,知识回顾与提高 成功测试经验介绍,5/28,成功测试经验介绍,测试人员的服务对象 项目经理（开发经理、测试经理） 程序员 文档编写人员 技术支持 市场人员 管理层和项目相关人员 用户 测试人员关注失效，客户才能关注成功 什么是“完备”的测试？,6/28,测试人员的服务对象,*项目经理。项目经理有资格了解测试员的工作进展并施加影响。测试员根据要求向其报告工作状态，迅速报告重要问题。并不要成为项目的瓶颈，从而为项
2、目经理提供服务。指挥项目是项目经理的特权。测试员的责任就是告诉项目经理自己能做什么，不能做什么，有关项目的决策和条件会对测试产生什么影响。 *程序员。通过尽可能迅速地提供好的错误报告，使得程序员的工作更容易一些。努力提高自己的技能并了解产品，以免用错误的或用毫无意义的报告浪费程序员的时间。如果测试员可以做到这一点，就可以赢得更多的信任，而这种信任又可以转化为支持和影响。,7/28,测试人员的服务对象,*技术文档编写员。与测试员一样，负责编写文档和在线帮助的技术文档编写员也不能得到产品的完整信息。测试员可以帮助他们理解产品到底怎样发挥效能，并为其指出文档中的错误。技术文档编写员也会帮助测试员。当
3、技术文档编写员研究产品，以及必须阅读文档的用户会怎样使用产品时，会了解到一些测试员不知道的信息。如果测试员与技术文档编写员有很好的关系，编写员就会告诉测试员有关产品的新特性、新用法、测试计划中的漏洞和他们所发现的软件问题。这些问题中的一部分永远也不会被报告，除非某个文档编写员知道哪个测试员关心这些程序问题。 *技术支持员。遗留在产品中的任何问题都会为技术支持员带来负担。测试员通过告诉技术支持员可能会给用户带来麻烦的产品问题，向其提供服务。如果测试员在开发期间与技术支持员一起工作，有时技术支持员会帮助测试员找出应该更正的软件问题。测试员也应该通过研究现场发现的难题，为技术支持员提供帮助。通过这种
4、方式，能够把测试员与技术支持员拉得更近，进而与客户也更近了。,8/28,测试人员的服务对象,*市场开发员。市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。对于程序员来说是很小的程序问题，对于市场开发员来说可能会是至关重要的问题。他们也许能意识到这种程序问题会使客户较难完成某种重要任务。此外，通过评审市场开发计划文档或描述，测试员可以帮助市场开发员对产品能力有更精确的认识。 *管理层和项目相关人员。测试员服务于公司业务，这也是为什么测试员必须小心，不要像个质量狂，而不是通信达理的人的原因。特别是到了项目要结束的时候，测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要
5、以明确、简洁的词汇编写测试状态报告，以便执行经理能够感到有做出决策的依据。 *用户。在测试员的心中，要想着将要使用该产品的人。当然，用户的满意是项目的最高利益。但是还要考虑满足主要用户对项目团队的特殊要求。,9/28,测试人员关注失效，客户才能关注成功,测试是项目团队中唯一不直接关注成功的角色。其他所有人都在创造什么，或创造性地指导创造。但测试员却是消极的。测试会是一种沉闷的工作，几乎像希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在、也不应该存在的东西，深信成功会为神带来不幸。” 重新定义比较积极的测试员使命是错误的，例如确认程序正常。即使“确认程序正常”作为使命交给测试员，测试员也
6、要忠告客户，这样的确认是不可能的。这种确认成本极高。除非运行所有可能的测试，否则就不能证明程序正常。测试员只能够说：“就我所执行的测试来说，没有发现产品不正常。”但是反过来的确认就非常经济了：只需一个测试，就可以说明产品不正常。 测试员关注失效，是因为这可以增加发现失效的机会。用自己全部的创造力和技能，寻找产品中的关键问题。如果测试员没有找到关键问题，程序员就不能改正，以后用户可能会替测试员找到。通过发现程序中客现存在的问题，测试员能够帮助项目团队更加了解自己的技能和产品风险，帮助他们将产品做得更好，更具可支持性，在市场中有可能更成功。,10/28,什么是“完备”的测试,有一些测试员承认自己不
7、知道是否发现了产品中的全部问题，但仍然不准确地讨论结束测试的含义。“对这个产品我需要测试5天”可以解释为，他可以在5天之内对产品进行完备的测试，也可能意味着他会在5天之内发现所有问题。完备性常常是隐含地表示出来的，而不是明说出来的。不管是哪种情况，这都是必须小心对待的概念。请考虑完备测试可能的含义： 完全发现了产品中每个问题。 完全检查了产品的每个部分。 完成了自认为是有用和经济的测试。 尽自己所能，完全达到了项目团队制定的目标。 完成了约定的测试。 完成了在一定条件下人所能够测试的所有内容。 完成了自己知道如何测试的所有内容。 完成了自己所承担的测试部分，不考虑其他人的工作。 完成了对产品很
8、广、但是不深的测试。 完成了对产品的一种测试。 用完了分配给测试的时间。,11/28,什么是“完备”的测试,如果测试员小心地澄清自己的意思，不要有“完备”、“完成”、“结束”等含义，则可能会很安全，由于有些工作没有做而受到的责备可能更少，在受到责备时可以更好地为自己辩护。请注意，“完备”的定义并不是在项目一开始就 能够最终确定的，随着测试项目的进展，随着新测试任务的突然出现，需要重新考虑。 为了解决在完备性上的普遍沟通问题，可让客户详细了解测试过程。总结自己实施的测试，以及为什么值得实施这些测试，并告诉客户自己没有做的其他值得做的测试，以及为什么没有做这些测试。,12/28,成功测试经验介绍,
9、事不关己、高高挂起？ 直觉？ 把直觉当做指南，但不能用做合理性证明。 关于规格说明书 显式和隐式规格说明书 它没有问题？ 快速产生测试思路，合理取舍测试用例 使自己的报告成为一种有效的销售工具 缺陷报告代表的是测试人员 缺陷报告对不同人的价值 程序员、需求分析人员、文档编写人员、售前、技术支持人员、高层管理人员,13/28,事不关己、高高挂起,测试是如此复杂与其他项目活动如此密切关联，以至于测试员总想通过采用狭隘的测试使命观进行更好的控制。有些测试员认为自己的使命就是找出产品和规格说明之间的差别。任何超出这个范围的问题，例如可使用性问题、需求问题、数据质量和可支持性问题，都“不关我的事”。我们
10、强烈要求这样的人把眼光放宽一些。所有其他事情都一样，测试员的使命应该是尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。因此，优秀的测试团队应由理解项目总体问题的不同类型的人员组成：产品将怎样设计、制造、市场开发、销售、使用、服务和升级。 说“不关我的事”的另一个原因是测试员处于困难的测试环境。负责程序设计的同事编写的规格说明可能很差，可能交付代码太迟，以至于没有时间执行合理的测试过程。他们可能声称测试员发现的重要问题实际上是测试员自己的主观臆想。在这种环境下，很想拒绝测试。测试员可以说，解释模糊的规格说明或在这样短的时间内进行某种测试不是自己的事。如果情况很严重，这样做也许不错，但
11、是首先应该考虑一下自己的期望是否实际，考虑一下是否有其他方式能够得到自己所需要的条件。如果测试员接受这样的哲学认为自己的工作就是付出合理的努力去适应和灵活应对各种情况，则程序员更有可能把测试员当作恩赐，而不是负担。而这反过来又会促使他们把帮助测试员看作是自己的事。,14/28,直觉,测试员很想根据自己的直觉使用具体的测试数据，或判断具体的输出，即测试员自己知道的“本能感觉”，即使说不出来使用这些知识的合理性的理由。我们认为这是有用的感觉，但是只是在开始时更有用，而不是在其他时候。 除了直觉有很强的偏见这个事实之外，真正的问题还在于测试员试图让其他人(例如程序员和经理)认真地对待自己的错误报告和
12、质量评估。除非这种发现是基于大家都有的直觉，否则测试员的工作建议很可能不被采用。 因此我们建议把直觉用作指南，但不能用作合理性证明。当有“这是问题，因为它显然是问题”的想法时，可考虑换一种方式；“这是问题，因为我观察到产品行为与需求x、Y和z矛盾，而我的客户很看重这些需求。”,15/28,关于规格说明书,并不是包含测试所依赖重要信息的所有参照都是显式地提供给测试员的： 显式规格说明是一个有用的需求信息源，经过客户的权威确认。(“是的，这就是规格说明，是产品描述。”)隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。(“这不是规格说明，但是有意义。”) 隐式规格说明的威信来自其内容的说服
13、力和可信性，而不是客户的批准。在大多数情况下，只有部分隐式规格说明与当前产品有关。隐式规格说明有很多种形式： 竞争对手的产品。 相关产品。同一产品的老版本。项目团队之间的电子邮件讨论。顾客意见。杂志文章(例如，有关产品老版本的综述) 。相关主题的教科书(会计书籍适用于会计应用程序) 。图形用户界面(GUI)风格指南。操作系统(os)兼容性需求。测试员自己的丰富经验。,16/28,关于规格说明书,当产品与显式规格说明冲突时，测试员的报告任务相对简单一些：“产品违反了规格说明，因此产品也许错了。”当违反的是隐式规格说明时，测试员的报告必须详细一些：“在Microsoft Office中，功能键F4
14、固定用于重复命令。除非我们也这样定义，否则在日常工作中也使用Office的用户会感到困惑。”虽然没有人说Microsoft Office是这个产品的规格说明，但是客户可能会同意采用与Office一致的用户界面会提高可使用性。如果是这样，则Office就是这个产品的一个隐式规格说明。 有些测试员可能会问，为什么设计人员不把所有有用的信息都放入显式规格说明，使得他们不必再从隐式资源中分辨规格说明。回答很简单：虽然这样做方便了测试员，但是很昂贵，而且没有必要。客户相信测试员能够使用所需的各种参考资料快速找出重要的问题。,17/28,它没有问题,任何时候听到有人说“我试过了，它没有问题“、“我保证它没
15、有问题”或“它现在更好了”，我们建议把“它没有问题”解释为“它看起来在一定程度上满足部分需求”。测试员应该立即想到的一些问题包括： “它”是什么?我们正在谈论的是产品的哪个部分? 外观是什么情况?到底观察到了什么? 检查了哪些需求?正确性如何?性能如何? 为了通过测试要在多大的程度上满足该需求?只是刚刚通过,还是超过指标很多? 它什么时候没有问题?测试覆盖了多大范围的条件?通过这些条件可以安 全地推广到多远? 如果不愿意，可以默默地问自己。关键是如果对“它没有问题”没有进一步地限定，它就会是模糊的。测试员所认为的“它没有问题”的意义，可能与别的人定义不同.,18/28,快速产生测试思路,试探法
16、(hcuristic)是一种经验规则，是一种基于经验做出猜测的方法。这个词源自希腊语,表示“开始发现”。试探法并不能保证得到正确的答案或最佳答案，但是很有用。最早运用试探法的著作是如何解决它(How to Solve it)(Polya l957)。 出于可能的测试用例数量是无限的，因此肯定要选出在所面临的时间和预算约束条件下有效的少量测试用例。有经验的测试员会收集并共享能够改进其猜测质量的测试试探方法。一组好的试探方法有助于很快地生成测试。以下是采用试探法测试的一些例子： 测试边界。边界更有可能暴露规格说明的模糊问题。 测试所有错误消息。错误处理代码与主流功能代码相比，一般比较弱。 测试与程序员的配置不同的配置。程序员已经偏信自己的配置没有问题。 运行比较难设置的测试。在其他条件相同的情况下，易于设置的测试更有可能已经被执行过。 避免冗余测试。如果某个测试实际上是重复其他测试，就不会产生新价值。 为了明智地运用试探法，请注意：试探法中并没有智慧，智慧来自测试员。试探法所能够做的，只不过就是为测试员的思考提出建议。盲目使用自己并不了解的试探法并不是好的测试实践。在收集测试方法时，要了解每个方法背后的原理，以及更适用和不太适用的条件。,
