软件测试经验与教训评论.docx

软件测试经验与教训评论

第一篇：软件测试经验与教训评论评注作者：傅健，[e-mail](转载请注明作者)经验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：任务完成时间评估，应由掌握最佳知识的人进行，或