做好测试计划

一、测试的重要性：

        如果没有测试计划，会带来以下问题：
        1、难以确切地知道具体的测试范围，以及应该采取的具体测试策略。
        2、难以预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师分工不明确，导致某些测试工作重复执行而有些测试被遗漏。
        3、测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间，就更难准确预估了。
        3、项目对潜在风险的抵抗能力很弱，难以应对对需求的变更以及其他突发事件。

        因此，一份好的测试计划要包括测试范围、测试策略、测试资源、测试进度和测试风险预估，并且每一方面都要给出应对可能出现问题的解决办法。

二、测试范围：

        测试范围描述的是被测对象以及主要的测试内容。如，用户登录模块，功能测试既需要测试浏览器端又需要测试移动端，同时还考虑与登录的安全性和并发性能相关的非功能性需求的测试等。测试范围的确定通常在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，这将有助于在早期阶段就发现潜在的测试疏漏。同时，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，因此必须有所取舍，进行针对性的测试。于是，在测试范围中需要明确“测试什么”和“不测试什么”。

三、测试策略：

        测试策略简单来讲就是需要明确“先测试什么后测试什么”和“如何来测试”这两个问题。事有轻重缓急，测试策略要求我们明确测试的重点，以及各项测试的先后顺序。
        比如，对于用户登录模块来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，对业务的影响孰轻孰重一目了然，因此，按照优先级你应该先测试“用户正常登录”，再测试“用户重置密码”。
        测试策略还需要说明，采用什么样的测试类型和测试方法。不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。
        1、功能测试
        对于功能测试，应该根据测试需求分析的思维导图来设计测试用例。因为主线业务的功能
测试经常需要执行回归测试，所以需要考虑实施自动化测试，并且根据项目技术栈和测试团队
成员的习惯与能力来选择合适的自动化测试框架。这里需要注意的是，通常应该先实现主干业务流程的测试自动化。实际操作中，通常需要先列出主要的功能测试点，决定哪些测试点适合采用自动化测试。并且决定使用什么样的框架和技术。对于需要手工测试的测试点，要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。另外，还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试的接口。
        2、兼容性测试
        对于兼容性测试来说，Web测试需要确定覆盖的浏览器类型和版本，移动设备测试需要
确定覆盖的设备类型和具体iOS/Android的版本等；对于已有的产品，可以通过大数据技术分析产品的历史数据，得出前30%的移动设备以及iOS/Android的版本列表，兼容性测试只需覆盖这部分即可。
        3、性能测试
        性能测试需要在明确了性能需求(并发用户数、响应时间、事务吞吐量等)的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。比如，是直接在 API级别发起压力测试,还是必须模拟终端用户行为进行基于协议的压力测试?是基于模块进行压力测试，还是发起全链路压测?
        如果性能是基于数据敏感的场景，还需要确定场景的数据量与分布，并决定产生数据的技术方案，比如:是通过API并发调用来产生测试数据，还是直接在数据库上做批量插入和更新操作，或者两种方式的结合?最后，无论采用哪种方式，都需要明确待开发的单用户脚本的数量，以便后续能够顺利确定压测场景。
        性能测试的实施是一个比较复杂的问题。首先，需要根据想要解决的问题，确定性能测试的类型。然后，根据具体的性能测试类型开展测试。
 

四、测试资源：

        测试资源通常包括测试人员和测试环境，需要明确“谁来测试” 和 “在哪里测试” 这两个问题。

五、测试进度：

        测试进度主要描述各类测试的开始时间、所需工作量、预计完成时间，并以此为依据来推算最终产品的上线和发布时间是否满足。如：版本接受测试的工作量、冒烟测试的工作量、自动化脚本开发的工作量、缺陷修复的验证工作量，回归测试的论述，每一轮回归测试的工作量等。

六、风险评估：

        计划赶不上变化，通常需求变更、开发延期、发现重大缺陷和人员变动是项目测试风险的主要原因。