在规定的条件下对程序进行操作去发现错误，然后对软件质量进行评估的一个过程。
需要注意的是，软件是由文档、数据以及程序组成的，所以对软件测试应该包括：软件形成过程的文档、数据以及程序，而不仅仅是对程序进行的测试。
通过测试工作发现问题并及时报告给开发，让开发修复软件当中潜在的各种错误和缺陷，提高软件质量，进而提高用户对产品的使用信心，避免软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持
（比如抢火车票，你模拟用户测试，最终测出的流量上限是1个亿。那高层拿到你的测试数据后就可以去决策这个上限能否让软件投放市场）
测试可以降低同类型产品开发遇到问题的风险。（参考同一公司的微信和qq，都是社交软件，qq踩过的坑可以让微信规避掉）
不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻列出来
缺陷存在群集现象：对于软件功能说，核心功能占20%，非核心是80%。在实际工作中我们会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就会遇到缺陷都集中在20%功能模块里的现象。
某些测试需要依赖特殊的环境：像有些手机不考虑冬天的情况，温度低的时候电量掉的快
测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷，我们追求测试工作尽早的开展
杀虫剂现象：同样的一个测试用例不能重的执行多次，因为软件会对它产生免疫（ 开发会根据你 的用例去修改，你再测同样的用例肯定能过关的或是被开发蒙混过关）
不存在缺陷谬论：任何软件不可能是完美的。
1.需求分析阶段：各种需求规格说明书
2.软件架构设计：API接口文档（接口测试）
3.编码实现阶段：源代码（白盒测试、单元测试）
4.系统功能使用：软件功能主体（当前行业做的最多的一种测试）
明确测试的目标，增强测试计划的实用性，明确内容与过程
采用评审和更新机制，保证测试计划满足实际需求
需要分别创建测试计划与测试详细规格、测试用例
瀑布流
项目计划—>需求分析—>软件设计—>编码—>测试—>运行维护
优点：
软件开发的各项活动严格按照线性方式进行
前一阶段完成后，只需关注后续阶段
缺点：
难以适应需求的频繁变化
早期的错误可能要等到开发后期的阶段才能发现
V模型
W模型
还有X模型、H模型
需求分析
软件设计（概要设计、详细设计）
软件编码
软件测试（单元测试、集成测试、系统测试、验证测试）
运行维护
详细介绍
功能性、可靠性、效率、易用性、可维护、可移植
功能性
定义:软件在指定的使用环境下,满足用户显性或隐性需求的能力
适合性:软件为指定的任务和用户目标提供一组合适功能的能力
准确性:软件提供具有所需精确度的正确或相符的結果或效果的能力
互操作性:软件与一个或更多个的规定系统进行交互的能力
可靠性
定义:软件在指定的条件下使用,维持规定的性能级别的能力
成熟性:软件为避免由软件中错误而导致失控的能力,
容错性:在软件出现故障或违反指定接口的情况下,软件维持规定性能级别的能力,
易恢复性:在失效发生的情况下软件里重建规定的件能级别并恢复受直接影响的数据的能力
可靠性依从性:软件遵循与可靠件相关的标准,约定以及法律法规的能力
效率
定义:在规定的条件下,相对于所用资源的数量,软件提供适当性能的能力
时间特性:在规定的条件下软件执行其功能时,提供适当的响应和处理时间以及吞吐率的能力
资源利用性:在规定的条件下软件执行其能力时,使用合适的资源数量和类别的能力
效率依从件:软件遵循与效率相关的标准和约定的能力
易用性
定义:在指定的条件下使用时,软件被学习,理解,使用和吸引用户的能力
易理解性:软件的使用，用户能理解软件是否合适,以及如何将软件用于特定的任务和使用环境的能力
易学习:软件使用户能学习其应用的能力易操作性:软件使用用户操作和控制它的能力
吸引性:软件吸引用户的能力
易用性依从性:遭循与易用性相关的标准、约定风格指南或法规的能力
可维护
定义:软件可被修改的能力,修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应性
易分析性:软件诊断软件的缺陷,失效原因或识别待修改部分的能力,
易改变性:软件指定的修改可以被实现的能力
稳定性:软件避免由于软件修改而造成意外结果的能力,
易测试性:软件使已修改软件能被确认的能力
可维护依从性:遵循与维护相关标准和约定的能力,
可移植
定义:软件从一种环境迁移到另一种环境的能力
适用性:软件能适用于不同的环境的能力
易安装性:软件在指定环境中被安装的能力
共存性:软件在公共环境中同与其分享公共资源的其他独立软件共存的能力
易替换性:软件在同样的环境下,替代另一个相同用途的指定软件产品的能力
可移植性依从性:软件遵循可移植性相关的标准和约定的能力
只要满足下列5个规则之一则称为发生了一个软件缺陷
软件未实现产品说明书要求的功能
软件未实现产品说明书虽未明确提及但应该实现的功能
软件出现了产品说明书指明不应该出现的错误
软件实现了产品说明书未提到的功能
软件难以理解、不易使用、运行缓慢，或者从测试员的角度看，最终用户会认为不好
致命：系统崩溃、异常退出、严重计算错误、严重资源不足
严重：系统无法满足主要的业务要求，像业务流程错误
一般：系统可以满足业务要求但有性能缺陷或界面缺陷，像提示信息不准确
轻微：易用性及建议性问题，不影响执行工作功能，像出现错别字
添加链接描述
内容可以涉及测试流程，测试分类，测试方法，测试工具
需求分析，梳理清楚我们需要设计的点是什么
编写测试计划，做什么类型的测试，需要什么样的工具
编写测试用例，用例是为了测试软件的某个功能而执行的操作过程
评审用例，对当前的用例进行添加或者删除
配置环境
执行用例，执行用例前先做冒烟测试，通过才开始正式测试
回归测试，缺陷被开发修复后进行复测
缺陷跟踪
输出测试报告，方便其它人去查看
测试结束，将整个测试过程产生的文档进行整理归档，方便后续版本使用。
社招：
1.首先要进行需求分析。软件开发完成以后，由项目经理拿到需求文档后，召开会议，开发、测试一同参与，评审需求文档中的内容。
（需求的来源（拿到软件不知道要测什么的时候参考的渠道）：需求规格说明书（产品经理提供）、看行业标准和政策法规、竟品分析、个人经验）
2.项目经理根据评审后的需求文档，制定测试计划。
（包含内容：人员、任务划分、时间规划（开发的 30%-40%）、项目结束需要出具的文档（测试用例文档或 bug 文档）、做什么类型的测试？需要什么样的工具……）
3.测试人员根据测试计划，编写测试用例。
4.测试用例编写完后后，需要召开会议，开发、测试一同参与，评审测试用例。
5.搭建测试环境，在开发提交第一版本后，开始进行测试，对测试发现的问题提交到bug管理平台。
6.开发人员修改bug后，对bug进行复测，确保bug修改后，关闭bug。
7.每次开发提交新版本后，重复5、6的操作，直到上线前的最后一个版本。
8.版本上线前，需要对系统进行一次全面的系统测试，测试不再发现bug后，进行上线的工作。
1.单元测试[ UT unit test]（白盒）：在软件测试中单元指的就是组成软件最小的底层代码结构一般就是类、函数、组件（当下的软件测试行业，不会刻意要求测试人员对源代码进行测试）
2.集成测试（IT system ingertaion test）（灰盒）：将多个单元模块组合在一起，然后验证它们之间沟通的”桥梁"是否能正常工作（接口测试）
3系统测试（ ST system test）（黑盒）这是当前行业做的最多的一种测试。由测试人员充当用户然后对软件的功能主体进行测试
4.验收测试
（1）α测试一内测，在软件开发环境下进行的测试，开发和测试在一起，把用户请到公司内部进行测试使用，或者说是公司内部的用户在模拟实际操作环境下进行的测试
（2）β测试-公测，用户的应用环境下，开发和测试不再一起，还要由玩家把bug发邮箱然后获得奖励的那种
（3）UAT（ user acceptance test）测试一由客户派出对于业务非常精通的人员来使用该软件，从而对功能进行测试。
（4）验收测试的核心就是让用户为当前软件“买单
1.功能测试：验证当前的软件主体功能是否可用。
2.兼容性测试：验证当前软件在不同的环境下是否还可以使用
3.安全测试：验证软件是否只是能授权用户提供功能使用。
4.性能测试：相对于当前软件消耗的资源它的产出能力。
按测试对象进行分类
1.白盒测试：这种测试的主体就是软件的底层代码，不会在意外在的界面是否OK，只要求底层功能实现，同时逻辑正确（把盒子打开，去研究里面的源代码和程序结构。）
2.黑盒测试：这種测试就是指测试软件外在主体功能是否可用，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和输出数据
3.灰盒测试：介于二者之间（接口测试）
4.上述三种方法当中的“盒”指的就是被测对象。
白盒测试、黑盒测试、灰盒测试，在实现测试方法上既包括了动态测试，也包括了静态测试。
按测试对象是否执行分类
1.静态测试：指的就是测试不执行。（开发出来的html和美工预期的html直接用肉眼看看是否相同即可）（指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程）
2.动态测试：将软件运行在真实的使用环境中进行测试。是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。）
按测试手段进行分类
1.手工测试：由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境。
2.自动化测试：所谓自动化主要有二种形，一种是自已写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。优点就是可以高效率的去执行一些人工无法实现的操作。
黑盒测试（功能测试）：边界值。等价类划分，因果图，决策表，错误推测法
白盒测试：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖
1、等价类划分法：把程序的输入域划分为若干部分，从每个部分中选取少数、有代表性的数据作为程序输入的测试用例。
2、边界值分析法：配合等价类使用的，对范围的边界数据进行专门测试。一般情况下，需要对边界值（O和100）以及边界值两边的数（-1和1以及101和99）分别进行测试。
3、错误推测法：利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，
像输入一些非法、错误、不正确和垃圾输入，输入空格、输入为空等等
因果图法：等价类和边界值没有考虑到输入的组合关系，因果图考虑的就是这个问题
用法：根据题目列出可能的输入和输出情况，然后对输入和输出各自进行条件的组合，把各自的组合关系列出来，然后就可以制成判定表了。
判定表驱动法：因果图只是一种辅助工具，通过分析最终得到判定表，再
通过判定表编写测试用例。但有时画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例。
判定表的组成
条件桩：问题的所有条件
动作桩：问题的所有输出
条件项：针对条件桩的取值
动作项：条件项的各种取值情况下的输出结果：
正交表法：
使用最小的测试过程集合获得最大的测试覆盖率，不可能为每个输入组合
都创建测试用例时，可以采用这种方法。
特点：均匀分散
使用：它有正交表模板，根据你题目中的控件和取值个数去选取合适的模板，然后把数据映射到模板上就可以得到测试用例表了。如果说是混合正交表不能使用模板的话就要用正交表生成工具了。
场景法：
模拟用户操作软件时的场景，主要用于测试系统的业务流程
当业务流程测试没有问题，也就是该软件的主要功能没有问题时，我们再重点从边界值、等价类等方面对控件进行测试
冒烟测试时也主要采用场景法进行测试
使用：
产品经理提供的业务需求就当成场景法的测试用例去测就行了，结果不一样的话提bug就可以了
通常在确定测试方法时，有以下几条参考原则：
（1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。
（2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。
（3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强
（4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法。
（5）对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试南例获得最大的的测试覆盖率）.
（6）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。
（7）采用错误推断法再追加测试用例—依靠测试工程师的经验和智慧
1）测试目的：
功能测试：检测实际软件的功能是否符合用户需求，测功能是不是全部实现，某个实现是不是有BUG。主要为了发现以下几类错误：A、是否有不正确或遗漏的功能？B、功能实现是否满足用户需求和系统设计的隐藏需求？C、能否正确接收输入？能否正确输出结果？
性能测试：验证软件质量的三个质量特性，可靠性，正确性和效率。主要是测试产品的健壮性
2）测试方式：
功能测试按照系用例，按照系统需求说明书和测试用例，对产品的功能一步步进行测试。找出产品功能是否全部实现
性能测试：一般都使用性能工具对产品的健壮性进行评估。通过创建场景和虚拟用户模拟真实环境，进行压力测试和负载测试。
性能测试包括压力测试和负载测试，测试的是不同负载条件下系统的各项性能指标，如吞吐量、响应时间、点击率等。
负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
压力测试可以被看作是负载测试的一种，即高负载下的负载测试。查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
通过压力测试可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载（压力测试）下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在50个并发用户时错误率是1%，而在200个并发用户时错误率是20％。
负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所c的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。
负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用。负载测试的加载方式也有很多种，可以根据测试需要来选择。
性能测试是为获取或验证系统性能指标而进行测试。多数情况下，性能测试会在不同负载情况下进行。
压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
黑盒主要是根据业务需求来设计的输入，白盒则根据系统的内部实现设计的输入，它的主要目标是覆盖更多的代码
只适用于单元测试阶段
优点：代码覆盖率高
缺点：覆盖所有代码路径难度大、业务功能可能覆盖不全、测试开销大（手工测，费人力；自动测，代码量大）
测试设计方法：
静态：测试过程中不执行程序，即不执行代码进行测试
手工方法：
桌面检查（交叉检查）（a写的代码给b检查，b写的代码给a检查）、
代码审查（相对正式，以会议的形式进行检查，由开发讲解自己的代码，下面的开发和测试听，然后提意见）、
代码走查（也要开会，形式是测试人员提前准备好测试用例看看程序的走向如何，人工来计算查看数据的走向）
自动化方法：
自动化工具，进行代码的扫描
动态：执行代码进行测试
方法有：
逻辑覆盖法：是通过对程序逻辑结构的遍历实现程序约覆盖。
基本路径测试法：在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例
逻辑覆盖法具体有：
语句覆盖：设计浏试用例，使得程序中每条语句至少被执行一次
缺点：语句覆盖不能准确的判断运算中的逻辑关系错误。
判定覆盖：也叫分支覆盖，设计测试用例，使得程序中的每个判断的“真”和假"都至少被执行一次。即：程序中的每个分支至执行一次。
缺点：判定覆盖会忽略条件中取或（or)的情况。
条件覆盖：设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值。
缺点：条件覆盖并不能保证判定覆盖。
判定条件覆盖：满足100%判定覆盖和100%条件覆盖的标准
缺点：会忽略条件中取或（or)的情况。
条件组合覆盖：设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次。
缺点：条件组合覆盖不能保证所有路径被执行
路径覆盖：设计测试用例，覆盖程序中所有可能的路径
缺点：满足路径覆盖，并不一定能满足条件覆盖，也就不能满足条件组合覆盖。并且实际过程中的循环是无法用这个方法的，工作量巨大。
设计用例一般使用基本路径测试，重点模块使用多种覆羕率标准
黑盒测试优缺点
优点
・对测试人员要求不高
・执行起来较简单，不需要了解程序内部的代码及实现
・能够谝历说明书中全部的功能；
・可以方便的测试复杂逻辑的程序功能
缺点：
・不可能进行穷举测试
・不可能进行覆盖所有代码的测试
・测试的正确率依赖于需求文档说明书，但是该文档也是人为编写的，存在一定的风险
白盒测试优缺点
优点
・迫使测试人员去仔细思考软件的实现
・可以检测代码中的每条分支和路径
・揭示隐藏在代码中的错误
・对代码的测试比較彻底
・让软件最优化
缺点
・昂贵
・无法检测代码中遗漏的路径和数据敏感性错误
・不验证规格的正确性
介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
测试者知道系统组件之间是如何相互作用的，但对组件内部程序功能和运作缺乏了解。
灰盒测试的优点
①相对于白盒测试，灰盒测试成本低；
②引入了自动化技术，提高测试效率，规范测试流程；
③能够进行基于程序路径的覆盖测试，保证软件质量。
灰盒测试的缺点
①投入的时间比黑盒测试多20%-40%；
②对测试人员的要求相对较高；
③不适用于简单的系统，成本高，性价比低。
概念：让程序代替人为去验证程序功能的过程
21伪为什么要进行自动化测试？能解决哪些问题？
1.解决-回归测试
2.解决-压力测试
3.解決-兼容性测试
4.提高测试效率，保证产品质量
回归测试：项目在发新版本之后对项目之前的功能进行验证；（并不是所有项目都要回归测试，但是和金融、火箭相关的就一定要，因为很精细）
压力测试：可以理解多用户同时去操作软件，统计软件服务器处理多用户请求的能力
兼容性测试：不同浏览器（IE、 Firefox chrome）等等
自动化测试在什么阶段开始？
功能测试完毕（手工测试
手工测试：就是由人去一个一个输入用例，然后观察结果；
站在代码可见度而言
自动化测试所属分
1.黑盒测试（功能测试）
2.灰盒测试（接口测试）
白盒测试（单元测试）
提示：web自动化测试属于黑盒测试（功能测试）
优点
1.较少的时间内运行更多的则试用例
2.自动化脚本可重复云行；
3.减少人为的错误；
4.测试数据存储
缺点
1.不能取代手工测试（比如登录框本来是要验证输入是否有用的，结果因为界面打不开而自动提交bug了）
2.手工测试比自动化测试发现的缺陷更多；
3.测试人员技腰要求；
误区：
1）.自动化测试完全替代手工测试
2）·自动化测试一定比手工测试厉害
3）.自动化可以发掘更多的BUG
3.自动化测试分类
1.web-（UI）自动化测试（本阶段学习）
2.接口-自动化测试
3.移动（app）-自动化测试
4.单元测试-自动化测试
接口测试工具： Jmeter, postman, robotframework
性能测试工具： Jmeter, loadrunner
U测试： Selenium
添加链接描述
1.一款软件从无到有会经历很多的开发阶段由不同的人来参与开发，所以最终产出的软件功能可能会存在问题。因此为了保证软件的功能是可用的，我们必须要进行测试。
2.当前的软件件行业已经不在是功能为王了，用户不仅仅只盯看软件的功能是否满足需求还会对软件是否容易上手，执行效率是否OK……等一系列其它体验都有了更高的要求，所以这也需要我们对软件进行大量的测试。
硬技能方面，第一计算机知识，包括操作系统，数据库，通讯协议原理，熟悉至少一门编程语言；
第二软件测试知识，包括各种测试理论，测试方法，测试用例编写，缺陥跟踪流程，软件质量评估等；
第三产品业务分析能力，熟悉所測产品的一些隐藏需求或者功能
软技能方面，像沟通能力、做事严谨耐心、富有责任心、对被测产品具有怀疑与破坏的精神、另外还要善于自我总结、自我督促。
因为喜欢测试，我从来不觉得测试不如开发！
测试的过程又是一个学习和思维进一步发散的过程，一直引领人往前探索，很有吸引力。我喜欢玩解谜类的益智游戏，我感觉测试和解谜游戏是一样的，都有一个从观察到推演，到尝试，到归纳再到发现的一个过程。
我觉得其实测试需要比开发拥有更加全面的技术，好的测试不仅要会做测试，还要懂代码的内部实现，还要有产品、业务的意识；
测试和开发是两个关注点不一样的工作。开发的目标是实现功能，测试的目标是确定功能是否能够正常运作。那么它的乐趣在哪里？简单地说是两个关键词：“发现”和“分析”。
我很喜欢一句话就是：
有的人喜欢创造世界，所以他们做了开发
有的人喜欢拯救世界，所以他们做了测试
测试人员不需要有太强的编程技术，普通应用或是代码段能看懂就行。思考问题时要全面、细致、有原则，对产品敏感，不能跟着开发和产品走，这是测试人员的基本要求。 测试开发人员需要写测试工具，自动化测试代码，具备一定的开发编码能力，虽然不像开发那样深入地掌握一种编码语言，但对于脚本语言还是要有所掌握，比如：Java、Python
每个公司的的项目都有严格的开发进度，开发部门忙于实现功能的时候，我想没几个产品经理会同意频频打断开发的进度要求停下来做bug分析。
而且专人做专事质量更加有保障，开发大多数的时间都是在思考如何实现具体的软件功能，怎样把功能做对，怎样让用户去用这个功能，测试则每天想的是如何提高软件质量，我要向的是每天要以怎样的奇葩的方式去用这个软件，而我们想的是用户怎么把这个功能用错
举例，就好像生产电脑，开发想的是怎么开机关机，测试想的是要是有人把笔记本360度折叠怎么办
而且从测试力度的角度来说，对于开发来说，自己写的东西就是最好的，测起来就不会这么狠，毛病就不会挑的这么多
首先确认开发环境是否跟自己的测试环境一致，排除因环境或者业务理解不一致而产生的错误bug。确认是bug后，和开发保持有效的沟通。重要程度高的bug，去找相关的需求规格说明书、概要设计文档等，确认这个功能是否与文档不一致，把bug描述清楚，尽量做到无歧义无冗余步骤，bug按照操作步骤可以复现，难以复现的截图下来和开发进行讨论。如果开发还不接受，就找项目经理或者产品沟通。
如果这个bug是个重要程度较低的，你可以优先测试其他功能，暂时不需要花大量时间去说服开发修改，有时间再进行集中跟进。
在我负责的这个入库模块里，有一个入库数量的文本框。
我测的时候，发现它只能接受数字，不能接受字母，也不能为空。
你按键盘下去再松开键盘按钮它会消失刚才输入的字母。然后我看了它的源码，开发写的是他给这个文本框定义了一个事件onkeyup，他用了一个replace函数对输入的字母用正则表达式替换成了空字符串。
然后如果你在这个框里不输入数据进行提交的话它会弹出一个提示让你输入，不能为空。
一开始测的时候，不能接受字母和非空测试没问题。当时就觉得说这个文本框通过测试。
到后面系统开发差不多了，我再复测一遍。那次我记得我当时一直按着一个字母a键，想着说看松开能不能通过不能接受字母的测试，后面不小心鼠标点到了文本框的外面，那一连串的a被输入到输入框里了，没有消失。我当时就很兴奋，那我这不是绕过了它的前端检验吗。我就提交，发现系统报错了。然后我就去看数据库，看了它的表的结构，它对应表的属性是整型，不能接受字母很正常。然后我觉得说可能是后端没有校验，直接接受前端的数据传给数据库导致失败。
我就突发奇想，再找一种绕过前端的方式看看是不是后端真的没有进行校验。我就打开开发者工具对表单校验进行一个http请求的抓包。在输入一个有效值提交后，找到它的请求文件里的请求头，因为它请求的方法是get，请求的参数明文显示在url里。我把刚才输入的值删掉然后直接在开发者工具里进行重发，绕过前端页面，然后看数据库果然保存了一个空值。证明了后端没有校验，不然它会给我返回错误消息什么的。
这也给了我一个思路，表单提交的时候不仅要测前端，还要测后端
（其实非空验证直接空值提交然后抓包的时候它不会产生任何请求文件，这也说明了没有进行http请求过程，也就是说这个非空校验是前端校验）
如果有幸入职咱们公司
1年内先做好本职工作、积累业务知识；
2-3年时间希望能完成公司项目的自动化架构，实现自动化测试；
目前我已经开始在研究学习 Python编程及编写自动化测试脚本；
3-5年的时间，希望能在技术上面上升到测试开发，能自己独立开发测试平台及工具，为公司带来更大价值。
加班我觉得主要是两种情況。
第一种，工作效率低不得不通过加班来完成工作任务，像这种加班我会尽可能提高自己的工作效率，不做无意义的加班。
另外一种，像发版日、紧急任务需要加斑这种情況的加班会义不容辞。
首先，单元测试开发来做，另外开发结束后，进行冒烟测试，冒烟覆盖了一部分测试用例，如果冒烟通过，那很多测试也就解决了。
看视频入门，对原理有不懂的地方看书
《软件测试的艺术 (原书第 3 版) 》
《高性能 MySQL》
《Java编程的逻辑》
一、使用的是有线网线
1、路由器数据堵塞，一般重启路由可以解决；如果重启仍不能解决，可能是运营商的问题了，及时电话咨询；
2、自身电脑问题，连接有线网的情况，这种情况很少见；
二、连接的是无线网
1、路由器问题，重启路由试试；也不排除线路问题；
2、无线接收器问题，看灯闪烁是否正常，可以尝试拔队，重新插上；
3、也可以尝试把无线禁用，然后重新开无线网络；
4、重新安装无线网驱动试试；
(我答的是 1.DNS坏掉了,修改自己的ip为8.8.8.8试试 2.网断了 3.服务器拒绝访问 4.请求/响应在网络传输中途被劫走)
（即不要一有什么事就提bug，像网页打不开你也提bug，至少你要问题定位分析过后，要提一个具体是什么原因导致的bug）
软件问题分析的两个方向（软件缺陷的方向，并不一定软件错误就说bug，软件配置方向也是bug）
业务方向：用户需求（显性+隐形）：使用用户场景
技术方向：软件架构（系统设计+环境部署）：运用IT技术
问题描述：通过 Windows上的浏览器，访问部署在 Linux系统的Web网站，发现网站无法访问？
・实战操作：该如何分析与定位问题？
步骤：
网络（客户端+服务端）：先看看浏览器端有没有连上网，能不能打开其他的网站
是否设置代理（浏览器有没有代理上网）
査看DNS解析正确？（开其他的网站看一下，或是直接打ip上去看看）
网址是否正确，有没有urI重定向、换其他浏览器
数据库
能不能ping通服务器lP
【以上鉴别完客户端没有问题】
web文件是否存在（cd /var/www/html，进到文件夹里看看有没有你的html）
服务器本机能不能打开（用服务端的浏览器打开网页看一下）
看看能不能ping通外面（ping一下百度看一下）
【以上鉴别完基本的服务端没有问题】
在这个过程中会不会有东西丢失了？抓个包看一下，可以用tcpdump -v port 80：看大于小于号就行，左边是客户端windows，右边是服务端linux，看到抓到的消息全都是>号，说明只有win给linux，没有linux给win，即只有请求，没有响应
现在可说明，是操作系统（进阶的服务端）阻碍了数据的出去，即防火墙
看看防火墙有没有运行：service iptables status，把防火墙关了试一下看看
确定是防火墙问题后不能直接粗暴地关闭它，因为会有安全问题
你改一下防火墙的规则即可。但又不能直接在命令行敲，因为服务器重启你这条规则就没有了。加到防火墙的配置文件里即可
现在你可以提bug了，运维或开发人员没有把防火墙设置好，导致服务器在外面访问不了
参考：添加链接描述
其他：
错误代码（网页显示什么错误代码）
端口号检査（80号端口）
服务器日志信息
