软件功能测试的步骤
近有和一个初学测试的朋友聊天，他说关于测试方面的书看来不少，理论和概念也背了不少，但是实际测试时还是不知道怎么怎么下手，不知具体该如何做？ 其实关于怎么入手做测试，没有什么具体的规范，以下是我的个人习惯，供大家讨论一下。
面对一个新的项目，应该从项目的编写需求分析时参与进去，了解项目的背景和用户的需求，然后根据项目的开发进度，编写测试计划；测试计划要包含以下内容：测试用例编写时间，按照用例执行测试的时间和执行回归测试的时间，这个时间根据要项目进度来设定，以保证计划的正常执行。
编写完测试计划后，不要急着编写测试用例，要先确定需求分析是不是已经编写完成，并经过了评审。如果确定需求分析已经评审完成，那要尽可能多的了解需求分析。根据需求分析编写测试要点，所谓测试要点，是测试用例的框架，把需求分析中的用户要求和用户业务记录下来，然后区分哪些是主要也需求，哪些是次要需求。这要便于测试的全面和测试重点的突出。
编写完测试要点后，再开始编写测试用例。所谓的测试用例，是指测试某项功能时，所作的输入数据或动作，并列出期望的输入数据或动作。那么编写测试用例，是用实际的操作来证明前面所写的测试要点中的功能点和业务实现。证明测试要点时要从正反两个方面进行，不但要证明正常情况下软件系统的反应，还要证明在非正常情况下，软件系统也要能作出正确的处理。对于主要的需求要尽可能全面测的测试，要考虑到各种可能性，而对于非主要需求，测试用例可以适当少一些，但是低也要有正反两方面的考虑。
测试用例编写完成后可以开始做测试了，做测试时要按照测试用例进行，要确保每条用例至少执行了一次，每执行一条用例要对比一下软件系统的实际输出和期望输出是否一致，如果不一致，要记录到测试报告中。实际测试时不要漏掉任何的不一致情况，因为这些不一致是软件系统的问题所在。对于软件输出不一致的用例，好多执行一次，尽量定位软件问题所在，以便于开发人员的修改。
测试完成后，要及时把测试报告反馈给开发人员，以便于开发人员的修改。当开发人员修改完成后，进入 到软件测试的后阶段回归测试（我认为这是麻烦的，呵呵），所谓回归测试，是验证上次测试时所发现的问题是不是已经被修改，有没有新的问题出现。之所以认为它麻烦，那是因为软件修改完成后可能会导致新的问题出现，如果把测试用例再重新执行一遍的话，要花费很多的时间。如果要使用测试工具进行自动化测试，要花费大量的时间去维护测试脚本，无论怎么做，都很麻烦。我的一般做法是把发现问题的测试用例和它有关联的测试用例重新执行一遍，如果没问题，算测试完成，否则，再次提交测试报告，直到测试完成……更多>>
沪ICP备07036474 2003-2012 上海泽众软件科技有限公司版权所有