火龙果软件hp惠普软件测试讲义(ppt).pptVIP

* 我们的策略 以一类测试方法为基础和主要线索 阶段性地运用二类测试方法 * 一类测试流程 一、审核需求和设计 一类测试是以需求和设计为本来验证软件的正确性。需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是进行一类测试的第一步。 这里所说的需求和设计具体说来它一般包括： （1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement Specification）； （2）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）； （3）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）。测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。 * 一类测试流程 二、设计测试 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。 在前面提到的三种文本中，功能设计文本是主要依据。这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。这是典型的“黑盒测试”。软件产品的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划” 文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。 * 一类测试流程 三、实施运行测试 实施运行测试是整个开发过程中最长最复杂的阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。 这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行，这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时,所涉及的测试用例当然也要相应地修改。 * 二类测试流程－阶段性测试 根据需要而带有随机性和突击性。对于这类测试，有一个专门的名称：“Bug Bash（Bug大扫除）”。 Bug Bash通常发生在产品开发各阶段（里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识来搜寻项目的Bug。 一般有以下要点： 1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益； 2）鼓励各部门，领域交叉有哪些信誉好的足球投注网站，新的思路和视角通常有助于发现更多的Bug； 3）分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。 4) 专业性的测试，如针对安全性攻击测试。可邀请公司内部，或业界的专家来搜寻产品的漏洞。 * 测试与开发的融合 * 测试与开发流程融合趋势 有意整合测试和开发融合的手段 1、测试活动的早期展开，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。 2、如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。 以上都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试