心得体会-软件测试心得体会(精选5篇)

软件测试心得体会（精选5篇）

软件测试心得体会（精选5篇）

关于软件测试的心得体会

虽然一如继往地写读书笔记，笔墨也浪费了不少。但真正坐下来利用大段的时间将自己的思路理清还没有过。因为最近有了一定的时间,更因为狠狠地泡了一段时间51Testing测试论坛,下载学习了该网站的电子测试杂志之后，自己的思路终于开始清晰起来，朦朦胧胧地开始看清了远方的路,麻着胆子去分析一下自己,也学着展望一下未来了,毕竟摸黑走路的感觉很不好。

我觉得学习软件测试的通用技术与针对某类软件的测试技术外,还有一个重要的与技术无关的方面:业务知识.没有具体的业务知识很难发现软件中潜在的逻辑错误甚至是需求上的错误,当然需求要依据特定的软件,但软件测试人员对需求理解的深入程度不应低于软件开发的人员.因为软件测试所有的依据来自于需求,而所有的需求来自于客户,甚至是我们的全部都来自于客户.识别需求后还必须转化为测试上的需求,毕竟测试人员看需求的角度和开发人员还是有区别的.

关于学习，我知道我并非计算机专业的学生,初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。但是,总该知道如何去学习，然而我认为，学习总该有必要的方法

1.找个好师傅

这是最重要的一条了,也是公司提供的最好的一个条件.刚进来的时候,td,测试案例都有一个pm细心的和你讲,案例有什么方法来设计?要注意哪

些错误?软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，一大堆的东西马上够你头晕的了.呵呵,还好,悟性不错,都囫囵吞枣地吞下去了.

2.学会读书

无论是神马专业，我始终确信，万变不离其宗，我知道，我不是这个专业的，但这个并不代表这我就不了解这个，再怎么不济，我也是从书本中走出来的，我相信，只要我努力地吧书本啃熟，我能够灵活地融入到这个职业中去，从书本中找寻解决问题的方法。标记出自己所错误的。

3.与前辈们一起讨论，多说

总有一天，我们会成为一位前辈，不过不是现在，至少现在我们应该好好的向别人学习，所以，我觉得，前辈是我们前进道路上不可或缺的一部分，他会成为引领我们前进的发动机，给我们指点，跟我们道工作的经验。然而，我们也应该多说，我知道，前辈们给我们讲解，已经是很辛苦的事情，毕竟，这不是他们的义务。我们也应该多多说说我们的观点，这样既能够让人家了解我们的水平，也方便老师前辈们对我们进行指导。

这些天的学习，我也有了一点自己的心得体会

体会一：软件测试在整个软件周期中的重要性。

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发现错误，而不在于验证软件是正确

的。

再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。第二篇、软件测试课收获和体会

软件测试心得体会（精选5篇）

软件测试课学习心得

1204013031许院生12计本3班

这个学期我学习了软件测试这门专业课程，在学期即将结束的时候，我也对这门课程建立基本的了解和理解。软件测试这门课程作为软件工程专业中一门很重要的课程，已经在软件领域占据了不可替代的角色，当一个软件从雏形到真正的在一台计算机上运行的时候，谁也不能保证计算机软件能一步到位的满足人们的需求。所以就有了软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。下面我简单的写一下这个学期对课程的总结和收获。

我认为，在整个庞大的软件工程中，不管是需求分析、架构设计甚至是最后的debug，都会产生引入不管的机会，这就要求作为一个软件测试师要掌握丰富的软件工程原理和知识。测试的工作将会存在于整个项目周期，即在项目开始时需要各种分析调研时就开始了。尤其是在形成需求规格说明书时就有对文档的测试需求，甚至主导整个项目的走向。

软件测试对逻辑思维、学习能力、反应要求很高，是否有严密的思维和

逆向思维也非常重要。做测试还要考虑到所有出错的可能性，有时候还要用一些非常规的的测试方法。软件测试还很注重软件性能问题，也就是要保证软件运行得很好；不同的使用环境下，考虑软件的兼容性同样重要。对于测试员来讲，会比开发人员更加重视软件产品的质量问题。在测试过程中，测试者可能会为客户的需求角度考虑

