测试新手不能错过的测试重点

作为一个测试新手，以下内容你不能不知道!!!

一、什么是测试用例？
     测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求.(通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。)
二、写测试用例有什么好处？
    1:理清思路，避免遗漏
        这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
    2:跟踪测试进展
        通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。
    3:历史参考
        在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
    4:重复性
        我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
三：测试用例的方法？

    这个内容我在之前的博文里面已经详细的介绍过了（需要了解可点击http://blog.csdn.net/sxl19960914/article/details/78850482，http://blog.csdn.net/sxl19960914/article/details/78879178）

四：我们在什么时候可以设计测试用例？

       当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们（国内大多小公司）项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。 我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根绝这些文档来设计测试用例。

五：测试用例的评审与更新？

     我们设计的测试用例设计完成之后，是否完整？是否符合系统？符合客户要求？对用例做一个评审是必不可少。关于评审的方式，不同的公司有不同的流程。我们编写的测试用例也不是经过评审之后就不变了，随着需求的变更、功能的改进，测试用例当然也需要更新和变动。

六：什么情况下不适合写测试用例

  1： 文件时间
   如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。这个时候就没必要编写测试用例了。
  2： 需求变动大且频繁
   需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。

七：测试用例的格式与要素

       一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。当然还可加入一些它选项，如：优先级、测试阶段...

    下面是一个测试用例的例子：

作为测试人员，凡是不符合需求文档的都需要当问题点提出。