软件测试经验与教训之管理测试项目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 用户手册
2. 市场产品开发文献
3. 市场开发人员向管理层推销产品概念的演讲
4. 类似的产品
5. 已经使用的用户界面标准和风格指南

18.如果后期变更是不可避免的，那么什么样的测试计划适用于后期变更

1. 不要编写维护成本很高的大量测试文档
2. 不要在测试之前开发大的测试包
3. 不要把手动或制度化测试捆绑特定的用户界面，除非是想要专门测试该用户界面
4. 通过最大化可维护性和跨平台来设计自动化测试
5. 构建一组通用用例，可以反复的使用。自动化脚本和测试用例都行
6. 构建一组很强的冒烟测试，以快速检测出被测软件中的基本失效

19.判断测试是否足够的好有多种因素

1. 测试知道发现的重要问题的种类，如果存在这种问题的话
2. 测试知道产品的不同部件如何表现出来严重问题
3. 测试对产品做了与这些风险相应的检查
4. 测试策略具有合理的多样化，以避免视野过窄
5. 测试使用了所有可能的资源进行测试
6. 测试满足客户期望的所有测试过程标准
7. 测试尽自己可能，清晰的表示测试策略，测试结果和质量评估

20.熟练的做到上面这些可是交付之后仍然存在问题可能是

• 了解的风险动态不够深入
• 在测试中出现错误
• 测试的风险评估是正确的，但是管理层决定冒险，并造成损失

21.不同的测试工程师拥有不同的擅长领域，有些人擅长测试数据的质量，有些人擅长逻辑复杂的业务流程，有些人更加的细心。如果测试工程师完成某项任务特别慢，并且不能很好的完成任务，说明他不适合这个工作，不要让测试员承担不适合的工作。

22.不要让测试工程师自始至终对某个项目的同一组功能进行测试，

1. 这会使测试员感到厌烦而且每个人都有测试盲点。
2. 测试员太专的话不如一个多面手测试
3. 如果这个人离开的话，会给测试小组留下很大的知识漏洞
4. 两个不同的测试关注点不一样，可以从多方面的进行测试

23.一个测试过程快到结尾的项目，如何快速找出新的问题

1. 对有怀疑的部分进行初步探索式测试，形成更细致地跟踪想法
2. 探索被认为是风险很低的部分
3. 定位看起来很容易引起不可重视问题的关键部分
4. 如果项目要延期，那么需要找出关键错误用来说服项目经理。

24.测试工程师可以把每天的任务分成阶段性测试，例如60分钟到90分钟为一个阶段。确定这一段时间的需要测试的任务，这样可以保证测试工程师的注意力更加的集中，

25.作为一个测试沟通能力非常的重要，测试和程序员以及产品的地位是相等的，他们不是你的下级，说服他们给测试提供资源，等等

26.测试报告应该注意以下几点

1. 使用中立，客观的语气
2. 不针对具体某个人
3. 所有的项目都采用一致的格式
4. 按照进度计划提交报告

27.通过bug数量来预估项目的进度

1. 项目刚开始的时候，bug数量会非常的多，到收尾阶段基本上没有什么bug了，说明产品的质量已经取决于稳定了
2. 如果到了项目的最后阶段仍然有这大量的bug，并且这些bug不易修改而且还会产生大量新的bug，则建议推迟产品的交付时间

28.项目日报可以用于项目进展和测试进展度量

1. 产品已经完成了多少测试
2. 计划进行的测试已经完成了多少
3. 发现了多少问题，有多少问题没有解决
4. 那些问题阻碍到了继续测试，因为未解决的缺陷，缺乏设备或某些问题还没有做出决策导致测试进度受阻
5. 我们对测试质量有多大的把握

29.测试的周报如何编写

1. 第一页列出关键问题

　　所需要做出的决策（是否需要增加测试人员，是否需要设备，那些问题急需解决）

　　所需的程序错误修改（影响测试的进度的bug）

　　预期交付的工作制品（需要交付的文档设备功能和工具等）

　　意外问题（某个员工跳槽引起的部分测试效率降低，员工需要培训）

1. 第二页描述测试小组完成计划任务进展的情况
2. 提供错误报告统计数字
3. 最后一页列出本周被延迟的项目已经程序错误