互联网软件测试设计感悟
今天部门小组内，一同学就软件测试设计进行分享，分享过程中大家有各种讨论和吐糟，颇有感悟。在此记录和写点自己的看法。
软件测试设计，单从狭义上讲，指的是软件测试用例的设计。是从需求转化到测试用例的过程。几点需要探讨的是：
一、测试测试用例是否要写？写的粒度如何？
目前就我个人测试的项目来看，测试用例都还是有写的必要性，即使项目再紧，时间再不够时，测试同学也要花一定的时间来进行测试设计，理清需求，理清测试的思路。当然，如果一个大牛，对此业务相当熟悉，或者业务非常简单，简单到不用设计也知道如何测的话，那就另当别论了。我目前的项目基本上都是会做测试设计，编写测试用例或者是画思维导图的。
但是，每个项目的测试用例的粒度会有所不同。对于之前测试的店铺业务，刚开始入职时，对于新人，测试用例都写的很规范，各种前置条件和校验点都很细致。此时对于业务的全面细致都很有好处。另外，这样的测试用例，业务沉淀的积累，更便于他人对此业务的了解，当有其它同学来测试此业务时，上手会更快。
后来对于此业务比较熟悉，业务也相对稳定，测试的校验点能评估的更全面，此时的测试用例，写的相对会比较粗，更多在校验点的覆盖，花在TC编写的时间会短一些。
之前接触的创新业务，项目处于探索阶段，需求变化比较频繁，测试用例的复用及参考价值不大。我更多的是以思维导图的方式，理清思路，对于TC更多的是写明测试的校验点，相对粒度比较粗。更多的是细节的确认，和产品，开发之前的沟通和需求变动的同步。保证测试用例的正确性和覆盖是否全面。
二、怎样的方式能更好的进行测试用例的设计？
测试用例的设计过程：在编写用例时，细化需求，产出测试的校验点。 测试时，一方面要以用户的角度去体验测试产品，另一方面，需要以开发的思维去分析功能。在黑盒测试编写功能时，可以走查代码，以白盒测试来辅助补全用例场景，各种异常流等，或去掉一些无意义的用例。
三、测试设计时要考虑的点有哪些？
广义上讲在做测试设计时，也是在做测试方案的设计，测试计划的制定。包括测试的手段，是手工测试还是自动化，可测性如何？是否会有性能，安全测试，是否要做兼容性测试，测试的重点等。但在有限的时间和人力资源的情况下，如何能提高收益和产出比？ 需要对不同的测试点分优先级，重点放在主要的风险点上。
四、测试角色的价值？未来的职业发展方向？
个人认为的软件测试角色的价值：在快速发展的互联网，需要的是更敏捷，更快速的响应和发布产品。测试的角色，是更好的保证产品的质量。
测试的义务，是发现问题，抛出问题和风险，持续跟进问题。一方面需要提升自己的技能，提升定位问题的能力。控制风险，评估影响（可与开发一起评估），对各种风险的识别的抛出。更高的境界，慢慢成为一个测试开发，测试辅助开发去执行测试，测试更多的是去开发工具，来帮助开发去测试。另一方面，测试要站在用户角度，熟悉业务，成为一个业务的专家。