到更多，由此我们可以认为测试人员有权利决定产品是否可以发布。然而，通过一个学期的学期，我们又不得不懂得，软件测试人员不是万能的，测试人员在面对一个设计烂编码烂的软件时，也是无法不低头的，再怎么测试它也变不成优秀的软件。

通过课上的理论因为课下的实践和后半学期又因为身体力行于QQ群论坛里使我对测试方法和设计分析有了大致的接触和深入了解。收印象深刻的有一下几点。

1、最基本的测试的分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试；从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。

2、然后就是，白盒测试中的逻辑驱动测试的覆盖率测试。

3、还有就是对于划分等价类和边界值法这一块，让我从模糊到明朗。

4、在初次写测试用例的时候，感觉真是纠结，用例写的很死板，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。在后来负责了对论坛新鲜事版块的测试之后，明白了测试用例其实就是指导怎么去执行测试，而且书写设计测试用例也要以熟悉软件的业务为前提，才能更好的去测试。

另外就是一个学期的学习让我纠正了几点误区：

1.有位大师曾说过：“软件测试的目的在于发现错误，一个好的测试用例在于发现从来未发现的错误，一个成功的测试是发现了从未发现的错误的测试。”由此我自认为测试就是为了找到bug，然而一个学期的测试学习经验告诉我这是错误的，如果只是为了找到BUG，那么BUG会成天缠着你。软件测试心得体会（精选5篇）

2.在大家协力测试论坛的时期内，我曾认为这种大量的重复性的工作真的很乏味，可是在这乏味中真心发生挺多有意思的bug，意想不到的bug，所以我认为只要掌握了方法，在重复中寻到到创新的小惊喜，任何东西都有它的特点。

作为测试新手，通过一学期的学习，我认为能独立写测试计划，设计测试用例，精通一种测试工具，理解一种bug管理软件是新手晋级老手的必备素质。任重而道远？！

在最后，我不得不提的就是细心和耐心了。这是我认为这个学期测试课上收获最大的了，课程要求测试时必须细心和耐心，我在想，如果以后真的工作在测试一系列的岗位上，要学会坐得住，用大量的时间和精力和bug斗争，分离、识别还有归类bug，是不是也能真的改变我粗心大意和三分钟热度的毛病。

最后感谢刘老师这学期的课程讲授，和实践中的指导和帮助。测试路程，路漫漫其修远兮，吾将上下而求索。第三篇、软件测试课程学习心得

软件测试心得体会（精选5篇）

我所理解的软件测试

《软件测试方法和技术》这门课程，还是由张建东老师教我们的。在张老师的讲解下，我深刻的体会到软件测试是很有必要的。一个软件，从

最开始的可行性分析、需求分析、概要设计、详细设计、编写代码。这一系列的开发之下。千辛万苦的，花费了大量的人力物力、金钱时间，终于把软件给做出来了。你试着想一下，要是送到客户的手上，客户突然发现，软件用不了，或者是软件存在很大的缺陷。导致软件不好用、甚至比原先没有这个软件，还麻烦了。客户是很愤怒的。客户一愤怒，就导致客户不会付钱。这最终，项目失败，造成资源的大量浪费，所以说软件测试还是很有必要的。再者就是，软件测试可以发现软件的缺陷，从而通知编程人员不断改进软件。在这样不断测试，不断改进的情况下。将软件性能不断提高，软件变得越来越好用。

