软件测试汇总

软件测试的22种类型：

（1）黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。

（2）白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

（3）单元测试：最微小规模的测试；以测试某个功能或代码块。典型的由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构；还可能需要开发测试驱动器模块或测试套具。

（4）集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、 络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

（5）功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作（自然他能用于测试的各个阶段）。

（6）累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来； 这种测试可由程序员或测试员来做。

（7）系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。

（8）端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用 络通讯，或与外部硬件、应用系统或适当的系统对话。

（9）比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。

（10）Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

（11）Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。

（12）健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

（13）衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

（14）接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。

（15）负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。

（16）强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。

（17）性能测试：在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”（和其他类型的测试）应在需求文档或质量保证、测试计划中定义。

（18）安装/卸载测试：对软件的全部、部分或升级安装/卸载处理过程的测试。

（19）恢复测试：测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。

（20）安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

（21）可用性测试：对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

（22）兼容测试：测试软件在一个特定的硬件/软件/操作系统/ 络等环境下的性能如何。

 

有效Bug怎么写span>

      拙劣的bug 告，例如：

　　在 告中说“不好用”；

　　所 告内容毫无意义；

　　在 告中用户没有提供足够的信息；

　　在 告中提供了错误信息；

　　所 告的问题是由于用户的过失而产生的；

　　所 告的问题是由于其他程序的错误而产生的；

　　所 告的问题是由于 络错误而产生的；

　　

　　简单地说， 告bug的目的是为了让程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

　　在bug 告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。如果愿意的话，您可以省去推测，但是千万别省略事实。

　　“程序不好用”

　　程序员不是弱智：如果程序一点都不好用，他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。他们需要信息， 告bug也是为了提供信息。信息总是越多越好。

　　许多程序，特别是自由软件，会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了，那就不必再 告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。

　　如果您不是 告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。

　　“演示给我看”

　　 告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。

他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。

　　这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题，他们通常会找到原因并开始试着修改。

　　“告诉我该怎么做”

　　如今是 络时代，是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里，当然他也可以用同样简单的方法给我一些建议。但是如果我的程序出了什么问题，我不可能在他旁边。“演示”是很好的办法，但是常常做不到。

　　如果您必须 告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。

　　确切地告诉程序员您做了些什么。如果是一个图形界面程序，告诉他们您按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。

　　把您能想到的所有的输入方式都告诉程序员，如果程序要读取一个文件，您可能需要发一个文件的拷贝给他们。如果程序需要通过 络与另一台电脑通讯，您或许不能把那台电脑复制过去，但至少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。

　　“哪儿出错了看来一切正常哦！”

　　如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。

　　同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。

　　如果您看到了错误消息，一定要仔细、准确的告诉程序员，这确实很重要。在这种情况下，程序员只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所 的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息，就把它们写下来。只 告“程序出了一个错”是毫无意义的，除非您把错误消息一块 上来。

　　特殊情况下，如果有错误消息 ，一定要把这些 码告诉程序员。不要以为您看不出任何意义，它就没有意义。错误消息 包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。给错误消息编 是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。

　　在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息 以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，保存好。

 

软测面试经验转贴 

第一关：首先要自我介绍，自己的性格怎么样，目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看对于软件测试有什么自己的想法。为什么会想到要做这行（因为我的简历上的工作经历没有关于测试方面的）。哦，还有期望薪资。
第二关：认为软件测试人员所要具备的基本素质，如果遇到问题会怎样处理，如果得不到研发人员的配合（就是研发说这个不是问题）你又会怎么处理就是一些基本概念，比如软件测试的流程有哪些我上任了，首先会怎么开始自己的工作计划。
（前两关通过了后面这个就好过多了）
第三关：像我介绍了一下公司的情况，告诉我主要针对什么内容的测试，会不会使用数据库。告诉我大概要做哪些内容，详细的可以上岗以后慢慢熟悉。

关键是要给对方留下好印象:)

 面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问，这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会：
