程序为什么要单元测试

A. 单元测试到底是什么应该怎么做

单元测试一般是有开发人员或测试人员来做。谁来做并没有一个绝对的标准，要根据公司的实际情况来决定。

单元测试的实现方式包括：人工静态检查、动态执行跟踪。

人工静态检查：就是通常所说的“代码走读”，主要是保证代码逻辑的正确性。

动态执行跟踪：就是把程序代码运行起来，检查实际的运行结果和预期结果是否一致。

开发人员做单元测试：

优点：开发人员对代码最熟悉，而且开发人员编程技能相对比较强，所以开发人员自己写单元测试效率上和覆盖率上都比较高。

缺点：开发人员平时写业务代码就要花费很多时间，有时候确实没有时间写单元测试；而且大部分开发人员没有太好的测试思想，单元测试可能只是写个最简单的用例就完了；自己写的代码自己测，往往都是不靠谱。

测试人员做单元测试：

优点：测试人员有比较系统的测试思想，可以更好地保证用例的覆盖。而且通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也非常有利。

缺点：测试人员的编程技能相对比较弱，如果不同编程是无法开展单元测试的。并且测试人员对代码没有开发人员熟悉，效率会比较低。

B. 什么是单元测试意义是什么

单元测试是什么
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确，通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为
单元测试的好处
1，单元测试不芦悉汪但会使你的工作完成得更轻松。而且会令你的设计会变得更好，甚至大大减少你花在调试上面的时间 2，提高代码质量 3，减少bug，快陆亮速定位bug 4，放心地修改、重构
写单元测试要注意什么
1，不能只测试一条正确执行路径，要考虑到所有可能的情况
2，要确保所有测试都能够通过，避免间接损害
3，如果一个函数复杂到无法单测，那就说明模块的抽象有问题
4，配置不是单元测试的难点，难点是mock（后文讲），做单元测试需要伪造被测函数用到的大部分函数
为什么写单元测试
编写单元测试太花时间了？考虑下面问题：
1，对于所编写的代码，你在调试上面画了多少时间？
2，对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你画了多少时间在重新确认这些代码上面？
3，对于一个别人报告的bug，你花了多少时间才找出导致这个bug的源码位置？
对于那些没有使用单元测试的程序员陪仔而言，上面这些问题所耗费的时间的递增速度是很快的，而且随着项目深入，递增速度会变得更快；而另一方面，适当的单元测试却可以很大程度地减少这些时间，从而为你腾出足够的时间来编写所有的单元测试——甚至可能还有剩余的空闲时间。

C. 为什么需要做单元黑盒测试

有了戚拿亮单元高宽测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。敏此
单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。

D. 软件开发里面单元测试是用来做什么的

单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字兄孙符了。

执行单元测试，是为了证明某段代码的行为确实和开发者所期望梁塌的一致。

为什么需要单元测试?

当编写项目的时刻，如果我们假设底层的代码是正确无误的，那么先是高层代码中使用了底层代码;然后这些高层代码又被更高层的代码所使用，如此往复。当基本的底层代码不再可靠时，那么必需的改动就无法只局限在底层。虽然你可以修正底层的问题，但是这些对底层代码的修改必然会影响到高层代码。于是，一个对底层代码的修正，可能会导致对几乎所有代码橡尘圆的一连串改动，从而使修改越来越多，也越来越复杂。从而使整个项目也以失败告终。

单元测试针对程序模块，进行正确性检验的测试。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

E. 单元测试的意义

单元测试由一组独立的测试构成，每个测试针对软件中的一个单独的程序单元。如果对单元测试的内容不清楚的同学，昌平镇电脑培训建议可以参考这篇文章，详细讲解单元测试的内容。

对于单元测试，人们往往存在很多的误解：

1)浪费的时间太多

