软件测试培训教程_软件开发管理

PPT 内容
PPT 图集

1. 软件测试培训教程研发部 2010年11月
2. 培训内容软件测试理论基础软件测试流程软件项目运作流程软件测试工作流程软件测试用例设计方法软件缺陷测试的技巧测试工具的选择软件的测试整个过程
3. 软件测试理论基础
4. 测试行业简介软件测试在软件生命周期中占据重要作用。软件生命周期的每个阶段都应该包含测试从而检验本阶段的成果是否接近预期的目标，尽可能早的发现错误并加以修正。由于测试的重要性和复杂度，它慢慢的独立发展成为一个行业，并且在迅猛发展。在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的 40 ％以上。而在软件开发的总成本中，用在测试上的开销要占 30 ％到 50 ％
5. 软件测试概论（概述）1975年，“测试数据选择的原理”（Toward a theory of Test Data）的文章，软件测试才被确定为一种研究方向。 1979年，“软件测试时为发现错误而执行一个程序或者系统的过程” 1983年，“测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的一种度量”。 2002年，“测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施、维护的的整个生命周期过程”。
6. 软件测试概论（行情）国外： A、软件测试在软件公司中占有重要的地位 B、软件测试理论研究蓬勃发展，引领软件测试理论研究的国际潮流 C、软件测试市场繁荣国内： 1、我国著名的软件公司都已经或者正在建立独立的专职软件测试队伍 2、国家开始对软件测试职业高度重视和认可（软考中级资格中增加软件评测师）
7. 软件测试概论（行情）3、用户对软件质量要求越来越高，通过第三方测试机构的严格测试来判定 4、市场需求量不断增大，软件测试工程师的待遇也在不断提高。北京地区的薪资趋势大致如图1-1所示。图1-1 薪资趋势图
8. 测试工程师的职业发展软件测试工程师一般有几个方向可走，如图1-2所示。一个理想的测试工程师应该有开发经验，至少要有开发的概念。仅仅发现Bug是测试的初步，而分析出根本原因，却要有很深的功底。初级测试工程师中级测试工程师开发工程师测试管理者高级测试工程师图1-2 职业发展规划图
9. 企业需要怎样的测试人才？一年以上软件测试经验计算机相关专业大专以上学历了解软件工程，熟悉软件测试过程和标准，熟悉配置管理技术和工具能够编制测试计划、设计测试用例、编写Bug报告和测试总结报告、使用测试工具、开发测试脚本熟练使用Windows或Unix或Linux操作系统
10. 企业需要怎样的测试人才？熟练C、C++、Java、VB、Delphi、C#中的一种以上熟练使用SQL Server或Oracle数据库了解业务领域（ERP、OA、电子商务、税务系统、电信计费系统……）熟练掌握至少一种以上的测试工具，如TestDirector、QTP、LoadRunner、Robot 进取、合作、表达、沟通、责任心、耐心、认真程度
11. 测试学习路线对于软件测试初学者，我们要切合实际、循序渐进的学习，在学习中可参考图1-3所示的软件测试学习路线图，从软件测试的理论基础，到项目实战，逐步学习，掌握技术技能，最终胜任软件测试工作。初学者软件测试理论基础学习缺陷管理知识学习Web测试环境搭建学习Linux操作系统知识学习配置管理知识学习数据库知识学习QTP功能测试工具学习LoadRunner性能测试工具学习项目实战岗前培训面试技巧工作图1-3 软件测试学习路线图
12. 软件测试由来调试在已知错误的情况下，对软件程序代码做出的一系列检查，校正的过程。测试在未知错误的情况下，检查程序代码是否有问题的过程。区分：软件测试从软件质量保证的角度来检查程序代码是否有误，而调试是为了解决当前已知的错误，调试活动无法替代软件测试活动。
13. 软件测试定义定义：软件测试就是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。软件测试应该是对软件形成过程的文档,数据以及程序进行的测试,而不仅是对程序进行的测试。 60%以上的软件错误并不是程序错误,而是分析和设计的错误,提倡软件全生命周期测试的理念。
14. 什么是软件质量1991年国际标准ISO 9126中定义为:软件满足规定或潜在用户需求的总和。 1999年国际标准ISO 14598中定义为:软件特性的总和，软件满足规定或潜在用户需求的能力。 2001年国际标准ISO 9126中定义为：软件满足规定用户或潜在用户需求的能力，要从软件在内部，外部和使用过程中的表现来衡量，包含内部质量、外部质量、和使用质量。
15. 软件测试与质量保证的区别软件质量保证和软件测试是软件质量工程中两个不同层面的工作。质量保证(QA):质量保证的重要工作通过预防，检查与改进来保证软件质量(所关注的是软件质量的检查与测量,着眼于软件开发的过程,步骤和产物)。软件测试：测试过程虽然与开发过程紧密相关但，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。
16. 软件测试的目的和原则基于不同的立场，存在着两种完全不同的测试目的：用户角度：希望软件测试暴露软件中隐藏的错误和缺陷，已考虑是否接受产品。软件开发者角度：希望测试成为表明软件产品中不存在错误的过程，验证被测软件已正确的实现了用户的需求，确立人们对软件质量的信心。
17. 软件测试的目的和原则换言之，测试的目的是：想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据测试不能表明软件中不存在错误，它只能说明软件中存在错误
18. 软件测试的目的和原则软件测试的原则：所有的软件测试都应追溯到用户需求。应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。完全测试是不可能的，测试需要终止。测试无法显示软件潜在的缺陷。也就是说测试只能证明软件存在错误而不能证明软件没有错误。
19. 软件测试的对象根据软件定义，软件包括程序，数据和文档，所以软件测试并不仅仅是程序测试，软件测试应该贯穿整个软件生命周期中。需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序。
20. 软件测试的对象为了把握各个环节的正确性，人们需要进行各种验证和确认工作：验证(verification)：是保证软件正确实现特定功能的一系统活动和过程,目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。确认(validation)：是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件，用户需求相符合。
21. 软件测试的对象
22. 软件测试分类一般的，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手动测试、自动测试
23. 软件测试分类—黑盒测试黑盒测试又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该测试类别注重于测试软件的功能性需求。测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终端用户使用该软件，检查软件产品是否达到了用户的需求。如图1-4所示为黑盒测试实例图。黑盒测试能更好的从用户角度来考察被测系统的功能性需求实现情况。测试用例测试结果图1-4 黑盒测试示例图
24. 软件测试分类—白盒测试白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部构成的测试。白盒测试需要测试工程师深入考查程序代码的内部结构、逻辑设计等。就像前面的例子，我们拆开手机，观察手机电路板的设计，液晶屏的构成等。对于白盒测试工程师来说，软件产品的内部结构是敞开的。如图1-5所示是白盒测试示例图。程序内部结构测试用例测试结果图1-5 白盒测试示例图
25. 软件测试分类—灰盒测试灰盒测试介于白盒和黑盒测试之间。灰盒测试一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。通俗地讲，灰盒测试就是白加黑。像我们的性能测试，自动化功能测试就是采用了灰盒测试的方法。图1-6是灰盒测试的示例图。测试用例测试结果图1-6 灰盒测试示例图
26. 软件测试分类—静态测试定义：静态的、不执行被测对象程序代码而寻找缺陷的过程。在进行静态测试时可采用一些代码走查工具，如QAC++、C++Test等。
27. 软件测试分类—动态测试实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用力中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。动态测试有四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。动态测试有三种主要方法：黑盒测试、白盒测试和灰盒测试
28. 软件测试分类—手动测试它是测试人员设计测试用例并执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果，最终输出测试报告的测试活动。可充分发挥测试工程师的主观能动性，将其智力体现在测试工作中，能发现许多的缺陷，但同时又有一定的局限性和单调枯燥性。
29. 软件测试分类—自动化测试定义利用测试工具，模拟用户业务使用流程，让他们自动运行来查找缺陷。优点快、广泛、可重复性工作缺点只可检查比较主要的问题，如崩溃、死机，无法发现一般的日常错误。编写脚本工作量也很大，有时会超过手动测试时间。我们要根据实际情况选择或者不选择测试工具，选择使用何种测试工具，不能为了实用工具而可以的去使用工具。
30. 软件测试人员职业要求从个人素质角度要求测试工程师需要具备以下6种素质：责任心沟通能力团队合作精神耐心、细心和信心时时保持怀疑态度、并且有缺陷预防的意识不断学习的能力
31. 软件测试流程
32. 软件测试流程图软件测试虽然是软件生存周期的一个独立阶段，但测试工作却渗透到从分析、设计直到编程的各个阶段中（1-7是软件测试所经阶段的一般流程）。需求测试、单元测试、集成测试、系统测试、性能测试、用户测试、回归测试需求测试单元测试集成测试系统测试性能测试用户测试回归测试图1-7 软件测试流程图
33. 需求测试要从以下几个方面考虑需求测试：完整性正确性一致性可行性无二义性健壮性必要性可测试性可修改性
34. 单元测试又称模块测试，就是对程序代码中最小的涉及模块单元进行测试。在单元测试中我们主要采用静态测试与动态测试相结合的办法。单元测试要求需要几年的代码编写经验，并且要十分熟悉当前的被测系统，以及该系统是否与其他系统的接口关联情况。单元测试在编码阶段占据非常重要的地位。可以降低编码的错误率，提高编码质量
35. 集成测试又称组装测试，是将软件产品各个模块组装起来，检查接口是否存在问题，以及组装后的整体功能、性能表现。一般可采用非增式集成方法、增式集成方法（自底向上集成、自顶向下集成、组合方式集成）等策略进行测试，利用一黑盒测试为主，白盒测试为辅的测试方法进行测试。主要解决各个组成但源代码是否符合开发规范、接口是否存在问题，整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等。
36. 系统测试将通过集成测试的软件部署到某种较为复杂的计算机永华环境进行测试。目的：通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。这个阶段主要进行的是安装卸载测试、兼容性测试、功能确认测试、安全测试等。采用黑盒测试法，主要考察被测软件的功能与性能表现。
37. 性能测试性能测试要求被测软件在业务处理速度、处理能力和所耗用的硬件系统资源比率满足用户的需求。不要尝试用手动方式进行性能测试，应当编写一段相应的程序或者使用专门的工具进行，如利用LoadRunner自动化性能测试工具。性能测试相对难度较大，要求测试人员掌握编程语言，精通业务流程，拥有深厚的项目经验。
38. 用户测试可称为用户确认测试。正式验收前，需要用户对本系统做出一个评价，用户可对交付的系统做测试，并将测试结果反馈回来，进行修改、分析。用户测试环节是被测试软件首次作为正式的系统交友用户使用，用户会根据他们的实际使用情况进行测试、使用，并提出实际使用过程中的问题。用户测试是软件生产流程中的最后质检关。
39. 回归测试回归测试是经过一段时间以后再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。有些时候可采用自动化测试工具来进行回归测试，如利用QTP 一般情况下，都由测试工程师手动的执行一千的测试用例。来检查用例通过情况。
40. 软件项目运作流程
41. 软件项目运作图市场调研可行性研究产品立项需求调研设计开发系统测试产品发布产品维护产品升级图1-8 软件项目运作图
42. 市场调研1、主动模式将公司或者企业作为需求接收的被动方，而需求的提出作为主动方。 2、被动模式在没有明确的需求提出者时，有公司或企业主动提出给特定使用用户群提供某种产品的模式。市场调研主体：市场人员、销售人员调研方式：客户走访，市场观察，报刊媒体等输出文件：《XXX项目市场调研分析报告》
43. 可行性研究以预测为前提，以投资效果为目的，从技术上、管理上进行全面综合分析研究的方法。基本任务：对新开发产品或升级产品从技术经济角度进行全面的分析研究，并对其投产后的经济效益进行预测，在既定的范围内进行方案论证的选择，以便最合理的利用资源，达到预定的社会效益和经济效益。主体：市场人员、销售人员对象：在市场调研阶段产生的《XXX项目市场调研分析报告》输出文件：《XXX项目可行性分析报告》
44. 产品立项在前期的市场调研、可行性研究经过评审可行后，则由需求调研人员牵头，进行产品立项，并进行产品小组的建立，同时制定产品的运作计划，如需求调研、产品设计、产品测试、产品发布等一系列的工作步骤及时间点。立项负责人：市场调研人员工作内容：提交产品立项申请，审批通过后，指定产品计划书，确定产品各个阶段的工作流程及时间进度表。
45. 需求调研1、主动模式 2、被动模式需求调研参与人员：市场人员、开发人员、测试人员等调研对象：客户或假象客户（广泛应用群）输出：需求规格说明书
46. 设计开发由系统架构师进行系统的概要设计，主要从稳定性、安全性、扩展性、可维持性等方面进行设计。设计人员：系统架构师、项目开发小组输出：项目开发计划、概要设计文档、详细设计文档、数据库文档等
47. 系统测试按照前期的测试计划，利用测试用例进行系统的功能、性能测试。在经过多次版本的迭代后，完成系统测试，输出测试报告。测试人员：项目测试小组输出：测试计划、测试方案、测试用例、功能测试报告、性能测试报告等
48. 产品发布经过开发部门、测试部门和其他部门的努力，产品在预定的日期完成，有项目组择日发布。发布人员：项目实施人员、市场部等输出：客户现场项目实施报告等
49. 产品维护交付使用后，需根据需求调研阶段协议，制定产品维护流程，出现问题需及时解决，直到产品使用废弃或升级，进入新的生命周期。
50. 产品升级在软件产品使用到一定期限后，可以根据先前的约定进行升级，或根据客户新的需求，再次进行新需求的调研开发等。
51. 软件测试工作流程
52. 测试部门组织结构1、人员构成测试主管、测试组长、环境保障人员、配置管理员、测试设计人员、测试工程师测试主管测试组长环境保障人员软件测试部配置管理员测试设计人员测试工程师图1-9 测试部人员结构图
53. 测试部门组织结构2、测试主管负责测试部门日常管理工作。 3、测试组长测试主管根据项目情况，指派合适的测试人员但当测试组长。 4、环境保障人员维护整个项目过程中的系统环境，如硬件、软件方便的。由测试人员兼任。 5、配置管理员是软件开发过程中的一个重要工作流程面对需求变更、版本迭代、文档审核起到相当大的作用。
54. 测试部门组织结构6、测试设计人员一般由高级测试工程师担当，负责测试方法设计、测试用例设计及功能测试、性能测试的步骤、流程设计。 7、测试工程师执行测试用例，进行系统的功能测试，经过多次版本迭代，完成系统测试。 8、技术构成白盒测试技术、黑盒测试技术、自动化测试技术人员、项目管理技术人员白盒测试技术人员黑盒测试技术人员软件测试部自动化测试技术人员项目测试技术人员图1-10 测试部技术构成图
55. 测试部门组织结构9、白盒测试技术人员该职位测试人员需要精通软件开发语言，要有几年的开发经验，能进行底层的代码review，测试桩设计等，同时能够食用百合测试工具对系统的最小功能单元进行测试，找出代码、系统架构方面的缺陷。 10、黑盒测试技术人员要求测试人员有一定的软件工程理论、软件质量保证知识。 11、自动化测试人员需测试人员掌握软件开发的知识，系统的调优，自动化测试工具，如QuickTest Professional LaodRunner。
56. 测试部门组织结构12、项目管理技术人员要求掌握一般的项目管理知识，如配置管理、版本控制、评审管理、项目实施与进度控制等。 13、资源构成 14、硬件资源需要齐备的测试环境，如测试PC机、测试服务器、测试芯片、测试手机等。硬件资源软件测试部软件资源技术支持图1-11 测试部资源构成图
57. 测试部门组织结构15、软件资源测试需要的操作系统、应用软件、管理软件等。如Windows、Linux等操作系统，SQL Server、Oracle等数据库软件，QuickTest Professional LaodRunner等自动化测试工具。 16、技术支持当测试人元遇到问题不能解决时，可由兄弟部门给予支持。确保在一个团队合作的环境下，更高效的完成测试工作。
58. 测试工作流程测试准备阶段测试工作流程测试开展阶段测试输出阶段图1-12 测试工作流程图
59. 测试工作流程1、测试准备阶段测试计划制定测试小组建立项目经理测试主管测试组长部署测试任务指派测试组长获取测试需求及相关文档图1-13 测试工作介入流程图测试组长测试主管测试工程师小组工作会议申请小组成员指定小组成员图1-14 测试小组建立图
60. 测试工作流程需求测试启动测试需求提取分配任务测试组装需求调研部门校正需要提供需求测试小组反馈结果图1-15需求测试流程图测试组长测试小组测试工具分配任务编写用例图1-16 部署测试需求提取任务流程图
61. 测试工作流程测试用例编写测试组长测试小组测试工具分配任务编写用例图1-17 部署测试用例编写任务流程图
62. 测试工作流程2、测试开展阶段搭建测试环境—测试组长，可根据说明说中的软件产品运行环境配置要求搭建。测试环境最好与开发环境分开文档引入—工作日报、功能测试报告、性能测试报告等模板执行测试—根据项目的Bug管理流程，经过多次的版本迭代，完成测试工作。
63. 测试工作流程3、测试输出阶段测试计划测试方案测试用例测试工程师的工作日报功能测试报告性能测试报告
64. 思考与练习1、软件测试共有几种模型？具体的内容是什么？相互之间有什么区别与联系？ 2、简要描述同行评审与阶段评审的区别。 3、软件测试与软件开发的关系是什么？ 4、什么叫软件测试？软件测试的目的是什么？
65. 思考与练习5、软件测试的一般工作流程是什么？ 6、软件测试的测试流程是什么？各阶段的工作内容重点是什么？ 7、当你接到一个测试任务后，你如何开展测试工作？
66. 软件测试用例设计方法
67. 什么是测试用例测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
68. 测试用例包含要素每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。具体可以参考建行测试用例模板
69. 黑盒测试案例设计技术测试用例设计：将软件测试的行为活动，作为一个科学化的组织归纳。测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。因为我们不可能进行穷举测试，为了节省时间和资源、提供测试效率，必须从数量极大的可用测试数据精心挑选出具有代表性或者特殊性的测试数据来进行测试。
70. 测试测试用例的好处在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。功能测试模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
71. 常见黑盒测试用例设计方法等价类划分法边界值分析法错误推测法因果图法判定表驱动法正交试验设计法功能图法场景法
72. 等价类划分法等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。划分等价类和列出等价类表确定测试用例
73. 划分等价类和列出等价类表等价类是指输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效，并合理地假设：测试某等价类的代表值就等于对这类其他值的测试。等价类划分有两种不同的情况：有效等价类和无效等价类。
74. 划分等价类和列出等价类表有效等价类：指对于程序的规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。
75. 6条确定等价类的原则1、在输入条件规定了取值范围或者值个数的情况下，可以确定一个有效等价类和两个无效等价类。 2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。 3、在输入条件是一个布尔量的情况下，可以确定一个有效的等价类和一个无效的等价类
76. 6条确定等价类的原则4、在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确定n个有效的等价类和一个无效的等价类。 5、在规定了输入数据必须遵守的规则的情况下，可以确定一个有效等价类类（符合规则）和若干个无效等价类（从不同角度违反规则）。 6、在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
77. 确定测试用例步骤为每个等价类规定一个惟一的编号。设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步，最后使得所有的有效等价类均被测试用例所覆盖。设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
78. 等价类划分法例题一个程序读入3个整数，把这3个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。构成三角形的3条边必须满足： A>0,B>0,C>0，且A+B>C,B+C>A,A+C>B 如果是等腰的，还要判断A=B,或者B=C,或者A=C 如果是等边的，则需要判断是否A=B,且B=C,且A=C.
79. 等价类表输入条件有效等价类无效等价类是否三角形的3条边(A>0） (1) (B>0） (2) (C>0） (3) (A+B>C) (4) (B+C>A) (5) (A+C>B) (6) (A≤0） (7) (B≤0） (8) (C≤0） (9) (A+B≤C) (10) (B+C≤A) (11) (A+C≤B) (12) 是否等腰三角形(A=B）(13) (B=C) (14) (C=A) (15)(A≠B)and (B≠C)and (C≠A) (16) 是否等边三角形(A=B）and (B=C) and (C=A) (17)(A≠B) (18) (B≠C) (19) (C≠A) (20)
80. 设计测试用例
81. 边界值分析法边界值分析：是考虑边界条件而选取测试用例的一种黑盒测试方法，是对等价类划分方法的补充。实践证明，软件在输入、输出域的边界附近容易出现差错，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
82. 边界值分析法使用边界值分析方法设计测试方案首先应该确定边界情况，通常输入等价类和输出等价类的边界，就是应该注重测试的程序边界情况。选取的测试数据应该正好等于、刚刚小于和刚刚大于边界值，也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。
83. 基于边界值分析方法选择测试用例的原则如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。根据规格说明的每个输出条件，考虑值的范围情况。
84. 基于边界值分析方法选择测试用例的原则。根据规格说明的每个输出条件，考虑值的个数情况。如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例分析规格说明，找出其它可能的边界条件。
85. 错误推测方法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
86. 错误推测方法常见依据在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等。已发现缺陷的测试方法的推广。容易发生错误的情况。补充等价类和边界值法遗漏的一些等价类组合。一些位置使用了共享变量，设计测试用例，修改一个共享变量，看其他位置有没有同时做修改
87. 因果图设计方法因果图方法是对等价类的扩展，可以理解为 “ 等价类组合判定表 ” 。因果图即输入等价类与输出等价类的关系图
88. 因果图生成测试用例的基本步骤分析软件规格说明描述中，那些是原因 ( 即输入条件或输入条件的等价类 ) ，那些是结果 ( 即输出条件 ) ，并给每个原因和结果赋予一个标识符。分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系。根据这些关系，画出因果图。
89. 因果图生成测试用例的基本步骤表明约束条件。由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。把因果图转换成判定表为判定表中每一列表示的情况设计测试用例。
90. 正交试验法正交试验设计方法：是从大量的试验数据中挑选适量的、有代表性的点，从而合理的安排测试的一种科学的试验设计方法
91. 正交试验测试用例设计步骤提取功能说明，构造因子状态表。加权筛，生成因素分析表利用正交表构造测试数据集。
92. 正交试验法优点节省测试工时。可控制测试用例的数量。测试用例具有一定的覆盖率。正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式是最好的，每个参数可能就是一个因子，参数的不同取值就是平水，采用正交试验法设计出最少的测试组合，达到有效测试目的。
93. 功能图分析方法功能图方法：用功能图形象地表示程序功能说明，并生成功能图的测试用例。又可以称作流程测试或状态迁移测试类似于白盒测试中的逻辑覆盖和路径法需要懂得控制语句（循环，顺序，选择，重复）
94. 功能图生成测试用例过程在每个状态生成局部测试用例。测试路径生成：从初始状态到最后状态的测试路径测试用例合成：合成测试路径和功能图中每个状态的局部测试用例。测试用例合成算法：条件构造树。
95. 场景法事件触发控制流程，事件触发时的情景便形成场景。同一事件不同的触发顺序和处理结果就形成事件流用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径的有基本流和备选流。
96. 测试用例选择的综合策略1、首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的有效方法。 2、在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强
97. 测试用例选择的综合策略3、可以用错误推测法追加一些测试用例，这些需要依靠测试工程师的智慧和经验。 4、对照程序逻辑，检查已设计的测试用例的逻辑覆盖程序，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 5、如果程序的功能说明中含有输入条件的组合，则一开始就可以选因果图法和判定表驱动法。 6、对参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的测试效果
98. 测试用例选择的综合策略7、功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。 8、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
99. 软件缺陷
100. 什么是软件缺陷符合下面 5 条规则之一的问题称为软件缺陷： 1、软件未达到产品说明书标明的功能。 2、软件出现产品说明书指明不会出现的错误。（如果软件含有产品说明中根本没有存在的功能，这是缺陷） 3、软件功能超出产品说明书指明的范围。 4、软件未达到产品说明书未指出但应达到的目标。（产品说明书虽然没有提到，但是按照常理应该达到的功能） 5、软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。
101. 缺陷的生命周期简单周期：测试员找到并登记软件缺陷，软件缺陷移交到程序员=>程序员修复软件缺陷，软件缺陷移交到测试员=>测试员确定软件缺陷被修复，测试员关闭软件缺陷。
102. 缺陷的生命周期复杂周期：发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员）=>软件缺陷移交到项目管理员=>（以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员=>重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员）=>项目管理员同意缺陷需要修复，缺陷转给程序员=>以修复形式解决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷）=>缺陷关闭
103. 报告缺陷的要点复杂周期：发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。参考软件测试缺陷跟踪管理说明.pdf文档（ vss\09_测试团队\公共\规范说明）
104. 缺陷的严重性分类A类——致命性：不能完全满足系统要求，基本业务功能未实现系统崩溃、不稳定或挂起等导致系统不能继续运行、导致系统出现不可预料的严重错误的问题。
105. 缺陷的严重性分类B 类 —— 严重错误：严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启动不属于更正办法）。使系统不稳定、破坏数据、产生错误结果，部分功能无法执行。
106. 缺陷的严重性分类C 类 —— 一般性错误： 1、界面错误。  2、非重要功能无法正确执行，实现不正确，实现不完整，但不影响功能  3、非严重性产生错误结果，但不影响一起功能。  4、正确性不受影响，但系统性能和响应时间受到影响。
107. 缺陷的严重性分类D 类 —— 轻微错误：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能，或对最终结果影响有限的问题。
108. 缺陷的严重性分类E 类 —— 测试建议：不影响系统运行，对系统的可用性等提示的建议性的问题。例如： 1、系统各个位置初始值的建议。  2、流程优化建议等等。
109. 缺陷分析缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标
110. 缺陷分析主要参数状态：缺陷的当前状态（打开的、正在修复或关闭的等）。优先级：必须处理和解决缺陷的相对重要性。严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件
111. 缺陷分析报告可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据
112. 软件测试的技巧
113. 测试技巧分类结构测试相对于功能测试动态测试相对于静态测试手工测试相对于自动测试
114. 结构测试技巧压力测试执行测试恢复测试操作测试复合性测试（与过程的复合性) 安全测试
115. 压力测试目标模拟出实际用户环境怎么用产生测试数据测试组模拟用户处理被创建的数据例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况什么时间使用当关于容量的信息不确定的时候
116. 性能测试技巧目标确定系统达到了希望达到的性能水平如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监控创建一个小程序例子计算通信的时间单位时间处理的信息量什么时候使用－在程序开发的早期进行
117. 恢复测试目标当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作如何使用程序的安装，运行方式，工具的使用和关键技术经过足够的评估系统开发完毕后，介绍一下发生失败后的处理过程例子人为的使一个系统在安装或者组装过程中产生错误什么时间去使用当操作的连续性是个重点的时候
118. 操作测试目标确定计算机的操作文档已经完整如何使用作为计算机正常操作的一部分来执行测试例子操作的介绍被文档化，操作者被培训什么时候使用预先将程序进行产品化。操作性是系统的一个重要指标的时候。
119. 复合性测试目标校验程序的开发是否依照已定义的标准，流程和操作方式进行的。如何去使用将文档/程序同标准相比较比较有效的方法是检查过程例子代码互查（一行一行）什么时候使用依赖于管理的需要
120. 安全性测试目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。如何使用对安全性的需求进行评审分析与安全性有关的处理流程转包给专业的人员例子定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。什么时间使用当被保护的资源对于组织具有重要的价值的时候
121. 功能测试技巧需求测试回归测试错误处理测试支持手册的测试系统兼容测试控制性测试并行测试
122. 需求测试目标用户的需求可以被实现如何使用创建测试用例和功能检查列表例子建立测试矩阵去证实系统需求均被文档化什么时候使用每一个应用程序都要进行需求测试
123. 回归测试目标程序修改后，确保功能的正确性如何使用重新测试应用程序中没有改变的部分例子重新执行以前的测试用例什么时间使用当新的程序有可能影响老的功能的时候
124. 错误处理测试目标所有可能的错误条件均经过了验证如何使用一组有经验的人员预测在那里会出现问题例子建立一个错误处理的列表什么时候使用贯穿整个开发生命周期
125. 支持手册测试目标检验操作过程被文档化了，并且完整了。如何使用对过程有足够的介绍可以协助用户正常使用例子系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。什么时候使用最佳时机是在安装测试的时候，但是应该在开发全过程中。
126. 兼容性测试目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换如何使用文件和数据被用来在多系统之间传递。例子典型的由一个系统到另一个系统的数据交换程序。什么时候使用当两个应用程序之间的参数有可能发生变化的时候
127. 管理能力测试目标验证数据交换时有足够的审计追踪能力如何使用关键数据或者有价值的数据例子从负面来看程序，是否确保了会出错的条件都被保护了。什么时候使用系统测试的一部分
128. 并行测试目的新版本和老版本同时运行，用以确保新版本的程序运行正确。如何使用需要对两个系统输入相同的数据来运行例子运行新旧两个工资支付系统什么时间使用当对新系统的的运行情况不确定的时候
129. 单元测试关注单元一级代码分析和测试功能分析和测试结构分析和测试以错误为导向的分析和测试
130. 测试要素/测试技巧矩阵测试要素压力执行恢复操作复合性安全性需求回归错误处理手工支持系统兼容管理并行单元可靠性√√√√√授权√√√文件完整性√√√√审查追踪√√√过程连续性√√√√
131. 测试要素/测试技巧矩阵测试要素压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元服务水平√√√权限控制√一致性√√√√正确性√√√√√√√√易用性√√√√可维护性√√兼容性√√耦合性√√√性能√√√√可操作性√√
132. 测试工具的选择
133. 测试工具测试标准边界值分析因果图检查表代码比较对照以编译为基础的分析确认/检查控制流分析
134. 测试工具能证明正确性的数据以覆盖为基础的测试数据字典数据流分析以设计为基础的功能测试设计评审桌面检查灾难性测试
135. 测试工具错误猜测执行的规则全面的测试实况调查流程图检查,视察使用仪器设备综合测试设备映射图
136. 测试工具建模并行操作并行模拟代码互查风险矩阵系统控制的评审得分快照(把系统一个时刻的情况保存下来)
137. 测试工具完成特征系统日志测试用例测试用例的产生形式跟踪工具程序容量的测试走查(讲解开发思路)
138. 选择和使用测试工具按照用途选择匹配的工具在适当的生命周期选择工具按照测试人员的实际技能选择匹配的工具选择一个可提供的工具
139. 测试工具/测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元确认测试标准√√√√边界值分析√√因果图√√√√√检查表√√√√√√√√√√√√代码比较√√编译分析√√确认/检查√√√√√√√√√控制流√证明正确性的数据√√√√√√
140. 测试工具/测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元以覆盖为基础的测试√数据字典√√数据流分析√以设计为基础的功能测试√设计评审√桌面检查√√√√√灾难性测试√√√错误猜测√√√√√√√√√√√√执行规则√全面的测试√√√√√√√
141. 测试工具/测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元实况调查√√√√√√√流程图√√√√√检查√√√√√√√√√√√√√使用仪器√√√√√√√综合测试设备√√√√√√√√映射图√建模√并行操作√并行模拟√代码互查√√√√√
142. 测试工具/测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元风险对照表√√系统控制审计评审√√√打分√系统快照√特征执行√系统日志√√√√√√√测试数据√√√√√√产生测试数据√√√√√√跟踪√工具程序√√√
143. 测试工具/测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元容量测试√走查√√√√√
144. 软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护确认测试标准√√边界值分析√√因果图√√检查表√√√√√√代码比较√编译分析√基础复杂度量测试√√控制流分析√验证、检查√√√√√√正确性数据√√覆盖测试对照表√√数据字典√
145. 软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护数据流分析√设计为基础的功能测试√√设计评审√桌面检查√√√√灾难性测试√√错误猜测√√√√√√执行规范√全面的测试√实况调查√√√√√√流程图√√√检查√√√√√√使用仪器√√√
146. 软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护综合测试工具√映射图√模型√√并行操作√并行模拟√代码互查√√√√√√风险列表√√系统控制审计评审√打分√√系统快照√完成特征√系统日志√√√
147. 软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护测试用例√√√√测试用例得产生形式√√跟踪√√工具程序√√√容量测试√走查√√√
148. 测试工具管理工具管理者的职责对工具负责帮助同事使用这些工具培训工具得使用方法负责同工具的厂家联系每年给出有关工具使用和购买得计划工具得升级工具情况报告工具管理者得任期不易太长
149. 测试工具管理工具管理者的职责对工具负责帮助同事使用这些工具培训工具得使用方法负责同工具的厂家联系每年给出有关工具使用和购买得计划工具得升级工具情况报告工具管理者得任期不易太长
150. 软件的测试整个过程估算测试计划需求设计编码测试总结安装，交付维护
151. 估算
152. 估算什么测试对软件工作量的估算的准确性测试评估软件系统的状况的准确性关注点：不准确的估算不适当的开发过程不真实的状态报告
153. 对工作量的估算如何知道对工作量的估算是正确的估算工作量的工具很容易出错对软件工作量的估算需要策略五个一般的方法猜加入一些约束条件以一些数据为基础模拟进行工作将一些参数模型化
154. 参数模型法回归模型：将现有的参数与已有的历史数据相拟和。启发式模型：对历史数据进行观察和解释现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。
155. 模型遵循的共同模式估算软件的大小将大小转化成人力的估算，并且作出可能的成本的估算依据项目的特性进行估算的调整将整体的估算划分到不同的项目阶段中估算不包括技巧上面的人力和计算机的运行时间将以上内容相加
156. 对估算进行检验检验估算模型的合理性检验模型是否包含了必须的测试要素检验模型的正确性
157. 校验估算模型的正确性重新进行估算校验输入是否正确校验输入是否合理校验对数据的计算是否合理有效比较延期的估算是否符合项目实际情况让谨慎的人来作测试验证工作对软件中的冗余价值估算
158. 影响估算正确与否的因素软件规模新设计新代码的比例复杂程度设计和编码的困难使用什么语言安全性需求的挥发性
159. 影响估算正确与否的因素组织因素项目计划人员开发环境计算机资源人员利用率膨胀因素估算就是估算，不是保证书
160. 软件进展测试追踪系统的瓶颈工作完成点同配置管理系统紧密的结合如何使用模块列表里程碑工作完成点用计算所有工作的完成度来检查系统工作过程。
161. 测试计划
162. 开发测试计划目标详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。可能的不利因素：没有得到足够的培训心里准备不足缺乏测试工具缺乏管理的标准和支持缺乏客户和最终使用者的参与没有足够的时间进行测试对于独立的测试人员过度信任版本改变的太快测试人员处于不受重视的情况中不能说不
163. 实施过程听取各方面的意见和建议标明项目风险测试要素联系测试矩阵建立测试计划对计划进行评审
164. 建立测试计划定义测试目标开发测试矩阵软件模型结构特性批量测试的阶段和用例为在线系统作概念上的测试脚本软件测试矩阵定义测试管理测试计划的一般性信息定义测试里程碑定义管理上的检查点书写测试计划
165. 评审测试计划涉及评审的问题评审测试的开始时间是否会延期有没有抵触评审的角色一段时间内是否很难得到工作的检查信息。更换工具有可能导致他们反感评审工作评审结果可能会影响对个人的工作评价对于最终成品的检查项目的需求规格说明书软件返工/维护的文档升级后的技术文档被更改的源程序测试计划用户手册（包括在线帮助）
166. 评审测试计划正式评审中的角色缓和剂（SQA）读者记录者作者检测员正式评审发现的缺陷应包含的信息起因类型分类级别
167. 评审流程计划和组织通篇的讲解（可选）个人准备评审会议修订和反复
168. 需求阶段的测试
169. 测试成本在软件开发的所有阶段进行测试被设计用来减少测试成本 IBM的数据大约 60个缺陷/千行 2/3的缺陷产生在需求和设计阶段在需求和设计阶段发现的缺陷修正的花费最小修正系统测试阶段发现的缺陷，花费是以上的10倍发布产品以后，修正缺陷的花费是原来的100倍
170. 生命周期的测试概念在软件开发过程中持续的进行测试在尽可能早的阶段点去修正缺陷需要正式的开发流程来支持组建测试团队当开发开始进行的时候，测试就开始进行了
171. 需求阶段的测试准备风险列表确定风险组确定风险风险分析风险检查表建立控制目标确定有足够的控制力度
172. 分析测试要素需求的设计是否遵循了已定义的方法提交了已定义的功能说明定义了系统界面已经估计了性能标准容忍度被预先估计预先定义了权限规则需求中预先定义了文件完整性预先定义了需求的变更流程预先定义了失败的影响权限定义
173. 需求走查建立基本规则选择小组/通报参与者项目介绍问题/建议形成最终报告
174. 需求阶段测试所有的花费都是值得的大部分缺陷将不会进入到设计&编码阶段目标需求正确的表现出了用户的需要需求已经被定义和文档化了花费和收益成正比需求的控制被明确有合理的流程可遵循有合理的方法可供选择
175. 设计阶段的测试
176. 设计阶段的测试交付的产品输入说明过程说明文件说明输出说明控制说明系统流程图硬件和软件的需求操作手册说明书数据保留的策略
177. 设计阶段测试任务给测试要素打分分析测试要素对设计进行评审检查修改的部分
178. 分析测试要素测试涉及的内容：设计了对数据完整性的控制设计了权限规则设计了对文件完整性的控制设计了审计追踪设计了发生意外情况时的计划设计了如何达到服务水平的方法定义了权限流程定义了完整的方法学设计了保证需求一致性的方法进行了易用性的设计设计是可维护的设计是简单的交互界面设计完毕定义了成功的标准需要同实际操作者沟通
179. 对设计进行评审选择评审组成员对评审组进行培训通报项目组分配足够的时间只对文档化的事实进行评审和项目组一起进行评审对评审形成建议和项目组对建议一起进行评审准备正式的报告
180. 编码阶段的测试
181. 形成的输出编码说明书程序文档计算机程序列表可执行的程序程序流程图操作介绍单元测试结果
182. 测试活动的关注点完成对数据完整性的控制定义完毕授权的规则完成对文件完整性的控制实现审计追踪规划出意外情况发生后的处理计划对系统如何达到预定义的服务水平做了计划完成了对安全问题的处理流程编码工作是依据规定的方法完成的编码与设计相一致（正确性）编码与设计相一致（易用性）代码是可维护的编码与设计相一致（简洁性）编码与设计相一致（耦合性）已开发了操作流程定义出程序成功的标准（性能上）
183. 测试的职责编码是一个纯技术的工作，几乎不需要用户的参与项目领导者有参与测试的责任监督过程的有效性
184. 建议的测试方式桌面调试语法上的结构上的功能上的代码互查建立基本的互查规则选择互查的team 对成员进行培训选择互查的方法提供互查的材料流程图，源程序，典型的处理流程对互查进行必要的管理给出互查结论提供最终的报告
185. 编码阶段的测试需解决的问题系统是可维护的吗？系统说明是否已经完成了？编码是否按照既有的标准进行，过程是否易于实践？是否有足够的测试计划用来评估可执行的程序？是否编制了足够的文档。
186. 测试关注点在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。文档测试阶段的测试计划测试用例前期测试的测试结果第三方测试反馈，例如：计算机操作人员正式的测试总结报告
187. 典型测试类型手册，回归，功能点测试一致性测试（授权）功能点测试（完整性）功能点测试（审计，追踪）覆盖性的测试（测试的连续性）压力测试（服务水平）一致性测试（安全性）依照预先定义的测试方法功能点测试（正确性）支持手册的测试（易用性）检查（可维护性）灾难性的测试（可携带性）功能和回归测试（耦合性）一致性的测试（性能）操作性的测试（易用性）
188. 建议测试方法测试方法测试用例的概念是简单的建立有效的测试用例是复杂的设计测试文件测试用例应当包含合法的和非法的输入每一个动作只进行一次关键操作输入测试数据分析结果尝试将测试文件违反程序的规则进行输入容量测试的测试工具以大信息量的数据进行输入这是一个昂贵的测试，应根据需要来选择在线系统需要做压力测试
189. 测试总结
190. 测试报告目标表示出目前项目的实际状况明确什么是测试做的工作，什么是不作的工作。给出系统的操作性能的评价明确什么时候系统可以进行产品化的工作关注点测试报告只有真正需要的时候才有用，需要配合市场和管理测试的信息是不充分的（对于评价一个项目来说）测试状况并不能真实的反应个人的状况
191. 测试期间数据的收集有关测试结果的积累数据测试任务，测试集合和测试事件的描述缺陷分析由于计划的问题，导致没有发现的缺陷的数据严重的缺陷缺陷类型为什么缺陷没有发现效果
192. 测试报告报告目前的软件状态功能/测试矩阵功能测试的状态报告，侧重点分析关于功能的工作时间轴期望发现 VS 实际发现的缺陷比没有发现的缺陷和改正的缺陷的差距按照类型分类，没有改正的缺陷的平均值缺陷分类报告测试活动报告
193. 最终的报告汇总各个阶段的项目测试总结报告继承性测试报告系统测试报告确认测试报告

软件测试培训教程

关键词

相关PPT