软件测试之我见.docVIP

软件测试之我见 Mume( Trackback: /TrackBack.aspx?PostId=12037) 我做软件测试有一段不短的时间了，可大量的盲目测试几乎没有增长我的测试经验，每次测试前总有些茫然，不知道自己怎样才能有效的发现软件中存在的缺陷；测试后也不能肯定是否可以放心的发布被测软件。我想可能很多初涉测试的工作者都同我有相似的感觉，我们需要有关测试的理论知识的引导，以下是我读了一些讲解测试技术的书籍后的收获，以及我对我国当前软件业中测试这一领域的认识，希望也能给测试同行点滴的收益。 一、 或许大家会认为软件测试员的工作目标是不言而喻的：就是找软件缺陷，然而《软件测试》这本书为软件测试人员提出了更确切的目标：尽可能早一些找出软件缺陷，并确保其得以修复。在阅读全书并仔细思考后，我觉得此目标包含三大点含义： 1．? 我觉得在这里有必要把这不言而喻的事实再次强调一下，因为有时产品的开发小组要测试员只是为了证实软件可以运行，而不是找缺陷。在这种情况下，测试人员也就缺乏不懈努力发现缺陷的探索精神和热情。所以我觉得在心里坚信不移的认为：软件测试员的基本目标是发现软件缺陷，是做好测试的首要条件。 2．? 因为软件的修复费用，随着时间的推移，将数十倍的增长，所以软件测试员应尽可能早的找出软件缺陷。对大型的软件，在软件开发的同时，就应该有紧随其后的测试，如果等到产品已经开发完毕才开始测试，非常有可能引起大量耗时费力的返工。而如何尽可能早的找出缺陷？《软件测试》这本书向我们介绍了一些理论上的测试方法：静态黑盒测试、动态黑盒测试、静态白盒测试、动态白盒测试；配置测试、兼容性测试、易用性测试……，怎样才能有效的用这些方法尽早的发现软件缺陷，需要大家在工作实践中不断的摸索、总结，进而不断的提高自己的测试能力。 3．? 请注意，我们这里提的是软件测试人员必需确保找出的软件缺陷得以关闭，而不是要软件缺陷得以修复。我们软件测试员需要对自己找出的软件缺陷保持一种平常心：并不是我们辛苦找出的每个软件缺陷都是必要修复的。可能是由于没有足够的时间、不算真正的软件缺陷、修复的风险太大等原因，产品开发小组决定对一些软件缺陷不作修复。 另外，测试员对软件缺陷描述不清楚，也会使软件测试员发现的缺陷被忽略。所以我们测试员必须在描述软件缺陷方面狠下功夫：用简单明了的语句描述软件缺陷；每一件报告尽量针对一个软件缺陷，避免多个缺陷混杂在一起，以致其中一些被忽略或忘却；记录引出软件缺陷的操作步骤，使缺陷得以再现。 虽然我们软件测试员需要对自己找出的软件缺陷保持一种平常心，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。关闭软件缺陷的前提可以是缺陷得以修复或决定不作修复。而缺陷是否需要修复的最终决定权在软件的最终负责人，检查缺陷得以关闭的责任在测试人员。 二、 概念 产品功能说明书：对产品最终需要实现的功能的描述。这些功能是最终确定的需要满足的客户需求，也包括是一些软件必须具备的能力。 在规范的软件生成的流程中，产品功能说明书应在用户需求评审会议召开后，进行系统的概要设计前确定。 原因 1．? 2．? 方法 1．? 2．? 3．? 如果测试人员发现产品说明书不符合以上几点，该怎么做？ 测试人员需要明白，我们的责任是反映产品的缺陷，我们不需要也不能修正产品，所以同发现软件的其它缺陷一样，在发现产品说明书的缺陷后，应该把它们如实并详细的记录下来，呈报给此软件的最终负责人，对并此缺陷的处理情况进行跟踪。 注意同发现的软件其它缺陷一样，缺陷列表应该呈报给软件的最终负责人，而不是给相关技术人员或技术主管，因为技术人员可能会以在技术的实现上有难度为推托，拒绝对缺陷的修改。 目前的可执行度 1．很多软件在开发前并没有书面形式的产品说明书 目前我国的许多软件公司都是小型的手工作坊式的公司，在程序开发前都没有一个正式的、完整的、确定的产品说明书，即便是这种情况，产品说明书也是存在的，它存在在软件设计人员、项目负责人的脑海里，在他们心中都有一个软件的轮廓，假定了软件将要实现的功能。我们的测试人员可以在同他们的交流和不断的询问中获得这个非正式的产品说明书，值得注意的是在我们得到这些信息后还需要以书面的形式把它们一一列举出来，再向相关人员请教，最后做到能完整、准确、一致、合理的描述了产品的功能。 2．测试人员一般不会在项目初期就参与项目 当前还存在着这样一种问题，公司一般不会让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。对这种情况，测试人员可以通过已经建立的软件的雏形，揣摩产品说明书，然后也是同上段所说一样，向相关人员请教，拟定一份书面的完整的、准确的、一致的、合理的产品说说明书。值得注意的是，