文档介绍：测试经验总结软件测试年终总结软件测试实****的收获软件测试工作计划测试年度工作总结篇一:测试工作经验总结测试工作经验总结功能测试最重要的是理解业务和需求。知道系统要实现什么功能, 业务流程是怎样的, 然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有: 等价类、边界值、因果图、判定表等, 在实际工作中, 我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点, 将测试用例按测试目的进行分类, 比如用户界面、功能点、业务场景等, 会让测试用例的结构看起来更清晰,执行测试用例的效率也更高。要做好功能测试,还需要对整个系统的数据库结构比较清楚, 每个功能点涉及哪些数据表, 对数据的操作方式是怎样的。这样就不单从前台页面来进行测试, 通过对数据库中数据的验证,可以发现隐藏的一些 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这个 Leve l 上来, 不用写多个用例, 只是在测试计划和执行的管理系统中作为测试集的一个环境参数,恰当地表达出来就可以。篇二:测试经验总结 1. 测试人员和用户的联系与区别黑盒测试人员和用户, 都是站在实际应用层进行操作, 因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用,而相对用户来说,测试人员对软件比较了解,但不熟悉业务本身。八个字归纳:用户是用,测试是测。用户不懂使用就需要技术支持人员去培训, 而测试人员在测试初期经过开发人员和项目负责人的简单培训后, 就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。应该做到: 由测试人员培训技术支持人员, 由技术支持人员实施时给用户培训。 2. 带着问题去测试阿猪工作守则第一条:带着问题去测试测试中会遇到很多问题, 没关系, 没有脑子里面的一个个问号, 是不能很好的发现问题的。往往发现一些藏的很深的 bug 都是在测试人员一步步解决这些问号的过程中, 切忌遇到问题就问, 不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度, 而且自己对问题的印象也不会很深刻, 毕竟在相对较短的测试时间内, 听不如记, 记不如自己去发现规律。 3. 测试期间提问题和交流的时机什么时候应该提问题? 我们都知道, 作为测试人员, 并不是测试期间什么时候遇到问题就要马上问,那什么时候是提问的时间? 培训培训时, 一般在讲解内容的间歇允许打断, 由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间, 这个期间的提问是欢迎的, 也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受