笔试ing…软件测试方面

1：单元测试、集成测试、系统测试、验收测试、回归测试这几步中最重要的是哪一步/h3>

这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。

2：集成测试和系统测试的区别及应用场景

区别：
1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD（概要设计文档）的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。

2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。

3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。

系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

3：测试项目具体工作是什么/h3>

搭建测试环境 – 撰写测试用例 – 执行测试计划 – 写测试计划，测试报告 – 测试，并提交BUG表单 – 跟踪BUG修改情况 – 执行自动化测试，编写脚本，执行，分析，报告 – 进行性能测试，压力测试等其他测试，执行，分析，调优，报告

4：黑盒测试中等价类划分

等价类划分的方法就是将程序的输入域划分为若干部分，也可以说是若干个等价类，然后从各个部分中选取少数代表性数据进行测试。每个类的代表性数据在测试中的作用等效于这一类中的其它值，也就是说，只要这个类中的某个值发现了缺陷，那么这个类中的其它任何一个值也都可以起到同样的效果，反之亦然，只要能够通过一个类中某个数据的验证，那么对于该类中其他任何一个数据，验证都是可以通过的
根据上面的描述，在等价类划分方法中，我们只需要在每个等价类集合中选取一个数据作为测试用例数据即可，因为每个数据和其集合内部的其它数据都是等价的，这样就可以用少量用例达到较好的测试效果，从而平衡测试效率和测试效果。
最后，要想使用等价类划分这种方法来设计测试用例，一定要先根据需求规格说明划分等价类，列出等价类表。
等价类：
等价类就是指某个输入域的子集合，并且在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并且合理的假定测试某等价类的代表值就等效于测试了这个等价类集合中的所有值。
根据软件的输入情况，可以将等价类划分为以下两大类型：

有效等价类：指对于程序的规格说明来说是合理的，有意义或者说正确的数据构成的输入集合。
无效等价类：与有效等价类相反，指对于程序的规格说明来说是无意义或者说错误的输入数据构成的集合。

等价类表:
在确定被测对象的输入域等价类后，就可以将有效等价类和无效等价类根据一定的格式形成等价类表，等价类表的绘制可以参考以下两个图：

测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件的开发的成本。在V模型中，测试过程被加在开发的后半部分，单元测试所检测代码的开发是否符合详细设计的需求。集成测试所检测此前测试过的各组成部分是否能完好的结合在一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。V模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型有两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和 测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 W模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。

9：自动化测试意义

• 可以对程序的新版本自动执行回归测试；
• 可以执行手工测试困难或者不可能实现的测试，如压力测试、并发测试；
• 能后更好的利用资源，节省时间和人力， 执行自动化测试之前首先判断这个项目是不是和推广自动化测试，然后对项目做需求分析，指定测试计划，搭建自动化测试框架，设计测试用例，执行测试，评估。

10：设计测试用例的方法

黑盒测试：

• 1.等价类划分 等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
• 2.边界值分析法 边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。
  边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。
• 3.正交试验法 正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
• 4.状态迁移法 状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
• 5.流程分析法 流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
• 6.输入域测试法 输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑 极端测试、中间范围测试，特殊值测试。
• 7.输出域分析法 输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。
• 8.判定表分析法 判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确；
• 9.因果图法 因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
• 10.错误猜测法 错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例。
• 11.异常分析法 异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。

白盒测试：

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：

1. 保证一个模块中的所有独立路径至少被测试一次；
2. 所有逻辑值均需要测试真（true）和假（false）两种情况；
3. 检查程序的内部数据结构，保证其结构的有效性；
4. 在上下边界及可操作范围内运行所有循环。

常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

11：你在项目中关于功能测试和接口测试是怎么做的/h3>

功能测试：首先制定测试计划，然后进行测试设计，将在测试计划阶段指定的测试活动分解，进而细化为若干个可执行程序的子测试程序，然后执行测试，按照测试计划使用测试用例对待项目进行逐一的详细的排查分析评估，最后对测试结果进行统计和分析。
接口测试：①需求文档 ②根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法） ③执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。

12：性能测试指标，对于登录功能做性能测试，有哪些指标，怎样测出可同时处理的最大请求数量

性能测试常用指标：
外部看：

• 吞吐量：每秒钟系统能够处理的请求数，任务数
• 响应时间：服务处理一个请求或一个任务的耗时
• 错误率：一批请求中结果出错的请求所占比例

服务器角度看：CPU，内存，服务器负载，网络，磁盘I/O；

对登录功能做性能测试指标：

• 单用户登陆的响应界面是否符合预期
• 单用户登陆时后台请求数量是否过多
• 高并发场景下用户登录的响应界面是否符合预期
• 高并发场景下服务端的监控指标是否符合预期
• 高集合点并发场景下是否存在资源死锁和不合理的资源等待
• 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏

怎么测出可同时处理的最大请求数量：
可以采用性能测试工具（WeTest服务器性能，该工具是腾讯WeTest团队出品，使用起来简单方便，但测试功能相当强大，能提供10w+以上的并发量，定位性能拐点，测出服务器模型最大并发）

