2018-02-01 20:06:50
Lenovo
- 别人交接给你的工作要及时核对，弄清
- 不要一知半解却不问清楚
- 遇到问题block了你的工作，不要窝在自己手里，抛出来
- 及时汇报进度
- 文档要面向业务小白，描述要清晰没有异议
- 遇到报错要学会自己百度出错信息及看追查程序代码
- bug要复现三遍，清楚复现率
- 遇到问题放弃不管会带来严重后果（openstack虚拟环境保障）
- 舒适区原则，新的任务从不熟悉到熟悉能让你cover更大的区域
Chemanman
- 开发总有一些你不知道的实现细节，会产生致命的bug
- 发现bug,在其他环境（比如正式环境）复现一下，首先排除环境及自己部署原因
- 检查是否按步骤部署
- 是否按需要刷了库，
- 是否需要重建索引，
- 是否需要清理缓存，
- 是否需要开启脚本），
- 部署版本是否正确，
- 开发是正确合并了分支（无缺失，无他人代码），
- 是否师脏数据引起
- 有无权限问题
- 一定要分析定位完问题再交给开发
- 弄懂相关接口字段和数据库表及字段含义
- 一定要分析 用户高频场景，而不单纯从软件设计角度或提测功能角度分析问题
- 版本更新的回归测试，不能只回归提测功能，总有一些关联或是开发的改动影响你是预测不足的。一定要回归基本的功能
- 测试是严格的管控师，有责任提高开发的代码/文档素养，自测不充分，提测格式不对，主流程不通的直接打回
- 要让开发因为自己的简单错误感到羞耻，并证据充分
- 问题指于我，遇到反馈及时相应，团队中不推诿
- pms传递结论性东西，不传递讨论过程（会干扰开发了解问题）
- 自己提或负责的bug要持续跟进（已经指向下个人之后）
- 对于提测任务一定要尽早了解需求，特别是中途介入的，一定要立即弄清楚各种逻辑
- 用例要产品评审
- 需求要读3遍，梳理完整
Spicespirit
- 不要相信开发
- 对数据对数据对数据，重要的事情说三遍
- 需求分析：Form表单类，操作流程类，状态迁移类->界面化，根据各输入框组成规则或业务逻辑限制用等价类组合正常用例和异常用例，异常包含，空，错误，多次错误，超长及破坏性
- 流程分析各条路线，及逆向，多次重复，反复逆向，及破坏性测试，注意各步的触发及实现细节（触发的数据库多个表/redis/队列等的变动等）
- 开发延期要及时风险报警
- 产品推动/项目经理推动/测试推动
- 要弄懂公司的所有技术架构
Self
最近帮朋友编写了一个基本的爬虫框架，交付后被发现种种问题：解了两天bug，个人的一点心得：
开发为什么会写出bug:
- 需求理解不充分，设计时就漏掉了某个限制或少了某个字段
- 所期非所得，这和熟练度有关，但开发过程中难免会需要使用新的库/API/函数，实际运行与开发设想的不一致
- 偷懒和简化，比如我在提取页面某种格式url的没有先用某种解析器解析出所有的链接，而是直接将页面源代码读取出来，使用正则匹配，结果遇到贪婪匹配的问题，需要配合比较复杂正则才能解决
- 意念式改动：这里有个段子：以前问一朋友为什么总是不回消息，他言：平时下班比较类，看到不太要紧的消息就直接用意念回复了。一个方法修改，有可能修改了存储数据库的值，却忘记了修改方法的返回结果。
- 平台因素，比如mac不严格区分大小写，比如Windows和mac文件结尾符不一样，比如python2和python3不一样的问题
- 开发一般很少关注，怎么测试的问题
- 自测不充分，开发一般会在调试过程中进行一部分测试，但是覆盖度远远不够，实际编写自测用例，比如模拟终端交互，提取函数内部方法，写mock，构造数据，分析各个路径，以及构造各种异常情况所要耗费的精力甚至要3-5倍编写功能的时间
- 抱着交差就行，可用就行的心态
个人总结对bug的处理的境界
- 初级测试：主要验证软件操作及返回，发现页面前端bug,主流程操作bug,问题直接抛给开发，只关注软件开发逻辑
- 中级测试：测试结果会核对数据库，出bug会简单的定位前端/后端的问题，抓包，log,会复现问题，提bug规范，带环境信息，预置条件，清晰的复现步骤，期望结果，实际结果，复现概率等
关注用户实际场景 - 高级测试：根据请求接口字段，对比接口文档，根据出错信息，定位代码，分析代码，定位bug原因，调试代码，解决bug方案
关注非性能问题，如并发，效率，规范，及未来的适用性，内存泄漏，架构等等 - 专家级别：测试驱动开发，性能调优，代码走查，发现其他可能bug
@ 感谢 孙磊/晓光/保江/柳静/何明 等给予的批评及指正