性能测试高端发展方向

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:35:08 | 相关网摘，我也收藏

业界认为性能测试ROLE划分为 性能测试工程师(偏重编写性能测试脚本、性能测试执行) 和性能测试分析师 (偏重性能分析、系统调优,也需要更加广、深）的知识。

根据个人的理解，性能测试高端发展有如下一些方向： 性能调优，架构评估，性能监控，容量规划，应用性能管理。

性能调优偏重系统级调优、代码级调优，需要非常熟悉系统架构、profile工具(如jprof, gprof ) 。有开发背景的最合适往这个走。

架构评估偏重参与项目前期，根据以前的性能测试经验以及教训判断架构合理性。以后进一步发展成系统架构师。

性能监控就是充分应用现有的工具（如 rpc.rstatd, openview, sitesope,cacti等）以及扩展工具满足详细指标，并图形化展现 容量规划则根据现有系统能力开展what if分析（如增加cpu，更换吞吐率，甚至机型），推算if之后系统性能表现，需要很强的数学功底以及建模能力。目前比较好的工具有teamquest。国内广东电信研究院评测中心和上海电信都在用。

应用性能管理，可以参考Mercury 的BAC产品，如何抢在用户之前主动发现网站或者业务瓶颈。 可以利用QTP/loadrunner的脚本结合sitescope 主动监控。 目前浙江移动已经实施。

http://www.51testing.com/?13997/action_viewspace_itemid_75169.html

软件测试的重要环节:Bug管理的一般流程

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:35:01 | 相关网摘，我也收藏

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
错误跟踪管理系统

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、
Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。
作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。
正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

软件错误的状态

新信息(New)：测试中新报告的软件缺陷；
打开 (Open)：被确认并分配给相关开发人员处理；
修正(Fixed)：开发人员已完成修正，等待测试人员验证；
拒绝(Declined):拒绝修改缺陷；
延期(Deferred): 不在当前版本修复的错误，下一版修复
关闭(Closed)：错误已被修复；

Bug管理的一般流程

　　测试人员提交新的Bug入库，错误状态为New。
　　高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为
Closed，如没有解决置状态为Reopen。

软件错误流程管理要点

为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。
拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

http://blog.sina.com.cn/s/blog_4be815f301008l7f.html

软件测试员的思考问题方式

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:49 | 相关网摘，我也收藏

测试员有很多不同的背景，测试团队是多元化的集体，但是大多数人都同意：测试员的思考方式是不同的。怎么不同?有人说测试员是“消极”思维者。测试员会抱怨这种说法，认为自己喜欢征服，他们在报告坏消息时有一种特别的兴奋感。这是—种普遍观点。我们提出另一种观点。测试员并不抱怨，他们提供的是证据。测试员并不喜欢征服，他们喜欢打破产品没有问题的幻觉。测试员并不喜欢发布坏消息，他们喜欢把客户从虚假信念中解放出来。我们的观点是，按测试员的方式思考意味着实践认识论。测试运用的是认识论，不是靠傲慢或谦卑。

　　本章旨在把测试员的大脑开发成经过仔细调谐的推理机器。请记住：要用精神力量做好事，而不做坏事。

经验１６，测试运用的是认识论

　　读者看到这个题目会说：嘿，回来！我们在这里不是要讨论对电影明星的新崇拜。请相信我们。认识论是能够帮助测试员更好测试的一个哲学分支。

　　认识论研究如何认识所了解的东西：研究证据和推理。这是科学实践的基础。研究认识论的人有科学家、教育家和哲学家，当然还有精英级的软件测试员。学习认识论的学生研究科学、哲学和心理学，目标是了解怎样才能改进我们的思维。我们使用的术语比经典定义要宽，以便能够更多地利用批评性思维的最新成果。将认识论运用于软件测试，要问与以下类似的问题：

·怎么知道软件足够好?

·如果软件并不是足够好，怎样才能知道?

·怎么知道已经完成了足够的测试?

　　苏格拉底早在2400年前就提倡并描述了对信念的批判性观察，因此我们把他看作是最早的认识论者。直到今天，哲学家、科学家和心理学家都还在继续研究认识论。作为测试员，这就是我们的遗产。

经验１７，研究认识论有助于更好测试

　　直接与软件测试有关的认识论问题包括：

·如何收集和评估证据。

·如何进行有效的推论。

·如何使用不同逻辑形式。

·拥有合理的信念意味着什么。

·形式和非形式推理之间的差别。

·非形式推理的常见谬误。

·自然语言的含义与模糊性。

·如何做出好的决策。

　　从来也没有研究过这些问题的很多人也能测试得很好，但是如果要做得比很好还好，就要研究这些问题。研究认识论可帮助测试员设计有效的测试策略，更好地意识到自己工作中的错误，理解自己的测试能够证明什么、不能证明什么，并编写出无懈可击的测试报告。

　　以下是三本具有很高可读性的入门书：

·《批判性思维的工具：心理学的元思想》(Tools of Critical Thinking：Metathoughts for Psychology)(Levy l997)。这本书是针对精神病医生写的，但是对测试员也很有用。书中每一章都是有关更好思维的不同思想。不一定把它全读完，可以挑选任何一章阅读。

·《思考与决策》(Thinking and Deciding)(Baron l994)。这是讨论思维世界的一本可读性很高的普通教科书,是很好的入门书。

· 《研究的技巧》(The Craft of Research)(Booth、Colomb和Williams 1995)。 这是一本有关批判性阅读和写作的很好的书籍，包括如何组织有说服力的论据。主要针对大学生读者。

经验１８，认知心理学是测试的基础

　　如果说认识论告诉我们的是应该怎样思考，那么认知心理学告诉我们的是我们是怎样思考的。与测试有关的一些问题包括：

·人的感觉和记忆可靠性。

·信念从哪里来。

·信念如何影响人的行为。

·做出决策所使用的偏见和捷径。

·如何了解并分享所知道的信息。

·如何考虑复杂事情。

·在压力下如何思考。

·如何识别模式。

·如何把想法和事物分类。

·如何注意事物之间的差别。

·记忆事件中的失真。

·如何重新构建部分记忆的事件(例如不可再现的程序错误)。

　　从来也没有研究过这些问题的很多人也能测试得很好，但是如果要做得比很好还好，就要研究这些问题。研究认知心理学有助于理解影响测试员工作成绩的因素，以及影响人们解释自己工作方式的因素。

　　开始研究认知心理学，不能不看《旷野中的认知》(Cognition in the wild)(Hutchins 1995)。Hutchins研究海军航海团队，以及他们怎样协同工作。这本书的很多内容也都与软件项目和测试团队有关。

　　有关思考心理学的一本有用的书是《理论与证据：科学推理的能力的开发》

　　(Theory and Evidence：The Development of Scientific Reasoning)(Koslowski 1996)。在这本书中，Koslowski研究了人们如何使用因果关系理论进行系统推理。这可以解释为什么测试不只是查看外部行为，并对照简单的预期描述进行检查。

经验１９，测试在测试员的头脑中

　　优秀测试和平庸测试之间的差别在于测试员如何思考：测试员的测试设计选择，解释所观察到的现象的能力，以及非常令人信服地分析描述这些现象的能力。测试的其他工作大部分是一般的办公室工作。如果看到两个测试员并排工作，不一定能看出谁的测试更好。他们工作中能够看得到的部分外表相同，这说明：

·很多人认为测试很容易，因为可以很容易地模仿优秀测试员的外表看得到的行为，并且他们没有好的测试的其他标准。

·如果要成为优秀测试员，就要学会像优秀测试员那样思考，而不是模仿他们的行为。

经验２０，测试需要推断，并不只是做输出与预期结果的比较

　　流行的观点认为，测试员只是执行测试用例，并对照预期结果比较执行结果。这种观点把测试看作是简单的比较活动，没有看到一些聪明人必须设计测试，并确定预期输出。想想看，测试设计人员几乎从来没有得到过应该测试什么的权威指导，更不要说应该期望什么了。可以得到的指导是要解释的主体。在现实生活中，大多数测试设计都是基于推断，或基于与测试员的推断有关的经验。不仅如此，这些推断还要随时间发生变化。像测试员那样思考，就是要掌握探索式推断的艺术。

　　探索式推断听起来可能像是奇怪的想法，这意味着要以一种不能事先预测的方式，通过一种思想引出另一种思想，然后再引出下一种思想。有关探索式推断的一本很好的书是《证明与反驳：数学发现的逻辑》(Proofs and Refutations：The Logic of Mathematical Discovery)(Lakatos，1976)。关于这本书需要注意的是，Lakatos如何说明数学和科学推理过程是探索式的，而不是脚本化的。甚至数学家也是积极探索地推理，而不是通过运用枯燥的公式。他们像测试员那样思考！
经验２１，优秀测试员会进行技术性、创造性、批判性和实用性地思考

　　各种类型的思考都要考虑测试的实施。但是我们认为需要提出四种主要思考：

·技术性思考。对技术建模并理解因果关系的能力。这包括诸如相关技术事实的知识和使用工具并预测系统行为的能力。

·创造性思考。产生思想并看到可能性的能力。测试员只能以能够想像得到的方式进行测试，只能寻找猜想会存在的问题。

·批判性思考。评估思想并进行推断的能力。这包括在自己的思考中发现并消除错误的能力，将产品观察与质量准则关联起来的能力，以及针对特定信念或所建议的行动过程构建有说服力的测试用例的能力。

·实用性思考。把想法付诸实施的能力。这种能力包括诸如运用测试工具，并使测试手段和力量与项目范围适应的技能。

　　总之，像测试员那样思考，会最终导致相信事物可能不像外表看起来那样。不管事物是怎样的，都可能有差别。我们发现，当测试过程以最具破坏性的方式失败时，根本原因最有可能是视野狭窄。换句话说，这不是运行了一万个测试，而本来应该运行一万零一个的问题；问题是没有想像出测试的总体大纲，没有做即使有两倍时间和资源也不会做的测试。

经验２２，黑盒测试并不是基于无知的测试

　　黑盒测试意味着产品内部知识在测试中不起重要作用。大多数测试员都是黑盒测试员。为了做好黑盒测试．就要了解用户，了解他们的期望和需要，了解技术，了解软件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，了解开发过程等等。黑盒测试的优势在于测试员可能与程序员的思考不同，因此有可能预测出程序员所遗漏的风险。

　　黑盒测试强调有关软件的用户和环境知识，这一点并不是所有人都喜欢的。我们甚至把黑盒测试描述为基于无知的测试，因为测试员自始至终都不了解软件内部代码。我们认为这反映出对测试团队角色的根本误解。我们不反对测试员了解产品的工作原理。测试员对产品了解得越多，了解产品的方式越多，越能够更好地测试它。但是，如果测试员主要关注的是源代码，以及能够从源代码导出的测试，则测试员所做的工作也许就是程序员已经做过的，并且测试员关于这些代码的知识要少于程序员。
经验２３，测试员不只是游客

　　测试员对产品做的大量不是测试的事，有助于测试员对产品的了解。测试员可以浏览产品，看看产品由什么组成，怎么工作。这样做有很高价值，但这不能算是测试。测试员和游客之间的差别在于，测试员把精力放在评估产品上，而不只是见证产品。虽然不必事先预测产品应该表现出的行为，但是试验产品能力的活动还没有成为测试，除非而且直到测试员运用某种如果问题存在就能标识的原理或过程时，这种活动才能成为测试。

经验２４，所有测试都试图回答某些问题

　　所执行的所有测试，都是要回答有关现实的产品和应该得到的产品之间关系的某个问题。有时测试员完全没有意识到自己在回答问题。如果测试员只是在寻找明显的问题可能还好，但是在很多情况下，问题并不会闪烁着“请报告我”的提示自己跳出来。产品的有些错误行为用户可能一眼就会看出，尽管测试员可能没有注意到。在任何测试活动中，都要问自己什么样的问题应该推动自己评估测试策略，否则就会更像是游客，而不是测试员。
经验２５，所有测试都基于模型

　　测试员在设计测试时，头脑中可能会有一个想像的图景，也可能有功能清单或某种图表。测试员会有谁是用户、用户关心什么的一些概念。所有这些都是模型。不管模型是什么，测试都主要基于产品模型进行，而不是实际产品。有缺点的模型会产生有缺点的测试。学会一种对产品建模的新方法，就像是学会了观察产品的一种新方法。

　　要研究建模问题。测试员对建模艺术越精通，越能够更好地测试。有关需求分析和软件体系结构的教科书和课程会有所帮助。获得各种建模技能的一种很好方法就是研究系统的思考。请参阅《通用系统思考引论：25周年版》(An　Introduction to General Systems Thinking ：Silver Anniversary Edition)(Weinberg 2001)。

经验２６，直觉是不错的开始，但又是糟糕的结束

　　测试员很想根据自己的直觉使用具体的测试数据，或判断具体的输出，即测试员自己知道的“本能感觉”，即使说不出来使用这些知识的合理性的理由。我们认为这是有用的感觉，但是只是在开始时更有用，而不是在其他时候。

　　除了直觉有很强的偏见这个事实之外，真正的问题还在于测试员试图让其他人(例如程序员和经理)认真地对待自己的错误报告和质量评估。除非这种发现是基于大家都有的直觉，否则测试员的工作建议很可能不被采用。

　　因此．我们建议把直觉用作指南，但不能用作合理性证明。当有“这是问题，因为它显然是问题”的想法时，可考虑换一种方式；“这是问题，因为我观察到产品行为与需求x、Y和z矛盾，而我的客户很看重这些需求。”

经验２７，为了测试，必须探索

　　为了很好地测试产品，测试员就必须研究它，必须深入它。这是一种探索过程，即使已经有了产品的完美描述。直到通过想像或接触产品本身而探索规格说明之前，所得到的测试都会是肤浅的。即使充分研究了产品，对产品有了很深的了解，仍然要探索问题。因为所有测试都是采样，而且样本永远也不可能完备，探索式思考要在整个测试项目过程中，在寻求最大化测试价值时起作用。

　　这里所谓的探索，是指有目的的漫游：带着一般使命在某个空间中漫游，但没有预先确定的路线。探索包括不断学习和实践。常常需要返回、重复或在没有经过培训的人看来是浪费的其他过程。也许正因为如此，探索对于测试和对软件工程的重要性，常常没有得到重视，总至受到这个领域的文献作者和顾问的嘲笑。

　　证明我们关于探索核心重要性的论断超出了本书的主题范围。生动地体验探索的一种方法，就是观察自己在不看印在盒子上的完成图的情况下，如何拼接拼图板，或玩“20点问题(Twenty Questions〕”或“策划(Mastermind)”游戏。请注意，通过预先严格确定的步骤进行，在这些活动中会怎样遇到更多的困难，得到更少的回报。


经验２８，探索要求大量思索

　　探索就是侦查，是没有边界的搜索。可把探索看作是在太空中遨游，需要前向,后向和侧向思索。

·前向思索。根据已知探索未知，从所看到的探索还没有看到的，注意支流和副作用。例如，看到一个打印菜单项，点击看看会发生什么。

·后向思索。从怀疑或想像的东西返回到已知，尝试证实或否定自己的推测。例如：怀疑是否有打印这个文档的方法，于是打开菜单并检查是否有打印菜单项[Solow 1990)。

·侧向思索。让自己的工作由于新冒出的想法而转移，然后再将探索主题返回到主线索上(de Bono 1970) 。例如：这个图很有意思。嘿!我想该打印一些更复杂的图，看看会怎么样。

　　即使没有要测试的产品，也可以探索。可以使用同样的思索过程探索一组文档，或与程序员面谈。通过构建更丰富、更具想像力的产品模型，探索也会不

　　断取得进展。这些模型以后会使测试员设计出有效的测试。
经验29, 使用诱导推断逻辑发现推测

　　诱导推断(abductive inference)又叫做假设归纳(hypothetical induction),是一种测试员每天都要使用的关键推理形式的有些怪的术语：最佳解释的推理。

　　其主要内容是：

1．收集一些数据并要找出其中的意义。

2．构造可能说明这些数据的各种解释。

3．收集更多的数据，以确定或否定每种解释。

4．从候选解释中，选择能够最一致地说明所有重要数据的解释，如果没有足够证据证实任何结论，则继续搜索。

　　诱导推断是科学和测试的基本方法。医生在为病人诊断时就要使用这种方法，测试员在判断产品是什么和不是什么、产品应该怎样运行或不应该怎样运行时，也要使用这种方法。如果要更好地进行诱导推断,则：

·收集更多的数据。

·收集更重要的数据。

·收集更可靠的数据。

·理解应用于数据的原因和效果。

·找出可以说明数据的更多、更好的解释。

·收集更多否定每个解释的数据。

·收集更多区分解释的数据。

·除非某个解释能说明所有重要数据，并且明显得到比其他解释更好的解释,否则不要确定解释。

　　诱导是寻找好的解释的一种系统化方法。尽管诱导推断过程并不提供绝对确定性,但是在很多情况下,这都是最佳手段。

经验30,使用猜想与反驳逻辑评估产品

　　20世纪初，哲学家Karl Popper引入了猜想与反驳(conjecture and refutation)方法(Popper 1989)，用于如何区分宗教和科学问题。这种方法基于科学家永远也不能绝对肯定任何具体事实,或关于自然的理论这个前提。任何东西都是猜想。有些猜想很强．例如重力的存在。它是猜想而不是绝对肯定的事实，是因为能够想像出新的信息，如果这种信息存在，就会使人们拒绝该猜想。Popper注意到，虽然我们不能证明猜想是真，但是却可以证明猜想是假的。因此，他提出给定猜想的置信度只能来自反驳它．但又反驳不了的努力。

　　这种给出猜想并尝试反驳的方法，以三种重要方式应用于测试：

·测试的目的是显示产品失效，要比显示产品正常更有力。如果想知道产品是否能够正常运行，寻找方法反驳其正常运行，这样的测试可能更好。

·有关软件(软件有怎样的行为、如何好等)已经牢固形成的信念应该受到质疑。这意味着应该能够想像出新的与已有信念矛盾的信息。否则，我们的信念只不过就是信仰。信仰在私人生活中是有益的，但是对测试是有害的。

·警惕声称以超过测试员所运行的具体测试的方式，检验或确认了产品的测试。任何量的测试都不能提供产品质量的确认性。

经验31,需求是重要人物所关心的质量或条件

　　可以从很多种“需求”定义中选择适合测试员的定义。作为测试员，必须认识到谁的关于质量的观点最重要(并不是每个人的观点都同等重要)。然后了解对于产品他们要什么，不要什么。这种需求与软件工程的“需求”(在“需求文档”中发布的，并由有批准权限的人批准的一组陈述)和所有种类的规格说明没有差别。至于测试，产品应该具备或满足的任何质量或条件都是需求。

　　不同客户通过产品要得到不同的东西，他们不一定知道要什么，而且所要的东西会随时发生变化。这位测试员的工作更有意义。欢迎测试。
经验32,通过会议、推导和参照发现需求

　　如果期望得到一迭印刷精美、文件袋封条盖有全球有效印章的需求，那还是另找工作吧。我们所经历的最好情况，需求文档(包括所有种类的产品规格说明、用例、多媒体文档等)是不完整、不准确的，尽管需求文档提供了信息并且是有帮助的。我们所看到的最差情况，文档是不完整、不准确、没有提供信息并且是没有帮助的。

　　测试员把项目文档(产品的显式规格说明)看作是惟一需求来源会影响其测试过程。在我们所管理的所有测试团队中，坚持这样要求会招致反驳。

　　需求信息到达测试员主要有三种途径：

·会议。找出其有关质量的意见具有影响力的人，与他们交流，了解他们最关心什么。

·推导。通过外推己知的项目和产品其他信息，确定什么需求最重要。

·参照。既发现显式，也发现隐式规格说明，并以此作为测试的基础。

　　在很多项目中，优秀测试员所使用的大多数需求要么来自推导，要么来自隐式规格说明的参照。搜寻测试所需的信息，是测试员的工作。

　　有一本关于这个问题的好书:《探索需求：设计之前的质量》(Exploring Requirements：Quality Before Design)(Gause和Weinberg l989)。
经验33,既要使用显式规格说明，也要使用隐式规格说明

　　并不是包含测试所依赖重要信息的所有参照都是显式地提供给测试员的：

·显式规格说明是一个有用的需求信息源，经过客户的权威确认。(“是的，这就是规格说明，是产品描述。”)

·隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。(“这不是规格说明，但是有意义。”)

　　隐式规格说明的威信来自其内容的说服力和可信性，而不是客户的批准。在大多数情况下，只有部分隐式规格说明与当前产品有关。隐式规格说明有很多种形式：

·竞争对手的产品。

·相关产品。

·同一产品的老版本。

·项目团队之间的电子邮件讨论。

·顾客意见。

·杂志文章(例如，有关产品老版本的综述) 。

·相关主题的教科书(会计书籍适用于会计应用程序) 。

·图形用户界面(GUI)风格指南。

·操作系统(o／s)兼容性需求。

·测试员自己的丰富经验。

　　当产品与显式规格说明冲突时，测试员的报告任务相对简单一些：“产品违反了规格说明，因此产品也许错了。”当违反的是隐式规格说明时，测试员的报告必须详细一些：“在Microsoft Office中，功能键F4固定用于重复命令。除非我们也这样定义，否则在日常工作中也使用Office的用户会感到困惑。”虽然没有人说Microsoft Office是这个产品的规格说明，但是客户可能会同意采用与Office一致的用户界面会提高可使用性。如果是这样，则Office就是这个产品的一个隐式规格说明。

　　有些测试员可能会问，为什么设计人员不把所有有用的信息都放入显式规格说明，使得他们不必再从隐式资源中分辨规格说明。回答很简单：虽然这样做方便了测试员，但是很昂贵，而且没有必要。客户相信测试员能够使用所需的各种参考资料快速找出重要的问题。
经验34,“它没有问题”真正的含义是，它看起来在一定程度上满足部分需求

　　任何时候听到有人说“我试过了，它没有问题“、“我保证它没有问题”或“它现在更好了”，我们建议把“它没有问题”解释为“它看起来在一定程度上满足部分需求”。测试员应该立即想到的一些问题包括：

·“它”是什么?我们正在谈论的是产品的哪个部分?

·外观是什么情况?到底观察到了什么?

·检查了哪些需求?正确性如何?性能如何?

·为了通过测试要在多大的程度上满足该需求?只是刚刚通过,还是超过指标很多?

·它什么时候没有问题?测试覆盖了多大范围的条件?通过这些条件可以安全地推广到多远?

　　如果不愿意，可以默默地问自己。关键是如果对“它没有问题”没有进一步地限定，它就会是模糊的。测试员所认为的“它没有问题”的意义，可能与别的人定义不同.
经验35,测试员所能得到的只是对产品的印象

　　不管测试员对产品的质量有什么看法，都是猜想。不管猜想有多么好的支持,也不能肯定自己是对的。因此，任何时候报告产品质量状态时,都应该用有关测试方法和测试过程的己知局限性的信息，对报告进行限定。

经验36,不要将试验与测试混淆起来

　　试验的含义是什么，可能表示测试员执行一段探索式测试，产生—些没有文档或试验产品的临时性试验；也可能表示测试员编写一套可执行测试程序，或一套显式的测试过程；也可能表示某种高水平的测试矩阵、测试大纲或一套测试数据。

　　试验的概念是自包含的、实在的，与其他方便(我们通篇使用方便(convenient)概念，因为它是测试界的标准行话)试验不同，但也是受限的。关键还是测试，而不是如何将测试打成被称为试验的包。测试是任何至少包含以下四种活动的活动：

·配置。准备要测试的产品，将其置于正确的起始状态，否则测试结果会受到不良变量的影响。

·运行。向产品输人数据,向产品发命令，以某种方式与产品交互。否则，产品只是放在那里，测试员能够做的只是评审，而不是测试。

·观察。收集有关产品行为信息、输出数据、系统整体状态、与其他产品的交互等方面的信息。测试员不能观察所有事物，但是没有观察的任何事物都可能使测试员看不到问题所在。

·评估。运用规则、推理或可检测所观察到数据中存在问题的机制。否则要么不能报告问题，要么只是把数据提交给客户，由客户自己进行评估。

　　试验产生的可能有很多形式，不要过于关注形式，耍保证有这四种活动发生。要关注执行这些活动的思考者，关注试验是否很好地完成了预想的策略和测试使命。

http://www.51testing.com/?action_viewnews_itemid_76243.html

单元测试中的问题和解决方案

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:40 | 相关网摘，我也收藏

利用单元测试，我们可以找出很多意想不到的问题，在Nunit对项目进行单元测试 过程中就查找出了很多隐藏的问题，下面是单元测试中遇到的问题与解决方案：

1.TQL_Part表
1.1问题1
下面是项目中的代码：
/**////
/// 根据taskid，获得对应的Part记录
///
///
///
public WYEng.Model.TQL_Part GetPaperPart(int taskId)
...{
SqlParameter[] parm = new SqlParameter[1];
parm[0] = new SqlParameter(PARM_TASKID, SqlDbType.Int);
parm[0].Value = taskId;
WYEng.Model.TQL_Part part = new WYEng.Model.TQL_Part();

using (SqlDataReader rdr = XPWY.DBUtility.DBHelperSQL.ExecuteReader(SQL_SELECT_PART, parm))
...{

while (rdr.Read())
...{
part.PartCode = rdr.GetString(0);
part.SetCode = rdr.GetString(1);
part.SubjectId = rdr.GetInt32(2);
part.DisplayOrder = rdr.GetInt32(3);
part.Description = rdr.GetString(4);
}

}
return part;
}
写测试用例如下：
using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
using WYEng.SQLServerDAL;

namespace WYEng.TestUnit
...{
[TestFixture]
public class TQL_Part
...{
SQLServerDAL.TQL_Part part;
WYEng.Model.TQL_Part p;
[SetUp]
public void CreateObject()
...{
part = new WYEng.SQLServerDAL.TQL_Part();
p=new WYEng.Model.TQL_Part();
}

[TearDown]
public void DeleteObject()
...{
part = null;
p=null;
}

[Test]
public void GetPaperPart()
...{
//输入TaskId的值，然后可以获取其Part所有信息
p = part.GetPaperPart(1); //正常情况
Assert.AreEqual(p.PartCode, "6666");
}
}
}运行Nunit，状态条为红色，经检查发现原因是
model层中的TQL_PArt的description下的代码段有问题
if (value != null && value.Length > 50)
throw new ArgumentOutOfRangeException("Invalid value for Description", value, value.ToString());
数据库中description的字段为Varchar(500),而这里只为50，现在更正为 if (value != null && value.Length > 50)
修正后，运行后的状态条为绿色。

1.2问题2
　　然后GetPaperPart()方法中加入如下代码，测试边界情况：
p = part.GetPaperPart(1000);//边界情况
Assert.AreEqual(p, null);
　　用以上代码测试边界条件时，状态条为红色。
　　经检查，发现代码如下
public WYEng.Model.TQL_Part GetPaperPart(int taskId)
...{
SqlParameter[] parm = new SqlParameter[1];
parm[0] = new SqlParameter(PARM_TASKID, SqlDbType.Int);
parm[0].Value = taskId;
WYEng.Model.TQL_Part part = new WYEng.Model.TQL_Part();

using (SqlDataReader rdr = XPWY.DBUtility.DBHelperSQL.ExecuteReader(SQL_SELECT_PART, parm))
...{
while (rdr.Read())
...{
part.PartCode = rdr.GetString(0);
part.SetCode = rdr.GetString(1);
part.SubjectId = rdr.GetInt32(2);
part.DisplayOrder = rdr.GetInt32(3);
part.Description = rdr.GetString(4);
}
}
return part;
}

用YEng.Model.TQL_Part part = new WYEng.Model.TQL_Part();实例化一个对象以后，如果rdr里面没有任何行，part的值也不为null，所以修改代码如下：
public WYEng.Model.TQL_Part GetPaperPart(int taskId)
...{
SqlParameter[] parm = new SqlParameter[1];
parm[0] = new SqlParameter(PARM_TASKID, SqlDbType.Int);
parm[0].Value = taskId;
WYEng.Model.TQL_Part part = new WYEng.Model.TQL_Part();

using (SqlDataReader rdr = XPWY.DBUtility.DBHelperSQL.ExecuteReader(SQL_SELECT_PART, parm))
...{
if (!rdr.HasRows)
...{
part = null;
}
else
...{
while (rdr.Read())
...{
part.PartCode = rdr.GetString(0);
part.SetCode = rdr.GetString(1);
part.SubjectId = rdr.GetInt32(2);
part.DisplayOrder = rdr.GetInt32(3);
part.Description = rdr.GetString(4);
}
}
}
return part;
}

　　运行Nunit后，状态为绿色，其他的类似问题也进行了相应的修正。

http://www.51testing.com/?action_viewnews_itemid_76468.html

Web测试的几个隐藏点

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:31 | 相关网摘，我也收藏

很多时候，基于需求的测试和针对web特有的浏览器兼容性测试、cookie失效的验证，对于测试人员并不陌生。但实际上，与浏览器相关的测试内容远不止这些。

　　举一个例子来说，很多时候我们都非常明确页面上的所有入口，并对这些入口设计了大量的用例，而浏览器的地址栏却常常会被我们忽略。实际上，url的输入意义远比我们意识中的重要，忽略了url的测试，很容易造成安全上的隐患。

　　再进一步的说，浏览器的前进、后退、刷新按钮同样是测试人员需要关注的点。前进、后退在用户登录、注销信息的测试中应用最为频繁。而刷新，往往容易被忽视，但其同样是bug的“温床”。在最近的一次测试中，我就遇到过在我删除某条记录系统提示删除成功后，点击“刷新”按钮，页面提示出错的情况。出现该现象的原因就在于页面试图去取已删除的内容，导致出现异常。其实这个问题应该隐藏了比较久的时间，但是却一直未被发现，足可见我们都忽视了“刷新”的测试。

　　除了上述的内容外，我相信一定还存在很多我们在测试中忽视的内容，而这些点的补充，是我们每一个人的责任！

http://www.51testing.com/?action_viewnews_itemid_76465.html

关于测试和恢复性的争论：面向对象vs.函数式编程

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:23 | 相关网摘，我也收藏

Michael Feathers最近的博文在博客社区引发了一场异常激烈的论战。Feathers发表言论说一些面向对象编程语言的内嵌特性有助于测试的进行，并且使用面向对象编程语言编写的代码更容易恢复。

他举了这样一个例子，class X有一个叫作badMethod的方法，这个方法处理一些“痛苦”的工作，比如调用并更新产品数据库、或者处理一些甚至关系到底层硬件的事务：

public class X { public void method() { ... badMethod(); ... } ...}
理想的设计是，系统可以允许独立测试一般的类和类组。但如果这个例子没有实现这样的设计，“badMethod是个非final，可覆写的方法”的事实就有利于为获得“测试足够的机动性”提供所需的灵活性，因为它允许“覆写功能并为我们创建一个楔子来让测试变得更简单”：
public class TestableX extends X { void badMethod() { // do nothing } }

Feathers称之为一个seam（接缝），“一个你无须修改便能使用一个功能替代另一个功能的地方”。他相信OO语言提供的缓绑定技术使得其本身比函数式语言的恢复更为友好。

一些评论者，包括Feathers本人在内，都强调了大多数语言都能提供seam的事实：预处理器、继承／多态性和委派、宏和函数指针、高阶函数、动态函数、一等函数、模块边界或monads。。。。。。其中一些人认为，真正关系到可测试性的是底层设计而非编程语言的选择。比如John，他断言，无论使用何种语言，“代码的结构需要首先考虑到简化单元测试。”另一位博客Andrew，强调说如果“代码的结构没有向所需的测试看齐的话”，那么实现将不得不向顺应测试的方向，做相应的修改。因此，他也评论说“关于‘seam’的想法确确实实是瞄准了为实现可测试性而进行恰当设计的底层问题”，也就是说，适当地布置seam。

http://www.infoq.com/cn/news/2008/03/revoerability-and-testing-oo-fp

软件测试内容全貌——全景图(1)

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:14 | 相关网摘，我也收藏

http://topic.csdn.net/u/20080118/10/cff32eb5-67e9-459d-8088-4f30d5cb2b8c.html

为可用性测试做的准备产品设计与战略

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:34:01 | 相关网摘，我也收藏

如果你没有对你的产品进行过测试，那么你的产品就不能正试上线。通过可用性测试可以提高产品的可靠性和有效性。

　　让真正的用户来进行用户测试是基础的可用性测试方式

• 在纸上记录用户使用时的表情和用户的回答

　　记录实际使用情况，包括每个用户使用每个功能的频率和各类事件发生的频率。

　　在测试期间，试验人员在正常情况下不应干扰用户的操作，当用户显然陷入困境，并且已经感到绝望时，应当给予一定的提示，同时试验人员要记录下用户的各个举动或回答。

• 当用户执行任务时，边想边说出自己的想法。

　　边说边做法可能是单个最有价值的可用性测试方法。采用此方法让用户在使用系统的时候大声的说出自己的想法。

• 协同交互方法

　　协同交互方法是边说边做的一种变形的方法。就是让两个测试用户同时使用一个系统。优点在于测试形式比只用单一的用户进行的标准边说边做测试的更加自然一点，因为人们习惯与在共同解决问题时把自己的想法讲出来。同时西贝提示“关于儿童产品的话，这个可以最佳选择呀”

• 核对测试，恒量，统计分析。

　　可以使用回顾式测试方法，让用户温习录像的内容来收集额外的信息。

• 查询技术：面谈和问卷。

　　其他的可用性测试方式：观察法、问卷调查和访谈、焦点小组等。

为什么要进行可用性测试？

　　很多人认为，以他们的经验可以了解别人的行为。然而经过可用性测试后这种想法完全失去立场。经验可以改变一个人的世界观，而且很难再次改变，但是别人不一定与你有同样的经验。然而有时设计师更容易用上自己的直觉，然而，直觉通常是错误的。

　　有一个关于键盘与鼠标的例子：在一项研究中有这种现象，测试用户被要求用键盘和鼠标做一个同样的任务。完成任务后，在没有告知测试结果前，每个用户都报告说他们使用键盘操作时要快，但恰好相反，秒表上显示的是他们使用鼠标时要快。

显而易见取走教训

　　在可用性测试前，不管是忠实哪种观点个人观点都是值得怀疑的，只能让测试结果来证实。

为可用性测试做的准备

确定测试目的

　　形成性评估：是反复设计过程的一部分，目的是为了改进界面设计；他的目标是理解界面细节方面的优劣，以及如何改进设计。它的典型方法是边做边说式测试。

　　总结性评估：在于评定界面的整体质量，例如可以在两个备选方案中进行选择，或者作为竞争性分析的一种手段，来了解竞争对手的产品设计好在哪里。典型的总结性评估方法就是度量型测试。

测试环境

1． 一个简单的测试环境：必须确保有一个舒适的测试环境。安排一个安静的房间，门口贴上"用户测试正在进行中-请勿打扰" ，禁用电话（手机和固话），确保适度的光亮，提供不含酒精的点心

2． 使用专用的测试研究室

摄像机

三脚架

好的麦克风

耳机（用来监控声音）

镜子

台灯或录像照明

彩色视频监视器（用来查看相机影像）

录像带记录器/播放器。

视频车。

电源线。

"请勿打扰"的标志。

茶点。

记录软件。

测试角色

1．测试调解人（管理员，主持人，经理，监察）

——负责整个测试过程，负责与测试用户的所有交感

2．数据记录者

——在纸上记录用户的有影响的行为和过程

3．摄像师

——负责用摄像机记录整个测试过程

——确保摄像机视角在用户和界面都可见。

——使用手动调焦（不能在电脑屏幕前使用自动调焦）

——关掉摄像机上的所有数据显示，如时间、日期等。

——确保摄像质量足够高。

——标记，拷贝，编辑录影带。

4．电脑操作员

——在一个纸张原型中担任一个电脑的角色。

——为每个测试用户重置一个电脑环境，如清除缓存，历史记录，cookies等等。

——不要将测试站点设为主页，让用户自己办输入URL。

——当遇到大问题时，重新配制环境到初始状态。

5． 测试参与者或测试用户

——参加测试。

本文来自于51Testing软件测试网

http://www.51testing.com/?action_viewnews_itemid_76635.html

软件过程改进：经验和教训

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:50 | 相关网摘，我也收藏

前言：

　　2001我开始慢慢关注起软件工程和CMM，也对CMM进行了学习。并且对其中的一些KPA在自己单位中进行了试验。可是一开始这些试验的结果并不令人愉快，甚至遭到了抵制和反对。开发和测试人员认为降低了开发速度和灵活性，加大了工作量，工作流程太烦琐。而质量的提高也不是一时可以反映出来的。于是在进行了2个小项目的试验后，我被迫停止了CMM在公司的实施。因为公司并不从事外包服务，所以CMM对其没有生存的压力。高层也只是想通过一个可行的过程管理，一个提高软件质量，保证项目进度，有效控制项目成本。所以公司并不是要去过CMM等级，而是要一个有效的过程管理。

　　所以我此后开始以‘有效、简易、可行、低成本’为标准探索起适合起我们公司的过程改进的最佳实践。现在，我很高兴可以在文中和大家探讨我公司在过程改进过程中的一些经验和教训，也许你会从中得到一些启发，开发出适合你自己的最佳实际。　　经验和教训：

　　在中小型的软件企业当中，软件过程的改进更容易半途而废。

　　中小企业，特别是开发人员小于40个人的企业。一般不会有专门的人员可以组建‘软件过程组’，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的，而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一方面希望，可以通过过程改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。持续的改进很重要，但频繁的改进会不利于过程的执行CMM中定义了每个KPA的目标和一系列的KP，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的最佳实践。一般的情况是，首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再在其他项目或整个企业中推广，也许在推广的过程中，又遇到问题，再对流程进行修改。整个的过程定义是螺旋上升的进行。 这本身没有问题，但有时当遇到问题时，不要太急于就改流程，或加流程的分支。而要仔细分析后，慎重的进行。太频繁的改动，给人一种不严肃的影响，似乎流程可以随意的改动和定义。最后，没人去遵守流程了。 同时，根据不同的项目若定义了太多了流程分支，最后，实际人员也不知道要去实行哪一套了。总之，频繁改动的规矩，让人无所适从。过程制定后，一定要有选择的进行试点。一个进度和成本宽余的项目和一群对过程改进 有热情的人是保证试点成功的组合。定义好一套流程，最好的验证方式就是找个真实的项目去‘跑’一遍。并注意收集应用流程前后的各种情况的对比。由于在项目的进行中，还要试验流程，所以需要更多的培训时间，让项目组的成员了解熟悉新的流程。需要更多的评审，不但是评审项目本身，还要评审过程和进行必要的度量。

一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程，要有热情去沟通在执行新流程当中遇到的问题，他们要有热情去克服进行中的困难，而不是抱怨，他们要有热情去总结和改进新的流程，使它更完善，最总要的是，他们要有热情作为新流程的传播者，把流程象星星之火一样在组织中开展。一个坚决支持过程改进的领导是必不可少的。象任何其他的变革一样，一个坚决支持变革的领导是不可缺少的。在一切顺利，大家赞成的时候，也许感觉不到什么。但当变革遇到阻力，遭受暂时的困难时，这种坚决的支持就是变革是否可以继续进行的保证。因此，在过程改进的初期，于企业的高层进行沟通，让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段，一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程，取得的成果。当然在遇到困难，或需要高层支持时，更要及时开口。(这对于技术人员主持的过程改进尤为重要。)要有选择的对于KPA进行改进，不一定是最薄弱的KPA，最重要是选择你可以控制的KPA。关于这点其实并不涉及CMM的技术问题，而是一个管理问题。这里有个现实的例子，一家企业的管理有点乱，高层希望可以通过CMM的过程改进，来提高企业的产品质量，理顺工作的流程。于是任命了一个开发组的主管(代称A)，来主持这个过程改进。 结果A在选择KPA的时候，认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨，需求经常改变，造成的返工很多，在最终期限的压力下他们不得不经常加班。 这个本事没有问题，可是需求管理和变革管理的发起基本是在系统分析组，而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别(即使是暂时的)。

　　现在问题来了，虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候，他发现，当他去评审需求分析组的工作时，别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。同时，流程中只要有一点不太合理的地方，就抱怨的很厉害。最后试点结束，他自己很累，试点的结果也不好，改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后，试点的流程并没有推广。其他的KPA过程改进也不再进行了，随着时间的推移，过程改进在企业中也不在有人提起。知道这位开发组的主管错在哪里吗? 他选错了KPA，他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚，他是个不受欢迎的人。注定了，在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理，这个至于他管理范围的KPA，他可以利用手中的权利、资源和威信，组织试点。可能情况就好的多。 又或者企业的高层给这个开发主管一个虚职，比如过程改进项目组组长，并任命其他组的组长为过程改进项目组成员。情况也会完全不同。

　　对于过程的改进要有度量。不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。 一个有力的对比可以堵住反对者的嘴。不要因为度量管理是CMM4级的内容就在实施低级别的CMM时放弃度量。一套流程需要一系列度量的数据来说明它改进了多少。而度量的数据将会为它赢得预算和支持。当然度量作为CMM4级的内容，也是有一定的道理的。收集一套完备、准确的度量是需要大量人力的。但是在一开始，也许我们可以借助一些好的工具达到同样的效果，而不必花费大量的时间和精力。在我就自己做过一个简易的BUG管理工具，并和数据库相连。在项目结束时我可以轻易的了解项目中有多少BUG、BUG分布如何，BUG的原因统计等度量数据。我只是用了几个SQL语句就掌握了我需要的度量。

http://www.51testing.com/?action_viewnews_itemid_76630.html

QC 9.0学习和安装笔记 - 一起测试网 - CSDNBlog

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:42 | 相关网摘，我也收藏

http://blog.csdn.net/szstc/archive/2007/06/27/1668152.aspx

如何判定“测试通过”？

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:34 | 相关网摘，我也收藏

文如标题。其实这应该是一个老生常谈的问题，然而因为太老了，所以它差不多已经在不断涌现的“后浪”（新问题）推动下死在了“沙滩上”，而答案也变得更加的模糊。

　　可是这个问题其实每一个测试人员都无从逃避。也许我们每个人都在心里有一把尺子，只是尺子的最小单位和最大丈量范围不同，但是确实就那么存在着。我也有，从我做测试的第一天起其实就已经有了，只是每次用这把尺子算出结果的时候，我都会或多或少的担心过是否自己计算错误。想想看，一个以测试为职业一个习惯对任何事物先进行怀疑的人怎么能不去怀疑自己的计算结果，更何况这个结果产生的影响足以值得我们去测试这个结果。

http://www.51testing.com/?action_viewnews_itemid_76464.html

进军IT行业需先做好职业规划

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:25 | 相关网摘，我也收藏

近年来，中国软件产业保持了迅猛发展的态势，但是，由于一直以来，中国许多软件企业存在着“重开发、轻测试”的倾向，因此，在造成软件产品质量问题日渐突出的同时，也突显了中国软件测试人才的极度匮乏。

3784.99亿元——软件行业发展迅猛

据最新出炉的《2008年中国计算机市场预测报告》显示，2007年前三季度，软件行业实现收入3784.99亿元，同比增长23.6%，占整个电子信息行业收入比例的10.95%。

30万——软件测试人才缺口30万

据前程无忧招聘网统计，目前，国内120万软件从业人员中，真正能担当软件测试职位的不超过5万人，软件测试人才缺口已超过20万并向30万大关急速挺进。在中华英才网近期发布的2007十大热门职业中，软件测试工程师也位居三甲之列。

10万——软件测试人才年薪可达10万

为了吸引更多的人才，企业纷纷采取高薪策略。据统计，测试工程师的起步月薪在4000～5000元左右，远高于同龄人1000～2000元的薪资水平，另外还可享受带薪年假、内部培训、住房公积金等福利待遇，工作2～3年月薪大约在8000～13000元之间。但即便如此，很多企业仍旧纷纷感叹：“高薪难觅找茬人才。”

1：8——目前我国软测人员与开发人员比例

微软公司软件测试工程师对外透露，在微软内部，软件测试工程师和开发工程师的比例基本维持在1：1左右，而国内其他软件企业中这一比例却仅在1：5至1：8之间。“招个软件测试人员比招博士还难！”不少企业发出类似的感叹。

透过以上数字，可以看出我国的IT行业人才结构正处于失衡状态，软件测试人才缺口巨大。这不但已经成为影响中国软件产业发展的瓶颈，制约着软件整体质量的提高，同时也加重了软件产业的开发和服务成本负担。因此，如何尽快建立软件测试人才的系统培养机制、进而保障软件业的健康化发展已成为现阶段亟需解决的当务之急。

数字背后：

IT行业人才结构失衡

日前，我国第一个全面解读IT行业工作岗位心理素质要求及心理特征与工作绩效之间关系的研究报告——《中国IT从业人员心理特征研究报告》在北京正式公布。专家指出，《中国IT从业人员心理特征研究报告》将为IT企业制定科学的人才选拔的标准提供重要的依据。此项研究报告指出做好职业生涯规划是IT从业者应具备的能力之一，是企业在选拔IT人才时考察的心理品质。

做好职业规划的五个方面

“要做好职业规划，首先要确定一个长期明确的目标，如10年之后你要达到什么水平，还要确定短期的目标，5年的目标、1年的目标，甚至明天的目标。而且确定的目标要可行。第二就是要根据自己的性格、兴趣、成长等因素选择职业。第三就是要选准行业，看这个行业今后的发展会给你留下的发展空间有多大。IT行业属于朝阳产业，正处于发展期，现在和将来都将会是个发展潜力巨大的行业。所以个人会有很大的发展空间。第四点就要做好准备，包括学历、技能、职业素质等方面的准备。第五按照确定的目标行动。”职业规划师张苒给出如此建议，这对于求职者以及刚刚跨入社会的职场人士有着重要的启示作用。

下面以IT行业中软件测试工程师的进阶之路为例，对IT从业者做好职业规划提供一点启示。

软件测试工程师的进阶之路

初级测试工程师

刚入门拥有计算机科学学位的个人或具有一些手工测试经验的个人。开发测试脚本并开始熟悉测试生存周期和测试技术。

测试工程师/程序分析员

具有1～2年经验的测试工程师或程序员。编写自动测试脚本程序并担任测试编程初期领导工作。拓展编程语言、操作系统、网络与数据库技能。

高级测试工程师/程序分析员

具有3～4年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级的评审，并为其他初级的测试工程师或程序员充当顾问。

测试组负责人

具有4～6年经验的测试工程师或程序员。负责管理1至3名测试工程师或程序员。担负一些进度安排和工作规模/成本估算职责。

测试/编程负责人

具有6～10年经验的测试工程师或程序员。负责管理8至10名技术人员。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。

测试/质量保证/开发(项目)经理

具有10多年的工作经验。管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。

计划经理

具有15年以上开发与支持(测试/质量保证)活动方面的经验。管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任。

软件测试人员的三大发展方向

“软件测试人员一般有三大发展方向。”微软公司的陈宏刚博士介绍说，一是走软件测试的技术路线，成长为高级软件测试工程师。二是向管理方向发展，从测试工程师到组长，再到测试经理，以至更高的职位。三是可以换职业，做项目管理或做开发人员。经过软件测试岗位洗礼的人才往往是行业中的多面手，在技术、管理、市场甚至其他非IT领域都能得到良好的发展。当然这首先要取决于从业者是否具备长远眼光，对自己的职业生涯进行合理规划。

http://news.csdn.net/n/20080311/114240.html

嵌入式软件测试的十大秘诀

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:11 | 相关网摘，我也收藏

在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入式有更深层次的理解，向Oracle询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢?　Oracle面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以，面对这个不同寻常却异乎成熟的问题，Oracle感到欣喜并认真回复了他:你的问题很有深度很成熟，因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员，把10条关于嵌入式软件开发测试的秘诀告诉了他:

　　1.懂得使用工具

　　2.尽早发现内存问题

　　3.深入理解代码优化

　　4.不要让自己大海捞针

　　5.重现并隔离问题

　　6.以退为进

　　7.确定测试的完整性

　　8.提高代码质量意味着节省时间

　　9.发现它，分析它，解决它

　　10.利用初学者的思维

　　这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。

　　1.懂得使用工具

　　通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对日益复杂的嵌入式软件进行快速有效的测试愈加显得重要。

　　就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。不同的工具，有不同的使用范围，有不同的功能。使用这些工具，你可以看到你的系统在干些什么，它又占用什么资源，它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?原因很多，主要有两个。一个是害怕，另一个是惰性。害怕是因为加入测试用具或测试模块到代码需要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。

　　.源码级调试器[Source-level Debugger]

　　这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能，是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于这一种。

　　.简单实用的打印显示工具[printf]

　　printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是，printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间)，需要慎重使用，最好设置打印开关来控制打印。

　　.ICE或JTAG调试器[In-circuit Emulator]

　　ICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实时的检测CPU的内部工作情况。像桌面调试软件所提供的:复杂的条件断点、先进的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE一般都有一个比较特殊的CPU，称为外合(bond-out)CPU。这是一种被打开了封装的CPU，并且通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在CPU被封装时，是没法“看到”的。当和工作站上强大的调试软件联合使用时，ICE就能提供你所能找到的最全面的调试功能。但ICE同样有一些缺点:昂贵;不能全速工作;同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合CPU也不大可能及时的被新出的CPU所更换。JTAG(Joint Test Action Group)虽然它最初开发出来是为了监测IC和电路连接，但是这种串行接口扩展了用途，包括对调试的支持。AD公司为Blackfin设计的Visual Dsp++就支持高速的JTAG调试。

　　.ROM监视器[ROM Monitor]

　　ROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和运行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技术。它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬件。并提供了如下功能:下载代码、运行控制、断点、单步步进、以及观察、修改寄存器和内存。因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时，它才会工作。如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再次进入ROM监控器。

　　.Data监视器[Data Monitor]

　　这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集并以图形形式显示各个变量的变化过程。

　　.OS监视器[Operating System Monitor]

　　操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面，这些监视器能够为你呈现事件之间的关系和时间联系;另一方面，还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。

　　.性能分析工具[Profiler]

　　可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。

　　.内存测试工具[Memory Teseter]

　　可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测试工具测测看。

　　.运行跟踪器[Execution Tracer]

　　可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。

　　.覆盖工具[Coverage Tester]

　　主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。

　　.GUI测试工具[GUI Tester]

　　很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。

　　.自制工具[Home-made tester]

　　在嵌入式应用中，有时候为了特定的目的，需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。

　　2.尽早发现内存问题

　　内存问题危害很大，不容易排查，主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。

　　在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大;但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。由于内存泄露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。

　　内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。

　　由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用malloc/free的以绝后患。

　　内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。

　　总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使用规则，比如谁分配谁释放。

　　3.深入理解代码优化

　　讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就象女孩子减肥一样，起码知道她哪个地方最需要减，才能去购买减肥药或器材来减掉它。可见，代码优化的前提是找到真正需要优化的地方，然后对症下药，优化相应部分的代码。前面提到的profile(性能分析工具，一些功能齐全IDE都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。

　　但是，profile工具在分析实时系统性能方面还是有不够的地方。一方面，人们使用profile工具往往是在系统出现问题即CPU耗尽之后，而profile工具本身对CPU占用较大，所以profile对这种情况很可能不起作用。根据Heisenberg效应，任何测试手段或多或少都会改变系统运行，这个对profiler同样适用!

　　总之，提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。

　　4.不要让自己大海捞针

　　大海捞针只是对调试的一种生动比喻。

　　经常听到组里有人对自己正在调试的代码说shit!可以理解，因为代码不是他写的，他有足够的理由去shit bug百出的代码，只要他自己不要写出这种代码，否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢?肯定是有人把针掉到海里咯;那针为何会掉在海里呢?肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候，你是否想过是你自己草率地丢掉的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为了寻求捷径可能没有严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢?关于如何写高质量请参考林锐的《高质量c++/c编程指南》或《关于C的0x8本“经书”》。

　　如果你确实已经把针掉在海里是，为了防止在找到之前刺到自己，你必须要做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根源，我们可以设计比较全面的错误跟踪代码。怎么来做呢?尽可能对每个函数调用失败作出处理，尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。

　　5.重现并隔离问题

　　如果你不是把针掉在大海了，而是掉在草堆里，那要好办写。因为至少我们可以把草堆分成很多块，一块一块的找。对于模块独立的大型项目，使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题，那么我们就可以着手去隔离问题。怎么隔离呢?我们可以用#ifdef把一些可能和问题无关的代码关闭，把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在，那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化;可以使用跟踪工具获得函数调用的情况包括参数的传递;检查内存是否崩溃以及堆栈溢出的问题。

　　6.以退为进

　　猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你这时的第一反映就是我到底改动了些什么呢，因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢?没错，代码控制系统SCS或称版本控制系统VCS(Concurrent Version Control,CVS是VCS的演化版本)。将上个版本check in下来后和当前测试版本比较。比较的工具可以是SCS/VCS/CVS自带的diff工具或其它功能更强的比较工具，比如BeyondCompare和ExamDiff。通过比较，记录所有改动的代码，分析所有可能导致问题的可疑代码。

　　7.确定测试的完整性

　　你怎么知道你的测试有多全面呢?覆盖测试(coverage testing)可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40%代码没有问题，而其余的可能存在bug。覆盖工具有不同的测试级别，用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有dead code,覆盖工具还是可以为你指出一些潜在的问题，看下面的代码:

　　if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))

　　如果almostAlwaysZero为非0,那么last=i赋值语句就被跳过，这可能不是你所期望的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。

　　总之，覆盖测试对于提高代码质量很有帮助。

　　8.提高代码质量意味着节省时间

　　有研究表明软件开发的时间超过80%被用在下面几个方面:

　　.调试自己的代码(单元测试)

　　.调试自己和其他相关的代码(模块间测试)

　　.调试整个系统(系统测试)

　　更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始的时候可能很容易就能找到。一个小bug可能让你付出巨大的代价，即使这个bug对整个系统的性能没有太大的影响，但很可能会影响让那些你可以看得到的部分。所以我们必须要养成良好的编码和测试手段以求更高的代码质量，以便缩短调试的代码。

　　9.发现它，分析它，解决它

　　这世界没有万能的膏药。profile再强大也有力不从心的时候;内存监视器再好，也有无法发现的时候;覆盖工具再好用，也有不能覆盖的地方。一些隐藏很深的问题即使用尽所有工具也有可能无法查到其根源，这时我们能做的就是通过这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦发现任何异常，一定要深入地理解并回溯其根源，直到解决为止。

　　10.利用初学者的思维

　　有人这样说过:“有些事情在初学者的脑子里可能有各种各样的情况，可在专家的头脑里可能就很单一”。有时候，有些简单的问题会被想的很复杂，有些简单的系统别设计的很复杂，就是由于你的“专家思维”。当你被问题难住时，关掉电脑，出去走走，把你的问题和你的朋友甚至你的小狗说说，或许他们可以给你意想不到的启发。

　　总结:嵌入式调试也是一门艺术。就想其它的艺术一样，如果你想取得成功，你必须具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀，我相信我们在嵌入式测试方面就能够取得成功。

http://hi.baidu.com/yingang2009/blog/item/c6de294eca506d0db3de05f3.html

用简单J2ME程序测试MIDlet生命周期

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:33:01 | 相关网摘，我也收藏

在MIDle程序学习中，生命周期是一个比较抽象的概念。其实生命周期就是一个简单的规定，规定了MIDle中的每个方法，什么时候被系统调用。

　　下面是一个示例代码，在每个方法的内部都输出一条语句，可以根据程序的输出结果来验证各方法被调用的顺序，具体代码如下：


//文件名：LifeCircleMIDlet.java
import javax.microedition.midlet.*;
/**
* 测试MIDle的生命周期
*/
public class LifeCircleMIDlet extends MIDlet{
/**
* 默认构造方法
*/
public LifeCircleMIDlet(){
System.out.println("默认构造方法");
}
/**
* 启动方法
*/
public void startApp(){
System.out.println("startApp方法");
}
/**
* 暂停方法
*/
public void pauseApp(){
System.out.println("pauseApp方法");
}
/**
* 销毁方法
* @param b
*/
public void destroyApp(boolean b){
System.out.println("destroyApp方法");
}
}
　　在J2WTK中运行该程序时，可以使用浏览器中的“MIDle”菜单中的暂停和恢复菜单，模拟暂停事件。

http://www.51testing.com/?action_viewnews_itemid_76706.html

UI-可用性测试的价值和实施

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:32:40 | 相关网摘，我也收藏

可用性测试的定义

　　可用性测试是指在设计过程中被用来改善易用性的一系列方法。我们为用户提供一系列操作场景和任务让他们去完成，这些场景和任务与您的产品或服务密切相关。通过观察，我们来发现过程中出现了什么问题、用户喜欢或不喜欢哪些功能和操作方式，原因是什么。针对问题所在，我们会提出改进的建议。

可用性测试的价值

　　可用性测试的价值在于及早发现您的产品或服务中将会出现的用户使用的问题，在产品开发或正式投产之前给出改进建议，以较小的投入帮助您全面改善产品，节约开发成本。

可用性测试的开展时间

　取决于产品设计进行程度

可用性测试的方法

　　1 、一对一用户测试： 一个可用性测试部分包括测试人员（主持人 / 助理）和一个目标用户，这个目标用户会在测试人员的陪同下完成一系列的典型任务。征得参与者的同意后测试过程将被摄像，测试人员将持续观察、了解用户的操作过程、思维过程以及相关各项指标（包括用户出错次数、完成任务的时间等），记录用户遇到的可用性问题并分析。

　　2 、启发式评估（ Heuristics Evaluation ）： 我们邀请 5-8 名用户作为评估人员来评价产品使用中的人机交互状况，发现问题，并根据可用性设计原则提出改进方案。

　　启发式评估法（ Heuristic Evaluation ）是一种用来发现用户界面设计中的可用性问题从而使这些问题作为再设计过程中的一部分被重视的内容可用性检查方法。
启发式评估法旨在利用已确立的可用性原则来解释每个发现的可用性问题，所以要根据由已经被违背的、好的交互系统需具备的原则所规定的设计准则来制定一个修正的设计方案是相当容易的。

　　根据 Nielsen （ 1994 ）的研究发现，一般情况下， 5 个评估人员能够发现 75% 的可用性问题，从可用性问题产出的市场价值与评估费用的比率来看，是较为理想的数字。

　　3 、焦点小组： 由 6-12 人所组成的富有创造力的小群体，在一名主持人的引导下对某一主题或观念进行讨论。藉由参与者之间的互动来激发想法和思考，从而使讨论更加深入、完整。在可用性测试中，焦点小组可用于对已有原型的比较、修改建议的讨论。

可用性测试的纬度

　　典型的可用性测试会包含以下纬度：任务操作的成功率、任务操作效率、任务操作前的用户期待、任务操作后的用户评价、用户满意度、各任务出错率、二次操作成功率、二次识别率用户操作过程中各认知纬度（视产品情况而定）等。

可用性测试花费的时间

　　典型的可用性测试，需要 2 周的前期沟通和准备， 1 个星期测试， 2 个星期提交分析报告。根据测试的内容及项目规模作调整。

可用性测试的文档

　用户甄别文档 (user screener)
　日程安排文档 (testing schedule)
　用户背景资料文档 (user profile)
　用户协议 (user concert form & DNA)
　测试脚本 (script)
　测试前问卷 (pre-test questionnaire)
　测试后问卷 (post-test questionnaire)
　任务卡片 (task card)
　测试过程检查文档 (checklist)
　过程记录文档 (logging sheet)
　测试报告 (report)
　影音资料 (DVD)

http://www.51testing.com/?action_viewnews_itemid_76709.html

CMM实施的案例分析

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:32:18 | 相关网摘，我也收藏

案例1:

　　V公司和竞争对手相比，在技术上并不占有优势，于是V公司采用了“快速响应”的策略。无论是面对瞬息的市场，还是多变的用户需求。V公司总能够抢先于竞争对手推出产品，为此受到了市场的肯定。但是V公司在实施CMM的时候，却错误地选择了“瀑布式”的开发模型，加上相对复杂的实施流程，如果研发体系严格按照要求去做，那么对市场的响应速度必然大大降低，企业的核心竞争力受到威胁。但是如果H公司坚定“快速响应”的策略，现有CMM的实施就无法有效进行。V 企业走入两难的境地。

　　V企业实施CMM并没有错，错的是他们在实施CMM的时候并没有考虑到企业的核心竞争力和总体战略，采用了错误的生命周期模型和相对复杂的实施流程，最后导致了这样的结果。

　　对公司的战略影响是一个方面，另外一个方面是，CMM的实施涉及到机构的重组，如果我们不能在组织架构，薪酬待遇，绩效考核等方面辅助以适当的政策的话，CMM的实施不可能顺利进行。

　　案例2:

　　W公司为了推行CMM，组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传，认为其对于CMM的推行和项目管理都具有重要作用，但是实际上QA人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不认账，认为 QA人员是没事找事。另外，QA这个岗位在薪酬和升迁方面毫不吸引人。

　　为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经理设法推行项目经理锻炼制度，让项目经理到QA部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持，项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。QA部门在W公司的威望江河日下。

　　QA人员对于质量保证和CMM的实施至关重要，如果我们认可QA人员对于公司的价值，那就必须在人才和待遇上向QA部门倾斜。

　　案例3:

　　S公司在推行CMM 2级的时候遇到了极大的阻力，项目经理对估计和计划过程根本不感兴趣。其原因在于S公司有“倒排计划”的习惯做法。

　　项目经理对项目的进度安排没有决定权，当项目经理接受任务的时候，项目的发布日期早已确定，而且项目经理做出的人力资源请求一般也不会得到满足，项目经理被迫在一个资源短缺的环境下开展工作。既然Deadline已经确定，增加人手又不可能，项目经理怎么会对估计和计划有兴趣呢?

　　与此相对应，S公司的内部宣传材料在不断地表彰在资源短缺的困难情形下做出成绩的经理和开发人员，对“无原则服从命令”行为的赞许，已经成为了公司文化根深蒂固的一部分，并且得到管理层的默许和鼓励。

　　S公司的文化和CMM的要求是抵触的。CMM要求项目经理对任务的合理性进行分析，要求在理性的基础上做出判断，而不是盲目地服从。如果S公司不能够改变他们的文化，CMM就不能够得到有效实施。

案例4:

　　A公司是一个小型公司，但却采用了一个步骤繁琐的CMM实施方案，而且没有采用任何自动化的过程工具，大部分由纸面文件传递来进行。比如在测试中如果发现了一个问题，必须由测试人员找到文件模版，填写好缺陷的种类和描述，打印出来，交给相关人员签字，开发人员的修改结果就只好填写在纸面上，最后还要找项目经理签字。相关人员浪费在文件传递上的时间可能比进行开发和测试的时间还要长。

　　以CMM为模型制订管理框架，其本质是为了规范管理，减少错误的发生。而执行这些管理规程，就其本身而言，并不是我们的目的，而仅仅是一种手段。对这些规程的执行也不创造任何价值。在条件许可的情况下，我们要尽可能地简化手续，提高效率。并适当地引入自动化工具。像A公司的情况，用一个缺陷追踪工具就可以大幅度地提高效率。

　　案例5:

　　H公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的CMM5级公司。这些手段Z公司都没有采用，但是Z公司却抢在了前面。

　　Z公司的“秘密武器”是一种形式化语言—SDL，Z公司采用SDL作为设计工具，这样C产品的相当一部分代码可以由SDL工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。H公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是质量， H公司都落后了。

　　H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM高级别的评估，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于CMM的组织机构忘记了先进的软件工程技术的重要性。

　　案例6:

　　H公司的B项目是一个庞大的项目组，技术相当复杂。名词术语很多，而且对于同一件事物的表达方式也不尽相同。项目组非常有必要制定一个规范的术语表，既统一了说法，也方便项目组的新人查阅。但是事情的发展是很有戏剧性的。

　　项目组在起初并没有重视术语表的编制，因为人少，产生的文档也不多，所以这件事情无人重视。但是到了项目进展了1/3左右，术语的混乱已经相当严重的时候。B项目组的一个工程师X自发地开发了一个小程序，用于查阅术语的名称和缩写。项目经理对X工程师的做法提出了表扬，并委任X开发和维护这个标准术语表。

　　项目经理和相关部门的始终没有意识到：(1)开发和维护这样的标准术语表是项目经理和配置管理人员的职责，不是某一个软件工程师的任务。(2)类似的问题在别的项目组一定出现过，以后的项目组一定也会遇到，必须在开发规范上堵住这个漏洞，让别的项目不会重蹈覆辙。

　　所谓的“管理无大事”，过程管理的真谛就在于这些看似细节的小事。基本的过程管理原则和规范只是“骨架”，而“血肉”是要靠这些看似细枝末节的小事来丰满的。积沙成塔，集腋成裘，点滴持续地改进，其效果最终是巨大的。

http://www.51testing.com/?action_viewnews_itemid_76789.html

成功的测试工程师就得多思考

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:32:10 | 相关网摘，我也收藏

最近在做一个机票的电子购票时,突然想到了这么个问题------在测试的过程中对某个功能想得越开,测试就完整,就越彻底!

当然我们在产生与该功能相关的想象时,其中最关键的是不能脱离需求,不能脱离该软件本身;不然这样的测试就适得其反了.

我们在测试某个功能时,1:想到在该软件中与该功能相关的功能;2:想到在该软件中与该功能相似的功能;3:站在客户或者用户的角度想,自己会用的很舒服吗?习惯大多数人的使用吗?如果在该功能上添加某个细节会让客户或者用户使用的更顺手.可以给项目经理和做需求的讨论,以便确定(切记:不要私自做主);4:与自己曾做过软件中有该功能或者网上类似的功能做对比,看怎样更适合使用(前提是不脱离需求);5:产生下联想下,如果该项目有2期或者后续的话,还应该考虑该功能的可延伸性,以便为后来做准备(我以前做过一个项目外网和内网都是同一组开发人员做的,但是统一个功能却不能相互导数据~~气愤呀)

想是不犯法的,只要不乱想! 所以一名好的测试工程师,他/她的思维一定是很活跃的很会联系其他东西的

http://www.51testing.com/?action_viewnews_itemid_76782.html

如何从测试角度量化评估软件质量

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:32:01 | 相关网摘，我也收藏

软件质量的量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。

　　下面我主要从bug统计来说一下我的经验。

　　1 测试项目数和摘出bug数预测

　　一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的bug数目和需要的测试项目。现在有些公司流行每千行bug数的标准来制定测试计划，这个标准是通过以往测试经验总结出来的，

　　一般来说，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。

　　2 测试bug分级

　　使用bugzilla或者Jira之类的缺陷管理系统何以很容易的实现bug分级，一般至少有Fatal, Major, Minor, cosmatic这几种，还有一种特殊的叫做blocker，意思是这个bug会影响测试进度。产品发布前，可以根据实际情况，定一个界限级别，比如要求新出Major为0，并且所有已有的Major全部close。

　　3 测试bug收敛

　　量化评估必不可少的是bug收敛，这个要通过统计每日新出bug并跟踪已有bug制作收敛曲线来实现。收敛曲线的形状发散表明目前产品极其不稳定，收敛曲线开始收敛表示目前产品趋于稳定，完全收敛之后可以认为是发布的时机。

　　4 测试bug分布

　　bug分布是决定下面测试重点的一个重要的参考数据。首先还是需要统计，找出所有已有的不同级别的bug在各个模块的分布，假如ABC三个模块，A模块占了bug的60%，C模块占了bug的8%那么，我们可以得出这样的结论，软件的不稳定瓶颈在于A模块，是一个薄弱点，需要开发人员集中力量对应。但是C模块也是一个可疑模块，因为出现bug率太低，如果不是开发的太好就是测试方法不当。

　　5 测试bug的周期

　　一个bug的生命历程是一个完整的轮回，从他出生(open)开始，到调查(Accept)到修复(Fix)，再到确认(Verify)是最简单的路线，这个周期越短，说明项目进展越顺利反之则意味着项目进度目前有很大的阻碍。

　　6 降级bug数

　　降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug又作了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。一个新的QA团队，在2，3，4，5，6步骤可能会有所迷惑，不知道阈值应该怎样选但如果每次都坚持这样做，很多次之后2，3，4，5，6会给这个团队大量的经验积累，完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。

http://www.51testing.com/?action_viewnews_itemid_76786.html

性能测试模型分析及建立

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:31:50 | 相关网摘，我也收藏

对于应用系统的性能测试，测试模型的建立至关重要，性能测试模型要以实际生产环境为标准搭建，只有模型符合实际的生产环境，性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。根据长期测试关键核心业务系统的经验，应用系统系统的性能测试模型分析应当按照下面几个步骤来实施：

　　业务模型建立

　　全面分析应用系统系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台批处理业务的数据规模和类别等。最终目的是建立一个能够逼真模拟应用系统系统实际运行场景的业务模型。

　　测试数据模型建立

　　根据业务模型准备测试数据和基础数据，确保系统数据库中数据容量和真实性符合实际运行情况。

　　监控模型建立

　　性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据。

　　测试模型建立

　　对应用系统系统的测试，因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。

　　执行模型建立

　　应用系统系统的性能测试必须要局方客户、系统开发商、第三方测试服务商紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。

　　风险模型建立

　　由于性能测试的特殊性，因此在整个测试过程中，会遇到很多导致整个性能测试失败的风险。丰富性能测试经验是必须的，能够提前分析可能遇到的各种风险并制定相应的规避措施。这样才能将性能测试的风险降到最低，最终圆满完成应用系统系统的上线性能验收测试。

　　上面的步骤或者说方面只是性能测试项目实施中要完成的工作方面的的概述，不同的项目可能有不同的实施方法或步骤要视项目而具体实现。要完成一个有效的应用系统的性能测试，从需求调研到测试分析的各个阶段，有很多工作需要完成，在以后的文章中，会对性能测试项目的分阶段工作进行讲解，适当的时侯会搭配一些项目实施的例子来进行讲解。

http://www.51testing.com/?action_viewnews_itemid_76785.html

一个TD测试工程师的独白

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:31:40 | 相关网摘，我也收藏

我是某公司的一位终端测试工程师，公司刚成立的时候我就加盟了，主要负责该公司的TD网络优化、系统测试、版本发布等。这5年一路走来，真可谓是尝遍酸甜苦辣，套用一句歌词那真是“把悲伤留给自己，美丽让你带走!”现在社会上一些不负责任的媒体整天瞎忽悠TD,一些所谓的专家也跟着掺合，搞的一些人对TD很有看法，作为TD的一个“老兵”，我今儿讲讲自己的故事，也算给大家一个交代，还TD一个清白。

　　2002年的时候，我当时在新加坡搞计算机通信，听说国内要搞3G就动了回国的念头。这之前我在华为做过GSM系统开发，那是97年左右的事情，当时GSM技术完全垄断在国外巨头手中，我们做技术开发，简直是一穷二白，关键是别人已经有成功的系统，这就给让我们的压力特别大，这样做了2、3年 ，还是看不到希望。我就失去了信心，就离开了华为，现在看来，当时要在坚持一些时间就好了，看看华为现在做的多好啊!

http://www.51testing.com/?action_viewnews_itemid_76626.html

测试分析和设计：黑盒测试类型

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:31:31 | 相关网摘，我也收藏

我们经常看到一些词汇，比如Ad Hoc testing, Exploratory testing等。书中给了一些解释。我也结合写一下我的理解。

1．Ad hoc testing
ad hoc 查英文字典的意思是“特别”的意思。Ad hoc testing表示的是一种没有系统规划的机遇测试人员经验的测试方法。其实做ad hoc testing非常好的人一定是对测试非常有sense或者非常有经验的人。他在脑中应用着一些技术（边界值分析，等价类划分，错误猜想），也有一些以前测试的经验，可以快速的找到重要的程序的Bug。对于一个项目而言，ad hoc可以作为系统的方法补助，但是却不能作为替代。Ad hoc应用时可以做以下这些：
1)将ad hoc testing中发现bug的test case加到test case系统中
2)测试结束后总结为什么系统的方法和process漏掉了ad hoc的发现的bug，而对process做提高
3)保持项目中有小比例的ad hoc的存在，这样可以打破惯性思维并且让大家有时候感觉发现bug也是一种游戏

