B/S 只需要操作系统和浏览器就行，可实现跨平台，客户端零维护，个性化能力低，响应速度慢。
C/S 响应速度快，安全性高，一般用于局域网，因为要针对不同的操作系统需要针对性的开发，并且维护成本高
超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。
1，get是不安全的，因为在传输过程中数据被放在请求的URL中；post所有操作对用户来说都是不可见的。
2，get传输量小，这主要是因为受URL长度限制；post传送的数据量较大，一般被默认为不受限制。
3，get限制form表单数据集的值必须为ASCII字符；而post支撑整个IS010646字符集。
4，get执行效率却比post方法好。Get是form提交默认方法。
1、cookie数据存放在客户的bai浏览器du上，session数据放在服务zhi器上。
2、cookie不是dao很安全，别zhuan人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
cookie 和session 的联系：
session是通过cookieshu工作的
session和cookie之间是通过$_COOKIE[‘PHPSESSID‘]来联系的，通过$_COOKIE[‘PHPSESSID‘]可以知道session的id，从而获取到其他的信息。
软件测试的目的是为了确保软件产品的最终质量，在软件开发的过程中对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范、实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。
1，测试显示软件是否存在缺陷
2，穷尽测试时不可能的
3，测试尽早介入
4，缺陷集群性
5，杀虫剂悖论
6，测试活动依赖于测试内容
7，没有错误是好是谬论
五个阶段：单元测试、集成测试、系统测试、验收测试、回归测试
单元测试是在软件开发过程中对单个功能进行的测试
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，进行集成测试。测试重点是模块间的衔接以及参数的传递等。
兼容性测试、安装测试、功能测试、协议一致性测试、性能测试、压力测试、容量测试
? α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见
在β测试中，采用的细节、数据和方法完全由各测试员决定：测试员负责创建环境，选择数据，并决定要研究的功能、特性或任务；
测试员负责确定自己对于系统当前状态的接受标准。
β测试由最终用户实施，通常开发组织对其很少或不进行管理。
验收测试：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者：用户，还可能有软测工程师等。
白盒为自动化测试测试人员编写测试脚本进行测试用于测试人为无法测试到的功能
黑盒为手动测试（纯功能测试）手动点点点
灰盒是介于白盒和黑盒之间
? 冒烟测试是对主要功能进行测试确保一切都已正确配置并可按预期运行为正式测试前验证是否为产品或系统的主要需求或预置条件是否存在漏洞
? 在测试策略制定阶段，制定回归测试策略
? 确定需求回归测试的版本
? 回归测试版本发布按照回归测试策略执行回归测试
? 回归测试通过关闭缺陷跟踪单
? 回归测试不通过，缺陷跟踪单返回开发人员，开发人员重修修改问题，再次提交测试人员回归测试
? 全部回归将整个项目全部回归测试不区分正确和错误代码，部分回归将错误的代码进行回归测试
? 1、对测试范围进度量 2、对处理分支进行度量 3、对需求业务的场景进行度量 4、明确其功能对应的输入、处理和输出 5、把隐式需求转变为明确。
1、测试的目的是为了发现尽可能多的缺陷，不是只为了说明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
有了详细的产品需求说明书后，在系统设计阶段就应该写系统测试方案，系统测试计划并开始详细设计测试用例了。
需要编写测试计划的人员有：项目经理、测试经理、测试人员，他们将根据每个所处的位置编写相应的测试计划
1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间
2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等
3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等
1、 测试目标：对测试目标进行简要的描述。
2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、 质量目标：制定测试软件的产品质量目标和软件测试目标。
6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、 测试策略：制定测试整体策略、所使用的测试技术和方法。
9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的
Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12、 风险分析（评估）：需要考虑测试计划中可能的风险和解决方法。
第一类标准：测试超过了预定时间，则停止测试。
第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。
第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础
第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。
第五类标准：根据单位时间内查出故障的数量决定是否停止测试。
需求风险、测试用例风险、缺陷风险、代码质量风险、测试环境风险、测试技术风险、回归测试风险、沟通协调风险、研发流程风险、不可预估风险
测试编号、测试分类、测试模块、测试输入、预计结果、实际结果、测试时间、测试人员、是否通过
优先级一般都是和缺陷的严重程度对应的。
高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。
首先，确认需求
第二，梳理需求，确认测试范围
第三，制订测试计划
第四，根据测试计划设计测试用例
第五，后续的执行测试步骤
做好测bai试用例工作的关键是要充du分考虑测试计zhi划的实用性，坚持dao5W1H的原则zhuan，采用评审和更shu新机制以及测试策略。要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。要坚持“5W1H”的原则，明确测试内容与过程。采用评审和更新机制，确保测试计划满足实际需求。因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。测试策略要作为测试的重点进行描述。测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素
? 排队-->运行中-->阻塞-->跳过-->通过-->失败-->警告-->关闭
等价类划分
多用于输入框：注册/登录
边界值
多和等价类划分结合使用，有边界限制的:注册的密码长度（掌握上点和离点的取值）
场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交表
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
? 判定表比较多用在多层条件判断组合的场景
? 现在在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景，而同一事件不同的出发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使用测试用例更容易理解和执行。
1、搭建测试环境，确定测试目的
? 测试环境尽可能的模拟真实环境
? 确保环境无毒
? 营造独立的测试环境
? 构建可复用的测试环境
2、安装依赖软件
拿python项目举例
安装python3、pymysql、redis等需要的工具。
导入Django、pymysql、redis等需要的第三方模块
拿Java项目举例
安装JDK、tomcat、数据库等需要的工具。
3、拉取代码
需要知道SVN地址或者Git地址
4、修改配置文件
修改数据库、redis等配置文件的配置信息，修改成测试环境的配置信息
5、编译、打包（python不需要编译直接可以运行，如果是Java、c、 c++需要编译）
6、导入基础数据
建表、导入管理员账号之类的信息，即把sql在测试数据库执行一次
7、启动程序。
? 1、记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
? 2、尽力取查找出错误的原因，比如有什么特别的操作，或者一些操作环境等。
? 3、程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在
? 4、无法重现的问题再次出现后可以直接叫程序员来查看问题。
? 5、对于测试人员来说，没有操作错误这条既然遇到了就是问题。即使真的操作错了，也要推到程序员哪里，既然程序员员犯错误，用户可能会犯同样的错误。错误发生的时候，Tester最大。
1 首先，将问题指派给开发人员。
2 然后，要获取判断的依据和标准：
3 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
4 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
5 根据用户的一般使用习惯，来确认是否是缺陷；
6 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
7 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
8 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
9仍不确定为BUG在上线前的测试总结中写入这个BUG
评估BUG的严重程度当程度高的时候应立即提示用户下线止损。
测试复现后提交缺陷管理软件，考虑bug的优先级别，再考虑修复的影响范围和难易度，然后出对应得补丁包。
在分析bug的原因，判断是什么因素导致的问题，再前往bug内容对相近的模块和类似的接口处进行复查。出现问题进行风险预防。
当BUG的程度不高为中等时提示用户维护或在下次版本迭代时进行修复进行回归测试
二八定律是一种社会准则，符合大多数社会现象的规律。同样也适用于互联网领域。
比如一个网站有成千上万的用户，但是80%的用户请求是发生在20%的时间内，比如大家去网上购物，基本也都集中在中午休息或晚上下班后。二八定律的核心原则是关注重要部分，忽略次要部分。系统性能如果能支撑发生在20%时间内的高并发请求，必然也能支持非高峰期的访问。
发现缺陷-->提交缺陷-->将缺陷指派给开发-->开发确认缺陷-->研发去修复缺陷-->回归测试缺陷-->是否通过验证-->关闭缺陷
New（新的）：bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
New：测试人bai员新建缺陷。du
open：开发人员打开zhi缺陷准备修改。dao
fixed：开发人员修改完zhuan毕。
reopen：回归测试不通过。shu
closed：回归测试通过。
reject：开发人员认为不是问题拒绝修改。
duplicate：提交的缺陷重复。
postpone：推迟修改。
abandon：开发人员认为不是问题或者已经提交过经过测试人员确认确实是这样，是一种特殊的closed。
紧急（一级）： 系统容易崩溃； 功能设计与需求严重不符； 内存泄漏； 严重的数值计算错误； 系统无法登陆； 循环报错，无法正常退出。
严重（二级）:通常表现为： 影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 比如： 1.功能未实现； 2.功能存在报错； 3.数值轻微的计算错误。
一般（三级）： 通常表现为： 界面、性能缺陷。 比如： 1.大数据下容易无响应； 2.大数据操作时，没有提供进度条3.边界条件下错误； 4.容错性不好。
轻微（四级）： 通常表现为： 易用性及建议性问题。 比如： 文字排列不整齐； 出现错别字，但是不影响功能； 界面颜色搭配不好； 界面格式不规范。
所属产品 所属模块 当前指派 重现步骤 严重程度 bug类型 操作系统 优先级 附件
报告名 测试时间 持续时间 返回状态 执行情况
首先我们要去定位发现这个bug的来源是属于前端还是后端，我们可以使用fidder进行抓包分析，在访问数据的是否抓取请求数据，比对请求数据是否正确，在服务器响应时我们可以抓取响应数据，并比对信息查看响应数据是否正确，如果是请求数据错误，那么该bug属于前端的错误，如果是响应数据错误，那么该bug属于后端（数据库）的错误，如果请求数据和响应数据都没有问题，那么就可以考虑是不是浏览器的解析出现的问题，我们就可以换一个浏览器再次进行测试一下。
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题
立项(确定项目)--编写需求(需求人员)--需求评审(编写需求人员发起)--开发编写概要和详细设计(编码并自测[开发环境])
测试:测试用例-测试用例评审(测试人员发起)--部署环境--冒烟测试(通过)--提交bug--回归测试(测试报告)--验收测试--上线
我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与，
讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，
我们测试会根据需求文档进行编写 测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审，
开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug 开发进行修改，修改成功后关闭bug，
进行回归测试，在上线前进行测试总结。
1.功能测试：
圆珠笔按下是否能正常书写。
2.性能测试：
笔芯弹出弹回的快慢。
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
4.兼容性测试：
看是否可以使用其他笔芯。
5.强度测试：
用力过度会有什么影响
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试：
笔的外观，舒适度
8.安全性测试：
是否会对使用者造成伤害
1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
? 2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
? 3、若是等边三角形，则打印：“等边三角形”。
? 4、画出程序流程图并设计一个测试用例。
? 分析一下：
? 1、构成三角形的条件：任意两边之和大于第三边；
? 2、构成等腰三角形的条件：任意两边相等；
? 3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
? 4、构成等边三角形的条件：三条边都相等。
? 那么用什么样的设计方法进行测试用例的设计呢？
? 一、等价类划分：三角形三条边A、B、C的数据类型不同
? 二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了
? 三、因果图法：三角形的三条边数据输入组合
我们再分析一下三角形的等价类：
? 有效等价类：
测试时的测试结果不为开发规定的5%可出现的BUG内也不属于严重程度较低的缺陷通过需求文档订立的测试用例不相符合所以认为他是BUG
根据开发人员的编码进行功能测试 性能测试 冒烟测试 单元测试 集成测试 系统测试 兼容测试 安全测试 和易用性测试等
解决用户问题或达到用户目标需要具备的条件或能力
遵守合同、协议、规范或其他要求
1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
3.善于怀疑，不要开发人员的能力
4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。
? 产品说明书中规定要做的事情，而软件没有实现。
? 产品说明书中规定不要做的事情，而软件确实现了。
? 产品说明书中没有提到过的事情，而软件确实现了。
? 产品说明书中没有提到但是必须要做的事情，软件确没有实现。
? 软件很难理解，很难使用，速度超慢，测试人员站在最终用户的角度看到的问题是平常的但不是正确的。
是特意设置的安全措施
防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款
所以特意设置了倒计时，限时内没有取走银行卡就会吞卡
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
性能监视器打开方法：
一、【开始》运行】输入perfmon，回车
二、右键【计算机》管理】
先进行冒烟测试发现BUG将BUG通过的测试用例测试输入和测试步骤完整的写入文档指派给开发人员开发人员确认BUG对bug进行修改当开发修改完成后重新发送给测试人员然后进行回归测试问题解决后关闭BUG为解决仍保持开启状态再次发送给开发直到解决。
原文：https://www.cnblogs.com/Swx1030/p/14204492.html