作为测试人员来讲在日常的测试工作中有个工作内容或者环节肯定是少不了的那就是编写测试用例。以前刚开始入手做测试的时候说实话我并没有认识到测试用例的重要性。我觉得对于我而言首先编写测试用例就是耽误自己的测试时间特别是项目很紧急的时候其次我觉得这个Web的功能看起来并不复杂只要我够仔细认真我肯定不会漏测的。可是后续暴露的问题证明我过于盲目自信了出现了个小问题是在产品验收时发现的并没有暴露给用户。后来组内进行阶段复盘的时候提到这件事情当时我被问到“这个点为什么会漏测呢有没有测试用例为什么没有写用例”面对他人一连串的发问我顿时觉得无力回答。我的带教师傅给我“上了一课”。师傅和我说“当你的能力还不足够的时候一定要从做好基础工作开始不要还没学会走路就想着跑”。师傅所说的基础工作就是写测试用例。我后来意识到写用例永远是测试人员工作中最基础但却很重要的工作。在后续的测试工作中我会按照标准去编写测试用例然后将我输出的测试用例给带教师傅看请他帮忙检查有不好的地方再进行修正。持续了几次之后我觉得我不再抗拒写测试用例了因为我觉得在编写测试用例的过程中帮助我打开了思路也指导了我后续的测试执行甚至极大提高了我的测试效率和测试质量这与我之前认为“写用例纯粹是浪费时间”的结论截然相反。刚开始写用例的时候也会遇到一些问题。比如用例中的描述如何做到简洁准确、如何让别人容易理解我写的用例、如何避免歧义、如何避免冗余用例、如何把握好用例的颗粒度等等。如何改善并解决这些问题呢我的办法是一方面多阅读其他测试同学编写的测试用例学习他们写得好的地方进行模仿借鉴第二方面是请带教师傅帮我检查。慢慢地我就能够写出比较规范易懂的测试用例了。我的体会是写用例简单写好用例不容易这是一份值得钻研的工作。上面提到了我个人对于写测试用例“心路历程”的变化为什么要写测试用例呢他的意义在哪我个人觉得有至少以下几点好处1、帮助测试人员剖析需求、梳理思路2、尝试用可以作为测试工作的依据和记录可以知道测试工作在回归测试、分析问题的时候能做到有据可查3、规范测试的执行提高测试效率和质量减少非必要的、冗余的测试执行避免漏测等如何去编写和组织测试用例测试用例如何去指导我们的测试工作呢下面简单介绍下测试用例的内容每条测试用例就是描述一个待检查的具体操作项一般来讲包括测试编号、用例标题、项目模块、优先级、前置条件、操作步骤、预期结果、测试结果等。有的还会把测试数据单独作为一项列出来这个没有什么强制要求一般根据自己的内部规范或者习惯自定义即可。组织测试用例的工具常用的可能是思维导图和Excel 软件。可以用思维导图帮助自己分析需求、梳理思维先写出测试点然后在Ecxel中针对测试点去组合书写出测试用例。用例写完之后需要按照业务或功能重要性去设置优先级比如我们常用的是P0 -P4P0优先级最高P4优先级最低。测试用例的评审写完测试用例后条件满足的话一般会先进行组内评审组内评审之后针对发现的问题对用例进行优化和补充。组内评审通过之后进行项目组内的用例评审与会人员一般涉及到产品经理、开发人员、测试人员等。评审后同样需要根据大家反馈的问题对用例进行优化补充然后再同步给大家。测试用例的执行测试人员需要根据评审并修正后的测试用例来执行测试并记录测试用例的执行结果。要确保每一条用例都得到正确执行并记录结果。这个过程非常重要我包括我的同事都曾有过没有按照用例去严格执行测试或记录结果导致漏测的情况。测试用例应该作为我们测试的依据和记录对于我们的测试活动起着指导作用。测试过程中用例的调整在测试用例评审完成之后到项目上线之前的这段时间产品需求或开发的技术实现往往会有所调整这要求我们的测试用例也要做到及时调整防止出现预期结果与实际结果不一致的情况后续追溯以来会比较麻烦毕竟测试用例是我们的测试依据。以上就是我个人对于软件测试工作中编写测试用例的一点体悟和见解。通过写用例这项工作我意识到基础工作的重要性有时候看起来很底层的事情往往很容易被忽视但这却是极其重要且比较难以做好的。我记得我曾经的领导和我说过测试工作是一门科学不是一门玄学是应该有据可依的且可以做到有据可依的。我觉得很受用也期待朋友们有所收获感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取