软件测试从零开始

目睹过很多测试新手的困惑：因为初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。此前给测试新手写过两篇文章，《测试职业规划》、《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 与开发人员为邻 

     尽可能跟开发搞好关系，尽可能座次靠近开发。

 

（未完待续......）