你可以问：贵公司近期和远期的发展目标是什么司的主要竞争对手有哪些司有多少开发人员有多少测试人员司又进一步扩充测试人员的计划吗我有幸能进入贵公司的话，我有怎么样的发展人员的沟通能力很重要，贵公司有规范的沟通渠道吗绍一下贵公司的福利情况。请问我什么时候能知道结果p>

 

软测面试考察点： 

对测试的理解——基本的测试知识，对测试是否认可p>

谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力、测试技能
测试设计的方法并举例说明——测试技术的使用
测试工具——熟悉程度，能否与当前工作匹配r> 如何做计划跟踪计划日常工作能力
如果开发人员提供的版本不满足测试的条件，如何做与开发人员协作的能力
熟悉unix系统、oracle数据库吗是否具备系统知识
做过开发吗哪些代码开发技能
阅读英语文章，给出理解说明部分英语能力
文档的意义——是否善于思考简单的概念，不同层次的理解）
假如进入我们公司，对我们哪些方面会有帮助讲讲自己的特长
随便找一件物品，让其测试——测试的实际操作能力

1. 阅读英文文章，给出理解说明，简单的英文自我介绍
2. 做测试多久了试之前是否从事过其它工作果简历中有或者自我介绍中提到过则跳过此条）
3. 为什么选择测试这行r> 4. 您找工作时，最重要的考虑因素为何r> 5. 您在以往的测试工作中都曾经具体从事过哪些工作最擅长哪部分工作r> 6. 一个测试工程师应具备那些素质和技能个问题可以继续考察数据库，linux，
编程语言， 络知识，沟通能力等方面知识）
7. 你们以前测试的流程是怎样的为理想的测试流程是怎样的r> 8. 用过哪些测试流程管理工具r> 9. 简述一下Bug的生命周期（Open——Closed）
10. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容提交高质量的软件缺陷（Bug）记录
11. 测试用例的内容有哪些，编写方法有哪些，（针对一个邮编地址的输入框设计测试用例）
12. 对自动化测试了解多少哪些自动化测试工具以及掌握程度，能结合以前的项目谈一谈吗r> 13. 什么是性能测试性能测试项目经验吗项目简述使用工具及过程
14. 能不能说下你的近期（半年到2年）和长期（3到5年）的职业计划（规划）
15. 假如进入我们公司，对我们哪些方面会有帮助讲讲自己的特长
16. 谈谈生活中的爱好
17. 对公司的了解，基于现在的了解是否有其它疑问

 

软测面试汇总：

1、软件测试
使用人工或自动的方法来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果的区别

2、集成测试的过程
计划阶段、设计阶段、实现阶段、实施阶段

3、白盒测试方法
桌前走查、单元测试、代码评审、同行评审、代码走查、静态分析

4、alpha和beta测试的区别
都属于系统测试
A是在实验室在专业测试人员的指导下，由非专业人士参加，测试问题可以马上得到反馈，代价较大
B是开放型测试，内部测试稳定后，发布Beta版本让公共用户测试，缺陷不能有效地反馈，需要将收集的信息整理为有用的缺陷 告，成本较低

5、测试结束的标准
严重程度在某一可接受范围内的缺陷都已经关闭
是否达到原先的覆盖定义标准
团队集体同意

6、软件测试活动的输出文档
测试计划、测试用例、缺陷 告、测试总结

7、测试活动中集成员的工作是
开发桩模块和驱动模块

8、驱动模块、桩模块
驱动模块：大多数场合称为”主程序”，它接收测试数据并将这些数据传递到被测试模块
桩模块：集成测试前，要为被测模块编制一些模拟其下调用模块的程序

9、软件缺陷等级
按严重程度分为
致命性错误，严重性错误，一般性错误，告警错误，建议

10、白盒测试
分为静态测试与动态测试2类测试方法
静态分析是一种不通过运行来测试的技术，是检验软件的表示和描述是否一致，没有歧义没有冲突
动态分析是软件在模拟的或真实的环境中运行之前、之中、之后，对软件系统行为的分析。
动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。分为：语句覆盖、路径覆盖、条件覆盖、分支覆盖、条件/判定覆盖、组合覆盖。

11、项目测试的全过程(软件生命周期)
测试流程：制定测试计划、测试设计与开发、实施软件测试、评审、版本发布

