信息系统测试的设计、组织和实施课件.ppt

《信息系统测试的设计、组织和实施课件.ppt》由会员分享，可在线阅读，更多相关《信息系统测试的设计、组织和实施课件.ppt（158页珍藏版）》请在三一办公上搜索。

1、信息系统测试的设计、组织和实施,5.1测试的计划5.2测试的设计5.3测试的执行5.4测试的总结,软件测试实施过程,测试计划,测试设计,测试执行,测试总结,5.1测试的计划,5.1.1测试类型的选择有各种各样不同的测试类型，在测试计划阶段，要根据系统的功能和特性、经费和时间等诸多方面因素，选择不同的测试方案，进而选择不同的测试类型。,22种测试类型,（1）黑盒测试：不基于程序内部设计和代码的任何知识，而是基于系统需求和功能。（2）白盒测试：基于一个应用代码的内部逻辑结构，测试是基于覆盖全部代码、分支、路径、条件。,22种测试类型,（3）单元测试：测试功能模块。典型的单元测试是由程序员而非测试员

2、来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构，还可能需要开发测试驱动器模块。,22种测试类型,（4）增量测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能部件能够足够独立，以便可以在全部系统完成之前各部件能够分别工作。这种测试可由程序员或测试员来做。,22种测试类型,（5）集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户/服务器和分布式系统有关。,22种测试类型,（6）功能测试：用于测试应用系

3、统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，所以功能测试能用于测试的各个阶段。,22种测试类型,（7）系统测试：基于系统整体需求说明书的测试；应覆盖系统所有联合的部件。,22种测试类型,（8）端到端测试：类似于系统测试；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话、与网络通讯，或与外部硬件、应用系统或适当的系统对话。,22种测试类型,（9）健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟经常与系统发生冲突，使系统陷于瘫痪

4、，说明该软件不够“健全”，说明该软件现在还不具备进一步测试的条件。,22种测试类型,（10）回归测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时更需要衰竭测试。因为自动测试工具一般都具有录制和回放功能，并且可以利用脚本语言编写测试程序，所以自动测试工具对这类测试尤其有用。,22种测试类型,（11）接受测试：基于客户或最终用户的规格说明书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。,22种测试类型,（12）负载测试：测试一个应用在重负载下的表现，例如测试一个Web 站点在大量的负载下，系统的响应何时会退化或失败。,22种测试

5、类型,（13）压力测试：在交替进行负载和性能测试时常用的术语。也用于描述在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。,22种测试类型,（14）性能测试：在交替进行负在和压力测试时常用的术语。理想的“性能测试”(或其他类型的测试)应在需求文档、质量保证文档或测试计划中定义。,22种测试类型,（15）可用性测试：对“用户友好性”的测试。显然这是主观的，测试标准将取决于目标最终用户或客户。用户面谈、调查、用户对话的录像和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。,22种测试类型,（16）安装/卸载测试：

6、对软件的全部、部分或升级版本进行安装/卸载处理过程的测试。,22种测试类型,（17）恢复测试：测试一个系统从灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。,22种测试类型,（18）安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时如何保证系统正常工作。这可能需要复杂的测试技术。,22种测试类型,（19）兼容测试：测试该软件在一组不同类型的硬件/软件/操作系统/网络等环境下的性能。,22种测试类型,（20）比较测试：与竞争伙伴的产品的比较测试，如软件的优点、缺点或实力。,22种测试类型,（21）Alpha测试：在系统开发接近完成时对应用系统的测试；测试后，仍

7、然会有少量的设计变更。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。,22种测试类型,（22）Beta测试：当开发和测试小组已经基本完成所要求的测试后，需要通过Beta测试在软件最终发行前去发现一些错误和问题。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。,5.1.2测试策略的制定,测试策略描述测试小组用于测试整体和每个阶段的方法。测试策略的制定是一项复杂的工作，需要由经验丰富的测试员来做，因为这将决定测试工作的成败。,问题的提出,是使用黑盒测试方法，还是使用白盒测试方法？如果决定综合使用这两种方法，那么在软件的哪些部分，什么时候分别运用它们呢？,问题的提出