2．Exploratory testing
不同于Ad hoc testing，Exploratory testing不是完全没有规划的。它是一种测试设计和执行同时进行的测试方法。比如测试计算器这个程序。我可以利用经验进行测试，然后将测试的内容记录下来。对于发现大量bug的功能，我可以先重点测试。Exploratory testing好处就在于利用经验发现最需要被测试的模块，将系统的最重要的风险提早释放。而且这些测试过的部分都是记录在案以后可以回归测试。

3．Random testing
随即测试被称为Monkey testing，就像一只手随便的摆弄敲打键盘。我觉得这种测试运用最多的领域在安全性和crash的测试中。

总结下来，我觉得如果对于一个项目而言，
1．主要还是应用系统话的测试方法，计划，规划设计，执行
2．Ad hoc testing可以在一个小阶段进行执行，比如项目到某个阶段有个找Bug 大会，大家都可以来找bug
3．Exploratory testing 可以应用在比如人力资源突然不够，项目进度不变的情况下，采用这个轻量级的方式
4．对于安全性和稳定性，可以用automation的方式运行部分的Random testing

http://www.51testing.com/?action_viewnews_itemid_77191.html

黑盒测试技术之等价类划分

haiwuyan2收录，使用标签：软件测试，时间：2008-3-15 8:31:09 | 相关网摘，我也收藏