12、缺陷 告的处理流程
提交缺陷 告－》分配缺陷 告－》处理缺陷 告－》返测 告－》关闭缺陷 告

13、软件生命周期（瀑布）
计划－》需求分析－》设计－》编码－》测试 －》运行、维护

14、V模型
用户需求                          验收测试
  需求分析与系统           系统测试
      概要设计                集成测试
         详细设计           单元测试
                     编码

15、常用的测试方法（测试策略）
数据库测试、功能确认测试、界面测试、值域测试、版本验证测试、可用性测试、强度测试。安全性测试、裸机测试、安装测试、加密测试、功能测试、性能测试、压力测试、负载测试、易用性测试、安装测试、界面测试、配置测试、文档测试、兼容性测试、安全性测试、恢复测试

16、常用的设计用例方法
等价类划分、边界值分析、因果图、通过测试和失败测试、错误猜测、随机测试

17、测试工作的认识过程及以后工作的建议

18、缺陷 告、测试计划、用例、总结的组成

19、基于WEB信息管理系统测试时应考虑的因素有哪些p>

20、软件本地化测试比功能测试都有哪些方面需要注意p>

21、测试计划工作的目的是什么计划工作的内容都包括什么哪些是最重要的p>

22、为什么要在一个团队中开展软件测试工作r> 因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试 告中得出软件的质量情况。

23、您在以往的测试工作中都曾经具体从事过哪些工作最擅长哪部分工作r> 我曾经做过web测试，后台测试，客户端软件，其中包括功能测试，性能测试，用户体验测试。最擅长的是功能测试

24、您所熟悉的软件测试类型都有哪些着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试

25、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。
　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
（1）是否有不正确或遗漏的功能r> （2）在接口上，输入是否能正确的接受输出正确的结果r> （3）是否有数据结构错误或外部信息（例如数据文件）访问错误r> （4）性能上是否能够满足要求r> （5）是否有初始化或终止性错误r> 　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
（1）对程序模块的所有独立的执行路径至少测试一遍。
（2）对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
（3）在循环的边界和运行的界限内执行循环体。
（4）测试内部数据结构的有效性，等等。
单元测试：单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
    单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试:集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试：系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）
    系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试：验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

26、测试计划工作的目的是什么计划工作的内容都包括什么哪些是最重要的r> 软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）

27、您认为做好测试计划工作的关键是什么r> （1）明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
（2）坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
（3）采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
（4）分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

28、 您所熟悉的测试用例设计方法都有哪些别以具体的例子来说明这些方法在测试用例设计工作中的应用。
（1）等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
（2）边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
（3）错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
（4）因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

29、您认为做好测试用例设计工作的关键是什么r> 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口
不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

30、请以您以往的实际工作为例， 详细的描述一次测试用例设计的完整的过程。
站功能的测试：
首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步：设计测试用例，测试策略是：把 站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试）， 站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的 站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位）， 站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤， 站才算完成了它的任务。有3个步骤呢，就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
第三步：搭建测试环境（为什么这个时候考虑测试环境呢我对 站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为 站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢， 站部分只用到了tomcat，所以只要有tomcat即可
第四步：执行测试

31、您以往是否曾经从事过性能测试工作有，请尽可能的详细描述您以往的性能测试工作的完整过程。
是的，曾经做过 站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位 站性能测试经验非常丰富的前辈带着我一起做。
性能测试类型包括负载测试，强度测试，容量测试等
    负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
    强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
    容量测试：确定系统可处理同时在线的最大用户数 
在 站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比显示）
Web服务器指标指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；

32、您在从事性能测试工作时，是否使用过一些测试工具有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

33、您认为性能测试工作的目的是什么性能测试工作的关键是什么p>

34、在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容提交高质量的软件缺陷（Bug）记录p>

35、您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

36、您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果测试人员同开发团队中其他成员良好的人际关系的关键是什么p>

37、在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么如何来对待这些事情的p>

38、在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

