软件测试的五种模式
最常见的5种：
瀑布模式 ：瀑布模型是一种线形的、顺序的软件开发模型
V W（W也叫双v）
快速原型
敏捷开发
软件测试流程/生命周期
测试需求分析
测试需求评审
编写测试计划
设计测试用例
测试用例评审
搭建测试环境
测试执行
回归测试
测试报告
软件测试分类标准
按阶段划分
单元测试
单元测试是指对软件中的最小可测试单元进行检查和验证。
集成测试
在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。
系统测试
将集成后的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试
系统测试范围/策略/类型
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
验收测试
1.它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制
2.主要确认软件是否按合同要求进行工作，既是否满足软件需求规格说明书中的要求。
验收测试分类：
1.非正式的验收测试
а测试
软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
ß测试
软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。
2.正式的验收测试
有正规的测试过程，需要制定测试计划、定义测试方案、选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面。
按是否运行程序划分
（1）静态测试(Static Testing)
不运行被测试的软件，而只是静态的检查代码、界面或者文档
（2）动态测试
实际运行被测试的软件，输入相应的测试数据，检查实际的输出结果是否和预期结果相一致的过程。
按是否查看代码
（1）黑盒测试
把软件看成一个黑盒子，在完全不考虑程序内部逻辑的情况下，检查程序是否满足用户需求。
（2）白盒测试
对程序内部结构和算法进行测试。必须先全面熟悉程序内部逻辑结构，然后编写程序，对所有逻辑路径进行测试的一种方法。
（3）灰盒测试
关注系统接口所实现的功能，是否和需求一致。
其他划分
（1）回归测试：
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全量回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归
（2）冒烟测试
冒烟测试的对象是每一个新编译需要正式测试的版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试，也叫预测试。
外部和内部质量
功能性
可靠性
易用性
效率
维护性
可移植性
需求分析怎么做？
产品经理组织召开需求澄清会议，对需求规格说明书上的内容进行讲解。
测试人员根据需求规格说明书，利用思维导图工具（mindjet mindmanager）对需求进行细化和分解，整理出测试点。
如何进行需求分析
在我们实际工作中，有些项目有需求文档，有些项目没有需求文档。
1、如果有需求文档，可根据需求文档，按层次整理出系统所有的单个功能，包括需要输入什么参数、每个参数有什么约束条件，以及各个功能之间数据流向，得到系统测试项；
2、如果没有需求文档，只有软件产品本身，则需要对产品本身进行功能分解，同样要按层次整理出系统所有的单个功能，包括需要输入什么参数、每个参数有什么约束条件，以及各个功能之间数据流向，得到系统测试项。
测试计划的内容包括，但不限于以下内容：
测试项目的背景、测试范围、测试方式/策略、测试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险方面
风险分析
测试时间短导致测试用例覆盖不全面
测试人力不足导致测试进度滞后
客户需求更改导致工作计划被打乱
开发部门不能按时发布版本，导致测试周期缩短
质量标准不统一，某些优先级方面，测试与研发意见不统一
测试人员经验不足导致测试结果分析不全面
软件测试开始和结束条件
1、启动条件：
软件测试是在项目启动、需求分析开始时随之启动。
2、结束条件：
需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。
写好测试用例的关键
1. 覆盖用户的需求；
2.从用户使用场景出发，考虑用户的各种正常和异常的使用场景
3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例
执行结果
No Test未执行状态
Pass通过状态
Fail失败状态
Block阻碍状态
Investigate观察中状态
用例优先级别
一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定。
1级(高)，影响很大，阻碍性的、流程性的用例。例如登陆功能，百度一下
2.级(高)，大的功能点，以及会阻碍少部分用例的执行。例如新增按钮，如不能通过，很多功能都不可测试
3. 3级(中)，小的功能点，例如刷新，刷新功能等
4. 4级(低)，小的UI的问题，位置，大小，验证，建议等等
用例组成的要素
用例编号、用例名称、级别、预置条件、测试步骤、期望结果、实际结果、备注
黑盒用例设计技术/方法
等价类
边界值
错误推测方法
判定表
场景法
登录功能怎么测试
功能性:
（1）输入正确的用户名和密码登录；（2）不输入任何的信息登录；（3）输入存在的密码点登录；（4）输入存在的用户名点登录；（5）输入存在的用户名，不存在的密码点登录；（6）连续输入三次用户名和密码不正确，点登录；（7）输入正确的用户名和密码，但是用户名（密码）不区分大小写；（8）在合法的用户名中间插入空格和正确的密码点击登录；（9）输入已经禁止的用户名点击登录；（10）输入已经删除的用户名点击登录；（11）输入的用户名和密码当中含有全角和半角的字符
安全性：
（1）口令锁定（2）密码是否以*号或者别的方式显示（3）异地登录是否有提示（4）抓包篡改登录用户的数据
易用性（用户体验）：
（1）是否支持回车键，Tab键（2）账户和密码是否可以复制粘贴（3）是否记住上次登录的用户名（4）界面布局是否合理，有无错别字
性能测试：
（1）多个用户登录并发测试（2）登录的响应时间
兼容性：
pc端要考虑浏览器（谷歌、火狐、ie）的兼容性和电脑系统的兼容性。手机端要考虑系统（ios、安卓）、品牌（苹果、华为）、型号、分辨率的兼容性
删除怎么测试
功能性：
（1）不勾选记录点删除 （2）选择一条记录点删除（3）选择多条进行删除（4）全选进行删除（5）分页进行删除（6）删除一个正在被使用的记录（7）删除一个有关联的记录
1.测试用例谁执行？
软件测试工程师时间40%
2.一个版本进行几轮测试？
三轮1.执行全部的测试用例 2.3轮进行回归测试
3.Bug测试工具？
禅道、bugfree、 mantis、 zirar、buggilla、td
4.版本关联工具？
svn（联网） git（不用联网，通过linux通过命令控制）
5.Bug的要素关联哪些？
bug id、bug 标题、复现步骤、期望结果、实际结果、附件（截图、日志、抓包、录屏）、影响版本、严重级别、修改优先级、bug模块、bug操作系统、bug类型
6.Bug的处理流程？
1.（1）提交给对应的开发人员（2）开发做出相应的处理（3）已经修复的bug进行回归测试（4）通过-关闭bug，不通过-打回开发 。
2.如果开发拒绝修复bug，需要进一步讨论，测试人员需要坚持自己的立场，如果讨论是问题，需要打回给开发，如果不是bug，自动关闭
3.如果开发和测试意见不统一，需要将问题升级，召集开发经理和测试经理一起讨论，再做决定。
7.bug的状态有哪些？
new、open、rejected、reopen、closed
8.bug的严重级别？
致命（系统死机、崩溃、闪退）、严重（系统次要功能没实现，算法出现问题）、一般（删除无提示，操作不符合用户的使用场景）、轻微（界面布局、ui、有无错别字、排版是否合理）
9.用例执行参考的文档？
测试用例
10.输出的文档？
bug清单测试报告
11.一般一天能找多少bug？
一般数量是不确定的，取决于1.看需求多少，需求的实现难以程度2.开发人员的技术水平3.测试用例的质量。一般我在实际项目中大概能找50-60个，但是越到后面找的越少，因为系统相对稳定了
12.提交的bug开发不认可怎么办？
1.加强测试过程的记录（截图，日志信息，抓包，录屏等）2.和开发关系的正确处理3.找证据，证明自己的观点，尽量说服开发4.如果双方无法达成一致，提交上级解决5.过程中，对事不对人
13.幽灵bug怎么处理？
1.截图 2.查看日志，是否有相应的错误信息 3.如果无法重现，先提交，标记为偶现bug4.让开发人员协助定位5.统计每天出现的频率和规律，通过录制视频，重现前期的操作步骤，定位bug 6.一直没有找到规律，无法重现，则项目组需要评估风险，将问题写到测试报告风险分析中
14.产品上线后用户发现bug，这时测试人员应该做哪些工作？
1.测试人员复现问题后，提交问题单进行跟踪
2.评估问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能
3.问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试
4.总结经验，分析问题发生的原因，避免下次出现同样问题
15.思维导图工具：
excel、mindmanager、x-mind
