测试生涯成长心得

原创,转载请注明来源。

 

来到公司一转眼半年时间了，经历大大小小的版本发布测试，从系统管理到报表再到账务管理以及即将到来的资产，也从一个会计小白转型为会计菜鸟，对于测试技术也逐渐有了自己的认识和理解，这篇心得主要还是谈谈对于测试用例的看法。

在测试理论中，有一种测试叫AD-hoc测试，也叫做探险式测试，属于随机测试，指的是完全根据业务常识进行测试，觉得哪里可能会出问题，就过去执行下试试，而且这个过程是不重复的，进公司后我大部分单子都是靠这种测试方法发现的，原因是其一我不熟悉会计方业务知识，只能跟着感觉走；其二就是我们的用例的可读性差、低效性，用例中的冗余、细节遗漏、以及层次扁平化导致用例的命中率不高。

前几天一直在写功能测试需求，之前也只是理论上接触过，并没有真的实践过，加上没有现成可用的模板，写的比较糟糕，快写完的时候，有些问题才慢慢想清楚，有些结构层次才逐渐理顺，下面是我最近一段的心得（鉴于马上就要开始新一轮的测试用例设计了，结合最近一段设计测试需求以及进公司近段时间的测试感受，对我们当前的测试用例设计，以及用例的执行，简单谈下我的想法）写下来一方面是指导自己，总结这一段的学习成果，另一方面希望能从中给其他人带来一点启发。

功能性测试范畴

功能性测试，我的理解，就是用来验证程序的功能是否正常，它的步骤可以非常的详细（这里的详细是指对此功能点步骤的描述详细，而并非对约束条件、数据如何流转描述的详细）比如我们的凭证手工录入就是一个功能点，它的功能测试需求从最基本的测试点来说就是只要可以完成凭证手工录入这个功能，录入完成后在页面上可以显示出这条凭证，整个过程中没有功能点出现问题即可。

功能测试需求，就应该是详细描述功能点的各个功能，使得测试用例设计者拿到这个需求后就可以做相应的测试用例设计。对新人来说，详细的步骤有很好的指导作用；对熟悉者来说，详细的步骤，可以选择跳过，也可用来保证思维的连贯。

拿【凭证编辑】举例，比如“凭证录入界面，提供删除分录，插入分录的功能”“提供选择科目辅助信息的功能”这些都应该属于功能测试需求，即用来验证功能是否正常的，在设计用例时这些功能点都可以作为是否需要覆盖的路径来考虑。

至于那些所谓的必输项、文本框取值范围、数据读写权限等等，诸如“凭证制单时至少填写一处摘要”“凭证分录金额必须为数值”、“验证财务月份是否锁定后还能制单”等等，这些都应该属于约束性测试范畴而并非功能测试范畴，我在本文的第二部分会进行详细说一下我的理解。

又诸如那些“验证分录中含有银行类会计科目时在进行银行账户选择时是否可以正确读取资金模块的账户信息”“制单完成后是否可以正常流转到凭证复核”等等，因为它们都是由多个不同的功能用例组成，依靠单一的用例无法完成，所以这些都属于系统性测试范畴。在本文的第三部分我会详细举例来说下我的理解。

 

对于我们当前TD中的用例，大致分为两种设计方法：

第一种是，把是把每个功能分离成不同用例比如：

凭证编辑-手工录入、凭证编辑-凭证处理、凭证编辑-删除凭证

（还可以分的再细一些，如【条件】按钮就应单独列出）

 

第二种是，把是把每个功能分离成同一用例的不同步骤比如：凭证复核，其中step1为单笔复核，step2为批量复核。

我个人觉得第一种做法可取性高些，原因是方面以后组合时调用，对于这点我会在后面详细说下我的看法。

 

一句话总结，功能测试用例设计只需要考虑所覆盖的功能点的功能完整，将每个功能分离成独立用例。

约束性测试范畴

这个名词也是某天在TD中写功能测试需求时无意中发现这个字段的，后来仔细想了一下也到网上查了一些资料，才了解其作用的。也就是我写的测试需求中的备选流(其实类型应该写成约束性需求)。

 

在Rational Unified Process定义中约束性需求一共有4类：

一、设计约束性需求——软件设计的限制

我个人理解，与软件易用性相关，比如会计习惯的金额应靠右显示。

二、实现约束性需求——软件构造的限制