[活动]迎五一，庆周年，盖高楼(活动结束)

peterz · 发表于 2009-4-28 15:15:33

黑盒测试主要采用的技术有:等价分类法、边沿值分析法、错误推测法和因果图等技术。

jut984907 · 发表于 2009-4-28 15:16:05

严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

大粽子 · 发表于 2009-4-28 15:16:54

　测试某业数据门户进行功能测试时查看了一下任务管理器，发现IE进程竟然达到了423，145K，怀疑发生了内存泄漏，因此打算直接用IE的插件js memory leaks dector来检测一下，但是进行了一些可能引起内存泄漏的操作后，检测结果一直都很正常，并没有发现关于内存泄漏的地方，开发人员只好自己判断哪些IFRAM没有被销毁来优化系统，降低内存的使用。

peterz · 发表于 2009-4-28 15:17:41

软件测试的一般步骤分为单元测试、子系统测试、系统测试、验收测试、平行测试

medoraemon · 发表于 2009-4-28 15:17:48

α测试规定是企业内部项目/产品在企业内部试用的过程。
根据项目/产品情况，企业高层管理者确定项目/产品是否需要开展α测试。
α测试可以从软件项目/产品编码结束之时开始，或在项目/产品系统测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠性之后再开始。
α测试产品经理主持，产品运维部搭建项目/产品运营环境，需求工程师协助收集新需求，测试经理协助收集产品缺陷。

peterz · 发表于 2009-4-28 15:17:55

软件测试的策略
(1) (1)  在任何情况下都应使用边界值分析的方法。
(2) (2)  必要时用等价类划分法补充测试方案。
(3) (3)  必要时再用错误推测法补充测试方案。
(4) (4)  对照程序逻辑，检查已设计出的测试方案。
(5) (5)  根据对程序可靠性的要求采用不同的逻辑覆盖标准，再补充一些测试方案。

jut984907 · 发表于 2009-4-28 15:18:07

对于缺陷分析，常用的主要缺陷参数有四个：

状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
优先级：必须处理和解决缺陷的相对重要性。
严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

24489024 · 发表于 2009-4-28 15:18:22

报告问题的优先级划分，分为
1、特急
2、加急
3、高
4、中
5、低

peterz · 发表于 2009-4-28 15:18:22

人工复审的方式和作用?
人工复审的方式：代码会审、走查和排练和办公桌检查；
人工复审的作用：检查程序的静态错误。

peterz · 发表于 2009-4-28 15:18:29

人工复审的方式和作用?
人工复审的方式：代码会审、走查和排练和办公桌检查；
人工复审的作用：检查程序的静态错误。

medoraemon · 发表于 2009-4-28 15:18:32

β测试是由企业的外部用户在实际运营环境下进行的使用。这些用户是与企业签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意反馈有关信息给企业。
β测试由产品经理主持，产品运维部搭建项目/产品运营环境，需求工程师协助收集新需求，测试经理协助收集产品缺陷。
只有当α测试达到一定的可靠程度时，才开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。

shenpengjun · 发表于 2009-4-28 15:18:47

白盒测试用例设计方法
1、语句覆盖
2、判定覆盖
3、条件覆盖
4、判定条件覆盖
5、条件组合覆盖
6、路径覆盖

大粽子 · 发表于 2009-4-28 15:18:49

IE内存泄漏的查找不仅需要有一定的经验，还需要有一定的耐心，当然，有一个使用起来有效方便的工具当然更好，现在，对于IE内存泄漏测试我也是刚刚起步，还有很多需要学习的地方，谨以此次测试过程与大家分享，共同进步

raining169 · 发表于 2009-4-28 15:18:54

严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

杨志 · 发表于 2009-4-28 15:18:54

性能测试工具 loadrunner

jut984907 · 发表于 2009-4-28 15:18:59

可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。