欢迎访问 天网 的个人空间

我的文集

  • 第182贴【2005-01-20】:测试计划--挂起准则和恢复需求

    2005-01-20 18:37:01   /   [每日一贴]

    测试计划这部分内容的目的是:找出所有对测试进行暂时挂起的条件和恢复测试的标准。测试人员在执行测试的过程中往往都备受折磨,经常会遇到一些导致测试执行困难的事情。在遇到这些困难的时候,虽然也欣赏测试人员排除万难继续前进的精神,但有时候继续执行测试是毫无意义的事情。以路由器测试为例,在路由转发基本功能测试中出现重大缺陷的情况,继续测试路由转发性能是毫无意义的,测试出的性能指标也无任何指导作用。甚至有些时候,某个特性的测试不通过,会导致其他特性无法执行测试,大量用例被堵塞。这时候可以用甘特图来显示测.
  • 第181贴【2005-01-19】:测试计划--测试项通过/失败准则

    2005-01-19 11:32:48   /   [每日一贴]

    测试计划的这个部分描述每个测试项的通过/失败准则。正如每个测试用例都需要一个预期的结果那样,每个测试项同样需要一个预期的结果。一般来说,通过/失败准则由通过和失败的用例、bug的数量、类型、严重性和位置、可使用性、可靠性和/或稳定性来表述的。随着等级的不同和组织的不同,所采用的确切标准也会有所不同。每个用例的重要程度等级是不一样的。尽管执行测试用例的百分比是一个常见的度量,但它经常会提供误导信息。比如,核控制设备的测试中,即使95%的测试用例获得通过,但是“核切断开关“的测试失败,那么其他的用.
  • 第180贴【2005-01-18】:测试计划--方法

    2005-01-18 10:38:26   /   [每日一贴]

    测试方法是测试的核心所在,所以有些组织更愿意将其标记为“策略”而不是方法。这部分内容包括:描述如何进行测试、解释对测试(并不是对被测项目)的成功与否起决定作用的所有问题。对总体测试计划而言,应该对各个测试阶段所采用的方法(包括从一个阶段到另一个阶段的入口和出口准则)进行解释。标准的测试阶段有单元测试、集成测试、系统测试和验收测试,有些组织会根据实际情况对这些阶段进行合并、删除或增加,或者对这些阶段取不同的名字。每个阶段是在特定的环境下定义的,环境中可能包括硬件配置、软件配置、接口.
  • 第179贴【2005-01-17】:测试计划--待测特征和不予测试特征

    2005-01-17 15:31:54   /   [每日一贴]

    测试计划中待测特征这一部分列出了待测的内容(从用户的角度出发),这与测试项相反,测试项是从开发者的角度对待测内容的度量。例如,如果要测试某台自动取款机(ATM),其中的待测特征可能包括:取款、存款、查询帐户余额、转帐、偿还贷款等。对于较低等级的测试而言,待测特征可能还要详细得多。测试计划中不予测试特征这部分用来记录不予测试的特征及其理由。对于某个特征不予测试的理由很多:可能该特征前后版本没有发生变化、可能因为该特征还不能投入使用。。。但是,一个特征之所以被列在这个部分,是因为它被归结为具有.
  • 第178贴【2005-01-14】:测试计划--测试项

    2005-01-14 11:31:11   /   [每日一贴]

    测试计划的这部分主要是纲领性地描述在测试计划范围内需要对哪些内容进行测试,以及应该与配置或程序库管理者和开发员协作完成哪些工作。这部分内容可以面向测试计划的等级来完成。对于较高的等级,这部分内容可以参照应用程序或版本来组织。对于较低的等级,这部分内容可以参照程序、单元、模块或者构建来组织。例如,如果这是一个财会软件总体测试计划,这部分内容可能包括与财会软件的2.2版、用户手册的1.2版和需求规格说明的4.5版相关的信息。如果这是一个集成或者单元测试计划,这部分内容实际上可能会列出待测程序(如果这些程序.
  • 第177贴【2005-01-13】:测试计划--参考文献

    2005-01-13 11:42:43   /   [每日一贴]

    IEEE推荐的参考文献包括:。项目授权。项目计划。QA计划。配置管理计划。相关政策。相关标准IEEE标准还规定,在多等级的测试计划中,每个较低等级的计划必须要以相邻的较高等级的计划作参考。另外还有一些需要考虑的参考文献,包括需求规格说明、设计文档和其他能够提供额外相关信息的文档。列在这一部分的每一项都应该包括文档名、日期和版本,以及联系位置或联系点。参考文献增加了你们的测试计划的可信度,同时便于读者确定哪些主题值得进行进一步研究。
  • 第176贴【2005-01-11】:测试计划--测试计划标识符

    2005-01-11 12:20:35   /   [每日一贴]

    为了跟踪测试计划的最新版本,需要为其指定一个标识数。如果软件组织有自己的标准文档控制系统,那么会自动赋值,用于标识测试计划的版本、等级以及与该计划相关的软件版本。测试计划和其他软件文档一样,本质上是动态的,需要及时更新。在对软件组织的测试计划进行审核时,需要对测试计划标识符进行审核。如果没有标识符,那么这意味着建立了测试计划后从未进行过变动,甚至可能从未使用过。更有甚者,测试计划仅仅是为了完成一项任务而进行的写作活动,没有任何指导意义。
  • 第175贴【2005-01-10】:测试计划--测试计划文档的各个组成部分

    2005-01-10 18:37:39   /   [每日一贴]

    IEEE标准829-1998软件测试文档编制标准测试计划模板目录1。测试计划标识符2。目录表3。参考文献4。词汇表5。介绍6。测试项7。待测特征8。不予测试的特征9。方法10。测试项通过/失败准则11。挂起准则和恢复需求12。测试交付物13。测试任务14。环境需求15。职责16。人员安排与培训需求17。进度表18。计划风险与应急措施19。审批
  • 第174贴【2005-01-07】:测试计划--计划模板

    2005-01-07 15:56:03   /   [每日一贴]

    软件组织有必要制订自己的测试计划模板,建议在参考IEEE标准829-1998软件测试文档编制标准的基础上结合自身的实际情况制作,它能为建立自己的自定义模板提供一个良好的基础。在许多情况下,IEEE模板可能已经符合软件组织的需求而无需变动,这时可以直接拿来应用。如果模板不能符合企业的具体要求,可以随心所欲的按照需要对其进行自定义。随着应用时间的增加,你可能会发现在模板中某些项总是留下空白,如果你能确信这些项与你们组织没有太大关系,那么可以调整模板,把这些项目去掉。如果某些措词在各个计划中都是相同的,那么.

我的资料

  • 用户组: 白银元老
  • 发帖数: 745
  • 发短消息
  • 注册日期: 2004-05-10
  • 更新日期: 2015-08-03
Open Toolbar