软件测试实训心得体会怎么写？15篇范文参考，轻松搞定报告

该实训报告在提交之后, 由教师给予了“合格”这一评价。但你自己是否思考过这样一个问题? 就是从实际需求到产品最终上线的整个流程之中, 你自己在内心真正想透彻、想明白的关键步骤具体是哪哪一个呢?

需求分析才是第一步

在实训开始的第一周期间, 授课教师明确要求学生们以五人为一个小组进行协作, 并且规定在现阶段禁止编写代码, 首要任务是把需求文档里的内容彻底搞明白, 然而我们小组里有一位男性成员没有听从安排, 直接就开始动手干活了, 结果等到两周过后才发现, 最终用户真正需要的是适用于Linux操作系统的环境, 而他之前所编写的程序全都是基于Windows系统的兼容方案, 因此不得不将整个功能模块推翻后重新搭建, 这一失误导致全组人员被迫进入了加班加点的工作状态。

在需求文档里面, 最容易缺失的信息就是运行环境以及并发量。我后来就聪明了, 把开工的动作放在先列一个确认清单这个环节之后去了, 要把操作系统、数据库类型、用户量级这几项内容逐一去询问清楚, 这样做的目的是为了省得后面出现需要返工的情况, 这一个步骤确实能够在关键时刻起到挽救局势的作用。

设计阶段别跳过去

在需求得到确认之后, 我们用了一周的时间去进行总体的设计与详细的规划, 这话说白了就是去画那个架构的图形, 去确定数据库里的表结构, 以及把功能模块分清楚。

我当时负责的是用户管理这一块, 我把MVC这三层各自需要干什么事情都给标注明白, 让每个人都能看得清清楚楚, 到了评审的时候, 老师这才点头认可, 然后说了一句可以开始动手做了。

在设计阶段, 大家最害怕的那种情况就是边写东西边改来改去。当时我们组里有一位同学, 他并没有等到方案评审完成就去动手写代码了。结果数据库字段的命名方式不统一, 导致在拼接接口的时候完全对不上号。

最后又花费了整整两天的时间来把这些内容对齐和修正。其实那种说法真的不假, 就是在设计环节多花上一天的时间, 能够在后面的编码环节节省出大概三天的工作量。

编码阶段分层思想是命根子

在进行代码编写的那两周时间里面，我觉得得到的最为重要的一个成果就是把那些有关SSH整合的事情以及DAO层的运行给真正地跑通了。

书本之上所提到的分层这样的两个字词在落到项目之中的时候具体体现为Controller仅仅是接收参数的部分, Service则是负责书写业务逻辑的部分, 至于DAO层仅仅是负责进行数据的增加与删除以及修改和查询这些操作, 各方职责分明, 谁也不可去越过界限去干别的事情，一旦出现越界的情况就会发生事故的。

这五个模块是由五个人分别负责各自的板块的, 但是对于那些公共的异常处理以及工具类这些部分, 是必须先要把接口定好的。我一开始呢没有跟组长把这个事情对起来, 是自己单独写了一套异常逻辑出来, 结果在合并代码的时候, 遇到了冲突的情况, 搞了一下午都还在处理这个问题, 最后白白熬了一个晚上。

测试不是跑完就完事

进入实训的第四周, 工作重心转向了测试环节。老师下达了指令, 要求编写测试用例, 并且必须涵盖单元、集成以及系统这3个层级层次。我具体负责的工作范围是黑盒测试部分。在设计过程中, 我结合了等价类划分法以及边界值分析法这两种技术手段, 最终一共拟定了42条测试用例。

然而, 在实际执行环节, 其中有3条测试用例在运行运行时直接触发了空指针异常故障。这一突发状况导致全组成员都陷入了愣住状态, 一时之间不知所措, 气氛也显得格外凝重。

白盒那几天我盯着一行"if(a>0&&b<10)"，单独测了a=0、b=10、a=0且b=10这几个边界，果然b=10时逻辑反了。测试计划得提前写死，不能想到哪测哪，否则漏测了上线才暴露。

维护阶段最容易被无视

在最后一周进行模拟上线维护的时候, 老师是故意放出了一个线上Bug的, 具体的现象是在某个接口在高并发的场景下出现了超时的情况, 于是我们那个小组就去加了连接池还有缓存技术, 然后整整磨了一天多时间才把事情给搞定, 说老实话这周确实比前面的所有周都要累得多一些, 但是通过这个过程学到的东西是最为扎实的。

维护这件事, 并不是说把东西修好了就彻底结束了, 而是需要把每一次进行修复的根本原因以及所有的改动细节, 全部清晰地记录在运维日志里面, 我们小组在这个环节中出现了疏漏, 没有做好相关的记录工作, 结果在面临答辩的时候, 被对方追问你是如何确认已经修复完毕的这一关键问题, 我们当时完全没有办法张口做出合理的回答, 导致印象分直接出现了大幅下降的情况。

答辩那天学到的最后一课

在答辩环节, 评委老师提问, 当需求发生变化的时候, 你这套设计方案要如何进行修改, 我一下子愣住了, 过了大概五秒钟的时间, 才终于把话接上来。

在这次实训开始之前, 我一直以为, 只要能把需求给跑通就算大功告成了, 可是经历完这次实训之后, 我才深刻地明白到, 需求发生变化那才是最普遍的正常情况, 所以在最初进行设计的时候, 提前把可扩展的那些点给预留好, 这比起直接把各种功能都写死在那里的做法, 重要性可是要大得多了。

这次实训里面的代码数量, 从总的情况来看是并不多的, 但是按照流程去进行操作这意思四个字的含义是被深深地刻在了大脑里面了。

无论是从需求的分析阶段一直到最后的维护阶段这一整个过程中的每一个步骤, 如果在这一过程中存在偷奸耍滑、偷懒的行为, 那么在后续的环节中就必然需要付出双倍的代价来进行偿还, 这样的一笔账目对于每一个人来说都需要自己进行具体的计算和权衡。

你在撰写实训心得的时候, 难道就是简单地照搬一些现成的模板, 还是说你确实有自己亲身遇到过的一些坑的详细记录? 欢迎大家在评论区里进行畅快的交流讨论, 如果你觉得这条内容很有价值, 那就请随手点个赞, 并且把它转发给身边有需要的朋友。