软件测试，旨在发现软件的缺陷。可以这样说，软件测试就是以发现软件缺陷，为最终目的的测试活动。它通过软件测试方法，白盒的、黑盒的、静态的或是动态的。借助软件测试工具，来找到缺陷。然后在缺陷评审和确认之后将缺陷记录下来，并用缺陷管理工具管理，详细描述，关注软件缺陷的发生周期。对它的严重性、和优先级下一个定义。书写软件缺陷报告，具名缺陷的重现步骤、测试的期望结果与实际结果、还有相关图片、文字资料。提交给软件编程人员，来完成软件缺陷的修复。软件测试的方法，包括：白盒测试和黑盒测试。其中，白盒测试之中，有含有：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖、等方法。黑盒测试方法中，有：等价类划分法、边界值分析法、判定表法、因果图法等。软件测试方法，按照是否运行代码来看，可以分为：静态测试和动态测试。其中静态测试有，对代码的走查和评审。动态测试，则是要通过运行代码来执行。白盒测试多用于软件的单元测试上，黑盒测试多用于功能性测试上。代码的静态测试和动态

测试，则是每一个软件项目都必须的。

单元测试，多构造桩函数或是驱动程序来测试。一般借助与各种软件测试工具。软件测试，或者说程序测试。一般先是进行单元测试。单元测试，修改完单元之中的缺陷、错误之后，就是集成测试。集成测试多针对程序功能进行测试，看程序的各项功能是否达到要求，是否齐全。集成测试之后就是系统测试。系统测试是针对整个软件系统的。看软件系统是否达到性能的要求。从而改进代码，以求达到系统的严格要求。最后就是验收测试，这个测试，一般都分成两半来做。一半是，程序员模拟客户环境，进行测试。而，另一半则是，真正的客户参与的测试。最大程度的体现客户的真实环境。客户在试运行的情况下，看是否会发现，平时发现并且以前的环境发现不了的问题。

验收测试，包含对界面的测试和软件可用性的测试，运用尼尔森十大原则，来测试软件是否好用。软件是否达到用户的对软件界面的需求。

无论是软件编写，还是软件测试，都需要相应的文档管理。还有针对软件测试制定的测试计划，软件测试执行等。

通过本学期的学习，我感受到软件测试是一门非常需要学习的课程。即使作为考察课程，它也是软件行业人士所必须了解的知识。它对软件工程项目的作用是至关重要的。现在，作为学生的我所做的项目虽然都是一些小的项目，但是在小组共同开发的时候还是需要用到

项目的测试。如今这门课程我学的还不是很好，但我相信在今后的实训及工作当中，能够更好的体验和感受到项目测试的精髓，对软件项目测试有更深入的了解。我也希望，学校的老师能够在今后的教学当中重视软件项目测试课程，多让学生了解实例，去感受、体会软件项目测试所

遇到的问题和解决方案，理解软件项目测试的精髓。第四篇、软件测试的一些心得和建议

软件测试心得体会（精选5篇）

一、软件测试员自身素质培养

（1）首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，相信一定能克服。

（2）善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是对的。

（3）打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

（4）保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。

（5）做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

（6）灵活一些，聪明一点，多制造一些容易产生bug的例子。

（7）在有条件的情况下，多和客户沟通，他们身上有你所需要的。（8）设身处地为客户着想，从他们的角度去测试系统。

（9）不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

（10）考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

（11）提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新

手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。（12）追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

（13）幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

（14）到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？

二、浅谈软件测试之技巧

软件测试虽然辛苦，但是掌握了一定的技巧之后可以事半功倍。

（1）边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

（2）非法测试，例如在输入数字的地方输入字母。

（3）跟踪测试，跟踪一条数据的流程,保证数据的正确性。

（4）在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

（5）接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

（6）代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。（7）突发事件测试，服务器上可能发生意外情况的测试。

（8）外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时,这个系统所受到的影响的情况。

（9）在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。（10）认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。软件测试心得体会（精选5篇）

（11）文字测试，如果在系统中有用词不当的地方，我想这是不应该的。（12）系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WINxx下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可

能发现BUG。

（13）用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。第五篇、软件测试员工作心得体会xx最新范文

软件测试心得体会（精选5篇）

软件测试员工作心得体会xx最新范文

它存在于整个项目周期，在项目开始之初需求调研的时候就开始了，在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重，能主导整个项目的走向，成败与否全在于开始阶段的决策。

体会二：软件测试的真正意义在于发现错误，而不在于验证软件是正确的。

再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。体会三：在系统性能测试方面需要重视。

