软件测试基础

软件测试行业介绍

 

1：什么是软件测试？（定义）

 

顾名思义，就是在规定的条件下对一个产品或程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

 

2：发展现状

目前国内软件产业规模越来越大，国内软件行业突破了传统的作坊式生产，从单打独斗的开发模式升级为工业化、流水线式的生产模式，导致专业的软件测试人才需求缺口巨大。

据悉，目前国内软件测试和开发人员比例大约在1：4—1：5，而国外测试和开发人员比例为1：1，可见，国内软件测试人才需求和职业发展潜力巨大。据分析，中国软件测试职业具有以下特征：

 

• 就业竞争小，工作起点高

 

信息产业部门发布的报告显示，我国目前软件测试人才的缺口在30万以上，在未来的十年中这一数字还将持续增大，因此从事测试职业所面临的竞争压力将远小于其他职业。而目前单独设立软件测试部门，对测试工程师有强烈需求的企业多是较大规模的软件企业，就业平台是比较高的。

 

• 薪资待遇好，职业寿命长

 

随着测试软件行业的兴起，薪资待遇越来越完善，刚入行的软件测试人员，起步月薪就在6000—10000元左右，远高于同龄人的薪资水平，工作2-3年后的薪资更是翻番。质量是产品的灵魂，作为软件质量的把关者，软件测试工程师在企业中的地位也越来越重要，其工作相对更加稳定，而且随着项目经验的不断增长，对不同行业背景了解的不断深入，软件测试工程师的水平将会越来越高，越“老”越吃香。

 

• 无性别歧视

目前软件开发领域一直趋于男生居多，而且很多公司加班通宵赶项目时常发生，而软件测试人员相对来说前期比较清闲，大多数只有产品上线的时候整个项目团队会加班。

由于工作的特殊，软件测试人员往往更偏好认真、耐心、细致、敏感、等个性元素，而这在一定程度上与女性的个性气质相吻合。据了解，目前很多IT企业中软件测试人员的比例更趋向平衡，甚至出现女性员工成主流的情况。

 

 

3：职业发展

 

初级测试工程师

通过网络或者是书籍学习或具有一些手工测试经验的个人，通常需要掌握独立编写功能测试用例，执行测试计划，编写测试报告，以及常用命令和常用工具的使用

测试工程师/测试分析员

具有1-2年经验的测试工程师或程序员。 能编写自动测试脚本和性能测试，进一步拓展编程语言、操作系统、网络与数据库方面的技能。

高级测试工程师/测试分析师

具有3-4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级的评审，并为其它初级的测试工程师或程序员充当顾问。继续拓展编程语言、操作系统、网络与数据库方面的技能。

测试组负责人

具有4-6年经验的测试工程师或程序员。负责管理 1至 3名测试工程师或程序员，担负一些进度安排和工作规模/成本估算职责，更集中于技能方面。

测试/编程负责人

具有6-10年经验的测试工程师或程序员。负责管理8至 10名技术人员，负责进度安排、

工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，为一些用

户提供支持与演示，开发一些特定领域的技术专长。

测试/质量保证/开发（项目）、经理

具有10多年的工作经验。 管理 8名或更多的人员参加的1个或多个项目， 负责这一领域 （测试/质量保证/开发）内的整个开发生存周期业务，为一些用户提供交互和大量演示，负责项目成本、进度安排、计划和人员分工。

计划经理

具有15年以上开发与支持（测试/质量保证）活动方面的经验。管理从事若干项目的人员以及整个开发生存周期，负责把握项目方向与盈亏责任。

 

4：职业发展空间

 

结合国内外软件测试行业现状，划分为三个方向，分别是自动化测试工程师、白盒测试

工程师、性能测试工程师。

 

自动化测试工程师，为其定义在功能测试范畴，指通常所说的依靠自动化测试工具进行

软件黑盒测试的工程师。

白盒测试工程师，定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的

人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测

试覆盖率分析等。

 性能测试工程师， 即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和

运行效率检测。

 

 

5：薪资调查

 

在所有软件测试专业毕业的同学中经过智联招聘的数据分析得知，其月平均工资约8246元，最低工资约5000元，最高工资为30000元以上，高级测试工程师年薪可高达25万元，其中21.1%的同学选择在北京发展，从近期的企业人才需求和薪金水平来看，软件测试工程师的年工资还有逐年上升的明显趋势。

 

 

 

