第一节 尽早的让测试人员参与的项目中
1.在项目生命周期的一开始(需求阶段)就让测试人员参与进来，我们可以得到如下好处：
(1)测试人员可以帮助查找需求中忽略的一些细节，语义不清的内容，前后不一致的地方
以及其它可能影响项目需求可测试性，正确性及其它一些质量问题。
(2)在帮助提高需求质量的同时，测试人员能更好的理解需求
2.Bug发现的越早，修改这个Bug的成本越低。
第二节 验证需求
1.在项目一开始时就定义需求开发和文档的准则
2.需求包手功能性需求和非功能性需求。 非功能性需求有：安全性，性能，易用性，可用性(针对色盲等残障人士)。
3.需求CheckList:
a.正确性：需求是否正确反应了客户的要求，是不是客户想要的。
b.完整性：测试人员应坚持要求：与功能需求相关联的非功能需求也应在需求中描述出来。
c.一致性
d.可测试性(可校检性)：针对每条需求都可以写一个有预期结果且可以对结果进行检验的测试用例
e.可行性：判断需求能否在规定的预算、项目周期及现有技术基础上完成。
f.必要性：判断是否每条需求都和系统功能有关。
g.优化
h.明确性:需求是以准确且可测量的方法陈述的。
i.可追溯性:当需求发生变更时可以找出所有受它影响的需求。
第三节 需求完成后即刻开始设计测试程序
1.需求是否完成的一个重要检查指标：能否根据需求写出测试用例。
2.需求完成后测试人员应即刻根据需求选用适当的测试方法，有必要的话可以选择适当的自动测试工具或自已开发自动化测试工具
第四节 保证需求变更是经过沟通的
1.需求的变动会引起一系列变动，从设计，代码，到测试 可能都会发生变化。
2.建立需求变更流程,成立CCB Change Control Board
3.CCB 职责：
CCB由产品管理人员，需求管理人员，QA，测试管理人员，配置管理人员等组成
CCB负责分析需求变更的有效性，影响，必要性，风险，优先级等。
第五节 基于已有的程序进行开发和测试
1.选择一个固定的版本做为基版本进行开发
2.完善现有程序的需求。
3.记录对现有程序的更新
4.执行有效的开发流程
第二章 测试计划
有效的测试计划是好的测试过程的奠基石。
第六节 理解手头上的测试任务及相关的测试目标
1.代码评审、检查及软件流程都能增强软件的质量，但测试可以被认为是给软件质量把关的最后一关。
2.测试计划的第一步是：理解手头上的任务，其中包括它的范围及测试目标。
3.如何做好测试计划：对系统要先有一个全面的了解,尽早的参与到项目中、了解公司的开发流程。
第七节 考虑风险
1.如果一个程序，其中75%的功能可以通过GUI测试完成，剩下25%的功能可通过对低层的测试完成。
那么75%功能没有必要再在底层进行测试。
第八节 基于功能有优先次序的计划做测试
1.测试应基于优先级、风险、软件开发周期。避免在近期版本中没有的功能上花费时间去开发测试用例。
第九节 时刻记住软件中的问题
1.Beta 版本。 开发人员有可能在Beta上新加一些功能，而这些功能可能不被自动化测试工具所支持。
2.新的和边缘技术。新的技术的加入可能会导致部分代码重构，这时原来的自动化测试脚本也需要做更改。
3.阶段式开发。在最初阶段程序支持输入并存储数据但是不支持显示存储的数据，这时就需要测试程序用其它的用法来检验数据。
4.Bug。在开发初期常会有些bug 阻碍测试继续进行，这时需要有效地与开发人员沟通尽早解决这些bug
5.补丁。补丁程序。检查补丁程序是否会对现有功能造成影响
第十节 获取有效的测试数据
1.边界值
2.尽早准备测试数据
第十一节 准备测试环境
1.测试环境不同于产品环境，搭建产品环境是很昂贵的。因此人们常用测试环境代替产品环境。
2.测试环境要能够代表典型的产品环境。
第十二节 估计测试准备和执行时间
1.开发比率方法是最长用的方法。测试人员的数目＝开发人员的数目乘以一个系数。
第三章 测试团队
第十三节 规划角色和职责
1.仅仅Bug数量来衡量一个Tester的好坏是不全面的， 除了bug数量还要将工作量，工作难度，时间限制，工作中的职责及经难考虑进来
要多方面结合，从一个整体的角度去评量一个Tester的好坏。
2.职责的划分： 测试经理，测试Lead,手动测试人员，自动测试人员，安全测试人员，网络测试人员，性能测试人员等。
第十四节 测试团队的组合人员组成
1.测试团队中就有 业务专家 技术专家 高级测试人员 一般测试人员
2.高级测试人员通过培训一般测试人员来提供整个团队的测试能力。除此之外，他主要负责重要功能的测试。
一般测试人员负责 普通功能的测试。-
总结bug bug分级如何分的
第十五节 评论测试人员的工作效率
1.检查测试人员能否按计划完成工作内容
2.测试人员对细节的关注能力
第四章 系统架构
第十六节 理解系统架构和系统的组成(component)
1.测试人员理解系统的架构对测试有以下好处
(1)提高测试报告的质量。可以帮助测试人员定位Bug的由哪个component引起的，将此内容写在报告中有益于开发人员快速解决bug。
(2)增强探索性测试的能力。测试人员在发现bug时往往会针对发现bug的地方做更详细的测试发现更多的bug。
对系统各component有深入的了解，针对发现bug的地方，测试人员能组织更有效和准确的数据进行测试。
(3)提高测试的准确性。
第十七节 检验系统对可测试性的支持
1.测试人员应参予到架构设计的review，并且研究架构的可测试性。
第十八节 用Log增强系统的可测试性
1.Log可以帮助测试人员和开发人员快速定位Bug的出处。
第十九节 Debug和Release模式
1.开发人员用Debug Build. 测试人员用Release Build做测试
2.Log应分级在Debug和Release中输出不同的信息。Debug中的Log信息更全面一些，在Release中只把错误写到Log中。
第五章 测试设计和文档
第二十节 分解然后征服
测试任务可以分解成以下几部分：
1.What 要测的是什么？ 即哪些需要测试，哪些不需测
2.When 什么时候开发测试程序和用例。 如果项目周期很短，可以用风险评估来找出高先级的测试程序。 先开发优先级高的测试用例和测试程序
3.How 如何进行测试，用什么方法。 通常针对不同的模块所采用的测试手段也不同。
4.Who 谁来开发测试程序。
第二十一节 要求用一致的测试模版和其它的测试测试标准
1.从项目一开始就把非功能性测试考虑进来。包括：安全性，性能，易用性，兼容性，可扩展性。
第二十二节 从需求获得有效的测试用例
1.设计有效的测试用例 要求测试人员深入理解系统的变化，flow,和各种场景
第二十三节 把测试程序当做“活”文档
1.项目的开发往往是迭完递增的，设计进常会发生变化，这时测试程序也需要做相应的变化。
第二十四节 利用系统的设计和原型
1.设计和原型有利于我们精化测试程序。
第二十五节 用经过验证的测试方法去设计测试用例
1.结合多种测试方法来设计测试用例
第二十六节 避免在测试程序中加入限制和具体的数据
1.把测试程序和测试数据分离开
2.在测试中避用定值，尽量用变量，这样可以提高测试程序的复用性。
第二十七节 探索性测试
1.在需求文档不全时我们要进行探索性测试，找出bug集中的模块。
第六章 单元测试
第二十八节 结构化开发方法以支持有效的单元测试
1.良好的设计，如分层设计有利于单元测试的进行。
2.单元测试时，有时还需要用内存检查工具查看是否有内存泄露
第二十九节 在开发代码前或中开发单元测试
1.单元测试可以检验开发人员对需求的理解。
第三十节 使单元测试执行成为编译过程的一部分
1.在编译时对模块进行单元测试。
通常大的软件编译需要很长时间，若编译完后发现原有的功能出现了问题，那么可能几天的编译的时间就浪费了。
为了解决这一问题 我们可以在编译完某个模块时立记刻执行自动化单元测试，若测试通过则继续编译其它模块。
这样做不但可以尽早发现问题，也节省了不必要的编译时间的浪费。
2.在编译时加入自动化单元测试，可以保证编译后的软件一直处于可测试的状态。(单元测试通过才值得进行软件测试)。
第七章 自动化测试工具
第三十一节 了解不同的测试支持工具
1.了解市面上不同测试工具的用途。
2.根据顶目的需要选择适当的自动化测试工具。
第三十二节 考虑研发测试工具而不是购买测试工具
1.在开发测试工具时可以考虑利用现有的开源的工具 如: DejaGNU, TETware, xUnit 和微软的网页测试工具 WAST
第三十三节 了解自动化测试工具对测试的影响
1.往往一个测试工具是不能满足项目的所有需要，要多个测试工具一起用。如 RPF 和 META。
2.测试工具并不会减少测试的工作量
3.评估测试工具时除了要考虑培训的费用和维护测试工具的费用。
4.并不是所有的用例都需要做成自动化。
第三十四节 关注公司的需求
1.没有一种工具适合所有的测试要求，每种工具都有它的适用性和不适用性。
第三十五节 用开发程序的原型来测试工具的可用性
1.在已开发好的程序上对测试工具进行可用性评估是最好的方法。
若有程序还没开发来，可以要求dev提供一个原型，在原型上测试工具的可用性。
2.GUI测试工具都有兼容性问题，可能识别不了GUI上的日历，表格等Active-X第三方控件
第八章 自动化测试的最优方法
最好的自动化测试的方法是把自动化测试当成一个软件开发项目。
第三十六节 不要仅靠回放和播放工具
1.结合黑盒，白盒，灰盒测试才是最有效的测试方法。
2.回放和播放类自动测试工具的缺点
脚本中的数据值是定值，容易产生扩展和维护上的问题。
脚本非模块化，难于维护。
脚本难复用。
3.应将脚本模块化，将指定有利于脚本复用的开发方针
第三十七节 当需要时开发一个测试挽具
1.把Test Cases抽象出来，写一个Test Harness,由它来执行Test cases. Test hardness 再调用Test adapter来执行Test cases
根据不同的系统写不同的Test adapter 从而复用Test cases
第三十八节 利用已有的脚本开发技巧
1.尽可能的从外部资源去读取测试所需要数据，如：把测试数据放到文件或数据中，而不是在测试脚本中写死
2.在做GUI自动测试时尽量用控件的Winodws Object name去找控件，而不是用Position去找控件
第三十九节 尽量自动化回归测试
1.何时做回归测试？ 当对加入新功能时或修改原先存在的bug的时候需要做回归测试,以保证原有功能不会受到影响。
2.回归测试的内容有哪些？ 回归测试的内容应包括：高风险的功能模块、常用的执行路径和代码修改后受影响的模块。
3.开发人员人员应给回归测试提供以下内容：在修改bug时和开发新功能时有哪些现有模块会受到影响，以便Tester更好的做回归测试。
4.在迭代开发的过程中，回归测试的内容也应随之迭代增加。
5.若需求经常发生变化，那么回归测试的效果会很差，除非回归测试的内容也随需求的变化而变化。
所以应确保用于回归测试的系统应是相对稳定的，不会经常有变化。
第四十节 开发自动化build和冒烟测试
1.冒烟测试用于测试系统的最主要的功能，它就是MS的BVT，只有BVT过了的build才能用于测试。
第九章 非功能性测试
兼容性，安全性，性能，易用性
第四十一节 不要把非功能性测试放在后面
1.如果在项目初期有把非功能性需求考虑进来，在后期加入非功能性需求时将很难完成或需要很高的成本才能实现非功能需求。
2.在需求阶段，如果在功能需求上标明非功能性需求，Test Team将会从中受益
3.设定全局的非功能性需求，可以防止在所有的文档中都重复说明非功能性需求。
4.非功能性需求的种类：
全局性非功能性需求 如兼容性
局部性非功能有需求 针对某个功能的非功能性需求
第四十二节 用产品大小的数据库去做性能测试
1.用不同的数据量去做性能测试并记录测试的结果，并分析结果得到性能的上界。
第四十三节 易用性测试
1.可以根据其它同类产品的做法来提高软件的易用性
2.观察用户的操作 想办法提高易用性。
第四十四节 考虑到安全的所有方面
1.Quality Web Systems ---Elfriede Dustin
2.SSL Secure Socket Layer 给socket的数据包加密
3.可以将安全测试外包给专注于安全测试的公司
第四十五节 调研产品的代码并据此设计并发测试
1.在做并发测试之前一定要了解系统的设计及系统所用的并发模式
2.在多用户的系统中并发测试很重要
3.并发模式：
悲观锁 适用情况：当经常会有许多用户修改同一数据时。
对于任何可以修改的数据，在未给数据加锁时所有的用户都可以读取该数据。
当用户想修改该数据时需请求锁，且只有允许一个用户持有锁，其它请求锁的用户必须等待，且任何其它用户看不到数据的内容。
缺点：当有一个用户数据时其它用户无法取得数据的内容
乐观 适用情况：用户不会经常同时对同一数据进行操作时。
用户在任何情况下都可以访问或更新数据。在更新数据时若之前已有更新的操作，用户的更新会失败，并提示更新失败。
缺点：当用户更新数据时可能会失败，浪费了用户的时间。
无并发控制(last one win)
在非并发操作中，后面的更新操作，会覆盖前面的更新操作的内容。
缺点： 若两用户同时进行更新操作，有可能会导致数据损坏。
第四十六节 为兼容性测试建立有效的测试环境
1.不在在兼容测试环境中安装开发环境，它有可能会污染测试环境
2.把精力集中在用户常用的环境下做兼容测试(软硬件)，在其它不常用的环境，如win98中只做些基本功能的测试。
第十章 管理测试执行
第四十七节 清楚的定义测试开始和完毕的周期
1.测试开始的标准：
代码受版本控制软件控制，build和compile没有问题，build有相应的release notes.
通过了冒烟测试，通过了单元和集成测试
2.测试结束的标准
执行了所有的测试用例，保证软件满足了功能性和非功能性需求
所有的level 1-2的bug都已解决，90%的level 3的bug 已解决。
产品在发布时可以有一些求解决的低优先级的bug
第四十八节 把测试环境和开发环境隔离开
1.测试需要在稳定的版本上进行，而开发环境上的版本往往是经常变的且是最新的。
在开发环境上做测试无法获得稳定的版本。降低测试的效率，所以要把测试环境和开发环境分开。
第四十九节 执行缺陷追踪周期
1.记录在各各开发时期 bug的数量，对数据进行分析，从而判断未来bug的增长趋势。
第五十节 跟踪测试程序的执行
1.根所Metrics(测试指标)，测试人员可以决定何时必须bug以确保产品质量
还可以预言可以可以发布产品
2.Metrics里应显示的一些基本数据
测试执行率：已执行的test cases数量 / 总的数量
Bug的年龄 ：从一开始发现bug到修改完毕所有的总时长
Bug从fix 到 retest的时长： bug从修改完毕到在新build中发布所有的总时长
Bug趋势分析：在测试过程中发现bug的趋势
若bug成增长趋势，那么可能有以下原因：
对原先bug修改不当
对原先build的测试覆盖率不够
直到某些bug修改前无法执行测试，而那些无法执行的测试用例发现了很多bug.
Bug修改的质量：同样的bug重复出现的次数及修改该bug后引起的新bug的数量
Bug在不同模块的密集成度：
若bug在某块密集成度过高，可能有以下原因：
该模块功能过于复杂
该模块的的设计和开发是不是有问题
是否低估了该模块的复杂度，导致分给该模块的人员数量不够
另外在分析Bug密集度时还要考度到bug的优先级。
浙公网安备 33010602011771号