一旦编码完成，缺乏软件工程实践经验的开发人员就会迫不及待地进行软件集成工作，这样就能看到实际系统开始启动工作，在这种开发步骤中，真正意义上的进步被表面上的进步所取代。系统能进行正常工作的可能性很小，更多的情况是充满了各式各样的Bug。这些Bug包含在独立的单元里，其本身也许是琐碎、微不足道的，但在软件集成为一个系统时会增加额外的工期和费用。

其实进行完整的单元测试和编写代码所花费的精力大致上是相同的，一旦完成了单元测试，在确保手头拥有稳定可靠部件的情况下，再进行高效的软件集成才是真正意义上的进步。

程序的可靠性对软件产品的质量有很大的影响，在大型软件公司，每写一行程序，都可能要测试很多遍。由此可见大型软件公司对测试的重视程度。

2)软件开发人员不应参与单元测试

单元测试常常和编码同步进行，每完成一个模块就应进行单元测试。在对每个模块进行单元测试时，不能忽略和其他模块的关系，为模拟这一关系，需要辅助模块，因此若单独的测试人员喊念迹进行单元测试，往往工作量大，周期长，耗费巨大，其结果事倍功半。软件的开发者总是应当负责高尺程序的单个单元的测试，保证每个单元能够完成设计的功能，其实在很多情况下，开发者也应进行集成测试。

3)我是很棒的程序员，不需要进行单元测试

如果我们真正擅长编程并且有绝招，就应当不会有错误，但这只是一个神话。编码不是可以一次性通过的，必须经过各种各样的测试，单元测试只是其中一种。缺乏测试的程序代码可能包含许多Bug，程序员在没有测试保护的情况下修改Bug，会引发更多的Bug，忙于除虫，于是更没有时间测试。如此循环往往会导致项目的崩溃。为避免产生恶性循环，代码必须有一张安全网来保护，随郑并时进行的单元测试就是这张安全网。

4)不管怎样，集成测试将会抓住所有的Bug

集成测试的目标是把通过单元测试的模块拿来，构造一个在设计中所描述的程序结构，通过测试发现和接口有关的问题。我们在测试工作开展的过程中，发现并提交进行合格性测试的软件，在测试过程中有很多Bug，有些严重问题，甚至导致死机，以至于不能再测试其他功能，进行错误修改，回归测试时又发现其他新的问题，使得测试工作很难开展下去。

F. 为什么要做测试

1、测试是做什么的?
如果是专业的测试人员的话，那软件测试的工作就相当复杂了，首先制定测试计划是势在必行的，包括测试的起始结束时间，在什么时间要有什么进度，之后就是进行各个测试环节，单元测试——集成测试——系统测试——验收测试。这里边前两步是用到白盒测试，后两步需要的是黑盒测试。
如果是找测试方面的工作的话，那一开始我相信问得不会很深，但是基础肯定是要知道的，就是什么是黑白盒测试，建议测试文档包含的必须部分等等吧，都是很基础的。
2、软件测试类型都有哪些?测试类型的区别与联系?
测试类型有：功能测试，性能测试，界面测试。
功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范(快捷键之类的)，是否美观(能否吸引用户的注意力)，是否安全(尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)?做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试。
3、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系?
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1)是否有不正确或遗漏的功能?
2)在接口上，输入是否能正确的接受?能否输出正确的结果?
3)是否有数据结构错误或外部信息(例如数据文件)访问错误?
4)性能上是否能够满足要求?
5)是否有初始化或终止性错误?
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1)对程序模块的所有独立的执行路径至少测试一遍。
2)对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3)在循环的边界和运行的界限内执行循环体。
4)测试内部数据结构的有效性，等等。
单元测试(模块测试)是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。
集成测试(也叫组装测试，联合测试)是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
4、做好测试用例设计工作的关键是什么?
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果;
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。
5、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)。
6、做好测试计划工作的关键是什么?
1)明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确。
2)坚持“5W”规则，明确内容与过程
“5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的(Why)，明确测试的范围和内容(What)，确定测试的开始和结束日期(When)，指出测试的方法和工具(How)，给出测试文档和软件的存放位置(Where)。
3)采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4)分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。