以软件测试员的身份实习已经近两个月了，虽然测试的工作相对枯燥，不过真的很能锻炼人的逻辑思维和发散思维。而且作为一个对设计念念不忘的测试实习生，我从测试工作中发现了一些对设计工作有启发的东西。
1.设计时没考虑到的情况都是未来要填的坑
都是未来要填的坑！都是未来要填的坑！都是未来要填的坑！(重要的事说三遍)
直到接触到测试用例，我才真正明白一个产品需要考虑的细节有那么多。就拿一个简单的输入框为例，输入框的位置、样式、默认状态，输入的格式限制、长度限制、重复限制，验证的时机、反馈的方式，提示显示的位置、样式、种类和各自的文案等等，这些都需要一一进行测试。如果设计师没有把细节考虑清楚，那么开发在实现的时候就有可能按照自己的理解来实现，然后测试重新向设计师一个个确认，开发再返工，大大影响了项目的进度(别问我怎么知道的.......)。而且更可怕的是，如果测试也遗漏了这些细节，那问题有可能直接呈现在用户面前，造成不能挽回的过失。所以，在做产品设计的时候不能满足于得到一个模糊的demo，要深入思考每一个细节，给出一份清晰，完整的设计稿。
2.构建复杂的东西要先理清思路，不急于开始着手
写测试用例的时间是执行测试用例的三倍，而写测试用例的一半时间是在梳理各个功能点需要测试的内容和测试的顺序。虽然直接测试可以快速发现问题，但是只有根据完整的用例进行测试才可以保证测试的全面性。过去我进行设计的时候总是迫不及待的就开始在纸上画草图，轻视一开始的需求分析和结构设计，直到细化设计稿的时候才发现流程有不合理的地方，结果只能推翻重来。快速地产出可见的成果能够带来很大的成就感，但不能因为求快而忽视前期的思考和准备，否则就得不偿失了。
3.同事也是忙碌又没有耐心的用户
Don't make me think里面写到，用户都只是匆匆地浏览，而不会仔细去看网页上的内容。其实我们的同事也是如此，大家都有着繁重的任务，内心对任何难懂的文档都是拒绝的。遇到易读性很差的文档，也许就直接匆匆浏览，然后按自己的理解去实现。所以不管是写缺陷报告还是交互说明，都要尽可能让同事轻松，准确地理解内容。使用表意清晰的符号和适当的图示都是很好的方式。如果实在是复杂的情况，不妨亲自跟同事当面讲解一下，避免发生理解偏差的情况。
其实这些也不仅限于设计和测试，和他人合作，完成工作，都需要注意这些细节。ps：三月是春招最关键的时间，童鞋们留意各种消息，不要错过啦！
