为什么要测试？
异常测试：从不同的角度去违反软件的规则
软件是由代码和文档组成的？
一个软件的产生，它是包含很多文档组成，需求规格说明书，概要设计说明书，详细设计说明书，测试用例文档，测试报告，测试计划
通过代码实现文档标注的功能
环境也会影响软件，以致出现软件“失效”现 象。
在其他环境进行验证的时候没有问题，放在生产环境就出现了问题，一些环境配置（服务器配置，软件硬件等）也会引发许多问题，也会导致软件无法使用
怎么保证产品的质量？
1.软件测试活动只是关键的质量保证活动之一
2.开发编译的代码规范性也是保证软件的活动
3.产品经理进行编写需求规格说明书规范，也是保证产品质量活动
通常软件生命周期包括哪些阶段？
• 1)客户问题引入或定义：产品经理进行引入客户需求
• 2)可行性分析
涉及经济（商业论证）：1.生产的软件是否能够带来具体的经济效益
2.项目组的资金能否支持这个项目的运转
政治：不能涉及政治相关的敏感话题
法律：不能从事黄赌毒
技术：项目组的技术能否实现这个需求
• 3)项目招投标：项目组发布公告吸引有资质的单位来承包项目组的一部分开发工作
• 4)项目立项：开始招聘人员，制定工作计划，制定产品标准，分配工作
• 5)需求分析：通过产品经理整理的需求文档进行分析，发现需求当中存在逻辑的问题和矛盾的地方，产品经理然后进行修改，直到所有的项目组成员意见达成一致，形成一个可执行的文档，然后继续分析需求文档，从需求当中提取到下一步工作计划
• 6)开发阶段
设计阶段：开发进行设计概要，设计文档，详细设计文档
测试人员进行设计测试计划-测试用例文档
coding编码阶段：开发进行编写代码
测试阶段：测试执行阶段（执行编写的测试用例）找bug对应的开发人员进行修复，直到所有的bug关闭，进行上线给用户使用
• 7)维护
1.持续跟进用户反馈的问题进行优化和解决
2.开发的代码维护不断的更新
3.测试用例的脚本也需要维护
一个完整的项目流程包含那些阶段？
1.需求搜索：由产品经理进行需求的搜索工作，然后整理成一份可以执行的文档
2.需求分析：1.分析这个需求是否有存在矛盾的地方，逻辑错误的地方，以及提炼下一阶段工作开展方向
3.概要设计：简称（HLD）是开发人员进行对系统的大致主体结构的设计，包括开发框架的使用以及数据库结构的建设。
4.设计人员：开发人员进行设计编写，对项目的系统配置以及开发具体的框架进行设计
5.详细设计：LLD
也是由开发人员进行设计的，设计项目的具体的具体内容，和设计编写接口
6.开发编码：开发在开发环境进行程序的开发工作
7.单元测试：白盒测试-透明盒子测试-开发人员自测
白盒测试的方法
1.语句覆盖：所有可以执行的语句都要运行一次
2.判定覆盖：所有需要进行取值的判定节点都需要运行一次
3.条件覆盖：所有运行出现的结果都需要运行一次
4.判定条件覆盖：所有判定取值出现的结果，都需要运行一次
5.条件组合覆盖：所有条件进行组合，运行一次
6.所有涵盖的路径方法都要运行一次
冒烟测试：是测试人员执行的第一轮测试，这个项目的主体功能是否运行
冒烟测试如果测试不通过，直接打回开发进行修复，然后进行自测，自测完成后再一次执行冒烟测试，直至冒烟测试通过，冒烟测试通过，编写冒烟测试报告结果
系统测试：IT测试
系统测试就是针对软件系统的配置以及性能等功能方面进行测试
集成测试：ST测试
也叫组装测试--->模块与模块之间的交互的问题
也针对API进行测试
系统集成测试（SIT）
全量测试（全方位的测试（包含it-st阶段内容））
回归测试（SIT1）
针对上一轮产生bug做验证测试，这个bug是否修复，这个bug相关联的一些模块也需要进行测试，看有没有产生新的bug
回归测试关闭条件，所有用例都已经执行通过，所有的bug修复率达到百分之98%，遗留的bug必须是建议bug不会对这个产品产生风险项，才可以关闭回归，进入验收阶段，回归测试通过，编写sit系统集成阶段的测试报告
测试报告的内容:
1.包含所有的测试用例
2.包含测试过程中所有出现的bug，一级bug（崩溃）二级bug（严重）三级bug（一般）四级（建议性bug）这些出现的bug数量及对应的情况，是否解决
3.包含所有遗留bug数量，及对应的风险管理，解决的相应版本
4.此次测试的总结
一级bug（崩溃）：引起服务器的崩溃，服务器挂了宕机
二级bug（严重）：此bug已经影响接下来的测试，阻碍了测试行为
三级bug（一般）：不影响测试的功能性bug
四级bug（建议性）：界面上优化问题等，例：文字信息，背景
验收阶段：
α alphc验收：在非正式环境进行验收--在模拟的预发布环境进行验收，项目的所有组成员在场，出现问题及时进行修复，验收通过发布线上给用户进行使用
β beta验收：在正式环境进行验收--会挑选一个时间进行验收
验收人员包含产品，测试，开发。发布正式环境之后，由测试人员进行新一轮测试，测试没有问题的话就直接交由用户进行验收使用。
假如发布的时候碰到bug怎么办？
1.首先分析这个bug修改需要多长时间，及这个bug的等级，如果说这个bug修复时间可控，那么就在当天晚上进行修复，再次进行发布
2.bug比较严重，开发人员不确定修复时间，及时进行回滚（恢复到上一个版本），取消上线发布，然后在进行修复，修复完成之后测试进行测试，测试通过再选择一个时间进行发布
静态测试：不需要运行程序，对程序的代码以及文档进行静态走查
动态测试:通过运行程序来发现程序当中的一系列问题，分为白盒和黑盒测试，都需要通过运行来检查
手工测试:以用户的角度来检验产品是否符合他对应的需求，点点点，属于黑盒测试的一种
典型的软件生命周期模型有哪些？
• --瀑布模型(waterfall)
特点：1.是阶段性展开的，一个阶段的完成才进入下一个阶段，直到项目结束
2.能够清晰的表达开发周期的全部过程，明确标注了每个阶段的任务
优点：适合大型的项目管理，需求稳定的项目
缺点：1.不够灵活，需求如果出现变动，返工的代价比较大
2.项目的前期很难看到实际结果
• --V模型：是一个串行结构的模型，它包含了测试的所有行为，测试的行为有了参考的依据
输入：用户需求 输出：需求分析
输入：需求分析 输出：概要设计（系统的配置大致功能，系统开发框架设计，系统的数据库设计）
输入：概要设计 输出：详细设计(各个模块之间的api设计，以及模块子功能的设计)
输入：详细设计 输出：编码coding
输入：编码 输出：单元测试（白盒测试。开发进行自测）
输入：单元测试 输出：集成测试（模块与模块之间的组装测试，系统与系统之间的联调）
输入：集成测试 输出：系统测试（安全，性能，功能等方面）
输入：系统测试 输出：验收测试（α，β 验收两种方式）
优点：1.涵盖了所有的测试行为
2.测试有了参考依据
缺点：测试行为依旧在开发行为之后，前面发生的一些问题测试并不清楚
• --W模型：是V模型的延伸，但它依旧是个串行结构，我们测试的介入项目时间提到需求分析阶段
优点：1.贯穿了整个项目的开发周期模型
2.测试行为提升到需求分析阶段能够尽早的发现项目当中问题
3.开发与测试进行并行开始，可以加强开发与测试的合作关系
缺点：1.实际的工作场景中并不会产生实际性的文档
2.编写文档对开发来说要求比较高，读懂实际文档对测试来说要求比较高
• --敏捷开发模型
交付周期是每星期，强调人与人之间的沟通，能够快速适应需求的变化。测试时间不足，会导致测试不是很全面。
• --迭代开发模型
项目被分为大量的迭代过程，一个迭代过程就是一个开发的生命周期，迭代的子集可以当作产品进行发布
• --增量开发模型
• --H模型
SRS（需求规格说明书）---澄清会议
所有项目组的组成员对需求规格说明书进行评审
1.开发分析需求的可行性，以及设计方法
2.测试分析需求的可行性，需求有疑问和有矛盾的地方提出
3.分析需求中开发需要的开发周期，和测试人员得出测试产品的大致周期
开发线：
概要设计（HLD）：系统方面的设计，包括系统开发框架的设计，这个项目的大致的主体功能，以及数据库结构的设计
详细设计（LLD）：模块与模块之间的接口设计，主体功能子模块的详细设计实现的方法与思路
coding编码的工作：开发人员进行编码-编码完成之后进行单元测试。
单元测试：白盒测试（开发自己在他自己的开发环境进行代码的走查。）
测试线：
继续了解需求文档，罗列出需求当中的测试点，然后根据罗列出来的测试点，转换为测试用例
TPM 设计制定测试计划：分配测试工作，相关项目模块划分，制定完成交付周期。
1.测试人员根据所划分的模块，书写相关模块的测试用例输出测试用例初稿。
用例评审：（是由测试人员进行发起的）
用例评审得目的：评审你所书写的测试用例，是否又存在遗漏的地方，有的话进行补充，再次评审。用例没有问题，那么就形成最终执行文档
组内评审：测试组所有测试人员进行评审
交叉评审：负责同一个项目的测试人员之间进行交互评审
会议评审：包含测试经理，产品经理开发等等所有项目组成员对你写的用例进行评审。
2.TPM将用例的基线文档导入到用例BUG管理工具，并将用例进行分配，用例bug管理工具：是用来管理测试用例，和所有的bug，管理项目产品。
3.搭建测试环境：
a.如果说公司有运维人员就由运维进行搭建测试环境
b.开发进行搭建测试环境，
c.测试人员进行搭建测试环境。测试环境一般是部署在linux系统或者windows系统，开发把开发好的代码包进行打包，然后转给对应的相关人员（运维,测试，要么开发自己部署）代码包的打包格式war.jar包
测试人员进行冒烟测试：
对项目的大致主体功能进行测试。测试通过，执行下一阶段工作，不通过打回开发进行修复，自测，进行新一轮的冒烟测试。冒烟测试通过，测试人员执行
SIT系统集成测试（全量测试，批量注入我们所写的测试用例。进行测试，如果发现bug，提交给对应的开发进行修复。直到第一轮测试完成。等开发修复好bug之后进行第二轮sit2测试（回归测试），回归上一轮所产生的bug。（这个bug相关联的模块是否出现了新的问题）如果说一直有bug产生就一直进行回归）直到这个项目bug修复率达到98%左右，且没有重大或者一般的bug，2%是建议性bug（不影响线上用户使用的bug，这些建议bug已经跟领导进行确认）那就就可以关闭回归测试。输出这个项目的测试报告
进行验收测试：α，β验收
一个项目可以划分多个版本V0.1 V0.2
BUG用例管理工具
testlink
QC
禅道
JIRA
TAPD
开发说测试提的bug不是bug怎么办？
1.作为一个专业的测试，我们有可以分辨bug的能力，如果说开发不进行修复，请示上级领导进行评判
|
|
384
0
多测师社区 