8、,是使用手工测试？还是需要用测试工具和自动化测试？如果要使用工具，那么是否需要开发，或者购买已有的商用测试工具？如果购买商用测试工具，选购哪一种工具？,问题的提出,是开发单位自己测试？还是请专业的测试公司测试？如果请专业的测试公司测试，只要派出相应的质量保证人员监督他们的工作即可。,制定测试策略的目的,测试策略描述测试过程的总体方法和目标，描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。,（1）一般的测试策略,测试开始于单元级，然后“延伸”到整个系统中。不同的测试技术适用于不同的时间点。测试是由软件的开发人员和独立测

9、试组织来管理的。,（2）黑盒测试的测试策略,1用边界值分析法和（或）等价类划分法提出基本的测试用例；2用错误猜测法补充新的测试用例；3如果在程序的功能说明中含有输入条件的组合，则在测试一开始时就使用因果图法，然后再按以上1、2两种步骤进行。,（3）单元测试的测试策略,1首先用黑盒测试方法，设计一组基本测试用例进行测试。如果发现未能满足覆盖标准，就用白盒测试法补充新的测试用例2首先用白盒测试法分析模块的逻辑结构，设计一批测试用例进行测试。如果发现未能满足覆盖标准，根据模块的功能用黑盒测试法进行补充。,5.1.3成立测试组织,为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的

10、组织和管理就显得尤为重要。,对软件测试管理的要求,l测试必须是有计划的。l测试必须是有组织的。l测试必须是有准备的。l测试必须是可管理的。l测试必须是可记录的。l测试必须是可追踪的。,软件项目的组织和任务,如何有效地管理和实施一个软件项目?在早期软件开发中，没有专门的软件测试部门和测试人员。软件测试工作通常是由开发人员自己来完成的。随着软件开发规模的不断增大，软件开发和软件测试逐步分离为两个独立的部门。为了管理软件项目，还必须有一个软件项目管理部门。,软件项目开发过程,定义：一个软件项目的开发过程，实际上就是一个在软件项目管理部门的控制之下、在一定的时间和财政预算范围内、由软件开发部门和软件测

11、试部门协同工作完成的从项目立项直到软件产品发布的全过程。,1.测试组织结构,（1）管理部门（2）开发部门（3）测试部门,测试组织各部门的职责,管理部门：负责整个软件项目的计划、实施、进度调整，以及产品的发布等工作。开发部门：专职于程序编码、系统集成和软件问题修复等开发工作。测试部门：专职于测试准备、测试实施、编写软件问题报告等测试工作。,(1)管理部门的组成和任务,管理部门的组成：软件项目经理软件开发部经理软件测试部经理若干关键技术人员,(1)管理部门的组成和任务,软件项目管理部门的任务：(1)制定或修改软件开发计划和测试计划。(2)对整个软件项目的进度进行评估。(3)对一些重大问题进行决策，

12、确保软件开发项目按计划保质量地完成。(4)决定每周要完成的开发和测试任务。(5)协调和解决各个部门之间发生的问题。(6)决定提前或推后发布软件。,(2)开发部门的组成和任务,开发部门的组成：软件开发部经理若干软件开发工程师,(2)开发部门的组成和任务,开发部门的任务：(1)按照软件开发计划及开发时间进度表，编写和集成程序代码。(2)对测试部门发现的软件问题进行分析，确定修改的优先级。(3)修复软件问题并进行软件系统集成，生产新的测试版本，在提交给测试部门之前进行基线检查。(4)将新的软件测试版本提交给测试部门进行验证。,(3)测试部门的组成和任务,测试部门的组成：软件测试部门经理若干质量保证人

13、员若干软件测试工程师,(3)测试部门的组成和任务,测试部门的任务：(1)在软件测试工作开始之前，编写测试计划和测试用例。(2)按照软件测试计划、测试用例及时间进度表，进行软件测试。(3)对发现的软件问题编写软件问题报告，并及时提交给软件开发部门。(4)在开发部门提供的新测试版本上，对修复的软件问题进行验证。(5)在新测试版本上，开始新一轮测试或继续前一阶段测试，并报告软件问题。,2.测试部门和开发部门的关系,基本原则:避免一个组织测试自已编写的程序，原因是开发组织很难客观地测试自己的程序。成立独立的软件测试机构进行软件测试。测试组织与开发组织之间的关系越远越好。优点：发现错误效率高，测试组织与

