23.1 测试基础23.2 软件测试技术23.3 信息系统测试管理 23.1 测试基础
1、软件测试模型
V模型特点：
存在一定的局限性，它将测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，这样会导致需求分析或系统设计阶段隐藏的问题一直到后期的验收测试时才被发现，当在最后测试中发现这些需求错误时，可能已经很难再更改程序的逻辑结构去修正问题，从而导致项目的失败。
等到软件编码完成后才开始软件测试工作，那么必须在代码完成后给测试工作预留足够的时间，否则将导致测试不充分。
失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，导致测试人员很难跨过这些边界来采集测试所需要的信息。
优点：将复杂的测试工作按阶段划分为各个小阶段来实现从多角度测试系统找出更多的缺陷。
缺点：软件测试容易误导为软件开发的最后一个阶段需求、设计阶段产生的问题不能很早发现质量控制和测试效率无高效发挥。
W模型特点：
由于V模型在软件开发编码完成后才介入测试工作，导致一些在需求和设计中的问题在后期验收测试中才被发现，这样不能体现“尽早地和不断地进行软件测试”的原则，由此演化成一种W模型。
增加了软件各开发阶段中同步进行的验证和确认测试活动。
由两个V字模型组成，分别代表测试与开发过程，表示出了测试与开发的并行关系
相当于两个V模型的叠加，一个是开发的V，一个是测试的V
由于在项目中开发和测试是同步进行，相当于两个V是并列、同步进行的。
优点：
测试和开发同步进行，有利尽早发现问题
增加非程序角度测试系统的思想
测试准备及设计工作提前，提高测试质量及效率
缺点：
把软件开发视为求、设计、编码等一系列串行的活动
开发和测试保持一种线性的前后关系
无法支持迭代、自发性以及变更调整
H模型特点：
在V模型和W模型中都存在一定的局限性，他们都把软件的开发过程视为需求、设计、编码等一系列串行的活动，但实际上，这些串行的活动之间存在着相互牵制的关系。
H模型将测试活动完全独立岀来，形成一个完整独立的流程。
仅仅演示了在整个生存周期中某个层次上的一次“测试循环”。
其他流程可以是任意开发流程，主要测试条件成熟了。
测试准备活动完成了，测试执行活动就可以进行。
原理：软件测试是一个独立的流程，贯穿于整个软件产品的周期，与其他流程并发进行。
优点：
将测试从开发中独立出来，利于研究更深的测试技术。
同时测试多个项目时，可对测试技术重复利用。
高效调整测试人员
缺陷修复时不受项目组内部人员限制。
缺点：
独立的测试组对系统认识不够深入。
影响测试质量及测试效率。
X模型特点：
无法引导项目的全部过程。
是对V模型的改进，提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成为可执行的程序。
左边描述的是针对单独程序片段进行的相互分离的编码和测试。
还定位了探索性测试，这是不进行实现计划的特殊类型的测试。
优点：
强训单元测试及集成测试的重要性。
引人探索性测试使测试模型与现实更接近。
缺陷修复时不受項目组内部人员限制。
缺点：
只强测试过程中的部分内容。
没有对需求测试验收测试等内容进行说明。
前置测试模型特点：
将测试和开发紧密结合，提供了一种轻松的方式，可以使项目加快速度。
将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。
并在开发阶段以“编码-测试-编码-测试”的方式来体现。当程序片段一旦编写完成，就会立即进行测试。
先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。
与V模型不同的是，前置测试模型认识到验收测试中所包含的3个要求：基于测试的需求、验收标准和验收测试计划，其中基于测试的需求和验收标准都与业务需求定义相联系，但是，验收测试计划则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成的。
用较低的成本来急早发现错误。
并且充分强调了测试对确保系统的高质量的重要意义。
反复使用了各种测试技术以及开发人员、经理和用户节省其时间，简化其工作。
2、测试类型分类
①单元测试：又称模块测试，是针对软件设计的最小单元（程序模块）进行正确性检验的工作。
②集成测试：又称组装测试、联合测试、子系统测试或部件测试。在单元测试的基础上将所有模块按照设计要求组装成子系统或系统进行的测试。
③系统测试：对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。
④验收测试：在软件产品完成了功能测试和系统测试之后、产品发布之前进行的软件测试活动是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。
3、按执行方式分类
①静态测试
不运行程序，通过人工对程序和文档进行分析与检查；
对软件中的需求说明书、设计说明书、程序源代码、用户手册等进行非运行的检查；
组成：代码检查、静态结构分析、代码。
②动态测试
通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现；
通过运行被测程序，检査运行结果与预期结果的差异，并分析运行效率结果与预期结果的差异，并分析运行效率和健壮性等性能；
组成：编写测试用例，执行程序，分析程序的输出结果。
4、开发测试：也叫“验证测试”或“α测试”
①：Alpha测试
是由一个用户在开发环境下进行的测试
并在在开发者对用户的“指导”下进行测试
不能由程序员或测试员完成
②Beta测试
一种“用户测试”
软件的最终用户们在一个或多个客户场所进行
开发者通常不在Beta测试的现场
不能由程序员或测试员完成
是在开发者无法控制的环境下进行的软件现场应用
③三个阶段
α是第一阶段，一般只供内部测试使用；
β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用
λ是第三个阶段，此时产品已经相当成熟只需在个别地方再做进一步的优化处理即可上市发行
5、用户测试
在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期；
不是指用户的“验收测试”，而是指用户的使用性测试。
6、第三方测试
也称为独立测试，是介于软件开发方和用户方之间的测试组织的测试。
有别于开发人员或用户进行的测试，其目的是为了保证测试工作的客观性。
还可以适当兼顾初级监理的功能。
以合同的形式制约了测试方，使得它与开发方存在某种“对立”的关系，所以它不会刻意维护开发方的利益，保证了测试工作在一开始就具有客观性。
不同于开发方的自测试，也不同于用户的自测试。
1、黑盒测试
功能测试，它是通过测试来检测每个功能是否都能正常使用。
把程序看做一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输岀信息。
着眼于程序外部结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测试只有采用穷举输入测试，才能查出程序中所有的错误。
用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法、正交试验设计法、功能图法、场景分析法等。
2、白盒测试
结构测试，可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结枃和处理过程，检查是否所有的结构及路径都是正确的，检査软件内部动作是否按照设计说明书的规定正常进行。
目的是通过检查软件内部的逻辑结构，对软件中逻辑路径进行覆盖的测试，可以覆盖全部代码、分支、路径和条件。
3、灰盒测试
介于白盒测试与黑盒测试之间的测试
关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试详细、完整，只是通过一些表征的现象、事件、标志来判断内部的运行状态。
是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
缺点：
①投入的时间比黑盒测试大概多20%~40%的时间；
②对测试人员的要求比黑盒测试高；
③不如白盒测试深入；
④不适用于简单的系统。
三种测试技术的区别：
用白盒测试验证单元的基本功能，用黑盒测试的思考方法设计测试用例；
黑盒测试中使用白盒测试的手段，常称为灰盒测试；
白盒测试需要对程序的内部实现十分熟悉，黑盒测试是完全基于对系统需求的了解；
仅仅使用白盒测试或者仅仅使用黑盒测试都不能系统的全面测试一个软件。
按测试对象分类
4、性能测试
①负载测试：又叫强度测试，是通过逐步增加系统负载，测试系统性能的变化并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
②压力测试：对系统逐渐增加压力的测试，来获得系统能提供的最大的服务级别的测试或者不能接收用户请求的性能点。
③压力测试：
并发测试：当测试多用户井发访问同一个应用、模块、数据时是否产生隐藏的并发问题如内存泄露、线程锁、资源争用等问题，几乎所有的性能测试都会涉及。
大数据量测试：
独立的数据量测试：针对某些系统存储、传输、统计、查询等业务进行的大数据量测试；
综合数据量测试：和压力性能测试、负载性能测试、稳定性性能测试相结合的综合测试。
④稳定性测试：
疲劳强度测试。
应用系统稳定运行情况下的并发用户数，或者日常运行用户数，持续运行较长一段时间，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理最大工作量强度性能过程。
⑤稳定性测试：
概率性的测试，即使稳定性测试通过，也不能保证系统实际运行的时候不出问题所以要尽可能提高测试的可靠性。
可以通过多次测试，延长测试时间，增加测试压力来提高测试的可靠性。
5、按质量属性划分
①容错性测试：检查软件在异常条件下自身是否具有防护性的措施或灾难恢复的手段。
②兼容性测试：
检查软件在不同平台、不同环境下能否友好地运行
软件兼容性（操作系统、浏览器、分辨率、数据库、软硬配合）
硬件兼容性（与整机兼容、与板卡及外设兼容）
数据兼容性（不同版本间、不同软件间）
③安全性测试：检验产品是否符合安全需求定义和产品质量标准。
④可靠性测试：在预期的使用环境中，由代表用户对软件进行面向故障的测试，来评估是否达到可靠性需求。
⑤可用性测试：评估设计方案或者产品的可用性水平。不能证明产品有多好、会有多少人喜欢。
⑥维护性测试：衡量对已经完成的软件进行调整需要多大的努力。通常包括：纠正性维护、适应性维护、预防性维护、完善性维护。
⑦可移植性测试：检验不经修改，应用程序或者系统从一种环境移植到另一种环境中还能正常工作的难易程度。
⑧易用性测试：评定软件的易学易用、各功能是否易于完成、软件界面是否友好等。
1、定义：为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动。
2、主要因素：策略制定、进度跟进、风险评估、文档评审、内外部协调、人员培养。
3、内容
测试部门管理：部门日常事务、部门人员、部门下属项目、部门资产等的跟踪及管理工作。
测试项目管理：测试人员管理、测试计划及测试策略的编写、测试评审的组织、测试过程的跟进测试内部和外部的沟通协调、缺陷跟踪。
4、测试监控，目的是为测试活动提供反馈信息和可视性，主要内容有：
①测试用例执行的进度
②缺陷的存活时间
③缺陷的趋势分析
④缺陷分布密度
⑤缺陷修改质量
5、配置管理：测试过程中的配置管理不仅包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本。
6、测试风险管理：
①需求风险：对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或执行了错误的测试方式。
②测试用例风险：测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求。
③缺陷风险：某些缺陷偶发，难以重现，容易被遗漏。
④代码质量风险：软件代码质量差，导致缺陷较多，容易岀现测试的遗漏。
⑤测试环境风险：有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差。
⑥测试技术风险：某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。
⑦回归测试风险：一般不运行全部测试用例，可能存在测试不完全。
⑧沟通协调风险：测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作难免存在误解、沟通不畅的情况，导致项目延期。