软件测试经验与教训

#####经验43 测试员要避免遵循过程，除非过程先跟随自己

警惕其他人的过程。测试用例和过程的描述，常常不提测试的内部设计目标。这非常容易使测试员在执行测试时并不太理解如何建立测试、或寻找什么。换句话说，测试员并没有真正跟上过程。一般来说，测试过程的编写和设计都比较差，因为没有多少优秀测试员像擅长计算机那样擅长程序设计人员的工作。如果要遵循测试过程，最后采用自己设计、自己拥有或已经完全了解的过程。
为了得到最好的结果，测试员必须掌握自己的测试，而不是自己的文档。要使过程跟随自己。
如果确信那些过程很好，也至少要眼睛一下过程的工作原理。

个人见解：需要更多的了解程序实现原理，了解的越多也就能发现更深层次的问题。

#####经验45 在创建测试过程时，避免“1287”

我们中的bach曾经见过一位测试员编写的测试过程包含“在字段中输入1287个字符。”这1287是从哪里来的员解释说，她的测试想法只不过是在一个小输入字段中，输入非常多的字符。因为他听说测试过程必须具体，因此小心的数量自己已经输入的字符数，1287.这就是过程中的这个梳子的由来。一个任意数，现在却被供奉起来，就像是印在水泥人行道上的猫的脚印一样。
过于详细的没有什么好处。当编写测试过程时，要避免与测试概念无关的的细化。包含所有必要的信息和设计与解释测试所需要的细节，但是要让未来的测试员有创造性的判断力地执行，让未来的测试员引入变化以使现在所编写的测试过程新鲜，高效。

个人见解：对这个经验深有同感。见过很多人写的测试用例，自己也写过不少的测试用例。很多时候发现用例写的很详细，完全不给执行人员思考的余地。导致用例执行完了还不知道程序到底做了什么，更别说有更深层次的思考。

#####经验56 测试员的程序错误分析会推动改正所 告的错误

测试员写的错误 告是要求改正错误的分析文档。
有些错误永远也不会被改正。测试员的责任不是保证所有错误都得到改正，而是准确 告问题，使读者能够理解问题的影响。
深入研究并写出好的 告，常常对错误改正的可能性产生巨大的影响。

个人见解：有些bug表面看起来影响不大，可修改可不修改，其实可能有很大的坑等着你跳呢~遇到逻辑比较复杂，并且影响面不清晰的情况下，更需要警惕。

#####经验63 决不要利用程序错误跟踪系统监视程序员的表现

测试员非常想 告某个程序员有大量程序错误没有修改，或程序员修改代码的时间太长，或程序员总试图推迟修改，这种愿望太强烈了。但是，使用这种跟踪系统时间估计程序员，或使程序员感到为难之后，其他程序员就会防备这个系统。最有可能的结果是，程序员争辩设计问题并不是程序错误，类似的错误是重复的，不应该 告不可重现的程序错误，测试员不胜任或测试不公平。这并不是没有道理的。只要测试员把程序错误跟踪系统用于行政或人力资源管理，而不是技术管理，人们就会这样对待它。

个人见解：有些公司通过测试员提的bug数量作为绩效考核，产生的bug数量作为程序员的绩效考核标准，个人觉得这个是错误的决定，这会导致程序员和测试员之间互相敌视，测试员提更多的bug（重复的、容易发现或者更肤浅的程序错误），程序员找各种理由辩解，最终谁都不愉快，开展工作越来越难。bug跟踪系统应该是技术管理，而不是人力资源管理

#####经验70 看似极端的缺陷是潜在的安全漏洞

通过因特 的绝大多数入侵，都利用了缓冲区溢出（buffer overrun）缺陷（schneiner 2000a和2000b）。只要测试员不是忙于检查他们“知道”程序员会忽略的极端情况，在产品交付之前本来是可以发现这些缺陷的。可以影响程序操作或导致数据被破坏的任何问题，都是一种司机利用。
如果输入存储区的数据比所分配的尺寸大，就会出现缓冲区溢出。超出的数据会溢出到其他存储空间中。会出现什么情况，取决于这是什么数据以及该存储空间的使用。有时什么也不会发生，有时在屏幕上会看到乱七八糟的东西，有时程序运行很怪异，有时导致崩溃。熟练的攻击者可以利用这种漏洞作为后面，得到对程序或运行该程序的系统的控制。
假设通过在逾期接受一个1~99的字段中，输入65536个9会导致程序崩溃。会有人真的这么干吗，有人当然要这样做。大概不会是自己的朋友，也不会放言“如果有人愚蠢到会这样做，程序崩溃会教训他”的忽略该缺陷的程序员。但是白痴并不是唯一滥用程序的人。
任何会产生严重后果的问题都应该解决，不管其多么“不可能”发生。当熟练的攻击者利用程序中的缺陷得手后，会写下这个消息并广为传播，使得所有脚本生手都可利用。

#####经验97 不要坚持要求修改所有程序错误，要量力而行

有时不修改特定程序错误有很好的理由，最重要的理由之一是风险。每个程序错误修改（以及对代码的其他变更）都会产生新的程序错误。当程序员修改一个小程序错误时，有可能产生更严重的程序错误。如果在项目临近结束时修改程序错误，测试员在修改完成和产品交付之间，可能没有足够的测试时间找出更大的问题。由于害怕不能发现修改陈胜的副作用，有经验的项目经理会对代码变更很谨慎。
另一个很好的理由是客户不愿意为修改付费，定制、合同软件和内部软件开发尤其是这样。客户实际上要为测试所花的时间付费。有些程序错误的处理成本要低于修复成本。即使是远方客户也有价值权衡问题。请想象一下修复了删除客户数据的关键错误更新版本。包含缺陷的程序还在用户场地运行。假设推迟更新版本的安装，以便修改拼写错误。对于这个更新版本的答案是明显的（不要修改拼写错误）。对于不太明显的决策，项目小组负责想象和评估这种价值权衡，以便在时间、成本、可用功能和可靠性几个方便找到合适的平衡点。
如果不能举出某个程序错误很重要的情况，或发现产品项目相关人员足够积极的支持测试员关于退出特定程序错误修改的请求，我们建议还是把那个程序错误放在一边，先考虑其他问题。