测试工作的一些心得体会

一、测试的首要条件----明确需求

做了6个月的测试了，觉得有必要把自己的一些心得体会写下来。

具体地和测试的内容有关，刚开始测试，犯了一个比较严重的方向性错误，觉得错误就是找BUG，找出最多BUG就显得自己有多牛似的，现在才发现自己错了。

首先测试，要做的就是验证软件是工作的，就是在一般情况下能完成其基本功能，这个就要紧扣需求，试想，如果软件连最基本的需求都满足不了，那么界面再美观，也只是一个空壳。这部分内容的测试要求测试人员要研究软件的说明文档，了解了需求才有资格做测试，其实，如果你不知道什么是正确的，那你提BUG的依据又在哪里?你提的BUG又怎么让开发人员心悦诚服地接受并修改呢？

话又说回来，只有明确了需求，也才能真正提出隐藏在软件内部，深层次的BUG，提出那些让开发人员觉得受益的BUG，也会受到开发人员的尊重与欢迎，也才能体现我们测试的价值。

否则，不明确需求，在界面上点点，提一些边边角角的缺陷，让开发人员不开心，觉得测试人员没水平，竟提些无关痛痒的BUG，浪费他们的时间，领导也会觉得测试的意义不大。

不过需求说明文档各个公司不一样，正规的公司都有比较详细的说明文档。还有就是当你对需求不清楚的时候，一定要去沟通。

这部分测试的时候也要分优先级的，软件最核心的功能是什么？把握最核心的，其次有影响的，再其次界面，帮助文档之类的。

二、根据需求设计测试用例

我就我工作的这边，需求文档就是一张张的表，刚开始测试的时候不知道表的意义何在，觉得看这些表太浪费时间了，没有好好研究，好在亡羊补牢，为时不晚，其实所有的内容都蕴含在一张张的表里。表中有表字段，表字段有取值范围，我们的测试用例来了，取值范围，边界值。还有索引值，是唯一索引，主索引的话，唯一性这里也要验证。还有表的关联性，A表中的值在B表中必须存在，也是一个测试点。总之，灵感就这么源源不断地来了，觉得测试真的是一件具有创造性的事情，丝毫没有觉得它的乏味。

我们还可以到数据库中去查表字段的取值是否和需求说明中一致，也是有很多测试点的。

当然，以上是说手工测试。何时才能自己开发自动化测试工具呢？或者用自动化测试脚本代替手工测试呢？期待这一天快点到来。

三、如何开展自动化测试呢？

因为我们测试的软件是一套很大的系统软件，整个测试是通过GUI界面进行的黑盒测试。这套软件也提供了人机命令接口，我一直在想，如果能通过这个接口把基本功能的验证都做了，抽出人力去充分发挥测试人员的创造性，那该多好啊！

想法想来已久，也小小实践了一下，实现了一小部分的自动化测试，不过，因为命令本身设计的不完善，所以只涉及了一部分功能，其二，命令本身存在缺陷，并不能取代界面的测试。其三，因为开发人员对命令部分的不重视。

也学习了Functional Tester工具，进行录制与回放，这个方法脚本的复用性不高，维护的代价也比较高，所以不选它了。

最好的方法就是开发自己的自动化测试框架。

【相关文章】

• 如何设计编写和设计软件测试用例

• 从测试用例看测试的问题及变化

• 测试用例可以当需求吗？