软件制造工程组合测试精.ppt

《软件制造工程组合测试精.ppt》由会员分享，可在线阅读，更多相关《软件制造工程组合测试精.ppt（79页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件制造工程组合测试第1页，本讲稿共79页4.4 测试的前期准备n软件测试工程的作业过程可分为测试设计（包括制定测试计划、确定测试方法等）和实施测试两大步骤。第2页，本讲稿共79页4.4.1测试规划与测试设计n对大规模开发系统一般不采用一次性整体测试，而是从局部依次扩大到整体的测试，按计划，有步骤地实施测试。一般从项目需求定义开始，概要设计、详细设计、程序编码的各个开发阶段，要进行测试设计，作成测试计划书，还包括测试作业完成后移植运行作业的计划。第3页，本讲稿共79页4.4.1测试规划与测试设计n表4.3各开发阶段的测试规划和设计评审验证内容 第4页，本讲稿共79页4.4.1测试规划与测试设计

2、n测试计划书一般包括如下的一些的内容：（1）测试工程概要、测试场所、测试方针（2）测试日程和实施体制第5页，本讲稿共79页4.4.1测试规划与测试设计（3）测试管理方法 测试工具 测试环境 测试检测清单 验证方法 版本管理方法 进度管理方法 问题管理方法 回归测试方法 设计变更管理方法第6页，本讲稿共79页4.4.1测试规划与测试设计（4）针对各阶段的测试应明确的事项 阶段测试的目的和范围 阶段测试开始和测试终止的基准 阶段测试检测清单 阶段测试实施日程和实施体制 阶段测试的验收基准和方法第7页，本讲稿共79页4.4.2 了解系统错误、缺陷的影响度n 信息系统的测试很难实现在与实际运行环境（数

3、据、使用者、硬件、时间、网络、系统负荷等）完全一致的条件下进行的测试。n在做测试计划和测试设计时，充分理解软件的错误、缺陷对用户将会造成什么样的影响是很重要的。第8页，本讲稿共79页4.4.2 了解系统错误、缺陷的影响度n软件中即使是很微小的错误，有可能会给用户造成重大的损害和影响。第9页，本讲稿共79页4.4.2 了解系统错误、缺陷的影响度n下图是系统缺陷对一个生产型企业的各个方面所产生的影响 第10页，本讲稿共79页 业务 混乱系 统 缺陷丧失顾客信任经 济 损失不可能恢复的数据业 务 停止不能回答用户的咨询送货发生错误交付期延迟不能处理用户订货断货业务状况不明不能检索信息不能进行业务指示

4、产品报废业务效率降低发生手工作业发生返工用户信息产品信息设计信息销售信息生产信息系统缺陷的影响图第11页，本讲稿共79页4.4.3利用各种测试支持工具n测试工具：作为定型测试，反复实施测试作业的支持工具；确定测试分支、生成测试数据的支持工具；验证测试的覆盖率，提高测试效率的工具；性能测试的支持工具；管理与测试相关连项目的支持工具；变更管理、版本管理的支持工具；检测错误作业的支持工具。第12页，本讲稿共79页4.4.3利用各种测试支持工具n表4.4 部分常用的测试支持工具 第13页，本讲稿共79页测试支持工具注意点组合测试支持工具支持测试计划的编制支持测试项目管理测试分支管理测试程序作成工具支持

5、作成测试分支的测试程序测试数据生成工具自动生成测试数据自动测试工具记录用户操作、自动生成测试程序根据测试记录自动运行测试程序自动生成测试记录测试管理工具记录已测试的编码部分统计分析测试的覆盖范围性能分析工具测量运行时的特性统计分析编码的执行次数、耗费时间检测错误工具提供检测错误的功能（一般作为开发工具的功能提供）软件管理工具版本管理变更管理表4.4常用测试支持工具第14页，本讲稿共79页4.4.4 测试检测清单与测试数据n根据测试计划，按各个测试阶段的目的准备实施测试使用的检测清单和测试使用的数据。第15页，本讲稿共79页4.4.4 测试检测清单与测试数据n测试检测清单是将要检测的项目以能确认