14、开发组织之间有正常的竞争。,测试组织与开发组织的耦合程度,l 测试组织与开发组织属于不同公司、不同城市、甚至不同国家；l 测试组织与开发组织属于同一公司不同部门；l 测试组织与开发组织属于同一公司同一部门，但不在同一小组；l 测试组织与开发组织属于同一公司同一部门同一小组内，但测试人员与开发人员为不同人员；l 测试组织与开发组织为同一公司同一部门同一小组，并且测试人员与开发人员为同一组人员。,3.测试人员的素质,（1）沟通能力（2）技术能力（3）自信心（4）外交能力（5）幽默感（6）很强的记忆力（7）怀疑精神（8）自我督促（9）洞察力,5.1.4 建立测试配置,1测试配置的内容人员：人数、经验

15、和专长，全职、兼职或学生。设备：计算机，打印机等。测试环境：硬件、软件环境。测试工具：黑盒或白盒测试工具。办公室或实验室：地点，大小等。专业测试公司：是否需要，费用如何。其他需求：移动存储器，电话，通讯等。,5.1.4 建立测试配置,2测试环境配置主测试环境配置辅测试环境配置,主测试环境配置,（1）符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。（2）选用比较普及的操作系统和软件平台。例如，一个软件若声称支持“Windows 9X/ME/NT/2000 professional”和“MS Office 97/2000/XP”，一般我们会采用如“Windows 2000 profe

16、ssional+MS Office 2000”的流行环境。（3）营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以免不相关的软件影响测试实施。（4）无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。,辅助测试环境配置,（1）兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。（2）模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意

17、义。（3）横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。,5.1.5 制定测试计划,测试计划是对测试工作的总体描述。,1测试计划的重要性,有条不紊地仔细制定测试计划，是达成测试目标的必由之路。一个良好的、完善的测试计划是进行成功测试的基础。必须要制定一个能够起到总体框架作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。,制定测试计划的重要性和必要性,组织性：即使在小型软件测试项目上，也可能有数千个测试用例。建立测试用例可能需要一些测试员经过几个月甚至几年的时间。正确的计划会组织好测试用例，以便全体测试员和其他项目小组成员有效地审查和使用。,制

18、定测试计划的重要性和必要性,重复性：在项目开发期间内有必要多次执行同样的测试，以寻找新的系统缺陷，保证老的缺陷得以修复。假如没有正确的测试计划，就不可能知道最后执行哪些测试用例及其执行情况，以便重复原有的测试。,制定测试计划的重要性和必要性,测试跟踪：在整个项目开发期间，计划执行多少个测试用例？在系统最终版本上执行多少个测试用例？多少个通过，多少个失败？有无忽略的测试用例？等等。如果没有测试计划，就不能回答这些问题。,制定测试计划的重要性和必要性,测试验证：在少数高风险行业中，测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的系统实际上是不合法和危险的。正确的测试计划和测试跟踪提

19、供了一种验证手段。,2测试计划的内容,包括：产品调研；测试需求说明；测试策略；测试记录；测试资源配置；计划时间表；软件问题报告跟踪；计划评审。,（1）产品调研,这部分应包括产品的一些基本情况介绍。目的变更信息软件结构及技术软件产品规格测试范围项目信息,目的：,重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。,变更信息：,说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。,软件结构及技术：,将被测软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何

20、传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有一些常规性的技术要求，比如运行平台、需要什么样的数据库等等。,软件产品规格：,就是制造商和产品版本号的说明，还可以包括关于被测系统的重要说明，如版权，日期等。,测试范围：,简单的描述如何搭建测试平台以及测试的潜在的风险等。,项目信息：,说明要测试的项目的相关资料，如：用户文档、产品描述、主要功能的举例说明。,（2）测试需求说明,列出所有要测试的功能项（测试项）。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。功能的测试设计的测试 整体考虑,功能的测试：,从理论上讲，测试要覆盖所有的功能项，划分

21、功能项将会是一个浩大的工程，但是有利于测试的完整性。例如：在数据库中添加、编辑、删除记录等。,设计的测试：,对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。这里的合理性包括美观性、可用性、易用性等方面。系统的外观是很重要的，它要求有尽可能好的合理性。,整体考虑：,这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块过程中的正确性。保证上述正确性是保证信息系统正确的前提。例如，我们要保证一个计算器程序中的数据在运算模块和输入输出模块之间的一致性，否则程序将出现错误。,（3）测试策略,描述如何公正客观地开展测试。要考虑模块、功能、集成、系统、版本、压力、性能、配置和安装等各个因

