测试之美书摘.doc

第一部分 测试者之美
一、这对你有好处吗
1.1 “质量把关人”就是在软件发布前已将该软件看做是一件商品的负责人。大多数测试人员不能很好的权衡风险、必要性、市场需求和成本开销。评估和承担风险其实是项目管理者或公司管理层的任务。
1.2 测试人员不应该是拿着工资却告诉你一切正常，测试人员就是要告诉你他们所了解的一切事实，甚至有时候他们会直白的说你的小宝宝很丑，还给出一些列论据。
1.3 一个真正的测试人员会把这些已有的测试看做自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方。为了你的测试人员士气着想，按部就班的工作可以交给那些愿意每天按部就班的人，或把手工自动化，有想法的人可以做些新的事情，想发现和报告缺陷，想贡献其他人无法贡献的力量。
1.4 经验丰富的测试人员知道哪里容易发现缺陷，他们还从经验中学到在类似的情况下那种技术曾成功的帮助他们发现缺陷，学会在纸里行间发现暗藏的玄机、观察显而易见之外的食物、询问一针见血的问题，以及眼界的扩展，继续学习和掌握新的工具。
1.5 测试的意义是发现缺陷。测试人员的工作是寻找、发现、报告、而不是神一样去评判，应该随心所欲的提供他们的意见，对于产品是否达到发布标准的争执意见，需要上升到公司管理层，测试人员偏向于改掉缺陷。
1.6 不要试图预测业务的优先级，他们理解的业务优先级并不完整，并不是基于用户的个人体验做出。
1.7 测试人员的工作不将报告发出来的原因。1、觉得报告的某一种或某一类错误没有意义，因为反正都不会被解决的。2、他们相信从政治上和实际上来说，报告他们发现的一切东西是不聪明的，他们应该至报告那些公司在乎的东西。
1.8 如果你理解了测试人员专业化学习成长要遇到的问题，和他们对认可、尊重、成功的渴求，你就会投资于培训你的测试人员。通过培训、认可和平等的奖励制度对测试团队表现出重视，你就会得到一个肯为你上刀山的测试团队，他们还会为你推荐业界中一些优秀的人才队伍。
二、完美的测试让利益相关者满意
2.1 我们为谁而测试
A．测试利益相关者，不仅限于项目参与者，还包括所有与我们做的测试和最终成果的质量相关的人。执行、领导、管理测试工作的那些人。
B．测试主管和经理
规划、指导、衡量和管理测试工作及其结果
C．开发人员、主管和经理
执行系统的人，他们收到我们的测试结果，通常必须对我们指出需要改动和改进的发现有所回应。
D．项目经理
负责把项目带向令人满意的结局的人。他们必须在质量、日程、功能和预算这些具有不同优先级的东西之间达到一个适当的平衡。
E．“如果还没本事，就别急着犯事”，不遵守规则很可能会犯事，所以要明白你的义务，跟健康、管人或执法人发生冲突可不是什么美好的经历。
2.2 什么令人满意
A．要保证有效，测试人员必须与利益相关者群体合作，以确定其目标和期望。每个利益相关者对测试都有一套目标和期望并期望他们能有效、高效和优雅地得以实现。
B．有效意味着测试人员的工作侧重点是重要的领域和典型的工作流程，并找出其中存在的任何曲线。高效意味着测试覆盖关键的领域和典型的用户场景，在项目早期发现重要的缺陷。优雅意味着要基于功能领域和关键质量风险明确的报告的结果，而不是基于隐蔽的边边角角的情况。
C．不同的观点导致一定的冲突，测试团队和项目组其他人会有一些怨恨和不满，通常情况下，组织过不了多久就得解散或重组测试团队。
2.3什么美是外在美
A．我们发现了多大比例的缺陷？我们发现了较高比例的严重缺陷吗？与在正式产品中出故
障的成本相比，在测试中发现和解决一个缺陷的成本是多少？
B．发现成本：就算我们没有发现缺陷，也会有测试成本。如：进行质量风险分析，建立测试环境，并创建测试数据。
C．内部故障成本：发现缺陷而导致的测试开发成本。如：提交缺陷报告、解决缺陷、确认测试缺陷已解决、回归测试改动过的构建这些活动。
D．外部故障成本：因为无法提供100%的无缺陷的完美产品而产生的支持、测试、开发和其他成本。
2.4 什么是美是内在美
A．我们已经自动化了多大比例的回归测试？我们覆盖了多大比例有关回归的质量风险？我们还能加快多少自动回归测试？对于每个问题，制定一个指标。
结论
A．了解你的利益相关者
B．了解他们对测试的目标和期望
C．为利益相关者的目标期望建立指标和目标
D．为测试的目标期望建立指标和目标
三、创建开源的QA社区
3.1 不搞特殊，你的亲身去做志愿者的工作。
3.2 一套简单的机制可以让志愿者参与项目：动力、合作、及时回应和成功。
A．让有兴趣的志愿者参与的最好结果就是得到他系统的支持，要达到这个状态，志愿者必须保持动力，因此要明白它如何收其他因素影响是很重要的。
B．单个志愿者绝不如一个团队有效，你应该经历促进QA社区的所有成员精诚合作。
C．资深志愿者和协调员应该尽可能快的回应其他志愿者的问题和要求，每当一个志愿者停滞在一个死胡同手足无措时，需要有人做出回应并提供帮助，否则他会离开项目。
D．不要低估成功给志愿者带来的能量。告诉志愿者他们的行为为项目贡献了多大力量非常重要，这就又产生了动力，创造了一个良性循环。
3.3 成功的活动--测试日
A、一套完整的测试用例，配以完整的文档以及如何运行这些测试的指示。鼓励资深志愿者运行比较难的测试用例，新志愿者去运行那些文档写的较好的手工测试用例。
B、鼓励用户参与测试日，直接影响了该项目的质量，应用程序在多种不同的运行环境、操作系统和硬件配置。