经过这次培训中多个案例的讲解，让我了解到系统在上线之后会有很多不能预知的性能问题，需要在上线之前实现进行模拟，以规避风险，包括大数据量访问，高并发数等等。

当然也有很多应对手段，没有哪种手段可称为最完美，只有最合适的，需要灵活掌握，综合运用以达到最优程度，这是个很值得研究的领域。下面是本人的几点想法：

想法一：加强系统上线前的性能测试。

目前我们在项目建设过程中对性能压力测试的重视程度还不太高，厂家也很少有雇佣第三方的测试机构。而是在现网进行试用，遇到问题再解决，可能会产生滞后问题，影响客户使用。希望以后能在性能测试方面提高重视程度，加大人力投入，以保证系统上线后能够稳定运行。

想法二：适当介入相关项目研发

对于快速响应这块，我们不能一味依赖厂家，而希望自己就能快速响应，及时将问题解决。这也是一个比较长远的问题，需要加强研发力量的投入。

我个人是做开发出身，有此类经验，当时是在客户现场，因为了解系统内部结构，能够在第一时间排查解决客户所反馈问题。

现在系统完全由厂家开发，很难了解内部结构，或许会造成后期维护困

难。所以，是否应该针对某些项目介入厂家研发工作，比如请厂家提供源代码等

相关要素，以增进维护人员对系统的了解。

最后再次感谢公司提供的平台，感谢领导的信任，让我有机会得到更深层次的学习以及展示自己能力的机会，我也会尽我所能来完善工作的系统，提高整体工作效率，为南方电网的发展建设提供更坚实，优秀的支撑服务平台。

资料来源：第六篇、软件测试学习感悟

软件测试心得体会（精选5篇）

学习软件测试的感受及体会

这学期学习了赵培英老师教授的软件测试这门计算机专业的专业课，我们学院又开设了刘老师的关于这方面的讲座，更彻底的使我们加深了对软件测试的认识。所以我想谈谈关于软件测试的体会及学到的一些知识。作为计算机专业的一门很重要的课程，在计算机领域占据着不可替代的角色，随着人类社会的进步，各种领域计算机的普及，计算机软件也越来越多的出现在各个场合，为人们的办公，生活，学习，休闲等提供了前所未有的方便。软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Dotherightthing），另一方面是确认软件以正确的方式来做了这个事件（Doitright）。作为计算机专业的学生，我想以我自己的观点来阐述一下我对软件测试的理解。

以前，就是在我没有认真了解测试行业之前，我也一直认为测试应该是不重要的，甚至认为有必要有专门的测试职业吗？认为软件主要是开发人员的事，软件的成果也是由开发人员决定的，当我学了软件工程这门

课，真正的了解到它的必要性，事实上真的不是那么一回事哦。软件无处不在，然而，软件是人编的——所以不完美。

我还查阅了一些资料就是不注意软件测试的案例：

1、迪士尼的狮子王（xx～xx）软件在少数系统中能正常工作，但在大众使用的常见系统中不行。后来证实，迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。

2、英特尔奔腾浮点除法软件缺陷（xx）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价，其主要原因是发现了软件缺陷没有正确的处理。

3、美国航天局火星极地登陆（xx）该项目使用前有经过测试，两个测试小组双方独立工作都很好，但从未走在一起。软件测试心得体会（精选5篇）

4、爱国者导弹防御系统（xx）一枚导弹在多哈击毙28名美国士兵，症结在于一个软件缺陷：一个很小的系统时钟错误累积起来就可能拖延14小时，

造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。

5、千年虫（大约1974）估计世界各地更换或升级该系统程序解决原有xx年错误的费用已经超过数亿美元。

这就是不注重测试的一些严重后果，因此我们发现了软件测试的必要性！在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则，包括：1、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。

2、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。

3、Pareto原则应用于软件测试。简单地讲，Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。

4、测试应从小规模开始，逐步转向大规模。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5、为了达到最佳效果，应该由独立的第三方来构造测试。最佳效果指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

6、不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.。软件测试心得体会（精选5篇）

