测试人员的时间分布

测试人员共同的焦虑，在于花了大量的时间去测试这个小场景，测试那个小场景，最后发现除了提交几个EC之外，没有对自己有一个体系的提升。
本文从管理的角度，去分析一下，测试人员的工作现状，产生这些现状的原因，以及如何去有效的做好测试。

• 现状
  按照一个release（30天）来计算：

类型	内容	时间
需求确认	和开发、业务人员开会讨论需求，确认理解一致	5天
测试用例设计	结合用户业务故事，从用户的角度去考虑	10天
测试脚本执行	利用工具，针对可自动化的用例进行集成，针对不可自动化的用例，保留步骤、参数和结果	15天

需求
- 更多的是继承以往经验。比如一些成熟的模块，再次测试时往往可以借助已有的测试脚本来覆盖即可。
- 新的功能依据行业的标准和规范、用户的实际需求。比如某些特定的运营商用户要求，考虑组播预加入时，网元上行的应答包太多了，希望有开关可以将其关闭，以减小干扰。查阅相应的技术标准和规范文件后，认为该新增的功能是合理的，并且是可以实现的。
- 考虑引进新的需求分析方法。比如实例化需求、MFQ。
用例
- 采用一些测试通用的方法。比如边界值、等价类、状态机、
- 依据以往测试经验，在之前用例的基础上，去增加新的用例。比如在测试vlan模块时，只需要对操作命令行进行简单的修改，就可以完全借用。
- 引进新的用例设计方法。比如GIVEN - WHEN - THEN三段式的设计方法，既保证了每个用例的单一性，也保证了对需求的覆盖率。
脚本
- 采用工具，完成脚本编写和调试。例如，采用底层库为python，实现层用RobotFramework做脚本执行，展示层用Jenkins做任务的调度和测试结果的分析和发布。
- 针对可自动化的脚本，将其加入冒烟计划。定期执行这些脚本，并产生可以信赖的测试结果。如果脚本执行失败，那么肯定是网元出现了问题。
- 针对不可或难以自动化的脚本，不将其加入冒烟计划。测试人员此时需要做好操作步骤、配置参数和测试结果的记录。有两个目的：一是为将来再次作此测试时，提供直接的指导；二是保证了该测试结果是可靠的，可以拿出来作为依据和参考。