四、协作是性能测试之美
4.1 100% ，互联网任何东西都无法保证百分百的概率
4.2 性能测试检查点
A．搜集系统性能指标基准，并验证系统使用模型中包括的每个功能任务，在1个用户的负荷下，在每一个包含该功能任务的性能测试构造中，都达到性能需求
B．搜集系统性能指标，并验证系统使用模型中包括的每个功能任务，在10个用户负荷下，在每一个包含该功能任务的性能测试构造中，都达到性能需求
C．搜集系统性能指标，并验证系统使用模型中包括的每个功能任务，在以下负荷程度的性能要求下，在每一个包含该功能任务的性能测试构造中，都达到性能需求
-- 用户负荷从100个增加到3000个，每行1个
D．收集系统性能指标，并验证系统使用模型，在开发组长，性能测试人员以及项目经理认为恰当的构造上，逾期9小时、负荷为1000个用户的压力测试的性能要求。
4.3 你不能性能测试所有的东西
A．代表网站上最可能的用户活动，关于用户第一次访问网站时最有可能做哪些事的讨论。UCML
4.4 这不是内存泄露
A．工具的问题 or 安装永久许可证密钥，临时许可证只允许3个同时连接
4.5 处理不了负荷，修改用户界面吧！
事实上只有两件事，大量用户同时做时我们无法处理，一个是“生成给个性化退休存储计划”，另一个是“生成个性化大学存储计划”。我还指出，人们如果要得到一个相对准确的计划，他们必须输入大量他们手边可能没有的信息。我随后开始设想，如果我们重新设计用户界面，是用户至少要点击到调查问卷的最后时，这些选项才出现（而不是在调查问卷的每一页上提供，无形中鼓励了人们在填入所有信息之后再点击该按钮，这样他们就能看到图表和图形的变化），这样可能会把生成计划的数量降低到可以通过营销活动的程度。我还进一步补充说，我们可以再营销活动结束后把计划生成链接再加回每个网页上。
4.6 这不可能是网络的原因
看上去像是一个路由器在最近的机架安装时物理上损坏了
4.7 应为太慢了，我们讨厌它
用户验收测试（UAT usEr ACCEptAnCE tEst）时说“慢”的时候，他们并不是指响应时间，他们指的是应用程序的设计影响了他们的工作效率。
4.8 关键事件分析
是指对某项活动或现象产生了重大贡献的事件，而不管是正面的还是负面的。

4