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

ljonathan

一定要记住测试工具只是手段，不是目的

sunqiang1024

测试包括白盒，黑盒，灰盒测试

sunqiang1024

测试工具有QTP，LR，CQ，QC，testmanager，robot，很多工具

freedomwar3

测试驱动开发（Test Driven Development,英文缩写TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。
概括起来，测试驱动开发的基本过程如下：
　　(1) 明确当前要完成的功能。可以记录成一个 TODO 列表。
　　(2) 快速完成针对此功能的测试用例编写。
　　(3) 测试代码编译不通过。
　　(4) 编写对应的功能代码。
　　(5) 测试通过。
　　(6) 对代码进行重构，并保证测试通过。
　　(7) 循环完成所有功能的开发。

lq1107

自动化测试十大要点        
当一款自动化测试工具引入到一个项目中，我们通常对它给予很高的期望；项目成员希望工具能够尽可能的缩小测试范围、节约成本并缩短项目进度，然而可悲的是，很多采用自动化测试的项目依然失败了。
        以下几个方面严重影响着自动化测试的效率，如果处理不当，将会造成事倍功半甚至前功尽弃的后果，自动化测试也成了一副空架子。

        一是测试的范围：想要百分百的实现自动化测试是不现实的，而且从时间投入上也是不可行的；有选择性的挑选应用程序的一些功能或区域模块，采用自动化测试。

        二是测试时间的准备工作：自动化测试脚本的开发时间必须考虑在内，一般来说，开发测试脚本的时间要比手工测试多出三分之二，因为现实里工具会在初始阶段增加测试的范围；因此，对自动化测试保持适度的期望值很重要：工具不能取代手工测试，更不能代替测试工程师。测试初始阶段，投入会比较大，当自动化完成后，将会大大缩短后续的版本的测试时间。
        三是投资的回报：自动化测试的准备工作如此漫长，据说自动化测试的效益只会出现在测试被执行三次以后的时间里。
        四是何时获得自动化测试的收益：定位合适的测试目标，并认真分析自动化测试的收益出现在何时、何处。如果测试程序频繁进行大幅度变更或修改，还是放弃自动化测试吧！－你将会耗费相当的时间去修改测试脚本，但收益是微乎其微的。（但是，如果应用程序频繁变更的模块彼此独立，或者修改较小，或者只是特定区域的变更，那么仍然可以成功采用自动化测试。）另外，谨记只有当应用程序将近发布时，才可以进行完整的自动化测试；如果应用程序缺陷太多，功能点运行失败，想要运行全面的测试套件程序是不太可能的。
        五是变更的程度：自动化测试最适合用于回归测试，将那些已经存在并相对完善的功能进行自动化测试；例如应用程序1.0版本的功能模块已经稳定，没有引入1.1版本的新功能，这种情况下，我们对其制订自动化测试计划并设计测试脚本，不至于因为简单的GUI变更（例如某个控件改名或移动）而使脚本无效。我们也需要将修改脚本的时间考虑在内，例如，如果应用程序的版本升级造成很大的功能改变，那么也许要全部重新书写测试脚本，这种情况是我们不愿意看到的。但是，如果只是某个相对独立的功能模块发生变更，或者变更较小，我们可以成功的实现在回归测试里的自动化。
        六是测试的完整性：我们如何度量一个测试是否通过或失败呢？单单凭借工具返回的“pass”不足以证明测试本身通过无误，例如，没有错误的提示信息出现并不意味着脚本的下一步动作能够成功进行。因此这一要点需要在规划测试脚本的通过与否标准上考虑在内。
        七是测试的独立性：测试的独立性应该被考虑在内，从而不至于某一个测试用例的运行失败引起全局影响，甚至阻止整个测试套件程序里其他脚本的运行；但是，在实践中对该问题的把握并不容易，需要一定的努力达到此目标。

        八是对测试脚本本身的调试和测试：必须花费一定的时间进行该工作，以检验测试本身的完整性。

        九是录制/回放：不要完全把工具的录制/回放功能作为创建测试脚本的唯一方法，这个观念是很重要的。测试者在后台运行测试工具，再手工执行测试，工具将测试者的动作记录下来，自动生成一个脚本，以便测试者可以重新运行测试动作，这虽然是个好想法，但对测试工作本身并无太大意义。

        十是对测试脚本的维护：最后一点，对自动化测试脚本的维护是一个高投入的工作，脚本必须持续的更新，否则一旦应用程序有太多的变更而要修改测试脚本时，你会因为一下子需要上百个小时而考虑是否值得这样做，从而最终放弃自动化测试。因此，测试脚本每次更新时，对其进行文档化管理是必要的。

