开发完了，如何做产品的测试用例？

lsekfe

前言
　　如果你听说过“测试驱动开发”（TDD：Test-Driven Development），单元测试就不陌生。
　　单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。
　　比如对函数abs()，我们可以编写出以下几个测试用例：
　　输入正数，比如1、1.2、0.99，期待返回值与输入相同；
　　输入负数，比如-1、-1.2、-0.99，期待返回值与输入相反；
　　输入0，期待返回0；
　　输入非数值类型，比如None、[]、{}，期待抛出TypeError。
　　把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。
　　如果单元测试通过，说明我们测试的这个函数能够正常工作。如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。
　　单元测试通过后有什么意义呢？如果我们对abs()函数代码做了修改，只需要再跑一遍单元测试，如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的修改与原有行为不一致，要么修改代码，要么修改测试。
　　这种以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。
　　*廖雪峰 python3 教程-单元测试*
　　学python3看到这里的时候，想起之前做2.0上线测试用例，不断完善用例时自己的心得，有种相见恨晚的感受。
　　产品的基础架构出来后，各类功能的开发和测试，如果都能够从这个理念出发，那么 开发和产品的沟通会顺利很多，效率也会提高很多。
　　因此打算做做总结，为接下来要做的2.2 做准备。
　　测试用例一般包括以下几个部分：
　　1、前置条件
　　2、输入
　　3、预期结果
　　4、测试结果及描述
　　PM 在做产品设计的时候，就编写好测试用例的1-3部分，不仅有利于之后的测试，还有助于开发团队精准了解具体需求，提高需求的逻辑完备性。
　　针对比较重要的开发任务，建议这样做。
　　实例
　　在实际操作过程中，最容易发生遗漏的地方是 “输入”部分。因此，我们从输入的规则上，就应该尽量做到遍历所有情况，具有逻辑完备性。
　　遍历规则：
　　有数据输入
　　有效数据输入：功能步骤1，功能步骤2，...
　　无效数据输入
　　无数据输入
　　再拿上面取绝对值函数abs()为例：
　　有数据输入：
　　有效数据输入：
　　输入正数
　　输入负数
　　无效数据输入：
　　输入非数值类型
　　无数据输入：
　　应用到我们客栈一个很小的功能测试用例，则体现如下：需求者确认报价