13：手工测试和自动化测试优缺点

手工测试

缺点：

• 1、重复的手工回归测试，代价昂贵、容易出错。
• 2、依赖于软件测试人员的能力。

优点：

• 1、测试人员具有经验和对错误的猜测能力。
• 2、测试人员具有审美能力和心理体验。
• 3、测试人员具有是非判断和逻辑推理能力。

自动化测试

优点：

• 1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

• 2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

• 3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。

• 4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。

• 5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

• 6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

• 7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。

缺点：

• 1、不能取代手工测试
• 2、手工测试比自动测试发现的缺陷更多
• 3、对测试质量的依赖性极大
• 4、测试自动化不能提高有效性
• 5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发
• 6、工具本身并无想像力

14：单元测试可行吗/h3>

可行，单元测试可以有效地测试某个程序模块的行为，是未来重构代码的信心保证。事前可以保证质量，事后可以快速复现问题，并在修改代码后做回归测试。可行性考虑的是要用一些可行的方法做到关键的代码可测试，如通过边界条件、等价类划分、错误、因果、设计测试用例要覆盖常用的输入组合、边界条件和异常。

15：评测bug

Bug的 priority（）和severity（） 是两个重要属性，通常人员在提交bug的时候，只定义severity，而将priority交给leader定义，通常bug管理中，severity分为四个等级blocker、critical、major、minor/trivial，而priority分为五个等级immediate、urgent、high、normal、low

Severity：

• 1、blocker：即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误，如服务器500错误。
• 2、critical：即映像系统功能或操作，主要功能存在严重缺陷，但不会映像到系统稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
• 3、major：即界面、性能缺陷、兼容性，常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。
• 4、minor/trivial：即易用性及建议性问题。

Priority

1、immediate：即马上解决;
2、urgent：急需解决;
3、high：高度重视，有时间要马上解决;
4、low：在系统发布前解决，或确认可以不用解决。

bug的分级

• 崩溃：系统崩溃，不能运行，死循环，数据库死锁，资源分配不均，黑屏，闪退，阻塞；
• 严重：服务器可以用，但是不稳定，继续使用会产生严重的错误；
• 一般：系统可以稳定的运行，次要的功能没有实现，提示语不完善，弹出框没有关闭按钮，不影响用户使用；
• 建议（次要）：建议性的，提示信息重合（看不清楚），界面排版不符合用户的使用习惯，颜色不符合软件使用场景。

16：bug生命周期

bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

如果待验的BUG在验证时没有解决好，我们需要重新打开–指派—已解决—待验，循环这个过程。

中间其他状态：拒绝、延期等

• 1、New:（新的）

  当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

• 2、Assigned（已指派的）

  当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

• 3、Open（打开的）

  一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

• 4、Fixed（已修复的）

  当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

• 5、Pending Reset（待在测试的）

  当bug被返还到测试组后，我们将bug的状态设置为Pending Reset”

• 6、Reset(再测试)

  测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

• 7、Closed（已关闭的）

  如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”

• 8、Reopen（再次打开的）

  如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

• 9、Pending Reject（拒绝中）

  如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending
  Reject”

• 10、Rejected(被拒绝的)

  测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

• 11、Postponed（延期）

  有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“

17：web测试和app测试的不同点

• 系统架构方面： web项目，一般都是b/s架构，基于浏览器的 app项目，则是c/s的，必须要有客户端，用户需要安装客户端。 web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
• 性能方面: web页面主要会关注响应时间 而app则还需要关心流量、电量、CPU、GPU、Memory这些。它们服务端的性能没区别，都是一台服务器。
• 兼容方面： web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容 app测试则要看分辨率，屏幕尺寸，还要看设备系统。 web测试是基于浏览器的所以不必考虑安装卸载。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 。
• 此外APP还有一些专项测试：如网络、适配性。

18：怎么测试网络协议

协议测试包括四种类型的测试

• 一致性测试：检测协议实现本身与协议规范的符合程度；
• 互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力；
• 性能测试：检测协议实现的性能指标，比如数据传输速度、连接时间、执行速度、吞吐量、并发度；
• 健壮性测试：检测协议实现在各种恶劣环境下运行的能力，比如注入干扰报文、通信故障、信道被切断。

19：如何进行单元测试/h3>

①创建单元测试，该工具可以对任何类、接口、结构等实体中的字段、属性、构造函数、方法等进行单元测试。创建单元测试大致可以分为两类：整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项，这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法，开发人员直接在这些自动生成的测试方法中添加单元测试代码就行了。 单独测试：如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项，这样就可以单独为某个方法创建单元测试了。
②运行单元测试；
③查看测试结果
④编写单元测试代码

20：

• 坚持在软件的各个阶段实施技术评审保障措施，才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期；
• 软件修复的代价最高的阶段为：发布阶段；
• 可以作为软件测试对象的是：需求规格说明书、软件设计规格说明书、源程序；

21：POST请求的提交数据方式

• application/json
• application/x-www-form-urlencoded
• multipart/form-data
• text/xml

