测试的基本原则

测试的基本原则
1，测试的标准是用户需求
2，测试不仅仅是单纯的软件本身的测试
2.1了解功能使用背景目的
2.2软件是否受其他外界因素影响，如：兼容性，落网/断网
3，软件外在没有失效不代表软件系统是可用的
4，软件的完美度没有完全正确的，测试只能帮助软件更加完美，更加正确。
5，穷尽测试是不可能的（有些条件组合非常多，穷尽是不可能的）
6，测试应该尽早介入（早期引入的问题占到整个问题数目的50%以上）
6.1需求分析评审，对理解需求更加透彻，为后面输出测试用例和测试工作打好基础
6.2确保开发，测试，产品经理对需求的理解是一致的，规避后面功能开发出现错误
6.3尽最大可能降低项目延期风险
7，二八原则/二八定律（80%的缺陷或错误会集中出现在20%的区域中）
8，杀虫剂效应（也就是说要不断更新用例，因为反复执行相同的测试用例会发现的bug几乎为0）通过交叉
8.1在测试过程中发现用例存在遗漏点或者用例与实际开发出了效果有偏差但实际效果体验更好，那么测试人员就要及时更新测试用例
9，测试活动依赖测试对象（测试的关注点不一样，有的更多关注安全和性能测试）
10，尽量选择第三方测试（避免自己测试自己开发的程序）

1，测试计划
2，测试用例的编写，输出测试用例
3，测试实现与执行（冒烟测试，SIT，回归测试）
1，非正常运行—》没有网路情况下使用软件
2，自身缺陷：代码+文档
3，环境也会影响测试
测试·用例：是用于测试工作的一份专业文档
包含要素（用例编号，用例标题，前置条件，操作步骤，预期结果，实际结果，优先级）
bug起源=飞蛾事件
测试：验证软件的正确性，发现软件中缺陷/bug

周期阶段：
1，客户问题引入分析（客户要求，上线发布时间，目的）-产品经理对接
2，可行性分析（项目经理，产品经理，开发经理，测试经理，技术大佬，架构师）
2.1，成本（人力，天数）
2.2，商业价值/法律
2.3，政治风险
2.4，涉黄涉爆
2.5，技术难关，根据公司现有的技术能力能否解决实现项目功能
3，项目招投标：·看谁要的钱少，有相关工作经历，时间周期
4,项目立项
4.1，成立项目组
4.2，人力安排，时间安排
4.3，采购设备
5，需求分析
5.1，参与人员：所有参与开发的人员
5.2，需求分析由谁主导：产品经理主讲
6，开发阶段
6.1，UI设计师：输出效果图                                                                                                                               
6.2，开发人员，进行编写代码
6.3，测试，对项目软件进行测试
6.4，交付给客户进行验收
7，维护



典型的软件生命周期模型
瀑布开发模性
V模型
1，需求分析：产品经理根据用户的需求提炼为项目需求，召开需求澄清会议（需求评审）
经过多次讨论分析最终形成一个基线化的文档，就叫需求规格说明书，简称SRS；
基线文档：代表各方对该文档达成一致，可以进入下一个状态
2，概要设计：简称HLD，项目分为模块A，模块B，模块C--由开发输出概要设计
3，详细设计：简称LLD，针对每一个模块中具体的功能怎么实现--开发人员输出详细设计
4，编码和实现：开发人员编写代码（代码打包成压缩文件，war/jar）
5，单元测试：简称UT，又叫白盒测试。可以看到内部的结构，内部逻辑和内部==》对代码进行测试。由开发人员完成
6，集成测试：简称IT。称灰盒测试，又称接口测试。模块A,模块B，模块C单独测试没有问题。放在一起进行测试
7，系统测试：简称ST。除了保证当前软件的功能正常使用，还要保证与第三方系统对接不会出现问题
8，验收测试：简称UAT，
阿尔法（α）测试：公司内部的开发和测试人员模拟用户的行为操作
对此时发现的bug进行修改
贝塔（β）测试：产品已经交付到客户手中，此时出现bug，客户进行收集bug发邮件抄送所有项目开发人员
项目经历了哪些阶段。每个阶段的输入与输出是什么？
输入                                        输出
需求分析                        用户需求                        需求规格说明书（SRS）
概要设计                        需求规格说明书        概要设计文档
详细设计                        概要设计文档                详细设计文档
编码阶段                        详细设计文档                代码打包
单元测试                        开发打包部署环境        单元测试包
系统集成测试                单元测试包                系统集成测试包
验收测试                        系统集成测试报告        验收测试报告
w模型：是V模型的补充
H模型（项目流程）
SRS澄清：需求评审，得到需求规格说明书
review（评审），测试人员要参与
PTM测试经理编写测试计划（规定测试范围，人力安排软件与硬件的资源，测试进度，风险评估）
风险评估：1，新人参与测试
2，项目需求延期提测

