近期机缘巧合，连续写2个项目的测试用例。第一个项目，纯属没有办法，参与该项目的现在就只剩我一个人了，只能自己写了，这不，我专门跑到客户那啥都不干，写文档写了2天；第二个项目，则是因为我在其中基本上打打酱油，只能做些鸡毛蒜皮的工作。虽然我自命不凡，觉得自己是全栈工程师，但别人不这么看，尤其是领导不这么看。不过，按照敏捷开发方法scrum的教程，其推崇多职能团队，即敏捷开发团队成员，每人都身兼数职，充当多种角色，比如既开发，又测试，还运维（哇塞，原来小公司的模式就是敏捷模式啊）。又比如，现在流行DevOps，说的是开发人员、运维人员、销售人员等大家通力合作，不分彼此，其实也有身兼数职的意思。

这么说，我还挺潮的。不过，技多不压身，50了，转型做测试也是一条出路。当然了，我不想做测试，写文档太枯燥了，感觉应该是AI干的活。

对于这两次写测试用例，有一些体会和感悟，记录如下：

一、测试用例的编写要求和思想

1、测试用例要写细

话说两个项目给的测试用例模板不一样，但貌似都有功能介绍，预期目标、测试步骤、测试结果，这是最核心的。测试用例是写给测试人员看的，是她们测试的时候的使用手册。写的时候，要假设测试人员对整个项目一无所知，只能按照我们写的测试用例机械地进行测试。因此测试步骤一定要写细，比如点击什么菜单，点击什么按钮，这个按钮在哪个位置，要写清楚。

2、测试用例的功能介绍简明扼要，只提一下其实现的功能就好，不要写太长。

因为测试人员是来测试的，不是来学习系统的，写得太长，她们要花时间去思考，没有必要。

3、测试步骤，是一种黑盒测试，注意是测试步骤，而不要写成功能介绍。

比如这样写就不对：

点击窗口左上角”导入“按钮，在弹出对话框中选择设备清单文件，点击”确定“，可以 将设备清单导入数据库。

应该是这样写：

点击窗口左上角”导入“按钮，在弹出对话框中选择设备清单文件，点击”确定“，成功将提示”导入数据成功”，否则提示”导入数据失败“。

二、测试用例应与研制任务书、需求规格说明书一脉相承

测试用例针对的功能，需要与研制任务书、需求规格说明书保持一致。事实上，我在第一个项目上，到客户办公室写文档，是研制任务书、需求规格说明书、验收规程（测试用例）三个文档一起改/写的。其中，研制任务书要引用合同关于功能的描述和要求，而需求规格说明书和验收规程要引用研制书里的功能描述；这个所谓的引用，就是照搬，复制粘贴一份。

同时，需求规格说明书里要有需求跟踪矩阵和反向需求跟踪矩阵，将研制任务书里的功能和需求一一对应；而验收规程则有研制功能、需求、测试用例三者对照关系。如图

1、研制功能与需求的对照

2、研制功能、需求和测试用例对照

3、测试用例与需求用例对应

4、小结

按照课本，我们知道，系统生命周期可以分为规划、开发、运维、更新或消亡4个阶段。规划，是甲方的活，包括组织可行性研究，输出建设方案；合同签署以后，进入开发阶段，又细分为总体规划、需求、设计、实施、验收几个小阶段，那在总体规划，可以编制研制任务书，然后需求分析，输出需求规格说明书；设计阶段是设计说明书；验收阶段是验收文档，一脉相承。现在，在生产实践中，把理论串起来了，不再是抽象的背诵内容。

三、测试用例模板

两个项目的测试用例模板不一样，记录一下。感觉第一个专业一些。

1、模板一

2、模板二

四、总结

我在写第二个测试用例的时候，面对的是一个不太熟悉的系统。因为项目是基于别的项目组现成的代码的二次开发，我身为开发人员，对这个系统，有许多功能其实并不了解。因为要写测试用例，被迫每个功能都点了一下，结果发现，系统的功能很强大，做得十分完善，有些东西还让我惊艳。受到的益处像土匪一样浅薄。也许这个项目一路走来，有许多程序员在上面修修改改，其中有些代码写得不怎么样，符合屎山的定义。但毕竟，项目可以跑，没啥大问题，功能还很强大，有许多值得我学习的地方。这不，这两天我正好用上了测试时发现的功能，借鉴了代码，节省了时间，效果还挺好。

同时，在写测试用力的时候，因为要写得比较细致，对功能有了一些新的视角。所以，教科书上说，有些开发方法或模型，在需求分析阶段就写测试用例，其实也是有道理的。如果能将测试用例写出来，其实对功能的理解就十分到位了。用来指导开发，或者用于跟用户交流，都是不错的选择。