测试工程师一般会分为以下几个等级：初级测试工程师、中级测试工程师和高级测试工

程师。不同的级别的测试工程师薪资差异很大。

初级测试工程师： 年薪约在8—12万元左右。他们的工作通常是按照测试方案和流程对产品进行功能测试，检查产品是否有缺陷。       

中级测试工程师： 年薪约在12—15万元左右。他们要能够编写测试方案，测试文档、与项目组一起制定测试阶段的工作计划。能够在项目中合理利用测试工具来完成测试任务。

高级测试工程师： 年薪约15—20+万元左右。他们不但需要掌握测试与开发技术，而且对所测试软件对口的行业非常了解，能够对测试方案可能出现的问题能够进行分析和评估。  

 

 

 

   软件测试背景

引言：

软件测试在软件生命周期中占据重要的地位，软件测试慢慢的独立发展成为一个行业，并且在迅猛发展，软件测试主要是发现问题定位问题，配合开发解决问题，如果公司中没有测试岗位可能存在很大的风险。

1.  软件缺陷与软件故障

一、      软件缺陷与软件故障案例

 

2. 软件缺陷产生的原因

软件缺陷从哪来？第一大原因就是软件产品规格说明书，很多情况下，说明书没有写，或写的不够全面，经常更改，或者开发小组没有很好的沟通，造成对说明书理解的不一致。第二大原因是软件设计，没有做设计或设计不好，经常变动等和产品规格说明书一样的问题，第三个原因才是编写代码和其它原因；前两个原因至少占了 80%以上。如图1-1所示

图1-1  软件缺陷产生的原因分布

通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：

(1)  需求解释有错误；

(2)  用户需求定义错误；

(3)  需求记录错误；

(4)  设计说明有误；

(5)  编码说明有误；

(6)  程序代码有误；

(7)  测试错误；

(8)  问题修改不正确；

(9)  不正确的结果是由于其他的缺陷而产生。

3. 软件测试和缺陷修复的代价

缺陷发现的越早，则修复这个缺陷的代价就越小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍（参见图1-2）。

 

4. 新人如何融入一个项目团队

5. 优秀的测试人员的基本素质

 1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。 2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试 3、负责测试用例的编写；编写测试报告和对测试结果分析， 4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行； 5、负责软件开发团队项目进度管理工作，6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等至少一种性能测试工具

 

6. 软件工程的目的

成本：项目的开销，人工成本，工具成本，设备成本，错误成本（BUG）

进度：时间，计划

质量：软件对顾客需求的满意程度，一个低质量的软件，即使生产成本很低，进度控制良好，顾客也难以接受。

7. 程序测试包含哪些内容

程序测试包括程序逻辑功能，界面，性能，易用性，兼容性，安装等测试，当然文档测试也算，排版，字体大小，也算程序测试的内容

8. 测试环境

测试环境=硬件+软件+网络

硬件环境：笔记本,台式机，服务器

软件环境：不同的操作系统 windows10   windows8   windows7   Linux   Mac，

不同浏览器：IE firefox  chrom

网络:局域网还是互联网

 

 

9. 测试流程

 

 

 

需求评审	测试计划制定	测试计划执行	发布与测试报告总结
1从用户体验角度提供设计建议 2从开发经验角度，分析设计是否存在风险，是否能够实现 3 联合其他模块分析，设计是否存在漏洞，逻辑功能存在缺陷	1测试用例设计 2测试用例评审，和测试时间估计 3测试资源申请 4测试人员分配	1用例执行 2 Bug修复验证和推动版本进度 3性能监控，压力测试，兼容测试	1版本发布和线上质量监控，用户反馈实时响应 2测试用例更新整合，测试计划评估 3提供版本最终测试报告，包括用例覆盖率，bug数据分析等
全程跟进需求变更，与产品无缝沟通，在测试阶段有需求变更要第一时间了解改动范围，如果影响版本的质量要说明风险，评估需求是否必须更改以及是否影响版本发布上线的时间线	规划测试项目需要的功能开发和自动化开发人员比例，规划整个测试流程需要的时间，要预留处理紧急事件的缓冲	执行 协调测试资源，部署测试环境，督促开发和产品提供一切需要的测试工具，测试数据等，推动版本进度，每日进行bug review（bug复盘），标识出bug解决的优先级和提交测试的时间点，每日提供当日产品质量报告	报告 项目发布上线后，对整个版本的bug进行数据分析，总结出用例的覆盖率，对于没有覆盖到用例的bug，转化成用例，同时测试人员之间进行分享，针对新接触的测试方法测试工具和有价值的bug进行经验总结

 