39、你对测试最大的兴趣在哪里么r>     最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试 上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
    刚开始进入测试行业时，对测试的认识是从 上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
    不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。
    我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说 站吧，最基本的技术知识你要知道 站内部是怎么运作的的，后台是怎么响应用户请求的环境如何搭建都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题细节是不是没有确定好问题都能在设计用例的时候发现。第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么你够厉害的话，可以帮开发人员初步定位问题。

40、你的测试职业发展是什么r> 测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

41、你自认为测试的优势在哪里r> 优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

42、你以前工作时的测试流程是什么r>     公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。
     以前公司主要是从事市场分析，工作期间调研相关市场行情-》与销售中心进行沟通明确需求-》收集数据-》着手写 告-》完成 告-》更新 告，总体的战略规划方面，产品分类（由市场分析 告将产品生命周期分为新品、畅销、常销、定制、退市）-》新品上市（上市计划，卖点穿透，资源匹配）-》老品管理（库存周转 告控制库存:避免库存过大避免缺货-》库龄、库存成本对所有品种计算库存跌价-》由跌价后净值率对产品分成不同的折扣区间-》由5个区间不断往下推进直到到最后一个区间退市兜底产品发出退市通知），市场拓展方面，负责入驻淘宝商城及早期页面修改维护（使搜索排名靠前、增加预售专区博客微博连载、量子统计、市场推广、页面维护） 
数据仓库：http://baike.baidu.com/view/19711.htm=ala0_1_1
    数据仓库（DW或DWH，Data Warehouse）是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。
    特点
　　1、数据仓库是面向主题的；(数据库是面向事务的设计) 　　2、数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出数据仓库的核心工具来，进行加工与集成，统一与综合之后才能进入数据仓库； 　　3、数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询； 　　4、数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。 　　5、汇总的。操作性数据映射成决策可用的格式。 　　6、大容量。时间序列数据集合通常都非常大。 　　7、非规范化的。Dw数据可以是而且经常是冗余的
8、元数据。将描述数据的数据保存起来。 9、数据源。数据来自内部的和外部的非集成操作系统。
    设计步骤
　　1)选择合适的主题（所要解决问题的领域） 　　2)明确定义事实表 　　3)确定和确认维 　　4)选择事实表 　　5)计算并存储fact表中的衍生数据段 　　6)转换维表 　　7)数据库数据采集 　　8)根据需求刷新维表 　　9)确定查询优先级和查询模式。
     建立步骤
　　1)收集和分析业务需求 　　数据仓库价值曲线
2)建立数据模型和数据仓库的物理设计 　　3)定义数据源 　　4)选择数据仓库技术和平台 　　5)从操作型数据库中抽取、净化、和转换数据到数据仓库 　　6)选择访问和 表工具 　　7)选择数据库连接软件 　　8)选择数据分析和数据展示软件 　　9)更新数据仓库

   
43、当开发人员说不是BUG时，你如何应付r> 开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么被用户发现或出了问题，会有什么不良结果员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

44、你为什么想离开目前的职务r> 因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。　
45、你对我们公司了解有多少p>

46、你找工作时，最重要的考虑因素为何r> 工作的性质和内容是否能让我发挥所长，并不断成长。

47、为什么我们应该录取你r> 您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

48、请谈谈你个人的最大特色。
我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

49、白箱测试和黑箱测试是什么是回归测试r> 50、单元测试、集成测试、系统测试的侧重点是什么r> 51、设计用例的方法、依据有那些r> 52、一个测试工程师应具备那些素质和技能r> 53、集成测试通常都有那些策略r> 54、你用过的测试工具的主要功能、性能及其他r> 55、一个缺陷测试 告的组成
56、基于WEB信息管理系统测试时应考虑的因素有哪些r> 57、软件测试项目从什么时候开始，么r> 58、需求测试注意事项有哪些r> 59、简述一下缺陷的生命周期
60、测试分析测试用例注意（事项）r> 61、你在你所在的公司是怎么开展测试工作的何组织的r> 62、你认为理想的测试流程是什么样子r> 63、你是怎样工作的r> 64、软件测试活动的生命周期是什么r> 65、请画出软件测试活动的流程图r> 66、针对缺陷采取怎样管理措施r> 67、什么是测试评估评估的范围是什么r> 68、如果能够执行完美的黑盒测试，还需要进行白盒测试吗么r> 69、测试结束的标准是什么r> 70、软件验收测试除了alpha,beta测试以外,还有哪一种r> 72、做测试多久了做过哪些项目p>