22、素的影响。,一般的测试策略,测试开始于单元级，然后“延伸”到整个系统中。不同的测试技术适用于不同的时间点。测试是由软件的开发人员和独立测试组织来管理的。,黑盒测试的测试策略,1用边界值分析法和（或）等价类划分法提出基本的测试用例；2用错误猜测法补充新的测试用例；3如果在程序的功能说明中含有输入条件的组合，则在测试一开始时就使用因果图法，然后再按以上1、2两种步骤进行。,单元测试的测试策略,1首先用黑盒测试方法，设计一组基本测试用例进行测试。如果发现未能满足覆盖标准，就用白盒测试法补充新的测试用例2首先用白盒测试法分析模块的逻辑结构，设计一批测试用例进行测试。如果发现未能满足覆盖标准，根据模块的

23、功能用黑盒测试法进行补充。,（4）测试记录描述,公正性说明：要对测试的公正性、依照的标准做一个说明，证明测试是客观的。在整体上，软件功能要满足需求、实现正确、和用户文档的描述保持一致。要保证测试的客观，就要保证测试人员能客观的完成测试任务。,测试用例：,描述测试用例模板，管理测试用例采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试用例记录中要为将来的回归测试留有余地。,软件问题报告：,在测试的计划阶段，应该明确建立一个软件问题报告的方法和工具。工具的来源是什么，如何执行的，用了什么样的数据。,特殊考虑：,针对一些外界环境的影响，要对软件进行一些特殊方面的测试。例如，对于一些

24、用于高尖端产品的信息系统，如水下机器人、太空探测器等，测试者应给予某些特殊的测试，使它们能在恶劣的环境下有着较高的可靠性和适应性。,经验判断：,对以往的测试中经常出现的问题加以考虑。例如对于数据库系统，数据的操作（存取，删除，修改等）是其基本功能，同时也是经常出现问题（如数据冗余、死锁等）的地方。经验判断就是针对系统运行或测试中经常出现的问题仔细研究考虑，使之发生率尽量的小。,（5）测试资源配置,制定一个资源配置计划，包含每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。,（6）计划时间表,测试的计划表可以做成多个项目通用的形式，根据大致的时间估计

25、来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。,（7）软件问题报告跟踪,在测试的计划阶段，应该明确建立一个软件问题报告的方法和工具，以及要明确如何界定一个问题的性质，对软件问题的描述尽可能是定量的，软件问题报告要包括问题的发现者和修改者、问题发生的频率、测出该问题所使用的测试用例，以及明确问题产生时的测试环境等。,定义软件问题级别,根据其严重程度分为3级：第1级 严重问题系统功能不能完成，或者是权限限制方面的失误等，也可能是某个部分的改变造成了别的部分的问题。第2级 一般问题系统功能没有按设计要求实现或者是一些界面交互的实现不正确。第3级 建议问

26、题功能运行得不像要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，如界面使用不方便，系统中信息格式不对，提示信息含义模糊混淆等。,（8）计划评审,在测试真正实施开展之前必须要认真负责的对测试计划检查一遍，并获得整个测试部门人员的认同，包括部门的负责人的同意和签字。,3测试计划的层次,一般而言，测试计划可分为3个层次。概要测试计划详细测试计划测试实施计划,概要测试计划,概要测试计划是软件项目实施计划中的一项重要内容，应当在软件开发初期，即需求分析阶段制定。,概要测试计划内容：,定义测试对象和测试目标；确定测试阶段和测试周期的划分；制定测试人员、软硬件资源和测试进度等方面的计划；规定

27、软件测试方法、测试标准以及支持环境和测试工具。,概要测试计划内容：,例如，被测试程序的语句覆盖率要达到95%，第3级以上的错误修复率需要达到95%，所有决定不修复的“轻微”错误都必须经过专门的质量评审委员会同意等测试衡量标准。,详细测试计划,详细测试计划是针对子系统在特定的测试阶段所要进行的测试工作制定的详细计划。,详细测试计划内容：,详细规定了测试小组的各项测试任务、测试策略、任务分配和进度安排等。,测试实施计划,测试实施计划是根据详细测试计划制定的测试者的测试具体实施计划。测试实施计划是整个软件测试计划的组成部分，是检查测试实际执行情况的重要依据。,测试实施计划的内容:,测试实施计划规定了

