【知识点全部来源于课本】

一.填空

1.单元测试的主要任务有模块接口测试。模块局部数据结构测试。模块中所有独立执行路径测试。各种错误处理测试。模块边界条件测试。

2.软件测试人员的基本技能要求有：业务知识。计算机专业知识。测试专业知识。用户知识。

3.对风险的评估主要依据三方面。风险描述。风险概率。风险影响。

4.软件缺陷的生命周期一般分为。
发现——打开：软件缺陷被发现并提交给开发人员。
打开——修复：开发人员再现，修复缺陷，然后提交给测试人员去验证。
修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
这三个阶段。

5.软件测试的整个过程分为。单元测试。集成测试。系统测试及验收测试。四个阶段。

二.名词解释

1.软件测试：软件测试就是为了发现错误，而执行程序的过程。是一个找错的过程，测试只能找出程序中的错误，而不能证明程序无错。

2.测试计划：软件测试计划是描述测试目的，范围，方法和软件测试的重点等内容的文档。是软件项目计划的子计划。在项目启动初期是必须规划的。

3.缺陷分析：对缺陷中包含的信息进行收集，汇总，分类之后，使用统计方法得出分析结果。

4.软件缺陷：存在于软件(文档，数据，程序)之中那些不希望，或不可接受的偏差，而导致软件产生质量问题。

5.回归测试：是指软件系统被修改或扩充后，重新进行的测试。回归测试是为了保证对软件修改以后，没有引入新的错误而重复进行的测试。

6.α测试：软件开发公司组织内部人员，模拟各类用户行为，对即将面世的软件产品进行测试，试图发现并修改错误。是在软件开发公司内模拟软件系统的运行环境下的一种验收测试。

7.β测试：是指软件开发公司组织各方面的典型用户，在日常工作中实际使用β版本。并要求用户报告异常情况，提出批评意见。

8.单元测试：是对软件设计的最小单元——模块进行正确性校验的测试工作，主要测试在语法，格式和逻辑上的错误。

9.集成测试：也叫组装测试，联合测试。是单元测试的逻辑扩展，它的最简单的形式是将两个已经测试过的单元组合成一个组件，并测试它们之间的接口。

10.系统测试：是指将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件，外设，某些支撑软件的系统等其它系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义做比较，发现软件与系统定义不符合或矛盾的地方。

11.验收测试：是在软件开发结束后，用户对软件产品投入实际应用以前，进行的最后一次质量检验活动。

12.黑盒测试：已知产品的功能设计规格和用户手册。可以测试验证每个功能是否都实现，每个实现了的功能是否都符合要求，以及产品的性能是否满足用户的需求。

13.白盒测试：已知产品的内部工作过程，可以通过测试验证每种内部操作是否符合设计规格要求。所有内部成分是否已经过检查。

14.静态测试：是一种不通过执行程序而进行测试的技术，其关键是检查软件表示和描述是否一致。是否存在冲突或歧义。

15.动态测试：主要验证一个系统在检查状态下是正确还是不正确。

16.测试用例：是测试执行的最小实体，是为特定的目的而设计的一组测试输入，执行条件和预期结果。

17.软件测试自动化：就是通过测试工具或者其他手段，按照测试人员的预定计划，对软件产品进行自动的测试，它是软件测试的一个重要组成部分。能够完成许多手工无法完成，或者难以实现的一些测试工作。

三.简答题

1. 软件测试的原则
尽早测试：
全面测试：
全过程测试：
独立的迭代的测试：
pareto原则：
对测试出的错误结果一定要有一个确认的过程：
制定严格的测试计划：
完全测试是不可能的，测试需要终止：
注意回归测试的关联性：
妥善保存一切测试过程文档：
2. 面向对象软件的特点

1.封装性:在面对对象程序设计中，封装是指将对象的数据和操作包装在一起，从而使对象具有包含和隐藏信息的能力。

2.继承性：是指基于现有的类创建新类的机制，继承性是面向对象程序设计中的一个关键概念。

3.多态性：多态性是指类为方法提供不同的实现方法，但能够以相同名称调用的功能，多态性允许对类的某种方法进行调用，而无需考虑方法所提供的特定实现。

软件测试的步骤(具体)

1.制定测试计划，设计测试方案，建立测试系统，搭建测试环境

2.准备测试材料，测试工具。

3.执行测试。

