<软件测试经验与教训>评注【原创】

 
<软件测试经验与教训>评注
作者： 傅健，jiafu@cisco.com(转载请注明作者)
经验6： 非常赞同，注重线下沟通方式，与开发做朋友，更容易发现更多测试思路，解决好问题；

经验10： 测试过程如若不限时间，很难定义穷尽之时，完美只是在指定时间/成本/质量要求下满足老板的要求。

经验11： 测试不能保证质量，非常赞同这个说话，考虑两个因素：（1）你给的时间和成本是多少？如果是0，提什么保证质量？（2）质量形成与构建者，也受其他人制约，例如三聚氰胺奶粉生产商不知道自己加了嘛？

经验13 ：测试确实应该尽其所能，横向上覆盖产品的设计，开发，发布，售后等过程，纵向覆盖与其他模块的交互；但是需要分析下为什么测试者往往有“不关我事”理论，无非涉及到管理的层面，例如：（1）薪资等不平等；（2）承接模块过多，失去兴趣和信心；

经验14 ：过程改进很伤感情，测试人员在测试前期不应该成为吹毛求疵的挑剔者，如果如此很可能出现两种情况：（1）开发的代码还没有完成阶段，但明知有很多bug之地，这个时候QA不断提出bug,势必影响开发心情。尊重开发的开发过程很重要；（2）开发的设计或许有其他思路，QA不断强调并说服开发者上司采用其他思路，如果不是非常有把握，就不要自作聪明强烈地说服开发者上司，这样最后往往被证明不定合理；

经验15：不要指望别人理解测试，需要不断向别人解释，这点在其他领域也适用，很多时候事实并不是就是事实，而是观察者眼中的“事实”，因此推销是门学问，“指鹿为马”未尝不可做到。

经验21：测试遗漏的问题更多集中在没有想到的用例，而不是执行不力；

经验22：所以进行Code审查更多的是了解设计从来更好的测试，不能指望直接发现代码错误；

经验30：任何量的测试都不能“确定”一个产品的质量，证明失效比证明正确容易的多。

经验31：客户需求多变，或许自己也不明白真正要什么，需求分析即是辅助、辨别需求。

经验32： 隐式规格说明很重要，很多测试依据都是这些“潜规则”，显式说明文档不可能也没有必要面面俱到。

经验33：测试员中的“它没有问题”，与他人眼中不同。

经验34：对质量印象只能限定在已知局限的前提下；

经验35：配置、运行、观察、评估是行为层面的用例；

经验37：对于复杂的任务模块需要间歇思考、细化击破，同样对于测试工作一样，过大的压力，无休止的加班不定有好的测试结果。测试应该有更多的思考时间；

经验39：防止思维定势，提倡多人思考互补，不用去偏执的带有目的去证明缺陷，而是平常心的客观测试。

经验43：应该提倡结对测试，互补思考，同时要攻破“难”点，越复杂之地越容易出问题，且多次出现频率更高。

经验45: 测试用例过于细节话，有可能限制测试者的想象力和创造性，之所以同一个CASE跑出不同的结果往往也和测试用例不过于细节化有关，但我认为不细节化一定程度上是好事情。

经验46：现在很多人还是以BUG数量、测试效果来衡量测试人员的水平，这条经验告诉人们要看测试人员如何思考；同时我们应该加强测试人才的培养与重视，不要仅仅为的是表面化的一些工作；

经验90：同行评审是个培训、提高的好方式；

经验103： 重试不同、多样测试比反反复复运行自动化脚本有效的多；

经验108： 专业培训的测试员的头脑是最好的测试工具；

经验114： 如果不是非常优秀的开发人员，且具有良好的测试思维，就不要开发测试工具，否则一旦推广害人害己，因为测试工具问题往往比普通产品更容易出现；

经验117： 自动回归测试有时候不能将改进和错误区分，特别是界面和输出格式变动；

经验118： 评估开发机构级别五级底部还有个级别是忘却（Oblivious）级，很多自动化测试没有提醒自己在执行软件开发过程；

经验122：评审自动化测试代码比用代码测试自动化测试代码好；因为后者容易陷入一个无限的逻辑；

经验130： 建议测试数据与测试执行分离；

经验132： 自动化是否绕过界面直接操作API取决于到底是界面稳定还是API稳定；尽量依赖稳定的东西；

经验133： 单元集成测试值得执行；

经验137： 提早测试自动化的好处：1）均衡时间，前期可能不是太忙；2）防止后期测试已经进行中要求自动化所带来的抵触心理；3）在开发完成前可以让开发提供更多的可测性；

经验143： 流程、模板都是用来规范人的行为的，只有不断了解、改善才有意义，如果一个流程、模板不允许任何应需改变则无意义；

经验146： 形式化工作越多，往往本质工作预留的时间越少，思维也限制的更固定；

经验148： 自己的测试文档是产品还是工具？这个问题很好；过于频繁的细节不要写到文档里，否则以后更新繁琐；

经验154： 不要利用程序员的弱点或透露的缺陷直接上报，类似于打小报告，以后的合作会减弱很多；