28、测试人员在每一轮测试中负责测试的内容、测试强度和工作进度等。,软件测试计划实例,软件测试计划实例,5.2 测试的设计,5.2.1测试设计概念5.2.2测试方案设计 5.2.3测试用例设计,5.2.1测试设计概念,测试设计：是系统测试工程中的一个重要问题，也是一种特殊的软件系统的设计和实现，即通过设计一个以发现错误为目标的系统来完成测试。重要性：如果不进行测试设计，要想彻底的测试一个庞大而又复杂的信息系统是不可能的。,5.2.1测试设计概念,测试设计的原则：测试设计必须依据一定的模型和原则，类似于一个应用系统的分析、设计以及编程中遇到的问题。设计的测试必须是可执行的、具体的。,5.2.1测试设计

29、概念,测试设计的步骤：识别和分析被测软件有意义的测试功能点;对这些测试点进行组织或层次划分，建立测试模型;为测试模型中的每个测试功能点设计测试用例。,5.2.2测试设计类型,基于功能的测试设计;基于实现的测试设计;混合类型的测试设计;基于故障的测试设计。,测试设计类型,基于功能的测试设计:根据一个单元、子系统或系统指定的或预期的功能来设计测试需求和测试用例，即黑盒测试设计。,测试设计类型,基于实现的测试设计:根据对系统内部结构或源代码的分析设计测试需求和测试用例，即白盒测试设计。,测试设计类型,混合类型的测试设计:将基于功能的和基于实现的测试设计方法结合在一起，设计测试需求和测试用例，称为灰盒

30、测试。,测试设计类型,基于故障的测试设计:有目的的设计一些故障并引入代码，以便察看被测软件是否可以揭示这些故障。,5.2.3测试用例设计,1测试用例的概念 测试用例实际上是对软件运行过程中所有可能存在的目标、运动、行动、环境和结果的描述，是对客观世界的一种抽象。,1测试用例的概念,测试用例设计应该体现软件工程的思想和原则。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。,1测试用例的概念,测试用例的定义

31、：测试用例，就是以发现错误为目的而精心设计的一组测试输入数据、执行步骤和预期结果的集合。测试用例=输入数据+执行步骤+预期结果,2.测试用例的类型,需求测试用例设计测试用例代码测试用例,2.测试用例的类型,需求测试用例：目的是测试是否符合需求规范；需求测试用例通常是按照需求执行的功能逐条地编写输入数据和期望输出。一个好的需求测试用例是可以用少量的测试用例就能够覆盖所有的程序功能。,2.测试用例的类型,设计测试用例：目的是测试是否符合系统逻辑结构；设计测试用例检测的是代码和设计是否完全相符,是对底层设计和基本结构上的测试。设计测试用例可以涉及到需求测试用例没有覆盖到的代码空间（例如界面的设计）。

32、,2.测试用例的类型,代码测试用例：目的是测试代码的逻辑结构和使用的数据。代码测试用例是基于运行软件和数据结构设计的,它要保证可以覆盖所有的程序分支、最小的语句和输出。,3测试用例设计的原则,设计测试用例基本的原则是：（1）一个好的测试用例在于能够发现至今没有发现的错误；（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；（3）在测试用例设计时，应当包含合理的输入条件和不合理的输入条件。,4测试用例的内容,一个典型的测试用例应该包括下列详细信息：（1）测试目标；（2）待测试的功能；（3）测试环境及条件；（4）测试日期；（5）测试输入；（6）测试步骤；（7）预期的输出；（8）评价

33、输出结果的准则。,5.3 测试的执行,软件测试部门的主要工作之一是按照软件测试计划、测试大纲及项目进度表，执行软件测试。,典型的测试执行步骤：,建立一组被测软件各个功能的测试用例集（测试任务）。执行测试任务，记录每个测试用例的执行结果。评价执行测试任务的结果，是否达到功能覆盖或代码覆盖要求。如果不满足覆盖要求，则需要进一步开发更多的测试用例，建立新的测试任务，对未被覆盖的功能或代码进行测试。只有当满足覆盖目标，并且所有测试均已通过，才可以停止测试。,5.3.1创建测试任务,什么是测试任务？测试任务是在某一测试阶段（系统测试，回归测试，功能确认性测试）计划执行的测试用例的一个集合。,创建测试任务

