1.质量是把开发过程和测试放到一起，不分彼此
2.测试工程师把用户放在第一位来思考，要发现糟糕的设计，令人困惑的用户体验，功能bug，安全和隐私等问题的困扰
做好测试需要了解用户，了解他们的期望和需要，还需要了解技术看能否实现用户的需要或者实现用户的需要的代价有多大。了解与之交互的软件。
3.重点要放在用户的使用方式和系统级别的体验上，要发现需求中的模糊之处，分析沟通不准确的问题
4.给一个项目配备多少测试人员，取决于项目风险和投资回报率。风险大意味着在测试上投入的资源也多，但是投入的资源与其潜在的回报成正比。
5.测试的时候先想一下该产品对于用户，对业务的意义是什么？为用户解决了什么问题？
6.要注意产品的特质也就是产品的品质和特色，区别于其他产品的地方，在某种程度上是人们选择你的产品而不是竞争对手的原因
7.测试的时候按照风险等级来看基本上可以分为4种类型
1）罕见：发生bug的可能性非常小，就算有bug修复起来也很容易。 例如：文案，错别字
2）少见：少数情况下才会发生bug，但是用户使用的场景不高或使用率较低。 例如：设置审核流功能，基本上是设置一次，很长时间都不会使用
3）偶尔：发生的bug容易想象，场景有点复杂。 例如：搜索功能，组合搜索功能
4）常见：用户经常使用的，复杂度高的，流程复杂的。 例如：日报
对于常见的风险用户重点关注的，非常容易发现的应该尽可能的设计更多的测试场景针对性的测试，并且一定要保证回归测试的存在。
对于风险较低的，逻辑简单的，可以降低有些要求，合理分配测试时间。
在测试之前一定要确定一系列的功能点，按照风险排序，然后合理的安排测试时间和分配测试资源。
设计测试用例时需要在了解原有的业务知识的情况下，按照需求应用 等价类啊，边界值啊，场景法等设计测试用例。
测试需要测一个新的产品的时候，可以先浏览一下产品，看看产品是由什么组成，怎么工作，然后评估一下产品。
在测试之前心里面大概知道想要得到的产品是什么样的，也就是对产品建模。
当观察到产品的某种行为与需求 某某某 矛盾。或者易用性太差，可以提bug。而不是凭着自己的直觉提bug；
探索测试可以通过前向思索，后向思索，侧向思索的方式来测试
前向测试：根据已知的探索未知的，从所看到的探索还没有看到的，注意支流和副作用。例如：看到打印菜单项，点击一下会发生什么情况。 有可能是让你选择要打印的内容，有可能是提示你没有权限等等。
后向测试：从怀疑或者想象的东西，返回已知的，尝试证实或者否定自己的推测。 例如：可以查看文件，那有没有打印文件的方法呢？？打开菜单看有没有打印的选项。
侧向测试：自己的工作由于新冒出的想法而转移，然后再将探索主题回到主线索上。 例如：看到一张很有意思的图片，那可以打印更复杂的图吗？？
当测试在判断产品是什么而不是什么，产品应该怎么样运行或不应该怎么样运行是可以使用诱导推论
1.收集更多的数据
2.收集更重要的数据
3.收集更可靠的数据
4.理解应用于数据的原因和结果
5.找出数据可以更多，更好的解释，只要找到了某个解释可以说明所有重要数据，并且明显得到比其他解释更好的解释，那么就可以确定这个解释
6.收集更多否定每个解释的数据
7.收集更多区分解释的数据
以下三种猜想并尝试反驳的方法可以应用于测试
1.测试是目的是显示产品是失败的，要比显示产品是正常更有利，寻找方法反驳其正常运行。
2.有关软件已经牢固形成的信念应该受到质疑（比如这个产品如何如何的安全，如何如何的方便）。这样才会用各种方法来把这个信念给超越
3.需要警惕，有人声称运用了各种方法来确认了产品的测试。任何量的测试都不能提供产品质量的确认性。
作为测试，必须认识到谁的关于质量的观点最重要（有些产品会有不同角色的用户使用，他们中某些使用要求甚至是冲突的，矛盾的。因此作为测试必须要认识到 谁的观点最重要）
作为测试既要测试产品文档明确写出来的，也要测试产品没有写出来的隐藏需求。这些隐藏需求可以通过相关产品，同一个产品的老版本，顾客的意见，专业的知识，测试的经验等
测试完毕没有发现bug真正的含义其实是 它看起来在一定程度上满足了部分需求。测试在有限的时间内，不可以做到完全没有bug。
测试至少包含以下四种活动：
。配置：准备要测试的产品，要将其置于正确的初始状态。 否则测试结果会受到不良 变量的影响
。运行：向产品输入数据，向产品发布命令，以某种方式与产品交互。
。观察：收集查看产品有关行为信息，输出数据，系统的整体状态，与其他产品交互等方面信息
。评估：运用规则，推理或可检测所观察到数据中存在问题的机制。
测试复杂产品时：可以先研究复杂的产品30分钟或一小时。然后停下来干点别的。经过几次轮回后，就会明白产品的模式以及轮廓，这样就可以更系统更具体的测试和研究策略
在有限的时间内可以应用以下方法发现更多的问题：
。测试边界【即边界值分析法】：
。测试所有错误信息：错误处理的代码与一般主流代码相比，一般比较弱
。测试与程序员的配置不同的配置：程序员已经配置好的，基本上已经测试过了。
。运行比较难设置的测试：容易配备的测试更有可能被执行过
。避免冗余测试：重复的测试产生的价值很小
很多测试员会发现自己精心测试的产品，换另外一个测试仍然会发现问题，那是因为测试员在测试的时候不可避免的会有有些偏向。
例如：边界经常会测试出问题，可能会忽略用户正常使用方式。有人反馈过问题，会把放在更加重要的位置。
新手测试提高能力的最快方法是：注意其他测试员所发现的自己本来也可以发现，但是却没有发现的问题
如果遗漏一个问题，检查这种遗漏是意外还是测试策略的比如结果。
第一次接触产品或功能时，要注意使自己困惑和烦恼的地方。，可能用户在使用的时候也会有这个烦恼
与团队新成员一起工作时，观察他们在了解 产品时的反应
警惕陷入测试惯例。
测试的时候知道自己想要得到的结果是什么
设计测试用例的时候避免过于详细，要让测试员有创造性和判断力的执行用例。 如 ：测试搜索的时候，要搜索 以权天下，设计模糊搜索的时候，可以直接写模糊搜索而不是 写 输入 以权进行搜索
重新发明东西至少有两个原因：通过改造使其适应新条件，了解其工作原理。而要掌握他，这两个方面都需要。 要想精通测试也要掌握这两点
测试五要素
。测试员：基于人员的测试手段。如用户测试，α测试、β测试
。测试内容：基于覆盖率的测试手段
。风险测试：基于程序功能失效的测试，以及失效造成的风险
。活动：如何测试。例如回归测试，冒烟测试
。评估：怎样判定测试通过还是不通过
常用的测试手段：
1）功能测试：逐个测试每个功能，彻底测试功能，直到确信该功能没有问题。
2）功能集成测试：多个功能组合在一起执行的情况
3）菜单浏览：遍历产品中所有菜单和对话框，使用每个可选项
4）域测试：域是一个（数学）集合，包含所有可能的函数变量取值。在域测试中，要标识函数和变量。变量可以是输入或输出变量。把每个变量都要把其可能取值集合划分为等价类，从中选取代表值进行测试。 请注意哦，与功能测试形成对比的是，我们重点关注的是变量而不是功能。 进行域测试时必须分析变量，然后再根据分析，以这个变量作为输入或输出，测试设计这个变量的每个功能
5）等价类分析：所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。从每一个子集中选取少数具有代表性的数据，从而生成测试用例。等价类又分为有效等价类和无效等价类。有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的，因为被测程序若是正确的，就应该既能接受有效的输入，也能接受无效输入的考验。
6）边界测试：边界值是指对于输入等价类和输出等价类而言稍高于其边界值及稍低于其边界值的一些特定情况。效和无效的分界点，往往是程序的判定点，是程序中最容易出错的地方，也是测试人员重点的测试内容
7）用各种方式映射和测试编辑字段：可以用多种方式改变某个字段中的值。直接输入，复制粘贴，通过各种方式改变字段的值。
8）逻辑测试：变量在程序中有关系，因果图是一种用于设计大量基于逻辑的测试手段。
9）基于状态测试：程序的状态要发生转换。在给定状态中，有些输入是有效的，其他收入被忽略或拒绝。
10）路径测试：一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所有语句。
11）组合测试：相互组合测试两个或很多变量。
基于风险测试：根据程序中，某个功能失效的可能性，以及如果失效确实发生可能造成的损失。 为了发现错误进行风险分析，功能怎么样会失效？什么风险因素导致这个功能失效。
。输入风险：限制程序可以处理的内容的约束。例如，程序只能处理32位数字，则程序应该检测并拒绝超出32位数字限制的输入
。输出风险：输入的合法的但是可能会导致产生程序不能处理的输出值。例如显示图片失败
。计算风险：输入输出没有问题，但是在计算某个值时程序失效。如，将两个很大的数乘在一起，积太大程序不能处理
。存储（或数据）约束：输入输出计算都是合法的，但是操作使程序耗尽内存，或产生的数据文件太大，程序不能处理。
。进行风险测试之前，还必须做相当量的非基于风险的测试。
一致性是评估程序的主要标准
1.与历史一致。现在的功能行为与以前的行为一致。
2.与我们的想像一致。功能行为与机构的项目预期一致。
3．与可比较的产品一致。功能行为与可比较产品的类似功能一致。
4.与所声明的内容一致。功能行为与承诺提供的功能一致。
5.与用户的预期一致。功能行为与我们认为是用户想要的功能一致。
6.产品内部一致。功能行为与产品内部可比较的功能或功能模式的行为一致。
7、与用途一致。功能行为与明确的用途一致。
测试提bug，并不是让所有的bug都得到改正，而是准确的报告问题，使项目组能够理解问题的影响，并加以判断修复的代价。
对于偶现的，极端场景下出现的bug，也要提当开发不愿意修复的时候，应该说明这个bug可能引发的后果。如果改的代价大于造成的影响那也要做个记录。
测试一定要把有争议性，偶现的等等bug都要提出来，因为只有bug才能很好的证明你确实发现了问题并且提出来。
对于其他人【如使用人员】提出来的问题，要反馈
如果产品使用者觉得功能不好，或都某些功能没有而感到失望，作为测试可以记录一下，以作参考
测试要注意产品使用产品的方式，以及喜欢该产品的什么功能，不喜欢该产品的什么功能。
不要要弄bug数量来对测试或者开发进行考核。如果以bug数量考核程序员的话，会浪费大量的沟通时间，程序员会争辩是设计问题而不是程序问题，问题重复了，或者复现不了没有办法等等
如果以bug数量考核测试的话，会造成都去找显而易见的bug，难的复杂的问题没有人管没有人问。把同一个bug的不同实例全部分别提出来。
发现bug一定要及时报告，以免时间长了记不清楚细节
当多人合作的时候，即使的非常明显的bug也要看一下是否有人报告过
测试还需要找出产品设计不合理的地方。
极端的，小缺陷全部都要提出来，无论他改还是不改
要给bug明确严重等级和优先等级，这样开发改的时候，知道那些需要先改，那些需要后改。不要夸大问题的等级也不要缩小问题的等级
发现一个bug后，可以对这个bug进行后续测试，以及对相关的进行测试，这样可以发现更多的bug
对于偶现的bug，也要重视，有可能随着时间的流逝而变得更严重
某些bug可能因为成本的问题，最后不会被解决，这也是正常的。
对于很早之前的bug，最好可以咨询一下之前的开发或测试人员，因为这些bug有可能是 为了避免 其他更严重的bug而不进行修改的
给开发提bug的时候，如果产品文档上面没有写的，不要自己私下定方案要与产品沟通后才可以。
项目有bug很正常，要注意和开发沟通交流的语气，态度。
提bug时，最好能使用图片这样更清晰，也可以使用动态图片这样更清晰。实在不行可以操作给开发看。
开发已解决bug的时候，要及时的验证，如果验证不通过，要及时与开发交流沟通。有的时候可能是 开发代码没有上传等等原因造成没有验证通过的
如果bug被不予解决或者设计如此了，要及时与产品和开发进行交流沟通，如果实在不行要让他们写下理由
测试文档的核心需求：
1.测试文档主要支持我们找出这个产品版本中的程序错误，指派工作和跟踪工作状态
2.测试文档为新测试小组成员提供培训材料，让新成员快速的了解产品
作为一个测试，自己有一个很重要的部分就是让自己或者自己的下属，不被项目经理或产品或其他人员滥用
在整个项目的过程中，要时刻对整个计划的大小细化或者更正。项目是一组任务并且是多人合作的，随着时间的推移，项目团队会发现有些任务比预期的要困难，或要花费更长的时间
或关键任务调离，或项目要求必须提前完成。
总会有很晚的变更，因为有些用户以前没有使用这种产品，或者他们对自己想要的东西有很好的想法，也不知道如何确切的描述自己的需求，主要是因为
1.他们不知道自己的所有需求
2.当他们试用过类似的产品后，会要求更改需求
3.不同的项目相关人员具有不同的需求，有时候这些需求常常是自相矛盾的，没有一份文档可以说清所有这些矛盾和潜在的矛盾需求，并进行综合考虑