1. 自动化测试碰到比较难解决的问题是什么
有关自动化测试的误区
目前，有些人对自动化测试的认识存在一定的误区，因此有必要对自动化测试树立正确的认识，以防止对其有过高的期望。
1．自动化测试工具是“万能”的
很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试。
2．测试工具可适用于所有的测试
每种自动化测试工具都有它的应用范围和可用对象，所以不能认为一种自动化测试工具能够满足所有测试的需求。针对不同的测试目的和测试对象，应该选择合适的测试工具来对它进行测试。在很多情况下，需要利用多种测试工具或者开发自动化测试框架才能达到自动化测试的目的。商业和开源的测试工具能够用来进行自动化测试，但是我们需要根据自身产品的特点，开发自动化测试框架，在框架中提供常用的测试用例，加快测试速度，达到测试用例复用，这是今后测试自动化发展的道路。
3．测试工具能使工作量大幅度减少
事实上，引入自动化测试工具不会马上减少测试工作，相反，在更多情况下，首次将自动化测试工具引入企业时，测试工作实际上变得更艰巨了。只有在正确合理地使用测试工具，并有一定的技术积累之后，测试工作量才能逐渐减轻。
4．测试工具能实现100%的测试覆盖率
由于自动化测试可以增加测试覆盖的深度和广度，利用白盒测试工具可能实现语句全覆盖、逻辑路径全覆盖等，但因为穷举测试必须使用所有可能的数据，包括有效的和无效的测试数据，所以在有限的资源下也不可能进行100%的测试。
5．自动化测试工具容易使用
对于这一点，很多测试工程师有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单的，捕获的操作是否正确，以及脚本编辑是否合理都会影响测试结果。因此，自动化测试需要更多的技能，也需要更多的培训。
6．自动化测试能发现大量新缺陷
发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。自动化测试用于回归测试，而大量的新业务测试更多地还是依赖手工测试。
2. 自动化覆盖率是什么
覆盖率是度量测试完整性的一个手段，是测试有效性的一个度量。通过已执行代码表示，用于可靠性、稳定性以及性能的评测。测试覆盖是对测试完全程度的评测。测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。
3. 自动化测试会占整个测试多大比例
目前的趋势是用自动化测试取代人工手动测试，从而提高效率和节约成本，但是自动化前期投入比较高，所以占比要看公司的投入情况
4. 软件测试面试常见问题及答案是什么
黑盒测试的优点有：
比较简单，不需要了解程序内部的代码及实现，与软件的内部实现无关，从用户角度出发，能很容易地知道用户会用到哪些功能，会遇到哪些问题，基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。
黑盒测试的缺点有：
不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%，自动化测试的复用性较低。
白盒测试的优点有：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐 藏的问题。
白盒测试的缺点有：
程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，智能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。
严重级别的错误：
影响系统整体基本流程运行的错误，由于某一操作造成系统死循环或服务器崩溃的错误。
较严重：功能实现错误、内部计算错误。
一般：UI错误，一些易用性的错误或建。
5. 白盒测试各种覆盖率分别表示什么含义它们之间的关系
case1走ace路线，2条语句都被执行了，所以语句覆盖率为2/2，即100%。case1走abe路线，只执行了1条语句，所以语句覆盖率为1/2，即50%。
白盒测试时基于程序结构的逻辑驱动测试，白盒覆盖中最常见的是逻辑覆盖（也叫代码覆盖或结构化覆盖），逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
(5)前端自动化测试覆盖率扩展阅读：
注意事项：
以静力分析结果为基础，采用规范检验和动态试验的方法进一步确认静力分析结果，提高试验效率和精度。
覆盖测试是白盒测试的重要手段，可以作为测试报告中量化指标的依据。对于软件的关键模块，应该使用各种覆盖率标准来度量代码覆盖率。
验收测试阶段：根据开发经验的需求，产品能否满足使用要求，能否达到原来的设计水平，完成的功能如何，是否符合用户的需求，以达到预期的目的。
6. 衡量软件测试质量的指标 测试用例覆盖率概念
第一个问题：我想在测试之前，你需要写一个测试计划，其中最重要的是本次测试使用的测试方法，测试工具，测试环境使用。人事安排和进度输出后的工件每个测试阶段，也是一个风险评估。这些前的准备工作做的测试，所以测试时会更有条理。
第二个问题：质量控制的测试，我认为最好的是一个很好的测试案例的设计，所以你可以控制的覆盖范围的测试。
补充：如果有足够的时间来审查设计使用的情况下，这可以提高测试的质量。然而，在实际工作中通常不能实现。 。 。 。
下面列出的在线软测量笔试题，很多单位在笔试复制下来作为一支笔的问题的时候，我至少召开两次会议，还有其他的问题笔，但它并没有列出。
True或False（每题1分，12分，正确的√，错误╳）
1。软件测试的目的是尽可能多地确定一个软件缺陷。 （）
2。 Beta测试是验收测试。 （）
3。验收测试是由最终用户实施。 （）
4。项目测定测试者不需要提交任何工件。 （）
五，单元测试发现，大约有80％的软件缺陷。 （）
六个。，代码审查是检查源代码模块的设计要求。 （）
七个。，自底向上的集成需要测试人员编写驱动程序。 （）
八个。负载测试，以验证该系统的能力被测试到什么程度。 （）
九个。，测试人员应坚持的原则，缺陷未修复完坚决不予通过。 （）
10。代码评审一般由测试人员举行。 （）
11。我们可以人为地使软件配置的问题不存在。 （）
12。集成测试计划，需求分析阶段结束时提交。 （）
二，挥发选择题（每题2分，10分）
1。合格的软件验收测试标准是：（）
A.软件需求分析说明书中定义的所有功能已经实现，性能指标均达到要求。
B.所有测试项目无残留的一级，二级和三级错误。
C.项目审批表，需求分析文档，设计文档和编码来达到同样的。
D.验收测试是完整的工件。
2。软件测试计划将评估需要哪些人参加？ （）
A.项目经理
B. SQA负责人
C.负责人配置
D.试验组
3 。在alpha测试下面的描述是：（）
A. alpha测试的需要用户代表
B. alpha测试不需要用户代表
C. alpha测试是系统测试的
D. alpha测试验收测试一类
4。测试设计师职责：（）
A.测试计划
B.设计测试用例
C.设计测试过程中，该脚本
D.评估测试活动
>
5。软件实施活动的进入准则：（）
A.需求工件基线技术
B.详细设计的基线
C.框架的工件的工件一直有一直基线
D.项目阶段成果已经基线
三，填补空白（每空1分，24分）
1。软件验收测试（正式验收测试）（非正式验收测试和alpha测试），（公开测试）三种类型。
2。系统测试策略功能测试（性能测试），负载测试，压力测试，可用性测试（能力测试），（强度试验），（也被称为兼容性测试），本地化测试（BVT测试）， （裸机试验），（安全测试），（），（容错试验），（恢复试验），（）15的方式。
3。设计系统测试计划需要参考项目文档（要求规范），（），和迭代计划。
4。面向过程的系统集成策略（），（）两种。
5个。编写测试用例一步绘制因果图，为五个步骤的状态图和因果关系图。
四，简答题（37分）
1。阶段评估和同行评议的差异。 （4分）
2。什么是软件测试。 （3分）
回答：以手动或自动的方式对系统进行测试，以验证系统是否满足预定的功能是要弄清楚实际结果和预期结果之间的差异。
3。简述集成测试的过程中。 （5分）
回答：单元的单元测试，模块组合再进行测试，按照设计要求。是否有检查的程序界面上的焦点问题。
过程：首先，集成测试的测试计划？测试 - >测试 - 开发 - > - >测试 - 评估测试用例执行，缺陷跟踪。
4。如何做一个文件测试？ （4分）
答：文档测试时应注意以下几点：观众的文件，术语的文档的正确性，文件，文件的完整性，一致性的文件，文档，易用性示例例如，语言的文件，
5。白盒测试几种方法？ （6分）
答：白盒测试方法分为：静态测试和动态测试
静态测试方法：（1）编码标准和原则（2）演练（3）审查（ 4）评估
动态测试方法：①语句覆盖（2）确定的条件（3）盖盖（4）判断 - 条件覆盖⑤条件组合覆盖⑥路径覆盖
⑦条件组合+路径覆盖
6。系统测试计划需要进行同行评审，为什么？ （4分）
答：系统测试计划是同行评审，测试需要很长一段时间，甚至可能
免疫系统的现象，它可以是一个同行评议，减少疲劳疲劳试验系统测试在同一系统上。
7。测试和β测试的区别。 （4分）
8。比较负载测试，容量测试和压力测试的区别。 （6分）
9。测试结束的标准是什么？ （3分）
7. 软件测试中覆盖率是什么意思
简单说就是测试中需要测试到的东西你测试了多少。比如：正常测试需要测试100个点，你测试了85个，说明你的测试覆盖率为85%。覆盖率越高测试的质量相对越好。
8. 为什么要对程序做代码覆盖率测试
关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个!
前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率?最重要的是于测试工作而言有怎样的价值呢?今天花了一点时间查了一下，有了初步的认识。大致归纳如下：
一、基本概念
代码覆盖率是单元测试活动任务之一;
覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。
二、价值
代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢?如何让它给我们带来价值呢?
1. 尽早评估代码质量
比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。
2. 为功能测试关注点提供情报
假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。
3. 估计修改已有代码所需的时间
对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。
当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。
9. 自动化测试是软件测试的重要手段，自动化测试有什么优势和手工测试有什么不同
自动化测试相对于手工测试优点如下：
1、可以模拟人工测试，减少重复机械的测试工作量，大量用于回归测试；
2、可以提高测试精度，例如进行大数据量的正确性校验；
3、进行人工难以执行的测试，例如单元测试、统计测试覆盖率等等；
4、用于模拟多线程的并发；
5、更好地利用资源。将繁琐的任务自动化。
6、测试具有一致性和可重复性。
7、测试的复用性。由于自动测试通常采用脚本技术，领测认为这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
8、增加软件信任度。
10. 软件测试中执行覆盖率怎么计算。
软件测试覆盖率
覆盖率=(至少被执行一次的item数)/item的总数
语句覆盖率=(至少被执行一次的语句数量)/(可执行的语句总数)
判定覆盖率=(判定结果被评价的次数)/(判定结果总数)
条件覆盖率=(条件操作数值至少被评价一次的数量)/(条件操作数值的总数)
判定条件覆盖率=(条件操作数值或判定结果至少被评价一次的数量)/(条件操作数值总数+判定结果总数)
路径覆盖率=(至少被执行一次的路径数)/(总的路径数)
需求覆盖率=(被验证到的需求数量)/(总的需求数量)
继承上下文判定覆盖率=(累加每个上下文内执行到的判定分支数)/(上下文数*上下文内的判定分支总数)
基于状态的上下文入口覆盖率=(累加每个状态内执行到的方法数)/(状态数*类内方法总数)
函数覆盖率=(至少被执行一次的函数数量)/(系统中函数的总数)
指令块覆盖率=(至少被执行的一次指令块的数量)/(系统中指令块总数)
DDP覆盖率=(至少被执行的一次的判定路径数量)/( 系统中判定路径总数)
分支条件组合覆盖率=(被评测到的分支条件组合数)/(分支条件组合数)
PPP覆盖率=(至少被执行的一次的PPP数量)/( 系统中PPP总数)