基础

测试流程

1)需求研读：

• 通读需求了解需求整体内容，然后精读需求理解需求的每⼀个业务逻辑，每⼀句话的意思。
• 在研读需求过程中的记录问题，然后通过百度，AI⼯具，CSDN社区，咨询朋友，同事，解决遇到的需求问题。
• 如果还有解决不了的问题抽时间和业务沟通，在需求评审之前，尽量把需求吃透

2)需求评审：

• 三⽅评审，产品主讲，主要讲解需求中的重点，难点，开发、测试、⼀起沟通讨论问题

3)测试计划：

• 测试计划⼀般由测试经理或者测试组⻓或者测试经验丰富的⼈编写
• 写测试计划之前⼀般要和开发负责⼈和业务沟通下，开发提测时间和业务要求的上线时间，根据这两个时间，确定我们有多少时间编写案例，多少时间进⾏测试，做⼏轮测试，每轮测试做多久
• 测试计划内容：测试开始时间，结束时间，⼈员配置，资源配置，测试的标准、⻛险（需求变动，bug太多，⼈员调动，测试环境和实际环境不⼀致）

4)分析需求编写测试⼤纲:

• 根据最终版需求，使⽤xmind(思维导图)编写出每个模块的测试点即编写测试⼤纲

5)编写案例：

• 根据测试⼤纲，使⽤多种设计⽅法设计案例。⽐如等价类，边界值，场景法，异常分析法，错误推断法等等，将测试点转化成具体的测试步骤

6)案例评审：

• 测试主讲，产品开发⼀起参加，查缺补漏 ，同时做好评审会议记录，会后补充修改案例

7)冒烟测试：

• 主要功能是否可以使⽤

8)系统集成测试：

• 执⾏测试⽤例，⽤例执⾏通过就pass，有问题就提交bug ，跟踪bug，验证bug

9)回归测试：

• 缺陷多的模块、新增模块、重点模块进⾏回归、根据个⼈经验

10)验收测试:

缺陷管理流程、缺陷状态

1. 发现bug通过管理⼯具jira提交给开发
2. 如果是bug，开发修改完成后更改bug状态为已解决。重新指派给测试
3. 由测试⼈员进⾏验证，确认修改正确，关闭bug
4. 如果不是bug，退回给测试⼈员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。
5. 验证未通过的bug重新激活，开发⼈员继续修改，直⾄验证通过，关闭bug

缺陷单状态

标题，重现步骤、附件（视频、log⽇志、截图、canlog⽇志）、严重等级、优先级、版本，所属模块等等

• 标题：缺陷标题通常需要简明扼要地描述缺陷所涉及的问题，开发快速了解缺陷的性质
• 重现步骤：能够帮助开发⼈员理解问题的真正原因，如果重现步骤能够详细清晰地描述，开发⼈员就可以快速定位和修复缺陷，节省不必要的沟通
• 附件：让开发更快地获取到必要信息。例如，截图、录屏、⽇志等多媒体素材能够有效地帮助缺陷处理⼈员定位问题，避免不必要的沟通和确认环节。

如何设计测试案例

• 设计测试案例最重要的是要先读懂需求，只有充分理解了需求，才能写出全⾯的有⽤的测试⽤例
• 通读需求了解需求整体内容，然后精读需求理解需求的每⼀个业务逻辑，每⼀句话的意思。在研读需
• 求过程中的记录问题，然后通过百度，AI⼯具，CSDN社区，咨询朋友，同事，解决遇到的需求问题。
• 如果还有解决不了的问题抽时间和产品沟通，在需求评审之前，尽量把需求吃透

除了需规上已经覆盖到的场景之外

• 我们还需要需要多参考借鉴其他同类产品中做的好的优秀的功能，多站在⽤⼾实际使⽤的⻆度，多从交互⽅向考虑设计测试⽤例
• 然后针对每个模块先设计流程的⽤例，包括正流程和异常流程，再根据业务规则设计各种场景⽤例，
• 再针对栏位，ui，提⽰信息设计对应的⽤例，当然涉及到模块之间的交互场景都要设计到在设计测试⽤例的时候会结合案例设计⽅法（等价类，边界值，场景法、错误推测法、异常分析等）进⾏设计

举个例⼦:语⾳控制空调

• ⾸先，设计正常调节温度的流程⽤例，然后再设计调节温度低于最低稳定、⾼于最⾼温度、吹脚、吹脸、或者脚脸同时吹、电量低开启空调、空调切换到舒适模式、切换到节能模式、切换到通⻛模式、⾳区同步开启和未开启状态下，跨⾳区控制空调等等⽤例，最后还要设计ui界⾯检查和提⽰语的⽤例
• 调节温度的案例设计可以采⽤等价类，边界值的⽅法，⽐如温度在16~32，有效等价类16度-32度， ⽆效等价⼩于16度和⼤于32度，在这个基础之上可以⽤边界测试下温度的边界15，16，32，33

异常分析法： ⽹络异常、断电、⽅⾔

测试报告包括哪些内容

每⼀轮测试执⾏完成之后编写测试报告

主要包含：

1. 测试⼈员，被测⻋机系统版本号，测试时⻓；
2. 测试内容（被测模块）；
3. 执⾏⽤例数；
4. 发现bug 数，其中严重的多少条，⼀般的多少条，轻微的多少条；
5. 是否还有遗留 bug；是否有⻛险，⻛险点在哪⾥；
6. 还有测试结果，通过或者不通过

提交⼀个bug开发不承认怎么办

开发如果不承认⼀般有两种情况,第⼀需求中没有要求，第⼆开发没有复现出你提交的bug

第⼀种情况，需求中没有提到，那我⼀般会站在⽤⼾的⻆度考虑，是否真的会有这样的场景，如果有

的话，那我先和开发沟通，晓之以理，动之以情，⼀般开发都会配合修改的，如果还是不修改的话，

那⼀般会把情况和业务进⾏沟通，最终由业务⽼师进⾏定夺

第⼆种情况，可能是开发复现的步骤不对，那这个时候我们就给给他复现⼀遍，如果复现确实存在问

题，开发⼀般会承认

如果我们⾃⼰也不能复现，那有可能这个bug是⼀个偶现的bug，针对偶现的bug,⼀般我们会尽可能多

的执⾏⼏遍，找出出现的原因，或者概率，然后也会去找出当时的⽇志，结合分析问题。如果⼀直复

现不了，那我们⼀般会记录这个bug然后每个版本都会进⾏验证（⼀般跟踪5-10个版本）

迭代项⽬制定执⾏案例的策略是什么？

⾸先，要选择本轮迭代新增和修改的案例其次，要选择本轮迭代内容相关联的案例，⽐如修改了⻋速⽅⾯的，就会把⻋速⽅⾯的案例都回归⼀

遍，（开发⼀般会给影响性评估表，我们也会根据⾃⼰的经验判断影响性）

然后，还要把所有的模块的流程案例和主要逻辑案例执⾏⼀遍