4.验证预期结果，测试不通过，反馈给编码人员修改，代码修改重新提交后，返回2继续。

5.记录缺陷

6.评估测试需求的覆盖率

7.分析缺陷

8.测试总结

2.2制订测试计划的原则
制订测试计划是软件测试中最有挑战性的一个工作，以下几个原则将有助于测试计划的制订
（1)制订测试计划应尽早开始。即使还没掌握所有细节，也可以先从总体计划开始，然后逐步细化来完成大量的计划工作。尽早地开始制订测试计划可以使我们大致了解所需的资源，
在项目的其他方面占用该资源之前进行测试
（2)保持测试计划的灵活性。制订测试计划时应考虑要能很容易地添加测试用例、测试数量等，测试计划本身应该是可变的，但是要受控于变更控制。
（3)保持测试计划简洁易读。测试计划没有必要很大、很复杂，事实上测试计划越简洁易读它就越有针对性。

（4)尽量争取多方面来评审测试计划。多方面人员的评审和评价会对获得便于理解的测试计划很有帮助，测试计划应该像项目其他交付结果一样受控于质量控制。
（5)计算测试计划的投入。通常，制订测试计划应该占整个测试工作大约113的工作量，测试计划做得越好，执行测试就越容易。
5.1测试用例的基本概念
测试用例是测试执行的最小实体，是为特定的目的而设计的一组测试输入、执行条件和预期结果。简单来说，测试用例就是一个文档，描述输人、动作、时间或者一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，并且达到程序所设计的结果。如果执行测试用例，软件在这种情况下不能正常运行，而且问题会重复发生，那就表示已经测试出软件有缺陷，这时候就必须将软件缺陷标示出来，并且输人到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，在修正了问题之后，又返回给测试人员进行确认，确保该问题已修改完成。

2，测试用例的作用
测试用例的作用主要体现在以下几个方面。
有效性：在测试时，不可能进行穷举测试，从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试，可有效地节省时间和资源、提高测试效率。
避免测试的盲目性：在开始实施测试之前设计好测试用例，可以避免测试的盲目性，并使得软件测试的实施重点突出、目的明确。
可维护性：在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。
可复用性：功能模块的通用化和复用化使软件易于开发，而良好的测试用例具有重复使用的性能，使得测试过程事半功倍，并随着测试用例的不断精化，使得测试效率也不断提高。
可评估性：测试用例的通过率是检验程序代码质量的标准，也就是说工程序代码质量的量化标准应该用测试用例的通过率和测试出软件缺陷的数目来进行评估。
可管理性：测试用例是测试人员在测试过程中的重要参考依据，也可以作为检验测试进度、测试工作量以及测试人员工作效率的参考因素，可便于对测试工作进行有效的管理。

