测试经典书籍中的观点（二）

《探索式软件测试》

---

"用户购买功能的同时也在忍受缺陷。" --史考特·沃兹沃思(Scott Wadsworth)

• 开发人员只能是个糟糕的测试者

如果开发人员善于发现缺陷，那么为什么不在编码的时候避免引入呢？从开发的角度去做测试，必然会有盲点。测试人员从“更好使用”的角度去测试，而不是开发人员的“如何实现”的角度去评估产品，会避开开发人员固有的偏见。当然，在开发阶段，单元测试是必须由开发人员进行的，例如数据验证，格式化，异常条件。

 

• 自动化测试的“坏”

1) 花大量时间编写测试代码，调试，进而重复编写

2）维护自动化测试代码时间增加了，真正测试的时间减少了

• 探索性测试-手工测试最好的技术

缺点： 测试人员漫无目的的尝试各种情况来找出bug . 

《软件测试实战-测试web msn》

---

ps : 看到书中一句话：培养测试思维-你能想到什么程度，测试工作就能做到什么程度。 希望读完这本书，能够对测试的程度做更深的理解。

 

• 提纲挈领做测试

接触到一个项目后，第一件事并不是立刻模块化测试，而是从整体上理解。

 

• 推动需求或流程的优化

ps: 推动流程优化，几乎是每个测试人员必须进行的一件事。 推动流程方面的优化一般包括：

1. 需求的完善（需求对后续开发测试的不利，进而针对性完善）；
2. 开发提测的完善（如何完善提测，减少P1,P2级别的bug）;
3. 推动项目中典型bug的减少；
4. 质量中存在的问题/如何进一步提高产品发布质量；

注释： 测试人员的所有工作围绕的核心不外乎以下几点：

1）不断推动产品上线的质量（包括对需求，提测，流程等等的推动；各种方法论）；

2）不断提高测试的效率（通过各种测试工具减少测试时间，减少回归时间，更精确测试）；

3） 不断发现进而提取预防或完善产品的极限（各种测试手段发现系统的局限在哪里，系统的“承受”极限在哪里；系统的风险点，实现程度对用户的影响等等）

• 性能测试vs压力测试

ps: 前者是评估产品在普通场景下的性能（响应时间，CPU，内存等等）； 压力测试是评估产品在极端场景下的性能（响应时间，CPU，内存等等）。例如，如果平常的用户量是10w, 那么性能测试是测试10w人使用情况，而压力测试是测试10w+（如30w,50w，持续n天），情况下系统情况。

 

• 白盒测试+单元测试

ps : 越关注开发人员的具体实现，越容易陷入一个细节当中。

 

• UI测试

ps： 一些通用项罗列：

页面元素的通用规范；

浏览器兼容；

残疾人员支持；

快捷键支持；

界面一致性-要求：与现有的界面风格尽可能一致界面友好性-要求：视觉上不存在明显冲突，满足视觉美感。易操作性/一致性-要求：主干功能设计，元素样式满足[普遍认知]，对功能使用没有异议兼容性-要求：能够应对未来或可能的功能扩展

 

• bug/风险与上线

ps :  有关上线前对质量的要求，特别是UI方面的要求，线上产品和非线上产品相差很大。对比线下产品，线上产品上线更谨慎：

1）上线有功能bug或者风险点时，是否上线（甚至有规定，此时产品要提前通知产品总监进行审批）

2） 对UI风格要求十分严格的线上产品，需求文档中做的修改需要通过审批（因为一个线上产品，很可能因为产品“孤立”的上线后，因为之后用户对UI的不适应，带来大影响）

3） 上线质量和上线时间冲突时，通过加班加点改善质量，其实这“赶”上线的过程，其实本身也存在某种风险。

 

• 项目中可能遇到的问题

1） 开发人员 随意开发出一个版本，扔给测试人员测试。

这种情况明显会加大测试人员的工作量。此时推动开发人员进行自测就尤其重要。 

2） 开发人员需要在较短时间内完成一个全新项目的开发

在很多实际类似的项目中，此类项目提测后发现的bug数量较多。开发人员自测不充分只是一小部分原因，更多的来自 测试自己代码中的风险：开发人员对 全新项目 把控的局限性。 接触过很多能力很强的开发人员，但在新而大的项目开发时，此类项目中产生的bug远远多于其他项目。

3） 发现了不能出现的bug---首先要做的是记录它，拉上各方人员去讨论研究它

测试人员很纠结的一种问题是，发现了一个bug, 但却重现不了这个问题，或者一个bug反复重现，开发却找不到具体原因（真实一个bug: 同时开多个页面时，总有页面显示会“缩小”，样式加载不出；刷新一个页面，另一个页面样式加载不出；反之亦然）。

4） 可怕的思维定势

ps:受限于 思维和经验，往往可能遗漏一些点。为防止此类事情发生：

A : 参考别人的测试点，总结同类项目中共同测试点；

B : 做一些随意的，探索性的测试；

C : 看测试书籍，站在巨人的肩膀上，才可以看得更远

D : 多结合用户使用习惯，用户的意见

 

5） 如何对待一个显而易见的bug

ps ：最重要的是，如何减少或避免显而易见的bug

6)  发现了一个无法修正的bug

抛出去，修不修，如何修，修到什么程度，大家来定。

 

• 不要把测试团队归在开发团队旗下

开发的任务是把产品开发出来，在产品质量上有时候对“自己的孩子”下不了手， 如果开发管理测试团队的话，势必有意无意的降低质量标准。