xLight.me – building new world

如何写有效的缺陷报告 介绍 缺陷注释 有效缺陷注释的要点 精简 准确 中性的语言 精确 定位 归纳 重现 影响 调试 证据 强化记忆 模板 Bug 的标题 总结 参考 如何写有效的缺陷报告 这是翻译一个名字叫做 Kelly Whitmill 的人写的文章，他在写这篇文章之前有 18 年的 软件测试经验，18 年中主要做为 team leader 来负责通过寻找并且实施有效的测试方法和测 试工具来达到系统的要求，擅长利用有限的资源来尽可能的模拟环境，在自动测试上有浓厚 的兴趣。从大公司到小公司都有过丰富的经历，现在在 IBM 公司工作。 介绍 缺陷报告是测试过程中可以提交的最重要的东西。它的重要性丝毫不亚于测试计划，并 且比其他的在测试过程中的产出文档对产品的质量的影响更大。所以很有必要学习如何写出 有效的缺陷报告。有效的缺陷报告将能够： 减少开发部门的二次缺陷率 提高开发修改缺陷的速度 提高测试部门的信用度 增强测试和开发部门的协作 为什么测试人员从开发那里得到的反馈比从其他部门得到的更多？一定程度上这个答 案就是缺陷报告，依照一些简单的规则可以使整个过程更加顺畅。但是我们的目标并不是写 一个非常完美的缺陷报告，而是能够传达正确的信息，让工作得以完成并且能够简化流程的 有效的缺陷报告。 这篇文章主要讲述缺陷报告的两个方面：1）描述的注释；2）摘要。首先我们先来看 注释。 缺陷注释 下面是确保你下一篇缺陷报告是有效的几个关键点： Condense－精简，清晰而简短 Accurate－准确，这到底是不是一个 bug？还是用户操作错误，或者是理解错…

交易方面 程序执行时间过长 Profile 解决Sql阻塞 + – 使用索引（定位，group，order） 简化sql 不要依赖sql完成计算工作（file sort，join，tmptable、求和） 严格控制那种随着历史数据的积累，exam rows越来越大的查询 当数据量放大到千万级别，exam rows是否能小于2k No sql 数据库是个同时应对很多很多服务(交易、数据、账户、票务、等等)的单点 预先计算 后台计算，并存入Memcache Lucence索引 变化触发索引更新 缓存 缺点：更新慢，缓存失效瞬间会有较大压力 Java或c重构 简化过于复杂的业务需求 要坚信：过于复杂的逻辑会让用户头晕并转身走掉 越来越大的访问量带来的压力 首先、要知道每个程序的负载能力（Requests/Sec）和scale能力（及瓶颈） + – 然后、要知道实际访问量（Requests/Sec），及趋势 要有预警机制 最后、及时扩充服务器 单期方案越来越多 方案列表对db压力大 简化列表逻辑 缓存 外部索引（lucene） 更新方案表时，造成锁表 永远可读 永远可写 过关统计、开奖慢 + – 基于任务的网格分布式计算 注数越来越大的单式方案 + – Map-reduce分布式计算 越来越多的程序，越来越多的故障点 在故障中生存 一次请求的失败不能影响其他请求 坚持做到运维友好 统一、易懂的配置文件 完整的安装、部署文档 做简单的程序 Keep it simple,…

秘密 出现次数 123456789 235037 9位数比8位数多，不过也不相伯仲啦 12345678 212761 11111111 76348 咦咦咦咦咦咦咦咦 下面还有 啊啊啊啊啊啊啊 ，嗯练声呢 dearbook 46053 大家都是去下载电子书的？ 00000000 34953 再多0也是0啊 123123123 20010 定快餐不？4008 123123 1234567890 17794 10位数字 88888888 15033 发发发发发发发发 111111111 6995 9个姨 147258369 5966 这是什么？求解释 987654321 5555 还会倒着数 aaaaaaaa 5460 啊啊啊啊啊啊啊啊，知道你在练声 1111111111 5145 10个姨 66666666 5026 a123456789 4435 终于开始字母数字混合啦！恭喜你荣登使用最多的 “字母数字混合，长度超过8位，字母开头”密码奖 11223344 40961 qaz2wsx 3672 更高级了！…