软件测试从零开始

Posted 软件测试杂谈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件测试从零开始相关的知识,希望对你有一定的参考价值。

目睹过很多测试新手的困惑:因为初涉软件测试行业,没有接受系统的培训,对软件测试一无所知,既不知道该测试什么,也不知道如何开始测试。此前给测试新手写过两篇文章,《测试职业规划》、《10年软件测试工作总结》,限于篇幅,泛泛而谈,对测试新手快速开展具体工作的帮助不大。今天本文分别讲一讲从测试前的准备工作、测试需求了解、测试用例设计、测试用例执行到测试结果分析的五个阶段中,测试新手需要注意的几个要点。

1、测试准备工作

     我们测试人员的工作,就是为质量保证提供信息。作为一名软件测试新手,如何才能发现所有的 BUG ?如何开始测试工作?即便面对的是一个很小的软件项目,测试需要考虑的问题也是方方面面的,包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢?

1.1 向有经验的测试人员学习

     这几年在带新人的过程中,整理了一些软件测试技术、测试流程、测试工具和质量管理相关文档资料,有兴趣的朋友可以评论里说一下。
     跟有经验的人学习大家都知道,不过需要注意的是,应时刻保持质疑和寻根究底的态度去学习。

1.2 阅读软件测试相关书籍

     有人整理过一篇介绍测试书籍的文章:http://www.cnblogs.com/scios/articles/4977953.html。另外,多看看论坛和测试方面的公众号,如光荣之路、51testing。

1.3 查看历史bug

     现在多数公司都有bug管理工具,里面的bug对我们了解项目是非常有价值的。这些bug是软件产品问题的集中体现。一般来说,我们需要关注这几个点:
  • bug描述:照着葫芦画瓢。
  • 开发对bug的解决方法:理解原理,积累经验。
  • 常见问题有哪几类,都是什么原因导致:总结并作bug预防
  • 哪些模块容易出问题:问题多的重点测
  • 哪些开发出的问题多:判断开发水平,水平低的重点测
  • 谁提的bug多/好:以后多跟他学习
 
1.4 走读历史用例

     走读别人的用例来提升自己的用例编写水平。走读测试用例也是有技巧的。走读用例时除了学习别人的语言描述技巧,更重要的是多问几个为什么,为什么他要写这条用例,为什么把这个模块自动化而不是另一个?
     测试用例编写有几个原则:准确性、简洁性、可重用性、适用性、可跟踪性、纯净性。当然这几个原则并不是在所有情况下都要遵守的,这取决于项目、执行人等多种情况。我计划于近期在我的qq群开一次测试用例的课程,欢迎有兴趣的来一起学习。

1.5 学习产品相关的业务知识

     软件测试人员不仅要掌握软件测试技术相关知识,对产品相关的业务知识也要学习。这很好理解,如果从事财务软件的测试工作,一定要学习财务知识;如果从事通讯产品测试工作,那么相关的通讯理论知识也是必须的;如果从事银行软件的测试,银行的业务流程也是不可或缺的知识点。

2、识别测试需求

     识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档,那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出,来设计测试用例。如果开发人员没有提供软件需求文档,那该如何是好?下面给出几个有效的方法:

2.1主动获取需求

     开发人员通常不会更好地考虑软件测试,如果没有开发流程的强制规定,他们通常是不愿意提供任何开发文档,即便有强制规定,需求文档也未必能够真正指导软件系统测试工作。因此,需要测试人员发挥主观能动性,与相关的软件开发项目经理和软件开发人员保持沟通,了解软件实现的主要功能是什么,并记录得收集到的信息。一般来说,开发人员即便没有提供相关需求文档,也会保存一些简单的过程文档,主动向开发人员索要这些文档,可以作为测试的参考。此外,可以与公司的技术支持(业务/客服)人员交流,技术支持(业务/客服)人员是最贴近用户的人,因此,通过交流可以获取第一手的用户使用感受,在测试的过程中会更加贴近用户。
     当拿到相关的资料后,从哪些方面分析需求?如何与开发人员交流需求?其实,只要把握需求分析的几个关键的点就可以解决问题:输入、处理过程、输出、性能要求、运行环境,下面针对每一个项目逐一分析:
     输入: 与该需求相关的一切可能输入,可以从这几方面考虑,输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中,这部分内容作为测试用例输入的依据。
     处理过程: 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可,在测试过程中发现 BUG 时候,如果对处理过程了解的深入,对定位问题根源有很大的帮助。
     输出: 描述每个需求的输出结果,包括输出的位置,输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中,这部分内容作为测试用例的预期输出。
     性能要求: 与该需求相关的性能要求,比如 “ 插入 ATM 取款卡后, 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制,就是对需求的基本性能要求。
     运行环境: 软件的运行所需的环境,包括硬件平台的要求、操作系统的要求、数据库的要求,以及其它相关支撑软件的要求。

2.2 确认需求的优先级

     确认需求的优先级是很必要的,在产品进度比较紧的情况下,需要根据优先级来安排迭代频次。
     有可能的话,推动公司规范的开发流程,让开发人员在编写软件需求文档的时即对需求排优先级。但是开发未能提供,那么需求的优先级只能由测试人员完成了。

2.3 加入开发小组的(邮件)群组

     测试人员需要通晓被测试产品,但是,产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程,测试人员会对产品的变更了如指掌。如果没有变更控制,那就要采用其他的土方法了,不如申请加入开发的聊天群,或者邮件群组。当开发人员讨论问题、通知召开技术会议的时候,测试人员可以及时知晓,如果必要,可以参加开发人员的技术会议。
     即便公司里面有了软件变更控制流程,加入到开发邮件群组也是一个很好的习惯。

2.4 与开发人员为邻 

     尽可能跟开发搞好关系,尽可能座次靠近开发。
 
(未完待续......)

以上是关于软件测试从零开始的主要内容,如果未能解决你的问题,请参考以下文章

软件测试从零开始

从零开始学习接口测试

Android测试:从零开始1——简介

从零开始学习敏捷开发

Android测试:从零开始2——local单元测试

从零开始学习CANoe(十七)—— Diagnostics