软件测试实践之

《软件测试实践之》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、软件测试实践之测试计划陈雷关键词：软件测试测试计划导读我们中国有句老话：“凡事预则立，不预则废”，说的就是做事情时事先计划的重要。对于软件测试工作，计划的意义也同样如此。在经历过失败的痛苦不断磨练之后，笔者来说说自己从事测试计划工作的一点心得。测试计划<>测试计划文档其实在工作中很多人都混淆了这两个不同的概念，把计划这样重要的事情简单的认为是找到一份测试计划文档模板，然后修修改改，添完空格就算交差了。闭着眼睛都可以想到这份文档的下场——束之高阁。这个计划相当于没有作过。测试计划的目的是尽早的明确测试工作的内容（范围）、测试工作的方法以及测试工作所需要的各种资源，并把这

2、些信息发布给所有涉及到测试工作的涉众，尽快将下一步测试工作需要考虑的问题和准备的条件落实下来。也就是说测试计划工作的重点在于对当前阶段工作任务的准备和规划以及信息的交流。测试计划的时机正如现在大家都在提倡的“尽早启动测试工作”一样，如果你的测试团队在软件开发的需求阶段就介入了项目，并随着项目的进行分阶段的完成不同的测试任务，那么应该在项目启动的初期就开始准备测试计划工作。当然，不要寄希望于一次就可以完成测试计划工作，最好是通过迭代的方法来完成它——在项目的不同阶段获得新的信息后就添加或调整一些内容。测试需求的确定确定测试需求也就是确定测试内容，或者说确定测试的具体对象

3、。可以帮助我们确定测试需求的工件包括软件需求规约、用例、架构设计文档以及详细设计文档等。下面我们以功能测试需求和性能测试需求为例简单说明一下如何获得测试需求。对于“功能性测试需求”，顾名思义，我们所希望表述的是对于系统中描述的功能性行为有哪些地方需要测试。这部分内容我们在项目早期就可以通过对软件需求规约和用例的分析来获得。一般来说，一个明确要求的功能性特性可以生成一条测试需求，用例中基本流或基本流同某些备选流的组合也可以生成一条测试需求。另外，我们还要关注用例间的相互关联和依赖性，这些多个用例间的不同联系也可以分别生成一条测试需求。而对于“性能测试需求”，通常都是包含

4、在“补充需求”中的“非功能性需求”中的，大多是对于某项业务执行时响应时间，或者资源占用率方面的要求。这部分需求提取起来也非常容易，下面的这个问题列表可以帮助你更快的完成这些工作：是否存在对于某项业务在不同的条件下（包括系统资源、硬件配置、网络环境以及数据量等）响应时间必须达到什么要求的描述？是否存在对于单位时间内必须响应多少次业务的描述？是否存在对某项业务或整个系统最大承受用户数量的描述？是否存在对同一时刻允许同时响应的业务的最大数量的描述？是否存在对不同业务进行性能比较的描述？是否存在将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的描述？是否存在对连续

5、长时间工作后性能变化所容许的范围的描述？……上面这个列表虽然不是非常详细和面面俱到，但是也可以帮你找到很多需要测试的内容了。当然，你应该尽量在工作中找到更多的方法并把它们添加到这个列表中来。对于可靠性测试需求、易用性测试需求、安全性测试需求、兼容性测试需求等等，也同样可以在软件需求规约和补充需求中找到相应的描述——如果需求人员已经完成了这部分工作的话。如果你需要测试的是一个业务范围较广、体积庞大的系统，最后生成的测试需求数量可能就会很大。如果希望可以提高检索和维护测试需求的效率，就要考虑使用相应的需求管理工具来分组管理，比如按照业务来分，按照用例来分，或者按照测试类型

6、来分。现在市面上的需求管理工具还可以帮助你建立软件需求同测试需求以及测试用例之间的关联，并且在软件需求发生变更时提醒你对相关的测试需求和测试用例进行修改。风险评估在确定了测试需求之后，我们还需要考虑确定测试对象的优先级和测试实现的先后顺序，以帮助我们在工作时把注意力集中到最关键、最有意义和优先级最高的测试对象上。另外，还可以通过利用业务之间的依赖性，来合理的安排测试过程，提高工作效率。为了确定测试优先级，首先要评估风险。对于风险最高的被测对象，我们应该优先进行测试。对于风险的评估，我们可以从下面三个方面进行考虑。1.重要性和严重性。对于系统中需要测试的对象，要从用户实

7、际业务的角度来考虑，这个被测对象在在系统中起到什么作用？如果它失效了，将会导致什么后果？重点要考虑失效时导致的不良后果。你可以设定多个不同的级别和分值，对严重的后果给一个高分，而不会对业务的完成产生影响的可以相应降低分数。2.原因。如果某个被测对象失效，那么导致它失效的原因是什么？这个原因又是如何出现的？它对系统正常业务的进行还有没有其他的影响？对于导致被测对象失效的原因一样要评估风险。3.可能性。如果一个被测对象可能失效，那么出现这种情况的几率有多高？当然，出现的几率越高，则风险也就越大。对于那些频繁发生的业务或经常使用的功能，发生问题的几率也会同