34、的目的：,通过将整个测试过程划分为不同的测试任务可以满足不同测试阶段的不同的测试需求。跟踪不同阶段测试用例的执行情况。决定测试的执行状态同一个测试用例在不同的测试任务中会产生分开的执行报告，各自带有独立的测试执行的历史信息。测试完成后，在任务中所有执行报告都会被归档。,5.3.2 执行测试任务,测试任务执行方式：一个测试任务；多个串行的测试任务；多个并行的测试任务；多个串行和多个并行的测试任务。,测试任务执行结果：,计划执行多少测试用例？实际执行多少测试用例？执行用了多少时间？记录每个测试用例执行结果（通过或失败）？记录测试用例执行通过的百分比？,5.3.3处理软件问题报告,1软件问题报告概念

35、软件问题报告的作用：记录测试中发现的软件缺陷。开发部门和测试部门对SPR进行协同处理。管理部门根据SPR状态了解测试进度和质量。,编号：是每个软件问题报告的唯一标识。作者：软件问题报告作者名称。标题：是对软件问题的简要描述。状态：软件问题报告状态。被测项目名：标识被测试的软件项目名称。被测软件版本号：标识被测试的软件版本编号。软件问题严重程度：对软件问题进行分级。修改优先级：定义修改次序和时间。操作系统平台和支持软件：对软件问题发现时的软件环境进行描述，以便开发部门再现该软件问题。网络环境：对软件问题发现时的网络环境进行描述，以便开发部门再现该软件问题。软件问题再现详细步骤：对软件问题发现的步

36、骤进行详细描述。软件问题变通和绕过方法：描述变通和绕过该软件问题的步骤。,2.软件问题报告的内容,什么是软件问题报告的生命周期?所谓软件问题报告的生命周期就是指软件问题从开始提出到最后完全解决，并通过复查的过程。,3软件问题报告的生命周期,在这个生命周期中，软件问题报告的状态不断发生着变化，记录着软件问题的处理进程。在这个生命周期中，各类人员对每个软件问题报告所负的责任不同，拥有的处理权限也不同，体现了协同工作的特点。,SPR生命周期的作用：,SPR生命周期中的五个状态：新建状态：SPR初始状态打开状态：经过校验的SPR状态待验状态：SPR被修复后的状态解决状态：修复SPR被验证后的状态关闭状

37、态：废弃的SPR状态,SPR生命周期五种状态及转换,SPR生命周期五种状态及转换,(1)测试人员在依据测试计划和测试用例进行测试的过程中，将发现的问题通过创建一个新的软件问题报告提交给软件问题报告库，同时将软件问题报告的状态设为“新建”状态。,SPR生命周期五种状态及转换,(2)负责该测试域的质量保证人员要对该软件问题进行校验。如果确认这个问题存在，那么就将软件问题报告的状态设为“打开/再现”。然后将该软件问题报告转给负责该功能的开发人员；如果认为这个问题不是一个需要修复的问题，就将该软件问题报告的状态设为“关闭/不是问题”。,SPR生命周期五种状态及转换,(3)开发人员要及时对其负责功能域的

38、软件问题报告进行审查。如果发现该问题是其它功能域的问题，则将报告转发给相应的人员或部门；对软件问题进行修复，修复完毕后要在软件问题报告中填写处理意见，并将软件问题报告状态设为“修复/待验”，并转给相应的质量保证人员进行复查；,SPR生命周期五种状态及转换,(4)质量保证人员对“修复/待验”状态软件问题报告进行验证。如果质量保证人员对开发人员的处理不满意（如问题仍然再现或修复失败），则将软件问题报告重新打开，状态设为“打开/修复失败”，转回开发人员重新处理；如果质量保证人员经过验证，确认问题已经修复，则将软件问题报告状态设为最终的“解决/修复”状态。,SPR生命周期五种状态及转换,(5)对于“关