22：软件缺陷

• 软件没有实现产品规格说明所要求的功能；
• 软件中出现了产品规格说明书不应该出现的功能；
• 软件实现了产品规格没有提到的功能；
• 不属于软件缺陷：软件实现了产品规格说明所要求的功能但因受性能限制而为考虑可移植性问题。

23：自顶向下、自底向上

自顶向下测试：是从程序的初始模块开始测试。

（1）该方在早期发现顶层的错误。

（2）早期的程序框架可以进行演示

（3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。

（4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。

优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。

自底向上测试：是从程序的底层模块开始测试。

（1）I/O操作可以提前测试，更好提交测试用例。

（2）测试后比较容易观察输出。

（3）需要开发驱动模块。

（4）直到最后一个模块提交，程序才能完整的系统测试。

优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

24：条件、语句、条件组合、判定覆盖

• 条件覆盖：设计足够的测试用例，使得判定中的每一个条件获得各种可能的结果，每个条件至少一次为true，一次为false；
• 语句覆盖：选择足够的测试用例，使程序中的每条语句至少执行一次。所谓足够的指的是越少越好；
• 条件组合覆盖：在白盒测试法中，选择足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次；
• 判定覆盖：程序中每个判定至少有一次为真值，有一次为假值，使得程序中每个分支至少执行一次(满足判定覆盖的测试用例一定满足语句覆盖)
  判定覆盖

25：

测试工程师在软件测试计划阶段依据工作说明书制定指定测试进度；

工作说明书—SOW 制定测试的进度

概要设计说明书-HLD 设计测试的用例

详细设计说明书-LLD 程序员编码实现

单元测试用例-UTC 单元测试使用

26：黑盒、白盒测试常用方法

黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

27：强度、压力、负载、容量等测试概念

• 强度测试：为了确定系统在最差环境下的工作能力，在非标准工作环境下，不断人为降低系统工作所需要的资源，以测试系统在资源不足的情况下的工作状态。
• 压力测试：高负荷下的负载测试
• 负载测试：模拟实际软件系统所承受的系统负荷，通过模拟增加用户量，观察响应时间，数据吞吐量，CPU占用，发现系统存在的性能瓶颈、内存泄漏、不能实时同步等问题。
• 容量测试：是性能测试的一种，测试系统的最大容量，为系统扩容，为性能优化提供参考。
• 性能测试—疲劳强度测试 通过增加短时间的交易量，而缩短测试时间来达到既定的测试目标，尽可能在短时间内完成规定的所有交易量。

28：单元测试策略

单元测试的策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

29：需求规格说明说的检查项

• 是否描述了软件约束条件；
• 需求优先级分配是否合理；
• 是否描述了软件的目标环境、包括软硬件环境。
  
  

30：软件自动化测试的优点

• 速度快、效率高；
• 准确度好和精确度高；
• 能提高测试的质量

31：编写测试计划的目的

• 使测试工作顺利进行；
• 使项目参与人员沟通更舒畅；
• 是测试工作更加系统化

32：实施缺陷跟踪的目的

• 软件质量无法控制；
• 问题无法量化；
• 重复问题接连产生；
• 解决问题的知识无法保留。

33：使用软件测试工具的目的

• 帮助测试寻找问题；
• 协助问题的诊断；
• 节省测试时间。

34：其他测试工具

• 禅道： 它集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能，是中小型企业项目管理的首选。
  禅道
• junit： junit是一个基于Java语言的单元测试框架，一个回归测试框架，junit测试是程序员测试，即白盒测试。Junit是一套框架，集成TestCase类，就可以用Junit进行自动测试了。
• MeterSphere： 是一站式开源持续测试平台，涵盖测试跟踪、接口测试、性能测试、团队协作等功能、兼容Jmeter等开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量软件的交付。

35：

1：软件调试的目的 ：改正错误；
2：get请求会产生一个TCP数据包，post会产生两个TCP数据包；
3：软件质量管理（QM）应有质量保证（QA）和质量控制（QC）组成；
4：测试后程序中残存的错误数目与已发现的错误数目成正比；
5：一次成功的测试是指:在对某段程序进行经过合理设计并得到有效执行的测试过程中,发现了错误并且这些错误是可修复的。如果本次测试可以最终确定再无其他可查出的错误,同样也被称作是成功；
6：软件质量因素不包括高性能；
7：按照测试实施组织划分，软件测试可分为开发方测试（α测试）、用户测试（β测试）、第三方测试
软件测试分类
8：单元测试能发现约80%的软件缺陷；
9：与需求分析、设计、编码对应的软件测试阶段是系统测试、开发集成测试、单元测试；
10：ping是IP协议中连通测试工具；
11：单元测试主要针对模块的几个基本特征进行测试，不能完成的测试是系统功能；
12：文档测试不是易用性测试包括的内容；
13：测试管理工具的基本功能：用户及权限管理、测试项目的管理、测试项目需求管理、测试任务分配和实施；
14：系统测试关注的是项目或者产品范围中定义的整个系统或产品的行为；

来源：丢丢丢Dr.