软件测试实训心得怎么写？学生视角的深度反思干货

许多人都认为软件测试仅仅是在上线之前进行那么几下鼠标的点击以便寻找错误, 然而在经历了这次的实训过程之后, 本人充分地意识到了这样的一个问题, 即测试工作其实是从需求调研的第一天就已经开始了, 一旦在其中任何一个环节出现了遗漏的情况那么就有可能给最终的给客户造成非常巨大的隐患。

测试不是上线前才做的事

在需求调研的阶段测试工作就介入了, 当需要编写需求规格说明书时必须要对文档内容做逻辑验证, 去确认是否存在矛盾的地方以及有没有遗漏的情况, 如果这一步骤没有完成, 那么后续开发出来的产品方向很可能就是错误的。

在系统正式上线之前, 我们需要分别启动两个不同的运行环境来进行测试。一方面, 我们要使用功能测试环境来验证需求和具体的功能是否达标；另一方面, 我们利用镜像环境去模拟真实的生产环境, 目的是为了对功能测试阶段遗留下来的一些小毛病进行回归检查。

只有严格通过这两道关卡的把关, 我们才能确保交付的质量是稳定可靠的。

再严密的测试也兜不住所有问题

测试这一行为, 它能够发现绝大多数的错误情况, 但是, 它没有办法确保软件产品中一个缺陷也没有存在, 其核心目的, 在于让软件产品达到基本可以使用的状态, 而对于其余部分的问题, 则依赖于在软件上线之后, 所建立的快速响应机制去进行兜底性的保障处理。

在最终的普通老百姓还察觉不到问题的之前, 进行测试的那伙子人要去主动地把情况给揪出来。一旦等到了客户打电话过来讲说那个软件没法用的时候, 那丢失的便是信任了, 这个事情的性质是绝对不一样的。

性能风险必须在上线前模拟

那个关于实训的案例, 讲解得确实是非常清楚, 并且指出了这样一个事实, 那就是系统在正式上线运行之后, 会出现非常多无法预先知道的关于性能方面的问题情况。在面对大数据量的访问请求以及高并发数量的冲击时, 如果没有在提前进行压力测试, 那么直接上线的行为就完全等同于一种赌博。

根本不存在那种算是完美的应对手段, 实际情况是只有最合适的才管用。针对压力测试、限流处理以及降级操作这些事, 必须得结合着项目的具体实际状况去灵活地加以组合使用。

在当前阶段进行项目建设的时候, 大家对于性能压测这一块的重视程度普遍都偏低一些。大多数情况下, 厂家几乎是不会去专门找第三方的专业机构来开展相关工作的。

工具是测试效率的底线

缺陷管理使用 bugzilla, 用例管理使用 testlink。对于缺陷情况, 要描述得非常详细, 并且记录下发生的周期。这样做是为了方便后续的追溯, 也是为了方便进行统计分析。如果把工具用得不好, 相关信息就会全都散乱地待在脑子里。

在此次实训课程当中, 我们学习了如何使用Ruby这个编程语言以及Watir这个工具来编写自动化测试脚本, 这样就可以把那些需要反复执行的测试环节给固定住。

而在编写测试用例表格的时候, 针对各项功能点的描述应该尽量做到足够细微, 同时还要对数据的输入、数据的输出、出错的提示语以及操作发生的时间戳等这些内容, 都原原本本地进行真实记录。

测试远不是枯燥点鼠标

以前我总以为是只要反复地操作软件, 就能够发现那些异常情况了, 并且认为做测试这件事, 比去做开发要低人一等一些。

可是实际上, 如果要把软件测试这一件事情做得比较好的话, 是需要具备关于网络、还有数据库、等等方面的操作系统这些知识的, 而我之前所学习的东西呢，它叫做信息与计算科学这样一个专业, 所以这里面所包含的这些基础性的东西, 是可以直接拿来就用的。

个人素质这一块是非常关键的, 耐心、细心以及沟通能力要贯穿到你整个职业生涯的每一个阶段去, 做测试的时候需要跟开发人员还有产品人员进行反复地沟通与交流, 仅仅拥有技术能力是不够的, 如果不太会说话那么很多事情是很难推动下去的。

开发出身反而更懂测试痛点

我之前一直从事软件开发相关的工作, 在客户现场的时候, 因为我对系统的内部结构非常了解, 所以能够第一时间对出现的问题进行排查和解决, 而维护人员如果仅仅依靠黑盒操作的方式来进行工作, 那么他们的工作效率肯定会出现大幅度的下降情况。

是否应该在某些项目里面让厂家提供源代码以及其他一些相关要素, 以此来增进维护人员对于系统的理解程度? 这个问题是值得进行一番讨论的, 但是它能够确实地带来大幅缩短故障定位时间这样的好处的。

你是否在从事测试工作过程中遭遇过这样的状况, 那就是开发人员仅仅针对你所报告的缺陷进行修改操作, 进而导致系统内其他原本正常运行的功能模块出现全面崩溃的严重后果呢? 欢迎你在相关评论区域分享个人亲身经历与感受, 倘若觉得该内容有价值不妨点击赞以及转发按钮。