6、的方式用文字描测试检测清单是将要检测的项目以能确认的方式用文字描述出来。述出来。在不同的测试阶段作成不同的测试检测清单，在不同的测试阶段作成不同的测试检测清单，如单元（模块）测试阶段的程序检测清单称为PCL，组合测试阶段的检测清单称为CCL，系统测试阶段的检测清单称为SCL。第16页，本讲稿共79页4.4.4 测试检测清单与测试数据n在测试中需要验证的项目及其判别、制约条件必须全部记入检测清单。第17页，本讲稿共79页4.4.4 测试检测清单与测试数据n例如单元测试的程序检测清单PCL要明确以下几个方面内容：窗体显示的输入、输出项目及判别条件；输出表格印刷输出项目及判别条件；数据库/文件输入、

7、输出项目及判别条件；程序间传递的数据、信息及判别条件。第18页，本讲稿共79页4.4.4 测试检测清单与测试数据n作成检测清单应遵循如下的原则：具体性：判别条件和确认内容必须是在测试结果中可确认的；完整性：检测内容必须是包含设计书中的所有项目、功能；有一定的密度：检测点占测试对象的一定比例。第19页，本讲稿共79页4.4.4 测试检测清单与测试数据 有一定的分布率：如PCL对正常、异常、临界处理及模块间接口数据、信息传输的检测一般按如下比率分配：检测正常分支的PCL条数约占70%；检测异常分支的PCL条数约占10%；检测边界、临界项目的PCL条数约占15%；检测关联模块间传递、接口项目的PCL

8、条数约占5%。第20页，本讲稿共79页4.4.4 测试检测清单与测试数据n测试检测清单针对各种各样的测试分支，须明确测试的前提条件、应确认的内容，明确在何种条件下应有什么样的测试结果。n每个测试分支都有编号，以便于实施测试时记录测试结果。第21页，本讲稿共79页4.4.4 测试检测清单与测试数据n测试结果的记录不仅仅是记录检查合格，还要记录测试结果的具体内容。n记录测试结果要注意易读性，便于他人追踪测试中发现的问题。n根据不同用户的要求，测试内容和测试结果还有可能作为开发方的系统验证资料提供给用户。第22页，本讲稿共79页4.4.4 测试检测清单与测试数据n在测试工程的进度管理中，可以按测试检

9、测清单确定的测试分支作成测试实施日程，统计已实施测试的分支数，确认各个测试分支组的测试进度。因此测试检测清单又可以用于测试进度管理。第23页，本讲稿共79页4.4.4 测试检测清单与测试数据n作成测试检测清单后，根据测试检测清单记述的测试分支准备其使用的测试数据。此外，根据测试分支的覆盖率（正常处理、例外处理等）、测试分支数，还可预算测试工程所需要的工数。n测试检测清单格式要根据测试项目的不同而进行不同的设计。一般都应包括检查条件、确认内容、确认日期等，并且要注意可读性和可实施性，便于测试者做测试数据，进行测试。第24页，本讲稿共79页4.4.5 测试前期准备应确认的事项（1）开发环境和测试环

10、境（2）确保必要的测试时间（表4.5举例说明了开发日程延后的对策处理方法。）第25页，本讲稿共79页4.4.5 测试前期准备应确认的事项（3）留有余地的测试计划（回归测试）n测试计划时，必须考虑如何利用测试工具等多种手段有效实施回归测试，并且制定出留有余地的测试计划，例如，制定精确的测试流程、有效利用测试工具、使测试尽可能自动化、留有回归测试的时间等。n此外，因为变更、修正作业可能诱发新的错误，要根据测试中发现的问题的重要度、优先顺序进行问题管理和变更管理。例如，经判断，对于影响度低的问题，程序的修正可放在测试的最后阶段，由专人集中实施，以减少变更、修正的工作量和风险。第26页，本讲稿共79页

