软件测试从零基础到月薪8k，我的学习经历值得让你少走两年弯路

我是去年9月22日才正式学习软件测试的，因为在国营单位工作了4年，在长沙一个月工资只有5000块，而且看不到任何晋升的希望，如果想要往上走，那背后就一定要有关系才行。而且国营单位的气氛是你干的多了，领导觉得你有野心，你干的不多，领导却觉得你这个人不错。我才26周岁，实在的受不了这种工作氛围，情绪已经压制了很多久，一心想着要跳出来，却一直找不到合适的机会。因为身边的朋友有在北京做测试开发的，他工作了四五年的时间，可以在北京拿到3万的月薪，说心里话我是真的羡慕，这远超出了我的认知范围。所以经过朋友的推荐，我开始学习测试，一共学了大概5个多月的时间，今年的3月6号在长沙找到了一份测试的工作，我包装了一年的工作经验，月薪8K五险一金，这算是成功上岸了。

在刚开始学习的时候我开始自学，因为有朋友是做这行的，所以自己在开始的时候少走了很多弯路，他给了我很好的建议，所以学习测试有个大佬带是尤为重要的。因为做软件测试的都有一个圈子，所以经过了朋友的引荐，他让我加了他们那个圈子的软件测试讨论群。里面大部分都是自学成功的大佬，在整个学习期间，我在他们这里真的是得到了不少的帮助。因为他们每个人都积累了很多资源，所以平时都是相互分享资源，如果公司有内推就业的名额也会相互推荐工作机会。当然里面也有一些还在学习中的人，这都是朋友相互推荐聚到一起的。所以我建议那些还在学习测试的初学者，一定要多结识一些行业内的大佬，可以加一下文章末尾这个测试交流群，对于一个初学者来说可以获得非常多的帮助，平时有一些问题发在群里，他们中有人工作不忙的时候就会出来解答，效率很高而且每个解答都讲解的非常透彻。我之所以能在5个月左右的时间自学测试就业，确实是得到了这些大佬不少的帮助。

我的学习心得，我认为能不能自学成功的要素有两点。

第一点就是自身的问题，虽然想要转行学习测试的人很多，但是非常强烈的想要转行学好的人是小部分。而大部分人只是抱着试试的心态来学习测试，这是完全不可能的。所以能不能学成测试并且就业，最关键的一点就是自己的愿望是否强烈。我是属于非常强烈那种，因为忍受不了现在工作的氛围，以及羡慕朋友在北京可以拿到3万的月薪，这些因素都促使我非常拼命的学。在加上自身可以做到从下班就开始看视频自学，一直学到晚上12点的这股劲，所以才能在5个月的时间内达到就业的水平。

第二点就是有大佬带你，如果全程都靠自己摸索是非常难的，对于一个不是本专业的人来说从开始的时候就“无从下手”。更不要说在学习过程中遇到的无数问题难以得到解决，因为我们在学习过程中会遇到无数问题，有的时候一个小问题就能困扰我们几个小时的时间，会导致我们的学习效率很低，这种情况出现多了以后，信心就会受到打击，觉得自己不适合学测试，最终放弃。而当有一个大佬去给你解答后，你会很快得到答案，并且能理解为什么要这样做，到底是哪里出现了问题，学习效率会非常高。

所以总结就是自身自觉主动学习在加上大佬全程带你，其实学习就是这么简单的事情，无非就是这两个关键的要素，少了其中一个都很难成功。

一、测试与软件模型

软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括：需求、设计、编码、测试、稳定、部署、维护等阶段。

常见的软件开发模型有瀑布模型、迭代开发、螺旋开发和敏捷开发。

1 瀑布模型

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要有以下问题：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
3. 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

因此，瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

2 迭代开发模型

迭代式开发是一种与传统的瀑布式开发相反的软件开发过程，具有更高的成功率和生产率。在迭代开发中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，逐步逐步的完成，故为迭代。每一次迭代都包括需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。迭代开发具有以下优点：

1. 降低风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2. 适应需求变更。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。
3. 持续的测试与集成，降低后期的工作量与风险。

3 螺旋开发模型

螺旋开发，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 “螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 螺旋开发分为以下四个阶段：

