软件测试基础
1:什么是软件
软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
系统软件:系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows, 数据库SQL-Server,驱动程序，java语言系统编译环境等。
应用软件:计算机用户为了解决某些应用的问题而购买、开发或研制的各种程序或软件包。如APP， QQ,微信等。（会有具体的应用场景）
2:什么是软件测试
百度的定义:为了发现程序中的错误而执行程序的过程。
那么对于我们，我们应该怎么去定义这个问题呢?
为了发现软件的错误而操作软件的过程，比如说发现微信的问题，就要去操作它，在不同的场景去操作它才能发现有没有问题
it里面把每一个软件称为产品，
3：软件测试的分类
如果真要认真的考虑软件测试这个职业，对分类了解清楚，也会对自己之后职业方向选择是个不错的起点。
按测试执行阶段划分:
单元测试（代码层面）、集成测试（功能测试）、系统测试（产品完成了称为一个整体的系统再去做测试）、
验收测试（产品完成之后由软件测试工程师或者用户对产品 进行验证） 正式验收测试、Alpha测试、 Beta测试
按测试技术划分:
白盒测试（代码）、黑盒测试（无代码）、灰盒测试（两者之间，）
被测试对象是否运行划分:
动态测试（程序是否再运行）、静态测试(不运行产品进行文档检查、代码走查、界面检查)
按不同的测试手段划分:
手工测试、自动化测试
按测试包含的内容划分:
功能测试（产品或者软件的功能进行测试）、
界面测试（界面的颜色，按钮颜色是否正常）、
安全测试（漏洞，后门，能不能被攻击，能不能修改用户密码等）、
兼容性测试（一个软件能不能在各种系统里面使用和不同浏览器等上面使用）、
易用性测试（对于用户来说操作是否简单，容易理解，）、
性能测试、
压力测试、
负载测试、
恢复测试（当我的软件出现问题的时候，最长多久时间能够自己恢复过来，需要对产品和系统进行攻击，
dos攻击ip攻击，如果攻击被垮了什么时候能恢复过来，什么时候切到备用的服务器上去）
其他测试:
冒烟测试、
回归测试、
探索性测试/自由测试(测试思维)
4：软件的生命周期
软件测试服务的对象是软件和产品，
软件生命经过下面六个阶段：
一：问题的定义及规划（市场调研）
主要确定软件的开发目的及其可行性。制定项目总体开发计划。
二、需求分析（确定这个产品可以做了之后，要做哪些功能，哪个功能具体是那样的，产品的demo，产品大概是什么样子）
在确定软件开发可行的情况下（经过市场调研了），对软件需要实现的各个功能进行详细分析，
明确客户的需求，输出需求规格说明书初版(原型图)，提交评审
三、设计
把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
概要设计:主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务
详细设计:对概要设计中表述的各模块进行深入分析等，其中需要包含数据库和表的设计说明。
四、编码
按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
五、软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
测试的方法主要有白盒测试跟黑盒测试两种。建立详细的测试计划并严格按照计划进行。
单元测试:主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块的测试，
也有具体到类，函数、方法的测试等。 单元测试一般是开发来完成
集成测试:单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递。
比如说注册和充值这两个功能是否能够连通
不同的功能模块之间，他们之间如果有功能的关联，看一些功能是否可以走通的--集成测试
系统测试:把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，
在系统中运行是否存在漏洞等。根据测试用例，进行完整的系统测试。
软件所有的研发完毕了，不针对单个功能进行测试，所有的功能已经成为一个完整的产品了我们去进行测试（根据测试用例进行完整的测试）
验收测试:主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。
用户对软件进行验收。
六、运行维护
纠错性（用户在使用产品过程中发现了问题，需要对他进行修复），
改进性（用户觉得这个软件不好用，需要改善一下才更好用 去改进））
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。
要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面。
比如微信不停的更新版本，修复bug，开发一些新的功能，
只要软件还在运行，测试就不能停，看软件是否正常运作，如果用户提出问题，需要去复现一下问题
测试得工作体验在和六个阶段
5：软件测试的工作流程
目前讲究测试左移：就是测试工作提前，以前是提交了代码和程序之后进行测试，
现在从开发开始编写计划的时候我们测试就介入写测试计划。然后根据计划分模块分工作
然后根据功能去写需求，根据需求说明书写用例，用例评审，部署测试环境，冒烟测试（主流程测试，主流程都gg的话那说明软件有问题，不需要继续测试），
（冒烟测试通过了）正式测试，提交bug管理系统并追踪（让开发进行修改），继续测试，测试通过，发布上线，测试报告
开发 测试
1:需求分析
2：需求评审
3：开发编写开发计划 - 测试编写测试计划
4：概要设计，详细设计 编写测试用例
5：编写代码自测 用例评审
6： 提交测试 部署测试环境
7： 冒烟，正式测试
8： 提交bug并追踪
9： 测试通过
10： 测试报告
11： 发布上线
6：软件测试基本流程：
1：测试需求分析阶段:阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议 熟悉软件产品
2：测试计划阶段:主要任务是编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围
(来自需求文档、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，
一 般由测试负责人编写，当然我们可能也会参与相关的评审工作。
人力物力的安排，不提前安排好人力有限，时间有限那么工作就会做的不好，计划一定要提前做的 出一个软件测试计划
3：测试设计阶段:主要任务是编写测试用例，会参考需求文档(原型图)、概要设计、 编写测试用例
详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
用例就是覆盖用户的所有使用场景：所有用户可能用到的操作和功能和数据都去模拟一下，
确保用户使用不出现问题 因为不能确保全覆盖，需要评审
4：测试执行阶段:首先搭建测试环境，执行预测(冒烟)，以判定当前版本可测与否，
如果预测通过，正式进入正式测试（根据测试用例执行测试），遇到问题提交Bug到缺陷管理平台，
并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束。----- (完善测试用例)
5：测试评估阶段:出测试报告,对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线。
（测试了哪些功能，有哪些人参与了，修复和发现了多少个bug，还遗留了多少bug，有没有一些上线的风险）
开发人员的工作流程：需求分析——>得知功能组成及设计软件结构、数据结构(概要设计、详细设计)——>编写代码——>单元测试
——>代码审查——>打包提交测试部——>等待测试提交bug——>修复bug——>等 待测试回归bug
——>... N轮——>版本上线——>面向用户使用
测试人员的工作流程: 开项目评审会——>领导指定测试计划——>熟悉项目，查看文档，体验产品——>需求分析——>编写测试用例
——>评审测试用例——>搭建测试环境——>等待开发研发完成，提交测试包进行测试(酱油期)
——>部署测试包——>冒烟测试(预测)——>执行测试用例——>bug跟踪 处理(提交及回归bug) ——>... N轮测试
——>版本上线——>面向用户使用
7：软件测试用例设计方法：
一：等价类：
等价类划分法的概念
定义:等价类划分法是一种典型的、重要的黑盒测试方法，是指某个输入域的子集合。在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。
划分:等价类划分有效等价类和无效等价类。
实例1：比如成年人的定义收>=18岁：
有一个系统根据人的年龄去判断是否成年？怎样设计等价类
<18未成年：输入：17，16，15，5，4，3，2，1，0都是一样的效果，都是未成年，所以小于18的整数的就算一个等价类
这个范围内的所有数据输入的结果都是一样的，所以不需要穷举：1输入到18
不需要这样测试，只要判断有一个年龄符合就可以了
>=18成年人：18，19，20，21，22，88，99，100，120 这个也不需要穷举，
所有大于等于18的整数是一个等价类，这个范围里面输入的数据导致的结果都是一样的，
有效等价类：所以两个等价类：这两个等价类叫有效等价类，就是我的系统可以接受这样的数据（输入的结果的数据是起作用的，系统是支持的：有效等价类）
无效等价类： 200无效的，假设人的寿命120，大于120不行小于等于0也不行，这些算无效等价类，
输入的数据是无效的不存在的，不支持你输入这些数据（输入的数据是无作用的，系统不支持的）
一般涉及到数字输入的时候：对他进行等价类的划分
实例二：微信红包：0.01-200之间
一：按数据范围划分:
有效等价类: 0.01-200(1)
无效等价类 : 小于0.01 (2) 大于200 (3) 0.01-200区间小数点后超出2位的值(4)
二：按数据类型组成划分:
有效等价类: 数字(5)
无效等价类: 非数字类型，比如：英文、中文、特殊字符、html标签... (6)
三：按是否为空划分:
有效等价类: 不为空(7)
无效等价类: 为空(8)
一个非常小的可以设计几组进行数据测试，8组数据数据完成测试
二：边界值，边界值分析法概念
定义:边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。边界值分析的基本.
思想:正好等于、刚刚大于、刚刚小于边界的值作为测试数据。0，0.01、 200（三个点）
注意: 0是一个特殊值，我们在考虑边界值的时候同时也要考虑这个特殊值。负数
边界值的作用:人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，
而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误!
开发程序设计的过程中很多只考虑等价类里面的数据是不是正常，对边界少有判断，
所以很容易出现很多问题，输入边界值可能出问题
实例一：微信红包:最小金额0. 01元，最大金额200元
边界值: 0 0. 01 0.02 199. 99 200 200. 01,
特殊值:负数
微信红包：
数字上来划分
有效的: 0.01-200
无效： 小于0.01 大于200 0.01-200区间小数点后超出2位的值
边界值： 0 0.01 0.02 200 199.99 200.01（按照正好等于，刚刚大于，刚刚小于来考虑边界值）
边界值使用场景：什么情况下才会使用边界值
边界值一般涉及到数字的时候就会用到，尤其重要，涉及到数据就一定考虑边界值
实例二：163的邮箱注册的时候填写邮箱地址
要求： 1：必填
2：6-18个字符，可以使用字母，数字，下划线组合，需要以字母开头（使用等价类和边界值来设计测试用例）
结果分析：
等价类划分：
长度划分：
有效等价类 ：6<= x <=18
无效等价类：x<6 x>18
特殊值： 0
内容划分：
有效等价类：1：全是字母 2：字母+下划线 3：字母+数字 4：字母+数字+下划线
无效等价类：1：全是下划线 2：全是数字 3：数字+下划线 4：除数字字母下划线以外的内容，特殊字符（@#$），中文等都是无效的
是否必填：
有效等价类：非空
无效等价类：空
边界值划分： 跟数字有关的时候就需要用到边界值（6-18个字符）
6 18 7 19 5 17（这就是边界值，刚好等于，刚好大于，刚好小于）
还需要补充这三组数据来测试是否考虑到边界值的情况
三：错误推测法，从错误操作层面推测是不是正常的
错误推测法概念：
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
它的要素共有三点：
分别为:经验、知识、直觉。关于如何使用的问题，我们提炼出两点:
列举出程序中所有可能有的错误和容易发生错误的特殊情况;
根据他们选择测试用例
我们用错误的操作去验证我们软件以及程序的健壮性，我们不可能只考虑到用户正常的操作，还要考虑用户的非正常操作，
因为每个用户操作可能都不一样，可能不正常去操作软件
用户傻逼，可能瞎几把操作遇到问题
简单的概括为:错误推断法是明知不可为而为之
实例一：某平台登录页面
既然是用错误猜测法，那么我们首先列出可能导致结果出错的情况，如下:
1、用户名跟密码的对应关系不对应的情况进行验证（对应知道可以登录成功，那么不对应的话什么情况）
2、账号或密码为空（为空）
3、用户名和密码，如果太短或者太长，应该怎么处理
安全性，密码太短时是否有提示 格式+满足格式要求但不是正确的（超长或者过短的）
4、用户名和密码中有特殊字符(比如空格)，和其他非英文的情况(是否做了过滤)（如果用中文呢，）
5、用户名和密码前后有空格的处理(过滤)
6、错误登录的次数限制（错误只能登录三次，如果超过三次呢，有没有冻结用户）
7、提交登录时，网络异常（没网提交会出现啥问题呢）
8、多次点击提交操作，只能被执行一 次
登录一般只需要点击一次，如果我点击多次呢，充值只能点一次，如果我点多次呢，发视频只要点一次，我要是点多次呢
明知不可为而为之，需要熟悉业务和参数，知道这样做是不对的，
但是用户不知道，充分考虑到用户的一些非法操作，然后用系统提醒用户这样操作不合理的
来提高用户的体验以及提升软件产品的健壮性，不管用户做什么操作，
都会有一套机制去提醒用户这样操作是不可以的，您应该怎样操作
每种方法设计出来的用例都是有重叠的，这没有关系，这样只会让用例越来越完善，越来越体系，测试就会越来越全面，不会出现漏测得情况，
四：场景法
场景法概念：
什么是场景法，通过场景描述的业务流程(业务逻辑)，也包括代码实现逻辑，设计用例来遍历场景(图上面所有路径)，验证软件系统功能的正确性。
考虑所有的业务路径和业务场景来验证软件系统功能得正确性
一个软件考虑用户的使用场景，每个场景都会去考虑不同分支去处理，模拟用户使用得各个场景，---场景法
如何使用场景法
画出流程图
矩形:表示步骤(操作、结果)
菱形:判断-是、否
注意:场录法的重点是测试流程(场景)，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试，
只有单个功能点测试过了和流程测试都测试过了，才算是充分的测试，还有其他地方需要进一步用别的方法进行测试，也是有可能的
当所有的测试过后才能说进行了一次比较完整的测试，
怎么体现场景法：
实例分析：根据场景画流程图，
矩形:表示步骤(操作、结果)，
菱形:判断-是、否，T表示ture，这个条件成立的时候 F表示这个条件false，这个条件不成立的时候，箭头表示流程走向
1：根据正常流程：主
2：根据异常流程：备用（非常规操作，非常规场景操作） 场景是很难全面覆盖的，出乎岂料的场景
普通流程图四条逻辑
true true
输入a，b，x三个值——>经过判断a<5and b=5——>a=2 or x>2 ——>输出a，b，x 主流程
true false
输入a，b，x三个值——>经过判断a<5and b=5——>a=2 or x>2——>x=x+1——>输出a，b，x 备用流程
false true
输入a，b，x三个值——>经过判断a<5and b=5——>x=x/a---a=2 or x>2——>输出a，b，x 备用流程
false false
输入a，b，x三个值——>经过判断a<5and b=5——>x=x/a——>a=2 or x>2——>x=x+1——>输出a，b，x 备用流程
因为true和false的走法不同。一共四个场景：TT TF FY FF
TT主流程
TF FY FF 备用流程
根据判断条件准备数据
四种测试用例组合编写得才能组成完整得用例，但是往往测试用例可能重复，去掉就行，这样才能不会在整个测试过程中出现漏测得情况，
给个业务场景，使用非常清晰得流程来展现得话，需要自己去画这个流程图（流程图的元素：矩形:表示步骤(操作、结果)，菱形:判断-是、否）
8：给出一个登录/购物车/支付页面，之间让你尽可能设计多的用例？
京东，淘宝，等电商平台，
设计用例：
分模块：
登录模块：正常登录（输入正确的用户名和密码） 异常操作（用户名or密码错误 为空 输入特殊字符 ）
购物车： 最多可以添加多少商品？ 可以增减删商品？ 可以修改选择了的商品的属性（比如说颜色，size尺寸）？
异常操作：过期商品的添加？ 售罄的商品能不能添加？ 购物车里面有优惠价会不会显示？ 打折会不会显示
支付：正常操作
异常操作：
tips：支付方式？（花呗，支付宝，银行卡还是余额） 余额不够的时候支付？ 银行卡不够的时候支付？ 代付？
根据这些去设计
场面就算场景法考虑问题，正常的操作和异常的操作，场景分出来之后根据等价类，边界值，错误推测法去做这个事情，
比如异常的操作用的过期的商品，售罄的商品，并不是所有的用例都支持等价类边界值去做的
模块合成在一起进行测试：
登录后——>添加商品——>支付能不能走通
9:软件需求分析
测试需求是什么?
测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求 要测什么
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求
比如说一个购物网站，具备注册、登录、浏览商品、购买商品、支付等功能。
那么在这个例子里面，注册、登录、浏览商品、购买商品以及支付等功能就是这个网站的需求。
对于这些软件需求，在软件需求说明书文档中，会有详细描述。像这个登录功能，
会详细描述登录是否支持老用户登录、是否支持手机号码快捷登录、第三方账号登录等等，
每个功能模块的业务流程、细节都会体现在软件需求说明书里。
哪些业务逻辑，功能场景需要测试，然后才能写用例，
需求分析考虑点：
登录功能： 输入输出有什么要求，有什么限制，有没有约束，对他进行验证这就是功能测试
分析各个功能模块的业务顺序，还有各个功能模块之间传递的信息和数据，对存在功能交互的功能给出对应的验证功能
如何进行软件测试需求分析
测试需求分析的主要目的:依据需求文档提取测试点，根据测试点来编写测试用例
这里重点讲一下测试点分析:
通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容: ( 功能测试)
通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容; (功能交互测试)
考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界面的验证，注册账号的唯一性验证(界面、易用性、兼容性、安全性、性能压力)
10：特殊场景下软件或者项目如何作需求分析
什么是特殊情况： 需求一般都是在软件需求规格说明书（或者是原型图，需求问题）上面编写的
无产品需求使用说明书
产品/软件暂时没有成品
遇到上述情况，我们怎么提前做好准备工作
破解方法：
1：需要知道做的是什么类型的产品（金融的，电商的，考试系统，小程序）
2：确定好产品的类型后。预估比较有难度的测试点：在哪些地方，比如电商，支付，购物车这块--提前列好可能支持几种方式
3：通过平常的会议，以及与同事的沟通去进一步了解自己的产品，提前去了解这个需求
4：找竞品去做功能模块的的分析
知道这个去做需求分析，从三个方面：功能，交互，隐形需求---去规划
这种特殊情况去写详细的测试用例是很难达成的，就是要别的方式去做，测试点的罗列（知道哪些地方要测试，把这个点一个个列出来
功能模块和一些比较重要的点列出来，后续根据这个清单去checklist---一步步去做）
11：软件测试用例的编写
什么是软件测试用例（testcase）
测试用例（testcase）是为了项目需求而编制的一组测试输入，执行条件，以及预期结果，以便测试某个程序是否满足客户需求
可以总结为：每一个测试点的数据设计（输入哪些数据）和步骤设计（先输入什么再操作什么）
登录这个测试点：用例设计考虑的方面，等价类
有效等价类： 正确的用户名和密码 测试数据
无效等价类：错误的用户名，错误的密码，不输入（都为空），输入特殊字符（%……&*） ，
测试用例的八大要素
1、用例编号: 产品名-测试阶段(st it uat) -测试项--0002 第几条用例，一般有一些规定，产品名，测试阶段，测试项
2、测试项目: 对应一个功能模块(细分功能) 对应哪个模块（登录，注册）
3、测试标题: 直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复 测试什么东西
4、重要级别: 高/中/低
5、预置条件: 需要满足一些前提条件，否则用例无法执行 前提条件
6、测试输入: (数据) :需要加工的输入信息，根据具体情况来设计(跟步骤结合起来定要具有指导性意义)
7、操作步骤: 明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
8、预期结果: 根据预期输出比对实际结果，来判断被测对象是否符合需求。(预期结果唯一，不能出现“是否或者”) （期望得到什么结论才是符合要求的，预估结果）
9、实际结果:
实例：根据lemfix社区的搜索功能编写用例：使用excel编写如下
输入字体‘搜索本站内容’文字就会消失
12：软件测试用例测试点的提炼
什么叫软件测试点
测试点：其实我们做需求分析的时候，就会进行一个罗列，以便于我们自己梳理清楚所有需要测试的点。
那么，什么时候需要用到?
需求分析，梳理测试的功能点时（需求分析的时候，罗列测试点）
写用例之前
任务紧急，来不及写用例时
测试点：没有具体的操作步骤和数据，就是一个大致测试的一个点，一个路径一个思维
写与不写的区别? (可以有效的帮我们确定测试点，不会产生漏项)
实例：
项目非常紧急，需要多功能做测试，为了防止出现功能漏测的情况，请根据下图罗列号测试点
测试点：
1：评论功能
输入内容
内容的形式：中文，英文，汉字，数字，特殊字符等各种
内容的长度：
是否有违规的内容：
表情/主体/@功能
2：内容显示
是否正常展示所有的内容：(上面输入发表之后就要顺便检查一下)
热度显示/时间排序/，点赞数多的显示再前面
评论数的变动是否会增加，增删会不会影响评论数的改动
3：互动
点赞（点赞和取消点赞）
分享/转发：是不是连着音乐，心情和评论一起转发了
回复（能不能回复别人的消息，最多回复对少条，）
4：跳转功能，
比如说跳转到用户页面
跳转专辑页面，/歌曲信息/歌手信息
罗列测试点，1.2.3.4一条条往下测试，不会漏测出现太多差错， 特殊情况下先去把测试点罗列好，
13：管理bug和bug追踪
软件的Bug,狭义概念是指软件程序的漏洞或缺陷，
广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等
bug就是和预期结果不一致/跟需求不一致/跟用户的要求不一致的所有的情况都是可以称之为bug，并不是单纯的代码错了就是bug？
我们的职责就是，发现这些Bug,并提交给开发，让开发去修改。
bug的定义
软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、
或与需求文档存在差异的功能实现等。
我们的职责就是，发现这些Bug,并提交给开发，让开发去修改。
跟我们的测试用例预期结果不致/跟需求不一 致/跟用户的要求不一致的所有的情况都可以称之为bug!并不是单纯的说:代码错了就是bug?
14：bug管理的工具禅道的使用：如何在禅道提交一个bug
所属产品（多个产品，多个项目，标记好）
所属模块（登录还是注册）
所属项目（1期项目，2期项目）
影响版本（发现的问题影响的是哪个版本1.0，还是3.0还是所有版本）
当前指派（bug指派给谁，谁去修改）
bug类型（代码错误，操作系统什么，浏览器版本） -----什么类型的错误，功能类型还是代码的错误还是一些界面上的问题，还是兼容性的问题，
bug标题（简单的话语来描述出现了什么问题）
严重程度（默认3）
优先级（默认3）
重现步骤，需要在里面写的非常清楚怎么操作然后出现了这个问题的，操作的步骤，当时出现这个问题的一些数据，出现了什么结果，期望值是什么
上面填写好了之后直接给到开发，----bug就会被开发收到，进行更改，更改完了后选择已修复，通知到测试
bug生命周期，发现bug需要提交让开发进行修改
15：如何管理和跟进bug：bug生命周期，发现bug需要提交让开发进行修改
1：发现bug
2：提交bug
3：指派给对应的开发
4：研发确认bug 否、研发确认这个不是缺陷，提交重复了，
无法重现 需要回归验证一下这个bug，验证完了之后决定是否关闭bug还是打开bug
5：研发是否解决（跟进bug） 否、研发提出不予解决，延期，验证bug是不是特别重要，验证优先级是的话不能关闭，要求开发改进 回归验证bug
6：回归验证bug
7：是否通过验证 否、没有修复bug 重新打开bug，告诉开发bug没有修复，重新进行上面的流程
8：验证通过就关闭bug
不是提交完了就完事了，必须去跟进，看开发有没有改，如果开发改了需要验证。改好了关掉。
没改好让开发继续改，开发不改尽需跟进（不改的原因是什么，bug不重要还是
bug重复了还是bug根本不存在，分类去进行再次确认，任何再去和开发进行再一步的沟通）-----如何管理bug，以及bug的管理周期，生命流程
16：如何进行web的兼容性测试
兼容性的测试的介绍
浏览器兼容性问题又被称为网页或网站兼容性问题，是指因为不同的浏览器对同段代码有不同的解析，造成页面显示效果不统的情况。
大多数情况下，我们的需求是，无论用户用什么浏览器来查看我们的网站或者登陆我们的系统，
都应该是正常显示效果，并能正常操作。这样才能够给用户更好的使用体验
大型旅游网站：
产生浏览器兼容性问题的原因:
因为不同浏览器使用内核及所支持的HTML语言的标准不同 ，(标准通用标记语言下的一个应用)等网页语言标准不同;
以及用户客户端的环境不同(如显示器的分辨率不同)造成的显示效果不能达到理想效果。最常见的问题就是网页元素位置混乱，错位。
网页元素（输入框，按钮，链接，颜色的显示）
内核:决定了浏览器如何显示网页的内容以及页面的格式信息
兼容性测试：
操作系统的兼容性，
设备的兼容性（手机不同操作系统的手机，不同品牌，ipad，平板），
操作系统兼容性（windows。xp，linux）
测试过程中接触得比较多得浏览器以及内核
ie内核 360，搜狗，傲游，搜搜都是使用得ie内核，
webkit内核ie内核 手机浏览器使用ie内核和webkit内核（andriod，ios）
CecKo内核 firefox
Presto内核 Opera浏览器
浏览器兼容性测试常见问题
1：浏览器兼容性测试场景：
什么时候才需要做这个测试，客户有这个需求，兼容性测试一般考虑5.6款浏览器去做：谷歌、火狐、ie8-9-11、 QQ、苹果，用的比较多
考虑客户要求的产品对于使用的用户的场景，用的比较多的浏览器是哪些，考虑到----测试需求不能想当然，了解用户使用环境下得浏览器是那种
想要去做兼容性测试没有指定浏览器，这时候通过内核+使用量去选择5-6款浏览器，谷歌、火狐、ie8-9-11、 QQ、苹果
根据 http://tongji.baidu.com/data/browser查看不同浏览器的使用情况：根据这个做个预测，哪些需要进行测试）
1：需求(客户)有制定必须要测试:火狐、IE9、谷歌、Qe
2：有要求做浏览器兼容性测试，但是无指定浏览器:这时候内核+使用量选择 5、6款浏览器
谷歌、火狐、ie8-9-11、 QQ、苹果
17：浏览器兼容性测试如何进行测试?任务如何分配?（兼容性测试过程中主要关注界面是否错乱，错位，）
1：在功能测试过程中，同步关注界面，是否错乱、错位
2：选择- 谷歌、火狐、ie8-9-11、 QQ、苹果 这些浏览器之后对功能进行一个分配，比如说电商项目：
注册登录购物车选择谷歌，ie8
收货地址选择火狐，ie9
个人信息选择qq，ie11
商品列表选择苹果的safiri
每种浏览器交叉分配，大型网页兼容性测试，很少能做到均匀分配，又做到每个浏览器测试的，把一些功能出现问题的时候
比如说出现问题，ie8和谷歌上面出现了问题，一旦出现了这种兼容性问题，那么别的人也同步验证一下，别人的浏览器是不是也有同样的问题存在
测试兼容性问题：交叉分配，根据功能模块去分配不同的浏览器，这样保证一定的覆盖率，也能快速完成测试任务
关键词:注册登录、购物车一谷歌， IE8
其他的功能界面，凡是能点击的位置点击下
A:我的收货地址一火狐，ie9
B:个人信息88，IE11
C:商品列表一 苹果
18：有客户反馈说在世界之窗浏览器上面有bug (兼容性)，公司一-般如何处理/解决?
先评估使用率，如果用的人多就解决;用的人少就建议引导客户更换浏览器，少数用户出现这个问题，耗费大量人力解决非常浪费资源
19：前台访问界面、后台管理平台，是否都要做兼容性测试?
都有访问页面，都是访问网站:一个用户使用，一个管理员使用
前台要做，后台基本不做 使用谷歌浏览器
前台 ：界面，用户可以操作的界面
后台：项目或者平台的管理者对数据进行管理，比如，买家看到的淘宝页面都是前台
卖家看到商品的购买信息：后台
前后台需要不需要做兼容性测试：根据需求，根据用户来的评估去做，前端用户用的比较多，优先去把前台的兼容性做好
后台根据用户的使用量去做，
20：一个电脑上无法安装这么多浏览器（比如ie8.ie9，）怎么解决
使用工具替代，替代我们做一些兼容性测试，不需要安装那么多浏览器也可也帮忙完成兼容性的测试
IETester
Spoon Browser Sandbox
Adobe Browserlab: https://browserlab.adobe.com/index.htm
Browsershots:http:/ /browsershots.org/
21：测试用例和其他类型测试的联系
软件测试，软件测试工作流程，软件测试用例设计的方法，软件测试如何写用例，如何管理bug，这些
功能测试，接口测试，自动化测试，性能测试，测试开发
接口测试 用例设计（测试哪些模块的接口，这些接口需要设计多少用例，哪些用例） 接口脚本
自动化测试 用例设计（功能自动化测试，依据用例设计脚本完成自动化测试） 自动化脚本
性能测试 用例设计（需要哪些场景，需要哪些数据，需要哪些前置条件，预期结果，比如登录测试需要知道：并发数，场景，启动时间多少） 性能场景脚本
知道产出，响应时间，tps，cpu，内存使用率，体验在用例设计里面，只是不同地方是
接口测试：接口测试用例 自动化测试：自动化测试用例 性能测试：性能测试用例
这些测试用例都是建立在之前学的测试用例的基础上去做的---功能测试用例是基础
测试用例和其他类型测试联系很密切，有了测试用例才会又后续的结论，脚本，产出，
用例设计很重要
22：如何进行其他类型的测试
有几种类型?
接口测试、性能测试、自动化测试
如何进行测试?用什么工具? ( 具体见分解)
接口测试：
流程：需求分析——>测试计划/任务划分（任务划分，人力资源，需要一些测试设备的计划，功能的划分）——>
用例编写 ——>环境部署（视情况而定） ——>选用工具 ——>开始测试
工具： jmeter
postman
soapui
其他在线工具
编码
需要掌握的其他知识点： 数据库
服务器相关：测试环境部署
日志查看
linux命令（服务器相关，测试环境部署，日志查看都需要掌握linux命令，操作服务器）
性能测试:
流程：需求分析——>测试计划/任务划分——>用例编写/方案设计/场景设计——>选用工具——>开始测试 ——>
......结果分析，出性能测试报告，再次回归的性能测试
工具： jmeter --支持并发，安装启动容易，开源不收费
loadrunner --工业级，要钱
编码 ----代码跑
需要掌握的其他知识点： 数据库
服务器相关：测试环境部署
日志查看
linux命令查看cpu内存资源等各种情况（服务器相关，测试环境部署，日志查看都需要掌握linux命令，操作服务器）
自动化测试：
流程：需求分析——>用例编写/方案设计/场景设计——>选用语言——>编写脚本——>执行脚本
选择语言： python --脚本语言，简单
java
需要掌握的其他知识点： 数据库
appium
selenium
