测试入门：
1.测试准备工作
在测试工作开始之前，首先要明确测试工作的目的是什么，如何开始测试工作？测试需要考虑的问题是方方面面的，包括硬件环境，软件环境，操作系统，产品的软件配置环境，产品相关的业务流程，用户的并发容量，使用时长等等。
2.向有经验的测试人员学习
如果你进入的是一家运作规范的软件公司，有独立的软件测试部门，规范的软件测试流程，软件测试技术有一定的积累，那么你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录，软件测试流程相关文档目录，产品业务相关的文档目录，在他的指导下逐渐熟悉软件测试的相关工作。
如果你进入的是一家软件测试一片空白的软件企业，那么你可以到国内的软件测试论坛和相关网站上寻找软件测试资源。
3.阅读软件测试的相关书籍
现在，中文版的软件测试书籍越来越多，从国外引进的软件测试书籍有很多经典之作，但是翻译成中文后，翻译质量对阅读效果有很大的影响，建议阅读英文版的原著，这同时也是提高英语水平的过程。
4.走读缺陷跟踪库中的问题报告单
一般软件缺陷跟踪工具有clearquest,testdirecter（商用工具），buggzilla，mantis（开源工具）等等，如果你所在的公司已经有使用以上工具建立了缺陷跟踪库，那就恭喜你，里面的缺陷报告单是极其有学习价值的，它们是软件产品问题的集中体现。学习里面关于缺陷产生的环境，基本描述，解决方法，是迅速提高软件测试经验的好方法。
5.走读相关产品的历史测试用例
如果你所在的公司有测试用例管理系统，那么走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。
测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例。根据用例项科研设计出若干个测试用例，它们是一对多的关系。
走读它们，可以掌握应该从哪些功能点来着手未来的测试工作，了解如何根据被测试的功能点开展软件测试用例的设计工作，从而提高自身用例设计水平。
6.学习产品相关的业务知识
软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。如果对业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，这样子，软件测试效果会大打折扣。
7.重视测试需求
识别测试需求是软件测试的第一步，我们要主动获取需求。开发人员通常是不愿意提供任何开发相关的文档的，因此测试人员要发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能，并记录手机到的信息。
得到之后，我们可以从以下几个方面来分析需求：
（1）软件输入：与该需求相关的一切可能输入，比如，输入来源，输入参数的数量，度量单位，时间要求，精度和有效范围。
（2）处理过程：描述对输入数据所执行的所有操作和如何获取输出的过程。测试人员了解处理过程即可。在测试过程中发现bug时，如果对处理过程有了解的深入，对定位问题根源有很大的帮助，同时也可以进一步测试软件潜在的问题。
（3）软件输出：描述每个需求的输出结果，包括输出位置，输出参数的数量，度量单位，时序，精确度，有效输出范围，错误消息。
（4）性能要求：比如连续运行48小时，频繁点击软件而不崩溃，响应时间等等。
（5）运行环境：软件运行所需的环境，包括硬件平台，操作系统，数据库等的要求，以及其他相关支撑软件的要求。
分析完需求之后，我们需要确定需求的优先级，如果产品进度比较紧，测试人员可以考虑优先测试优先级高的需求项，放弃优先级低的需求项。
8.测试用例设计
需求收集完毕，就要开始测试设计。测试用例是一个文档，描述输入，动作和一个期望的结果，目的是确定应用程序的某个特性是否正常的工作。
用例的基本要素包括：用例名称，用例编号，时间，测试类型，优先级，测试方法，测试描述，测试输入，操作步骤，预期结果，实际结果，用例结论。
可以利用已有的软件checklist来拟作一份粗糙的用例文档，然后再设计的过程中不断地完善它。
测试用例设计完成之后，最好能够增加评审过程，由产品相关测试人员和开发人员评审，提交评审意见，再根据意见来完善测试用例。利用评审可以发现用例的很多问题，比如，设计错误，设计遗漏，冗余，不充分等等。当然，一般软件开发的节奏是非常紧凑的，评审是很难开展的。
9.测试用例的执行
测试环境搭建之后，我们就要开始执行测试用例了。在执行的过程中我们要注意以下几个问题：
（1）全方位的观察执行结果：测试用例执行过程中，实际输出结果跟预期一致时，也不代表测试用例执行成功。我们还要查看操作日志，系统运行日志，系统资源使用情况等等。
（2）加强测试过程记录：执行步骤跟用例描述有差异，要记录下来，以后更新用例。如果软件提供了日志文件，执行完测试用例后一定要记录相关的日志文件，以后有问题，可以通过测试记录定位问题。
（3）及时确认发现的问题：如果发现了可疑问题，又无法定位是否是软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。
（4）与开发人员良好的沟通：如果你提交问题报告单，可能会被开发人员无情驳回，拒绝修改，这个时候你只能对开发人员晓之以理，说服他。测试人员和开发人员之间应该制定软件缺陷的标准原则。
（5）及时更新测试用例：在测试过程中，往往会发现自己遗漏了一些测试用例，或者某些用例根本无法执行，或者若干个冗余的用例完全可以被某一个用例替代，那么我们要及时更新用例。
（6）提交一份优秀的问题报告单：软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。
（7）测试结果分析：测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。