黑盒测试有多种技术，在不同的场景情况下可以结合使用。主要有等价类划分，边界值，判定表，状态迁移图，正交试验法等。当然这些技术在白盒测试中也可以用，它们只是技术，而白盒黑盒测试只是测试方式。今天先讨论等价类划分。

等价类划分的目的就是为了在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果。有有效等价类盒无效等价类。有效等价类中的数据代表的是一组符合需求文档的正确的有意义数据。无效等价类则正相反。我们来看几个例子来理解怎样划分等价类（注意我不会用书中的例子，而是举实际我们遇到的一些软件或者网页上的例子）

a) 一个取值范围的情况 （1个有效等价，2个无效等价）

大家看到密码输入框的限制是密码长度>=4。但是其实还是有个隐含的条件。也就是密码字段在数据库中的限制，当然可以用varchar，但是一般用固定长的字符类型的，比如20。所以有效等价类：密码长度大于等于4小于等于20。无效等价类密码长度小于4或者大于20。所以我们从有效等价类中挑选长度为4的密码形成一个test case。从无效等价类中挑选3，21作为2个test case。（注：也许大家想加入20这个case，但是这个是边界值分析考虑的事情了）

b) 布尔型取值（1个有效等价，1个无效等价）

对于验证码我们很熟悉了，其实是一种布尔型取值。True或者False。这里就是一个有效等价类和一个无效等价类。4828和4827分别作为test case

c) 独立的N种取值（n个有效等价，1个无效等价）


这个是windows中Notepad的选择字体的对话框，其中Font style。可以选择Regular, Italic, Bold, Bold Italic。注意他们可能都是独立的。（注意我这里用独立是因为没有需求文档，我不清楚bold Italic是否是独立的，暂且算作独立）。那么有效等价类是4个，无效等价类是1个，既是非这些里面的取值。

d）等价类的划分可能是渐进的。

比如初一看两个1个有效等价类既是有效的email和1个无效等价类一个无效的email。但是如果有更多的要求。比如注册过的email是不允许的，那么无效等价类变为2个。

http://www.51testing.com/?action_viewnews_itemid_77192.html