软件测试工作总结

20xx.09—20xx.12 用友行业测试部

刚来到用友，我进入到了行业测试部，被安排在房地产NCV5.7项目上，主要测试项目过程管理和运营管理模块，房地产产品涵盖了项目建设的各个阶段的业务应用，从项目建设期间的规划，投标，施工，到后期的项目运营。我从认真学习产品的需求文档和课件资料开始了自己的测试工作，首先学习产品和房地产领域的业务知识，了解实际业务场景，再熟悉产品的流程，各个功能如何实现，以及各个模块之间的接口，因为项目过程管理涉及收付款，与财务会计平台接口较多，为了学习丰富自己的财务知识，在边测试产品的同时，我还考取了会计证，对自己的财务知识有了一点补充。

测试工作最重要的是要细心，耐心，专心，更要有责任心。在这里，我培养了自己吃苦耐劳和自主学习的能力，尝试多去交流沟通和表达。在工作中，我学会了如何处理测试与开发，需求以及环境组等各角色人员之间的关系，同时注重与他们的沟通，加强团队合作协助，及时解决问题。

由于ERP软件涉及的公共测试项目和测试方法较多，工作中遇到不懂不会的我虚心向同事请教或自己研究，争取弄明白并解决问题。如果别人遇到困难，自己也会热心帮助。部门经常安排一些培训，对我的工作有很大的帮助，有时还会安排我进行返讲，这也是对我工作的一个考核。在测试工作中，对于bug的反馈都有规范的方式和追踪系统，随着不断的摸索，我逐渐清晰了自己的测试思路，工作也有了条理，按时完成部门分配给自己的任务，不知不觉中提高了自己的能力，同时对工作也更加有信心和热情。

工作中，我养成了勤总结的习惯，周期性进行工作汇报，完成周总结，月度总结等。业余时间的锻炼让我有了强壮的体魄，能够适应加班及高压的工作。

20xx.01—至今 用友产品测试部

由于房地产产品发版，20xx年元旦过后，我被安排到了产品测试部，负责测试生产制造NCV6.1产品，V6是的体系与V5有很大的不同，由于我是第一次接触制造产品，因此对自己也提出了严格要求，使自己尽快掌握产品。经过努力，我也快速掌握了产品并顺利通过了需求返讲考核，并得到了部门的认可。

产品测试部测试的是水平产品，测试氛围很浓，很多之前没接触过的在这里都会接触到，很多以前没有用过的工具在这里都可能用到，但我们测试工作的目标只有一个，推动问题的解决，提高产品的质量，使产品成功发版。工作中发现问题我会想尽一切办法通过各种途径

来解决。在这里，我参与了制造产品最初的单元提交，集成用例评审，到最后的发版验收。 由于水平产品公共测试项目较多，比如审批流，业务流，国际化，客户端……等等，有时要面对大量的用例验证，有时为了找出bug不停的反复操作，有时要及时维护产品的状态报告，有时要尽快完成百人测试方案，有时要抓紧做产品的PPT演示或录制课件，有时为了解决客户现场或用户遗留问题而加班到很晚，在忙忙碌碌中我度过了每个工作日，在这种快节奏，高效率的环境中我不断充实自己，成长自己。

除了对产品大量的业务流程和功能测试，还要对产品进行性能测试，在测试过程中我学会了应用一些相关的自动化测试工具，掌握了一些测试软件，比如通过NMC，NC_Runner等，熟悉了一些测试方案。并学会了搭建并简单维护环境，如升级代码或打补丁，能够通过DbVisualizer连接数据库，从sql或oracle数据库后台查询一些基本的表。有时发现问题需要通过录制前台和后台日志，以便于分析问题。

由于我对接触新事物有着浓厚的兴趣，同时也为了增加自己的知识，我花了很多时间来学习并测试其他产品，比如财务，供应链，成本管理，质量管理等等。

第二篇：软件测试总结

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

测试的基本原则

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：

1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。 2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。

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

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

5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

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

7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.

测试的基本原则<二>

1．应当把“尽早和不断的测试”作为开发者的座右铭

2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

什么是测试用例

1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目 的是确定应用程序的某个特性是否正常的工作。一个测试用例应当有完整的信息， 如：测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步 骤和期望结果。

2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。这主要是由于是 需要完整的考虑应用的整个操作。正因为这样，需要在开发的早期准备测试用例。