第一步、明确测试范围
有些需求是多个部门一起合作的，可能会有多个测试和你一起分工合作。文章源自玩技e族-https://www.playezu.com/185193.html
你需要明确自己主要负责测试哪些地方，细化到功能模块。文章源自玩技e族-https://www.playezu.com/185193.html
这个时候，你应该明确两点：文章源自玩技e族-https://www.playezu.com/185193.html
1.你测试的模块到底依赖哪些其他模块文章源自玩技e族-https://www.playezu.com/185193.html
2.有哪些模块依赖你所负责测试的模块文章源自玩技e族-https://www.playezu.com/185193.html
设计测试用例的时候，把重点放在设计你自己负责的测试范围上；文章源自玩技e族-https://www.playezu.com/185193.html
对于有依赖的模块，也需要考虑降级和容错，也就是你要考虑，你负责的模块出问题了，对人家造成什么影响；文章源自玩技e族-https://www.playezu.com/185193.html
或者，人家负责的模块出问题了，对你所负责的模块有什么影响。文章源自玩技e族-https://www.playezu.com/185193.html
明确测试范围的2个好方法：文章源自玩技e族-https://www.playezu.com/185193.html
1.需求评审会一般产品会按功能模块去划分，分别评审，你需要和与你对接的产品和开发步调一致。文章源自玩技e族-https://www.playezu.com/185193.html
2.测前沟通，找开发和产品去做测试前的沟通，必要时，甚至要找关联的测试人员去做一次沟通，明确测试范围。
第二步、熟悉需求文档
需求文档至少要看三遍！
在你熟悉需求文档的时候，也相当于已经进入测试了，像一些公司美其名曰：文档测试。
产品经理写需求没想到的，你想到了，都可以大胆的提出来，要有质疑的精神。
另外这里还有一个小建议：尽量让产品经理把产品的流程图画上，流程图可以反映出数据流向是怎样的，这可比文字更加直观。
这样你会对整个需求文档有更深的理解。
第三步、熟悉开发文档
开发的系统设计文档、接口设计文档、数据库表结构，如果有的话，最好都看一遍。
第四步、设计和编写测试用例
现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。
•Excel 比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。
•Xmind 比较适合用例较多、功能相对复杂、结果预期比较多样的功能。
以下分别举两个使用场景：
（1）假如说测app的话，个人感觉用Xmind可能会更合适
用Excel的话，由于功能比较繁琐，可能用例条数会很庞大，一方面测试起来，看太多表格，容易头晕。另一方面维护起来也比较麻烦。
而Xmind可以只是把功能点写上，本身结构化的设计思维会让测试思路比较清晰，测试用例维护起来比较方便。
（2）对于上线后的回归测试验证点（CheckList），我们可以用Excel去表达，主要是针对主流程主功能的正向操作进行验证，逐条操作也防止漏测。
但其实用哪种软件编辑测试用例，都是看个人的使用习惯，关键是自己能看懂，别人也可以看懂就可以了。
设计测试用例时的，需要结合需求文档，把测试点罗列清楚，尽量用简洁的语句表述，非常忌讳写出过于啰嗦的用例。
另外，设计测试用例的几条思路我也简单介绍一下：
1.按模块把功能点罗列全，切记不要照抄需求文档，这样写不写有什么区别？
2.软件测试的基本测试方法要有效利用上，像边界值法、等价划分类、场景法等等，都是特别实用测试方法。
3.不要在细枝末节上纠结太多，根据二八法则，80%的bug都集中在主流程里面，要确保主功能主流程没问题。
第五、用例评审
测试用例设计完，一定要和产品研发一起评审测试用例，漏掉的测试点要及时补充。
评论