从计划开始
正如我前面所说，最早介入项目的人，应该是能力和经验并重的人；同样在测试阶段，也是如此。
大多数测试人，包括我自己，测试生涯是从手工测试开始的，完成上级分配给的测试用例基本就是自己的全部工作内容。老实说，这更应该是个智能机器人来干的活。虽然我现在已经从事需求分析的工作，但还是有些诚惶诚恐，每次一个模块完成了测试，提交给客户后，回顾前一时期的工作，发现有些问题，在需求分析阶段就应该给予定性，并进行有效沟通，从而可以避免后期测试时产生的一些冗余流程和开发人员与测试人员之间对产品标准认识的误解。
需求分析是个互动的环节。有时因客户临时的决定，需求会发生变动，让测试人员不得不调整测试策略或用例；更多时候虽然是需求一致，但因开发人员实现时采取不同的方式，也会影响到测试人员。但这并不代表测试部门会被动的接受，你可以，也应当提出你认为合理的方式。比如：开发人员实现一些表单验证，偏好.net自带的一些验证控件，但从测试人员的角度来看，一些场合下最好编写自定义控件来实现，满足易用性的要求。至于前者，大多少时候我们只能将想法告知项目经理或与客户打叫道的负责人，将测试人员的意见纳入到考虑范畴之内。
以上有些内容其实已经渗入到了生成测试用例阶段。做需求分析，往往第一步是生成一份可执行的测试计划文档。虽然网上不乏这样的模板，但这并不是机械的填充与名词替换。重要的不是结果，而是过程。无论是制定测试范畴、进度，归纳产品特性，准备资源配置，预计风险，这些东西总结出来不是摆设，而是真正能够对未来设计测试用例，功能测试，性能测试起到引领作用。
当然，计划只是计划，俗话说计划赶不上变化，很多时候，特别是周期短的项目，微调也是时而发生的，测试团队不可能脱离其他部门，所以最大限度的评估好自己的工作的同时，也要做好因其他原因而改变测试安排的准备，比如，开发团队因某个技术点实现困难，需要延期；客户突然决定产品需要支持Opera浏览器。虽然允许测试计划演变，但演变的因素里不应包含前期因自身工作的疏忽、未考虑周全而频繁变动计划。
最大化的清晰需要完成的测试工作，最小化测试工作的不安因素，我浅薄的认为是测试计划主要完成的两件事。
本文出自lghss23的51Testing软件测试博客：http://www.51testing.com/?227608
版权声明：原创作品，转载请保留链接，标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关阅读：
