测试经验总结

1．        决定BUG严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，可以设定1－10分，每两分为一个层次可以依照如下划分：

ü         Blocker：阻碍开发和/或测试工作

ü         Critical：逻辑错误，丢失数据，内存溢出

ü         Major：主要的功能缺陷？

ü         Minor：次要的功能缺陷？

ü         Trivial：产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等，页面交互性问题

2．        决定BUG优先级的时候，可以先假设不修复该Bug，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定bug的优先性。

3．        容易产生Bug的情况

ü         虽然在开发过程中，软件需求通常都会发生改动，但是，如果某一部分的软件需求频繁发生变动，那么就会导致和这部分软件需求相关的编码和设计频繁变动，那么在测试中，这部分编码设计实现的产品出现bug的可能性就很大。

ü         如果根据测试需求设计的某个测试用例描述的业务非常复杂，并且和其他的业务之间也有非常复杂的关系，那么可以判定设计和编码实现也会非常复杂，那么该部分出现bug的可能性也非常大

ü         如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现bug的可能性就很大，尤其是这些第三方组件使用者很少而且没有通过严格的认证的情况下。

4．        于测试的工作用时间的估算，可以参照公司过去的经验，根据公司以前的测试计划或测试报告，查看和目前从事的测试对象相仿的产品，查看测试该产品的参与者有多少，工作用时多少，单位效率如何，根据这些可以大致的估算出工作用时来，但是，并不是说估计的工作用时就能保证完全正确，因为在实际的工作当中会出现很多意外的情况，而且，工作用时的估计也需要有丰富的工作经验，所以，如果工作用时估计不精确，也是可以接受的。

5．        功能性测试需求表述的是对于系统中描述的功能性行为有哪些地方需要测试，这部分内容可以在项目早期就通过对软件需求规约和用例的分析获得，一般来说，一个明确要求的功能性特性可以生成一条测试需求，用例中基本流或基本流通某些备选流的组合也可以生成一条测试需求，另外，如果用例之间有相关性和依赖性，这多个用例间的不同联系也可以分别生成一条测试需求。

6．        如何根据频频变更的软件需求确定测试需求

       采用的是软件需求的版本化管理，指在一个软件产品进行新版本的迭代时，尽早确定这个版本中所包含的需求。就自己某前测试的项目ODD，来说，这个项目没有软件需求，因为这个项目是对现有产品的升级，是基于现有产品进行开发的，因为Mymiles方面的新要求，或者房源查询数据接口的变化，这个项目的软件需求发生了很大的变动，在已经测试的B9，B10版本中有包含的某些功能可能在新版本中会取消，在新版本中又会添加新的功能。在这种情况下，作为这个项目的测试人员，就应该尽早确定这次新版本中包含的需求，然后和上次测试的版本进行比较，哪些内容是新增的，哪些内容是被调整过的，哪些内容是在新版本中取消的等等，当确定了这些内容以后，也就获得了新的软件需求，然后再确定测试需求。

7．        测试需求的整理

       测试需求的整理是明确现在要“测什么”，软件需求确定以后，根据软件需求规约，软件需求用例，从文档对软件特性和软件业务流程的描述中获得软件所设涉及的业务的一个基本认识，比如用户的实际业务是怎么进行的？实现这些业务需要什么约束条件，这些约束条件对实现业务的影响是什么？多个业务之间是否存在相互的关系，如果存在相互的关系，这些相互关系对处于这些关系中的业务又什么影响等。通过这些业务的分析，可以获得最初的一些测试需求。等开发部门的架构设计文档和详细设计文档出来以后，可以根据这些文档，对已有的测试需求进行增补，在执行测试的时候，如果发现在测试需求中没有包含的内容，则对这部分内容，也要整理添加到测试需求当中。

8．        测试需求的可测试性

测试需求的可测试性指的是，对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证，即，要保证所有的需要实现的需求在最终实现后，都可以用某中方法来明确的判断是否符合需求文档中的要求。

9．        测试用例设计的有效功能

有效功能是指在被测应用所设计的实际业务中，当用户在原始状态下进行工作时，整个业务流程对用户来说具有实际意义的功能，当把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就没有了意义。而在该业务完成以后，可以为其他用户或业务提供所需要的信息。比如，财务软件中，用户填写一张会计凭证的是，它利用软件的功能，从备选会计科目中选择一个会计科目，这个功能就不是一个有效功能，因为在原始状态下，这个功能对用户来说没有什么实际的意义。但是，添加会计凭证这个功能就是一个有效功能。

对于相互之间存在数据或状态依赖的有效功能，要注意将他们剥离到不同的测试用例中。

10． 试用例常用设计方法

Ø        填写操作列表：将在软件上操作的步骤记录下来，包括所有被操作的项目和相应的值，这种方法的又是在于可以清晰的表达对于一条确定的测试用例的测试思路。比如可以利用操作步骤设计测试用例，测试常见的用户登录框用户正常登录功能、

Ø        填写测试数据矩阵：将被操作项作为矩阵的一个字段，而矩阵中的一条条记录，则是这些字段的值，利用这个方法，可以存放测试数据，特别是操作步骤相同，知识赋予属性的值不同的情况，比如可以利用测试数据矩阵，编写测试用例，将用户不能输入错误用户名和密码的情况以数据记录的形式存放在测试矩阵中。

11． 测试用例的设计并不是简单的把在应用程序上具体的操作的繁琐的步骤记录下来，因为通过这样的方式设计的测试用例，维护起来是十分庞大和复杂的，当需求中软件的某个特性发生变动时，为这个特性每个可能的值设计的测试用例都要进行修改，可以想象，修改这样的测试用例是多么的困难。所以，在测试用例设计的时候，要关注测试思想，而不是关注测试步骤，将测试者应该遵循的操作过程单独描述，然后，将针对这个测试用例的输入数据和输出数据单独写出来，这样，就不用再对原本多个用例中重复出现的操作步骤过程再次描述，可以把更多的精力放在测试数据的设计和准备上。当软件需求发生变更时，只需要对操作过程维护一次，再添加或调整测试数据就可以了

12． 准备有效的测试数据

       准备有效的测试数据，要从这个业务流程中最下游的业务开始考虑，找到实现它的所有输出所需要的所有输入，包括那些它所不能接受或无法处理的输入。当然，这些输入都来自于它的之间的上游业务。继续这种方法向上迭代，找出实现它的直接上游业务的所有输出所需要的所有输入。直至到达整个业务流程的最上游，也就是启动整个业务流程的第一个业务。

       对于测试用例的执行顺序的安排，同样是充分利用了多个业务之间的相关性和依赖性，再执行测试用例时，尽可能的将存在相互对照意义或者直接联系的内容安排再一个顺序中执行，并尽量在执行一个测试用例的时候检查更多的内容。

13．   描述bug主题时，应当根据实际情况，简要的描述出自己的操作和希望被重视的现象，不应该包含自己对异常表现出现的原因的推测和猜想。

14．  不能假设开发人员对他们开发的程序都十分熟悉，在提交bug的是，一定要说明白是哪个模块的哪个功能，出现了哪种类型的错误，并且，如果需要，应该把需求种关于该部分的描述写出来。