一、缺陷的定义：所有不满足或者是超出用户需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。   二、软件测试的目的：     1、以最少的人力、物力、时间找到潜在的各种错误、缺陷    2、利用测试结果、测试信息，避免将来出现错误    3、利用更高效的测试管理手段，提高软件测试的效率和产品质量。    对软件测试的理解：     1、为了尽可能多的发现缺陷，避免线上出现重大问题    2、更深层次的定位bug，协助开发找到解决方案    三、测试和调试的区别：     1、主体不同，一个测试一个开发；目标不同，一个找bug一个改bug；  方法不同，一个正向思维一个反向思维；    2、测试：从已知条件开始，使用预先定义的过程，并没有预知的结果；调试：未知条件开始，结果未知    3、测试：可计划，预先定义用例，调试：计划较困难    4、对象不同：测试文档、数据、代码，调试代码    四、软件生命周期：     软件立项-需求分析-设计（概要设计、详细设计）、编码、测试（单元、集成、系统、验收）-发布维护-淘汰    软件定义：程序+数据+文档    五、软件开发过程模型     1、瀑布模型：    特点：分阶段，当前一个阶段完成，才能进入下一个阶段    优缺点：1、阶段划分过于严格2、线性，前期定需求，到后期才能见到结果，风险较大3、不适应需求的变化    2、快速原型：    特点：迅速建立起一个可维护的原型，便于达成共识确定需求    优缺点：1、克服了瀑布模型---前期需求后期结果----的缺点，减少了风险2、缺点：技术和工具不一定符合主流；快速建立不断更改导致质量低下    快速原型和敏捷开发模型的异同点：   快速原型，原型用于展示不投入生产使用；    敏捷开发（按照一个短的迭代周期工作，强调快，每次交付一些成果，快速响应新需求；迭代，逐渐完善）每次迭代都直接投放市场    3、增量模型    特点：模块作为一个增量组件，从而分批次的进行设计    优缺点：分批次提交，组件为单位，风险低；开发顺序灵活；但项目管理人员把握全局的水平较高。    4、迭代模型    特点：强调开发的深入、优化；每一次开发迭代都要经历完整的工作流程    优缺点：降低了一个增量的开支风险；降低了产品无法按照既定的进度进入市场的风险，加快了进度，适应需求变化容易    5、螺旋模型    特点：兼顾快速原型的迭代，以及瀑布模型的系统化    优缺点：引入风险分析，重大风险时有机会停止；适合大型昂贵的软件    六、软件测试过程模型（用于定义测试的流程和方法）     1、V模型    特点：1、忽视对需求、设计阶段的测试2、后期需求才能得到验证，风险较大3、没有体现尽早测试、不断测试的理念    2、W模型    特点：1、测试、开发并行2、测试对象：程序+需求+设计3、尽早测试，降低成本4、串行、无法支持迭代（无循环）    3、H模型    特点：1、准备好了就可以测2、尽早准备测试、执行测试3、按照某种次序，也可以反复执行    4、X模型（探索性测试、随机测试）    特点：1、帮助有经验的测试人员，在测试之外发现更多的错误2、针对单独的程序片段进行相互分离的编码和测试    七、软件测试过程理念     理念：尽早测试、全面测试    核心竞争力：尽早发现问题、发现别人无法发现的问题   八、软件测试的分类（重点）     1、按开发阶段划分：   单元测试：检查每一个程序模块能否实现详细设计说明书中的功能、性能、接口设计约束要求；需要从内部结构出发设计测试用例；多个模块可平行独立的进行单元测试    集成测试：单元测试基础之上，将所有的程序模块进行有序的递增测试，检查单元或部件的接口关系，逐步集成为符合要求的程序部件或整个系统。    集成模式：1、增量集成（测一个模块就连一个模块）2、非增量集成（每个模块测完了再连接）3、三明治集成（大爆炸集成，定位缺陷较困难）    集成划分：1、自底向上：从原子模块开始组装，测试到较高层模块时，所需下层模块功能均已具备，缺点是最后一个模块加入时才具备整体形象，需要开发驱动模块2、自顶向下：从主控模块开始测试，需要开发桩模块，能及时发现设计上的错误    确认测试：（较短）验证所有的功能、性能以及其他特性是否和用户预期要求一致    系统测试：（最重要）真实的环境下，检查完整的程序能否和系统正确的配置、连接，并最终满足用户所有的需求。（再进行大规模的系统测试前，先进行冒烟测试）     系统测试和集成测试的区别：1、角度：集成测试偏重于技术角度，系统测试偏重于业务角度2、内容：集成测试偏重于各个模块之间的接口，系统测试偏重于整个系统的功能和性能3、技术：集成测试黑盒+白盒，系统测试黑盒   验收测试：Alpha测试和Beta测试都需要用户的参与，但是Alpha测试是用户在开发环境或公司内部模拟实际操作环境的测试；Beta测试由最终用户来测试   各阶段对应的文档：单元测试-详细设计说明书，集成测试-概要设计说明书，系统测试-需求规格说明书，验收测试-用户需求   2、按测试技术划分     黑盒：    特点：不查看内部逻辑，只查看功能是否能正常使用    缺点：覆盖率较低    优点：易实施，不需要关注内部实现    白盒：    特点：对程序内部结构分析测试，对所有代码路径进行测试，是一种穷举测试。    缺点：耗费较大，不能检测到遗漏的逻辑    优点：可检测到代码的每一条分支路径，揭示隐藏在代码中的错误，对代码的测试比较彻底。    方法：语句覆盖、条件覆盖、判定覆盖、条件组合覆盖、基本路径覆盖    灰盒：基于外部表现也基于内部逻辑    4、按代码运行     静态：不实际运行代码，静态检查代码、界面、文档    动态：实际运行代码，输入相应的测试数据，检查实际输出结果和预期是否相符。    5、按软件特性     功能测试：    性能测试：某一功能在指定时间、空间下是否正常使用。    安全性测试：检查程序内保护机制能否防止非法程序入侵，不受各个因素干扰。    6、其他    回归测试：新版本要重复旧版本的所有测试用例。目的：旧版本缺陷被修复、确认没有新缺陷   冒烟测试：对新版本大规模测试之前，先验证一个软件基本功能是否实现，是否具备可测性    随机测试：经验、直觉    猴子测试：意想不到的错误    九、软件测试的流程     需求分析（需求是否合理）---制定测试计划（人、时间、业务点、工具）---测试用例设计---执行测试（环境搭建、bug提交）---测试报告    详细工作流程：    1、需求分析会议：产品、开发、测试参加，主要探讨一些功能点--->需求文档、原型图、数据库表设计    2、开发员进行开发，测试经理编写测试计划--->测试计划    3、测试员参考需求规格说明书、原型图编写测试用例--->测试用例    4、先预测（主功能业务测试）-->依据测试用例进行系统测试-->提交跟踪bug--->测试完，编写测试报告    5、产品上线，维护性测试    职责划分：   1、测试员：设计测试用例测试脚本    2、测试经理：制定测试计划    3、评估测试--测试经理召集开发、测试来做    十、关于需求     1、需求定义：用户解决问题、达到目标所需的条件；系统或系统部件满足合同、标准、其他正式文档所需条件    用户需求：用户使用产品要完成的任务    业务需求：客户对产品高层次、高目标要求    功能需求：开发人员必须实现的功能    2、80、20原则     Bug分布：将近80%在需求和设计上，20%在程序和其他方面    3、产品需求变更怎么办？     先看改动的范围，如果改动的范围较小，重新测试；    如果改动范围较大，可以放在下一个版本或者争取延长测试时间；    如果不能争取时间，加班加点，且在报告中说明变更情概况。    十一、评审     1、评审的定义：正式的会议上将软件项目的成果提交给用户、客户、相关部门对软件产品进行评价和批准。    2、评审的目标：找问题（找出可能影响软件产品质量、开发过程、维护工作的适应性和环境方面的设计缺陷）、解决问题、改进和优化（性能、安全性、经济方面的改进）    3、分类：    同行评审：产品创建者的同行们，改进不足    单人评审：简单、单独一个评审员    管理评审：软件项目、产品管理者    代码检查：检查编写好的代码规范    十二、两个定义     Software test plan：测试员与开发交流的主要方式，最终目标是交流意图、理解任务，重要的是过程而不是文档    Testcase:设计一种情况，程序在这钟情况下，必须能够正常运行并且达到所设计的预期结果。    用例编写注意：不要穷举，详细与时间的平衡，多关注反向，用例库应该不断的更新，可以复用但要注意有效性，灵活……    十三、黑盒测试用例设计方法     1、等价类划分：          确定了取值范围，一个有效、两个无效       确定了输入值集合或规定了必须如何，一个有效一个无效       布尔一个有效一个无效       输入一组值n个，n个有效，一个无效       规定必须遵守规则，一个有效，n个无效       规定划分的等价类，要划分更小的等价类           2、边界值分析          规定了范围，取刚到达范围的边界值以及刚超越这个范围的边界值       规定了个数，取最大个数、最小个数、最大个数加一、最小个数加一       找其他可能的边界       若给出的输入域输出域是有效集合，选第一个和最后一个       若使用了一个内部数据结构，则选取这个内部数据结构边界上的值         3、因果图          适合多种输入条件的组合（案例：饮料机）         4、判定表驱动          条件排列顺序、规则排列顺序不影响操作，某个规则满足并确定执行操作，不比检验别的规则；（案例：累不累）         5、正交试验法          用最少的实验覆盖最多的操作，用例少，效率高       确定因素，确定每个因素的水平，选择正交表         6、场景法：           描绘事件触发的场景，利于设计测试用例（基本流、备选流）        7、状态迁徙法：           一个状态---某操作---另一个状态，直到没有新的状态        8、测试大纲法：           着眼于需求        十四、web测试方法     1、web功能测试          链接测试：检查链接是否正确；跳转页面是否存在；是否有孤立的页面       表单测试：表单控件是否正确；提交信息是否正确完整；是否有错误处理       Cookie测试：（cookie通常标识用户信息、记录用户状态，使用web时会创建一个cookie文件，写入部分信息，若下次再访问，就能够正确的标识）检查cookie能否正常工作         2、web性能测试          速度测试：多长时间才能显示出来所需界面-----影响时间的因素有服务器（要从大量的数据中检索），硬件（cpu,内存），访问页面文件大小，网络       负载测试：一定负载下，web能否正常工作       压力测试：系统崩溃的临界点         3、web安全性测试          日志文件记录主要操作，加密技术要完整、正确，web是否有超时         4、web兼容性测试：服务端，客户端    5、web易用性测试：能否完成一个任务，完成一个任务多长时间，完成一个任务访问页面数，是否有明确的导航功能，帮助功能是否可靠、易用    十五、web测试、app测试区别     1、架构：web基于b/s,app基于c/s，web中只要更新了服务器，客户端会自动更新，app更新需要用户手动完成，app修改了服务器，意味着客户端使用的所有版本都要进行回归测试    2、性能：web关注响应速度，app关注电量、流量、cpu、内存    3、兼容性：web依赖浏览器、电脑硬件系统；app依赖手机、平板、安卓、ios；分辨率，尺寸，    4、app比web多一项---安装、卸载、更新、界面操作、触屏手势    十六、app测试关注哪些：     性能：cpu,内存，耗电量/流量（满格时候，省电模式），安装，卸载，更新，吞吐量（每秒系统能够处理的请求数），响应时间（处理一个请求的耗时），错误率（一批请求中出错的占比）    兼容性：不同系统上win,linux,unix，不同手机上android,ios    中断：电话、短信、断网    网络：三大运营商，数据wifi切换，4g2g切换，弱网，无网    十七、手动、自动化缺点，自动化意义     手动：          缺点：重复的手工回归测试代价昂贵容易出错；也依赖测试员的经验和能力       优点：手工测试员有经验和对错误的猜测能力；有审美能力、心理体验；有是非判断、逻辑推理能力         自动：          优点：回归测试更方便，缩短时间；可以运行更繁琐的测试；可以执行一些手工困难的、不可能的性能测试；更好的利用资源       缺点：不可以取代手工；手工比自动化发现的缺陷更多；对测试质量依赖很大；工具本身并没有想象力；制约软件的开发         自动化测试的意义：1、回归测试2、执行困难的压力、并发等性能测试3、更好的利用资源，节省时间、人   使用测试工具的意义：帮助测试找问题、协助问题诊断、节省测试时间   十八、bug周期、类别     New:测试员发现一个bug    Assigned:开发确认是一个bug    Open:开发处理bug    Fixed:开发自认为已修复    Pending Reset:（待测）    Reset:再测    Closed:确认解决    Reopen:再次打开    Pending Reject:开发拒绝    Rejected:被拒绝    Postponed:延期    new----assigned----open---fixed--pending reset---reset----closed---reopen---pending reject----rejected---postpoend    bug类型：代码错误，界面优化、设计错误、性能问题、测试脚本