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:软件需求分析
测试需求是什么?
测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求 要测什么
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求
比如说一个购物网站，具备注册、登录、浏览商品、购买商品、支付等功能。
那么在这个例子里面，注册、登录、浏览商品、购买商品以及支付等功能就是这个网站的需求。
对于这些软件需求，在软件需求说明书文档中，会有详细描述。像这个登录功能，
会详细描述登录是否支持老用户登录、是否支持手机号码快捷登录、第三方账号登录等等，
每个功能模块的业务流程、细节都会体现在软件需求说明书里。
哪些业务逻辑，功能场景需要测试，然后才能写用例，
需求分析考虑点：
登录功能： 输入输出有什么要求，有什么限制，有没有约束，对他进行验证这就是功能测试
分析各个功能模块的业务顺序，还有各个功能模块之间传递的信息和数据，对存在功能交互的功能给出对应的验证功能
如何进行软件测试需求分析
测试需求分析的主要目的:依据需求文档提取测试点，根据测试点来编写测试用例
这里重点讲一下测试点分析:
通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容: ( 功能测试)
通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容; (功能交互测试)
考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界面的验证，注册账号的唯一性验证(界面、易用性、兼容性、安全性、性能压力)
原文：https://www.cnblogs.com/yuanwt93/p/14509338.html