10.    软件测试分类

 

 

10.1. 黑盒测试和白盒测试

 

黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果

 

有人把黑盒测试比作中医，通过“望闻问切”来判断是否有问题。

 

“望”：观察软件的行为是否正常。

 

“闻”：检查输出的结果是否正确。

 

“问”：输入各种信息，结合“望”，“闻”来观察软件的响应。

 

“切”：像中医一样给软件“把把脉”，敲击一下软件的某些“关节”

 

 

白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构。

 

 

10.2. 静态测试和动态测试

静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。

 

动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。

 

10.3. 功能测试和性能测试

 

1.1.1.   功能测试

 

是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。

 

功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。

 

逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车

 

界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...

 

易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适

 

安装测试:

 

兼容性测试:硬件兼容性测试和软件兼容性测试

 

硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容

 

软件兼容性测试:比如一款软件在windows8和windows10上是否兼容

1.1.2.   性能测试

 

时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）

 

空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗

 

一般性能测试:软件正常运行，不向其施加任何压力的测试

 

稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。

7

负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）

 

压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）

 

 

 

 

 

10.4. 回归测试、冒烟测试、随机测试

1.1.3.   回归测试

是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug（回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。）

 

1.1.4.   冒烟测试

指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

 

测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。

 

1.1.5.   随机测试

 

是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

 

 

10.5. 单元测试、集成测试、系统测试和验收测试

 

 

1.1.6.   单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。

 

单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。

 

目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划。

 

单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码,检查运行的结果。

 

1.1.7.   集成测试

集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。

 

l  在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失

l  一个模块的功能是否会对另一个模块的功能产生不利的影响

l  各个子功能组装完成后，能否达到预期的父功能

l  全局数据结构是否有问题

l  单个模块产生的误差累计起来是否会放大

例如：模块接口测试

l  应对通过所测模块的数据流进行测试

l  调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配

l  所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。

l  输出给标准函数的参数的个数、属性和顺序是否正确

 

1.1.8.   系统测试和验收测试

 

集成测试完成之后，就是系统测试和验收测试。

 

系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

 

系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。

 

 

验收测试：以用户为主的测试，软件开发人员和质量保证人员参加，

 

11. 测试案例（需求：500ml的水杯）

 

1.1.9.   需求：(功能，性能，界面，安全，易用) 

测试一个带广告图案的花纸杯 

1.1.10. 功能测试

能否装水，

除了装水， 能否装其他液体。比如可乐，酒精

能装多少ML的水

杯子是否有刻度表

杯子能否泡茶，跑咖啡

杯子是否能放冰箱，做冰块

杯子的容量是否于需求一致（500ml）

1.1.11. 界面测试

外观好不好看。

什么颜色

杯子的形状是怎么样的。

杯子的图案是否合理

杯子外观是否简单，美观（需求文档）

杯子大小是否一致

杯子的材质是否与需求一致

1.1.12. 性能测试

能否装100度的开水 (泡茶)

能否装0度冰水

装满水，长时间放置是否漏水(7*24)

能否使用的最大的次数（漏水）

杯子内壁上的涂料是否容易脱落。

杯子上的颜色是否容易褪色或者脱落

掉在地上不易摔碎

如果是有盖子的：

         盖子拧多紧不会漏水

        

1.1.13. 安全性测试

制作杯子的材料，是否有毒

放微波炉里转的时候，是否会熔化。

杯子盛放热水是否释放难闻气味(毒味)

杯子是否容易滋生细菌

杯子内壁上的材料，是否会溶解到水中

装进不同液体，是否会有化学反应。

 

1.1.14. 易用性测试

杯子是否容易烫手