1. 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
2. 风险分析：分析评估所选方案，考虑如何识别和消除风险；
3. 实施工程：实施软件开发和验证；
4. 客户评估：评价开发工作，提出修正建议，制定下一步计划。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建 造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

4 敏捷开发模型

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

1. 个体和互动重于流程和工具。
2. 可工作的软件重于求全而完备的文档。
3. 客户协作重于合同谈判。
4. 应对变化重于遵循计划。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。人员彼此信任，人少但是精干，可以面对面的沟通。

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作；按短迭代周期工作；每次迭代交付一些成果；关注业务优先；检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

5 四种模型比较

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

6 软件开发过程中的测试

在前面介绍的软件开发过程中，测试都是一个重要的组成部分。尤其对于中大型项目，从项目开始指出就要制定测试计划、对需求进行测试、设计测试和测试用例、执行测试，最后对测试的结果进行总结和分析。软件缺陷发现得越早，修复软件缺陷所需的代价越小。

TDD（测试驱动开发）的思路就是通过测试推动整个开发的进行，开发代码之前，先编写测试代码。在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。并且，软件测试的活动贯穿整个软件开发生命周期的始终。

7 软件测试的目的与原则

测试的定义：使用人工或自动手段来运行或测定某个系统的过程，其目的在于检查它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

软件测试的目的：发现程序中的错误，保证软件产品的最终质量。

1. 测试是程序的执行过程，目的在于发现错误
2. 一个成功的测试用例在于发现至今未发现的错误
3. 一个成功的测试是发现了至今未发现的错误的测试
4. 确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
5. 确保产品满足性能和效率的要求
6. 确保产品是健壮的和适应用户环境的

软件测试的原则：

1. 测试用例中一个必须部分是对预期输出或接口进行定义
2. 程序员应避免测试自己编写的程序
3. 编写软件的组织不应当测试自己编写的软件
4. 应当彻底检查每个测试的执行结果
5. 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
6. 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
7. 应避免测试用例用后即弃，除非软件本身就是个一次性的软件
8. 计划测试工作时不应默许假定不会发现错误
9. 程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比

8 软件的可测性

软件的可测性太差会导致测试的难度相当大，甚至无法测试。这种情况往往是由于极差的软件架构设计和极为不规范的软件开发工作导致的。

1. 紧耦合。不把大半个系统实例化就无法测试。
2. 弱内聚。这个类实现了太多功能，导致测试非常复杂。
3. 冗余。同一个方法在多处使用，每一处都得测。

好的软件架构应该是松耦合、高内聚的。提高软件的测试性的同时也提高了软件的可维护性和可管理性。

二、测试用例设计

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

1 黑盒测试与白盒测试

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查。

合理的测试策略是将这两种测试要素组合起来。我们可以通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试。

白盒测试方法有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。黑盒测试方法有等价类划分、边界值分析、因果图分析、错误测试、状态图、场景法等。

2 白盒测试用例设计

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。可以很直观地从源代码得到测试用例，无须细分每条判定表达式。由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。（遗漏隐藏的逻辑分支）

判定覆盖要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和为“假”的输出结果。判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。（遗漏组合判定中的某些条件取值）

条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。判定/条件覆盖准则的缺点是未考虑条件的组合情况。

多重条件覆盖要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。缺点是线性地增加了测试用例的数量。

路径覆盖要求设计足够的测试用例，覆盖程序中所有可能的路径。由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。

3 黑盒测试用例设计

（1）等价类划分

等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类分为有效等价类和无效等价类，其中，有效等价类是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合；而无效等价类是指对于程序的规格说明来说是不合理的，没有意义的输入数据构成的集合。设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。划分等价类有以下原则：

1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；则小于0和大于100的为无效等价类，0~100之间的为有效等价类。
2. 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。
3. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
4. 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

1. 为每一个等价类规定一个唯一的编号；
2. 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
3. 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

（2）边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

（3）因果图

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

（4） 错误测试

错误测试是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

如测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

1. 输入的线性表为空表；
2. 表中只含有一个元素；
3. 输入表中所有元素已排好序；
4. 输入表已按逆序排好；
5. 输入表中部分或全部元素相同。