72、你们以前测试的流程是怎样的r>     测试计划－测试用例设计－测试执行－测试分析 告

73、用过哪些测试工具么选择测试这行r>     它是一个新兴的行业，有发展潜力，而且很锻炼人，需要掌握更多的技能，比做开发要更难

74、为什么值得他们公司雇用r>       帮助公司提高软件质量和测试部门的技术水平
75、如果我雇用你，你能给部门带来什么贡献r>       分享我的测试经验和测试技能，提高测试部门技术水平
76、如何从工作中看出你是个自动自觉的人
     自动自觉范围太广
      1. 工作成果
      2. 工作质量
77、你的工作通常能在时限内完成吗.（我想问一下就是她问这个问题的动机是什么）
      在有足够的资源和合理的工作量的情况下，完全可以按时完成，并能比一般人做的更好
78、通常你对于别人批评你会有什么样的反应
  有错即改，无措勉之
79、如果明知这样做不对，你还会依主管的指过去做吗
     在公司内部下级是否有申诉渠道r> 80、如果你接到一个客户抱怨的电话，你确知无法解决他的问题，你会怎么处理
    为什么抱怨么样的问题r>      如果是客服问题，提交客服部门解决
    如果是质量问题，分析原因，下一版本改进
81、你觉得什么样的人最难相处
     自以为是的人
82、什么叫单元测试p>

    功能测试，性能测试，界面测试，安全测试（可以简单点，比如只涉及到COOKIES里的内容），压力测试（商业性质的 站） 等等，B/S软件也要根据其具体功能采用不同的测试策略。
83、请就软件测试人员应该具备什么样的基本素质说说你的看法。

     态度、责任心、自信、敏锐的观察力、良好的发散思维
84、请就如何在开发中进行软件质量控制说说你的看法

     先设计后开发模式，加强单元测试，加强代码走查，有一套完整的白盒测试方法。关键是加强开发人员的质量意识，增进程序员向工程师水平发展。
85、简述软件测试的意义，以及软件测试的分类

    意义嘛，就自己想吧。软件测试的分类，这个很多人都按各种方法去分。无明确答案

86、你在五年内的个人目标和职业目标分别是什么r> 　　分析这个问题是用来了解你的计划能力的，通过这个问题，面试人同时还可以知道你的目标是否符合企业对你的安排。
　　错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁，我认为做太多的个人计划是荒谬可笑的，不是吗r> 　　评论这种回答属于令人反感的一类。首先，当有人想了解你的目标时，”将来的某个时候”这种通俗说法并不奏效。其次，认为企业很脆弱，领导者更换频繁，这种说法毫无疑问会令人反感，而且也是不合理的。最后，认为做计划可笑，看不起这个问题，而且反问面试人，这些都注定了这样的求职者最终会失败。
　　正确回答从现在起的五年之内，我希望能够在一个很好的职位上待几年，而且最好有一次晋升，然后就期待着下一步。不管是向上提升，还是在企业内横向调动，对我个人来说，我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
　　评论这个问题没有回答得过分具体（那样可能会产生漏洞），而且它表明你有雄心，并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望，表明你是一个有灵活性的人。
87、你怎样做出自己的职业选择r> 　　分析 面试人提出这个问题是为了了解求职者的动机，看看他（她）应聘这份工作是否有什么历史渊源，是否有职业规划，是不是仅仅在漫无目的地申请很多工作。
　　错误回答 我一直都想在企业界工作。自孩提时代起，我就梦想自己至少也要成为大企业的副总裁。
　　评论 除了难以令人相信之外，这种回答还存在一个问题：它表明求职者会对副总裁以下的职位不感兴趣。
　　正确回答 在上大学四年级前的那个夏天，我决定集中精力在某一领域谋求发展。尽管我是学商业的，但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标，想清楚了自己擅长做的事情以及想从工作中得到的东西，最后我得出了一个坚定的结论，那就是这个行业是最适合我的。
　　评论 这种回答表明，求职者认真地做过一些计划，缩小了自己的关注点，而且也认准了前进的方向。这种回答还表明，求职者理解个人职业规划的重要性，并且有能力做出认真的个人决策。

