测试的理论，还有测试驱动开发是怎么用的，为什么要用测试驱动开发、linux和数据库、计算机网络（可刷牛客网来提升）。

单元测试->集成测试->确认测试->系统测试->验收测试

（1）单元测试：
单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。Junit 测试是程序员测试，即所谓 白盒测试 ，因为程序员知道被测试的软件如何（ How ）完成功能和完成什么样（ What ）的功能。 Junit 是一套框架，继承TestCase 类，就可以用 Junit 进行自动测试了。
工件是加工过程中的生产对象。
（2）集成测试
又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
（3）确认测试
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
（4）系统测试
软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，
目的在于与系统需求比较，发现问题
（5）验收测试
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

Alpha测试在Beta测试之前，由一个用户在开发环境下进行的测试，也叫做验证测试。

alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境进行的受控测试，不能由程序员或测试员完成。Alpha测试可以从软件产品编码结束之后开始，或在模块(子系统)测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

Beta测试：软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

区别：A测试是一个用户，可以是内部人员也可以是用户，开发人员在场，测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。

B测试是多个用户在一个或多个实际使用环境下进行，完全是用户，开发人员不在场。着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。

针对手机应用软件的系统测试，我们通常从如下几个角度开展：功能模块测试，交叉事件测试，压力测试，容量测试，兼容性测试，易用性/用户体验测试等.

对手机可以施加的压力测试类型主要有：存储压力、边界压力、响应能力压力、网络流量压力

设计测试用例时，应注意测试用例的代表性、测试结果的可判定性和可重现性。

1、测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。

2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

什么是静态测试?

答:通过运行程序测试软件称为动态测试.通过评审文档、阅读代码等方式测试软件称为静态测试,在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.

静态测试方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

什么是白盒测试?

答:白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。

白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖

1.语句覆盖：可执行语句至少被执行一次；
2.判断覆盖：每个判断的取真分支和取假分支至少经历一次；
3.条件覆盖：每个条件的取值至少满足一次；

4.路径测试：执行所有可能的执行路径；
5.条件组合覆盖：每个条件的所有可能都至少出现一次，并且判定结果至少出现一次 ；

6.判断/条件覆盖：判断和条件都满足；
与条件覆盖的区别：他不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次；
7.基本路径测试：路径测试执行了每个路径，每个判定的结果肯定经历过一次

黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、决策表和综合策略。

设计系统测试计划需要参考的项目文挡有：软件测试计划、软件需求规范、迭代计划

系统测试有负载测试、易用性测试、强度测试、安全测试。

(1)负载测试：数据在超负荷环境中运行，看程序是否能承担。目的是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
(2)强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
(3)容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

单元测试能发现约80%的软件缺陷。

逻辑测试覆盖中，测试覆盖最强的是条件组合覆盖。

测试方法可以分成个人复查、抽查和会审、黑盒测试、白盒测试。

软件测试的原则之一是测试应该尽早进行，最好在需求阶段就开始介入。

测试驱动开发(Test-DrivenDevelopment)是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD得原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于敏感词开发方法和过程。TDD得基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能的产品。

缺点：增加代码量。测试代码是系统代码的两倍或更多。

什么是驱动模块？

答:驱动模块在大多数场合称为”主程序”，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此写驱动
驱动模块主要完成以下事情：
1、接受测试输入;
2、对输入进行判断;
3、将输入传给被测单元，驱动被测单元执行;
4、接受被测单元执行结果，并对结果进行判断;
5、将判断结果作为用例执行结果输出测试报告。

什么是桩模块?

答:比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

需求文档测试：测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

设计文档测试: 测试设计是否符合全部需求以及设计是否合理。

测试工具：

loadrunner 包括脚本编辑工具、测试执行工具、结果分析工具

性能测试：主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。

目的是通过测试，确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，并对系统进行优化。

压力测试：模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行，以此来获得系统性能提供的最大服务级别的一种测试。

负载测试：通过逐步增加系统工作量，测试系统能力的变化，并最终确定在满足功能指标的情况下，系统所能承受的最大工作量的测试。压力测试实质上就是一种特定类型的负载测试。

自动化测试和手工测试的适用场景：

自动化测试适用场景：

1.产品需求变更较少。

2.项目开发周期较长。

3.测试用例执行频繁。比如大量的回归测试工作

4.手工测试无法胜任。比如高并发操作，持续收集设备资源，长时间稳定性测试，多用户操作等手工操作或测试无法胜任的工作。

5.人物财力资源充足。

手工测试适用场景：

1.产品需求变更较多。

2.项目开发周期较短，需要迅速交付。

3.测试用例执行不是很频繁，需要人为观察，需要灵活测试。

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

自动化测试的优点：

1、对回归测试更方便：周期较长的回归测试工作量大，测试比较频繁，适合自动化测试。由于测试的脚本和用例都是设计好的，测试期望的结果也可以预料，将回归测试自动化可以极大的提高效率缩短回归时间。
2、模拟真实情况：可以执行手工测试无法执行的测试，比如同时并发上千用户测试系统的负载量，测试人员无法达到测试目的，而使用自动化测试工具可以模拟多用户的并发过程。
3、有效的利用人力物力资源：频繁地机器化的动作可以用自动化测试执行，减少错误的发生，更好的利用人力资源。
4、测试的重复利用：由于自动测试通常使用的是自动化脚本技术，这样就可以只需要做较少的甚至是不修改就可以实现在不同的测试过程中使用相同的用例。
5、减少人为的错误：自动化测试是机器完成，不存在执行过程中人为的疏忽和错误。

自动化测试的缺点：

1、自动化测试是工具执行，没有思维，无法进行主观判断，对界面色彩、布局和系统的奔溃现象无法发现，这些错误通过人眼很容易发现。
2、自动化测试工具本身是一个产品，在不同的系统平台或硬件平台可能会受影响，在运行时可能影响被测程序的测试结果。
3、对于需求更改频繁的软件，测试脚本的维护和设计比较空难。
4、自动化测试是机器执行，手工测试比自动测试发现的缺陷更多。
5、自动化测试要编写测试脚本，设计场景，这些对测试人员的要求比较高，测试的设计直接影响测试的结果。

综上所述，可以归结自动化完成不了的，手工测试都能弥补，两者有效的结合是测试质量保证的关键。