39、闭/不是问题”的软件问题报告，还可以转为“打开/再现”状态，转移的条件就是经过质量保证人员的复查，确认该问题需要开发人员来解决。,SPR生命周期五种状态及转换,5.4.1确定测试完成标准 5.4.2测试结果统计 5.4.3测试结果分析 5.4.4测试总结报告,5.4 测试的总结,5.4.1 确定测试完成标准,一个软件的测试项目除了通过测试计划、测试用例以及软件问题报告来进行有效的管理外，如何决定什么时候停止测试是一个非常困难的问题。原因：测试不可能找出程序中的所有错误；限于某些条件的限制（如时间和经费），测试不能无限期进行。,不正确的完成标准,在实际工作中，有一些常用的典型标准完全没有意义，也

40、毫无益处。两个最常见的标准是：(1)测试超过了预定的时间表，则停止测试。(2)执行了所有测试用例但没有发现错误，则停止测试。,一些可参考的完成标准,(1)把执行了所有使用规范的设计方法建立的测试用例，作为判断完成测试的基础。测试用例设计方法包括：等价类划分；边界值分析；错误推测法；因果图。,一些可参考的完成标准,(2)明确的指出了完成测试的要求，如直接指出要查出的错误数（如千行代码错误数）。使用该方法要求：估计程序中错误的总数；估计这些错误中通过测试，有多少可以很容易地查出来；估计哪些错误产生于某些特定的设计过程，并且估计这些错误将在测试的哪个阶段被查出。,一些可参考的完成标准,(3)指出在某

41、个测试阶段中，单位时间内查出错误的数量。通过对这些数据的分析，一般可以确定应该继续测试，或是结束这一阶段测试，开始下一测试分阶段。,一些可参考的完成标准,(4)根据各个测试阶段中发现和修复软件问题的趋势曲线,作为判断完成测试的基础。通过对这种曲线的分析，一般可以确定软件开发和测试是否按照一个正确的方向进行。,测试周期与错误数目的关系,软件问题密度分布:在该结果报告中，给出软件问题相对软件问题所在的区域、软件问题产生的过程阶段的分布情况。相对问题区域的分布可以帮助管理人员检验80/20规律（80%的问题分布在20%的区域）在该项目的具体表现，制订有针对性的修改措施和质量保证措施。相对软件过程阶段

42、的分布是反映当前项目还存在的软件问题，以及软件问题在整个项目过程中的发展趋势。,5.4.2 测试结果统计,软件问题修改率:修改率是对问题修改过程的工作效率的一个反映，同时指出当前还有多少问题未得到解决或处理。,5.4.2 测试结果统计,软件问题周发现率:发现率是对发现问题过程的效率的反映。该结果中按照质量保证手段列出软件问题周发现率，帮助项目管理评价哪种质量保证措施更有效。,5.4.2 测试结果统计,按周列出延期修复的软件问题:该结果报告帮助项目管理人员在组织实行产品验证和产品确认时，明确需求规格说明中的需求满足情况。,5.4.2 测试结果统计,严重问题的生命周期分析:该结果是对项目过程中“解

43、决问题”子过程的能力的反映，同时为项目管理人员的决策提供及时的警告信息。如果严重问题的生命周期很长，那么在一定程度上说明严重的问题在项目过程中未引起足够的重视，或者因为处理问题过于困难需要更多的投入来解决问题。,5.4.2 测试结果统计,测试结束后，必须编写测试分析报告，对测试结果加以总结归纳。（1）产品标识；（2）使用的配置；（3）使用的文档；（4）产品说明、用户文档、程序和数据的测试结果分析；（5）与需求不相符的功能项列表；（6）测试的最终日期。,5.4.3 测试结果分析,从四个方面对测试结果进行分析：能力缺陷和限制建议评价,5.4.3 测试结果分析,能力：论述经测试证实了的本软件的能力。

44、如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异对能力的测试所带来的影响。,5.4.3 测试结果分析,缺陷和限制：论述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。,5.4.3 测试结果分析,建议：对每项缺陷提出改进建议，如：（1）各项修改可采用的方法（2）各项修改的紧迫程度（3）各项修改预计的工作量（4）各项修改的负责人,5.4.3 测试结果分析,评价：说明该项软件的开发是否已达到预定目标，能否交付使用。,5.4.3 测试结果分析,在测试完成之后，需要编写测试总结报告。测试总结报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。,5.4.4 测试总结报告,测试总结报告的内容,测试总结报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试总结报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,测试总结报告模板,