一直做测试工作好几年，以往项目的测试用例少则十几页，多则几十页，费时费力的写出来，真遇到几个项目需要同时测试，而测试人员严重不足的情况下，测试用例就基本上成了仅仅是用来熟悉需求的前奏曲。尤其当真正几个项目同时推进时，测试用例的完成也将成为问题。

　　近期，团队引入“敏捷”思想，彻底解放了我关于测试用例的困扰。将常用功能的测试检查表checklist替代冗长繁琐的测试用例，既解放了生产力，又同时提高了生产效率。但是在编写checklist前一定要注意以下几点：

　　1、应该坚持有必要的项目需求文档，哪怕是写的不够详细也好，最少都要出一份简单的功能列表；

　　2、参与项目的所有人员（包括设计、前端、开发、测试、运维、市场/商务），均需要尽量提前参阅已存在的项目相关资料，比如市场调研书，可行性分析报告，产品需求文档，或一切对项目有用的文档。提前熟悉项目相关文档是非常有必要的，往往我们在执行的时候这一点大家都不会引起重视，导致评审时提不出意见，等到开发阶段才发现逻辑或流程有问题。

　　3、需求文档要进行评审，根据之前参阅项目相关资料，在评审期间，参与项目的所有人员（包括产品、设计、前端、开发、测试、运维、市场/商务等）均可根据自身观点提出疑问，或其它相关的功能点需求；评审必须做会议记录，并由产品人员对需求文档进行修改和更新发布。

　　在编写checklist时应注意：

　　1、测试人员需要对产品相关的所有业务逻辑有非常清晰的认识；在需求评审阶段提出所有的疑问，并与市场/商务人员保持良好的沟通，真正了解市场需求，最终目的是由我们开发的产品解决目前面临的市场问题。

　　2、根据需求文档、原型图等提炼出其中的功能检查点；

　　3、如果项目引入“敏捷思想”，进行迭代开发，则找到前期项目的一些需求文档，概要设计，详细设计等，提取出里面的功能检查点。

　　4、checklist文档完成之后，需要分发给每个和项目有关人员，如产品、设计、前端、测试、开发、运维、市场/商务等人员。对有纰漏或错误的地方予以修正并更新。

　　这次的必购改版，花了2天的时间，一共拟出了79个大的功能检查点，在测试阶段，严格按照此checklist表进行检查，也为后期的产品验收提供了标准和依据。