11、4.4.5 测试前期准备应确认的事项（4）系统的各个接口是测试工程的关注点外部接口的测试，应尽量避免在系统测试和运行测试时才实施。最好是在程序开发工程期间内，即在单元测试阶段实施接口测试。最初测试时，只需要确认接口部分的动作，不必要完成系统整体的逻辑处理。为接口部分的处理准备简单的程序，专门的测试数据，测试接收和传送数据的效果。第27页，本讲稿共79页4.4.5 测试前期准备应确认的事项n在考虑测试计划、设计测试方案时要注意以下几点：（1）在设计工程期间要考虑组合测试计划书；（2）站在用户的立场考虑系统错误、缺陷造成的影响；（3）结合各种测试方法确定测试流程；（4）搭建必要的测试环境，确定测试

12、工具；（5）将回归测试列入测试计划；（6）作测试计划时要考虑尽早实施接口测试。第28页，本讲稿共79页4.5 测试的实施n在作好测试计划的基础上，确认开发作业已基本完成，测试工具、数据、环境等已准备好，就可以进入测试作业。第29页，本讲稿共79页4.5.1 各个测试阶段的测试设计和实施者n单元测试一般由开发程序的程序员实施。组合测试由详细设计者和测试设计者实施。系统测试和运行测试一般由从事系统设计作业的系统工程师实施，而运行测试不仅仅是由承担开发项目的企业或部门实施，而且要以用户为主体实施。表4.6对各个测试阶段的计划、实施测试作业者给以了说明。第30页，本讲稿共79页4.5.2 实施测试的要

13、点1、实施测试前应确认的事项n测试前必须确认系统是否进入测试状态。n虽然各个测试阶段有不同的测试重点，但是对于作为测试对象的软件系统的核心部分，要尽早实施性能测试，即对软件系统的效率性进行测试。第31页，本讲稿共79页4.5.2 实施测试的要点2、风险意识n采用新技术、用户需求变更、开发人员的变动等都有可能带来风险。n风险度=发生概率（发生频率）发生时的影响程度（损失）n每个开发人员在自己担任的作业中，都应该经常考虑有可能发生什么样的风险，一旦发现问题应及时与项目管理者商谈，尽可能避免和防止风险的发生。第32页，本讲稿共79页4.5.2 实施测试的要点3、问题管理n在测试中发现错误，修正程序，

14、再测试，确认修正是否正确，这是一般测试作业的流程。n表4.7 处理问题的流程第33页，本讲稿共79页处理流程作业人员处理内容1发现问题测试人员记录测试中发现的问题，交给验证人员。2判断问题，确定修正方案验证人员分析问题，判断问题的重要度，确定修正方案和修正人员。3修正问题开发人员理解问题，修正程序，确认修正是否正确；记录问题发生的原因和修正的内容，交给验证人员。4确认修正内容，确定回归测试方案验证人员确认修正内容，确定对修正部分的回归测试方法和测试人员。5修正确认测试人员确认问题是否被修正，记录确认结果，交给验证人员。表4.7 处理问题的流程处理问题的流程：第34页，本讲稿共79页4.5.2

15、实施测试的要点n问题管理的要点如下：设置专人进行问题管理，对发生的问题作最终判断；对测试结果一定要有记录；作成问题一览表，给每个问题编号，并记录问题解决的状况；对发生的问题要立即记录，以免遗忘；对问题的记录要注意语言简洁、明确、准确，同时要记录实施测试时的条件（如测试环境、测试流程、测试数据）；第35页，本讲稿共79页4.5.2 实施测试的要点n 如果感觉是很难再现的问题，应马上保留测试环境、测试数据等，以便分析原因；如果实施测试者判断是难以用文字表达的问题，要立即找开发人员或程序修正人员，现场说明；n 问题发现者和处理者都要记录和判断问题的重要度；n 问题处理者对记录的问题不明白、或认为没有

