产品测试方法及基本常识.doc

软件测试误区： 产品开发完成后进行测试； 产品质量问题是测试人员的错误，产品发布后如果发现问题，是软件测试人员的错误； 测试技术要求不高，比编程容易，随便找一个人就可以了；（有编程经验对测试BUG的敏感性；需要编写自动化此时脚本的能力；除了技术还有管理，谁都可以做，但结果不一样。） 测试跟着开发动，有时间就多测，没时间就少测；（必须要有计划有组织。） 测试是测试人员的事，与开发人员无关；（开发人员需要自测，还需要沟通协作） 产品测试是没有前途的工作，只有程序员才是软件高手； 测试是产品开发的后期活动，产品测试=程序测试；（产品缺陷具有“生育能力”；需求测试和设计测试也是产品测试的一种；产品测试应该涵盖整个产品生命周期；同时，产品测试本身也应被测试。） 测试要执行所有可能的输入；（在实际测试中，穷举测试工作量太大，实践上行不通；一般采用等价类和边界值分析等措施来进行实际的产品测试；寻找最小最重要的用例集合成我们精简测试复杂性的一条必经之道。） 好的测试一定要使用很多的测试工具；（工具所能发挥的作用依赖于使用工具的人。因此，对工具的过分依赖将降低人的能动性，并最终使测试本身收到损害。适当的使用测试工具能够减轻测试人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。） 软件测试从零开始 　　 如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。 　　5、 走读相关产品的历史测试用例 　　 如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。 　　 通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。 　　 总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。 　7、 识别测试需求 　　 识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法： 　　8、 主动获取需求 　　 开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。 　　 当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析： 　　 软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。