软件测试的个人总结

软件测试通过系统验证和缺陷发现，确保产品质量与用户体验，提升开发效率，是否能更好地满足市场需求？下面是小编为您整理的软件测试的个人总结范例，仅供参考，希望能够有所帮助。

软件测试的个人总结 1

这学期的期末大作业是对ELearning Java Web应用系统进行测试，通过这次系统测试，我学到了很多知识，软件测试个人总结。对于具体的测试部分，我主要做的是单元测试和性能测试，其中单元测试使用的是Junit工具，性能测试使用的是JMeter。就这次大作业而言，我认为它与我们平时做的实验很不相同，我们平时的实验只是涉及到测试的某个小部分，而这次测试却是对一个相对完整的项目按照规范的标准进行测试。

对于好的测试来说，应该注意一下几点：

1.测试的独立性：一次只测试一个对象，方便定位出错的位置。这有2层意思：一个TestCase，只测试一个对象；一个TestMethod，只测试这个对象中的一个方法。

2.给测试方法一个合适的名字。

3.在assert函数中给出失败的原因，如：assertTrue("…should be true",…)，方便查错。在这个例子中，如果无法通过assertTrue，那么给出的消息将被显示。在junit中每个assert函数都有第一个参数是出错时显示消息的函数原型。

4.测试所有可能引起失败的。地方，如：一个类中频繁改动的函数。对于那些仅仅只含有getter/setter的类，如果是由IDE(如Eclipse)产生的，则可不测；如果是人工写，那么最好测试一下。

5.在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如针对与测试方法A和B，在setUp和tearDown中的代码应该是A和B都需要的代码。

6.测试代码的组织：相同的包，不同的目录。这样，测试代码可以访问被测试类的protected变量/方法，方便测试代码的编写。放在不同的目录，则方便了测试代码的管理以及代码的打包和发布。

对于测试用例的命名，我们最好要使其与测试类的名称相一致，比如说，类的名称为Testing，此类的测试用例的名称为TestingTest。当我们把测试代码和被测的代码放在同一目录下时，我们就可以在编译被测代码的同时编译测试代码，从而确保两者是同步更新的，工作总结《软件测试个人总结》。事实上当前的普遍做法，就是把单元测试视为build的一个环节。保持测试之间的独立性是一个很好的习惯，使得它们在任何次序下执行的结果都是相同的。如果真得需要某些测试按照特定的次序执行，我们可以借助addtest来实现。当我们需要增加一个测试时，我们要书写一个自己的测试用例，但是如果喜欢在测试用例的构造函数中做有关的初始化工作，这就不是个好习惯。数据文件应该尽可能和源代码一起都放在配置管理系统上，但这样一来如果我们采用上面的resource机制，我们就需要做一件工作，就是把数据文件从原来的位置-就是源代码的某个相对路径，拷贝到编译后的位置，也就是class文件的相应的相对路径。

通过这次软件测试的系统测试，我对软件测试有了更加深刻的认识，其实软件测试并不像想象的那么简单，它需要测试人员具备多方面的能力和素质。软件测试人员应该拥有广阔的视野、一定的编程能力、细心和耐心等等。这些对于能否测出优秀的系统来说都是必不可少的。

经过这次对java Web应用系统的测试，我的测试能力得到了锻炼，对软件测试有了比较全面的认识，收获了很多珍贵的东西，而且我也从软件测试的角度，对编写健壮的程序也有了新的认识。