共计 2643 个字符，预计需要花费 7 分钟才能阅读完成。
1 测试要站在用户的角度
- 这个不难理解，咱们所有测试流动应该站在用户角度思考；
- 比方为什么会有测试思维和开发思维，这两个是有本质区别的；
- 简略说，什么是用户的角度？
①最起码软件测试要依据用户需要来测试，要发现软件是否满足用户的需要；
②站在用户的视角，扫视软件的易用性和好看性；
③站在用户的视角，思考软件的应用的应用场景；
④站在用户的视角，软件是否具备弱小的应用粘性等；
⑤站在用户的视角，软件如何体现能力为用户带来更大的利润。
当然还有很多。。。
- 能够这么说，把产品和软件“当本人儿子”看待！！！你会怎么做！！？？
- 概括说：
测试工作应该建设在满足客户需要的根底上，如果产品最终不能满足用户需要，那么开发、测试的投入都是徒劳的。
2 软件测试要尽早进行
- 场景 1：
软件版本转测了，开始筹备打算，设计用例等等，是不是有点迟了？ - 场景 2：
在需要评审阶段，提出测试的要求，可测试性剖析等，这样是不是会好点呢？ - 咱们简略看下场景 1 和 2，不难发现，必定场景 2 会好点，为啥？
- 概括说：
软件的谬误存在于软件生命周期的各个阶段，因而应该尽早发展测试工作，把软件测试贯通到软件生命周期的各个阶段中，这样测试人员可能尽早地发现和预防谬误，升高谬误修复的老本。尽早地发展测试工作有利于帮忙测试人员理解软件产品的需要和设计，从而预测测试的难度和危险，制订出欠缺的打算和计划，进步测试的效率。
3 穷尽测试是不可能的
我的项目今天上线，仍有一大堆性能未测试，怎么办？
- 场景 1：加班加点，全副功能测试。
- 场景 2：划优先级，重点测试。
你更偏向哪个？
其实，软件测试自身就是有危险的，不论是抉择那种形式，都不可能保障软件是 OK 的，但因为测试的数据量大，工夫短等起因，咱们又不能进行穷举测试，所以咱们抉择场景 2 会好点。
- 概括说：
因为工夫和资源的限度，进行齐全 (各种输出和输入的全副组合) 的测试是不可能的测试人员能够依据测试的危险和优先级等确定测试的侧重点，从而管制测试的工作量，在测试老本、危险和收益之间求得均衡。
4 遵循 GoodEnough 准则
说实话，我当初也不怎们了解这是啥，
根本意思就是：既不要做过多测试，也不做不充沛的测试。
概括说：
测试的投入与产出要适当衡量，造成充沛的品质评估过程，这个过程建设在测试破费的代价之上。测试不充沛无奈保障软件产品的品质，但测试投入过多会造成资源的节约。可通过需要剖析和危险剖析找到测试侧重点，制订最低测试通过规范和内容，再进行具体问题具体分析。做到适当测试。
5 测试缺点要合乎“二八”定理
- 也称为 Pareto 准则、缺点集群效应；
- 个别状况，软件 80% 缺点会集中在 20% 模块中，缺点并不是均匀散布的。因而在测试时，要抓住主要矛盾，如果发现某些模块比其余模块具备更多的缺点，则要投入更多的人力、精力重点测试这些模块以进步测试效率；
6 防止缺点免疫
- 简略用个词语来形容下“抗药性”，因为测试人员对软件越来越相熟，可能会疏忽一些细小的问题，导致发现问题的能力降落；
- 同一类或同一个测试用例被重复执行，可能导致发现问题的品质也会降落；
- 以上景象也被称为“杀虫剂”景象。改善思路是要及时更新测试用例和防止造成思维定势。
7 分阶段测试
- 这个其实如果是有欠缺的测试流程的话，根本都会进行分阶段测试，比方单元测试，集成测试，零碎测试等等；
8 第三方体验性测试
- 体验的角色为非测试人员、非开发人员之外的人员；
- 起因：测试人员可能对本人测试过的产品曾经造成思维定势，某些细节或者问题不容易发现；而软件自身就是开发人员码代码整进去的，那开发根本不会认为本人写的是有问题的。那么这个时候，如果减少第三方的体验性测试，势必能够开掘一些问题。
9 并不是所有的缺点都要修复
- 再不影响用户应用的前提下，如果软件缺陷修复的老本太大、修复工夫缓和、不值得修复等状况，是能够思考临时不修复缺点，等机会成熟了，能够思考下；
- 还有一种状况是发现的缺点自身不属于缺点，这个就要依据具体情况来剖析了。
10 模块缺点越多，暗藏危险越大
- 如果咱们发现某个模块发现的缺点越多，那开发批改的中央可能就越多，则产生的未知危险就越大，那咱们就要重点剖析，重点投入人力进行测试。
11 测试具备破坏性
- 往往咱们应用一些正规的伎俩或者罕用的伎俩，无奈发现更多的缺点时候，咱们须要换一种思路，比方如何毁坏软件，让他的弱点出现进去，这样能力更多发现软件暗藏的问题。
12 测试只能发现存在的缺点，而不能证实软件没有缺点
- 听的最多的一句话是“这问题你都发现不了，要测试是干嘛的！！？？”；
- 哈哈，兴许你能够说“这么简略的、一键操作的工作都能写出 bug，要开发是干嘛的？”
- 开个玩笑，做测试，咱们只能说尽可能多的发现存在的、暗藏的缺点，然而咱们不能保障测试过的软件没有缺点，没有人有这个能力和实力这样说。
13 测试因该要系统化、流程化
- 针对一个被测试对象，咱们要严格进行系统化剖析，制订具体的测试计划。严格执行测试流程，充沛援用各种测试技术，系统化进行测试，而不是轻易测一下，点一下；
- 测试也有相干的流程和制度，咱们必须遵循，不能因集体志愿独断独行。
14 软件测试须要进行迭代
- 咱们不能指望一次性就发现暗藏的问题，须要进行迭代测试，循循渐进；
- 同时，因为缺点自身也有生命周期，如果要对缺点进行修复，可能对
15 适当做回归测试
- 每次迭代，都有可能进行回归测试，而不是只测试本版本。适当的进行回归测试可无效防止测试笼罩不全。
16 测试要遵循肯定的规范
- 做测试不是轻易测试，咱们要遵循肯定的规范；
- 比方公司方面的、部门方面的、行业当面的等规范，进行标准化测试。
17 测试之木桶原理
- 测试只是软件产品实现过程过程中的一个环节，产品质量存在各个环节，不能说产品质量由测试来决定，只能说测试对产品质量起到推动作用。如果把软件品质全副赌在测试身上，那将是灾难性的决定。
18 测试之立场
- 一句话，做测试肯定要有【准则】，这个准则不仅指的是前边提及的所有准则，另一方面指的的是【立场】；
- 举例：
如果发现一个缺点，站在产品、用户、测试的角度，确定是一个缺点，然而开发人员认为只是本人简略的操作或者失误，不认为是缺点，通过侵犯周折后，你被开发压服了。这种状况是不容许的。
①能够先把缺点进行剖析和记录，用充沛的事实和证据谈话；
②向上反馈，由部门主管、项目经理、产品经理决策，本人拿不准的不能私了；
③如果你 100% 确定是缺点，就依照缺点的解决流程来，不能因为他人的质疑而扭转本人的立场。
【特地阐明】：常识来源于网络、各种材料、书本、网站等，本文仅用于学习应用，不做他用，如果波及版权问题，请分割博主删除，谢谢