4 测试用例设计综合策略

Myers提出了使用各种测试方法的综合策略：

1. 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2. 必要时用等价类划分方法补充一些测试用例。
3. 用错误推测法再追加一些测试用例。
4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

测试用例的设计步骤：1)构造根据设计规格得出的基本功能测试用例；2)边界值测试用例；3)状态转换测试用例；4)错误猜测测试用例；5)异常测试用例；6)性能测试用例；7)压力测试用例。

三、软件测试类型

单元测试

单元测试并不是对整个程序进行测试，而是对构成程序的较小模块进行测试。单元测试减小了调试的难度（一旦某个错误被发现出来，我们就知道它在哪个具体的模块中）；单元测试提供了同时测试多个模块的可能，将并行工程引入软件测试中。

在为模块单元测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。单元测试总体上是面向白盒测试的，因此，单元测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

集成测试

自顶向下集成和自底向上集成

功能测试

功能测试的目的是为了暴露程序的错误以及与规格说明不一致之处，而不是为了证明程序符合其外部规格说明。

功能测试是一种黑盒测试，功能测试常用步骤有：根据需求来细分功能点，根据功能点派生测试需求，根据测试需求设计功能测试用例。

系统测试

系统测试的目的是为了证明程序不能实现其目标，系统测试的测试用例设计有以下14种类型：

1. 能力测试：是判断目标文档提及的每一项能力（或功能）是否都确实已经实现。
2. 容量测试：使程序经受大容量数据的检验。容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量。
3. 强度测试：使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。
4. 易用性测试：试图发现人为因素或易用性的问题。
5. 安全性测试：设计测试用例来突破程序安全检查的过程。举例来说，我们可以设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制。
6. 性能测试：很多软件都有特定的性能或效率目标，这终特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。
7. 存储测试：
8. 配置测试：
9. 兼容性测试。
10. 安装测试：有些类型的软件系统安装过程非常复杂，测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这尤其重要。安装程序如果出现故障，会影响用户对软件的成功体验。
11. 可靠性测试：所有类型的测试都是为了提高软件的可靠性，但是如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。
12. 可恢复性测试：诸如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统测试的一个目标是证明这些恢复机制不能够正确发挥作用。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复。
13. 适用性测试
14. 文档测试：检查用户文档的正确性。用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。

四、自动化测试

自动化测试：以程序测试程序、以代码代替思维、以脚本运行代替手工测试。

冒烟测试:就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。比如，拿到QQ的app新版本，登陆都登陆不上，那么这个版本肯定无法继续测下去。或者，游戏中新的模块出现，但是新的模块总是崩溃、卡死，测试进行不下去，那么冒烟的结果就是不合格的。

回归测试:就是以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug。

1 自动化测试的优势

1. 回归测试更方便、可靠。由于回归测试的业务流程操作和测试用例是预先设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。
2. 可运行更多更繁琐的测试，且快速高效。
3. 可执行一些对于手工测试来说相当困难或根本做不到的测试。比如，对大量用户的并发测试等。
4. 具有一致性和可重复性的特点。
5. 自动化测试脚本完全具有复用性。由于自动化测试通常以脚本的方式实现，这样在不同的版本之间，就可能只需要做少量的维护甚至不做任何修改，实现在不同的测试版本中使用相同的测试脚本执行相同的测试用例。

2 自动化测试的劣势

1. 永远不可能完全取代手工测试。自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合转换成自动化测试用例的。
2. 无法保证测试的正确性。测试脚本本身也可能存在缺陷。
3. 手工测试能发现的缺陷远比自动化测试多。自动化测试几乎是无法发现新缺陷。
4. 自动化测试工具是死的，它本身没有任何想象力。
5. 自动化测试对测试工程师来说必须有一定的开发技术背景。

3 引入自动化测试的时机

1. 项目周期长，系统版本不断。主要在于回归测试。
2. 需求变更不频繁。
3. 系统中的测试对象基本可以正常识别，不存在大批量第三方控件。
4. 需要反复测试，如可靠性测试需要进行上千次的系统测试。

4 何时避免展开自动化测试