lq1107

软件测试过程模型
针对每个测试级别，将适当的执行如下活动：

一、创建测试策略：

输入：
· 要求硬件和软件组件的详细说明，包括测试工具（测试环境，测试工具数据）。
· 针对测试和进度约束（人员，进度表）所需资源的角色和职责说明
· 测试方法（标准）
· 应用程序的功能性和技术性需求（需求，变更请求，技术性和功能性设计文档）
· 系统无法提供的需求（系统局限）

输出：
· 已批准和签署的测试策略文档，测试计划，测试用例
· 需要解决方案的测试项目（通常要求客户项目的管理层协调）

过程：
· 测试策略是关于如何测试系统XYZ的正式描述，要求开发针对所有测试级别的测试策略。测试小组分析需求，编写测试策略并且和项目小组一起复审计划。
· 测试计划应该包括测试用例和条件，测试环境，与任务相关的测试，通过/失败的准则和测试风险评估。测试进度表将识别所有要求有成功的测试成果的任务，活动的进度和资源要求。

二、创建测试计划/设计

输入：
· 已批准的测试策略文档。
· 如果测试工具适用，自动化测试软件和以前开发的测试脚本
· 作为一种测试的结果（有关测试文档的问题），测试文档中没有说明的问题
· 从概要和详细设计文档（软件设计，代码和复杂的数据）中导出的对软件复杂性和模块路径覆盖的理解

输出：
· 设计时发现的问题反馈给开发人员（软件设计，代码问题）
· 已批准的测试场景，条件和脚本（测试设计，用例和脚本）
· 测试数据

过程：
·通过复审发布版本的功能需求和准备能够更好的拆分为测试脚本的业务功能逻辑集合，准备测试场景和用例。测试将定义为测试条件，用于测试的数据和期望的结果（数据库更新，文件输出，报告结果等等）。将可能在应用程序中出现的既普通又异常的情况描绘为测试场景。
·项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前，开发人员同时也负责执行单元测试用例。
·在开发人员和客户的协助下，测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下开发。
·通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。
·在测试之前，捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照，一些输出的数据也被基线化。在回归测试时，基线化的数据用于支持以后的系统维护。
· 为评定应用程序的就绪情况、环境和被测试的数据，应召开测试准备会议。为了指出发本版本的入口标准状态，应创建测试就绪文档。

三、执行测试

输入：
·已批准的测试文档（测试计划、用例、程序）
·如果适用测试工具，自动化测试软件和编写好的脚本
·设计的变更（变更请求）
·测试数据
·测试和项目组的可用性（项目人员，测试小组）
·概要和详细设计文档（需求，软件设计）
·通过配置/构建人员能够完全转移到测试环境（单元测试过的代码）的开发环境
·测试就绪文档
·修订文档

输出：
·代码的变更（测试修复项）
·作为一种测试的结果（测试文档问题），测试文档没有说明的问题
·设计时发现的问题，反馈给开发人员和客户（需求，设计，代码问题）
·测试事故的正式记录（问题跟踪）
·为向下一级别转移而准备的基线化包（已测试的源代码和对象代码）
·测试结果的日志和总结
·已批准和带有修订测试交付项的签署文档（已更新的交付项）

过程：
·在执行阶段中应召开Checkpoint 会议。(如果由需要，)每天应召开Checkpoint 会议处理和讨论测试中的问题，状态和活动。
·通过采用系统的手段跟进测试文档来完成测试的执行。当执行测试程序的每一个包时，为了记录程序的执行和测试程序找出的任何缺陷，应该将问题记录到测试执行日志中。测试程序执行后的输出当作测试结果。
·为了确定是否可以得到预期的结果，测试结果应该由适当的项目组员评估（，适合于测试的所有级别）。记录并和软件开发经理/程序员讨论所有差异/异常，为了以后的调查和解决应该将它文档化（每个客户可能有不同的记录日志和报告bug/defect的过程，通过Configuration Management (CM)小组校验这些过程）。通过/失败的准则用来确定问题的严重级别，结果记录到测试总结报告中。
·根据客户的风险评估来定义在系统测试中发现的问题严重级别并记录到他们选择的跟踪工具中。
·基于问题的严重级别有目的的修复并提交到测试环境中。被修改的问题应进行回归测试并将没有问题的修复项转移到新的基线中。在测试完成后，测试组的成员应准备一份总结报告。总结报告要由项目经理，客户，SQA和/或测试组长复审。
·在证实达到一个指定的测试级别后，配置经理应根据配置管理计划中的要求整理发布的软件组件并转移到下一个测试级别。软件只有在客户正式验收之后才可以转移到生产环境中。
·测试小组在复审测试和更新的文档中发现的测试文档的问题。有些问题可能是由于技术性和功能性之间的不一致或修改所造成的。

