测试小知识

---

测试小知识

一、软件缺陷

1、软件缺陷产生的原因

1. 需求解释有错误
2. 用户需求定义错误
3. 需求记录错误
4. 设计说明有误
5. 编码说明有误
6. 程序代码有误
7. 数据输入有误
8. 测试错误
9. 问题修改不正确
10. 不正确的结果是由于其他的缺陷而产生

2、软件测试和缺陷修复的代价

	缺陷发现的越早越好，发现的早修复的代价就小，在需求、设计、编码、测试、发布等不同的阶段，发现缺陷后修复的代价都比在前一个阶段修复的代价高10倍
	能甩锅就甩锅，甩锅给开发，给项目经理，不能拍案说上线，有问题找经理
	

二、软件测试基础理论

 前言： 软件测试是保证软件质量的一种手段，那么，什么叫软件测试

1、软件测试定义

	狭义：测试的定义：‘程序测试是为了发现错误而执行陈旭的过程’。这个定义呗业界所认可，经常被引用
	广义：为了更早的发现问题，所以将测试延伸到需求评审、设计审查活动中，也就是将‘软件质量保证’的部分活动归为测试

2、软件测试的现状

现状：初期 ，不成熟，浮躁
公司越来越注重，开发与测试比列越来越接近
没有建立起相对完整的测试体系概念：对自己的工作职责理解不到位
在中国必然安会经过一个不成熟的阶段，但最终会趋于平静，平稳的发展阶段

3、测试的前景

软件测试员-》初级测试工程师-》中测试工程师
到了中级就有很多的职位了
	测试组长- 资深测试工程师-质量师-测试经理、项目经理、产品经理-行业测试专家、测试分析师、质量经理、质量内审

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

1. 学习需求文档	2.查阅用户手册	3.学习设计文档	4.查阅BUUG库	5.编写测试用例	6.提问的技巧	7.寻找可学习的人	8.虚心学习的态度

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

1、参与需求讨论，制定测试计划，确保测试能顺利执行并完成
2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试
3、负责测试用例的编写；编写测试博爱高和对测试结果分析
4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行
5、负责软件开发团队项目进度管理工作
6、熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句
7、熟悉使用loadrunner，jmeter等至少一种性能测试工具
	缜密的思维能力--正确的测试态度--性格：好奇心、成就感--良好的心理素质

6、软件工程的目的

成本--进度--质量=成功项目

7、程序测试包涵那些内容

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

8、测试环境

测试环境=硬件+软件+网络
硬件环境：笔记本，台式机，服务器
软件环境：不同的操作系统 Windows10 Windows8 Windows7 Linux Mac
不同的浏览器Firefox  Chrome
网络：局域网或者互联网

9、测试流程

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

三、软件测试分类

1、黑盒测试和白盒测试

 黑盒测试（black Box Test）指的是吧测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，
        只关心软件的输入数据和输出结果
        有人把黑盒测试比作中医，通过 “望问切问” 来判断是否有问题

        “望” 观察软件的行为是否正常
        
        “闻” 检查输出的结果是否正确
        
        “问” 输入各种信息，结合 “望” ，“闻”来观察软件的响应
        
        ”切“ 想中医一样给软件 ” 把把脉“ ，敲击一下软件的某些 ”关节“
        
白盒测试（White Box Testing）指的是吧盒子打开，去研究里边源代码和程序结构

2、静态测试和动态测试

静态测试：是指不实际运行被测试软件，而只是静态的检查程序代码，界面过着文档中可能存在的错误的过程
登台测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和逾期结果是否相符过程

3、功能测试和性能测试

3.1功能测试

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

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

逻辑功能测试：测试应用是否符合逻辑，不如应该先注册账号之后，才能登陆，登陆之后才能看我的购物车

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

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

3.2 性能测试

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

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

一般性能测试：软件正常运行，不向其事假任何压力的测试

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

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

压力测试：持续不断的给被测试的系统增加压力，知道被测试的系统压垮为止，用来测试系统所承受的最大压力(测试强度)

四、回归测试、冒烟测试、随机测试

4.1、回归测试

是指对软件的新版本进行测试时，重复执行上一个版本测试的用例，比如在1.0版本中没有一个bug，到了2.0中，再重新测试1.0这个bug

4.2、冒烟测试

指对一个软件惊醒系统大规模的测试之前，先验证一下 软件的基本功能是否实现，是否具备可测性
测试小组在正式测试一个新版本之前，先指派一俩个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本

4.3、随机测试

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

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

5.1、单元测试

	单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或者一个菜单等
	单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如Java中执行单元测试叫做Junit测试
	目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划
	单元测试方式：先静态地观察代码是否符合规范，然后动态地运行一下代码，检查运行的结果

5.3、集成测试

集成测试是单元测试的下一个阶段，是指通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分
	在把各个模块连接起来的时候，穿越各个模块的接口的数据时候会丢失
	一个模块的功能是否会对另一个模块的功能产生不利的影响
	各个子功能组装完成后，能否达到预期的父功能
	全局数据结构是否有问题
	单个模块产生的误差累计起来是否会放大
例如：模块接口测试
	应对通过所测模块的数据流进行测试
	调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
	所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序是否匹配
	输出给标准函数的参数的个数、属性和顺序是否正确

5.4、系统测试和验收测试

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

系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，一级软件所运行的软硬件进行测试

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

六、测试分类占比

七、软件测试的原则

1、应当把“尽早和不断地测试”作为开发者的座右铭
2、设计测试用例时，应该考虑到合法的输入和不合法的输入，一级各种便捷条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况
3、一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
4、对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有B来确认，严重的错误可以召开评审会进行讨论和分析
5、制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极端的时间内完成一个高水平的测试
6、回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
7、妥善保存一切测试过程文档 ，意义是不言而喻的，测试的重现性往往要靠测试文档

八、软件的开发模式

8.1线性模型和渐进式模型

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

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

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

8.1、迭代和增量的理解

9、软件生命周期模型

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

9.1、边做边改模型

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

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

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
	1、缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改
	2、忽略需求环节，给软件开发带来很大的风险
	3、没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难