16、必要修正程序时，要与测试人员联系、确认；对判断为不需要修正的问题，一定要说明理由；第36页，本讲稿共79页4.5.2 实施测试的要点n 修正错误之后。要记录发生问题的现象和修正的内容；n 修正错误时要注意对同类问题的检查，不能在程序或系统的其它地方遗留同样的错误。第37页，本讲稿共79页4.5.2 实施测试的要点4、问题记录表（简称B票）n记录测试过程中发现的错误、问题。B票不仅仅是用于记录错误信息，还可以提供给质量管理人员、验收人员，作为追踪、分析、确认软件质量的原始资料，有利于改进和提高开发质量。第38页，本讲稿共79页4.5.2 实施测试的要点n根据统计规律，一般要求各个测试阶段发现的错

17、误应占测试对象规模的一定比例，以确保测试的质量。第39页，本讲稿共79页4.5.2 实施测试的要点nB票主要记录如下内容：发生错误的现象，如测试中发生功能遗漏、计算结果错误、打印错误等等；产生错误的原因，如由于设计不良、理解错误、编程不良、测试数据错误等原因造成；采取的对应措施，如修正设计书、程序、测试数据等；发生设计书、程序修正时，记录其修正的范围。第40页，本讲稿共79页4.5.2 实施测试的要点5、不再现问题 测试中常发生曾经出现而以后不在出现的问题，我们常称之为不再现问题。第41页，本讲稿共79页4.5.2 实施测试的要点n一类是问题发生时环境发生了改变，如：测试数据有变化；硬件发生变

18、化；数据库发生变化；操作系统发生变化；某个相关连的程序版本发生变化；其他相关连程序发生故障；第42页，本讲稿共79页4.5.2 实施测试的要点 受内存空间变化的影响；受测试时间、日期变化的影响；运行到某种程度时系统内部发生冲突；系统状态发生变化（初期状态，多次运行状态）。上述的项属于间歇性问题，发生的频度低，但修正很花时间。第43页，本讲稿共79页4.5.2 实施测试的要点n另一类是在完全相同的环境下，由于人为的原因引起的变化，如：操作顺序发生变化；测试人员未按测试流程进行作业；测试人员变更；无关人员触动了系统。第44页，本讲稿共79页4.5.2 实施测试的要点n在发生不再现问题时，首先要对引

19、起不再现问题的原因进行分析。同时，向测试实施者确认测试时的状况，消除人为因素，尽可能在问题发生时的相同环境下进行再次测试，使问题再现。其次是收集、确认问题发生时的系统日志、程序日志，检查相关连的程序，反复测试使问题再现。第45页，本讲稿共79页4.5.2 实施测试的要点6、测试中发现的错误的水平展开 对测试中发现的错误、缺陷，不能仅限于对该错误、缺陷的修正，要同时注意分析程序中是否有其它类似的问题；是自己的理解错误，还是编程习惯产生的错误；别的程序是否也有类似的错误等等。第46页，本讲稿共79页4.5.2 实施测试的要点7、版本的管理n明确发现的错误是在什么时间的程序版本上测试的。n每个参加测

20、试、修正程序的开发人员要充分理解开发项目的整体版本管理方法。第47页，本讲稿共79页4.5.2 实施测试的要点8、提高测试工程的效率n测试工程是需要花费整个开发工程的约25%50%的工数的工程 n从外部设计阶段就开始考虑提高质量和测试规划，直到内部设计阶段考虑整体的测试方案，逐步形成周密的测试计划。第48页，本讲稿共79页4.5.2 实施测试的要点9、防止系统在正式运行中出现故障n在正式运行前，要尽可能在接近真实的数据量、网络环境、终端数量、集中使用密度等实际环境进行系统性能验证测试、负荷测试、耐力测试等。n在正式运行前，还需要从系统的应用方面考虑编制操作手册，进行用户培训，建立技术支持体制。