还有就是关于软件测试的分类：从是否需要执行被测软件的角度，可分为：－静态测试

－动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为：－白盒测试

－黑盒测试

关于静态测试和动态测试：

（1）静态测试是指不实际运行被测软件，而只是静态的检查程序代码、

界面或文档中可能存在的错误的过程。

其中包括代码测试、界面测试和文档测试3个方面。对于代码测试，主要测试代码是否符合相应的标准和规范。对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。对于文档测试，主要测试用户手册和需求说明是否符合用户的实际要求。

（2）动态测试是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以，我们判断一个测试属于动态还是静态测试，唯一的标准就是看是否运行程序。

关于黑盒测试和白盒测试：

（1）黑盒测试

指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子，只关心软件的输入数据和输出结果。

黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误: ?是否有不正确或遗漏了的功能?

?在接口上，输入能否正确地接受?能否输出正确的结果?

?是否有数据结构错误或外部信息(例如数据文件)访问错误?

?性能上是否能够满足要求?

?是否有初始化或终止性错误?

用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。

黑盒测试的测试用例设计

?等价划分法

?边界值法

?错误推测法

?因果图法

（2）白盒测试

指的是把盒子盖打开，去研究里面的源代码和程序结构。

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

白盒测试的主要方法：

?逻辑驱动测试

?基本路径测试

主要用于软件验证。

使用程序设计的控制结构导出测试用例。

逻辑驱动测试：

主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下6种类型：?语句覆盖

?判断覆盖

?条件覆盖

?判定-条件覆盖

?条件组合覆盖

?路径覆盖

白盒测试的主要目的

?保证一个模块中的所有独立路径至少被执行一次；

?对所有的逻辑值均需要测试真、假两个分支；

?在上下边界及可操作范围内运行所有循环；

?检查内部数据结构以确保其有效性

测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Dotherightthing），另一方面是确认软件以正确的方式来做了这个事件（Doitright）；第二是提供信息，比如提供给

开发人员或程序经理的反馈信息，为风险评估所准备的信息；第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。

经过这一门课程的学习和老师的给我们的讲座，意识到测试并非是我想像的从客户角度任意使用软件产品，从而发现有无质量问题，它有它的理论和实践体系。软件测试是一项严谨的工作，软件测试员一个基本的素质是打破砂锅问到底。喜欢找出那些深藏不露的系统冲突，乐于处理最复杂的问题，外表上热衷於来回奔忙，追求尽善尽美，为征服系统而额手称庆。

最后特别感谢老师对我们的课程学习的讲授，让我们了解到计算机更多

的知识，也让我们了解到求职关于计算机方面的岗位，应具备哪些专业知识，谢谢老师！第七篇、软件测试----个人体会小结

软件测试心得体会（精选5篇）

软件测试----个人体会小结实习结束了，从7.21—12.3号。走的时候有点伤感不舍，但也有很多的收获，很多美好的回忆，有很多感激。现对实习的工作收获体会做个总结吧实习没有我刚踏入社会时想的那么美好，工作很累，刚开始觉得考研是最累的，但工作同样很累，压力是上级给你的，自己更多的要去调节这种压力；而考研的压力是自己的给的，性质完全不同。但无论选择哪条路，都没有什么对错，我觉得。实习后本来想留下来，但最后还是离开了。实习阶段无论是工作能力上，还是为人处世上，都给了我一个历练的过程，虽然只有4个多月，但收获频多。

1.软件测试技术的提高测试技术的提高，这是最明显的.做了四五个项目，和20个左右的日常需求。编写TC:第一，编写TC的能力提高，编写TC 需要很细致，写的时候要同时多思考，扩散思维的去写，这样写出来的TC才是有价值的，有含金量的，思考的过程能让你想到按部就班写时想不到的情况。比如：写TC的时候要考虑有设置导航属性属性值时，才可以显示导航。这时要扩散下想，设置了导航属性，但没有设置属性值，会是什么情况。第二，很重要的一点，特别是项目比较大的时候。编写TC前，有写测试设计的一个过程，在写测试设计的时候，就应该把测试点的思路理清晰。画MM（freemind）图是个很好的方式，MM图已经可以相当于测试的一个框架，搭建框架的过程，也就是理清思路的一个过程，在MM图的叶子节点，可以细化到最终的一个测试功能点，把该功能点对于的规则写到MM图的备注上，写TC时就不容易漏掉测试点