88、你都用什么测试方法
针对不同的产品或者系统或者模块，有不同的测试方法。总体而言有白盒测试和黑盒测试。
89、怎么编写案例
案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
90、怎么才能够全面的测试到每一个点
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点。

91、谈谈软件测试技术，以及如何提高
92、谈谈软件测试职业发展，以及个人的打算
93、谈谈软件测试在企业的地位，也可以结合软件生命周期来谈
有可能清晰的思路比确切的答案更重要
94、软件测试的方法有r> 95、软件测试的过程p>

96、有一个新的软件，假如你是测试工程师，该如何做r> 97、软件测试分哪两种方法适合什么情况r> 98、一套完整的测试应该由哪些阶段组成阐述一下各个阶段。
99、软件测试的类型有那些比较这些不同的测试类型的区别与联系。
100、测试用例通常包括那些内容阐述编制测试用例的具体做法
101、在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试存在什么样的区别与联系r> 102、在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因采取哪些方法去检查这个原因r> 103、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程

104、测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

        设计测试用例需要考虑以下问题：

        测试用例的基本格式:软件测试用例的基本要素包括测试用例编 、测试标题、重要级别、测试输入、操作步骤、预期结果

       (1).用例编 ： 测试用例的编 有一定的规则，比如系统测试用例的编 这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编 。定义测试用例编 ，便于查找测试用例，便于测试用例的跟踪。

       (2).测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

       (3).重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然.

       (4).测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

       (5).操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

       (6).预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

105、软件测试分哪两种方法适合什么情况br> 软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
106、一套完整的测试应该由哪些阶段组成阐述一下各个阶段。
计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试
一套完整的测试应该由五个阶段组成：
(1)．测试计划
首先，根据用户需求 告中关于功能要求和性能指标的规格说明书，定义相应的测试需求 告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
(2)．测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
(3)．测试开发
建立可重复使用的自动测试过程。
(4)．测试执行
执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
(5)．测试评估
结合量化的测试覆盖域及缺陷跟踪 告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
107、软件测试的类型有那些比较这些不同的测试类型的区别与联系。
BVT (Build Verification Test)，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确
Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况
Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低
此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等
108、测试用例通常包括那些内容阐述编制测试用例的具体做法
不同结构的用例包括的不一样。（版本、编 、项目、设计人员、设计日期、输入、预期输出……）
软件测试用例的基本要素包括测试用例编 、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编 ： 测试用例的编 有一定的规则，比如系统测试用例的编 这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编 。定义测试用例编 ，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ”

109、bug定义 ，软件测试定义

110、软件测试自动化含义测试用到自动化测试p>

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以及性能测试方面）。

111、性能测试目标和原理是什么种为例说明协议选择的原则和方法

112、功能测试方法有哪些b常用的功能测试方法有哪些p>

113、测试脚本运行不畅时如何调试p>

114、事务、资源利用率、思考时间、迭代，用软件测试角度解释这些名词

115、编写windows自带的简单计算器的测试用例

116、单元测试的主要内容测试的主要内容测试与系统测试的关系是什么p>

117、试用一种最熟悉的编程语言计算sum=1+2+3+^+100

118、某OA系统，常规的测试流程是提交bug给测试主管A，然后督促响应的开发人员B来修改，在短暂的测试时间内，需不断的做回归测试，测试异常终止，客户提出的测试不充分的批评，如何处理解答客户的问题是回归测试p>

      ppt>2M时系统会崩，这个问题需尽快解决，此时A、B都不在，应该如何发邮件给开发主管p>

 

 

 

TestingTop测通软件测试面试题：

http://testingtop.com/bbs/viewthread.phpd=7682&extra=page%3D1

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表32843 人正在系统学习中