1.测试人员和用户的联系与区别

黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。

八个字归纳：用户是用，测试是测。

用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。

应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。

2.带着问题去测试

阿猪工作守则第一条：带着问题去测试

测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。

3.测试期间提问题和交流的时机

什么时候应该提问题？

我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？

培训

培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。

阿猪工作守则第二条：培训时脑子灵活转动，多想多问

以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。

…… …… 余下全文

1.按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。

单元测试。

单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

集成测试。

集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。。  确认洌9试。

确认测试

确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

系统测试。

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接，并满足用户需求。

验收测试。

按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

2.按照测试实施组织划分，软件测试可分为开发方测试、用户测试(β测试)、第三方测试。

开发方测试。

通常也叫“验证测试"或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。

…… …… 余下全文

测试过程中遇到的问题总结

1 需求变更问题

内容详述：由于种种问题，在开发提交代码及测试完毕后，出现需求变更现象。 典型项目：密

影响人员：实施、研发、测试

对测试影响：需求变更直接导致开发人员情绪变得消极，导致测试的工作受到影响。 可记录数据：需求变更讨论会议次数、更改需求个数、时间间隔

可规避方法：从测试角度出发来规避，只能从前期进入需求调研，前期做充分工作。如果是后期进入测试的话，将很难规避这样的风险，我是这样认为的。

2 新需求文档不全、不详细、不存在

内容详述：项目开始时，文档还是可控的，到项目进行过程中的需求变更和新需求，几乎都不会再生成文档。

典型项目：几乎所有

影响人员：开发、测试

对测试影响：没有明确文档作为测试的依据，测试不能发现产品偏差。

可记录数据：没想到呢

可规避方法：自己做好会议记录，同时要求相关人员编写相关文档。

3 开发对测试的责任过分放大

内容详述：程序不稳定，是由于测试测的不充分所至。测试充分就能保证产品质量。 典型项目：密

影响人员：测试

对测试影响：开发对测试人员产生依赖，让测试准备数据，重现问题，修改完问题不进行自测，继续让测试准备数据进行测试。导致测试消耗了大量时间。

可记录数据：缺陷重开率、缺陷新建与修正比

可规避方法：测试不是生产者，测试更不是开发的保姆，将测试的责任及职责宣传给研发和实施部门，同时测试应站正自己的位置。

4 迭代式开发造成测试瞬间压力较大

内容详述：一个项目需要多个版本，开发按照迭代式开发，当第一个版本出来时，测试量较大，当第一版稳定后，其余版本的测试任务较小，当最后一版出来后，需要对所有版本间的数据传输做全面测试。瞬间压力可上升到极点。

典型项目：密

影响人员：测试、实施

对测试影响：瞬间的测试压力大

可记录数据：没想到呢

可规避方法：将测试计划中详细描述这种情况下的测试需要较长测试时间，与研发、实施三方进行确认。无论开发计划如何变更，测试人力投入不变。

…… …… 余下全文

文档模板：201842222.doc 版本：v1.5(2007-09-04) 1

测试总结报告 CEERS_TSR_0.1

文档修改记录（Revision Chart）

?北控软件有限公司, 2013 I

测试总结报告 CEERS_TSR_0.1

目 录

1 引言 ......................................................................... 1

1.1 编写目的 ................................................................................................................................... 1

1.2 定义与缩写 ............................................................................................................................... 1

1.3 参考资料 ................................................................................................................................... 1

1.4 文档结构 ................................................................................................................................... 1

2 产品/系统概述 ................................................................ 1

…… …… 余下全文

业务流程测试总结

近期公司比较强调业务流程的测试，本人就总结一下业务流程的测试经验与大家分享，欢迎大家多提意见。

一、业务流程整理

1、充分掌握业务知识，业务流程以及业务的数据流向。

站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。

2、从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。（这点对把握测试重点很重要）

3、了解业务流程在系统中对应的功能。（建立业务与系统的映射，为编写测试用例做好准备）

二、编写测试用例（在需求文档以及UI原型评审之后）

1、绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。

2、根据业务流程的重要程度、使用频率为各流程设置好优先级。

3、采用场景法、路径法或其他方法（方法其实是不固定的，有时候可以综合使用多种方法）梳理出每个业务流程在系统中对应的操作步骤，形成业务流程的测试用例。

注意：

* 这里的操作步骤没有必要像功能点测试用例的步骤那么详细，这个操作步骤可能是一个业务操作集，可以分解成多个步骤，这些业务操作集合，也可以对应具体的功能点测试用例，从而做到测试用例的复用。所以可以说这里的业务流程测试用例就像是将多个功能点的测试用例组合成一个集合，形成一个业务流。 * 在每个步骤中需要标识出执行该操作的用户角色，因为在一个业务流程中，很可能涉及到不同的角色。

