一：自测背景

开发人员做好自测，非常必要，也是大趋势。前期都是开发自测（包含必要的测试），后期才是用户体验方面的测试；从成本上分析，BUG越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。另外，写出高质量的代码，是能力的体现，专业的体现，自身价值的体现。一个优秀的开发者，自测的bug一定会多于测试发现的bug，也就是轮到测试的时候bug数量相当少。

二：疑难问题

1. 时间和进度太紧张
2. 对自己代码过于自信，自认为很健壮，不忍心去修改
3. 认为这是测试的责任，多度依赖测试
4. 不知如何有效的做好自测，覆盖全面

三：思维转变

1. 代码质量、项目质量均是我们的责任。
2. 测试和开发人员思考问题不同，开发是在制造软件，测试是在破坏软件，想办法去找出问题。
3. 任何功能都有正常场景和异常场景，多数使用等价类和边界值去选择数据，覆盖全面。
4. 不要相信任何开发的代码是无bug
5. 走出具体实现时用的开发思维，站在需求和用户的角度去自测是否通过，假如自己是用户去测试你的功能

四：不好好自测带来的痛处

1. 需求遗漏：一旦被用户发现此问题，用户印象会大打折扣，可能直接从开始使用即放弃使用，将带来非常大的客户流失
2. 功能事故：主流程功能没有测试到位，或者异常场景没有测试到位，导致线上频繁报错，体验极度不好，直接认为就是事故
3. 需求延期上线：如果自测不充分，测试花大量的时间去沟通低等级bug，甚至主流程走不下去，这样无疑会给开发带来返工、重复测试、耗时、需求延期、项目延期等一系列问题。

五：自测报告规范

功能模块介绍及背景介绍

1. 功能、背景介绍
2. 使用用户群体介绍

环境信息

1. 版本号
2. Hosts
3. 预发or正式
4. 账密信息
5. 功能设计文档以及UI设计图等

评估时间

梳理好的自测点

1. 编写代码时候记录的业务点
2. 需求变更的自测点
3. 正反向场景测试点
4. 易用性测试点
5. 兼容性
6. 开发此功能是否会对其他功能造成影响（需要leader评估）

自测实际结果：

1. 高等级bug数量
2. 中等级bug数量
3. 低等级bug数量
4. 单元测试覆盖率
5. 单元测试通过率

期望结果：

1. 高等级bug数量为0
2. 中等级bug数量为0
3. 低等级bug数量不超过5
4. 单元测试覆盖率90%
5. 单元测试通过率100%

是否具备提测标准

1. 实际结果在期望结果之内则表示通过，否则不通过。

六：测试案例--新增安全组规则

1.先找出我们要测试的测试点
1.1、规则方向
创建入口决定了规则方向，所以只需要关注从哪个创建入口进入，观察二者是否一致

1.2、授权策略

1.3、协议类型

1.4、端口范围

1.5、授权对象

1.6、优先级

1.7、描述

1.8、界面展示

2.像这种多种因子的测试，我们尽量交叉测试，这样大大减少工作量.

2.1、正常场景和异常场景创建

2.1.1、我们输入正常场景的数据，创建看能否成功
2.1.2、输入上述数据异常的场景去创建，查看确定按钮，或者是否能创建成功。

比如这种情况就不能出现：

3.1、结合业务
3.1.1、企业安全组创建规则

因为涉及到业务的问题，暂时先举例这么多

七：祝福

最后祝愿每一个developer都成为一名优秀的开发者，在代码的世界里，越走越远。

备注：编写代码的时候记录自测点，可以用xmind或者excel或者笔记本都可以，只要最后罗列出来的都通过测试即可，要有记录。