经验157： 测试是一种服务，不是控制，无法控制最终产品的质量；

经验168： 任务完成时间评估，应由掌握最佳知识的人进行，或者由估计错误需要负责的人执行，而不是根据测试经理的主观期望。

经验173： 可以拒绝某个版本的测试：1）新的版本很快就有，这个版本的测试结果会被忽略；2）重要的功能点没有添加；3）基本功能点不工作，导致大部分测试无法进行；

经验182： 提前应对可能风险，将潜在的风险预处理划分到项目的各个阶段而不是后期应急处理；

经验183：测试思考中总体认为产品不是一天做出的，而是慢慢堆积出的，只要有东西提交，就有可测之地，同时越早越好，只是需要抱着同情、谨慎心态等不同心态而已；

经验186：考虑二轮以上测试；

经验189： 测试：开发人员比例这种问题如果不结合具体项目及要求就不要提！

经验197：测试小组的真正力量是沟通，而非监管；

经验199： Bug数随进度推进而不断降低不能完全说明质量已经符合要求，因为后期可能从事非发现缺陷的活动：如展示产品、回归测试等；简单说：当看到BUG数连续几天较少时，不要完全觉得是产品质量变好，而可能是最近没有从事太多新的测试；

经验211： 要给予员工自己的思考、执行时空自由，尊重他们的测试思路，而不是模板化；

经验213： 非常赞同：指明了如何评价一名测试人员的工作，但是很多公司做不到，因为很辛苦。或许他们更倾向于用BUG数来衡量，这样简单明了，虽然不正确。

经验215： 赞同，所以假设必须分配多个任务给同一个员工，不要纠错式的责备某个时刻某个任务没有做好;

经验216： 测试经理在测试产品领域的视角要开阔；

经验220： 多了解员工的期待与现实感觉，不仅仅对于新员工需要这么做，留住老员工也是必须的，否则会出现离职都不知道真实原因的情况。关心员工、与员工做朋友非常重要。

经验225： 不要在项目末尾添加新手，有可能起到相反作用，这点在项目管理上也提到；同时不要为了以后可能有的培训或者职位更换理由，浪费太多时间在文档活动；在开发程序时也一样，不要为了以后可能还用不到的需求做无限扩大需求活动，否则永无尽头且不实际。

经验226：经理应该 客观评价事物，不要不懂装懂，否则容易误导员工，有失公正；

经验227： 不要使自己陷入导致工作失败（如工作量过大）或者没有希望的工作上，最终只会使自己的情绪受到伤害。管理者总是觉得应该给能者更多的工作，而员工则希望更多的休息，如果给予信任的员工更多的工作，最终可能导致其失败并有损情绪，实际上就是摧残而已。

经验228： 测试经理不应该是传话筒，否则有可能是成为不同决策者的执行机器，而应该是中间沟通协调层，保护其员工不受不同决策者的不同观点的影响，但是这种保护应该是正确的观点指导下。

经验235：多样化是项目团队建议的良药；

经验238：跳槽时不要显示对原来公司的不满或泄露原公司的信息；

经验239：速度测验高分只能反映是脑力兔子，或者有可能是训练、练习所致；而低分者可能是脑力乌龟，慢工出细活。

经验245： 从职业发展角度来说，掌握测试技术本身比掌握专业业务逻辑更好，当然这里的专业业务是银行系统等的话，另当别论。

经验250： 面试贯彻2个逐条：逐条解释简历中的每条：逐条解释招聘要求的每个条目为什么自己符合，不符合，但是可以很快学习的地方；

经验252： 和其他公司测试员建立联系，有助于以后的职业发展。

经验253： 如有可能，多休息也是一种缓和跳槽的想法；

经验278：  测试计划经常漏掉如何保障测试策略的执行与工作产品；

经验280：  讨论风险和覆盖率，研究用例内容比单纯统计测试用例数量更有意义；

经验284： 策略决策可利用资源可简单归纳为：人、事、物；

经验285： V字软件测试模型强调软件测试策略早先制定，实际上随着测试的深入，策略会因风险识别的准确度提高等因素而做出调整，因为V不是非常好的项目组织方法。

经验286： 不要将测试局限在某个阶段，抓住一切机会测试可以测试并值得测试的事物；

经验297：项目初期：同情的测试；开发只想知道已经完成的功能的测试结果，不是想知道自己还没有做的功能的测试结果；整个测试按项目发展分为：同情地测试-》积极地测试-》多样地测试=》谨慎地测试；

经验292： 当遇到测试问题过多的模块（可能需要其他设计替换），应提醒开发，不要再痛打落水狗；要测试模糊不清的地方（接口之地、新的技术方案、需求模糊之地）；测试员负责任务之间的缝隙处（交叉部分）容易出问题；

 

总结：

（1）      关注如何思考；

（2）      关注本质，少看数量；

（3）      关注多样化；

（4）      强调结对测试；

（5）      测所有可测之地，越早介入越好；

（6）      不同阶段，拥有不同心态；