本文面向软件测试开发新手，从测试前期的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。

1、测试准备工作

测试初期，测试工程师首先应该搞清楚测试目的是什么。把问题抛给项目经理，他可能会说：“发现产品里面所有的bug”。那如何才能发现所有的bug？如何开展测试工作？即便是面对一个很小的项目，也需要考虑全面，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。

2、向有经验的测试人员学习

如果进入到一家运作规范的软件公司，有独立的测试部门，规范的测试流程，那么，恭喜你！可以向有经验的前辈进行请教，在前辈的指导下逐步熟悉软件测试的相关工作。当然，如果你进入到的是一家测试刚起步的企业，那么，也恭喜你！可以在这里开创一片属于自己的天地（当然前提是老板认可软件测试的重要性，重视产品质量）。

3、阅读相关书籍

现在测试相关书籍越来越多，可以到相关网站、购物平台查找相关书籍。目前，从国外引入的测试数据经典之作有很多，但是翻译成中文后可能对阅读效果有一定的影响。

4、软件缺陷库中的问题报告单

如果你所在的公司有缺陷跟踪库，无论采用商用工具，如ClearQuest、TestDirecter等工具，还是采用的Bugzilla、Mantis等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。

5、阅读相关产品历史测试用例

如果你所在的公司有测试用例管理系统，那么，阅读相关产品的软件测试用例是迅速提高测试用例水平的一大捷径。通过阅读测试用例项目，你可以掌握从哪些功能点着手开展工作；可以了解如何根据被测试的功能点开展测试用例设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和输出结果等等。总之，阅读优秀的测试用例，是提高自身用例设计水平很好的一个方法。

6、学习产品相关业务知识

测试人员不但需要掌握测试技术相关知识，对产品相关的业务知识也要熟悉。即便你是测试专家，但对产品业务一无所知，那么也只能测试出纯粹的软件缺陷，而对眼前出现的产品业务相关的缺陷，很可能也是视而不见，如此依赖，测试效果会大打折扣。

7、测试需求识别

识别需求是软件测试的第一步，如果开发人员能够提供完整的需求文档和接口文档，便可以根据需求文档中描述的各个功能项目的输入、处理过程和输出来设计测试用例。

如果开发人员没有提供需求文档，则可以通过：主动获取需求、确认需求的优先级、加入开发小组的邮件群组、与开发人员为邻等方法进行。

8、测试用例设计

测试需求收集完后进行测试用例设计。测试用例就是一个文档、描述输入、动作或时间和一个期望的结果，其目的是确定应用程序的某个特征是否正常运行。具体包括：重用同类型项目的测试用例、利用已有的软件Checklist、加强测试用例的评审、定义测试用例的执行顺序等。

9、搭建测试环境，执行测试用例

测试用例设计完毕后，接下来就是执行，而执行过程中的第一步就是搭建测试环境。一般来说，软件提交测试后，开发人员还需提交一份一份运行环境说明书，此外，还应该给出被测试软件的详细使用说明书。对于复杂的软件项目，如果没有安装指导说明书作为参考，在搭建环境的过程中可能会遇到各种问题。

10、测试执行过程中需注意的问题

测试环境搭建完成后，根据定义的测试用例执行顺序执行。在执行的过程中需注重以下几个问题：

（1）全方位的观察测试用例执行结果：通过查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。

（2）加强测试过程记录：如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据。

（3）及时确认发现的问题：测试过程中若发现了软件缺陷，那么需及时确认问题，然后再提交问题报告单。

（4）与开发人员进行良好的沟通：测试过程中，但你提交了问题报告单，可能会存在被开发人员驳回的情况。这个时候需做到有理有据，有说服力，良好的态度和开发人员进行沟通。

11、及时更新测试用例

在测试过程中乳沟发现了一些遗漏的测试用例，需及时进行补充。不要想着执行结束后统一进行更新，这样往往会遗漏更多本应该更新的测试用例。

12、提交一份优秀的问题报告单

软件测试提交的问题报告单和测试报告一样，都是测试人员工作的输出因此，提交一份优秀的问题报告单也是很重要的。根据被测试的产品，需要在“问题描述”中增加相应的描述内容，需要具体问题具体分析。

13、测试结果分析

软件测试执行结束后，测试活动还没有结束。因此，测试结果分析是必不可少的重要环节。测试结束后也应该分析自己发现的软件缺陷，对发现的缺陷进行分类，你会发现自己提交的问题只有固定的几个类别。之后再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现所有提交问题的类别存在差异。