1. 项目周期短，需求变更频繁。项目周期短的情况下引入自动化测试，不但收不回成本，而且会延长产品的发布时间。需求频繁改变会使老功能的业务逻辑被修改，从而导致相应的测试脚本也需相应修改。
2. 软件版本还没稳定。
3. 多数对象无法识别以及脚本维护频繁与艰难。

5 自动化测试用例设计

在项目的测试过程中，测试工程师都会首先分析测试需求，产出测试计划后，编写和设计测试用例，设计开发测试脚本。

1. 自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。并不需要覆盖所有的手工测试用例。
2. 自动化测试用例的选择一般以“正向”为主。正常情况即为“正向”，异常情况即为“反向”。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常运作。
3. 手工测试用例可以不用回归原点，而自动化用例往往是必须的。所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态。比如添加用户功能，由于用户名是唯一的，第一次执行时没有问题，第二次执行时程序就会出现用户名重复而报错；这种情况下，就需要在自动化测试用例最后增加删除该用户的步骤。
4. 自动化测试用例与手工测试用例不同，不需要每个步骤都写预期结果。

五、测试文档编写与缺陷管理

测试文档包括：测试计划文档，测试设计规格文档，测试用例，软件缺陷报告，状态报告。

测试用例对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例一般包括验证测试用例和证伪测试用例；验证测试用例用于验证代码是否按照预期执行，得到预期结果；证伪测试用例验证代码是否对异常和错误条件进行了适当处理。

缺陷报告包括：问题/错误的简单描述，重现的环境配置要求，保证多次精确重复的特定输入，期望结果与实际结果的对比，优先级与严重性，对客户的影响等。

六、常用的测试工具

1 功能测试UFT

UFT自动化测试的原理

1. 封装真实被测对象并转化为UFT对象到对象库。
2. 对比对象库里的对象鉴别属性和运行时的真实被测对象的鉴别属性。
3. 对比结果一致，则说明对象成功匹配并可以继续对该真实被测对象进行后续操作；如果不一致则报错，提示对象无法识别。

封装对象模型

在UFT里的封装对象共分两个概念，Test Objects（测试对象，TO）和Runtime Objects（运行时对象，RO）。TO就是被被添加到对象库中的对象，RO就是被测试软件在运行实际所运行的对象。他们都是UFT封装的对象，TO是为了识别RO而存在的。

UFT识别对象通常先在对象库中添加测试对象，然后在被测软件运行的时候，根据脚本中调用的对象名称，在对象库中找到相应的测试对象，并根据这些对象的特征属性，在被测试软件中搜索相匹配的正在运行的对象，最后就可以对这些实际运行的测试对象进行操作。

GetTOProperty()
基本含义：获取对象库中某个对象的某个属性的值。
公式：ReturnValue = 对象.GetTOProperty("封装属性名")

SetTOProperty()
基本含义：设置对象库中某个对象的某个属性的值。
公式：对象.SetTOProperty "封装属性名" "封装属性值"
注：使用代码形式的修改对象属性属于临时性的，只在脚本运行时有效，一旦脚本运行结束，对象库里的属性值就会还原。

GetROProperty()
基本含义：获取实际运行时的某个对象的某个属性的值。
公式：ReturnValue = 对象.GetROProperty("封装属性名")
注：使用GetROProperty这个方法来动态获取实际运行时的一些确认信息，然后和所预期的测试数据做对比。如注册功能，在提交一些注册信息以后，一般都要到接下来的确认页面去验证一些信息，这就可以使用GetROProperty来动态获取实际运行时的一些确认信息。

对象无法识别的解决办法

1. 设置虚拟对象。不推荐，虚拟对象非常脆弱，难以维护；即使对象没有发生变化，但只要对象在界面是那个的方位发生变化，虚拟对象就会识别失败。
2. 使用相对坐标配合WSH去定位对象。
3. 使用DOM组建接口应用技术。只适用于Web项目。
4. 使用UFT自定义扩展SDK Customer来进行二次开发使UFT能够识别对象。难度大。
5. 开发提供专属插件。
6. 把无法识别的对象的一些方法封装到一个dll中并使用UFT调用。

数据驱动与场景恢复

数据驱动Data Table的应用：实现测试数据和脚本业务的分离。
场景恢复：场景恢复可以应对多种类型的错误并进行恢复操作。

