《软件测试心得体会软件测试的心得体会(4篇).docx》由会员分享，可在线阅读，更多相关《软件测试心得体会软件测试的心得体会(4篇).docx（7页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 软件测试心得体会软件测试的心得体会(4篇)软件测试心得体会 软件测试的心得体会篇一 再严密的测试也不能完全发觉软件当中全部的错误，但是测试还是能发觉大局部的错误，能确保软件根本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前准时主动的去发觉并解决。这一点就需要加强研发队伍的建立。 经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有许多不能预知的性能问题，需要在上线之前实现进展模拟，以躲避风险，包括大数据量访问，高并发数等等。 固然也有许多应对手段，没有哪种手段可称为最完善，只有最适宜的，需要敏捷把握，综合运用以到达最优程度，这是个
2、很值得讨论的领域。 目前我们在工程建立过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进展试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。盼望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。 对于快速响应这块，我们不能一味依靠厂家，而盼望自己就能快速响应，准时将问题解决。这也是一个比拟长远的问题，需要加强研发力气的投入。 我个人是做开发出身，有此类阅历，当时是在客户现场，由于了解系统内部构造，能够在第一时间排查解决客户所反应问题。 现在系统完全由厂家开发，很难了解内部构造，或许会造成后期维护困难。所以，是否应当针对某些工
3、程介入厂家研发工作，比方请厂家供应源代码等相关要素，以增进维护人员对系统的了解。 最终再次感谢公司供应的平台，感谢领导的信任，让我有时机得到更深层次的学习以及展现自己力量的时机，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的进展建立供应更坚实，优秀的支撑效劳平台。 软件测试心得体会 软件测试的心得体会篇二 这个暑假惠普派人到我们学校来开展软件测试培训。教师说时机难得所以我就参与了，说实话每天在教师从早晨坐到下午，中间只有一个半小时休息时间，这样还是相当累人的。我们第一天开头就觉得这个简直比寻常上课还累啊。 不过 看到教师讲得如此仔细，看到惠普如此强大，我看在座的学员都听得特别仔
4、细。所以向我这种上课从来不听讲的这回都听得仔细得不得了，呵呵。 前两天的确还是有点累，讲的也是理论课，而且以前我们从来没有接触过测试这个行业，所以听得也嘿吃力。但是教师给我们讲了不少他们的工作阅历和惠普这种世界五百强美国十强的企业文化，鄙人是深受教育啊。 后两天我们每个人带一个笔记本进展上机操作了。我们的第一个任务就是安装软件，那个软件好大啊 ，整整2个g。我们考啊考啊考了好久才考完。软件叫qtp，就是惠普的快速测试专业版。的确是一个强大的软件，呵呵 大家用了就晓得了! 有 了电脑自然好耍了，我们休息的 时候就上网啊，我看猫和老鼠都看得差不多了。不过那个软件究竟是大软件，操作还是比拟简单，而且
5、全英文版，对我这种英语水平的人的确有点难以承受a。不过 呢，我还是在教师的敬业精神鼓舞下学到了不少学问 受益匪浅啊，单词也记到了不少!离六级又近了一步! 四天的培训在今日就彻底的完毕 了，下午教师给我们开 座谈会，问我们有什么问题，结果呢我们一点问题都没得。教师教得好啊 呵呵!我们没得问题 教师又只有给我们说他的光芒历史了撒 。什么当年大学毕业了差点工作都没找到啊，什么当年英语学得最撇啊，还有找不到工作在网吧郁闷打嬉戏啊 呵呵。 我记得教师说得最有感情的一句话就是“社会是黑暗的啊”。我们对这句话都是深信不疑!所以以后呢，要好好努力啊，不管社会有 好黑暗你都能找到光明，生活就是如此，时间本就平凡
6、。好好干好好干! 软件测试心得体会 软件测试的心得体会篇三 软件测试在整个软件周期中的重要性，它存在于整个工程周期，在工程开头之初需求调研的时候就开头了，在形成需求规格说明书的时候就需要针对文档进展测试。这个环节在后续整个工程中占了很大的比重，能主导整个工程的走向，成败与否全在于开头阶段的决策。 体会一：软件测试的真正意义在于发觉错误，而不在于验证软件是正确的。 再严密的测试也不能完全发觉软件当中全部的错误，但是测试还是能发觉大局部的错误，能确保软件根本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前准时主动的去发觉并解决。这一点就需要加强
7、研发队伍的建立。 体会二：在系统性能测试方面需要重视。 经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有许多不能预知的性能问题，需要在上线之前实现进展模拟，以躲避风险，包括大数据量访问，高并发数等等。 固然也有许多应对手段，没有哪种手段可称为最完善，只有最适宜的，需要敏捷把握，综合运用以到达最优程度，这是个很值得讨论的领域。 下面是本人的几点想法： 想法一：加强系统上线前的性能测试。 目前我们在工程建立过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进展试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。盼望以后能在性能测试方面提高重视程度，加
8、大人力投入，以保证系统上线后能够稳定运行。 想法二：适当介入相关工程研发 对于快速响应这块，我们不能一味依靠厂家，而盼望自己就能快速响应，准时将问题解决。这也是一个比拟长远的问题，需要加强研发力气的投入。 我个人是做开发出身，有此类阅历，当时是在客户现场，由于了解系统内部构造，能够在第一时间排查解决客户所反应问题。 现在系统完全由厂家开发，很难了解内部构造，或许会造成后期维护困难。所以，是否应当针对某些工程介入厂家研发工作，比方请厂家供应源代码等相关要素，以增进维护人员对系统的了解。 最终再次感谢公司供应的平台，感谢领导的信任，让我有时机得到更深层次的学习以及展现自己力量的时机，我也会尽我所能
9、来完善工作的系统，提高整体工作效率，为南方电网的进展建立供应更坚实，优秀的支撑效劳平台。 软件测试心得体会 软件测试的心得体会篇四 在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应当是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。 而通过这次的这次分析觉得自己的测分还存在以下的问题： 1、太关注开发的内部实现规律。建议：将开发内部实现规律看成一个黑盒子，测试分析
10、要从这个黑盒子的输入和输出上去看开发内部实现规律是不是有问题，而不应当先去了解开发的实现规律然后根据他们的思路去分析。 2、分析文档写的过于具体，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写具体设计的道理一样)，这样后面的人才会自己主动去想问题。 3、分析文档要考虑维护性问题，不要消失类似比方还款中状态为“r”这种详细的数据内容。由于我的分析是对后续用例编写人员的一个指导性的文档，所以假如侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应当详细写到r这么细节，否则的话开发稍作变动
11、我们就要相应变动我们的用例 4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白究竟是怎么回事。 总结： 1、以后写测试分析文档，依据仅仅是prd文档，必需抛开开发实现规律局部(即不去看系分文档)，待测分出来之后，再去看系分文档，相互看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去相互明确更细节的东西。 2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上局部，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个掩盖，在针对路径的用例中不需要关注到数据库表级那么细。 3、在做流程路径掩盖之前应当画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进展路径掩盖。