项目组中常用的评审（TC）有哪些？（用例评审，谁写谁讲）
交叉评审：测试组内同事之间进行评审
组内评审：项目组同事，开发，产品经理，测试，UI设计师进行评审
会议评审：有客户参与

testlink是一款用例管理工具
TPM或测试骨干，运维搭建测试环境

公司有那些环境？
开发环境：开发人员编码使用环境
测试环境：测试人员测试当前项目软件的环境
预发布环境：模拟用户使用使用环境，产品经理验收使用
生产环境：线上环境，真实环境

环境搭好之后，开发人员将开发功能的代码打包，交由TPM或运维人员进行部署到测试环境，部署完成之后重启服务器，就可以通过浏览器访问网页（刷新）项目部署一般都是在Linux服务器上
冒烟测试==)sit1系统集成测试之前进行，在我们测试用例中选取20-30条进行测试
定义：对主体功能进行测试，起源硬件行业中电路板测试

qq登录功能的主体功能是什么？
qq能登录成功
qq注册功能的主体功能是什么？
成功注册新的qq
冒烟测试不通过--版本打回，开发人员重新编码修复，修改完成之后再次进行打包部署，再进行冒烟测试，一直到冒烟测试通过为止

系统集成测试：
sit1：又称全量测试，需要测试所有：==编写的测试用例：==）编写了1000条用例需要全部执行测试完成
sit2：又称回归测试，增量测试（用例数量增加）；==为了覆盖更多场景

回归测试测试那些内容？
1，测上一轮发现bug的用例
2，测试新增加的用例
3，每一轮都要进行冒烟测试
4，测试与上一轮发现bug相关联模块用例
SIT3,SIT4都称回归用例。整个测试周期，bug数量是呈现收敛趋势。

为么要去补充测试用例？
因为开发过程中，我们测试人员是不知道最终开发出来的产品是否符合预期。我们在开发完成之后我们才看得到相关页面功能，这页面功能可能会在我们测试人员分析需求的时候遗漏的，为了避免这些遗漏的情况，我们是需要及时补充测试用例的；
在项目要求的时间节点，输出测试报告；需要到达测试准出标准
o0bug，H模型当中有允许带1-2个易用性bug（易用性bug不会影响功能时使用） 当前版本发现易用性bug如果需要到下一个版本中解决，必须发送邮件告知测试经理并且抄送给所有开发人员

项目跟产品：先有项目然后才有产品
项目跟版本：一个项目包含多个版本

项目上线：产品经理会提前已邮件的方式告知相关人员；具体上线时间。
测试人员配合上线前，上线中，上线后的工作
上线前：测试人员应做随机测试，或交叉测试
上线中：整理当前版本的相关文档记录进行归档
上线后：要在正式环境中进行测试（所有测试都是按照用户的操作进行验证）
灰度发布：小范围发布，降低风险

敏捷开发模型：
重点明确，及时调整（往着一个目标去开发，出现偏差及时调整）
直接面向客户需求进行开发
持续不断的发现问题，解决问题(频繁更易迭代)
周期短（1-2周）
轻量级（每个版本的任务量不会太多）
晨会：15分钟左右（对前一天工作总结；对当天开发工作进度安排；是否会存在一些延期风险）

增量开发模型：

迭代开发模型：将复杂且周期长的项目，划分为多个独立的功能板块且分为多个版本开发上线