七、与程序员交互
150，理解程序员怎样思考
· 大多数程序员都很专一
· 程序员关注自己的系统理论
· 程序设计是一种复杂活动
· 程序员常常要与各种困难作斗争
· 很多程序员不喜欢例行工作，常常构建工具和脚本来自动化自己所命名的重复性工作
151，获得程序员的信任
152，提供服务
· 测试第三方组件
· 测试非正式个人版本和原形
· 为程序员建立测试环境以便程序员自己进行测试
· 评审需求文档的可测试性
153，测试员的正直和能力需要尊重
· 要干脆的报告问题
· 将自己的判断建立在产品行为的实际观察基础之上
· 如果失效是不可重现的，要展示为了重现失效做的各种尝试
· 直接报告坏消息
· 不要假装了解自己并不了解的东西
· 不要夸张错误报告，也不要缩小的错误报告，不要受外界压力的诱导
· 如果测试员是正直的，就可以展示自己的能力
154，将关注点放在产品上，而不是人上
155，程序员喜欢谈论自己的工作，应该问他们问题
156，程序员乐于通过可测试器提供帮助
· 用程序员的语言谈话
· 尽早提出要求
· 要现实
八、管理测试项目
157，建设一种服务文化
158，不要尝试建立一种控制文化
159，要发挥耳目的作用
160 ，测试经理管理的是提供测试服务的子项目，不是开发项目
161 ，所有的项目都会演变，管理良好的项目能够很好的演变
162 ，总会有很晚的变更
· 他们不知道自己所有的需求
· 当他们使用软件的早期版本我竞争对手的产品后，其需求会发生变化
· 不同的项目相关人员具有不同的需要，这些需要常常是矛盾的
· 需求是在我们想要和我们能够得到的功能进行不断斗争的结果(Bach 1999a)
163 ，项目涉及功能、可靠性、时间和时间之间的折衷
功能、可靠性、时间、成本
164，让项目经理选择项目生命周期
165 ，瀑布生命周期把可靠性与时间对立起来
166，进化生命周期把功能与时间对立起来
167，愿意在开发初期将资源分配给项目团队
· 评审需求文档的可理解性、可测试性和模糊性
· 随着其他项目工作制品（文档、代码等)的开发，在对他们进行测试
· 推动代码评审
· 拟定硬件配置和准备配置或借用设备的初步清单
· 要求提供可测试性功能
· 讨论代码覆盖率度量使用其他开发支持工具的可能性
· 准备测试自动化
· 研究测试工具
· 如果可能，订购可以用于被测软件的外部开发的测试包
· 了解产品的市场和竞争情况
168 ，合同驱动的开发不同于寻求市场的开发
169，要求可测性功能
170，协商版本开发进度计划
171 ,了解程序员在交付版本之前会做什么
（以及不会做什么)
172 ，为被测版本做好准备
173 ，有时候测试员应该拒绝某个版本
174 ，使用冒烟测试检验版本
175 ，有时正确的决策是停止测试、暂停改错、并重新设计软件
176，根据实际使用的开发实践调整自己的测试过程
177，＂项目文档是一种有趣的幻想：有用，但永远不足＂-Brian Marick
代码中超过80%的代码用于处理错误，实现主要功能的代码不足20%
178，测试员除非要用，否则不要索要
179 ，充分利用其他信息源
· 用户手册查岗（以及以前版本的手册)
· 产品市场开发文献
· 市场开发人员向管理层做的推销产品概念的演讲
· 程序每个新的内部版本所带的软件变更备忘录
· 内部备忘录（例如项目经理对工程师描述的功能定义）
· 已出版的风格指南和的用户界面标准
· 已出版的标准（例如C语言)
· 第三方产品兼容性测试包
180，向项目经理指出配置管理问题
· 有一个测试子项目在四个月时间内发现了几百个程序错误，平均每个程序错误会再次出现2.5次
181 ，程序员就像龙卷风
182，好的测试计划便于后期变更
· 不要再测试之前开发大的测试包
· 不要编写维护成本很高的大量测试文档
· 不要把手工或自动化测试文档的特定的用户界面
· 通过最大化可维护性和跨平台可以移植性来设计自动化测试
· 构建一组能够在不同程序中重复使用的通用测试
· 构建一组很强大的冒烟测试，以快速检测被测程序中的基本失效
· 慎重考虑极限编程
· 开发一种产品用户和用户要通过产品获得效益的模型
· 帮助程序员开发大的单元测试包，以及相对简单功能的其他测试
183，只要交互工作制品，就会出现测试机会
184 ,做多少测试才算够？这方面还没有通用的计算公式
185 ,＂足够测试＂意味着＂有足够的信息可提供客户做出好的决策＂
186，不要只为两轮测试做出预算
187 ，为一组任务确定具体进度计划，估计每个任务所需的时间
188 ，承担工作的人应该告诉测试经理完成的任务需要多长时间
189，在测试员与开发人员之间没有正确的比例
190，调整任务和不能胜任的人员
191，轮换测试员的测试对象
192，尽量成对测试
193，为项目指派一位问题查找高手
194，确定测试的阶段计划，特别是探索式测试的阶段计划
195 ，分阶段测试
196 ，通过活动日志来反映的测试员工作的干扰
197，定期状态报告是一种强有力的工具
· 永远使用中性、客观的语气，不要使用全大写词汇以及幽默
· 对事不对人
· 采用所有的项目都一致的格式
· 按照标准进度计划提交报告
· 仔细的选定状态报告的内容
· 要把状态报告提交给项目团队之外的人看
198，再也没有比副总裁掌握统计数据更危险的了
199，要小心通过程序错误数量度量项目进展
200，使用的覆盖率越独立，了解的信息越多
201，利用综合记分牌产生多个因素一是的状态报告
202，以下是周状态报告的推荐结构
· 第一页：
· 所需的决策（如：需要如何确定这些功能的优先级？测试什么设备？是否吸收新测试小组成员？)
· 所需的程序错误修改
· 预期交付的工作制品
· 意外问题
· 第二页描述项目小组完成计划任务进度的情况
· 第三页提供错误报告统计数据
· 最后一页列出本周被延迟的程序错误
203 ，项目进展表示另一种展示状态的有用的方法
204 ,如果里程碑定义的很好，里程碑报告很有用
205，不要签署批准产品的发布
206 ，不要签字承认产品经过测试达到测试经理的满意程度
207，如果测试经理要报告产品发布报告，应描述测试工作和结果，而不是自己对产品的看法
208，在产品最终发布报告中列出没有排除的程序错误
209 ，有用的发布报告应列出批评者可能指出的10个最糟糕的问题
九、测试小组管理
210 ，平庸是一种保守期望
211 ，要把自己的员工当作执行经理
《有效地执行经理》
212，阅读自己员工完成的错误报告
213 ，像评估执行经理那样评估测试员
· 阅读其错误报告
· 阅读其编写的代码
· 收集其一起工作的程序员和其他有关人员的意见
214，如果测试经理确实想知道实际情况，可以员工一起测试
215，不要指望别人能够高效处理多个项目
216，积累自己员工的专业领域知识
· 阅读类似产品客户的杂志或书籍
· 参加教授客户如何使用类似本公司正在开发产品的学习班
· 参加与产品的下层组织有关的学习呗
· 在客户现场工作
· 推销自己公司或竞争对手的软件
· 每周利用几个小时回答公司技术支持热线电话
217，积累自己员工相关技术方面的专门知识
218，积极提高技能
219，浏览技术支持日志
220，帮助新测试员获得成功
· 为新员工找好办公室或小隔间
· 至少要安排一天的时间让新测试员与有关人员见面
· 为新测试员指派一名指导员
221，让新测试员对照软件核对文档
222，通过正面测试使新测试员熟悉产品
223 ,让测试新手在编写新错误报告之前，先改写老的错误报告
224 ,让新测试员在测试新程序错误之前，先重新测试老程序错误
· 重现现在还没有关闭的程序错误
· 重新测试已经解决的程序错误
· 重新测试已经解决但还没有关闭的程序错误
225，不要派测试新手参加几乎完成的项目
225，员工的士气是一种资产
三分士气一分体力
227，测试经理不要让自己被滥用
228，不要随意让员工加班
229，不要让员工被滥用
230，创造培训机会
· 阅读小组
· 午餐培训会议
· 公司统一安排培训
231，录用决策是最重要的决策
232，在招募期间利用承包人争取回旋余地
233，谨慎把其他小组拒绝的人心拉到测试小组中
234，对测试小组需要承担的任务，以及完成这些任务所需要的技能做出规划
235，测试团队成员要有不同的背景
236，录用其他渠道的应聘者
237，根据大家的意见决定录取
238，录用热爱自己工作的人
239，录用正直的人
240，面谈时，应让应聘者展示期望有的技能
241，在面谈时，请应聘者通过非正式能力测验展示其在工作中运用的能力
242，录用时，要求应聘者提供工作样本
243，一旦拿出主意就迅速录用
244，要将录用承诺形成文字，并遵守诺言
十、软件测试职业发展
245，确定职业发展方向并不懈努力
· 自动化测试程序员
· 自动化测试结构分析员
· 性能和可伸缩性测试员
· 系统分析员
· 用户界面和人员因数分析员和鉴定员
· 测试计划设计员
· 专题测试专家
· 黑盒测试员
管理职位：
· 测试小组组长
· 测试经理
· 测试主任或质量主任
· 内部顾问
· 外部顾问
转岗：
· 程序设计经理或项目经理
· 技术支持经理
· 产品经理
· 文档编写小组经理
过程管理：
· 软件指标专门人员
· 软件过程改进专门人员
246，测试员的收入可以超过程序员的收入
247，可大胆改变职业发展方向并追求其他目标
248，不管选择走哪条路，多要积极追求
249，超出软件测试拓展自己的职业发展方向
250，超出公司拓展自己的职业发展方向
251，参加会议是为了讨论
252，很多公司的问题并不比本公司的问题少
253，如果不喜欢自己的公司，就在找一份不同的工作
254，为寻找新工作做好准备
255，积极并维护希望加入公司的名单
256，积累材料
257，把简历作为推销工具
· 如果有显著不同的工作岗位感兴趣，这个写出不同的简历
· 准备一份历史简历
· 准备一份功能性和关键词简历
· 决不要夸大自己的背景、技能或经验
258，找一位内部推荐人
259，收集薪金数据
260，如果是根据招聘广告应聘，应根据广告要求调整自己的申请
261，充分利用面谈机会
262，了解准备应聘的招聘公司
263，在应聘时询问问题
264，就自己的工作岗位进行谈判
· 知道自己想要什么？
· 知道他们想要什么？
· 知道他们的想法？
· 知道他们作为潜在雇员怎样谈判？
· 知道自己的其他选择，除了这个工作岗位之外的其他工作岗位是什么？
265，留意能力资源部
266，学习Perl语言
267，学习Java或C++
268，下载测试工具的演示版并试运行
269，提高自己的写作技巧
270，提高自己的公众讲话技巧
271，考虑通过认证
272，不要幻想只需两个星期就能够得到黑带柔道段位
273，有关软件工程师认证制度的警告
十一、计划测试策略
274，有关软件策略要问的三个基本问题是：＂为什么担心＂，＂谁关心＂，＂测试多少＂
275，有很多种可能的测试策略
276，实际测试计划是指导测试过程的一套想法
测试计划是指导将要做什么的所有想法
277，所设计的测试计划要符合自己的具体情况
· 开发：产生将要测试的产品的系统
· 需求：成功产品的评判标准
· 测试团队：能够投入该产品的测试人员
· 测试实验室：是测试函电能够完成测试任务的系统、工具和材料
· 任务：测试团队必须要按照客户认可的陈光标准解决的问题
278，利用测试计划描述在测试策略、保障条件和工作产品上所做的选择
279，不要让保障条件和工作产品影响实现测试策略
280，如何利用测试用例
281，测试策略比测试用例重要
282，测试策略要解释测试
· 与具体产品有关
· 关注风险
· 多样化
· 实用
283，应用多样化的折衷手段
284，充分利用强有力测试策略的原始材料
· 测试员运用各种测试手段的技能
· 测试员有关产品内部技术的知识
· 具有特殊测试或工艺技能的朋友
· 原始测试数据库
· 各种测试平台，包括测操作系统与硬件配置
· 各种测试工具
· 实际用户数据
· 植入产品中的可能测试性功能（如日志记录文件、判断和测试菜单）
285，项目的初始测试策略总是错误的
286，在项目的每个阶段，可自问＂我现在可以测试什么，能够怎样测试？＂
287，根据产品的成熟度确定测试策略
· 项目初期，同情的测试
· 项目中期，积极的测试
· 项目末期，多样的测试
· 项目最后，谨慎的测试
288，利用测试分级简化测试复杂性的讨论
0级，冒烟测试
1级，能力测试
2级，函数测试
3级，复合测试
289，测试灰盒
290，再重新利用测试材料使，不要迷信以前的东西
291，两个测试员测试同样内容也许并不是重复劳动
292，设计测试策略时既要考虑产品风险，
· 也要考虑产品要素
· 不要在测试员之间的缝隙中遗漏测试
· 经常测试客户要求测试的内容
· 偶尔测试客户要求不要测试的内容
· 测试不够清晰和矛盾的内容
· 不要痛打落水狗
· 更多变更意味着更多测试
293，把测试周期看作是测试过程的韵律
· 接受产品
· 对测试系统进行配置
· 检验可测试性
· 确定哪些部分是新增加的或经过修改的
· 确定修改了哪些程序错误
· 测试程序错误修改
· 测试新的或经过变更的部分
· 这是其他部分（注意首先测试风险较大的部分)
· 报告测试结果
版权声明：51Testing软件测试网及内容提供者拥有本文全部版权，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