21、第49页，本讲稿共79页4.5.2 实施测试的要点n确保系统测试成功的一些要点 在充分理解用户业务流程的基础上设计测试流程；在设计测试流程时设想用户容易发生的操作错误；对参加测试的人员进行相关业务培训，使测试人员对用户业务有一定的了解；确保系统测试必需要的时间和人员；计划测试日程时要考虑回归测试的时间；活用测试工具，提高测试效率；第50页，本讲稿共79页4.5.2 实施测试的要点 系统测试以开发方为主体，用户为辅，并着手准备运行测试；系统测试时尽可能使用接近真实的数据；设想正式运行时系统的负荷进行耐力测试；根据可靠性成长曲线（请参见4.6.2中图4.24）判断测试的动向和进度，在出现异常曲线时

22、采取适当的对策；对发现的问题确定优先顺序，从优先顺序高的问题着手修正；对测试发现的问题根据需要进行水平展开；重视问题管理、设计变更管理和版本管理第51页，本讲稿共79页4.5.2 实施测试的要点n10、测试设计和实施测试中的注意事项n表4.8说明了组合测试、系统测试和运行测试各个测试阶段的主要测试工作，以及开始和结束的条件。n表4.9说明了各个测试阶段在测试设计和测试实施时一般应注意的一些主要问题。第52页，本讲稿共79页4.5.3 从运行测试到实机运行从运行测试到实机运行 1、运行测试的主要特征 运行测试以使用者为主体 运行测试是进行业务测试第53页，本讲稿共79页4.5.3 从运行测试到实

23、机运行从运行测试到实机运行 2、运行测试的结束 在结束运行测试，进入实机运行时，必须是用户的所有与系统相关的人员都能够使用该系统。因此为了确保系统实机运行能够顺利进行，用户培训是非常必要的。一般在开发计划中应包括用户培训计划，准备与实际系统接近的培训系统，在运行测试阶段同时实施用户培训。第54页，本讲稿共79页4.5.3 从运行测试到实机运行从运行测试到实机运行 n从运行测试到实机运行作以下几点总结：运行测试要以用户为主体进行设计、实施；业务测试是在运行测试阶段实施，而不是在系统测试阶段实施；在进行运行测试前作成操作手册；尽早明确实机运行的评价基准；运行测试的设计、实施要从技术、业务、环境等多

24、方面考虑；运行测试是用户培训的最好时机。第55页，本讲稿共79页4.5.4 测试实例说明测试实例说明-单元测试n测试策略 单元测试一般总是把白盒测试法和黑盒测试法结合运用。先用黑盒测试法设计出一组基本的测试用例，然后用白盒测试法，根据覆盖标准补充新的测试用例以满足覆盖标准。一般情况下，单元测试以白盒法为主。第56页，本讲稿共79页4.5.4 测试实例说明测试实例说明-单元测试n主要工作：n根据详细设计书作成单元测试使用的程序检测清单（PCL）PCL有矩阵型矩阵型PCLPCL 和和表格式表格式PCLPCL。无论哪种格式，都有检查项目、检查条件、确认内容、确认时间等基本内容。作成PCL的主要思路是

25、针对详细设计书中的每个功能项目，列出其执行时需要的条件，确认在相对应的条件下应产生的结果。第57页，本讲稿共79页4.5.4 测试实例说明测试实例说明-单元测试n主要工作：n根据详细设计书和PCL则可作成测试数据 通常可以用一批数据来测试一个或几个PCL的检查项目，一般不采用一条数据测试一个或几个PCL。n使用问题记录表（B票）记录在测试过程中程序发生错误和对错误进行处理的相关信息。n对测试结果进行整理。在测试结果中需要注明测试的输入数据和输出数据，并标注相对应的PCL的检查项目编号。第58页，本讲稿共79页4.5.4 测试实例说明测试实例说明-单元测试n测试实例 p120n 程序检测清单（P

26、CL）n表4.11是一个矩阵型PCL p122p122n表4.12是一个表格式PCL p123n 测试数据 P121 问：要完成PCL中的所有测试项目的测试，应怎样补充测试 数据？n 问题记录表（B票）P125n 测试结果 P126第59页，本讲稿共79页4.5.4 测试实例说明测试实例说明-组合测试n组合测试需考虑的问题组合测试需考虑的问题:n 数据穿越接口可能丢失。n 一模块可能破坏另一模块功能。n 子功能组装可能未产生所要求的主功能。n 全程数据结构可能出问题。n 误差累积问题。n测试策略n由独立的测试小组进行n测试用例通常采用黑盒法设计n推进方式可采用渐增式或非渐增式n模块组合后，应进

