标签：正交 服务器端 如何 持久 测试方法 基础 瀑布模型 怎么 ref
1、什么是软件测试？
软件、网站或系统等在没有发布到用户手中之前先保证它能够
满足的一切需求，能够正常使用，保证产品到用户手中的一个质量安全保证问题。从功能、性能、安全、从各个接口、逻辑方面解决它，从不同的角度去解决这个产品到用户
手中出现的各种问题。使用人工或者自动手段来提高软件的安全和质量以及性能以及其他的一些问题，保证它的质量，保证用户体验。测试人员发现问题、跟进问题解决的过程，其目的在于检测它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
2、软件测试的法则：
（功能、可靠性、易用性、效率、可维护性、可移植性）
3、玻璃杯的测试：
功能：装水、牛奶等装载功能
可靠性：隔热功能、会不会散发有毒气体，装热水冷水到多少度会炸
易用性：有没有盖、杯子的重量、杯子的口径
效率：反复装水倒水的使用寿命
可维护性：盖坏了能不能换
可移植性：使用的范围、在什么场合适用等。
4、简述一下缺陷的生命周期：
缺陷的生命周期指的是缺陷从被发现到被解决验证的完整过程。
一个缺陷的正常生命周期是新建（提交）--打开（确认）--修复
---测试验证--通过关闭。没有通过就重新打开。
5、设有一个档案管理系统，要求用户输入以年月表示的日期，假设
日期限定在1990年1月~~2049年12月，并规定有6位数字字符组成，
钱4位表示年，后2位表示月，先用等价类、边界值法设计测试用例，
来测试程序的”日期检查功能“
代码：public static boolean CheckDateValidness(String date){
int len=date.length();//字符串长度
if(len!=6)
return false;
int i=Integer.parseInt(date);//字符串转化为整型数字
int year=i/100;
int month=i%100;//前四位是年 后两位是月
if(year<1990||year>2049)
return false;
if(month<1||month>12)
return false;
return true;
6、软件测试的原则：
6.1 所有的软件测试都应追溯到用户需求；
6.2 应当把“尽早的和不断的进行软件测试”作为软件测试的座右铭；
6.3 完全测试是不可能的，测试需要终止；
6.4 测试无法显示系统所有潜在的缺陷；
6.5 软件开发人员应当避免测试自己的程序，应由测试人员来完成测试工作；
6.6 设计测试用例时，应该考虑各种情况；
6.7 对测试出的错误结果一定要有一个确认的过程；
6.8 严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作；
6.9 妥善保管测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之
用；
6.10 Pareto原则，测试发现的错误中80%很可能起源于20%的模块中；
软件测试的七大原则--------------摘自CSDN博客
原则1: 测试显示缺陷的存在
测试可以显示缺陷的存在，但不能证明系统不存在缺陷。测试可以减少软件中 存在缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的，或者说是不存在缺陷的。
原则2: 穷尽测试是不可能的
穷尽测试是不可能的，当满足一定的测试出口准则时测试就应当终止。考虑到所有可能输入值和它们的组合，以及结合所有不同的测试前置条件，这是一个天文数字，我们没有可能进行穷尽测试。
原则3: 测试的尽早介入
根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。此外，IBM的一份研究结果表明，缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量降低软件开发成本。
原则4：缺陷集群性
Pareto原则表明“80%的错误集中在20%的程序模块中”。实际经验也证明了这一点，通常情况下，大多数的缺陷只是存在测试对象的极小部分。缺陷并不是平均而是集群分布的。因此，如果在一个地方发现了很多缺陷，那么通常在这个模块中可以发现更多的缺陷。因此，测试过程中要充分注意错误集群现象，对发现错误较多的程序段或者软件模块，应进行反复的深入的测试。
原则5: 杀虫剂悖论
论杀虫剂用得多了，害虫就有免疫力，杀虫剂就发挥不了效力。在测试中，同样的测试用例被一遍一遍反复使用时，发现缺陷的能力就会越来越差。这种现象的主要原因在于测试人员没有及时更新测试用例，同时对测试用例及测试对象过于熟悉，形成思维定势。
为克服这种现象，测试用例需要经常的评审和修改，不断增加新的不同的测试用例来测试软件或系统的不同部分，保证测试用例永远是最新的，即包含着最后一次程序代码或说明文档的更新信息。
原则6: 测试活动依赖于测试背景
对于每个软件系统，比如测试策略测试技术、测试工具、测试阶段以及测试出口准则等等的选择，都是不一样的。同时，测试活动必须与应用程序的运行环境和使用中可能存在的风险相关联。因此，没有两个系统可以以完全相同的方式进行测试。比如，对关注安全的电子商务系统进行测试，与一般的商业软件测试的重点是不一样的，它更多关注的是安全测试和性能测试。
原则7: 不存在缺陷的谬论
系统的质量特征不仅仅是功能性要求，还包括了很多其它方面的要求比如稳定性、可用性、兼容性等等。假如系统无法使用，或者系统不能完成客户的需求和期望，那么，这个系统的研发是失败。同时在系统中发现和修改缺陷也是没有任何意义的。
7、软件测试对象：
软件测试不等于程序测试，软件测试贯穿软件定义和开发的整个期间。需求分析、概要
设计、详细设计、以及程序编码等各个阶段所得到的文档，包括需求规格说明、概要设
计规格说明、详细设计规格说明、以及源程序，都是软件测试的对象。
8、软件测试的分类：
8.1 按测试方式分类：
8.1.1 静态测试：不需要执行所测试的程序，仅通过分析或检查源程序的语法、结构、
过程、接口来检查程序的正确性。
8.1.2 动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。
8.2 按测试方法分类：
8.2.1 白盒测试：结构测试，基于代码的测试或基于设计的测试。（已知产品的详细
设计过程，可以通过测试证明每种内部操作是否符合设计规格的需求，所有的
内部成分是否已经通过。）------测试源代码，主要在系统内部结构中测试。
8.2.2 黑盒测试：行为测试，功能测试或基于需求的测试，基于系统应该完成的功能
进行测试。（已知产品的用户需求规格，可以通过测试证明整个软件系统是否
符合用户的最终需求。）-----主要在应用端和服务器端，不用接触系统内部结构。
8.2.3 灰盒测试：已知产品的接口文档，可以通过接口来验证软件给服务器发送的各
项请求和返回值的正确性，可以脱离可视化界面进行测试，大大提高工作效率。
--------结合以上两种情况
8.3 按测试过程分类：单元测试、集成测试、系统测试、验收测试
9、软件测试的目的：
9.1 测试是为了发现系统中的错误而执行程序的过程；
9.2 好的测试方案在于尽可能发现迄今为止尚未发现的错误；
9.3 成功的测试是发现了至今为止尚未发现的错误的测试；
9.4 测试并不仅仅是为了找出错误，通过分析错误产生的原因和测物发生的趋势，可以
帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进；
9.5 这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；
9.6 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
10、软件测试阶段：
按照开发阶段划分：单元测试、集成测试、系统测试、验收测试
10.1 单元测试：对源代码实现的每个单元程序进行测试，检查各个程序模块是否正确
的实现了规定的功能。
10.2 集成测试：在单元测试的基础上，把已经测试完的模块组装起来进程测试，验证
组装后功能以及模块间接口是否正确，主要对与设计相关的软件体系结
构的构造进行测试。
10.3 系统测试：将已经集成好的软件系统，与计算机硬件、外设、数据库和操作人员
等其他元素组合在一起，在实际运行环境下，对计算机系统进行一系
列测试工作。
10.4 验收测试：用户根据合同、《需求规格说明书》或《验收测试计划》对产品进行的
验收测试，以确定系统是否满足验收标准，分为 alpha测试和beta测
试。
alpha测试：用户在开发环境下的测试（内测）；
beta测试：多用户在实际环境中的测试（公测）。
11、黑盒测试的测试策略
11.1 UI测试：用户界面测试；如图片像素、页面布局、CSS样式等；
11.2 配置测试：测试系统服务器以及测试机的配置是否满足产品以及测试需求；
11.3 表单值域测试：测试表单输入的等价类、边界值、正交法；
11.4 数据完整性测试：测试系统的数据库数据是否异常，push、pull是否正确，是否存
在遗漏的数据表；
11.5 逻辑测试：测试软件业务逻辑是否正确；
11.6 业务流程测试：测试软件前后台的业务流程，每个分支和功能点是否可跑通；
11.7 逆向思维测试：测试软件在非正常操作下的处理事务的能力；
11.8 接口测试：测试软件内部接口以及外部接口返回值是否正确，提示语是否正确并
且友好；
11.9 本地化测试：测试系统在外界环境下是否能够满足用户需求，例如翻译是否正确；
11.10 回归测试：在项目上线并且进行更新修改后，需要进行回归测试，确认之前没有
问题的模块依然正确；
11.11 冒烟测试：用于集成测试之后的测试方法，确认软件是否满足系统测试要求；
11.12 cookie测试：测试软件缓存是否正确，清理后的表现等；
11.13 功能测试：就是对产品的各功能进行验证，根据功能测试用例，依次测试，检查
产品是否达到用户要求；
11.14 自动化测试：属于功能测试范围，一般用于回归测试，减少很大工作量；
11.15 性能测试：测试软件在各种状况下的性能，如吞吐量、响应时间、CPU占用率、
内存占用率等；
11.16 易用性测试：测试软件是否易用，主观性比较强，一般根据很多用户的测试反馈
信息，才能评价易用性；
11.17 故障转移和恢复测试：测试服务器挂掉以后，是否有备用服务器能够继续支撑压
力和请求；
11.18 错误推断测试：当发现一个BUG后，通过经验和直觉推测出可能因为此BUG而
引发的其他问题；
11.19 安全性测试：测试该系统防止非法侵入的能力；
11.20 兼容性测试：测试该系统与其他软件硬件兼容的能力；
11.21 比较测试：通过与同类产品比较，考察该系统的优缺点；
11.22 Alpha测试：一种先期的验收测试，此时系统刚刚开发完成；
11.23 Beta测试：一种后期的验收测试，此时系统已经通过内部测试，大部分错误已经
改正；
11.24 随机测试：在系统内进行随机的页面或流程测试（一般由运维和开发进行抽测）。
12、集成的方法和测试策略
集成方法：自顶向下集成、自底向上集成
驱动模块：被测模块的上层模块
存根模块：被测模块的下层模块
自顶向上集成的策略：深度优先策略，广度优先策略
13、性能测试包括哪几方面？
12.1 压力测试：最大并发值（一瞬间能够承受的压力）
12.2 负载量测试：响应时间 （最大能够承载的人数）
12.3 稳定性测试：内存占用、CPU占用率、吞吐量---服务器每秒处理的字节数 （持久
性）。
14、什么是测试用例？
测试用例时一份测试文档，它描述输入、动作和一个期望的结果，目的是确定应用程序
的某个特性是否正常的工作。（通俗的讲测试用例就是解决要测什么，怎么测和如何衡
的问题）。
14.1、测试用例的编写规范：
分为3大类：1、基本信息；2、主体信息；3、执行结果
基本信息：功能模块、编写人、编写时间；
主体信息：编号、测试对象、测试点、预置条件、测试步骤、测试数据、预期结果、用例优先级（高中低）；
执行结果：执行通过/不通过/未执行/无法执行、执行时间、缺陷报告。
14.2、 编写测试用例的原则：100%覆盖需求！！！
14.3、设计测试用例的方法：
14.3.1、大纲法：拆分系统模块；
14.3.2、等价类：用来找到所有的正例和反例，正确范围内测试内容（手动输入框、或、非此即彼、“顿号”---能同时存在）；
14.3.3、边界值：是对功能、值域方面的测试；
14.3.4、因果图：是针对有组合功能进行设计用例，得出决策表，每一列是一个测试用例；
14.3.5、场景法：基于系统流程的测试；
14.3.6、错误推断法：使用特殊的测试方法进行测试；
14.3.7、正交法：组合过多，用因果图不易看清的情况下。
14.4、测试用例的准则：
14.4.1、至少覆盖所有状态一次；
14.4.2、至少覆盖所有事件一次；
14.4.3、至少覆盖所有路径一次。
14.5、测试用例的优先级：
高：用户经常执行的动作及业务逻辑操作，必须保证功能性是稳定的，以及重要的接口和涉及金钱交易的用例；
中：区域的功能用例变得更详细，用例多数方面包括等价类、边界值、逆向思维等测试用例；
低：此用例通常是最少被用户执行的动作；
15、软件测试的流程：
大公司流程：1、拿到需求文档；
2、需求评审（完备性、逻辑性、二义性、可行性、看需求是否合理）；
3、编写测试计划；
4、测试计划评审；
5、编写测试用例；
6、用例评审；
7、拿到接口文档；
8、接口测试；
9、执行冒烟测试；
10、系统测试--执行测试用例--迭代测试；
11、每次迭代都需要提交一份阶段性测试报告（做完确认测试后写）
12、发布上线前进行性能测试；
13、提交总结性测试报告--发布上线--进入beta测试阶段；
16、软件的生命周期模型
16.1、瀑布模型：
过程：计划---需求分析---设计---编码---测试---运行维护
特点：不能跳跃的修改；开发周期短（多为外包项目）
16.2、V模型：
过程：测试开发完毕之后再进行的一种测试，从单元测试开始逐步往系统迈进。 需求分析--概要设计--详细设计--软件编码--单元测试--集成测试--系统测试--验收测试；
优点 ：明确地标明了测试过程中存在的不同级别，清楚的描述了测试阶段和开发过程期间各阶段的对应关系；
那么我们可以分析出：单元测试和集成测试对应于详细设计和概要设计，那么在单元测试和集成测试中我们就需要检测程序的执行是否满足软件设计的要求。系统测试对应于需求分析和系统分析，在系统测试过程中我们就需要检测系统的功能，性能，质量上是否满足系统要求的指标。验收测试对应于用户需求阶段，在验收测试中我们就需要确定软件的实现是否已经满足用户的需求。但也不难看出，在V模型中，只是把测试作为编码之后的一个阶段，并没有在需求开发阶段就进入测试。这也算是他的一个缺点了。
缺点：当编码完成后进入测试阶段，这时候发现的一些BUG可能不容易找到其根源，并且代码修改起来会很困难；在实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大；
解决思路：当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序中错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求；
V模型适合的场所：一般适用于一些传统的信息系统应用的开发，而一些高性能高风险的系统、互联网软件或一个系统难以被具体模块化的时候，就比较难做成V模型所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型；
16.3、W模型：
过程：由图可以看出，W模型中开发和测试是同时进行的；
优点：测试与开发并行，让测试更早的介入开发环节，尽早的发现软件缺陷，降低软件开发的成本。
缺点： 在W模型中，需求、设计、编码等活动被视为串行的，开发未完成之前无法进入测试阶段，不支持敏捷模式的开发；
16.4、H模型（敏捷模型）
优点：H模型将测试活动完全独立出来，形成一个完全独立的流程，贯穿于整个产品的生命周期，与其他流程并发的进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段：全检测试可以尽快尽早的进行；软件测试可以根据被测物的不同而分层次进行；
缺点：需要有完整的测试团队；
标签：正交 服务器端 如何 持久 测试方法 基础 瀑布模型 怎么 ref
原文地址：https://www.cnblogs.com/springamy/p/10987885.html