杯子是否好端，好拿

杯子的水是否容易喝到

杯子是否有防滑措施

是否能接受杯子的广告内容与图案

12.    测试分类占比

 

13.    软件测试的原则

1.应当把“尽早和不断地测试”作为开发者的座右铭。

2.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

3.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

4.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

5.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

6.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

7.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。 

14.    软件的开发模式

 

1.1. 线性模型与渐进式模型

线性模型：最常见的“瀑布模型”，基础框架，但缺点在于“集成之日就是爆炸之日”。（立项分析-需求分析-设计-编码-测试-维护）很多企业使用后使用迭代进行修改。

 

渐进式模型：最常见的“螺旋模型”，（需求分析-风险分析-设计、编码-测试、评审），迭代开发和增量开发模式。

 

注意：每一次迭代原型出来后，测试人员都需要从原型界面，系统主要功能，性能等方面对原型进行评审。

 

1.2. 迭代和增量的理解

 

15.    软件生命周期模型

软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1]  。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

 

1.1. 边做边改模型

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

 

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2） 忽略需求环节，给软件开发带来很大的风险；

（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

 

1.2. 瀑布模型

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题

 

优点：

1)  为项目提供了按阶段划分的检查点

2)  当前一阶段完成后，只需要去关注后续阶段。

缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4）瀑布模型的突出缺点是不适应用户需求的变化。

 

1.3. 原型化模型

 

原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。

如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。

 

模型要点：瀑布和原型模型相结合，强调版本升级。

 

该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。

该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。

该模型比较能符合实际的情况，我们往往也是通过多个版本来逐步实现全部需求，但需求是不可能在一开始就完全确定的，实际情况是往往只能确定80%，而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后，可以适用于大部分的实际项目。

1.4. 增量模型

增量模型也是原型化开发方法。如图所示

1.5. 螺旋模型

螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型的整个开发过程如图所示。

 

 

 

图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。

1.软件分多个版本开发，每个版本就是一次螺旋。

2.每个版本按照这样的顺序进行：

   1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）

   2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）

   3）实施软件开发；（图中右下象限）

   4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）

3.需求不是一次获取和实现的，通过多个螺旋来完善。

4.计划也不是一次成型的，每次螺旋都需要调整。

 

 

优点：

1）设计上很灵活，可以在项目的各个阶段进行变更；

2）以小的分段来构建大型系统，使成本计算变得简单容易；(国企项目)

3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；

4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

 

 

缺点：

螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。

因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

 

1.6. Ｖ模型

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

 

 

V模型的缺陷及解决思路

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

 

优点：

1 每一个阶段都清晰明了，便于控制开发的每一个过程。

2 既包含单元测试又包含系统测试。

缺点：

1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。

2 测试和开发串行。

 

1.7. Ｗ模型

 

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

优点

1 测试伴随着软件的整个生命周期，例如，在需求分析结束后就可以进行需求分析测试。

2 测试于开发是并行独立进行的。

缺点

1 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。

2 对于需求和设计的测试技术要求很高，实践起来很困难。

16.    软件测试的常识知识

1.1. 测试部门的组织结构

 

 

 

17.    软件测试工具

https://zhidao.baidu.com/question/8152959.html

软件测试工具是通过一些工具能够使软件的一些简单问题直观的显示，使测试人员更好的找出软件错误所在。

软件测试工具分为自动化软件测试工具和测试管理(禅道)工具。

软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入。

测试管理工具是为了复用测试用例，提高软件测试的价值。

一个好的软件测试工具和测试管理工具结合起来使用将会使软件测试效率大大的提高。

 

Bug管理工具：  禅道 Jira（付费）,Trac,gitlab

自动化   python+ selenium ，python+ appnium （ui自动化） pytest,unites,Junit (测试用例 单元测试)  innerHtml  （发送测试报告） request +python+allure 接口自动化

性能测试工具   jmeter ,Loadrunner、

抓包工具       Fiddler ,charles (弱网测试的)

接口工具      postman ，jmeter

录制脚本      bodyboy  jmeter

 

云测    腾讯云   模拟不同的移动端或者是web浏览器

 

命令  Linux  adb  monkey

数据库  myql,oracle,redis

语言  python,java,c,c++