软件开发过程中常用的测试方法

一．目前项目中所 使用的测试方法

目前项目中(目前项目是一套C/S架构的系统) 所使用的测试方法为：单元测试，集成测试，功能测试，回归测试，验收测试。

下面就上面的三种测试方法，分别做一下说明：

(1) 单元测试

这个步骤主要是开发者针对开发过程中，程序内部的函数、类、变量等等数据进行正确性的测试。

开发人员根据需求，在经过详细设计之后，开始着手编写代码。一般情况下，每完成一个函数 ( 类、变量 ……) 之后，就要进行单元测试，以验证编写的函数能完成详细设计说明中的功能。

举个例子：一个函数需要把一些重要的数据插入到数据库中。那在编写完这个函数之后，就要进行测试，以验证①函数能正确带出需要插入数据库的数据变量②带出的数据可以正确的插入需要插入的数据库。

在上述测试通过之后，再接着按照详细设计说明进行接下来的开发工作。

(2) 集成测试

集成测试是在单元测试的基础上，将所有模块按照详细设计的要求组装成子系统或系统，进行集成测试。集成测试侧重于模块间的接口正确性以及集成后的整体功能的正确性。

举个例子：等一个个函数或者功能模块的单元测试完成之后，就需要测试这些函数或者模块之间的整体的数据流是否正确。

(3) 功能测试

等开发人员开发完之后就要把最后开发、测试 ( 单元测试，整合测试 ) 完的 requirement release 给内部 QA 人员去做功能测试。因为开发人员的单元测试、集成测试只能保证 release 给 QA 的新的 requirement 的开发是可以正常运行的，执行起来的效率是最高的，一些基本的功能（如：数据库操作，通信，显示， error handing ，信息反馈 …… ）可以正常使用。但是对于特定需求的业务逻辑还不能完全保证其正确性，所以需要更加详尽的功能测试过程。

在功能测试过程里，需要测试人员严格的按照需求说明，测试新开发的 requirement 是否完全符合 user 的要求，是否符合行业的规范，是否符合实际的操作流程和业务逻辑。

(4) 回归测试

回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

根据修复好了的缺陷再重新进行测试。

回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某个已知已经修正的缺陷再次围绕它原来出现时的步骤重新测试。

(5) 验收测试

验收测试是软件测试过程中的最后一步。这时相关的 user 根据需求说明文档对系统进行测试和验收，决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试的目的是确保系统已经准备就绪，并且可以让最终 user 使用新需求中的功能。

二．测试工具

针对上述测试过程，单元测试和集成测试都是需要软件开发人员去控制和把关的。一个好的开发人员肯定也是一位好的单元测试、集成测试人员，因为在开发的过程中时刻都需要进行单元测试和集成测试。

虽然单元测试有专门的测试软件 ( 需要购买相应的 license) ，但是我觉得在 目前项目 的开发过程中不是非常有必要，这个在开发人员开发的时候就可以去把关卡住，不需要 QA 再通过相关的自动化测试工具去做复杂的白盒测试。

对于功能测试，特别针对于我们现在的 项目 ，我们可以设计一套测试系统去测试每条 message 处理逻辑的正确性。

这个测试系统成立的前提条件是，我们在需求成立的时候就把相关的测试用例设计出来，针对于 目前项目中 的 message 来说，就是在 send 给 SERVER 具体 message 的时候，就能把相关 replay 的信息预知出来；这个前提条件其实完全可以做到，就是在正真开发之前先模拟一遍开发完成后的实际的需求，通过在数据库运行具体的 sql 逻辑、改变数据库数据等等方法先把新 requirement 中的逻辑事前模拟一遍，然后根据模拟出来的具体值编写测试用例。等到单元测试、集成测试完之后就运用测试系统去运行事前已经编写好的测试用例，如果得到的结果符合测试用例的值，那么说明这次测试时通过的。

这个测试工具需要针对 目前项目 的每条 message 编写不同的处理逻辑 ( 因为每个 message 各不相同 ) ，然后匹配事前已经定义好的测试用例来验证功能是否符合需求。

三．几个不能覆盖到的地方

1. 因为这个测试系统只能根据 message 的 replay 值来进行匹配验证，所以如果一条 message 的功能主要放在逻辑处理上 (TP ，数据库操作 …….) 而不是放在 message replay 上的话，那样就不能通过 message replay 的信息中得到预定的值来进行功能验证

2.replay 的信息量很大的话，也不能进行验证

四． release 的时候所遇到的问题的分析

1. 在 release 给 QA 之前就存在问题

这个问题主要体现在单元测试，集成测试的时候没有覆盖到很多临界数据、特殊数据。这些临界的数据或者需要特别处理的数据往往导致操作失败或者系统崩溃，所以在进行单元测试、整合测试的时候设计这些数据是很有必要的。

2.QA release 给 user 的时候存在的问题

这个部分是因为没有把所有的操作都进行完整的测试，没有完全覆盖到需求说明中的所有业务逻辑导致的。

3. 已经修改过的错误再次发生

这是因为没有进行回归测试。

4. 最终 user 报需求不符合要求，使用不习惯，有很多 bug

这个原因比较复杂，其中最主要的原因是在谈需求的时候没有把需求谈清楚，或者说这些 user 没有很好的阅读需求说明书就把需求文件给签署了，其实里面还有很多东西是不明确的。

还有个原因是 release 给具体用户测试的时候，他们也没有根据自己具体的需求去进行测试。

原文链接：/article/7993966.html