jinchaojch0

CMMI体系的五个级别是
1.初始级
2.可重复级
3.已定义级
4.已管理级
5.持续优化级

movestar

划分等价类：
  等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

movestar

一、创建测试策略：

输入：
· 要求硬件和软件组件的详细说明，包括测试工具（测试环境，测试工具数据）。
· 针对测试和进度约束（人员，进度表）所需资源的角色和职责说明
· 测试方法（标准）
· 应用程序的功能性和技术性需求（需求，变更请求，技术性和功能性设计文档）
· 系统无法提供的需求（系统局限）

EVA1987

软件测试可以在一定程度上提高软件的质量，但是无法完全保证软件的质量！

movestar

这两天五一很多人都不在啊，呵呵


测试过程控制

合理的进行测试人员的组织与分配，按功能模块并结合测试人员的实际情况（人员素质、测试业务水平、工作态度）进行测试工作的安排（界面测试（风格、字体、提示信息、布局等）可安排一般测试人员）、功能和性能测试需有较深资历的人员进行测试）。

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

movestar

测试技术的选择基于下面的几个因素，包括：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现缺陷类型的经验等。
有些测试技术适合于特定的环境和测试级别；而有些则适用于所有的测试级别。

耶罗

质量是满足部分需求。

new000

从软件开发的过程按阶段划分有

　　
　　A.单元测试
　　B.集成测试
　　C.确认测试
　　D.验收测试
　　E.系统测试

jut984907

测试用例是软件测试的核心

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

movestar

过程：
·通过复审发布版本的功能需求和准备能够更好的拆分为测试脚本的业务功能逻辑集合，准备测试场景和用例。测试将定义为测试条件，用于测试的数据和期望的结果（数据库更新，文件输出，报告结果等等）。将可能在应用程序中出现的既普通又异常的情况描绘为测试场景。
·项目开发人员将定义单元测试需求和单元测试的场景/用例。在集成和系统测试之前，开发人员同时也负责执行单元测试用例。
·在开发人员和客户的协助下，测试小组将开发集成和系统测试的测试场景、用例。验收测试用例将由客户在项目和测试小组的帮助下开发。
·通过使用测试脚本执行测试场景。脚本将定义用于执行一个和多个测试场景的一系列步骤。测试脚本通常描绘在一般的系统操作中会出现的事务或过程。测试脚本包括用于测试过程或事务的特定数据。测试脚本将覆盖多个测试场景并且包括运行/执行/周期信息。测试脚本映射需求和用于保证任何测试都是在范围内的追溯矩阵。
·在测试之前，捕捉并且基线化测试数据。这些数据将作为单元和系统测试的基础和在可控的环境下执行系统功能。为了以后的对照，一些输出的数据也被基线化。在回归测试时，基线化的数据用于支持以后的系统维护。
· 为评定应用程序的就绪情况、环境和被测试的数据，应召开测试准备会议。为了指出发本版本的入口标准状态，应创建测试就绪文档。

walker1020

配置管理工具(configuration management tool)、覆盖率测量工具(coverage measurement tool)、调试工具(debugging tool)、动态分析工具(dynamic analysis tool)、事件管理工具(incident management tool)、负载测试工具(load testing tool)、建模工具(modeling tool)、监控工具(monitoring tool)、性能测试工具(performance testing tool)、探测影响(probe effect)、需求管理工具(requirement management tool)、评审工具(review tool)、安全性工具(security tool)、静态分析工具(static analysis tool)、压力测试工具(stress testing tool)、测试比较器(test comparator)、测试数据准备工具(test data preparation tool)、测试设计工具(test design tool)、测试用具(test harness)、测试执行工具(test execution tool)、测试管理工具(test management tool)、单元测试框架工具(unit test framework tool)。

水上飘

同行评审（Peer review，在某些学术领域亦称审查(refereeing)）为一种审查程序，即使一位作者的学术著作或计划让同一领域的其他专家学者来加以评审。在出版单位主要以同行评审的方法来选择与筛选所投送的稿件录取与否，再而资金提供的单位，也是以同行评审的方式来决定研究奖助金是否授予。同行评审的程序主要针对的是让作者的著作使之符合一般的科学与学科领域的标准。在许多领域著作的出版或者研究奖金的颁发，如果没有以同行评审的方式来进行就可能比较会遭人物议。

304543223

划分等价类：
  等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类

304543223

CMMI体系的五个级别是
1.初始级
2.可重复级
3.已定义级
4.已管理级
5.持续优化级