近期机缘巧合,连续写2个项目的测试用例。第一个项目,纯属没有办法,参与该项目的现在就只剩我一个人了,只能自己写了,这不,我专门跑到客户那啥都不干,写文档写了2天;第二个项目,则是因为我在其中基本上打打酱油,只能做些鸡毛蒜皮的工作。虽然我自命不凡,觉得自己是全栈工程师,但别人不这么看,尤其是领导不这么看。不过,按照敏捷开发方法scrum的教程,其推崇多职能团队,即敏捷开发团队成员,每人都身兼数职,充当多种角色,比如既开发,又测试,还运维(哇塞,原来小公司的模式就是敏捷模式啊)。又比如,现在流行DevOps,说的是开发人员、运维人员、销售人员等大家通力合作,不分彼此,其实也有身兼数职的意思。
这么说,我还挺潮的。不过,技多不压身,50了,转型做测试也是一条出路。当然了,我不想做测试,写文档太枯燥了,感觉应该是AI干的活。
对于这两次写测试用例,有一些体会和感悟,记录如下:
一、测试用例的编写要求和思想
1、测试用例要写细
话说两个项目给的测试用例模板不一样,但貌似都有功能介绍,预期目标、测试步骤、测试结果,这是最核心的。测试用例是写给测试人员看的,是她们测试的时候的使用手册。写的时候,要假设测试人员对整个项目一无所知,只能按照我们写的测试用例机械地进行测试。因此测试步骤一定要写细,比如点击什么菜单,点击什么按钮,这个按钮在哪个位置,要写清楚。
2、测试用例的功能介绍简明扼要,只提一下其实现的功能就好,不要写太长。
因为测试人员是来测试的,不是来学习系统的,写得太长,她们要花时间去思考,没有必要。
3、测试步骤,是一种黑盒测试,注意是测试步骤,而不要写成功能介绍。
比如这样写就不对:
应该是这样写:
二、测试用例应与研制任务书、需求规格说明书一脉相承
测试用例针对的功能,需要与研制任务书、需求规格说明书保持一致。事实上,我在第一个项目上,到客户办公室写文档,是研制任务书、需求规格说明书、验收规程(测试用例)三个文档一起改/写的。其中,研制任务书要引用合同关于功能的描述和要求,而需求规格说明书和验收规程要引用研制书里的功能描述;这个所谓的引用,就是照搬,复制粘贴一份。
同时,需求规格说明书里要有需求跟踪矩阵和反向需求跟踪矩阵,将研制任务书里的功能和需求一一对应;而验收规程则有研制功能、需求、测试用例三者对照关系。如图
1、研制功能与需求的对照
2、研制功能、需求和测试用例对照
3、测试用例与需求用例对应
4、小结
按照课本,我们知道,系统生命周期可以分为规划、开发、运维、更新或消亡4个阶段。规划,是甲方的活,包括组织可行性研究,输出建设方案;合同签署以后,进入乙方的开发阶段,又细分为总体规划、需求、设计、实施、验收几个小阶段。那在总体规划,可以编制研制任务书;然后进入需求分析阶段,输出需求规格说明书;设计阶段是设计说明书;验收阶段是验收文档,一脉相承。现在,在生产实践中,把理论串起来了,不再是抽象的背诵内容。
三、测试用例模板
两个项目的测试用例模板不一样,记录一下。感觉第一个专业一些。
1、模板一
2、模板二
四、总结
我在写第二个测试用例的时候,面对的是一个不太熟悉的系统。因为项目是基于别的项目组现成的代码的二次开发,我身为开发人员,对这个系统,有许多功能其实并不了解。因为要写测试用例,被迫每个功能都点了一下,结果发现,系统的功能很强大,做得十分完善,有些东西还让我惊艳。受到的益处像土匪一样浅薄。也许这个项目一路走来,有许多程序员在上面修修改改,其中有些代码写得不怎么样,符合屎山的定义。但毕竟,项目可以跑,没啥大问题,功能还很强大,有许多值得我学习的地方。这不,这两天我正好用上了测试时发现的功能,借鉴了代码,节省了时间,效果还挺好。
同时,在写测试用例的时候,因为要写得比较细致,对功能有了一些新的视角。所以,教科书上说,有些开发方法或模型,在需求分析阶段就写测试用例,其实也是有道理的。如果能将测试用例写出来,其实对功能的理解就十分到位了。用来指导开发,或者用于跟用户交流,都是不错的选择。