上周我花了一些时间给从来没有学过测试的销售人员讲解测试。
主要是这位销售人员对测试比较感兴趣，再有就是想转行，废话不多了。
之前与我联系，我做了下准备，打算从最基本的知识开始讲起来。我问题她什么是测试，她总体告诉了我一下。
在交流中发现她其实对测试有点了解了，主要是在给她上课前，让她去看些测试方面的书籍。
我没有照着书上讲，而是从一个实践项目例子给她穿插测试知识。
我有一个项目它的功能主要有注册与登录功能，这样简单的需求已经有了形状。这个项目有开发人员，测试人员，开发经理，测试经理，配置人员。
首先我要了解测试流程是怎么样，她回答道：单元，集成，系统，验收，基本上也是对的。然后从这四个方面分辨给她讲解这几个阶段各自做哪些事情，需要谁来做。
现在你已经是测试人员，作为测试经理需要编写测试计划，不然没有计划根本就是一堆糊状的东西。在测试计划中包含哪些东西。这是我抛出来的问题，如果让她回答还是有点难度。所以我在白板上把测试计划要素给写出来，给她讲解。细节不做详细。
-----测试计划的依据，是开发计划书，也就是开发经理写的各个模块哪个开发负责
测试计划需要评审，我跟她说这是理想状态下，实践上很少有评审，如需了解我可以推荐一本书上的评审细节。测试计划评审完了，那就是根据需求编写测试用例。什么是测试用例，测试用例它其实是你测试的一个依据（通俗的说），如果你
没写测试用例，直接去测试系统，那么依据不可靠，对其他测试人员来说用例是一个很好的学习文档。
用例的要素同样要告诉她，这个时候就要融入测试方法。比如什么是黑盒测试，等价类，边界值，场景法，错误推测法，（因果图，决策表，这两个通常比较少用）。编写完测试用例，需要评审下（理想状态）。
-------测试用例的依据是：需求规格说明书，有时候也要附带上开发计划书。这些都是要事先准备，不然空手测试抓不到重点。
用例编写之后是用例的执行，对照用例执行步骤，发现缺陷时，做记录。
-----这里开始就讲缺陷流程
这个时候就涉及到缺陷报告，当然还是要素等，如何写（不做详细了）。当我们把缺陷报告编写时，那么就需要给测试经理来评审，看是否有重复的缺陷。等到测试经理评审后，发送给开发经理，开发经理根据开发模块再发送到相应的开发人员。
开发人员修复缺陷，转发给测试人员，测试人员验证缺陷，如果缺陷通过了，那么这个缺陷的状态就是通过了。如果不通过缺陷打回给开发人员，重新修复。
这其中还有一个有趣的现象，如果开发人员不认为这个问题是缺陷，那么如何解决？首先如果两边意见不同意，可以请开发经理来做判断。如果开发经理认为不是，那么这个缺陷可能被撤销。如果是，开发人员必须去做修复。
等到缺陷报告上缺陷，关闭率为90%以上，那么就可以写测试报告，有一点缺陷修复概率不可能100%这点可以理解，人无完人吗。
每个测试人员都需要测试报告，测试报告不需要写缺陷的详细内容，只需要写出模块的缺陷率即可。等测试人员把每个模块的测试报告写完，交付给测试经理，然后由他汇总。
这个测试过程中，需要有以下文档产出：测试计划，测试用例，缺陷报告，测试报告等。
等到项目讲完，我觉得应该她也有所了解，后期的深入就需要她自己发掘。在整个过程中尽量不要用术语给她讲解，因为她还没入门，要用简单易懂的话来解释。
