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

shinta

所谓漏测，是指软件产品的缺陷没有被测试组发现而遗漏到了用户那里，却最终被用户所发现。如果产品在用户那里出现问题，产生的后果是非常严重的。在软件开发过程中，缺陷越早被发现，发现和解决缺陷所花的成本就越小。如果缺陷是在测试组测试中发现的而不是被用户使用时发现的，那么所花的成本将小得多。如果缺陷是被开发组在开发过程中发现的，那么所花的代价将更小。因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。

shinta

压力测试        系统长时间运行是否会出现死机的现象的测试
        系统长时间运行是否会出现SESSON丢失的现象的测试
        长时间运行，是否会出现连数据库不成功的现象的测试
        大量数据导入导出是否会出现死机的现象的测试
        同时打开多个应用程序的测试的测试

shinta

安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图

joy123

灰盒测试，介于前两者之间，灰盒测试关注输出对于输入的正确性，同时也关注内部表现。  
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

wgw1230

测试的风险问题:
如果一个项目确定了截止日期,开发又不断地延期,管理层又不断地强调要保证项目的质量?测试工作该如何组织和管理？

alfa_23

自动化测试一般用于回归测试

alfa_23

自动化测试工具有qtp，silktest。loadrunner，等等

alfa_23

测试分为单元测试，系统测试。集成测试，

walker1020

原帖由 alfa_23 于 2009-4-29 15:42 发表
自动化测试工具有qtp，silktest。loadrunner，等等

根据多数人的观点，LoadRunner是性能测试工具，不是自动化测试工具。莫非你说的是 winRunner?

hnnx

参与有奖

nany1999

我回

nany1999

我回

nany1999

我会回

mvjh13

对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。
对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。
但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，
并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，
要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，
就可以通过测试去验证产品在多大程度上满足了客户需求。
对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。
由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ”
测试经理的一个重要职责。
高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。
我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。
在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量

默默巫

原帖由 nany1999 于 2009-4-29 16:16 发表
我会回

压力测试        系统长时间运行是否会出现死机的现象的测试
        系统长时间运行是否会出现SESSON丢失的现象的测试
        长时间运行，是否会出现连数据库不成功的现象的测试
        大量数据导入导出是否会出现死机的现象的测试
        同时打开多个应用程序的测试的测试


这位会员请看清活动规则后发贴,屡次犯错的话要扣分了哈.

心中有彩虹

性能测试很有前途，但还不会，努力学习loadrunner中。
默默送我牌牌！

mvjh13

什么是 “ 可测试性 ” ？软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。

以下是一个常见的软件可测试性检查表：
· 可操作性－ “ 运行地越好，被测试的效率越高。 ”
· 可观察性－ “ 所看见的，就是所测试的。 ”
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化。 ”
· 可分解性－ “ 通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。 ”
· 简单性－ “ 需要测试的内容越少，测试的速度越快。 ”
· 稳定性－ “ 改变越少，对测试的破坏越小。 ”

水上飘

动态黑盒测试

       不深入代码细节的软件测试方法。常被称为行为测试，因为测试的是软件在使用过程中的实际行为。

       首先，从产品说明书获知测试对象的软件的输入和应该得到的输出。
   
       接下来，开始定义测试案例。 测试案例：指进行实验用的输入，以及测试软件用的程序。
         
       选择测试案例是软件测试员最重要的任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把不可穷近的可能性减少到可以控制的范围是成功的诀窍。

   测试基本方法：通过测试 vs   失败测试
  
       通过测试：确认软件至少能做什么，而不考验其能力。

       失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称为迫使出错测试。蓄意攻击软件的薄弱环节。
   
       在设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。
   常见的测试案例就是设法迫使软件出现错误提示信息。产品说明书可能会给出这样的功能要求，针对这个问题的测试可能是通过测试也可能是失败测试。可能两者都是。不用去刻意区分，重要的是找到软件缺陷！

选择测试案例：等价分配

       等价分配：是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。也称等价划分。

       等价分配技术提供了一个选择哪些数值、舍弃哪些数值的系统方法。

       等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。
       等价分配的目的是把可能的测试案例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险。如果为了减少测试案例的数量过度进行等价分配，测试的风险就会增加。另外，等价区间的划分没有一定的标准，只要足以覆盖测试对象就行了。

数据测试

       软件由数据（包括键盘输入、鼠标单击、磁盘文件、打印输出等等）和程序（可执行的流程、转换、逻辑和运算）两个最基本的要素组成。

       对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件、次边界条件和无效数据。

       1. 边界条件测试

       程序在处理大量中间数值时都是对的，但是可能在边界处出现错误。比如数组的[0]元素的处理。想要在Basic中定义一个10个元素的数组，如果使用 Dim data(10) As Integer ，则定义的是一个11个元素的数组，在赋初值时再使用 For i =1 to 10 ...来赋值，就会产生权限，因为程序忘记了处理i＝0的0号元素。
       边界条件是指软件计划的操作界限所在的边缘条件。

       数据类型：数值、字符、位置、数量、速度、地址、尺寸等，都会包含确定的边界。
       应考虑的特征：第一个/最后一个、开始/完成、空/满、最慢/最快、相邻/最远、最小值/最大值、超过/在内、最短/最长、最早/最迟、最高/最低。这些都是可能出现的边界条件。

   根据边界来选择等价分配中包含的数据。然而，仅仅测试边界线上的数据点往往不够充分。提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。以下例子说明一下如何考虑所有可能的边界：

莫玉岩

软件测试与质量保证
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作；
质量保证：通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产特
软件测试：通过执行软件来，对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量

mvjh13

测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－
我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合
用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件
完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。