软件测试经验与教训之管理测试项目-526互联

测试工程师需要站在用户的角度考虑问题，因此有条件的话多与用户打听一下，对系统的看法

测试工作是整个项目的一个子项目，要申请资源并提供服务，因此有些项目经理或者产品经理会滥用测试的人力，甩锅给测试。

作为一个测试经理，自己有一个很重要的部分就是让自己或者自己的下属，不被项目经理或产品或其他人员滥用

在整个项目的过程中，要时刻对整个计划的大小细化或者更正。项目是一组任务并且是多人合作的，随着时间的推移，项目团队会发现有些任务比预期的要困难，或要花费更长的时间

或关键任务调离，或项目要求必须提前完成。

总会有很晚的变更，因为有些用户以前没有使用这种产品，或者他们对自己想要的东西有很好的想法，也不知道如何确切的描述自己的需求，主要是因为

1.他们不知道自己的所有需求

2.当他们试用过类似的产品后，会要求更改需求

3.不同的项目相关人员具有不同的需求，有时候这些需求常常是自相矛盾的，没有一份文档可以说清所有这些矛盾和潜在的矛盾需求，并进行综合考虑

项目涉及功能，可靠性，时间和资金之间的折中
功能：选择合适的功能，越完善的功能需要花费的时间越多，成本越高
可靠性：使产品能够正常运行，但不能花费无限时间和资金保证
时间：尽可能迅速的将产品投入使用
成本：以最低合理成本构建产品，成本包括资金和机会成本，当把关键资源（特别是技术熟练人员和独特设备的时候）其他团队就不能使用该资源了
时间和可靠性是对立的，当因为问题太多时，要么交付错误很多的产品，要么延迟交付。

测试人员可以在项目初期就介入，测试人员可以做的事情如下
1.可以评审需求文档的可理解性，可测试性和模糊性
2.需求评审后，马上进行测试用例评审，看是否有遗漏的地方，开发会考虑测试的用例评审进行设计代码
3.拟定资源配置，包括人力和硬件资源或技术资源

不同的产品有不同的测试要求一般分为合同驱动的产品和寻求市场的产品还有内部使用的系统
1.合同驱动的产品，主要责任就是根据合同完成自己的义务，合同之外的就不管不问了。如果客户进行变更则由项目经理来评估成本
2.寻求市场的产品，要考虑所发布的产品能否销售给目标市场，如果竞争对手的产品更有竞争力，那么严格遵循产品文档就没有意义了。需要重新搜集客户，竞争对手和媒体期望的产品而要求修改设计
3.内部使用的系统基本上满足业务方的需求，同时还要控制使用的成本，毕竟内部使用的系统一般对UI要求比较低
测试负责人要使整个团队了解测试小组的需要，以及使测试小组更有效，高效地发挥作用所需的信息和支持。
在正式测试之前，测试需要做的准备了解一下开发自测过了吗？测试环境怎么样？测试资源是否齐全？
在下面这些情况下，测试应该拒绝测试改版本：
1.主要功能缺失
2.主流程不通
3.以前正常的关键功能，现在不能正常使用了
4.收到一个版本后，后续版本需求和现在的版本需求有很大的冲突
正式测试之前要进行冒烟测试：冒烟测试主要检查版本的基本功能，主流程是否顺畅

有时一个地方的bug太多，并且反复修改也没有改好，那么就停止测试，让开发仔细思考问题所在并且重新设计代码。

要根据实际的开发来调整自己的测试过程，有些项目就是不能提供完整的规格说明书或者需求老是变更。只能根据实际的情况来调整，而不能一味的拒绝。

项目文档是有用的，但是肯定是不足的，对于测试来说很多东西他肯定是没有写的例如边际问题等等。

测试除了产品文档外，还可以借鉴以下产品进行测试