* 需要平衡项目的进度、成本，不一定需要覆盖所有的路径。

三、测试数据设计

1、输入数据：

测试业务流程与功能点测试的重点不一样，因此设计测试数据的时候更多需要考虑下面的因素（按重要到次要排列）：

1）关键的判断条件

2）符合业务意义的数据

…… …… 余下全文

测试计划

做测试需要做好准备工作，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。就需要有一个完善的测试计划。测试计划的内容包括：确定阶段的测试范围和任务、确定测试策略和方法、确定测试周期、确定测试人力资源的分配、确定测试风险分析。

确定阶段的测试范围和任务——描述项目测试中做的测试范围，包括测试软件功能范围、测试种类等。

测试策略——主要分析可能实施的测试方法，考虑可能需要的测试工具。

测试周期——预测完成整个测试所需时间。也可以根据功能模块进行细分，估算每个模块需要完成的时间。

资源分配——分为人力资源、软硬件资源。组建测试项目组，确定测试项目负责人和组员，明确各成员的相关责任。按照不同的任务，能够提交的交付成果详细列出；

测试风险——大多考虑的就是项目开发延期、测试人员不足、用例无法全面覆盖测试点、时间不足、bug无法及时修改导致无法验证、测试人员技术不足导致测试进度拉长；

编写测试计划的目的在于充分考虑执行测试时的各种资源，执行时所能调用的一切资源以及受各种条件限制，可能受到的各种影响。编写完成测试计划后，进行项目内评审。

设计

描述对系统分解后每个功能点逐一的操作描述，包括用什么方法测试、用哪些测试数据、期望测试结果是什么以及对测试环境的设计。以功能点分析为依据进行测试用例的设计，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按操作步骤来执行的测试用例。测试用例需要覆盖所有的测试需求。测试用例一般包括以下几项：编号、功能点、预置条件、测试数据的输入、操作步骤、期望的输出结果、实际运行结果。对有性能测试、负载测试及安全测试需求的，设计专门的测试方法和用例。编写完成测试用例后，组内进行评审。

测试执行

测试用例的设计完成之后，部署测试环境。待开发提交测试版本后，开始进行测试。在满足用户使用的测试环境上，按照测试用例的条件、操作步骤、测试数据对系统进行操作。比较实际结果和测试用例所描述的期望结果是否一致，以确定系统是否能正常运行。

…… …… 余下全文

光阴似箭、岁月如梭，转眼之间已经来到天维公司三个月了。那么针对公司目前的测试现状、存在的问题、自己的测试工作情况，做一下总结，顺便谈一下自己对测试的看法和见解供大家一起学习探讨。

目前天维公司的测试现状，处于起步阶段，当前能做到的，只是对公司绩效考核系统实施了测试，测试的过程、测试的阶段、测试的结果都没有严格完善的测试流程来控制，所以对软件产品的质量无从保障，没有什么依据可供参考。公司领导苏工和张工对测试工作相关重视。准备从对测试工作流程进行规范管理抓起，提高测试工作效率，量化测试工作，对软件产品进行全面的测试控制，从而对软件产品的质量进行保证。

针对天维公司绩效考核系统的测试，根据自己在这三个月来的测试工作情况，做一下全面的总结。天维公司绩效考核系统的测试工作从阶段上来划分，可以划分为两大部分：

1、项目开发阶段

在项目的开发阶段，测试工作将分为以下两方面：

? 数据库测试

数据库的测试也就是后台测试。这一阶段的工作，主要包括存储过程的测试和数据核对测试两部分进行。那么针对存储过程和数据核对的测试，要从以下几个方面考虑着手。

? 把存储过程中涉及到的表全部列出来，并对表进行归类，分为源数据表，目的数据表，这样做有助于思路比较清晰，便于比对实际结果和预期结果。

? 分析存储过程的逻辑关系，把存储过程中，表与表的连接关系条件列出，这样在准备测试数据的时候不会漏掉必要的条件，尤其当表比较多，连接条件也比较多时，这一项工作相当重要。

? 把存储过程中，存在的分支，详细列出。在测试时，要把每个分支都测试到。避免在测试过程中，只测试一种情况，这样就很难把握测试的全面性。

? 在数据的核对时，要注意测试的数据的设计，尽可能考虑边界值。 ? 当得到结果数据为计算公式计算出来的数据时，要考核数据的准确性和数据小数位数。

? 前台功能测试

对于前台功能的测试，由于从目前客户的需求方面考虑应该从以下几方面考虑测试。

…… …… 余下全文