测试平台对持续集成的支持(之二)——测试代码的编写(一)

       测试代码的编写事实上包括从需求审阅开始，经历测试分析->用例编写->测试代码编辑。这一节只探讨前三个环节，测试代码编辑后续再探讨。无论软件开发模式发生何种变化，需求审阅，测试分析和用例编写都是必须的(当然现在有的开发模式把测试分析和用例编写合二为一，将用例尽量简化，但基本的思维过程仍然离不开上述环节)。如何将上述三个环节快速进行以适应持续集成是一个难点，因为这三个环节主要是测试人员思维活动的环节，现阶段基本不可能被自动化的机制所取代。因此这个环节的测试平台的建设主要立足于如何尽可能的从各个方面帮助测试人员理清思路，快速消化PD写的需求分析，快速理清编写测试分析和用例的思路上面。


       目前平台的建设着重从以下几个方面考虑：


       1. 和网站需求全景图(后面称为产品文档，即有机囊括网站所有需求的一份大而全的需求说明书)打通，以功能点为单位形成用例集与产品文档的需求点对应。          将功能点为单位形成用例集，有助于编写测试分析。目前云效平台正是遵循这个思路来组织用例的管理。但是仅此其实是不够的，如果能和需求环节的产品文档打通，将以功能点为单位的用例集与产品文档中的需求点一一对应，那么测试分析和用例编写的效率将进一步大幅提高。因为每当一个项目新的需求文档起草并有机融合进产品文档的各个部分，测试平台将能够帮助测试人员自动从产品文档的改动部分(即新的需求)迅速的找到对应的需要修改的用例集。如此将极大地提高测试人员理清测试分析和测试用例的思路的能力，减少测试分析遗漏，长此以往测试人员将具备全面理解整个网站产品的能力。


       但是这里的难点有两个：
       其一在于对PD的高要求。PD在起草一个项目的需求的时候，需要清楚的知道要修改整个产品文档的哪些部分，才能够既完整地体现一个项目的需求又能将该项目需求有机融入整个产品文档。为此有些传统软件行业的PD中有专门的PD负责将其他PD的项目需求文档定期分拆融入整个产品文档。互联网行业的需求快速变化，能否维护一份完整的产品文档是一个较高的挑战。


       其二在于需求管理系统能否做到对整个网站维护起一份产品需求文档，并将该产品文档的各个需求点有组织的管理。传统软件行业已有这样的先例，但在互联网行业，笔者尚未见到。


       2. 测试策略：测试策略注入是帮助测试人员理清测试分析思路，防止测试遗漏的另一个重要的功能。随着测试平台的完善，测试策略终将发挥其应用的作用。


       3. 用例编写的自动化：测试平台的自动化到一定程度后，用例与测试代码可以做到自动双向转换。用例可以转换成测试代码，或者测试代码可以转换成用例。这样用例或测试代码只要实现一者便能自动转换成另一者。业内已有一些工具或框架在向这个方向努力。


云效平台官网地址：http://yunxiao.aliyun.com/