测试理论学习
测试用例
搭建环境
QA（测试环境）
预发布环境（开发环境）
生产环境（线上环境）
定义
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。
编写步骤
拿到测试需求——分析需求（画思维导图）——编写用例——划分用例优先级。
编写特征
（1）一致性：主要包括用例模板一致；各同事的编写方式一致；以及用例的细腻度一致。
（2）覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对哪些功能会产生影响的覆盖；对各种场景的覆盖，包括功能和非功能以及异常功能。
（3）可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点。
（4）执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行但标为测
试通过的情况。
（5）持续更新：要及时不断的更新，要尽量减少用例库中失效的用例。
（6）复用性：主要用例可以被不断的复用。
组成元素
（1）用例ID；（2）用例名称；（3）测试目的；（4）测试级别；（5）参考信息；（6）测试环境；（7）前提条件；（8）测试步骤；（9）预期结果；（10）设计人员。
写测试步骤的注意事项：详细、清晰、通俗易懂。
测试用例评审步骤：
1，发起会议邀请
2，到约定的时间在会议室评审测试用例
3，评审结束后，完善测试用例
BUG提交和BUG⽣命周期管理
缺陷概况
缺陷又叫BUG 缺陷 ISSUE
缺陷类型： 建议 优化 BUG 需求
建议：建议不能说问题，建议表达的是更加完善
优化：指的是产品不是那么很好，优化下更加好，比如提升信息
BUG：指的程序存在缺陷
需求：客户有了新的想法，增加到产品里面
缺陷级别： 致命 严重 一般 建议
致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
严重：操作性错误、结果错误、功能遗漏。
⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。
建议：对产品的改进建议。
缺陷优先级： 紧急 高 中 低
优先级表示修复缺陷的重要程度和紧迫程度。
紧急：影响进⼀步测试，需要⽴即修复。
⾼：必须在版本发布前修复。
中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。
低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
缺陷状态： 进行中 已关闭 不解决 重开 暂缓
主要描述缺陷当前的状态。状态如下：
新建：测试⼈员新提交的bug、优化或者建议的状态。
进⾏中：开发⼈员确认是bug，在修复bug过程的状态。
已解决：开发⼈员已修复bug的状态。
已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。
不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态
重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发⼈员的状态。
暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。
BUG的缺陷流程
用自己的话描述就是：一，测试人员发现问题，把问题提交给开发人员，开发人员确定是bug后，开发人员解决，解决完给测试人员测试，测试通过后关闭。
二，测试人员发现问题，把问题交给开发人员，开发人员不认为是bug，拒绝解决问题。
三，测试人员关闭后又发现问题出现重新交给开发，开发解决完测试人员测试，测试没问题后关闭。
四，测试发现问题提交给开发，开发确认是BUG，解决BUG需要然后全体人员讨论是否延迟，若延迟该BUG后续处理
使用TAPD操作缺陷流程
ISSUE注意事项：
1,BUG标题一定要表达出问题的核心，看了标题就知道是什么问题
2，BUG步骤要清晰明了，通俗易懂，步骤要非常详细
3提交BUG最好有问题的截图
4，提交BUG最好有详细的日志信息（主要针对的是后台服务）
测试计划的编写
测试计划的定义及⽬的 ⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员安排以及任何偶发事件的⻛险。软件测试计划是指导测试过程的纲领性⽂档。计划可以统⼀认识，可以规划过 程。 测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试⽬标（被测 特征）、测试优先级、测试配置/测试资源<硬件、软件、⼈⼒、技术等>、测 试周期、进度安排（测试任务、⼈员安排）、 测试策略、测试⽅法/途径、 测试交流、⻛险分析、测试标准、需交付⽂档等内容。
测试范围 明确测什么？
测试策略 明确怎么测
资源安排 包括测试⼈员的安排和资源环境安排
进度安排 在明确测试范围、⽅法和⼈员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、 上线计划衔接。
发布标准 发布标准是测试完成和产品上线需要满⾜的条件，以便项⽬内所有⻆⾊都有⼀致认可的⽬标。
⻛险预防
手工测试
⼿⼯测试就是由⼈去⼀个⼀个的输⼊测试⽤例，然后观察结果，和机器测试相对应，属于⽐较原始但是必须的⼀个 步骤。⼿⼯测试⼜叫功能测试，或者说是业务测试。它的特点主要为： 优点：⾃动化测试是⽆法替代⼈的测试的⾏为模式的，也⽆法替代探索性的测试 缺点：执⾏效率慢，影响测试交付的效率
⾃动化测试
⾃动化测试就是通过编写代码(使⽤⼯具)的⽅式来替代模拟⼈的⼀种⾏为⽅式来对系统进⾏的⼀种测试。⾃动化测 试⼜分为UI⾃动化测试，API⾃动化测试，性能⾃动化测试。⼀般性说的⾃动化测试⼤多数时候指的是UI⾃动化测试和API⾃动化测试。
软件质量
软件质量 描述当前软件是否好⽤，在当前的软件⾏业⾥我们所采⽤的⼀套标准是基于 ISO 组织 制定的。需要我们记忆的就是软件质量的六⼤特性：
功能性：软件需要满⾜⽤户显式或者稳式的功能。
易⽤性：软件易于学习 和上⼿使⽤。
可靠性：指的就是软件必须实现需求当中指明的具体功能。
效率性：类似于软件的性能。
可维护性：要求软件具有将某个功能修复之后继续使⽤的能⼒。
可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使⽤的能⼒
测试用例术语
冒烟测试：
冒烟测试⽬的是确认软件基本功能正常
探索性强调测试
探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计 过程，强调在碰到问题时及时改变测试策略。
回归测试
回归测试是对已有的功能进行测试，或者对已有的和新功能进行测试
每日例会
昨天干了什么
今天干了什么
有什么问题提出来
敏捷模式：小步快跑 ，快速迭代
项目里面的角色：
项目经理：pm
后端开发：开发负责人，以及其他开发 4-5人
前端开发：1-3人
产品经理：1人
测试同学：2-4人，测试负责人
所以在一个项目，人员大概有：13人
公司职位
开发经理
测试经理
运维经理
2周一个迭代
第一周
星期一：熟悉需求，列计划
星期二：编写测试用例
星期三评审测试用例
星期四/星期五：完善测试用例，完善自动化测试的测试脚本，进行冒烟测试
第二周
星期一：测试，以及提交bug
星期二：回归bug，进行第二轮的测试
星期三：进行系统的测试和验收测试
星期四：编写测试报告，准备上线前的工作
星期五：跟踪产品上线后的情况，项目内部复盘
C语言 冒泡排序
浙公网安备 33010602011771号