个人理解大概从3个方面去考虑:
　　1. 表单，也是基础的功能；
　　2. 逻辑方面；
　　3. 业务流程。
　　去面试，面试官问我一个很让我说不清的问题，她问我如何写好Expected Result，说实话当时听到这个问题我有点茫然，我拼命的考虑如何去诠释这个问题，事实上，这么多年工作，这么多年的测试用例中，我并未关注这个问题，一个好的Expected Result，个人认为是和将要实现的功能或者是需求要完全匹配。由于个人原因精力也不是很集中，似乎头脑处于空白时段，听到耳朵的问题，似乎大脑不懂得去思考。对于的面试我并不满意，但是面试官问我的一些问题，其实都很基础也很简单，但是细想起来似乎又不是很容易回答，嗨，总之是个失败的面试！
　　对于一个好的测试用例，无非是三点：
　　1.易用性：对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费很少的时间可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。对于不熟悉测试工作，不熟悉被测应用的人来说，也完全可以参照着该测试用例执行下去。
　　2.易维护性：当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设计人员，应该可以花费很少的时间完成定位并维护所有相关测试用例的工作。
　　3.可重用性：一个好的测试用例要保证可以随着版本的变化它始终保持可用状态，不能因为版本的变更，导致测试用例无效或者冗余。