了。第三，编写TC思路很重要，思路不清晰是不可能写出有含金量的TC的，即使写了也是平淡无味的，特别是功能逻辑复杂，需求变更比较多的点。这时，写TC前要先理下思路，可以从外到里，一步步的罗列下测试点，打个草稿，下手写TC的时候就思路清晰，即使有MM图了也有必要再这么做一次。第四，TC写完以后一定要再过一遍，再让同事review下，因为人无完人，没人能考虑的万无一失。同事指出不足的时候，也是你提高学习的一个过程。第五，每个公司都有自己的规范，有时候这些框框会定住你的思维，这时要特别注意变通下，提醒下自己。写测试设计：测试设计的好处很多，如果可能的话，自己负责的模块一定要自己仔细写测试设计。目前我在测试设计时主要用到MM图，流程图，判定表。MM图的重要性上面已经讲过了，流程图主要针对流程性比较强，逻辑多的功能模块。判定表最后一个项目才用到过，用到还不熟，一点个人体会

是判定表不是什么地方都适合画的，主要适合存在的情况比较多且关系密切的时候。比如：库存量，本来就只有0或非0两种可能，就没必要把这个条件加入判定表了。执行测试：执行测试，发现问题，解决问题。才能最终体现测试人员的价值。这三个步骤每个都很重要。执行测试是最基础的，不多说了。发现BUG的能力需要测试人员的细心，专注和扩散思维能力，有时候经验也很重要。比如一些同步的功能点、边界值时页面的展示问题、还有新功能的链接问题等都是容易出错的地方，需要特别注意。有时候，特别是到最后第三轮测试时，一些边边角角的地方要重点关注下，是之前测试容易忽略的地方，往往也是开发人员容易忽略的地方。比如js错等。发现bug后要解决bug，如果没有解决，那测

试人员前面的工作相当于没有意义了。所以这步很重要。解决问题看起来很简单，告诉开发人员解决就好了。但实际上不是这样的，从实习阶段过来，我觉得解决bug，是我最需要提升的一个地方，也越来越发现它的重要性。解决bug分好几步，首先，要重现bug，如重现了，再判断下是不是个bug，因为有时会规则本来就是这样，或由于你的操作没有符合规则造成的正常结果。如果判定是个bug，这时你要想想这个bug 是个什么bug，定位下问题，这需要经验，也需要多思考才可以。如果定位正确，缩小bug的范围，可以有效的帮助开发解决bug，提高bug 解决效率。但如果定位错了，很可能会误导开发。所以要三思，当然个人觉得这部也是技术含量最高的一步。接下去就得提bug给开发了，bug 的描述一定要清晰简洁，避免出现踢皮球现象。Bug提好了还有跟进bug 解决。如果是严重的bug，最好再通知下开发立即解决，bug拖得越久风险越大。可以养成每天早上开机，首先看下缺陷库里的bug，将fixed的bug再验证一遍，没有解决的问题，看下严重程度，督促开发解决。如果严重bug开发没能及时解决，要考虑报告pm等，协助开发人员解决。处理bug的效率不当是开发的责任，也体现了一个测试人员的能力，如何有效控制跟踪bug尽早解决，是一门学问，也是成为开发欣赏的测试人员的重要一步，以后还要多努力。自动化测试：能有幸在实习阶段学到自动化测试的东西，是很欣慰的。现在已经能独立编写自动化脚本，不过写脚本也是要细心，要多思考才行，另外要注意自己多注入营养，遇到问题先自己主动去解决，不行再求教别人。自动化脚本开发是一个长期的过程，虽然现在工作告一段落，但这块我不会放弃掉，而且希望能对这方面有更多的了解进步