测试工作经验总结

测试工作经验总结

功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。

要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。

了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。

测试用例的编写经验

1 步骤和数据的分离

将输入的各种数据已参数的形式表达在操作步骤中，而不需要为每一种输入数据创建一个测试用例。

例如：atm存款

好的测试用例，在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

1.密码正确的登录

2.密码错误的登录

3.密码输入三次错误，卡被锁定

4.取少于余额的款项

5.尝试取大于余额的款项

6.尝试取等于余额的款项(考虑手续费)

6.取款额度大于当次的限制

7.取款额度大于当天的限制

7.取款次数大于限制次数

等等

不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下(此处只列出了操作的步骤，略去了系统的交互中的反馈结果)：

1.插入卡->A:输入密码->B:按“确定”键->重复A-B

2.A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?

2 单独的测试基础数据准备工作

将测试基础数据提前准备好，写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。

3 测试用例的前后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

测试经验总结

测试经验总结

测试工程师 6年工作经验总结

手机软件测试经验总结

项目测试经验总结

软件测试经验总结

手机测试经验总结

测试经验总结（优秀）

BBS 银行测试经验总结

手机软件测试的经验总结

《测试工作经验总结.doc》

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档