2 性能测试LoadRunner

LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实时性能监测，来帮助测试人员更快地查找和发现问题。

1. 轻松创建虚拟用户。Virtual User Generator能够生成虚拟用于，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程，然后将其转化为测试脚本，并进行参数化操作（Data Wizard直接连接数据服务器获取数据）。利用虚拟用户可以在不同操作系统上同时产生成千上万用户访问，能极大的减少负载测试所需要的硬件和人力资源。
2. 创建真实负载。建立虚拟用户后，需要设定负载方案、业务流程组合和虚拟用户数量。用Controller能够很快地组织多用户测试方案。
3. 定位性能问题。LoadRunner内含一个实时检测器，在负载测试过程的任何时候都能观察到应用系统的运行性能。
4. 分析结果。一旦测试完毕，LoadRunner收集汇总所有的测试数据，并提供高级的分析和报告工具，一遍迅速找到性能问题并做出相应的调整。

七、软件测试面试题总结

1. 给你一个网站，你如何测试？

首先，查找需求说明、网站设计等相关文档，分析测试需求。

制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

功能性测试可以包括，但不限于以下几个方面：

1. 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。
2. 提交功能的测试。
3. 多媒体元素是否可以正确加载和显示。
4. 多语言支持是否能够正确显示选择的语言等。

界面测试可以包括但不限于一下几个方面：

1. 页面是否风格统一，美观
2. 页面布局是否合理，重点内容和热点内容是否突出
3. 控件是否正常使用
4. 对于必须但未安装的控件，是否提供自动下载并安装的功能
5. 文字检查

性能测试一般从以下两个方面考虑：压力测试；负载测试；强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

安全性测试：

1. 基本的登录功能的检查
2. 是否存在溢出错误，导致系统崩溃或者权限泄露
3. 相关开发语言的常见安全性问题检查，例如SQL注入等
4. 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持

兼容性测试，根据需求说明的内容，确定支持的平台组合：

1. 浏览器的兼容性；
2. 操作系统的兼容性；
3. 软件平台的兼容性；
4. 数据库的兼容性

开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

定期评审，对测试进行评估和总结，调整测试的内容。

2. 在搜索引擎中输入汉字就可以解析到对应的域名，请问如何用LoadRunner进行测试。

1. 建立测试计划，确定测试标准和测试范围
2. 设计典型场景的测试用例，覆盖常用业务流程和不常用的业务流程等
3. 根据测试用例，开发自动测试脚本和场景：

录制测试脚本：新建一个脚本（Web/HTML协议）；点击录制按钮，在弹出的对话框的URL中输入”about:blank”；在打开的浏览器中进行正常操作流程后，结束录制；调试脚本并保存，可能要注意到字符集的关联。

设置测试场景：针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标；针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃；执行测试，获取测试结果，分析测试结果。

3. 一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?

300个用户在一个客户端上，会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。300个用户在一个客户端上，需要更大的带宽。

IP地址的问题，可能需要使用IP Spoof来绕过服务器对于单一IP地址最大连接数的限制。

所有用户在一个客户端上，不必考虑分布式管理的问题；而用户分布在不同的客户端上，需要考虑使用控制器来整体调配不同客户机上的用户。同时，还需要给予相应的权限配置和防火墙设置。

4. 目前主要的测试用例设计方法是什么？

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖

黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法

5. 软件的安全性应从哪几个方面去测试？

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统 、系统网络安全的测试要考虑问题 、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击，看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞

数据库安全考虑问题： 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独立性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

6. 简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试

静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。

动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。

黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

7. 软件测试分为几个阶段，各阶段的测试策略和要求是什么?

和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段：

1. 单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
2. 集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
3. 系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
4. 验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。
5. 单元测试测试策略：
6. 自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
7. 自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
8. 集成测试的测试策略：
9. 大爆炸集成：适应于一个维护型项目或被测试系统较小
10. 自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
11. 自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
12. 基于进度的集成
13. 优点：具有较高的并行度；能够有效缩短项目的开发进度。
14. 缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。

系统测试的测试策略：数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试

8. 软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？

单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。

集成测试阶段：集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。

系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。

