测试反思1---会议室预订增加需求配置

今天有个比较紧张的功能割接---会议室预定中需求配置，因为是领导提的需求，所以大家都很重视。不过这不是今天要说的，要说的是为什么放了三次，都还有问题，虽然是小问题。

首先说下，我们本来是有预订会议室功能的，这次是在原基础上做二次开发，而所用系统是我们公司的OA 系统，所以牵扯到单元测试和集成测试。

功能的原型文件是我画的，虽然需求讨论会我没有参加，但是开发经理给说了大体需求，然后根据转述画原型，同时在原型的制作和评审中，逐渐了解了具体需求。

下面就是开发提交测试了，是于今天早上提交的测试，由于功能需要，因此是需要今天割接的，同时手上还有几个功能也是要今天割接的，所以并不是一整天都在测试会议室，估计下来，在这个功能上花费了3个小时。

这个功能分为会议室管理、预订会议室、个人预订记录管理（变更、取消预订记录）、全部预订记录管理（变更、取消预订记录）、以及会议室查看。因此，我就依照顺序，做了测试：增加会议室、预订会议室、变更预订记录、取消预订记录。因为功能于会议室管理，并无代码修改，因此并未做过多测试，仅是增加了一个会议室并测试会议室管理列表的搜索条件修改。

预订会议室的测试，就是重点了，因为是主要修改的内容。首先，是预订的入口，共有2个入口，要保证进入页面是同一个。其次，是预订的页面。本次的修改，就是在预订的页面，添加了需求配置的复选内容和各选项的备注、接口人选择。复选内容需要在点击特定按钮后出现，各选项的信息需在选择该选项时出现，接口人和类别的下拉选择，在选择相应信息后，自动带出指定信息。

割接中的问题，分别为接口人信息中邮件的换行、接口人选项更新、接口人信息的显隐控制。

第一个问题：接口人信息中邮件的换行。测试环境时，并未对常见邮箱地址长度进行验证，因为测试环境也是有地址的，自然而然就认为长度时合适的，然后在正式环境时，是个长名的邮箱地址，结果就换行了。可实际上，该页面是可以展示的，只需要将字段长度做调整。

第二个问题：接口人选项更新。

第三个问题：接口人信息的显隐控制。问题具体描述是：在预订页面，没有选择了接口人的下拉选择，因此没有显示接口人信息，但变更页面，在预订时没有选择接口人，但显示了接口人信息。单元测试中，没有测出来。