6.I.1软件缺陷的定义和描述
软件缺陷简单来说就是存在与软件(文档、数据工程）之中的那些不希望，或不可接受的偏差、而导致软件产生质量问题。但是，以软件测试的观点对软件缺陷的定义是比较宽泛，按照一般的定义，只要符合下面5个规则中的一条，就叫做软件缺陷。
软件未达到软件规格说明书中规定的功能。
软件超出软件规格说明书中指明的范围。
软件未达到软件规格说明书中指出的应达到的目标。
软件运行出现错误。
软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。
如果在软件系统的执行过程中遇到一个软件缺陷，可能引起软件系统的失效。那么准确、有效地定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约软件测试项目的成本和资源，提高软件产品的质量。
软件缺陷的基本描述是报告软件缺陷的基础部分，一个好的描述需要使用简单、准确、专业的语言来抓住软件缺陷的本质，若描述的信息含糊不清，可能会误导开发人员。以下是软件缺陷的有效描述规则：
单一准确：每个报告只针对一个软件缺陷。
可以再现：提供出现这个缺陷的精确步骤，使开发人员看懂，可以再现并修复缺陷。
完整统一：提供完整，前后统一的软件缺陷的修复步骤和信息，如图片信息，log文件等。
短小简练：通过使用关键词，使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。
特定条件：软件缺陷描述不要忽视那些看似细节但又必要的特定条件（如特定的操作系统，浏览器），这些特定条件能提供帮助开发人员找到产生缺陷原因的线索。
补充完善：从发现软件缺陷开始，测试人员的责任就是保证他被正确的报告，并得到应有的重视，继续监视其修复的全过程。
不作评价：软件缺陷报告是针对软件产品的，因此软件缺陷描述不要带有个人观点，不要对开发人员进行评价。

7.2.1软件测试文档的作用
测试文档的重要作用可从以下几个方面看出。
(1)促进项目组成员之间的交流沟通
基本上，测试文档的编写和建立主要是进行一些标准认证的基本工作，它是测试小组成员之间相互交流的基础和依据，以此测试小组成员之间进行交流和沟通可以事半功倍。一个软件的开发过程需要相当多的开发步骤和许多各类人员共同运作才能完成。当软件开发进人测试阶段，对软件整体部分(包括系统功能、问题原因和解决方法等)最清楚的是测试人员，项目组成员之间的交流沟通以文档的形式进行交接是方便、省时、省力的方式。
(2)便于对测试项目的管理
测试文档可为项目管理者提供项目计划、预算、进度等各方面的信息，编写测试文档已是质量标准化的一项例行基本工作。
(3)决定测试的有效性
完成测试后，把测试结果写人文档，这对分析测试的有效性、整个软件的可用性提供了必要的依据。有了文档化的测试结果，就可以分析软件系统是否完善
(4)检验测试资源

测试文档不仅用文档的形式把测试过程以及要完成的任务规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经开发出来，但所需资源还是不能落实，那就必须及早解决。

（5）明确任务的风险
记录和了解测试任务的风险有助于测试小组找出潜在的，可能出现的风险，同时事先作好思想上和物质上的准备。
(6)评价测试结果
软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，需要对软件产品进行质量控制。一般来说，对测试数据进行记录，并根据测试情况撰写测试报告，是软件测试人员要完成的最重要的工作。这种报告有助于测试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。完成测试后，将测试结果与预期结果进行比较，便可对已测试软件提出评价意见。
(7)方便再测试
测试文档中规定和说明的部分内容，在后期的维护阶段往往由于各种原因需要进行修改完善，凡是修改完善后的内容都需要进行重新测试(可能包括某些接口)，有了测试文档，就可以在维护阶段进行重复测试，测试文档在维护过程中对于管理测试和复用测试都非常重要。
(8)验证需求的正确性
测试文档中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的。
测试文档记录了测试的完成过程以及测试的结果，文档是测试过程必要的组成部分，测试文档的编写也是测试工作规范化的一个组成部分。在测试中，应该坚持按照软件系统文档标准编写和使用测试文档。
10、什么是软件测试自动化
软件测试自动化就是通过测试工具或其他手段，按照测试人员的预定计划对软件产品进行自动的测试，它是软件测试的一个重要组成部分，能够完成许多手工无法完成或者难以实现的一些测试工作，正确、合理地实施自动化测试，能够快速、全面地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布日期。

软件测试自动化涉及测试流程、测试体系、自动化编译以及自动化测试等方面的整合、也就是说，要让测试能够自动化，不仅是技术、工具的司题，更是一个公司和组织的文化问题、首先公司要从资金、管理上给予支持，其次要有专门的测试团队去建立适合自动化测试的测试流程和测试体系最后才是把源代码从受控库中取出、编译、集成，并进行自动化的功能和性能等方面的测试。
自动化测试能够替代大量手工测试工作，避免重复测试，同时它还能够完成大量手工无法完成的测试工作如并发用户测试、大数据量测试、长时间运行可靠性测试等。特别是对于大型工程，或者持续的长期工程，采用自动测试的效果是非常明显的。因为对于一项工程、其功能部件可能很多，而且部件之间的关系也比较复杂，要采用人工的测试就需要投人很大的精力，而且当需要进行反复测试的时候、自动化测试的需求就逐渐明显。测试活动的自动化在下列情况下提供最大价值，即重复使用测试脚本，或测试脚本子程序生成后，被一些测试脚本反复调用、因为是长期的工程，学习一种测试工具使用方法的时间相对于工程建设的时间比例就很小，因此，工程性软件的开发中，采用自动测试工具是很有意义的。但自动化测试在实际应用中也存在局限性，并不能完全替代手工测试。如定制型项目，这种项目专为客户定制，其中定制的还可能包括项目所采用的开发语言、运行环境等，这样的项目不适合做自动化测试。同样，对于小型项目，自动化则试可能用处不大，不值得再花时间学习一种测试工具的使用方法。