9. 一条软件缺陷（或者叫Bug）记录都包含了哪些内容？

一条Bug记录最基本应包含：

1. bug编号；
2. bug严重级别，优先级；
3. bug产生的模块；
4. 首先要有bug摘要，阐述bug大体的内容；
5. bug对应的版本；
6. bug详细现象描述，包括一些截图、录像....等等；
7. bug出现时的测试环境，产生的条件即对应操作步骤；

10. 黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！

黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关； 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。

黑盒测试的缺点有：不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；自动化测试的复用性较低。

白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐 藏的问题。

白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。

11. 如何测试一个纸杯？

功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

12. 黑盒测试的测试用例常见设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1）等价类划分： 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2）边界值分析法：是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3）错误猜测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4）因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

5）正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6）场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

7）状态图法：通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

8）大纲法：大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

13. 详细的描述一个测试活动完整的过程。（供参考，本答案主要是瀑布模型的做法）

项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后SQA进入项目，开始进行统计和跟踪

开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

测试用例完成后，测试和开发需要进行评审。

测试人员搭建环境

开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交给BugZilla。

开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。

重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。

如果有客户反馈的问题，需要测试人员协助重现并重新测试。

14. 说说你对集成测试中自顶向下集成和自底向上集成两个策略的理解，要谈出它们各自的优缺点和主要适应于哪种类型测试

自顶向下集成

1. 优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
2. 缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
3. 适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
4. 自底向上集成
5. 优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
6. 缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
7. 适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

15. 设计测试用例时应该考虑哪些方面，即不同的测试用例针对那些方面进行测试？

设计测试用例时需要注意的是，除了对整体流程及功能注意外，还要注意强度测试、性能测试、压力测试、边界值测试、稳定性测试、安全性测试等多方面。（测试用例需要考虑的四个基本要素是输入、输出、操作和测试环境；另外，测试用例需要考虑的是测试类型（功能、性能、安全……），这部分可以参照TP做答。此外，还需要考虑用例的重要性和优先级）

16. 在windows下保存一个文本文件时会弹出保存对话框，如果为文件名建立测试用例，等价类应该怎样划分？

单字节，如A；双字节， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式为8.3格式的；文件名格式为非8.3格式的；/,,*等九个特殊字符。

假设有一个文本框要求输入10个字符的邮政编码，对于该文本框应该怎样划分等价类？

特殊字符，如10个*或￥；英文字母，如ABCDefghik；小于十个字符，如123；大于十个字符，如11；数字和其他混合，如123AAAAAAA；空字符；保留字符

17. 单元测试、集成测试、系统测试的侧重点是什么？

1. 单元测试针对的是软件设计的最小单元--程序模块（面向过程中是函数、过程；面向对象中是类。）,进行正确性检验的测试工作,在于发现每个程序模块内部可能存在的差错.一般有两个步骤:人工静态检查\动态执行跟踪
2. 集成测试针对的是通过了单元测试的各个模块所集成起来的组件进行检验,其主要内容是各个单元模块之间的接口,以及各个模块集成后所实现的功能.
3. 系统测试针对的是集成好的软件系统，作为整个计算机系统的一个元素,与计算机硬件\外设\某些支持软件\数据和人员等其他系统元素结合在一起,要在实际的运行环境中,对计算机系统进行一系列的集成测试和确认测试.

18. 你所了解的的软件测试类型都有哪些，简单介绍一下。

按测试策略分类：

1、静态与动态测试

2、黑盒与白盒测试

3、手工和自动测试

4、冒烟测试

5、回归测试；

按测试阶段分类：单元测试、集成测试、系统测试；

其他常见测试方法：

1、功能测试

2、性能测试

3、压力测试

4、负载测试

5、易用性测试

6、安装测试

7、界面测试

8、配置测试

9、文档测试

10、兼容性测试

11、安全性测试

12、恢复测试

19. 您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

20. 一套完整的测试应该由哪些阶段组成？

可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试

21. 面向对象的测试用例设计有几种方法？如何实现？

给类中的每个构造函数设计一组测试用例

组合类中的类变量、实例变量

组合类中的各种方法

根据前置条件和后置条件设计测试用例

根据代码设计测试用例