27、行回归测试（采用软件改动前测试时执行过的测试用例对改动后的软件再进行测试。）第60页，本讲稿共79页4.5.4 测试实例说明测试实例说明-组合测试n主要工作：n测试流程和测试计划。测试流程的作成，一般可以利用基本设计的各个子系统的数据流程图，按照各个子系统的输入参数，自顶向下设计测试流程。同时，要做好测试计划，落实各个子系统的测试期间、测试人员和验收人员。nCCL。CCL的作成一般以各个子系统的相关联几个程序模块为单位进行。它主要检测各个程序模块之间的参数设置和传递是否正确，确认关联程序运行的最后结果。第61页，本讲稿共79页4.5.4 测试实例说明测试实例说明-组合测试n主要工作：n测试数据

28、。测试数据的作成要按照CCL的检查条件进行，一般要注意多个参数的各种组合条件的测试数据、数据记录条数(1条或多条)和特殊条件下的测试数据的做成。当然，基本数据文件（例如初期设定文件等），各种代码表的数据文件要事先准备好。第62页，本讲稿共79页4.5.4 测试实例说明测试实例说明-组合测试n主要工作：nB B票票。组合测试阶段的B票作成方法与单元测试阶段的B票作成方法基本相同。其目的是要把测试过程中所发现的设计不良和程序错误记录到B票中，以保证快速有效地解决问题，提高程序系统的质量。n测试结测试结果果。作成测试结果的目的首先是要使测试人员和验收人员按照CCL和测试结果对各个子系统的功能进行严格

29、检查，其次是要证明所进行的组合测试是有效的。第63页，本讲稿共79页4.5.4 测试实例说明测试实例说明-组合测试n测试实例 p127n 程序检测清单（CCL）主要检测各个程序模块之间的参数设置和传递是否正确，确认关联程序运行的最后结果。n表4.15 CCL清单 p128p128n测试数据 P127 测试数据的作成要按照CCL的检查条件进行，一般要注意多个参数的各种组合条件的测试数据、数据记录条数(1条或多条)和特殊条件下的测试数据的做成。当然，基本数据文件（例如初期设定文件等），各种代码表的数据文件要事先准备好。n 问题记录表（B票）n测试结果整理 P129第64页，本讲稿共79页4.6 软

30、件调试软件调试n测试与调试的比较测试与调试的比较n调试的步骤调试的步骤n调试困难的原因调试困难的原因n调试策略调试策略第65页，本讲稿共79页软件测试与调试 测试与调试的比较 测试测试 (test)(test)调试调试 (debug)(debug)以已知条件开始以已知条件开始,使用预先定义的程序使用预先定义的程序,有预知的结果有预知的结果以不可知内部条件开始以不可知内部条件开始,结结果一般不可果一般不可预见预见有计划有计划被动的被动的由独立的测试组，在由独立的测试组，在不了解软件设计的条不了解软件设计的条件下完成件下完成由程序作者进行由程序作者进行发现错误发现错误找出错误位置，排除找出错误位置

31、，排除第66页，本讲稿共79页软件调试n调试的步骤n从错误的外部表现形式着手，确定出错位置；n研究有关部分的程序，找出出错的内在原因；n修改设计和代码，以排除有关错误；n进行回归测试，以确认错误是否排除，是否引起新的错误；n若不能通过回归测试，则撤消此次修改活动，恢复设计和代码至此次修改之前的状态，并重复上述过程，直到错误得以改正。第67页，本讲稿共79页软件调试n调试困难的原因n心理方面：高度焦虑、不愿接受可能发现的错误n错误本身的特点n错误症状和引起错误的原因相隔很远（高度耦合的程序结构）；n错误症状可能在另一个错误被纠正后消失或暂时消失；n错误症状可能实际并不是由错误引起的（如误差）；n

