第一天笔记
SRS 规格书前端页面UI开发 OS操作系统win7，10，11MAC OS苹果基于unix开发的系统Linux开源系统（源代码） dos命令行界面win+R>cmd dir，Windows系统dos界面，查看当前位置所有文件夹命令 你们公司的系统是什么架构的？公司系统架构：C/S架构（客户机与服务器架构）：1.需要下载客户端。2.客户端需要时常更新。3.用户可能略低，安全性高。4.减轻服务器压力，对服务器性能要求低。5.上传和下载速度快。 B/S架构（浏览器与服务器架构）：1.直接通过浏览器进行访问。2.不需要用户更新。3.用户量可能偏高，安全性低。4.对服务器性能要求高，用户所有操作由服务器接收处理。5.上传和下载速度慢。 客户提出要求→项目需求→开展项目我们所在公司部门：研发部、软件研发部、软件开发部测试（TE）：软件测试工程师——助理、初级工程师、中级工程师、高级工程师、测试架构师、专家、顾问TC：测试用例、测试案例（我方编写、执行）TE：软件测试工程师TL：测试组长TPM：测试经理 开发：编写代码开发经理：管理、技术指导 项目经理：统筹整个项目 产品经理：收集需求，整理项目需求分析师：协助产品经理 运维人员：维护公司环境，项目发布和部署 DBA：数据库管理 —————————————————————————— BUG：导致软件在运行过程中出现的问题简称L1--A：致命L2--B：严重（主体流程）L3--C：一般L4--D：建议、提示 测试用例：根据需求文档分析需测试点，以测试点编写相关测试步骤、对应的预期结果，并执行。 描述功能，显示操作步骤，已知预期结果的一个文档。 编写→执行→处理1>瀑布模型： 1-1.测试最后介入，问题最后发现 1-2.不能跨阶段关注 1-3.适合需求稳定项目 1-4.每个阶段都会生成对应的文档
———————————————————————————————————————————— 2>V模型：主要了解各个阶段会生成之文档ST和IT合并称为SIT；即系统集成测试 2-1.需求说明：分析需求规格说明书（SRS），在公司中通过澄清会议对需求中的问题进行说明 2-2.系统工程设计阶段：主要考虑整个系统需要实现什么功能 2-3.概要设计阶段HLD：把系统功能划分为多个模块，以及模块和模块之间接口设计 2-4.详细设计阶段LLD：面向着某个模块里面的内部实现过程 2-5.编码：根据详设的要求去编写相关的代码 2-6.单元测试UT：主要测试具体一个模块里面的代码有没有满足详设的要求 检查代码逻辑（开发） 2-7.集成测试IT：将整个项目的模块拼接并测试是否正常运行 2-8.系统测试ST：不单保证当前模块是否正常运行，还需保证相关联模块是否正常 2-9.验收测试UAT：正式及非正式验收 2-9-1.非正式验收 (1) α(aerfa)验收：公司内部组织，开发与测试，即时处理问题 (2). β（beta）验收:特定用户验收测试，通过反馈修复问题 2-9-2.正式验收：正式版本，由广大用户使用 *一般集成测试和系统测试一起做，SIT
一般公司有哪些环境开发环境dev：开发人员写程序代码的服务器环境测试环境sit：测试人员对软件进行测试的服务器环境验收环境、预发布环境uat：验收人员模拟生产环境的数据对软件进行验收生产环境、真实环境、线上环境（prod）：给广大用户使用的服务器环境，是公司盈利的环境 优点： (1)改进了瀑布模型 (2)反应的测试活动与开发阶段有对应关系 (3)添加了测试策略，分别对底层的代码进行了测试，也对用户的需求进行测试缺点： (1)还是一个串行模型，前期阶段出现的问题仅能在后期发型 (2)测试介入的时间较晚，软件开发周期的编码阶段之后才介入 ————————————————————————————————————————————3>H模型准备阶段：1.进行需求澄清会议，由产品经理召开，一般参加人员有：整个项目的所有人员（项目经理、开发、测试、运维人员），需求澄清会议各方确认无大问题，便可输出基线化的需求文档（*基线化：不会有大改动）2.分析开发输出的概设和详设文档3.测试经理输出测试计划或者测试方案4.测试人员根据任务需求文档编写测试用例， 进行用例评审会议(测试经理召开) 组内评审（交叉评审）：测试组内的同事进行相互的评审 组外评审：项目成员进行评审，一般是跟当前需求相关的测试人员和开发人员，产品经理一起进行5.评审通过后便会形成用例基线文档，测试经理将其提交至用例管理平台(testlink，禅道)，分配给对应测试人员6.搭建测试环境 执行阶段（开发进行提测、转测、转测试，开发人员将完成代码打包自测后提交于测试人员，一般一天内）7.部署项目：把开发的代码包部署到测试环境，并且运行，一般是由测试运维或测试经理、测试骨干执行8.冒烟测试：(1)测试当前版本的主体功能和重要分支功能(2)一般不会超过半天(3)冒烟测试不通过就进行版本打回 冒烟测试的用例是怎么进行挑选？ 选择和主体功能相关的测试用例和用例级别比较高的测试用例 9.冒烟测试通过后，可以进入SIT1测试(第一轮系统集成测试)，SIT测试一般分为3轮 每一轮测试用例是怎么进行挑选的？SIT1测试选择全量的测试用例(当前版本相关的所有测试用例)SIT2/SIT3测试(回归测试，相对于SIT1的回归)，选择的是：(1)上一轮测试出现的BUG的测试用例需重新进行验证(2)BUG相关模块的测试用例(3)每一轮都要进行主题功能的测试(也就是每一轮都要选择冒烟测试用例)(4)可以选择你觉得可疑的测试用例和测试场景(5)测试人员补充的测试用例 为什么要补充测试用例？因为开发过程，我们测试人员并不知道最终开发出来的产品是不是我们预期的，所有在开发完成之后才能看到所有的相关页面，为了避免漏测的情况，我们需要及时的补充测试用例 10.整个测试周期，BUG的数量应该是呈收敛的趋势11.输出测试报告，需要达到测试准出条件(0BUG上线)，当然可遗留1-2个建议性的缺陷，遗留的BUG必须明确后续的版本进行修改12.回归测试分为两种情况：(1)SIT过程的回归测试，除了SIT1以外的测试都叫回归测试(2)SIT过程以外的回归测试，主要是对整个系统进行回归 冒烟测试与回归测试的区别？冒烟测试：又称为版本构建测试，提交测试，每一次版本构建(代码提交)时都要进行的测试，对版本的基础功能和主体功能 进行的测试，一般不超过半天，两小时左右，不通过直接打回回归测试：系统维护阶段进行，对原有的功能缺陷进行验证测试区别：测试阶段不一样，冒烟测试是在版本提交时进行，回归测试是在系统维护阶段执行 在测试过程中，执行测试用例时，发现一个问题(用例不通过)，就要及时进行提交BUG的操作，叫做提单
———————————————————————————————————— 4>敏捷模型：1.重点明确，及时调整：往着一个目标去开发，出现偏差就及时进行调整2.倾听用户的声音，相信用户的直觉：面向市场用户的需求进行开发3.勇于创新，小步快跑：头脑风暴，什么相关的功能都可以提，有问题不适合直接剪掉，适合用户的持续进行改进4.持续不断地发现问题，解决问题：频繁迭代，保证主体功能无误，允许小问题，但需要及时进行修改5.持续提升整个团队的产品能力：
页:
[1]