背景
以往未完成自测的项目在交付测试时，出现大量低级错误，导致测试部工时投入低效，测试质量不高，所以将开发测试作为交付
提测前的一个重要节点，开发人员必须具有基本的测试意识和能力，确保无重大问题，主功能逻辑畅通，保证交付提测的质量
目的
1、检查设计视觉还原度
2、检查业务流程及功能访问是否符合要求，避免遗漏功能
3、检查页面功能和逻辑是否正常
4、自测是重要环节，加强团队自测意识和规范流程操作
自测要求
1、开发自测用例
根据测试部提供的开发自测用例进行测试
示例：
一级模块 用例名称 优先级 用例类型 前置条件 步骤描述 预期结构 备注
2、问题状态：
待处理、已解决、已验证
功能自测：
● 按照测试环境真实数据以及流程操作系统是否正常
● 检查所有的文案，是否有错别字、是否有语病
● 检查各个菜单导航、面包屑导航是否链接正确
● 检查界面按钮、接口是否已做权限控制
● 接口返回错误时是否做了异常处理，对接口返回字段对的对象或数组是否已判断存不存在的情况
● 检查浏览器控制台是否有报错
● 检查各组件模块是否需要做无数据情况的处理
● 检查网络访问慢的情况，异步操作代码执行顺序是否正确
● 组件销毁的时候，是否已清除定时器
● 检查同一个浏览器，不同标签，登录2个不同账号操作系统会不会产生异常影响
● 检查缓存数据的key是否唯一，会不会有冲突
● 接口通过率100%
性能自测：
● 检查接口请求返回耗时
● 检查静态资源（CSS|JS|图片等）请求耗时
● 检查页面加载速度和渲染速度
● （react）检查组件是否过多的触发了组件render
● 检查界面动画是否流畅
兼容性自测：
● PC端项目优先保证系统在chrome浏览器中正常运行
● PC端项目尽量兼容IE11，避免用户谷歌浏览器除问题的情况下还能正常使用系统进行操作
● PC端项目布局需要考虑小屏幕、小分辨率的情况
● 移动端项目需要考虑兼容安卓和IOS以及每个系统的版本（以产品要求为主）
● 移动端项目需要考虑兼容市场上大部分的主流手机型号（以产品要求为主）
容错自测/异常测试：
● 对于一些不可逆的操作，需要二次确认
● 每个输入框均需要有maxlength
● 提交动作的按钮需要有防止重复提交处理
● 表单校验需要有全局的开关控制，也方便测试人员做后台校验测试
● url中跳转携带的参数必须先进行encode处理
安全自测：
● 对未做校验的输入框的值进行常见的xss攻击，例如 <img src=1 onerror='alert(1)'>
● 敏感数据不存localstorage和cookie，若需要存，是否需要进行加密和混淆处理
● 与金钱相关的系统，要做进一步的安全攻击自测
● vue-cli\create-react-app等脚手架项目发布是否已将sourceMap设置为false
UI交互自测:
● 图片、图标加载是否正常，是否有异常处理
● 文本内容过长处理
● 输入框是否能通过tab键获取焦点
● 输入框是否需要添加回车事件
● 在接口请求或界面资源加载反应比较慢的地方，是否有等待的标识
● 检查风格（界面、布局、控件）是否和整体UI风格保持一致：比如弹出框、消息提示、按钮等
● 需要考虑用户在没有键盘的情况下是否也能正常操作系统
Q&A
1、时间紧，任务急是否需要自测？
确保主线功能正常，明确说明哪些功能模块未完善
参考
自测规范、流程、效果的实际情况
1、只有少数的项目有明确的自测规范和流程
2、没有自测规范的项目往往对自测环节不重视，这需要有人站出来去推进和改善。
3、有明确的规范不等于有好的自测效果。好的自测效果=明确规范+合理的自测内容&时间+真实的执行+及时监控&效果反馈&持
续改进
4、有些项目的自测效果不稳定，受不同开发的个人自测意识影响限制，这可能需要让自测效果好的开发发起一些自测经验分
享、培训，减少不同开发间自测效果的差异性。或者增加自测的执行者，不仅局限在单个开发。
不自测或不好好自测会带来的问题
1、需求遗漏、部分代码合并提交遗漏，这些问题需要按照需求来制定明确的自测内容并记录执行，防止遗漏
2、项目延期：如果不自测，测试花大量的时间沟通低级bug，甚至测试主流程都进行不下去，这样无疑需要更多的开发返工、重
复测试、耗时，最终导致项目延期。如果在项目初期就能计划、预期合理的开发自测时间，保证一定的自测效果，这样其实是更
高效省时间的选择。
自测的方法和方式
1、自测依据：测试&自测用例、测试&自测点、主流程、需求
2、自测依据提供人：测试&开发&双方共同评审后决定（用例、点、主流程）；产品（需求、交互、视觉）
3、自测执行人：开发；产品&交互&设计（验收）；自测巡查小组（监督）；负责不同模块的其他开发（交叉自测、代码审
查）；
4、自测方式：公开演示；自动化执行；接口正常用例跑通；单元测试；功能测试
5、自测执行结果记录：验收kb记录；自测报告
自测效果好的项目经验分享
1、持续监督自测效果（制定低级bug率月目标并监控达成率），定期反馈自测流程问题、不断改进，让自测符合项目特点
2、软件开发完成打包后，在送测前一天，开发集中花半个小时，开发中每个模块功能由对应主要开发和非该模块的开发过一遍
自测用例
3、制定明确的自测规定、自测用例设计规范。记录自测模块及负责人。推行走查发现bug的模式。
4、测试写好用例给到开发评审，ok后 整理完主流程给到开发自测。
5、尽早提供可执行的测试用例，用线上页面或任务的方式，来确保某个人已自测某功能。
6、开发评审测试用例并与测试共同制定主流程用例（自测用例）；送测前建立自测测试计划，模块交叉分配；将环境部署到送
测环境上，在送测环境上执行自测用例。
若送测内容涉及多个开发、模块、端，如何保证集成自测效果
1、引入第三方监督机制，比如建立开发自测巡查小组，让非本项目的开发人员看着开发人员演示功能并接受检查。
2、新需求送测前，由交互、视觉对产品进行一轮验收；然后送测时由一到两个开发负责人负责产品所有模块的自测。
3、交叉自测，功能开发负责人自测自己开发的功能通过后，交由其他开发执行用例
跨端、跨模块 Android/iOS互测：同一端跨功能互测。 互测过程中尽量减小被代码编写人员的逻辑影响，局外人身份参与。
4、开发自测个人开发模块，还有测试联动点，查看数据之间交互是否正确
5、每周固定一天，所有开发对产品进行走查，提出优化、缺陷，提交后由产品、交互决定该问题如何修改，何时安排送测
自测中需要注意的内容
1、思维模式：开发自测时需要走出具体技术实现时用的开发思维，需要站在产品用户、需求的角度上去衡量自测是否通过。
2、工作量：自测工作量需平衡适中。自测效果满足一般要求即可：主流程无明显报错，无阻碍性bug引起的中断。
开发拿到的自测用例如果太重了，就很难去执行。轻量级的冒烟测试用例（仅针对未改动/小改动模块，新增模块需详细点）比较
适用，开发执行效率快且容易发现严重问题，可以提高开发的积极性。
3、积极意义：与其让开发把自测当做任务完成，建议倡导走查模式，鼓励发现问题，给予奖励
4、兼容性：若产品有兼容性需求，开发就最好别每次都用同一台机型或浏览器去自测，可以在不同送测时尝试换测不同的浏览
器或机型
5、执行力：有流程有用例，如果没有执行力都无效
6、自测不仅仅在A1需要，修复bug后的自测也需要执行，否则存在问题被多次打回的可能
7、时间：提前合理计划预留自测时间，而不是压缩测试人员的测试时间
8、环境：开发经常会使用虚拟机进行自测，会因为物理环境与虚拟环境的差异而导致一些低级问题。
对于自测，测试人员能做些什么
1、输出对外部门测试相关的分享，培训，启发开发的测试思维
2、持续关注、监控自测效果、改进
3、及时更新自测用例