32、错误症状可能是由不易跟踪的人工操作引起的；第68页，本讲稿共79页软件调试n调试困难的原因n错误本身的特点(续)n错误症状可能是和时间相关，而不是处理问题；n很难再现错误症状的输入条件；n错误症状可能时有时无（如在软硬件结合的嵌入式系统中）n错误症状可能是由于把任务分布在若干不同处理器上运行而造成第69页，本讲稿共79页软件调试n调试策略n猜测法 通过分析错误症状，根据以往的经验，辅助使用已有的计算机工具，猜测错误的原因并进行定位。n在程序中插入打印语句n使用注释或GOTO语句运行部分程序n使用调试工具第70页，本讲稿共79页软件调试n调试策略n跟踪法 检查错误征兆，确定最先发现错误“症状”的

33、位置，然后人工沿程序的控制流往回跟踪源代码，直到找出错误的根源；也可以向前跟踪每条语句的执行情况，找到最先出现错误的地方进行分析 第71页，本讲稿共79页软件调试n调试策略n原因排除法:先假定错误原因，然后利用数据证明或否定假设（归纳法）；或先列出所有可能的原因，然后逐一排除。（演绎法）收集有关数据组织数据研究数据间的关系提出假设证明假设纠正错误不能不能能能归纳法调试的过程第72页，本讲稿共79页软件调试n调试策略n原因排除法:先假定错误原因，然后利用数据证明或否定假设（归纳法）；或先列出所有可能的原因，然后逐一排除。（演绎法）列举可能原因排除不会发生的原因收集更多的测试结果分析余下的原因证明

34、假设纠正错误无剩余有剩余能不能演绎法调试过程第73页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程 n定义 nANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”nM.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”第74页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程 n软件的质量特性 质量特性 说明1、功能性 按照使用目的，正确运行。2、可靠性 软件运行过程中不会发生突然中断等故障。3、使用性 用户容易理解、学习、操作。4、效率性 具备要求的运行速度和数据、信息的处理量

35、。5、维护性 容易维护和修改。6、移植性 容易移植。第75页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程n软件质量反映了以下三方面的内容:n 软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。n(2)在各种标准中定义了一些开发准则，用来指导软件开发人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。n(3)会有一些隐含的需求没有明确地提出来。例如，软件应具备良好的可维护性。第76页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程n提高软件开发质量的基本方法 提高质量防止发生问题（早期发现问题）发现并修正问题（测试发现问题）需求定义概

36、要设计详细设计程序制造测试第77页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程 早期防止问题发生，通常采用早期防止问题发生，通常采用4 4种做法：（种做法：（1 1）信息交流，）信息交流，（2 2）经验积累，（）经验积累，（3 3）文档化，（）文档化，（4 4）设计评审）设计评审 交流信息的方法交流信息的方法定期会议电视会议电子传言利用互联网信息交流积累经验的方法积累经验的方法过去做过的项目的再利用为新项目准备必要的资料整理开发注意事项和基准对发现问题采取的对策研讨经验积累项目计划书需求定义书概要设计书详细设计书作业基准、规范文档化设设计计评评审审方法方法会议评审演示循环演讲内容内容需求调查责任者以召集会议的形式进行设计评审对相关人员进行模拟程序运行演示设计人员分别说明各自设计的内容设计评审第78页，本讲稿共79页4.7 软件质量与测试工程软件质量与测试工程n测试工程应注意的事项 测试工程需要充分的时间和工数；必须保证进入测试工程前的软件开发质量；针对软件的特性考虑软件最重要的质量特性，确定测试的优先顺序；进入测试工程后必须采取各种有效措施，尽最大努力发现软件的问题和缺陷；利用可靠性成长曲线监视测试的效果和进度；活用业务对象的相关知识、信息技术的知识，扩大视野规划测试工程。第79页，本讲稿共79页