(软件工程7.pptVIP

第七章 软件测试 案例1 某公司产品开发部开发某网络教育平台软件的工程过程 产品在历时一年半的研发后开始投入测试。测试工作允许的时间为7个工作日。 测试工作过程记录如下 经过7个工作日的测试，得出结果，此系统不可用，需做重大修改。系统经过重新设计，保留了部分原有业务功能和业务逻辑之后重新开发，并进行了测试。测试工作允许的时间为三个月。 测试工作过程记录如下 在最后的系统测试结束后，对测试结果进行了分析，发现如下现象： 第二版中的4000个多缺陷基本包含了第一版发现的600多个缺陷； 相似缺陷较多，例如：如果一个程序员写的模块中发现某个页面邮件输入格式没有校验，那么他写的所有页面中包含邮件数据项的内容都不会校验； 数据校验遗漏较多：如果在一个系统输入了不合法的数据项，那么，整个系统中就会出现几十个数据项合法校验遗漏； 细节错误较多，例如：页面Title不对应的错误在系统中有600多个； 程序设计风格不统一。相同的功能点，如分页、翻页处理，做得五花八门，并且以测试人员的理解来判断是否为缺陷，导致某些功能点在不同页面就能发现个3到5个缺陷。 问题的解决 规范化产品开发流程：产品开发是应该遵循软件工程规范的，开发过程不应该跳过必要的环节。例如这个案例中的产品，无疑就是开始系统设计和评审工作没有做好，才导致二次开发，并且还有一个严重的遗漏就是首次开发忽略了测试工作。测试、质量保证等相关工作应该从立项开始就同步启动。 需求分析要明确：如果开发人员都不知道完成的内容是否正确，而是由测试人员来判断是否符合要求，那简直是需求分析的的巨大“失误”。用户或者设计者想要达到什么目标一定要清晰的描述出来，模棱两可的需求是没有办法设计测试用例的，更不用说进行测试了。 开发人员的调试一定要到位：开发人员一定要认真调试代码，至少要把自己负责的部分和其它模块的接口部分进行 详细的测试。这项由开发人员进行的基础测试是不可缺少的。目标就是把尽可能多的缺陷消灭在开发阶段。本来在开发阶段解决的 缺陷由测试人员来发现会有如下的后果： 耽误进度 转移测试人员注意力 降低开发人员斗志 加强缺陷管理：缺陷管理在这个案例的前期做的不好。在缺陷管理中，我们不但应该把缺陷修改工作能否一次通过 作为考核开发师的标准之一，更应该把一些常见的缺陷是否存在作为考核开发工程师的标准。在经过一定的积累后，开发团队应该形成一些常见的程序缺陷列表，以 引起开发组成员注意。在此基础上，还需要做到：修改缺陷要彻底 、低级缺陷不存在 案例2 在一个正在建设测试团队的组织中，这个研发团队有独立的测试小组，但不是独立的测试部门，产品部经理兼任测试经理。在产品提交给代理商后，代理商发现了一个严重的缺陷，并对其进行了投诉，最终的结果是公司领导层对开发队伍的相关人员进行了一系列惩罚。 在代理商验收测试进行的第三天，测试人员发现了一个严重缺陷——“流转后的文档无法正常归档”。代理商立刻向公司的客户服务部进行了投诉。在此之后的10多天里，代理商的测试人员又陆续发现了近30个缺陷。 问题产生的过程如下： 这个缺陷实际发现过一次，开发人员进行修改时，发现难度较大，决定暂停修改，得到了测试人员的认可； 接着大家忙于新的测试和修改工作； 产品发布前，开发工程师进行了修改，然后直接发布，在开发环境下问题确实得到了解决； 上面案例的执行过程中，有几处显而易见的不合理的地方： 缺少文档，尤其是需求文档。 测试介入太晚。 回归测试做的不合理。 产品发布的出口不对。 缺陷的用户权限控制不严。 没有对每个缺陷进行全程跟踪。 缺少了缺陷审核步骤。 * 在设计测试用例时，我们要同时考虑有效等价类和无效等价类的设计。因为软件不能只接收合理的数据，还要经受意外的考验，接受无效的或不合理的数据，这样获得的软件才能具有较高的可靠性。 那么，如何来划分等价类呢？这是使用等价类划分的一个重要的问题，以下我们将结合具体实例来给出几条确定等价类的原则: * * * * * * 。。。。 。。。。当然不排除两者平行地进行测试一。 * 请看上面的示意图：首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试、检测和排除子系统（或系统）结构上的错误。然后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。 * 既然测试的目的在于寻找错误，并且找出的错误越