关于软件测试(一）

什么是软件测试：
软件测试就是证明软件不存在错误的过程。
为了证明程序能够正确运行。
验证软件功能是否能满足用户的需求。

测试帮助项目管理者了解当前软件开发过程中的缺陷，以便及时纠错。
帮助测试人员设计出针对性的测试方法，改善测试中的效率和有效性。
让开发人员在知道错误产生的重灾区，加强自测试。
让客户清楚我们专业的质量保证团队，可以向他们提交一份满意的答卷。

测试和调试的区别：
测试是发现程序中的缺陷，调试是定位并解决程序中的问题。

软件的生命周期：
需求分析，计划，设计，编码，测试，运行维护

开发模型：

瀑布模型：线性模型。
测试阶段往往处于软件实现后，这意味着必须在代码完成后有足够的时间预留给 测试活动，否则将导致测试不充分，将缺陷直接遗留给用户。

螺旋模型：适合规模庞大，复杂度高，风险大的项目。
强调全过程的风险管理，强调各开发阶段的质量。提供机会检讨项目是否有价值继续下去。
缺点：引入非常严格的风险识别，风险分析和风险控制，这对风险管理的水平提出了更高的要求，需要人员，时间资金的投入。

增量、迭代：
增量：是逐块建造的概念，例如画人像，可以先画头，再画身体，再画手脚…
迭代：先画整体轮廓，再勾勒基本雏形，再细化，着色。
敏捷模型：
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。那敏捷测试是什么？敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。就像Scrum一样，Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。让我们看看Wikipedia 是如何描述敏捷测试的
敏捷测试就是持续地对软件质量问题进行及时地反馈

结论
敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，这些实践具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。和传统测试的区分，可以概括如下：

1. 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。

2. 传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。

3. 传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。

4. 传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。

5. 传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。

6. 传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。

7. 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

常考的一些面试题：

1、什么是兼容性测试?

答：兼容性测试是检查软件在不同软件平台，硬件平台上是否可以正常运行的测试。主要查看软件在不同操作系统、浏览器、数据库中运行是否正常。

2、你能不能说下你3-5年的职业规划?

答：首先，要巩固自己的测试基础知识，在基本知识扎实的情况下提高理解需求文档的能力。

其次，学习自动化测试工具，并将它运用到测试中去。

然后，在测试技术达到一定程度后，要学会如何带领一个测试团队。

最后，争取在最快的时间内达到测试经理的水平。

3、软件的评审一般由哪些人员参加?其目的是什么?

答：参加人员：客户、项目经理、开发人员、测试人员。

目的：查看软件在未正式投入运行前是否还存在问题。对于不同软硬件平台能否正常运行，是否存在着与客户理解不一致的地方，同时可以对一些可以改进的地方再进行修改。

4、什么是软件测试，软件测试的目的?

答：软件测试是通过人工或者自动化的操作进行还没有商业化用途的程序，查看他们的功能是否满足客户需求。

目的：在最短时间内找出尽可能多的软件缺陷。

5、开发人员总是犯一些低级错误怎么解决?

答：要在开发的前期就制定好一些编码规范，这样子可以减少很多由于个人习惯引起的错误。同时，测试人员在发现开发人员犯一些低级错误的时候不可以指责他们，要耐心的给他们指出错误所在。然后在让开发人员自己进行测试，从而找出错误。

6、什么是软件测试?

答：为了发现程序中的错误而执行程序的过程。

7、说下一个缺陷测试报告的组成?

答：缺陷编号、缺陷标题、缺陷描述、缺陷的优先级、缺陷的重要程度、缺陷所述的模块、缺陷所属的版本、缺陷所属的开发人员、输入数据、输出结果、缺陷分析等。

8、发现的缺陷越多，说明软件缺陷越多吗?

答：是的，通常如果发现一个缺陷的话，可能就会发现很多类似的缺陷，由于开发人员的习惯，可能一个地方有缺陷，另外一个地方就会有相同的缺陷。

9、所有的软件缺陷都能修复吗?所有的软件缺陷都要修复吗?

答：从理论上来说所有的缺陷都是可以修复的，但是并不是所有的缺陷都要修复。

一些对于软件没有影响的、不影响使用的缺陷我们可以不修复。因为修复些细小的缺陷需要花费很多时间。项目上面可能会因为时间问题而先忽略这些小缺陷。

10、您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

答：我一般都是做的Web测试，搭建测试环境，对于一个程序进行集成测试，系统测试，回归测试等。其中还要编写测试用例以及一些文档，用户使用手册，功能测试文档等等。最擅长的是功能测试。

11、开发人员说不是bug时，你如何应付?

答：首先把自己的见解告诉开发人员。在同开发人员沟通到底是不是bug，但是如果开发人员还是认为不是bug的话，就把这个问题提到项目经理处，同时附上自己的见解。由项目经理决定是否为bug。

12、软件测试项目从什么时候开始，为什么?

答：一般软件测试越早展开越好，一般是从需要阶段就要进行软件测试。软件测试不仅是测试功能，对于需求文档一类的也要进行测试。越早的找出bug，就会减少后续开发人员修改程序的次数，并且可以降低成本，如果等整个软件开发的差不多了发现一个致命的错误的话，是需要花费很多时间和人力进行重新修改的。如果在一开始就发现的话就不会出现这种情况了。

13、功能测试用例需要详细到什么程度才是合格的?

答：测试用例覆盖到所有的测试点。

14、测试用例通常包括哪些内容?

答：用例编号、测试环境、用例标题、输入数据、预期结果等。

15、你用什么测试方法进行测试?

答：根据不同的系统和模块有不同的方法。主要是黑盒测试和白盒测试。

测试用例的设计方法

 1．等价类划分

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

2．边界值分析法

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

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

3．错误推测法

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

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

4．因果图方法

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

请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

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

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

测试类型有：功能测试，性能测试，界面测试。

功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

简述负载测试与压力测试的区别。

压力测试（Stress Testing）

压力测试的主要任务就是获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力。例如，对服务器做压力测试时就可以增加并发操作的用户数量；或者不停地向服务器发送请求；或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的最大状态。人们通常使用测试工具来完成压力测试，如模拟上万个用户从终端同时登录，这是压力测试中常常使用的方法。

负载测试（Volume Testing）

用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高能达到什么程度。例如，对于信息检索系统，让它使用频率达到最大；对于多个终端的分时系统，让它所有的终端都开动。在使整个系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。

Beta测试与Alpha测试有什么区别？
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场

Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试